<J1A84>
yes you can see the scad file for download
<J1A84>
but it is a L/R bolt with L and R Nut
<sinned6915>
a company that was a client made threadmills
<J1A84>
and it is not a real thread geometry
<sinned6915>
they would make these and a double headed stud and pass out at tradeshows
<sinned6915>
real thread geometry
<J1A84>
yeah not that difficult
<sinned6915>
you'd watch seasoned, experienced machinists swap it end for end and screw it on and you could see thie brains short circuiting like "how can this be?"
<InPhase>
sinned6915: The problem is that peeps[zen] correctly fixed how difference() will behave. ScrewHole does a difference() { children(); ...thethread...; } 2019 treated the children() as missing if missing, and flipped the negative screw thread around to positive. This was basically a bug that differs from specified usage.
GNUmoon has quit [Remote host closed the connection]
<sinned6915>
whoa, what! gimme a moment
<J1A84>
they look cool but are much weaker compared to full threads.. but can be useful if you need to get through a other nut first
GNUmoon has joined #openscad
<InPhase>
sinned6915: It just happens your design takes advantage of this 2019 bug in how difference works, because you are using the ScrewHole operator that puts a hole in its children as if it generates the positive for the thread. But what you are supposed to be doing is using ScrewHole on the thing to put the hole in. You set up for this in LHole and RHole, but then you don't use those modules you created
<J1A84>
yes you can index children if needed without all are used
<InPhase>
It's correct. That's not the problem.
Junxter has quit [Ping timeout: 246 seconds]
<InPhase>
sinned6915: Look at your code lines 70 and 71, where RHole and LHole have NO children.
<sinned6915>
Inphase: you said that last night and i did nto understand
<J1A84>
InPhase we already found that .. but the code is working in snapshots version
<sinned6915>
should the R/LHole be children to main object?
<InPhase>
Your code should look like "RHole(H, [0,0,-H/2]) LHole(H, [0,0,-H/2]) HermiNut();"
<J1A84>
sinned6915 no the main object is the children() in R/L Hole
<InPhase>
sinned6915: And in fact, that resolves it. I just tried.
<sinned6915>
it seems to only do the one thread, not both
<sinned6915>
but i think i am understanding it
<InPhase>
I see both.
<InPhase>
Maybe you accidentally put a semicolon in there.
<InPhase>
https://bpa.st/DURQ This is what I'm seeing it correct with, in both 2019.05 and 2021.01.
<InPhase>
Plus a recent master branch build.
_xxoxx has quit [Quit: Leaving]
JakeSays has quit [Ping timeout: 248 seconds]
JakeSays_ has joined #openscad
<sinned6915>
its taking the thread out, but not the right threads. there should be a crossover
<InPhase>
We make an effort to strive to preserve the behavior of correct code, but for the sake of keeping the language sane and low in bugs, we can't and shouldn't preserve bug compatibility. You just happened to, by a mistake, stumble into a bug in your code that worked in 2019.05, which led you astray on the right usage.
<InPhase>
Yes, I see crossover.
<sinned6915>
oh , i totally get that bug issue.
<sinned6915>
i even suspected it last night and said i wondered if there was a mistake that 2019 was tolerating and 2012 was not
<InPhase>
It's hard to take an image that adequately shows the cross-over, but I definitely see it. :)
<sinned6915>
that paste you put up works right
<sinned6915>
my code is not
<sinned6915>
so what i a struggling to apply is which is the parent and child
<sinned6915>
the child is the application of module ?
<InPhase>
A() B(); B is the child.
<InPhase>
A "operates on" B.
<InPhase>
And thus A receives B as children().
<sinned6915>
in the case of the thread library, the module defines the threads
<InPhase>
ScrewHole is designed to be used as ScrewHole(...) SomeObject();
<sinned6915>
ok, iirc we defined the RH and LH becasue of the mirror
<InPhase>
You chained that along with RHole(...) { ScrewHole(...) children(); } which means you created an operator RHole to use as RHole(...) SomeObject();
<InPhase>
A problem in your usage that you should be mindful of is that your mirror([1,0,0]) operates on both ScrewHole and its children.
<sinned6915>
right
<InPhase>
That might be fine in this case, but if you did not want it, you would need: mirror([1,0,0]) ScrewHole(...) mirror([1,0,0]) children();
<sinned6915>
back up, the mirror is what is throwing off.
<sinned6915>
how to do it w/o the LH module
<InPhase>
You could also make a DualHole module like: module DualHole(...) { ScrewHole(...) mirror([1,0,0]) ScrewHole(...) mirror([1,0,0]) children(); }
<sinned6915>
why would i mirror the children in that last example
<J1A84>
InPhase that code works fine with 2022 too (without change)
<InPhase>
You flip the children around, put a normal hole in them, then flip the universe around again to get the children back to normal, leaving you with a mirrored hole.
<sinned6915>
i am going to have to contemplate that one
<InPhase>
Basically, you do your operation in the mirror universe temporarily. :)
<sinned6915>
i take it that you got your computer issues sorted if you are running openscad?
<InPhase>
Yes. That was an extremely arduous battle though, leaving me quite exhausted.
<sinned6915>
yes, i KNOW that pain!
<InPhase>
9 hours of extra work right after a full day of work.
<J1A84>
this is unnecessary complex .. just use two screws and mirror one.. and substract that union from your nut
<sinned6915>
hopefully its over
<InPhase>
The computer is 100% as good as it was.
<sinned6915>
J1A84: i was halfway tying that when InPhase came back.
JakeSays_ has quit [Ping timeout: 248 seconds]
<sinned6915>
I have like 4 things to try now.
<J1A84>
good training though
<sinned6915>
and whole bunch of stuff to contemplate while cutting grass
<InPhase>
J1A84: The benefit of ScrewHole over ScrewThread is that it does bonus work to get the clearances right. But of course one is welcome to rip that clearance bonus logic out of ScrewHole's implementation and make one's own.
<sinned6915>
yes
JakeSays has joined #openscad
<sinned6915>
I think it is useful to have the 2 operations. you dont have to worry about remembering the clearances
<InPhase>
But also, I think it is often helpful to do holes as operators, and get used to that mindset. It lets you work in the positive-space with holes as things added.
<InPhase>
I penned a philosophy choice into the API, but I think it's a reasonable one given the language structure.
<InPhase>
I would not besmirch anyone choosing a different preferred API and customizing. It is a minor "I think this is better" rather than a "it should definitely be this way" to my assessment.
<sinned6915>
ok, that is where i get goofed up as to what is parent and what is child
<sinned6915>
"// This creates a threaded hole in its children using metric standards by default."
<sinned6915>
how does the hole have children?
<Scopeuk>
So you would do hole() objectThatShouldHaveHole();
<sinned6915>
right, but that seems backwards to me
<Scopeuk>
This is the design concept InPhase was talking about
<Scopeuk>
It's object hierarchy rather than conceptual design higherachy
<sinned6915>
yes, that is where i am lacking in experience
<Scopeuk>
Think of it like hole is working the same way as rotate or transform
<sinned6915>
i am not disagreeing, i am trying ti get my head around itin the correct way
<Scopeuk>
You can only make modifications to your children
<Scopeuk>
It's a bit tricky to wrap your head around in the first instance
<InPhase>
sinned6915: So the reason it makes sense is because you pick up a block of wood and go "I will drill a hole in it". This is an operation, and modules that act on their children are operators. They change the children.
<InPhase>
PutHoleIn() Wood();
<InPhase>
This comes from the notion of operators in math and physics, and fits nicely with the functional language philosophy.
<InPhase>
It also scales better. TenHoleCircle() Wood(); If you wanted a lot of ten hole circles for some reason, this would be really handy. Without it you'd need to do some clunky differences with loops and you'd lose the abstraction advantages of the operators.
JakeSays has quit [Ping timeout: 240 seconds]
<InPhase>
The price is it helps in some cases then to be able to specify the location and orientation of the holes, which is why my ScrewHole module takes optional position and rotation parameters. You then end up with a chain of operators putting holes at various positions and orientations into an object, but it's nice and orderly.
JakeSays has joined #openscad
<sinned6915>
i have like 5 years of bad appliction to unlearn
<sinned6915>
i am not trying to argut
<InPhase>
Yep. There is a reason I described it as worth "getting used to" rather than "obvious".
<J1A84>
sinned6915 all is based on how you write your modules .. difference(){wood();hole()}; is the syntax so difference is A- B..
<sinned6915>
actually, i blame buZz ;)
<J1A84>
now you can make a module where A is the children or B .. or where A is the first children and B the second (which is what difference does)
<J1A84>
but you also can revert this and write a module that is substracting the first children from the second .. so you could use hole(){holeshape(); wood();}
<J1A84>
it would just be confusing when there are more children;
<InPhase>
sinned6915: One should think of it as doing pretty general sorts of transformations.
la1yv_a has quit [Read error: Connection reset by peer]
la1yv_a has joined #openscad
<buZz>
sinned6915: what codestyle are you blaming me for?