DG
David Gustavson
Mon, Aug 30, 2021 6:41 PM
Prusaslicer defaults compensate pretty well for dimensions. My small holes are a bit tight, but I’m usually drilling and tapping those so I haven’t tried to optimize them. Generally all I tweak per spool is extruder flow, which I often run at about 95%. I mostly print PETG. Plastic repelling paint on the extruder helps with stringing. I’m using a hardened 0.4 nozzle at 270 deg C.
--
David Gustavson
dbg@SCIzzL.com
On Mon, Aug 30, 2021, at 10:05 AM, Gene Heskett wrote:
On Monday 30 August 2021 11:21:51 nop head wrote:
The nozzle radius has no effect on the object dimensions. What matters
is the volume of plastic flowing through it.
Do you not get a nozzle dia oversize when you are driving the nozzles
center x distance? It is not and never can be a point src when it
is .4mm in diameter. So if I drive it exactly a mm, I will have -.2 at
the start of that mm. and a +.2mm at the end, for a 1.4mm total length.
The slicer is supposed to know that based on the nozzle dia and
compensate but the success of that is highly dependent on the flow,
which if way off, can exceed 2mm in width for the laid down line even if
its only .19mm thick. With this printer, the initial prime on the edge
of the build plate as it starts is nearly 3mm wide using the default
preamble in cura. I have cut that by 50%, but still get that initial
line nearly 2mm wide. And that I am positive, contributes a lot to the
plastic buildup on the nozzle that will pull a pat loose and waste it.
Several times I have lost a print, and had to clean a 50 cent coin
diameter
Using a .19 layer, its now around 6mm up on that 100x100y50z test file.
It did one of the splines at 90% flow this morning, showing 5.99mm up as
it parked, but the part measures 6.72mm tall.
I'll know more when this is done, a bit over an hour from now.
Once thats fixed, then I'll do a temp tower to see if I can stop the
bridging. By then it will be close to time for another spool, and start
all over. Need 10 kg spools and driers to fit them... :-)
Thank you nop head.
On Mon, 30 Aug 2021 at 15:28, Gene Heskett gheskett@shentel.net
wrote:
On Sunday 29 August 2021 03:47:09 Gene Heskett wrote:
On Saturday 28 August 2021 23:21:21 MichaelAtOz wrote:
Calibration is something you need to do, not the printer.
You need to slice & print calibration objects and get your
callipers out.
Then adjust slicer settings, rinse, repeat, until you get
physical objects matching the specification of the calibration
object.
You will need to have profiles for different materials with
settings from a calibration run for that material (usually just
extruder settings being different).
I haven't calibrated for a long time as I use Shapeways, but
Google coughed up these which look reasonable.
Yes, I dl'd several of them, should be helpfull, thank you.
https://all3dp.com/2/how-to-calibrate-a-3d-printer-simply-explai
ned/
Then do some torture tests
https://all3dp.com/2/best-3d-printer-test-print-3d-models/
I am preparing to print 1 or two of what I have dl'd from the links
above and below, but first I thought I'd see what happens to a
priint by fiddling with temps and flows. Flow in particular seems to
be excessive. so as a test, using the printers builtin first layer
calibration. adjusted it for an initial single line thickness of
.19mm, but the solid pad at the end of that pattern was .25 to .27
thick, so I repeated that but at 90% flow from the printers tune
menu, and got a final pad .21mm thick that when microscoped, was
still nicely welded to the adjacent line, but the top surface felt a
lot smoother, so I have it doing one of the spline parts, and its
looking cleaner about half done than previous copies have. Then
I'll do that 100mmX,100mmY,50mmZ thingy. Big enough to separate
scaling errors from nozzle radius errors.
There is little point printing functional objects until you can
print a calibration object accurately.
https://www.thingiverse.com/search?q=calibration
https://www.thingiverse.com/search?q=calibration&type=things
&type=things
From: Father Horton [mailto:fatherhorton@gmail.com]
Sent: Sun, 29 Aug 2021 12:36
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: Provide a simple measurement tool
It almost sounds as if your printer profile is messed up. Are
you using defaults in PrusaSlicer, or did you change something,
or are you using Cura?
On Sat, Aug 28, 2021 at 9:24 PM Gene Heskett
gheskett@shentel.net wrote:
On Saturday 28 August 2021 20:51:21 Gareth Chen wrote:
If your printer is printing 5.98mm parts to be 6.51mm tall
it's seriously out of calibration...
Its a Prusa mk3S, has about a 25 minute calibration using
markers on the bed for xy references. But other that running z
against to top stops and hammering on the top for a while, I
don't see where it calibrates the z range. XY home apparently
senses motor current to detect just touching the left and rear
stops. Not even hard enough to obviously hear it hit. If the
same circuit is used for detecting the top of travel, then its
failing as its dual z motors and useing a default because it
hammers the top of travel for about a full second. I'll ask
prusa monday. And get the m command to change it too.
Thank you..
[...]
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law
respectable. - Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law
respectable. - Louis D. Brandeis
Genes Web page http://geneslinuxbox.net:6309/gene
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Prusaslicer defaults compensate pretty well for dimensions. My small holes are a bit tight, but I’m usually drilling and tapping those so I haven’t tried to optimize them. Generally all I tweak per spool is extruder flow, which I often run at about 95%. I mostly print PETG. Plastic repelling paint on the extruder helps with stringing. I’m using a hardened 0.4 nozzle at 270 deg C.
--
David Gustavson
dbg@SCIzzL.com
On Mon, Aug 30, 2021, at 10:05 AM, Gene Heskett wrote:
> On Monday 30 August 2021 11:21:51 nop head wrote:
>
> > The nozzle radius has no effect on the object dimensions. What matters
> > is the volume of plastic flowing through it.
> >
> Do you not get a nozzle dia oversize when you are driving the nozzles
> center x distance? It is not and never can be a point src when it
> is .4mm in diameter. So if I drive it exactly a mm, I will have -.2 at
> the start of that mm. and a +.2mm at the end, for a 1.4mm total length.
>
> The slicer is supposed to know that based on the nozzle dia and
> compensate but the success of that is highly dependent on the flow,
> which if way off, can exceed 2mm in width for the laid down line even if
> its only .19mm thick. With this printer, the initial prime on the edge
> of the build plate as it starts is nearly 3mm wide using the default
> preamble in cura. I have cut that by 50%, but still get that initial
> line nearly 2mm wide. And that I am positive, contributes a lot to the
> plastic buildup on the nozzle that will pull a pat loose and waste it.
> Several times I have lost a print, and had to clean a 50 cent coin
> diameter
>
> Using a .19 layer, its now around 6mm up on that 100x100y50z test file.
> It did one of the splines at 90% flow this morning, showing 5.99mm up as
> it parked, but the part measures 6.72mm tall.
>
> I'll know more when this is done, a bit over an hour from now.
>
> Once thats fixed, then I'll do a temp tower to see if I can stop the
> bridging. By then it will be close to time for another spool, and start
> all over. Need 10 kg spools and driers to fit them... :-)
>
> Thank you nop head.
>
> > On Mon, 30 Aug 2021 at 15:28, Gene Heskett <gheskett@shentel.net>
> wrote:
> > > On Sunday 29 August 2021 03:47:09 Gene Heskett wrote:
> > > > On Saturday 28 August 2021 23:21:21 MichaelAtOz wrote:
> > > > > Calibration is something you need to do, not the printer.
> > > > >
> > > > > You need to slice & print calibration objects and get your
> > > > > callipers out.
> > > > >
> > > > > Then adjust slicer settings, rinse, repeat, until you get
> > > > > physical objects matching the specification of the calibration
> > > > > object.
> > > > >
> > > > > You will need to have profiles for different materials with
> > > > > settings from a calibration run for that material (usually just
> > > > > extruder settings being different).
> > > > >
> > > > >
> > > > >
> > > > > I haven't calibrated for a long time as I use Shapeways, but
> > > > > Google coughed up these which look reasonable.
> > > >
> > > > Yes, I dl'd several of them, should be helpfull, thank you.
> > > >
> > > > > https://all3dp.com/2/how-to-calibrate-a-3d-printer-simply-explai
> > > > >ned/
> > > > >
> > > > >
> > > > >
> > > > > Then do some torture tests
> > > > >
> > > > >
> > > > >
> > > > > https://all3dp.com/2/best-3d-printer-test-print-3d-models/
> > >
> > > I am preparing to print 1 or two of what I have dl'd from the links
> > > above and below, but first I thought I'd see what happens to a
> > > priint by fiddling with temps and flows. Flow in particular seems to
> > > be excessive. so as a test, using the printers builtin first layer
> > > calibration. adjusted it for an initial single line thickness of
> > > .19mm, but the solid pad at the end of that pattern was .25 to .27
> > > thick, so I repeated that but at 90% flow from the printers tune
> > > menu, and got a final pad .21mm thick that when microscoped, was
> > > still nicely welded to the adjacent line, but the top surface felt a
> > > lot smoother, so I have it doing one of the spline parts, and its
> > > looking cleaner about half done than previous copies have. Then
> > > I'll do that 100mmX,100mmY,50mmZ thingy. Big enough to separate
> > > scaling errors from nozzle radius errors.
> > >
> > > > > There is little point printing functional objects until you can
> > > > > print a calibration object accurately.
> > > > >
> > > > >
> > > > >
> > > > > https://www.thingiverse.com/search?q=calibration
> > > > > <https://www.thingiverse.com/search?q=calibration&type=things>
> > > > > &type=things
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _____
> > > > >
> > > > > From: Father Horton [mailto:fatherhorton@gmail.com]
> > > > > Sent: Sun, 29 Aug 2021 12:36
> > > > > To: OpenSCAD general discussion
> > > > > Subject: [OpenSCAD] Re: Provide a simple measurement tool
> > > > >
> > > > >
> > > > >
> > > > > It almost sounds as if your printer profile is messed up. Are
> > > > > you using defaults in PrusaSlicer, or did you change something,
> > > > > or are you using Cura?
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Aug 28, 2021 at 9:24 PM Gene Heskett
> > > > > <gheskett@shentel.net> wrote:
> > > > >
> > > > > On Saturday 28 August 2021 20:51:21 Gareth Chen wrote:
> > > > > > If your printer is printing 5.98mm parts to be 6.51mm tall
> > > > > > it's seriously out of calibration...
> > > > >
> > > > > Its a Prusa mk3S, has about a 25 minute calibration using
> > > > > markers on the bed for xy references. But other that running z
> > > > > against to top stops and hammering on the top for a while, I
> > > > > don't see where it calibrates the z range. XY home apparently
> > > > > senses motor current to detect just touching the left and rear
> > > > > stops. Not even hard enough to obviously hear it hit. If the
> > > > > same circuit is used for detecting the top of travel, then its
> > > > > failing as its dual z motors and useing a default because it
> > > > > hammers the top of travel for about a full second. I'll ask
> > > > > prusa monday. And get the m command to change it too.
> > > > >
> > > > > Thank you..
> > > > > [...]
> > > > > Cheers, Gene Heskett
> > > > > --
> > > > > "There are four boxes to be used in defense of liberty:
> > > > > soap, ballot, jury, and ammo. Please use in that order."
> > > > > -Ed Howdershelt (Author)
> > > > > If we desire respect for the law, we must first make the law
> > > > > respectable. - Louis D. Brandeis
> > > > > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > > > > _______________________________________________
> > > > > OpenSCAD mailing list
> > > > > To unsubscribe send an email to discuss-leave@lists.openscad.org
> > > >
> > > > Cheers, Gene Heskett
> > >
> > > Cheers, Gene Heskett
> > > --
> > > "There are four boxes to be used in defense of liberty:
> > > soap, ballot, jury, and ammo. Please use in that order."
> > > -Ed Howdershelt (Author)
> > > If we desire respect for the law, we must first make the law
> > > respectable. - Louis D. Brandeis
> > > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > > _______________________________________________
> > > OpenSCAD mailing list
> > > To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
AM
Adrian Mariano
Mon, Aug 30, 2021 7:43 PM
Yes, geometrical calculations can be painful. I know people here are fond
of doing everything from first principles every time, which makes them more
painful than might be necessary. But my quick solution to your squares
problem:
sq1 = rot(a,p=square(10));
sq2 = right(20,p=rot(b,p=square(10)));
stroke(sq1,closed=true);
stroke(sq2,closed=true);
alldist = [for(i=[0:3], j=[0:3]) segment_distance(select(sq1,i,i+1),
select(sq2,j,j+1))];
echo(min(alldist));
But your examples also gets at the question of what allowed definitions of
points are, the "random" points. Your definitions both have to do with
optimization, which means you've gone up a leap in complexity from simple
geometry. Points derived from optimization aren't going to be clickable on
a model. You can't "see" them. The only way you can find these points
is by doing the math.
I can't run your model because it's full of parameters. But I would think
that in that case, at least, it would be possible to define your model in
terms of the width. If you start from the width and build everything from
there then you'll have the right width. That's the kind of thing I meant
when I wondered about the need for access to distance values. The notion
that you need to know the width of your model after the fact so you can fix
your botched model by trial and error to make it the right width....doesn't
appeal to me as a design strategy. But if you really want to pursue
trial-and-error design then having a way to measure does seem very
important. (It's unclear to me if starting from the width just shifts the
measurement problem somewhere else, but it seems like if you have
measurable parameters you should be able to measure them and then design to
the measurements directly.)
On Mon, Aug 30, 2021 at 12:45 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 8/29/2021 5:57 PM, Adrian Mariano wrote:
The question I have is: why do you need to know where a point is? What
are you trying to do that requires this knowledge in a real model? I
wonder if there might be alternative approaches that don't require that
information, or where the model can be structured so that it's easy to know
where the point is. I suspect that at least some of the time, such
alternative approaches may exist.
I think the problem with straight "calculation" schemes is that they can
get very hard, very fast.
Quick, what's the distance between the closest points in these squares?
rotate(a) square(10);
translate([20,20]) rotate(b) square(10);
You're a much stronger math guy than I am, so maybe you can do that off
the top of your head, but it would take me some pretty serious thinking.
And that's a simple case.
In a real project... as I've mentioned, a lot of my work is in scale
models. I was designing an armchair:
[image:
https://cdn.thingiverse.com/assets/ed/00/42/d1/65/featured_preview_WIN_20200407_22_06_02_Pro.jpg]
Here's what generates the sides and arms:
// Sides
for (s=[-1, 1]) {
translate([s*w/2, d, leg_h+seat_h]) {
rotate([90, 0, -90])
clip(v=[0,0,s]) {
pipe_polygon(r=wing_t, fill=true, open=true, [
[3*inch, 0],
[18*inch, 0],
[18*inch, 8.5*inch],
[4*inch, 8.5*inch],
[3.5*inch, 17*inch],
[4*inch, 26*inch],
[-3.8*inch, 28*inch]
]);
}
// Arms
translate([s*0*inch, -20.75*inch, 8.75*inch])
rotate([-86.5,0,4*s])
cylinder(d2=wing_t*1.3, d1=wing_t*2, h=16*inch);
}
}
All of those dimensions are measured by hand off the real object, and the
angles are eyeballed.
Now, what's the width, measured between the outsides of the two arms? I
want to tweak the angles and sizes so that's it's pretty close to correct.
Yes, geometrical calculations can be painful. I know people here are fond
of doing everything from first principles every time, which makes them more
painful than might be necessary. But my quick solution to your squares
problem:
sq1 = rot(a,p=square(10));
sq2 = right(20,p=rot(b,p=square(10)));
stroke(sq1,closed=true);
stroke(sq2,closed=true);
alldist = [for(i=[0:3], j=[0:3]) segment_distance(select(sq1,i,i+1),
select(sq2,j,j+1))];
echo(min(alldist));
But your examples also gets at the question of what allowed definitions of
points are, the "random" points. Your definitions both have to do with
optimization, which means you've gone up a leap in complexity from simple
geometry. Points derived from optimization aren't going to be clickable on
a model. You can't "see" them. The *only* way you can find these points
is by doing the math.
I can't run your model because it's full of parameters. But I would think
that in that case, at least, it would be possible to define your model in
terms of the width. If you start from the width and build everything from
there then you'll have the right width. That's the kind of thing I meant
when I wondered about the need for access to distance values. The notion
that you need to know the width of your model after the fact so you can fix
your botched model by trial and error to make it the right width....doesn't
appeal to me as a design strategy. But if you really want to pursue
trial-and-error design then having a way to measure does seem very
important. (It's unclear to me if starting from the width just shifts the
measurement problem somewhere else, but it seems like if you have
measurable parameters you should be able to measure them and then design to
the measurements directly.)
On Mon, Aug 30, 2021 at 12:45 PM Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 8/29/2021 5:57 PM, Adrian Mariano wrote:
>
> The question I have is: why do you need to know where a point is? What
> are you trying to do that requires this knowledge in a real model? I
> wonder if there might be alternative approaches that don't require that
> information, or where the model can be structured so that it's easy to know
> where the point is. I suspect that at least some of the time, such
> alternative approaches may exist.
>
>
> I think the problem with straight "calculation" schemes is that they can
> get very hard, very fast.
>
> Quick, what's the distance between the closest points in these squares?
>
> rotate(a) square(10);
> translate([20,20]) rotate(b) square(10);
>
> You're a much stronger math guy than I am, so maybe you can do that off
> the top of your head, but it would take me some pretty serious thinking.
> And that's a simple case.
>
> In a real project... as I've mentioned, a lot of my work is in scale
> models. I was designing an armchair:
> [image:
> https://cdn.thingiverse.com/assets/ed/00/42/d1/65/featured_preview_WIN_20200407_22_06_02_Pro.jpg]
>
> Here's what generates the sides and arms:
>
> // Sides
> for (s=[-1, 1]) {
> translate([s*w/2, d, leg_h+seat_h]) {
> rotate([90, 0, -90])
> clip(v=[0,0,s]) {
> pipe_polygon(r=wing_t, fill=true, open=true, [
> [3*inch, 0],
> [18*inch, 0],
> [18*inch, 8.5*inch],
> [4*inch, 8.5*inch],
> [3.5*inch, 17*inch],
> [4*inch, 26*inch],
> [-3.8*inch, 28*inch]
> ]);
> }
> // Arms
> translate([s*0*inch, -20.75*inch, 8.75*inch])
> rotate([-86.5,0,4*s])
> cylinder(d2=wing_t*1.3, d1=wing_t*2, h=16*inch);
> }
> }
>
> All of those dimensions are measured by hand off the real object, and the
> angles are eyeballed.
>
> Now, what's the width, measured between the outsides of the two arms? I
> want to tweak the angles and sizes so that's it's pretty close to correct.
>
AM
Adrian Mariano
Mon, Aug 30, 2021 7:49 PM
Ray,
I agree that if you're trying to manipulate an existing STL then being able
to extract distances could be useful. I have rarely done this. When you
talk of "something made to fit something else" I do that by measuring the
thing in the world and then designing to fit. If you only have STL of the
thing then you can't do that. It's not really clear to me how you could
specify which point in the STL you wanted, though. The concept of "tip of
the cone" is easy to handle if you are writing the model. You say "well, I
have this cone and I need to know where its tip is". If you're talking
about some automatic mechanism for extracting points from geometry that's
hard unless you have a geometry format that is well tagged. (STL doesn't
have cones, just triangles.)
On Mon, Aug 30, 2021 at 6:46 AM Ray West raywest@raywest.com wrote:
Hi Adrian,
My use of random was meant to refer points that i did not know the
position of (without a lot of work), any point on (or off) the object, for
example an imported dxf file, or stl generated elsewhere. In my previous
post I came to the conclusion that you have mentioned in your first
paragraph, below.
wrt why? - If something needs to be made to fit something else. Depending
on the tolerances required, then it becomes an iterative process of making
prototypes, which could be reduced if distances were more accurately known.
The problem seems to be caused (at the higher level) by the fact that
values can not be passed out from a module. I'm thinking a solution would
be to parse the text openscad file in some other program/language, merely
to calculate points. The question then becomes how to define the points of
interest? e.g, in words I can describe it as 'the tip of the cone that is
not at the origin' (and then it needs a better definition, since both tips
are not at the origin) , but can I identify/name that point in openscad?
I tend to work around the limitations to produce what I want, I'm not
adverse to reaming holes to the correct size, for example, but my approach
to these problems is more pragmatic than pure.
Best wishes,
Ray
On 30/08/2021 01:57, Adrian Mariano wrote:
Ray,
I think you need to distinguish two cases. You are talking about "random"
points. What's a "random" point? To me it's the result of a rands()
computation, which means you have the point value in a variable, and hence
it's easy to compute with them. If you have points that are defined in
some complex way by a sequence of geometry operations then there's no way
to gain access to those points. So if, say, you don't understand how to
find the point of a cone (in your example) you'd be left with the trial and
error approach. But anything that OpenSCAD can compute you can compute
yourself, so you can, in principle, write code to compute the location of
points that result from some complex sequence of operations. We had a
discussion a while back about a bisection method for solving equations.
I've written a linear solver. Tools like this can find points defined by
geometry. But it's not something you can extract automatically from your
model. It's something you have to do separately.
The question I have is: why do you need to know where a point is? What
are you trying to do that requires this knowledge in a real model? I
wonder if there might be alternative approaches that don't require that
information, or where the model can be structured so that it's easy to know
where the point is. I suspect that at least some of the time, such
alternative approaches may exist.
On Sun, Aug 29, 2021 at 8:02 PM Ray West raywest@raywest.com wrote:
On 29/08/2021 20:19, Michael Möller wrote:
Ray West asked about my reply :
And the point is - you don't measure the distance created in one
module and then recode it in the other part - you code the distance,
once.
I can't quite envisage this. Any chance you could show a simple example?
Adrian Mariano answered that quite well. That's what the technique
covers. Not two random points.
Hi Michael,
I did not understand what was being said, and I guess understanding
whether the 'you' that you were using was a generic 'you', instructions for
the world at large, or a specific you, a confirmation for Bob. The example
I posed is just to represent two random points. (It would be easy to
calculate the distance from the two lines of code to generate the cones in
this specific case, but that was not what I was looking for). The
eyeball/cube/whatever can be applied anywhere, relatively easily. I was of
the understanding that you were describing a technique that could be
applied between any two points, but by being calculated, instead of
eyeballing. I was hoping that based on the example two points, the code
could be written to generate the distance between them, in a way that could
be applied to any two points, no matter how much is involved in generating
them. I suppose it is different in specifying the distance between two
points, say, compared to having two points and trying to find the distance
between them.
Best wishes,
Ray
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Ray,
I agree that if you're trying to manipulate an existing STL then being able
to extract distances could be useful. I have rarely done this. When you
talk of "something made to fit something else" I do that by measuring the
thing in the world and then designing to fit. If you only have STL of the
thing then you can't do that. It's not really clear to me how you could
specify which point in the STL you wanted, though. The concept of "tip of
the cone" is easy to handle if you are writing the model. You say "well, I
have this cone and I need to know where its tip is". If you're talking
about some automatic mechanism for extracting points from geometry that's
hard unless you have a geometry format that is well tagged. (STL doesn't
have cones, just triangles.)
On Mon, Aug 30, 2021 at 6:46 AM Ray West <raywest@raywest.com> wrote:
> Hi Adrian,
>
> My use of random was meant to refer points that i did not know the
> position of (without a lot of work), any point on (or off) the object, for
> example an imported dxf file, or stl generated elsewhere. In my previous
> post I came to the conclusion that you have mentioned in your first
> paragraph, below.
>
> wrt why? - If something needs to be made to fit something else. Depending
> on the tolerances required, then it becomes an iterative process of making
> prototypes, which could be reduced if distances were more accurately known.
>
> The problem seems to be caused (at the higher level) by the fact that
> values can not be passed out from a module. I'm thinking a solution would
> be to parse the text openscad file in some other program/language, merely
> to calculate points. The question then becomes how to define the points of
> interest? e.g, in words I can describe it as 'the tip of the cone that is
> not at the origin' (and then it needs a better definition, since both tips
> are not at the origin) , but can I identify/name that point in openscad?
>
> I tend to work around the limitations to produce what I want, I'm not
> adverse to reaming holes to the correct size, for example, but my approach
> to these problems is more pragmatic than pure.
>
> Best wishes,
>
> Ray
> On 30/08/2021 01:57, Adrian Mariano wrote:
>
> Ray,
>
> I think you need to distinguish two cases. You are talking about "random"
> points. What's a "random" point? To me it's the result of a rands()
> computation, which means you have the point value in a variable, and hence
> it's easy to compute with them. If you have points that are defined in
> some complex way by a sequence of geometry operations then there's no way
> to gain access to those points. So if, say, you don't understand how to
> find the point of a cone (in your example) you'd be left with the trial and
> error approach. But anything that OpenSCAD can compute you can compute
> yourself, so you can, in principle, write code to compute the location of
> points that result from some complex sequence of operations. We had a
> discussion a while back about a bisection method for solving equations.
> I've written a linear solver. Tools like this can find points defined by
> geometry. But it's not something you can extract automatically from your
> model. It's something you have to do separately.
>
> The question I have is: why do you need to know where a point is? What
> are you trying to do that requires this knowledge in a real model? I
> wonder if there might be alternative approaches that don't require that
> information, or where the model can be structured so that it's easy to know
> where the point is. I suspect that at least some of the time, such
> alternative approaches may exist.
>
> On Sun, Aug 29, 2021 at 8:02 PM Ray West <raywest@raywest.com> wrote:
>
>>
>> On 29/08/2021 20:19, Michael Möller wrote:
>>
>> Ray West asked about my reply :
>>> > And the point is - you don't measure the distance created in one
>>> > module and then recode it in the other part - you code the distance,
>>> once.
>>>
>>> I can't quite envisage this. Any chance you could show a simple example?
>>>
>>>
>>
>> Adrian Mariano answered that quite well. That's what the technique
>> covers. Not two random points.
>>
>>
>> Hi Michael,
>>
>> I did not understand what was being said, and I guess understanding
>> whether the 'you' that you were using was a generic 'you', instructions for
>> the world at large, or a specific you, a confirmation for Bob. The example
>> I posed is just to represent two random points. (It would be easy to
>> calculate the distance from the two lines of code to generate the cones in
>> this specific case, but that was not what I was looking for). The
>> eyeball/cube/whatever can be applied anywhere, relatively easily. I was of
>> the understanding that you were describing a technique that could be
>> applied between any two points, but by being calculated, instead of
>> eyeballing. I was hoping that based on the example two points, the code
>> could be written to generate the distance between them, in a way that could
>> be applied to any two points, no matter how much is involved in generating
>> them. I suppose it is different in specifying the distance between two
>> points, say, compared to having two points and trying to find the distance
>> between them.
>>
>> Best wishes,
>>
>> Ray
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
JB
Jordan Brown
Mon, Aug 30, 2021 8:41 PM
On 8/30/2021 12:43 PM, Adrian Mariano wrote:
But your examples also gets at the question of what allowed
definitions of points are, the "random" points. Your definitions both
have to do with optimization, which means you've gone up a leap in
complexity from simple geometry. Points derived from optimization
aren't going to be clickable on a model. You can't "see" them. The
only way you can find these points is by doing the math.
Well... maybe. Especially if you feel the need to get the exact
answer. But often you don't need the exact answer. You can look at the
model, visually say "those two points are the closest", and put a
virtual caliper across them. If curves are involved you probably won't
pick exactly the right points, but the error will probably also be small.
I can't run your model because it's full of parameters. But I would
think that in that case, at least, it would be possible to define your
model in terms of the width. If you start from the width and build
everything from there then you'll have the right width.
I wasn't expecting you to be able to run it, just wanted to give an
example of complexity in a concrete project.
Yes, I could have, but then there would be some other parameter that
I'd want to check. It's already defined in terms of the width at the
back of the chair; if I wanted to mathematically constrain the front
then that would in turn mean that the parameters of the truncated cones
that form the arms would be something that would either need to be
derived or tweaked to fit.
That's the kind of thing I meant when I wondered about the need for
access to distance values. The notion that you need to know the width
of your model after the fact so you can fix your botched model by
trial and error to make it the right width....doesn't appeal to me as
a design strategy. But if you really want to pursue trial-and-error
design then having a way to measure does seem very important. (It's
unclear to me if starting from the width just shifts the measurement
problem somewhere else, but it seems like if you have measurable
parameters you should be able to measure them and then design to the
measurements directly.)
Indeed, and my engineering side doesn't like it when I tweak models to
fit. But measurements are not precise, and some measurements are
theoretically possible but impractical. I don't have the tools to do
angular measurements (beyond a protractor), and especially not things
like the angle of a truncated cone. Plus, the actual chair's arms
aren't truncated cones. They're a more organic shape (sort of like a
curved truncated cone); a truncated cone seemed like a good-enough
approximation.
On 8/30/2021 12:43 PM, Adrian Mariano wrote:
> But your examples also gets at the question of what allowed
> definitions of points are, the "random" points. Your definitions both
> have to do with optimization, which means you've gone up a leap in
> complexity from simple geometry. Points derived from optimization
> aren't going to be clickable on a model. You can't "see" them. The
> *only* way you can find these points is by doing the math.
Well... maybe. Especially if you feel the need to get the exact
answer. But often you don't need the exact answer. You can look at the
model, visually say "those two points are the closest", and put a
virtual caliper across them. If curves are involved you probably won't
pick exactly the right points, but the error will probably also be small.
> I can't run your model because it's full of parameters. But I would
> think that in that case, at least, it would be possible to define your
> model in terms of the width. If you start from the width and build
> everything from there then you'll have the right width.
I wasn't expecting you to be able to run it, just wanted to give an
example of complexity in a concrete project.
Yes, I could have, but then there would be some *other* parameter that
I'd want to check. It's already defined in terms of the width at the
back of the chair; if I wanted to mathematically constrain the front
then that would in turn mean that the parameters of the truncated cones
that form the arms would be something that would either need to be
derived or tweaked to fit.
> That's the kind of thing I meant when I wondered about the need for
> access to distance values. The notion that you need to know the width
> of your model after the fact so you can fix your botched model by
> trial and error to make it the right width....doesn't appeal to me as
> a design strategy. But if you really want to pursue trial-and-error
> design then having a way to measure does seem very important. (It's
> unclear to me if starting from the width just shifts the measurement
> problem somewhere else, but it seems like if you have measurable
> parameters you should be able to measure them and then design to the
> measurements directly.)
Indeed, and my engineering side doesn't like it when I tweak models to
fit. But measurements are not precise, and some measurements are
theoretically possible but impractical. I don't have the tools to do
angular measurements (beyond a protractor), and especially not things
like the angle of a truncated cone. Plus, the actual chair's arms
aren't truncated cones. They're a more organic shape (sort of like a
curved truncated cone); a truncated cone seemed like a good-enough
approximation.
GH
Gene Heskett
Mon, Aug 30, 2021 9:04 PM
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
Prusaslicer defaults compensate pretty well for dimensions. My small
holes are a bit tight, but I’m usually drilling and tapping those so I
haven’t tried to optimize them. Generally all I tweak per spool is
extruder flow, which I often run at about 95%. I mostly print PETG.
Plastic repelling paint on the extruder helps with stringing. I’m
using a hardened 0.4 nozzle at 270 deg C.
I haven't tried it that hot YET, but the temp tower I just did would seem
to indicate more heat than 240C might be beneficial. At 95% flow, no
bridges were usable, yet it slobbers all over the internal facing
splines. I'm going to try one of them at 250C/85C, wide open fan after
the first layer.
The 100X100Y50Z test was within .2mm everyplace. 50mm tall leg was
50.07mm.
So why is my 5.98mm tall gear, 6.72mm tall when miked. 3/4mm taller than
designed?
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
> Prusaslicer defaults compensate pretty well for dimensions. My small
> holes are a bit tight, but I’m usually drilling and tapping those so I
> haven’t tried to optimize them. Generally all I tweak per spool is
> extruder flow, which I often run at about 95%. I mostly print PETG.
> Plastic repelling paint on the extruder helps with stringing. I’m
> using a hardened 0.4 nozzle at 270 deg C.
I haven't tried it that hot YET, but the temp tower I just did would seem
to indicate more heat than 240C might be beneficial. At 95% flow, no
bridges were usable, yet it slobbers all over the internal facing
splines. I'm going to try one of them at 250C/85C, wide open fan after
the first layer.
The 100X100Y50Z test was within .2mm everyplace. 50mm tall leg was
50.07mm.
So why is my 5.98mm tall gear, 6.72mm tall when miked. 3/4mm taller than
designed?
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
GH
Gene Heskett
Mon, Aug 30, 2021 9:04 PM
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
Prusaslicer defaults compensate pretty well for dimensions. My small
holes are a bit tight, but I’m usually drilling and tapping those so I
haven’t tried to optimize them. Generally all I tweak per spool is
extruder flow, which I often run at about 95%. I mostly print PETG.
Plastic repelling paint on the extruder helps with stringing. I’m
using a hardened 0.4 nozzle at 270 deg C.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
> Prusaslicer defaults compensate pretty well for dimensions. My small
> holes are a bit tight, but I’m usually drilling and tapping those so I
> haven’t tried to optimize them. Generally all I tweak per spool is
> extruder flow, which I often run at about 95%. I mostly print PETG.
> Plastic repelling paint on the extruder helps with stringing. I’m
> using a hardened 0.4 nozzle at 270 deg C.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
DG
David Gustavson
Mon, Aug 30, 2021 9:29 PM
@GeneHeskett The mechanical Z tolerances can't be that far off.
Somehow a wrong value has gotten put in the code relating steps to Z, I suspect.
Look at the G code's Z values!
I had to raise my temperature from about 240 to 270 after switching from a brass nozzle to the hardened one, which conducts heat less well. I also changed to a solid copper heat block, just on superstition.
Do I recall you use Cura on your Prusa? Cura has some plugins I'd like to try, but I've been afraid to use it.
David Gustavson
dbg@SCIzzL.com
On Mon, Aug 30, 2021, at 2:04 PM, Gene Heskett wrote:
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
Prusaslicer defaults compensate pretty well for dimensions. My small
holes are a bit tight, but I’m usually drilling and tapping those so I
haven’t tried to optimize them. Generally all I tweak per spool is
extruder flow, which I often run at about 95%. I mostly print PETG.
Plastic repelling paint on the extruder helps with stringing. I’m
using a hardened 0.4 nozzle at 270 deg C.
I haven't tried it that hot YET, but the temp tower I just did would seem
to indicate more heat than 240C might be beneficial. At 95% flow, no
bridges were usable, yet it slobbers all over the internal facing
splines. I'm going to try one of them at 250C/85C, wide open fan after
the first layer.
The 100X100Y50Z test was within .2mm everyplace. 50mm tall leg was
50.07mm.
So why is my 5.98mm tall gear, 6.72mm tall when miked. 3/4mm taller than
designed?
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
@GeneHeskett The mechanical Z tolerances can't be that far off.
Somehow a wrong value has gotten put in the code relating steps to Z, I suspect.
Look at the G code's Z values!
I had to raise my temperature from about 240 to 270 after switching from a brass nozzle to the hardened one, which conducts heat less well. I also changed to a solid copper heat block, just on superstition.
Do I recall you use Cura on your Prusa? Cura has some plugins I'd like to try, but I've been afraid to use it.
--
David Gustavson
dbg@SCIzzL.com
On Mon, Aug 30, 2021, at 2:04 PM, Gene Heskett wrote:
> On Monday 30 August 2021 14:41:31 David Gustavson wrote:
>
> > Prusaslicer defaults compensate pretty well for dimensions. My small
> > holes are a bit tight, but I’m usually drilling and tapping those so I
> > haven’t tried to optimize them. Generally all I tweak per spool is
> > extruder flow, which I often run at about 95%. I mostly print PETG.
> > Plastic repelling paint on the extruder helps with stringing. I’m
> > using a hardened 0.4 nozzle at 270 deg C.
>
> I haven't tried it that hot YET, but the temp tower I just did would seem
> to indicate more heat than 240C might be beneficial. At 95% flow, no
> bridges were usable, yet it slobbers all over the internal facing
> splines. I'm going to try one of them at 250C/85C, wide open fan after
> the first layer.
>
> The 100X100Y50Z test was within .2mm everyplace. 50mm tall leg was
> 50.07mm.
>
> So why is my 5.98mm tall gear, 6.72mm tall when miked. 3/4mm taller than
> designed?
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
NH
nop head
Mon, Aug 30, 2021 9:31 PM
Do you not get a nozzle dia oversize when you are driving the nozzles
center x distance?
No, the slicer decides what line width it is using and offsets the model
inwards by half of the line width and moves along the resulting path with a
flow rate that produces the correct width line. The slicer I use doesn't
even know what my nozzle diameter is because I don't tell it and I might
even run the same gcode on two machines with different nozzle sizes. The
nozzle size does not affect the flow rate, so does not affect the line
width.
For each nozzle size you can use a range of line widths and layer heights.
On Mon, 30 Aug 2021 at 22:05, Gene Heskett gheskett@shentel.net wrote:
On Monday 30 August 2021 14:41:31 David Gustavson wrote:
Prusaslicer defaults compensate pretty well for dimensions. My small
holes are a bit tight, but I’m usually drilling and tapping those so I
haven’t tried to optimize them. Generally all I tweak per spool is
extruder flow, which I often run at about 95%. I mostly print PETG.
Plastic repelling paint on the extruder helps with stringing. I’m
using a hardened 0.4 nozzle at 270 deg C.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
> Do you not get a nozzle dia oversize when you are driving the nozzles
center x distance?
No, the slicer decides what line width it is using and offsets the model
inwards by half of the line width and moves along the resulting path with a
flow rate that produces the correct width line. The slicer I use doesn't
even know what my nozzle diameter is because I don't tell it and I might
even run the same gcode on two machines with different nozzle sizes. The
nozzle size does not affect the flow rate, so does not affect the line
width.
For each nozzle size you can use a range of line widths and layer heights.
On Mon, 30 Aug 2021 at 22:05, Gene Heskett <gheskett@shentel.net> wrote:
> On Monday 30 August 2021 14:41:31 David Gustavson wrote:
>
> > Prusaslicer defaults compensate pretty well for dimensions. My small
> > holes are a bit tight, but I’m usually drilling and tapping those so I
> > haven’t tried to optimize them. Generally all I tweak per spool is
> > extruder flow, which I often run at about 95%. I mostly print PETG.
> > Plastic repelling paint on the extruder helps with stringing. I’m
> > using a hardened 0.4 nozzle at 270 deg C.
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
BE
Bob Ewart
Mon, Aug 30, 2021 10:22 PM
On 8/30/21 11:47 AM, Jordan Brown wrote:
On 8/29/2021 10:48 AM, Bob Ewart wrote:
I've been a programmer for over 60 years, which is probably why I
like OpenSCAD so much. I'm not sure my hands are steady enough to
place a point on the UI.
More likely is to incorporate it into OpenSCAD proper, so that the
native transformations track the cumulative transformation and make it
available.
That would be sufficient. By echoing various points, I can tell if they
are lined up properly and can manually calculate the distances.
That technique has advantages, but it also has serious weaknesses:
- It can't measure the distance between points on two sibling
objects, because of the "black hole" effect. (You can echo
coordinates out to the log and then externally do math on them,
but bleah.)
- It has no direct way to measure from anything but the origin.
Measuring against simple objects like cubes is easy math.
Measuring the height of a cylinder is easy. Measuring from a
particular point on the perimeter of a circle is not too bad.
Measuring between the two closest points of two circles starts to
get ugly. Measuring anything non-trivial involving boolean
operations gets hard.
I'm not really asking for that. Trying to measure the distance between
two arbitrary solid figures is way beyond what I am asking for.
On 8/30/21 11:47 AM, Jordan Brown wrote:
> On 8/29/2021 10:48 AM, Bob Ewart wrote:
>>
>> I've been a programmer for over 60 years, which is probably why I
>> like OpenSCAD so much. I'm not sure my hands are steady enough to
>> place a point on the UI.
>>
>
> Zoom is your friend.
>
>> I would much rather put an echo in the code to find out where I am.
>> Your discussion
>> <https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html>
>> in the forum on Oct 22, 2020 contained code which I've added to my
>> local library. I will be using it.
>>
>> You should consider putting it somewhere like on github so everyone
>> can find it.
>>
>
> More likely is to incorporate it into OpenSCAD proper, so that the
> native transformations track the cumulative transformation and make it
> available.
>
That would be sufficient. By echoing various points, I can tell if they
are lined up properly and can manually calculate the distances.
> That technique has advantages, but it also has serious weaknesses:
>
> * It can't measure the distance between points on two sibling
> objects, because of the "black hole" effect. (You can echo
> coordinates out to the log and then externally do math on them,
> but bleah.)
> * It has no direct way to measure from anything but the origin.
> Measuring against simple objects like cubes is easy math.
> Measuring the height of a cylinder is easy. Measuring from a
> particular point on the perimeter of a circle is not too bad.
> Measuring between the two closest points of two circles starts to
> get ugly. Measuring anything non-trivial involving boolean
> operations gets *hard*.
>
I'm not really asking for that. Trying to measure the distance between
two arbitrary solid figures is way beyond what I am asking for.
GH
Gene Heskett
Tue, Aug 31, 2021 12:22 AM
On Monday 30 August 2021 17:29:56 David Gustavson wrote:
@GeneHeskett The mechanical Z tolerances can't be that far off.
Somehow a wrong value has gotten put in the code relating steps to Z,
I suspect. Look at the G code's Z values!
I had to raise my temperature from about 240 to 270 after switching
from a brass nozzle to the hardened one, which conducts heat less
well. I also changed to a solid copper heat block, just on
superstition.
Do I recall you use Cura on your Prusa? Cura has some plugins I'd like
to try, but I've been afraid to use it.
Yes, I use cura on my mk3s. And just for grins I raised the nozzle temps
to 250 and 260 for the last 2 builds, 2nd one underway now. And I've
reset cura to a .22 layer after the first one. and that has come pretty
close to wiping out the extra height. So I am getting closer. And the
260C version matches the openscad z size +-.05mm. But it didn't do
anything to stop the stringing between the splines when they are pointed
inward.
There are I hope, other slicers that do bridging better, cura is not so
good at that. But other than those 2 obvious problems, seems to be
working quite well. I have the 2nd of 3 critical parts on the build
plate now, and I am hoping the layer size change will fix all 3. The two
housings are about 1mm from being completely assembled due to the
overthick parts.
We used to say when an engine blew up 70 years ago, that the pan wasn't
big enough for all the parts. ;-) Neither is this but I'm working on
that.
Take care all.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
On Monday 30 August 2021 17:29:56 David Gustavson wrote:
> @GeneHeskett The mechanical Z tolerances can't be that far off.
> Somehow a wrong value has gotten put in the code relating steps to Z,
> I suspect. Look at the G code's Z values!
>
> I had to raise my temperature from about 240 to 270 after switching
> from a brass nozzle to the hardened one, which conducts heat less
> well. I also changed to a solid copper heat block, just on
> superstition.
>
> Do I recall you use Cura on your Prusa? Cura has some plugins I'd like
> to try, but I've been afraid to use it.
Yes, I use cura on my mk3s. And just for grins I raised the nozzle temps
to 250 and 260 for the last 2 builds, 2nd one underway now. And I've
reset cura to a .22 layer after the first one. and that has come pretty
close to wiping out the extra height. So I am getting closer. And the
260C version matches the openscad z size +-.05mm. But it didn't do
anything to stop the stringing between the splines when they are pointed
inward.
There are I hope, other slicers that do bridging better, cura is not so
good at that. But other than those 2 obvious problems, seems to be
working quite well. I have the 2nd of 3 critical parts on the build
plate now, and I am hoping the layer size change will fix all 3. The two
housings are about 1mm from being completely assembled due to the
overthick parts.
We used to say when an engine blew up 70 years ago, that the pan wasn't
big enough for all the parts. ;-) Neither is this but I'm working on
that.
Take care all.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>