<gunnbr>
Or you're on the same side of the split as I am.
LordOfBikes has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
ferdna has joined #openscad
Jack2292 has joined #openscad
Jack22 has quit [Ping timeout: 256 seconds]
lastrodamo has joined #openscad
ferdna has quit [Quit: Leaving]
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
gunnbr has quit [Ping timeout: 240 seconds]
lastrodamo has quit [Quit: Leaving]
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
ur5us_ has joined #openscad
rvt_ has joined #openscad
rvt_ has quit [Client Quit]
Jack2292 is now known as Jack22
* Jack22
makes some noise
rvt_ has joined #openscad
rvt_ has quit [Client Quit]
othx has quit [Ping timeout: 240 seconds]
othx has joined #openscad
ur5us_ has quit [Ping timeout: 268 seconds]
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
arebil has joined #openscad
foul_owl has quit [Ping timeout: 256 seconds]
foul_owl has joined #openscad
lastrodamo has joined #openscad
fling has quit [Ping timeout: 256 seconds]
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
rvt_ has joined #openscad
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
la1yv has quit [Read error: Connection reset by peer]
la1yv has joined #openscad
rvt_ has quit [Quit: rvt_]
rvt_ has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
rvt_ has quit [Quit: rvt_]
<pa>
merry xmas, folks
<pa>
quickie: a good stl for an adjustable wrench? I tried the print in place model, but 1. sucks with pla and 2. it has really short beaks, and i doubt that one is useful when fully open
<InPhase>
pa: Well generally this is going to work better in metal.
<InPhase>
A plastic print-in-place adjustable wrench is going to always have too much wiggle from the clearance needed. So the only viable approach would be one that you assemble in some manner.
<InPhase>
The metal designs could be pretty closely copied for this, printed in three pieces. You would need either a metal screw for the axis of the thumb adjuster, or a printed rod. Since that piece is not load bearing a printed rod can still work.
<InPhase>
Some post-print finishing work is probably required to clear out the slider rack of any print imperfections.
<InPhase>
It will need to be printed in 100% infill. I figure the metal ones probably already have approximately the optimal ratios of the sizing of pieces. I don't know what you could change about that for a printed piece other than maybe making the handle full thickness instead of inset like the metal ones tend to do.
<InPhase>
For the thumb adjuster Jack22's German-language threading solution might be a good choice. You need gentle touch edges on that threading.
<InPhase>
Alas, I haven't yet memorized how that interface works, and the docs haven't been filled in yet, so best to just ask Jack22 about it. It uses the Gewinde call here: https://github.com/UBaer21/UB.scad
<InPhase>
Jack22: I feel like the ultimate thread module would combine some features of our two ones, and also take an arbitrary list of line points for the z-profile, but then apply optional modifiers to that input set of points to do the bonus features like narrowing the top for insert ease.
<InPhase>
Plus presets for all the metric and imperial standards.
<Jack22>
and you need to study the module for 2yr to use it - Ü
<InPhase>
:) Interfaces can be sorted out.
<InPhase>
Implementations can't always be made clean, but with a few layers and careful workflow thoughts, an API usually can be.
<Jack22>
i think most important are the presets for easy usage
<InPhase>
Right. It would need multiple entry points to a common base.
<InPhase>
I tried to get at that in mine, but the common base needs restructured before other types of more general threads could be supported.
<InPhase>
I was still an early OpenSCADer when I wrote that though, and I am not even remotely pleased with its structure.
<InPhase>
(The inside part)
<Jack22>
i think best would be to get "pitch" for rotate_extrude - then you just need a thread profile
<InPhase>
Yeah maybe.
<InPhase>
My early attempts to use linear_extrude for threading revealed this is just a computational nightmare. rotate_extrude at least starts in the right direction.
<InPhase>
But this will also not be adequate for threading, because one needs to alter the thread extents along the path to do tapering.
<Jack22>
hmm right
<InPhase>
And the base of threads needs to cleanly terminate at a thread and not abruptly end before the bolt head.
<Jack22>
just intersect with a cylinder would do that
<Jack22>
I think it is better if the thread ends /starts before the head - this is just something difficult to machine
<InPhase>
Also coming to a point is occasionally useful. As a novelty I put wood screws in the threading library, but a more killer-ap for that I think has been these, which were hugely popular for downloads: https://www.thingiverse.com/thing:2191927
<othx>
InPhase linked to "Customizable Drywall Anchors, Auger-Style by rcolyer" on thingiverse => 2 IRC mentions
<InPhase>
Those things actually work exceptionally well. I put up a lot of things around the house with those anchors when I REALLY want something to stay in the wall, and a stud is not available.
<InPhase>
The thingiverse comment I left there of "I've often experienced the problem of some excess force removing an old anchor from a wall leaving a hole larger than the old anchors that were used." can be read as "kids *sigh*"
<InPhase>
But to date I have never once seen a kid yank anything held with those anchors out of a wall.
<Jack22>
probably as in US these dry walls are popular
<InPhase>
Yep. Almost every internal wall of every house.
<InPhase>
The only internal wall I have that's not drywall is the brick facade around my fireplace.
<InPhase>
I think the ideal module form will take a "cross-section thread profile" function, and an f(r) for the tapering profile.
<InPhase>
Then we can preset some tapers for things like the auger anchor points, wood screws, or easy insert bolts.
<InPhase>
Since there were no function literals when I wrote my threading there is a single function that I deemed "good enough" embedded and interwoven in a messy way. But a cleaner functionally-modularized approach would take that externally.
<InPhase>
Time to go do some more Christmas festivities. Later. :)
* Jack22
is surrounded by ferroconcrete
<Jack22>
CU
TheAssassin has quit [Remote host closed the connection]
<othx>
peeps[zen] linked to "Parametric Helical Coil (Spring) by thehans" on thingiverse => 2 IRC mentions
<peeps[zen]>
pretty sure the concept could be adjusted to threads
<tcurdt>
I did that for threads before - but I remember running into problems when things got a bit more complicated ... but cannot recall the exact scenario
<Jack22>
peeps[zen] it is about the number of slices needed
<peeps[zen]>
the recent changes to linear_extrude should help smooth things out a bit too, i would think.
<Jack22>
peeps[zen] when using $fn=36 only for the circle it gets weird
<Jack22>
it renders fast but just looks strange in preview linear_extrude(4,twist=3*360,slices=60)T(0.2)circle(5,$fn=36);
<peeps[zen]>
what is T ?
<Jack22>
oh sorry translate([.2,0,0])
<Jack22>
with show edges all these linear_extrude objects light up as there are so dense
<peeps[zen]>
that's not at all how my method of using linear_extrude works, you have to distort the cross section as shown in the image examples
<Jack22>
does that change the number of slices used and how it looks with show edges ?
<peeps[zen]>
it better if you use $fs and $fa to calculate slices automatically: $fs=2; $fa = 1; linear_extrude(4,twist=3*360) translate([0.2,0,0]) circle(5);
<peeps[zen]>
but yeah it won't likely ever be ideal face economy compared to handcrafted polyhedron
<Jack22>
it was a demonstration - if you use $fn=36 in the linear_extrude it is also better - but nothing changes that the angle between the profile and the extrusion path is very low an you like to get near 90° .. else it will always look strange
<Jack22>
for a coil this is ok but if you have threads the angle is even lower and require more slices
<Jack22>
and for a flat side the base profile is an Evolute so you have many points
<Jack22>
(if you making a simple triangle shaped thread that way)
snaked has quit [Quit: Leaving]
fling has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
KimK has quit [Ping timeout: 240 seconds]
KimK has joined #openscad
<pa>
hi again, i found online (openscad-extra) a module for torus that does module rounded_cylinder(d=1, h=1, r=0.1, center=true, $fn=100){ ... torus(r1=r, r2=(d-r*2)/2, $fn=$fn); }, and i just figured that $fn=$fn doesn't work
<pa>
what's the correct way to forward $fn?
ur5us_ has joined #openscad
<peeps[zen]>
torus is not a builtin module, maybe that definition is not using $fn
<peeps[zen]>
$fn is a dynamically scoped special variable, so you shouldn't need $fn=$fn even
<peeps[zen]>
pa ^
<pa>
peeps[zen]: yea, it's using, and if i do $fn=100, that works fine
<pa>
but $fn=$fn is somehow not picked up
<peeps[zen]>
what version of openscad are you using? i think there was some bugs fixed recently related to variable assignments like that
<pa>
version, quite ancient i think.. 2019.05-3ubuntu5
<peeps[zen]>
remove $fn from the parameters in torus definition
<peeps[zen]>
the point of special variables is that they propagate down the call chain automnatically. defining at each level is kind of counterproductive
<peeps[zen]>
but for what its worth, your code works fine on a recent dev snapshot.
castawayc has quit [Ping timeout: 240 seconds]
castawayc has joined #openscad
rvt_ has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
arebil has joined #openscad
<pa>
peeps[zen]: thanks
<pa>
trying
rvt_ has quit [Quit: rvt_]
juri_ has quit [Ping timeout: 240 seconds]
juri_ has joined #openscad
<peeps[zen]>
pa: its possible to get the propagation to work even in 2019 release if you *don't* define the special variable as module parameters. just pass it in once to the top level instantiation: rounded_cylinder($fn=100);
<pa>
ha i see, thanks for checking!
<peeps[zen]>
pa: and if you really want different defaults for modules depending on whether they are called directly, here is a backwards compatible way that works: https://paste.debian.net/hidden/cbe7163e/
<peeps[zen]>
note the assignments inside the module definition, but not in parameter list: $fn = $fn ? $fn : 50;
* pa
is shamelessly copypasting :D
<peeps[zen]>
no problem, its definitely an odd quirk of argument assignment for older versions
<pa>
i suppose i should build the latest version and use that one.. i was just lazy and trying to finish this model first -.-
<Jack22>
in general you could build those modules different like rotat_extrude has an angle parameter or building the rounded cylinder from 2D instead of union tori and cylinder
<peeps[zen]>
if that part of your design is radially symmetric, then its always easier to work out the 2D radial section, then rotate_extrude the whole thing, as Jack22 alluded to
<peeps[zen]>
its also a lot easier on cpu and ram
<peeps[zen]>
but also i don't know what you mean that you don't get to shave enough
<pa>
right
<pa>
thanks, then i'll remodel
<pa>
right now i was using a brutal half ellipse as 2d section
<Jack22>
pa there are some nice libraries doing that for you but you will learn more if you do it yourself
* pa
has to find the script to generate that now..
<pa>
Jack22: well i was generating the part outside openscad, as i felt it was easier to iterate
<Jack22>
if you can show what the whole part should look we may find a faster solution for you