Closed Irev-Dev closed 3 years ago
This is not related to cq-cli, I get the same error without it. You need to call workplane()
before move()
. It might be considered a functional bug of CQ, it might be a feature.
The example that @marcus7070 posted later in that Discord conversation works with newer versions of CQ, but the last stable release is missing the scale
argument to spline()
(PR here). This could maybe be an argument for upgrading the version of cq-cli that CadHub uses, but once you break away from the latest stable release of CadQuery core (via cq-cli), where do you draw the line? Should CadHub always be running on the bleeding edge, even with the risk or stability issues, or should it focus on stability over new features? I think only @Irev-Dev is qualified to answer that, and I'm happy to help get CadHub set up to run a newer version if that's what's decided on.
This version works with newer versions of CQ:
from cadquery import *
d1 = 58.5
d2 = 56.5
d3 = 63.5
d4 = 84
d5 = 88
h1 = 8.5
h2 = 154
l1 = 14.5
l2 = 4.5
cup = (
Workplane("XY").circle(d1 / 2).extrude(h1)
.faces(">Z").circle(d3 / 2)
.workplane(offset=h2).circle(d5 / 2)
.loft()
.cut(Workplane("XY")
.circle((d3 - 3.5) / 2)
.workplane(offset=h2).circle((d5 - 3.5) / 2)
.loft()
.translate([0, 0, h1])
)
.faces("<Z").circle(d2 / 2).toPending().cutBlind(8.5 - 1)
)
ring = Workplane("XZ").move(88.0 / 2, 0).circle(1.5).revolve()
lid_rings = (
Workplane("XY").circle(91.75 / 2).extrude(0.6)
.faces(">Z").circle(91.5 / 2)
.workplane(offset=4.0).circle(88.0 / 2)
.loft()
)
inner_cove_d = 56;
lid_invert = (Workplane()
.workplane(offset=4.6)
.transformed(rotate=(5, 0, 0), offset=(0, 0, 17)).circle(73 / 2)
.transformed(rotate=(-5, 0, 0), offset=(0, -5, -3))
.moveTo(inner_cove_d / 2, 0)
.radiusArc((inner_cove_d / -2, 0), inner_cove_d / 2)
.spline([
(inner_cove_d / -3, inner_cove_d / 3),
(0, inner_cove_d / 2.5),
], [
(0, 1),
None,
(1, 0),
], scale=True, includeCurrent=True)
.spline([
(inner_cove_d / 3, inner_cove_d / 3),
(inner_cove_d / 2, 0),
], [
(1, 0),
None,
(0, -1),
], scale=True, includeCurrent=True)
.close()
.loft()
)
depresser = (Workplane("XY")
.circle((13 - 2) / 2)
.workplane(offset=0.5)
.circle((13 - 2) / 2)
.loft()
.faces(">Z")
.circle((13 - 2 - 1) / 2)
.workplane(offset=0.5)
.circle((13 - 2 - 1) / 2)
.loft()
.faces(">Z")
.circle((13 - 2 - 2) / 2)
.workplane(offset=0.5)
.circle((13 - 2 - 2) / 2)
.loft()
# .faces("|Z").wires().fillet(0.20)
)
lid = (lid_rings
.faces(">Z")
.circle(79 / 2)
.transformed(rotate=(5, 0, 0), offset=(0, 0, 17)).circle(73 / 2)
.loft()
.cut(lid_invert)
.faces(">Z[0]")
.transformed(offset=(0, 0, 0))
.move(17 / -2, 15)
.vLine(17.0)
.radiusArc((17 / 2, 15 + 17), 44 / 2)
.vLine(-17.0)
.hLine(-18.0)
.close()
.cutBlind(-5.20, taper=25)
.faces(">Z[-1]")
.workplane()
.transformed(rotate=(0, 0, 180), offset=(0, inner_cove_d / 2 - 11, 0))
.hLine(14 / -2)
.vLine(1.5)
.hLine(1.2)
.vLine(2.0)
.hLine(0.5)
.vLine(4.0)
.ellipseArc(2.5, 2.5, angle1=180 - 90, angle2=-90, sense=-1)
# .hLine(15.3 / 2)
.hLineTo(0)
.mirrorY()
.wire()
# .cutBlind(3.5) # HERE
.cutBlind(-3.5) # HERE
.faces(">Z[-1]")
.workplane(origin=(inner_cove_d / -4, -5, 0))
.circle(13.0 / 2)
.cutBlind(-1.5)
.faces(">Z[-1]")
.workplane(origin=(inner_cove_d / 4, -5, 0))
.circle(13.0 / 2)
.cutBlind(-1.5)
.faces(">Z[-1]")
.union(depresser.translate((inner_cove_d / -4, -5, 17)))
.faces(">Z[-1]")
.union(depresser.translate((inner_cove_d / 4, -5, 17)))
)
show_object(lid)
log(f"is lid Solid valid? {lid.findSolid().isValid()}")
You need to call
workplane()
beforemove()
. It might be considered a functional bug of CQ, it might be a feature.
Yes, I trip myself up with that one frequently. I don't know if there is a reasonable way to avoid it though (there are plenty of breaking ways to avoid the Workplane.workplane
or .center(0, 0)
call after every method that returns a Solid/Compound, but breaking changes for this are probably not going to be acceptable).
I took a look at _findFromPoint
and this behavior is actually logical/as-described. There is not logical way to find a endpoint of a compound (likely solid) object. An explicit error makes sense.
If it's easy to install multiple versions of the cli on my docker image, then I think multiple versions makes sense.
@Irev-Dev This PR that I just opened on the CadHub repo should fix your problem with rendering the lid example. I've implemented a beta release system with cq-cli so that we can avoid the risks of doing a rolling release on main/master. I can publish tested beta releases as CadHub starts to fall out of date with the latest features of CadQuery. Hopefully this will keep CadHub's CadQuery integration stable.
cq-cli has been updated in CadHub's CadQuery integration and the lid example now works.
Here's a link You can see what I've commented out get it partially working.
Full code gives the following error.
full code