Provide a simple measurement tool
I've been following issue #3638
https://github.com/openscad/openscad/issues/3638 on openscad at
github. I'm not alone in wanting to know where a particular point is
located or how far apart two points are.
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are. So it should be
possible to insert something like /echo($X,$Y,$Z);/
You would be able to check alignment and distance from those echo's.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple function
could calculate the distance between two such points. Angles could also
be determined with three points.
//
--
Bob
The goal of Computer Science is to build something
that will last at least until we've finished building it.
IIRC this has been done in user code by redefining translate, rotate, etc
to use multmatrix and maintaining an inverse transform in a $variable.
On Fri, 27 Aug 2021 at 21:22, Bob Ewart jinnicky@bobsown.net wrote:
I've been following issue #3638
https://github.com/openscad/openscad/issues/3638 on openscad at
github. I'm not alone in wanting to know where a particular point is
located or how far apart two points are.
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are. So it should be
possible to insert something like echo($X,$Y,$Z);
You would be able to check alignment and distance from those echo's.
Even better would be to have *Point1 = [$X,$Y,$Z]; *A simple function
could calculate the distance between two such points. Angles could also be
determined with three points.
--
Bob
The goal of Computer Science is to build something
that will last at least until we've finished building it.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 8/27/2021 1:22 PM, Bob Ewart wrote:
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are.
You might think so. And it could. But no, it doesn't.
Turning the example into a concrete one:
translate([1,2,3]) {
rotate([4,5,6]) {
translate([7,8,9]) {
cube();
}
}
}
the result of executing the OpenSCAD program is this CSG tree:
multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0, 1]]) {
multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131, 0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0], [0, 0, 0, 1]]) {
multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9], [0, 0, 0, 1]]) {
cube(size = [1, 1, 1], center = false);
}
}
}
It is a later stage, after the execution is done, after the program has
any control, that actually does the geometric work.
As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations and
using $ variables to pass down the accumulated transformation.
Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html
Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple function
could calculate the distance between two such points.
norm(p1-p2) will give you the distance between two points. But: even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do. OpenSCAD modules are black holes;
you cannot get information out of them. Thus, if you have
... some sequence of transforms ... {
A();
}
... some other sequence of transforms ... {
B();
}
although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are, because
there is no way to get the information out of the stack of transforms.
(Except via echo() or text(), but the information is not then available
to the OpenSCAD program.)
Angles could also be determined with three points.
Yes, with some appropriate use of atan2(), but with the same physics
limitations.
On Friday 27 August 2021 22:18:03 Jordan Brown wrote:
On 8/27/2021 1:22 PM, Bob Ewart wrote:
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are.
You might think so. And it could. But no, it doesn't.
Turning the example into a concrete one:
translate([1,2,3]) {
rotate([4,5,6]) {
translate([7,8,9]) {
cube();
}
}
}
the result of executing the OpenSCAD program is this CSG tree:
multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0,
1]]) { multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131,
0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0], [0, 0,
0, 1]]) { multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9], [0, 0,
0, 1]]) { cube(size = [1, 1, 1], center = false);
}
}
}
It is a later stage, after the execution is done, after the program
has any control, that actually does the geometric work.
As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations
and using $ variables to pass down the accumulated transformation.
Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates
-for-objects-td30377.html
Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple
function could calculate the distance between two such points.
norm(p1-p2) will give you the distance between two points. But: even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do. OpenSCAD modules are black holes;
you cannot get information out of them. Thus, if you have
... some sequence of transforms ... {
A();
}
... some other sequence of transforms ... {
B();
}
although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are, because
there is no way to get the information out of the stack of
transforms. (Except via echo() or text(), but the information is not
then available to the OpenSCAD program.)
Angles could also be determined with three points.
Yes, with some appropriate use of atan2(), but with the same physics
limitations.
I know I'd sure like to have the ruler thats located at 0,0,0 in the
display, made portable so its available to lay across a part to find out
how big it is. That would be handier than the turn button on the
outhouse door at a family reunion. I'm also aware thats one very tall
order to do in 3d space. But the need is there.
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
Many people have written rulers. You can probably easily find a few with
google. Also there's one in BOSL2:
include<BOSL2/std.scad>
cylinder(h=10,r=7.5,$fn=25);
ruler(10);
Of course, this ruler is part of your model, not something you can lay down
over your mode as you view it.
To the original poster I'd ask why you want to measure a distance. What
are you planning to do with the result? There may be some simple way to
achieve your end goal that doesn't require measuring.
On Sat, Aug 28, 2021 at 2:32 AM Gene Heskett gheskett@shentel.net wrote:
On Friday 27 August 2021 22:18:03 Jordan Brown wrote:
On 8/27/2021 1:22 PM, Bob Ewart wrote:
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are.
You might think so. And it could. But no, it doesn't.
Turning the example into a concrete one:
translate([1,2,3]) {
rotate([4,5,6]) {
translate([7,8,9]) {
cube();
}
}
}
the result of executing the OpenSCAD program is this CSG tree:
multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0,
1]]) { multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131,
0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0], [0, 0,
0, 1]]) { multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9], [0, 0,
0, 1]]) { cube(size = [1, 1, 1], center = false);
}
}
}
It is a later stage, after the execution is done, after the program
has any control, that actually does the geometric work.
As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations
and using $ variables to pass down the accumulated transformation.
Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates
-for-objects-td30377.html
Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple
function could calculate the distance between two such points.
norm(p1-p2) will give you the distance between two points. But: even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do. OpenSCAD modules are black holes;
you cannot get information out of them. Thus, if you have
... some sequence of transforms ... {
A();
}
... some other sequence of transforms ... {
B();
}
although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are, because
there is no way to get the information out of the stack of
transforms. (Except via echo() or text(), but the information is not
then available to the OpenSCAD program.)
Angles could also be determined with three points.
Yes, with some appropriate use of atan2(), but with the same physics
limitations.
I know I'd sure like to have the ruler thats located at 0,0,0 in the
display, made portable so its available to lay across a part to find out
how big it is. That would be handier than the turn button on the
outhouse door at a family reunion. I'm also aware thats one very tall
order to do in 3d space. But the need is there.
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
I am working on a little sign in two parts, the sign itself and a
support bracket. I want to make sure that the connectors are the same
distance apart and that the are far enough apart to fit over a bracket
holding my monitor.
--
Bob
Truth is stranger than fiction because fiction has to make sense.
On 8/28/21 7:41 AM, Adrian Mariano wrote:
Many people have written rulers. You can probably easily find a few
with google. Also there's one in BOSL2:
include<BOSL2/std.scad>
cylinder(h=10,r=7.5,$fn=25);
ruler(10);
Of course, this ruler is part of your model, not something you can lay
down over your mode as you view it.
To the original poster I'd ask why you want to measure a distance.
What are you planning to do with the result? There may be some simple
way to achieve your end goal that doesn't require measuring.
On Sat, Aug 28, 2021 at 2:32 AM Gene Heskett <gheskett@shentel.net
mailto:gheskett@shentel.net> wrote:
On Friday 27 August 2021 22:18:03 Jordan Brown wrote:
On 8/27/2021 1:22 PM, Bob Ewart wrote:
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are.
You might think so. And it could. But no, it doesn't.
Turning the example into a concrete one:
translate([1,2,3]) {
rotate([4,5,6]) {
translate([7,8,9]) {
cube();
}
}
}
the result of executing the OpenSCAD program is this CSG tree:
multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0,
1]]) { multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131,
0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0],
[0, 0,
0, 1]]) { multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9],
[0, 0,
0, 1]]) { cube(size = [1, 1, 1], center = false);
}
}
}
It is a later stage, after the execution is done, after the program
has any control, that actually does the geometric work.
As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations
and using $ variables to pass down the accumulated transformation.
Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates
<https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates>
-for-objects-td30377.html
Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple
function could calculate the distance between two such points.
norm(p1-p2) will give you the distance between two points.
But: even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do. OpenSCAD modules are black
holes;
you cannot get information out of them. Thus, if you have
... some sequence of transforms ... {
A();
}
... some other sequence of transforms ... {
B();
}
although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are,
because
there is no way to get the information out of the stack of
transforms. (Except via echo() or text(), but the information
is not
then available to the OpenSCAD program.)
Angles could also be determined with three points.
Yes, with some appropriate use of atan2(), but with the same physics
limitations.
I know I'd sure like to have the ruler thats located at 0,0,0 in the
display, made portable so its available to lay across a part to
find out
how big it is. That would be handier than the turn button on the
outhouse door at a family reunion. I'm also aware thats one very tall
order to do in 3d space. But the need is there.
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
<http://geneslinuxbox.net:6309/gene>>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
<mailto:discuss-leave@lists.openscad.org>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Hey, I'd like that, too ....
But,
Executive summary : The point or elegance of OpenSCAD is that you define
exactly where you want each part to go. Why measure it? (Answer: to verify
your code)
Longer version: There have also been requests that you can "nudge" a part
interactively with the mouse. I'd like that, too, but again - that's not
the point of the declarative language and only exact numbers. If you want
to design with drag-n-drop use tinkercad.com or blender etc. Yes, I too,
sometimes am too lazy, or do not have the required
trigonometric/mathematical skill. So I fudge it. I keep entering a new
fudge value until it fits. Of course I never know if it actually fits, it
just looks good on screen (zoom in zoom in ,...). For my average 3D printer
that's often good enough. Hint: Use the animation feature, then you get a
refresh as you type.
Of course, if I do proper design, ie. think about what I want to do,
modularize my OpenSCAD program, use wiki for a "math refresher course" and
so on, then I do not need to measure my output.
Actually I do. I have this seperate visualizer tool for STL files (3D Tool
Free), and there I can get the 3D distance and angle between any two
points, edges, surface and what not. As it is NOT part of OpenSCAD it
also checks for other bugs that might be. Verifying my design before
committing to plastic, so to speak.
Remember that you can write a module that only does a transform - see
"children()". I've also used a module/function combination in a sub
assembly whose only purpose is to return a number (a distance f.ex) that
needs to be repeated in another part of the model. Which brings me back to
the executive summary.
Msquare
On Fri, 27 Aug 2021 at 22:22, Bob Ewart jinnicky@bobsown.net wrote:
I've been following issue #3638
https://github.com/openscad/openscad/issues/3638 on openscad at
github. I'm not alone in wanting to know where a particular point is
located or how far apart two points are.
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are. So it should be
possible to insert something like echo($X,$Y,$Z);
You would be able to check alignment and distance from those echo's.
Even better would be to have *Point1 = [$X,$Y,$Z]; *A simple function
could calculate the distance between two such points. Angles could also be
determined with three points.
--
Bob
The goal of Computer Science is to build something
that will last at least until we've finished building it.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Hi Bob, mine and your last email crossed in time. This was sort of what I
was hinting at. You define the critical distance in a separate module or
file which you use in both part designs.
You create a module with the common parts (the shape of a screw hole?)
and/or a function which returns the critical distance. Then in your two
parts you call that module/function. (modules return a shape or transform a
child shape; functions are just mathematical one-line functions)
You can have both parts in the same file, where you just comment out a line
or other which determines which part to render this time - or - you have a
common file, and in your two shape files you use "include <filename>".
Either way you are certain you have used the same distance.
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.
On Sat, 28 Aug 2021 at 15:14, Bob Ewart jinnicky@bobsown.net wrote:
I am working on a little sign in two parts, the sign itself and a support
bracket. I want to make sure that the connectors are the same distance
apart and that the are far enough apart to fit over a bracket holding my
monitor.
--
Bob
Truth is stranger than fiction because fiction has to make sense.
On 8/28/21 7:41 AM, Adrian Mariano wrote:
Many people have written rulers. You can probably easily find a few with
google. Also there's one in BOSL2:
include<BOSL2/std.scad>
cylinder(h=10,r=7.5,$fn=25);
ruler(10);
Of course, this ruler is part of your model, not something you can lay
down over your mode as you view it.
To the original poster I'd ask why you want to measure a distance. What
are you planning to do with the result? There may be some simple way to
achieve your end goal that doesn't require measuring.
On Sat, Aug 28, 2021 at 2:32 AM Gene Heskett gheskett@shentel.net wrote:
On Friday 27 August 2021 22:18:03 Jordan Brown wrote:
On 8/27/2021 1:22 PM, Bob Ewart wrote:
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are.
You might think so. And it could. But no, it doesn't.
Turning the example into a concrete one:
translate([1,2,3]) {
rotate([4,5,6]) {
translate([7,8,9]) {
cube();
}
}
}
the result of executing the OpenSCAD program is this CSG tree:
multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0,
1]]) { multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131,
0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0], [0, 0,
0, 1]]) { multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9], [0, 0,
0, 1]]) { cube(size = [1, 1, 1], center = false);
}
}
}
It is a later stage, after the execution is done, after the program
has any control, that actually does the geometric work.
As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations
and using $ variables to pass down the accumulated transformation.
Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates
-for-objects-td30377.html
Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.
Even better would be to have /Point1 = [$X,$Y,$Z]; /A simple
function could calculate the distance between two such points.
norm(p1-p2) will give you the distance between two points. But: even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do. OpenSCAD modules are black holes;
you cannot get information out of them. Thus, if you have
... some sequence of transforms ... {
A();
}
... some other sequence of transforms ... {
B();
}
although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are, because
there is no way to get the information out of the stack of
transforms. (Except via echo() or text(), but the information is not
then available to the OpenSCAD program.)
Angles could also be determined with three points.
Yes, with some appropriate use of atan2(), but with the same physics
limitations.
I know I'd sure like to have the ruler thats located at 0,0,0 in the
display, made portable so its available to lay across a part to find out
how big it is. That would be handier than the turn button on the
outhouse door at a family reunion. I'm also aware thats one very tall
order to do in 3d space. But the need is there.
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
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
On Saturday 28 August 2021 09:15:26 Michael Möller wrote:
Hey, I'd like that, too ....
But,
Executive summary : The point or elegance of OpenSCAD is that you
define exactly where you want each part to go. Why measure it?
(Answer: to verify your code)
Longer version: There have also been requests that you can "nudge" a
part interactively with the mouse. I'd like that, too, but again -
that's not the point of the declarative language and only exact
numbers. If you want to design with drag-n-drop use tinkercad.com or
blender etc. Yes, I too, sometimes am too lazy, or do not have the
required
trigonometric/mathematical skill. So I fudge it. I keep entering a new
fudge value until it fits. Of course I never know if it actually fits,
it just looks good on screen (zoom in zoom in ,...). For my average 3D
printer that's often good enough. Hint: Use the animation feature,
then you get a refresh as you type.
I don't think my machine has the horsepower to do that in real time. And
printers seem to have a mind of their own, I have some parts that are
supposed to be 5.98mm tall, and I watched it finish as 5.99mm on the
printers own display, but when mic'd, it is 6.51mm tall. Needs lots of
sanding to fix that...
Of course, if I do proper design, ie. think about what I want to do,
modularize my OpenSCAD program, use wiki for a "math refresher course"
and so on, then I do not need to measure my output.
Actually I do. I have this seperate visualizer tool for STL files (3D
Tool Free), and there I can get the 3D distance and angle between any
two points, edges, surface and what not. As it is NOT part of OpenSCAD
it also checks for other bugs that might be. Verifying my design
before committing to plastic, so to speak.
Remember that you can write a module that only does a transform - see
"children()". I've also used a module/function combination in a sub
assembly whose only purpose is to return a number (a distance f.ex)
that needs to be repeated in another part of the model. Which brings
me back to the executive summary.
Msquare
On Fri, 27 Aug 2021 at 22:22, Bob Ewart jinnicky@bobsown.net wrote:
I've been following issue #3638
https://github.com/openscad/openscad/issues/3638 on openscad at
github. I'm not alone in wanting to know where a particular point
is located or how far apart two points are.
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are. So it should be
possible to insert something like echo($X,$Y,$Z);
You would be able to check alignment and distance from those echo's.
Even better would be to have *Point1 = [$X,$Y,$Z]; *A simple
function could calculate the distance between two such points.
Angles could also be determined with three points.
--
Bob
The goal of Computer Science is to build something
that will last at least until we've finished building it.
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
If your printer is printing 5.98mm parts to be 6.51mm tall it's seriously
out of calibration...
On Sat, Aug 28, 2021, 7:31 AM Gene Heskett gheskett@shentel.net wrote:
On Saturday 28 August 2021 09:15:26 Michael Möller wrote:
Hey, I'd like that, too ....
But,
Executive summary : The point or elegance of OpenSCAD is that you
define exactly where you want each part to go. Why measure it?
(Answer: to verify your code)
Longer version: There have also been requests that you can "nudge" a
part interactively with the mouse. I'd like that, too, but again -
that's not the point of the declarative language and only exact
numbers. If you want to design with drag-n-drop use tinkercad.com or
blender etc. Yes, I too, sometimes am too lazy, or do not have the
required
trigonometric/mathematical skill. So I fudge it. I keep entering a new
fudge value until it fits. Of course I never know if it actually fits,
it just looks good on screen (zoom in zoom in ,...). For my average 3D
printer that's often good enough. Hint: Use the animation feature,
then you get a refresh as you type.
I don't think my machine has the horsepower to do that in real time. And
printers seem to have a mind of their own, I have some parts that are
supposed to be 5.98mm tall, and I watched it finish as 5.99mm on the
printers own display, but when mic'd, it is 6.51mm tall. Needs lots of
sanding to fix that...
Of course, if I do proper design, ie. think about what I want to do,
modularize my OpenSCAD program, use wiki for a "math refresher course"
and so on, then I do not need to measure my output.
Actually I do. I have this seperate visualizer tool for STL files (3D
Tool Free), and there I can get the 3D distance and angle between any
two points, edges, surface and what not. As it is NOT part of OpenSCAD
it also checks for other bugs that might be. Verifying my design
before committing to plastic, so to speak.
Remember that you can write a module that only does a transform - see
"children()". I've also used a module/function combination in a sub
assembly whose only purpose is to return a number (a distance f.ex)
that needs to be repeated in another part of the model. Which brings
me back to the executive summary.
Msquare
On Fri, 27 Aug 2021 at 22:22, Bob Ewart jinnicky@bobsown.net wrote:
I've been following issue #3638
https://github.com/openscad/openscad/issues/3638 on openscad at
github. I'm not alone in wanting to know where a particular point
is located or how far apart two points are.
If you have something like:
translate([a,b,c]) {
rotate([d,e,f]) {
translate([g,h,i]) {
OpenSCAD has to be keeping track of where you are. So it should be
possible to insert something like echo($X,$Y,$Z);
You would be able to check alignment and distance from those echo's.
Even better would be to have *Point1 = [$X,$Y,$Z]; *A simple
function could calculate the distance between two such points.
Angles could also be determined with three points.
--
Bob
The goal of Computer Science is to build something
that will last at least until we've finished building it.
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
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
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
I'm not sure what you mean about a calibration for xy reference. When I
start a print using gcode produced by PrusaSlicer, it does a 49 point z
calibration before anything else. I don't think you're supposed to try to
detect the top of travel. Certainly I've never seen that happen. And I
don't know that it would help much wtih z cal unless you were really far
out. It seems like z cal depends on two things: accurate determination of
the z=0 point and accurate motor operation. I've just always printed on my
Prusa MK3 (now S) using PrusaSlicer with just minimal changes to suit the
model (e.g. turning brim on, adjusting infill, and changing the number of
perimeters) and things just always work and come out accurately sized. I
just printed some screw tests where the thread pitch is around 1.25 mm and
I printed the bolt .2mm smaller than the nut (nominal sizes) and the two
parts engage. I previously printed 1/4-20 bolts that engage with standard
metal hardware. It just works. Note that Prusa has 24/7 tech support by
chat, which I've found pretty helpful at figuring out issues I have had. I
had a situation where the magnets in the base came loose and moved around
and interfered with the motor operation, which messed up the Y
calibration. It would try to travel behind the back of the build plate.
When the machine goes right and left until it hits the sides I think it's
testing belt tension. (I'm not sure how that test works.) I had an issue
early on after I first assembled my machine with insufficient belt
tension.
On Sat, Aug 28, 2021 at 10: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
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.
https://all3dp.com/2/how-to-calibrate-a-3d-printer-simply-explained/
Then do some torture tests
https://all3dp.com/2/best-3d-printer-test-print-3d-models/
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
--
This email has been checked for viruses by AVG.
https://www.avg.com
On Sat, 2021-08-28 at 22:22 -0400, Gene Heskett wrote:z
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.
If you have sensorless homing X and Y, that will work fine. It detects
stall current. But I seriously doubt that your machine came equipped
with sensorless Z homing, for the simple reason that the Z axis will
not give a high enough stall current to stop the bed in time, due to
the flex in the Z axis while driving a screw, with its (for want of a
better word) gear reduction of the screw.
I am quite certain that your endstop for the Z axis is some sort of
sensor, be it mechanical (like a microswitch), electronic (capacitive,
inductive, piezoelectric, etc.).
So for the Z axis, you want the Z homing to NEVER hit the bed. That's
usually a mechanical adjustment, moving the sensor toward/away from the
bed. When the Z axis homes, you will have a gap between the nozzle and
bed, and that's when you adjust your Z offset such that z=0 is when the
nozzle touches the bed.
As for your bad height of prints, that's a result of configuring the
wrong setting for Z axis steps/mm or step distance, depending on how
it's specified.
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
On Saturday 28 August 2021 22:36:09 Father Horton wrote:
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?
cura 4.10.0, I could't make sense out of prusaslicer.
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
Hi Gene,
MK3S(+) has an z-calibration.
Activate factory restart.
You can find procedure here :
https://help.prusa3d.com/en/article/xyz-calibration-mk3-and-mk3s_112351
I had to do it also in the near past by controlling all calibration by
'benchy'.
After that it's much better now.
example 59.8 -> 59.7 to 59.9
Hope you can somehing with it.
Regards,
Harm Jeurink.
PS I want to start new item on here but cannot find anymore how to make
1st message.
Anyone can tell me?
Gene Heskett schreef op 2021-08-29 04:22:
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
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-explained/
Then do some torture tests
https://all3dp.com/2/best-3d-printer-test-print-3d-models/
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
"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
On Sunday 29 August 2021 00:23:08 larry wrote:
On Sat, 2021-08-28 at 22:22 -0400, Gene Heskett wrote:z
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.
If you have sensorless homing X and Y, that will work fine. It detects
stall current. But I seriously doubt that your machine came equipped
with sensorless Z homing, for the simple reason that the Z axis will
not give a high enough stall current to stop the bed in time, due to
the flex in the Z axis while driving a screw, with its (for want of a
better word) gear reduction of the screw.
I am quite certain that your endstop for the Z axis is some sort of
sensor, be it mechanical (like a microswitch), electronic (capacitive,
inductive, piezoelectric, etc.).
So for the Z axis, you want the Z homing to NEVER hit the bed. That's
usually a mechanical adjustment, moving the sensor toward/away from
the bed. When the Z axis homes, you will have a gap between the nozzle
and bed, and that's when you adjust your Z offset such that z=0 is
when the nozzle touches the bed.
the printer has a test pattern for that, and the sensor is 1.065mm above
the bed for a .18mm nozzle gap. Adhesion with petg is generally good,
and a single line is .17 mm thick. No interline gaps in the little patch
at the end when held up to the light with a very strong glass for a
close look. Prusa MK3S lets you trim that in extremely small increments,
1/20th the increments possible with other printers, and does it without
bed leveling wheels.
As for your bad height of prints, that's a result of configuring the
wrong setting for Z axis steps/mm or step distance, depending on how
it's specified.
I expect dimmensional accuracy to generally print at about the target
move plus the nozzle dia, and generally write my code to be .2mm approx
undersized on each edge to come out with a decent press fit where parts
come together. Currently that value seems to be closer to .3 than .2.
for a .2mm layer, indicating over extrusion.
Thanks.
[...]
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
Getting back on track, it took me a while to grasp the idea that the
programming part of Open SCAD is just an elaborate script producing
interface, and when the programming side of it finishes, the scripts
that are produced, are forwarded to the graphics engine to create the
3-D model. The programs and the rendering do not run simultaneously. The
first cannot communicate with the second. So the program is not in the
position to access geometric dimensions that are then produced and
rendered afterwards.
Producing a script that maps the transformation of the graphical objects
before they are calculated through the CSG Tree is in fact running a
parallel universe that involves far more effort for any degree of
complexity for my designs than I believe it is worth. Is this
frustrating? Yes. Is it trivial solving this problem? No.
The penny dropped when I understood the significance of:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL... in the console.
The "CSG Tree" becomes a static list of graphical transformations. I
calmed down substantially when I got it. So while it may seem the
addition of the "ruler" idea would be easy (given all the other amazing
stuff OpenSACD allows us to do), it will take a very crafty programmer
to do it in the first place, and really crafty one to retain
compatibility with the existing processes. So I listen to the experts on
how they "work around" this issue, the quality of their work attests to
the fact they know what they are doing.
My simple approach is to usually draw in any critical extras (eg bolts,
bearings axles etc) my creation has to work with, or position easily
"checkable chunks" of known dimensions, to test my model with and then
remove them when the final model is created. This will not be convenient
for all situations but there other really good ideas that have helped
others.
Rob
Yes I nearly always model all the parts in the assembly to get my printed
parts to interface with them. I can see in the preview if things fit or
clash and never know the actual dimensions. If I need to know a dimension I
examine the STL with Netfabb studio.
On Sun, 29 Aug 2021 at 11:38, Rob Ward rl.ward@bigpond.com wrote:
Getting back on track, it took me a while to grasp the idea that the
programming part of Open SCAD is just an elaborate script producing
interface, and when the programming side of it finishes, the scripts that
are produced, are forwarded to the graphics engine to create the 3-D model.
The programs and the rendering do not run simultaneously. The first cannot
communicate with the second. So the program is not in the position to
access geometric dimensions that are then produced and rendered afterwards.
Producing a script that maps the transformation of the graphical objects
before they are calculated through the CSG Tree is in fact running a
parallel universe that involves far more effort for any degree of
complexity for my designs than I believe it is worth. Is this frustrating?
Yes. Is it trivial solving this problem? No.
The penny dropped when I understood the significance of:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL... in the console.
The "CSG Tree" becomes a static list of graphical transformations. I
calmed down substantially when I got it. So while it may seem the addition
of the "ruler" idea would be easy (given all the other amazing stuff
OpenSACD allows us to do), it will take a very crafty programmer to do it
in the first place, and really crafty one to retain compatibility with the
existing processes. So I listen to the experts on how they "work around"
this issue, the quality of their work attests to the fact they know what
they are doing.
My simple approach is to usually draw in any critical extras (eg bolts,
bearings axles etc) my creation has to work with, or position easily
"checkable chunks" of known dimensions, to test my model with and then
remove them when the final model is created. This will not be convenient
for all situations but there other really good ideas that have helped
others.
Rob
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Gene,
I suggest that you revisit PrusaSlicer. Just print some simple calibration
test object with the default parameters and see if it comes out better
compared to the same print on Prusa---that won't require a deep
understanding of PrusaSlicer. I wonder if you can resolve most, if not all
of your problems by switching to PrusaSlicer and using the profiles that
are specifically built to work with the MK3S.
On Sun, Aug 29, 2021 at 7:10 AM nop head nop.head@gmail.com wrote:
Yes I nearly always model all the parts in the assembly to get my printed
parts to interface with them. I can see in the preview if things fit or
clash and never know the actual dimensions. If I need to know a dimension I
examine the STL with Netfabb studio.
On Sun, 29 Aug 2021 at 11:38, Rob Ward rl.ward@bigpond.com wrote:
Getting back on track, it took me a while to grasp the idea that the
programming part of Open SCAD is just an elaborate script producing
interface, and when the programming side of it finishes, the scripts that
are produced, are forwarded to the graphics engine to create the 3-D model.
The programs and the rendering do not run simultaneously. The first cannot
communicate with the second. So the program is not in the position to
access geometric dimensions that are then produced and rendered afterwards.
Producing a script that maps the transformation of the graphical objects
before they are calculated through the CSG Tree is in fact running a
parallel universe that involves far more effort for any degree of
complexity for my designs than I believe it is worth. Is this frustrating?
Yes. Is it trivial solving this problem? No.
The penny dropped when I understood the significance of:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL... in the console.
The "CSG Tree" becomes a static list of graphical transformations. I
calmed down substantially when I got it. So while it may seem the addition
of the "ruler" idea would be easy (given all the other amazing stuff
OpenSACD allows us to do), it will take a very crafty programmer to do it
in the first place, and really crafty one to retain compatibility with the
existing processes. So I listen to the experts on how they "work around"
this issue, the quality of their work attests to the fact they know what
they are doing.
My simple approach is to usually draw in any critical extras (eg bolts,
bearings axles etc) my creation has to work with, or position easily
"checkable chunks" of known dimensions, to test my model with and then
remove them when the final model is created. This will not be convenient
for all situations but there other really good ideas that have helped
others.
Rob
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
Hi Gene,
In Cura, load the extensions for 'parts for calibration' , go through
each process to set up your printer correctly to work with your slicer
and filament. In reality, you may need to run the tests every time you
change your filament. This stuff is not the same as cast iron/steel
milling machines, is is flimsy aluminium and plastic, generally built
down to a price (but with a high profit margin and a load of hype). If
you keep taking the same steps, you'll end up in the same place. Prusa
has a good support network, or so I'm led to believe, I would hope they
will guide you better on printing problems.
Best wishes,
Ray
On 29/08/2021 09:08, Gene Heskett wrote:
I expect dimmensional accuracy to generally print at about the target
move plus the nozzle dia, and generally write my code to be .2mm approx
undersized on each edge to come out with a decent press fit where parts
come together. Currently that value seems to be closer to .3 than .2.
for a .2mm layer, indicating over extrusion.
Thanks.
[...]
Cheers, Gene Heskett
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and get
information about that object. How possible would it be to click on an
object - probably on a vertex - and get its coordinates? Or to drag a
ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it would
be a feature of the OpenSCAD model viewer. (That also means that it
would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable from
the language.)
I haven't looked at the viewer at all; before I do has somebody already
thought about this aspect?
Hi Michael,
On 28/08/2021 14:25, Michael Möller wrote:
Hi Bob, mine and your last email crossed in time. This was sort of
what I was hinting at. You define the critical distance in a
separate module or file which you use in both part designs.
You create a module with the common parts (the shape of a screw hole?)
and/or a function which returns the critical distance. Then in your
two parts you call that module/function. (modules return a shape or
transform a child shape; functions are just mathematical one-line
functions)
You can have both parts in the same file, where you just comment out a
line or other which determines which part to render this time - or -
you have a common file, and in your two shape files you use "include
<filename>". Either way you are certain you have used the same distance.
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?
So far, for measuring I sort of developed a digital caliper, but it is
easier for me to simply use a cube, and eyeball its fit, but so far I'm
not aiming at more precision than I can achieve by 'whittling' the final
object.
I've put some code below, to show the sort of thing I do. So, given the
two cones, what do you do?
// distance between two random points
$fn=50; // select two points (tips of cones, say)
cylinder(h=10, d1=10, d2=0);
translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
// fit a cube between points
//#cube([55,20,40]);// first try
translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
error.
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xdxd)+(ydyd))
so diagonal = sqrt((dbdb)+(zdzd))
*/
db = sqrt((xdxd)+(ydyd));
diagonal = sqrt((dbdb)+(zdzd));
#translate([0,-10,0])text(text= str("distance between points = ",
diagonal),size=3);
// that's it
Isn't the triangles, and their associated vertices potentially ambiguous once the complexities increase. For example a cylinder is no longer a pure geometric shape but a collection of triangles, the number of which depends on $fn and the concept of a tangent to the digitised cylinder no longer is simple? So as to measure a diameter, Tanger to tangent? If we come back to picking the vertices "by eye" what have we achieved that is better than "fit by inspection" to put roughly what I do?
Cheers, RobW
On 29 August 2021 10:39:16 pm AEST, Jordan Brown openscad@jordan.maileater.net wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and get
information about that object. How possible would it be to click on an
object - probably on a vertex - and get its coordinates? Or to drag a
ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it would
be a feature of the OpenSCAD model viewer. (That also means that it
would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable from
the language.)
I haven't looked at the viewer at all; before I do has somebody already
thought about this aspect?
I suppose, if another set of '3d cross hairs can not be generated and
moved known distances, the whole drawing could be translated so that the
point of interest was at the origin, but that again is eyeballing it,
but zooming in can get it good enough for many applications.
On 29/08/2021 13:39, Jordan Brown wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at
best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to click
on an object - probably on a vertex - and get its coordinates? Or to
drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable
from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I think the proposal was that you have a function that defines the critical
distance. Then you use it when needed. So if you have some complex
computation that determines the location of a screw hole then you put it in
a function and you use it when you need to make the screw hole and also to
make the mating hole in another part. But in your example you know
everything you need to compute the parameters of the cube, so why use trial
and error? Just use the actual points that define the cube. I prefer to
minimize the use of trial and error. I suppose you could embed the
calculation of the cone tips into a function.
On Sun, Aug 29, 2021 at 9:44 AM Ray West raywest@raywest.com wrote:
Hi Michael,
On 28/08/2021 14:25, Michael Möller wrote:
Hi Bob, mine and your last email crossed in time. This was sort of
what I was hinting at. You define the critical distance in a
separate module or file which you use in both part designs.
You create a module with the common parts (the shape of a screw hole?)
and/or a function which returns the critical distance. Then in your
two parts you call that module/function. (modules return a shape or
transform a child shape; functions are just mathematical one-line
functions)
You can have both parts in the same file, where you just comment out a
line or other which determines which part to render this time - or -
you have a common file, and in your two shape files you use "include
<filename>". Either way you are certain you have used the same distance.
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?
So far, for measuring I sort of developed a digital caliper, but it is
easier for me to simply use a cube, and eyeball its fit, but so far I'm
not aiming at more precision than I can achieve by 'whittling' the final
object.
I've put some code below, to show the sort of thing I do. So, given the
two cones, what do you do?
// distance between two random points
$fn=50; // select two points (tips of cones, say)
cylinder(h=10, d1=10, d2=0);
translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
// fit a cube between points
//#cube([55,20,40]);// first try
translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
error.
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xdxd)+(ydyd))
so diagonal = sqrt((dbdb)+(zdzd))
*/
db = sqrt((xdxd)+(ydyd));
diagonal = sqrt((dbdb)+(zdzd));
#translate([0,-10,0])text(text= str("distance between points = ",
diagonal),size=3);
// that's it
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Sunday 29 August 2021 09:50:50 Rob Ward wrote:
Isn't the triangles, and their associated vertices potentially
ambiguous once the complexities increase. For example a cylinder is no
longer a pure geometric shape but a collection of triangles, the
number of which depends on $fn and the concept of a tangent to the
digitised cylinder no longer is simple? So as to measure a diameter,
Tanger to tangent? If we come back to picking the vertices "by eye"
what have we achieved that is better than "fit by inspection" to put
roughly what I do? Cheers, RobW
I generally do the final fit .1mm or even .05mm at a time, adjusting till
it fits well.
One of my more nagging problems lies in forming the splines for this
drive, two parts use exactly the same code to lay out the triangle whose
sides become the working faces of the spline, but one module does a
rotate([0,0,180]) of that to point the splines or outward. The outward
faceing splines print flawlessly, but the inward ones bridge heavily
from tip to tip. Requires some precise work with a box knife, freshly
broken off and sharp. And macular degeneration is becomeing a problem.
I'm playing with temps and retractions, even speeds, but haven't found
the magic twanger yet, halfway thru this spool of PETG.
As for the Z thickness, I could develop a scale foctor but I'd druther
fix the printer. But one has to understand what it is he is fixing by
first determining the cause. eg Does ironing cause any growth. Many more
questions so first is finding the actual src of the problem. When you
are down the the radius of the nezzle, fix your src, but that isn't a
scale, its an offset, ditto for /some/, but not all of the z growth.And
I'm due to take the air junk off and tighten the nozzle again too.
On 29 August 2021 10:39:16 pm AEST, Jordan Brown
Hmm.
Most of the discussions on this topic are program-centric: "How can
I find out where I am?". As discussed, that's difficult and limited
at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to
click on an object - probably on a vertex - and get its
coordinates? Or to drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of
boolean operations, both of which yield vertices that are not
identifiable from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
Take care & Thanks Rod.
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
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.
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.
Thank you very much
--
Bob
The world is coming to an end! Repent and return those library books!
On 8/29/21 8:39 AM, Jordan Brown wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at
best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to click
on an object - probably on a vertex - and get its coordinates? Or to
drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable
from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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.
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
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
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
mailto: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
<mailto:discuss-leave@lists.openscad.org>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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.
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
The nozzle radius has no effect on the object dimensions. What matters is
the volume of plastic flowing through it.
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.
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
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 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.
On 8/29/2021 6:44 AM, Ray West wrote:
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xdxd)+(ydyd))
so diagonal = sqrt((dbdb)+(zdzd))
*/
db = sqrt((xdxd)+(ydyd));
diagonal = sqrt((dbdb)+(zdzd));
Slight simplification: the 3D extension of the Pythagorean Theorem is
straightforwardly x^2 + y^2 + z^2 = d^2, so you can get the distance
with sqrt(x^2 + y^2 + z^2); no need for the intermediate square root.
(Note that you can derive this from your expression; substitute db into
the second expression and then cancel the square against the square root.)
Better simplification: this is the definition of the norm() function,
so all you need is norm([xd,yd,zd]). Note that this also means that if
you have two points p1 and p2, you can get the distance between them
with norm(p1-p2).
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:
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.
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.
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