KT
Kevin Toppenberg
Sun, May 19, 2019 4:33 PM
I know that OpenScad doesn't formally have units. But if I make an object:
cube([10,10,10]);
and export it to STL and print it on a 3D printer, it comes out 10x10x10 mm.
Normally I would really like this. But lately I have been making some parts
as models for things that I will ultimately machine into metal. And
because I live in the US, everything here seems to be be in stuck in the
Imperial system. So to make an object 1"x1"x1", I do this.
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
And while this is perfectly usable, it would be nice if was a switch that
could change the units from mm to something else. This means that the
on-screen scale would need to change also.
E.g.
$imperial=1
Has this already been considered?
Thanks
Kevin T
I know that OpenScad doesn't formally have units. But if I make an object:
cube([10,10,10]);
and export it to STL and print it on a 3D printer, it comes out 10x10x10 mm.
Normally I would really like this. But lately I have been making some parts
as models for things that I will ultimately machine into metal. And
because I live in the US, everything here seems to be be in stuck in the
Imperial system. So to make an object 1"x1"x1", I do this.
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
And while this is perfectly usable, it would be nice if was a switch that
could change the units from mm to something else. This means that the
on-screen scale would need to change also.
E.g.
$imperial=1
Has this already been considered?
Thanks
Kevin T
TP
Torsten Paul
Sun, May 19, 2019 4:40 PM
On 19.05.19 18:33, Kevin Toppenberg wrote:
E.g.
$imperial=1
Has this already been considered?
I don't think it has.
Also I don't think it even belongs into the language, it might
be more flexible and fitting in the export dialog where it can
depend on the file type how to handle things. For STL that would
need to scale, other file formats have a special list of units
that can be specified.
ciao,
Torsten.
On 19.05.19 18:33, Kevin Toppenberg wrote:
> E.g.
> $imperial=1
>
> Has this already been considered?
I don't think it has.
Also I don't think it even belongs into the language, it might
be more flexible and fitting in the export dialog where it can
depend on the file type how to handle things. For STL that would
need to scale, other file formats have a special list of units
that can be specified.
ciao,
Torsten.
A
adrianv
Sun, May 19, 2019 4:51 PM
I'm not quite sure I understand: are you modeling something in inches that
you need to output to a device that uses millimeters?
Why not just wrap your whole model with a scale() to (optionally?) change
the output scale as required, e.g. scaling up by 25.4 if you need to have a
model in inches processed into mm.
--
Sent from: http://forum.openscad.org/
I'm not quite sure I understand: are you modeling something in inches that
you need to output to a device that uses millimeters?
Why not just wrap your whole model with a scale() to (optionally?) change
the output scale as required, e.g. scaling up by 25.4 if you need to have a
model in inches processed into mm.
--
Sent from: http://forum.openscad.org/
AC
A. Craig West
Sun, May 19, 2019 5:38 PM
I was just going to recommend the same thing, wrap the whole design in a
scale statement
On Sun, 19 May 2019, 12:52 adrianv, avm4@cornell.edu wrote:
I was just going to recommend the same thing, wrap the whole design in a
scale statement
On Sun, 19 May 2019, 12:52 adrianv, <avm4@cornell.edu> wrote:
> I'm not quite sure I understand: are you modeling something in inches that
> you need to output to a device that uses millimeters?
>
> Why not just wrap your whole model with a scale() to (optionally?) change
> the output scale as required, e.g. scaling up by 25.4 if you need to have a
> model in inches processed into mm.
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
CA
Carsten Arnholm
Sun, May 19, 2019 7:12 PM
On 19.05.2019 18:33, Kevin Toppenberg wrote:
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
This would be required only if you needed to use different units for
different values in the modelling process. Otherwise, simply do
toInch=25.4;
scale(toInch) YourModel();
As the last transformation before exporting.
Carsten Arnholm
On 19.05.2019 18:33, Kevin Toppenberg wrote:
> function inch(i) = 25.4*i;
> cube([inch(1), inch(1), inch(1)]);
This would be required only if you needed to use different units for
different values in the modelling process. Otherwise, simply do
toInch=25.4;
scale(toInch) YourModel();
As the last transformation before exporting.
Carsten Arnholm
S
shadowwynd
Mon, May 20, 2019 12:26 AM
I use both imperial and metric units almost daily in my shop, out of
necessity, not choice.
My 3D printer defaults to metric; my CNC machine is a UK-built metric
machine that uses "round" imperial units but is metric internally (both my
slicer and G-Code generators translate around the units).
However, the issue becomes hardware and parts. Metric hardware in the
stores has 1/10 :-) the selection of the imperial parts and usually costs
more. If I buy wood, all the stores sell it as imperial units, some sell
metric-cuts as imperial-rounded. It gets fun when sizes vary store-to-store
and even internally to a store. I buy metric drill bits from Amazon but
have /never/ seen one in a store; "similar" parts I use come in as either
30mm or 1-1/8" (28.6mm) and that 1.4mm makes a big difference when making
holes.
If I buy (3/4)" nominal plywood from one store, it is ~0.71" inches, but is
actually a solid 18mm.
If I buy (3/4)" nominal plywood from a store a block away, it is 0.75"
exactly (19mm).
...not a big deal until you have a part with slots or finger joints.... it
just means that every CNC part has to have a "board thickness" variable.
Most of my code starts like this:
inch = 25.4;
mm=1;
length = 1.5inch; // Some dimension in inches
width = 3.25inch;
button_d = 28*mm; // Some dimension in mm
echo ("Width = ", width/inch);
etc.
I normally measure in metric; but I might start with the dimensions (in
inches) of the parts so that I can easily keep track of what I will need for
a build list. ALWAYS ALWAYS ALWAYS track the units and be explicit what
units are used for a particular part - NASA wasted $125 million learning
this lesson. It isn't uncommon for me to then add a metric "fudge" factor
to an imperial part to handle printing/machining tolerances - it is cleaner
and allows for easier tweaking.
hole_d = (1/8)*inch + 0.5; // Diameter of 1/8" plus a 0.5mm fudge
--
Sent from: http://forum.openscad.org/
I use both imperial and metric units almost daily in my shop, out of
necessity, not choice.
My 3D printer defaults to metric; my CNC machine is a UK-built metric
machine that uses "round" imperial units but is metric internally (both my
slicer and G-Code generators translate around the units).
However, the issue becomes hardware and parts. Metric hardware in the
stores has 1/10 :-) the selection of the imperial parts and usually costs
more. If I buy wood, all the stores sell it as imperial units, some sell
metric-cuts as imperial-rounded. It gets fun when sizes vary store-to-store
and even internally to a store. I buy metric drill bits from Amazon but
have /never/ seen one in a store; "similar" parts I use come in as either
30mm or 1-1/8" (28.6mm) and that 1.4mm makes a big difference when making
holes.
If I buy (3/4)" nominal plywood from one store, it is ~0.71" inches, but is
actually a solid 18mm.
If I buy (3/4)" nominal plywood from a store a block away, it is 0.75"
exactly (19mm).
...not a big deal until you have a part with slots or finger joints.... it
just means that every CNC part has to have a "board thickness" variable.
Most of my code starts like this:
inch = 25.4;
mm=1;
length = 1.5*inch; // Some dimension in inches
width = 3.25*inch;
button_d = 28*mm; // Some dimension in mm
echo ("Width = ", width/inch);
etc.
I normally measure in metric; but I might start with the dimensions (in
inches) of the parts so that I can easily keep track of what I will need for
a build list. ALWAYS ALWAYS ALWAYS track the units and be explicit what
units are used for a particular part - NASA wasted $125 million learning
this lesson. It isn't uncommon for me to then add a metric "fudge" factor
to an imperial part to handle printing/machining tolerances - it is cleaner
and allows for easier tweaking.
hole_d = (1/8)*inch + 0.5; // Diameter of 1/8" plus a 0.5mm fudge
--
Sent from: http://forum.openscad.org/
BL
Bryan Lee
Mon, May 20, 2019 12:47 AM
OHope this is useful to someone.
STLs don't have units. Per wikipedia:
STL files contain no scale information, and the units are arbitrary.[7]
https://en.wikipedia.org/wiki/STL_(file_format)#cite_note-7
Most of the 3d printing programs I've used have an option to convert from
mm to inches or back, and the CAM program I use (Vcarve) has that as an
option when importing STLs.
I really like the suggestion of surrounding the entire model with a scale(){}
** An advantage of doing this is that you can use larger numbers, and thus
get higher counts in your circle segments ($FN, etc). I.e. If you have
something that is 1000 (thou), it will have more segments that something
that's 25.4 (mm). Not sure I explained that well.
I have been modeling a bunch of furniture lately for a video game. For
convenience, I've been measuring in inches...because metric tape measures
are hard to find in my town.
All my designes are being built with the measurements as variables, and when I
define the values, I multiply the inches measurement by a scale value,
"inches_to_mm", which is defined as 2.54.
I have been finding, however, that 1 unit in the game world, is
aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
this was very helpful, and I'm glad I chose to scale everything.
Example code for small table:
inch_to_mm=2.54/100;
top_width=24inch_to_mm;
top_lenght=42inch_to_mm;
top_thickness=2*inch_to_mm;
top=[top_width,top_lenght,top_thickness];
leg_length=(29-top_thickness)inch_to_mm;
leg_width=2inch_to_mm;
module leg(){ // Other models make more use of this module
cube([leg_width,leg_width,leg_length]);
}
translate([0,0,leg_length])
cube(top);
translate([0,0,0])
leg();
translate([top_width-leg_width, 0, 0])
leg();
translate([0,top_lenght-leg_width,0]) /// far end
leg();
translate([top_width-leg_width,top_lenght-leg_width,0])
leg();
Thus Kevin Toppenberg hast written on Sun, May 19, 2019 at 12:33:43PM -0400, and, according to prophecy, it shall come to pass that:
I know that OpenScad doesn't formally have units. But if I make an object:
cube([10,10,10]);
and export it to STL and print it on a 3D printer, it comes out 10x10x10 mm.
Normally I would really like this. But lately I have been making some parts
as models for things that I will ultimately machine into metal. And
because I live in the US, everything here seems to be be in stuck in the
Imperial system. So to make an object 1"x1"x1", I do this.
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
And while this is perfectly usable, it would be nice if was a switch that
could change the units from mm to something else. This means that the
on-screen scale would need to change also.
E.g.
$imperial=1
Has this already been considered?
Thanks
Kevin T
OHope this is useful to someone.
STLs don't have units. Per wikipedia:
STL files contain no scale information, and the units are arbitrary.[7]
https://en.wikipedia.org/wiki/STL_(file_format)#cite_note-7
Most of the 3d printing programs I've used have an option to convert from
mm to inches or back, and the CAM program I use (Vcarve) has that as an
option when importing STLs.
I really like the suggestion of surrounding the entire model with a scale(){}
** An advantage of doing this is that you can use larger numbers, and thus
get higher counts in your circle segments ($FN, etc). I.e. If you have
something that is 1000 (thou), it will have more segments that something
that's 25.4 (mm). Not sure I explained that well.
I have been modeling a bunch of furniture lately for a video game. For
convenience, I've been measuring in inches...because metric tape measures
are hard to find in my town.
All my designes are being built with the measurements as variables, and when I
define the values, I multiply the inches measurement by a scale value,
"inches_to_mm", which is defined as 2.54.
I have been finding, however, that 1 unit in the game world, is
aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
this was very helpful, and I'm glad I chose to scale everything.
Example code for small table:
inch_to_mm=2.54/100;
top_width=24*inch_to_mm;
top_lenght=42*inch_to_mm;
top_thickness=2*inch_to_mm;
top=[top_width,top_lenght,top_thickness];
leg_length=(29-top_thickness)*inch_to_mm;
leg_width=2*inch_to_mm;
module leg(){ // Other models make more use of this module
cube([leg_width,leg_width,leg_length]);
}
translate([0,0,leg_length])
cube(top);
translate([0,0,0])
leg();
translate([top_width-leg_width, 0, 0])
leg();
translate([0,top_lenght-leg_width,0]) /// far end
leg();
translate([top_width-leg_width,top_lenght-leg_width,0])
leg();
Thus Kevin Toppenberg hast written on Sun, May 19, 2019 at 12:33:43PM -0400, and, according to prophecy, it shall come to pass that:
> I know that OpenScad doesn't formally have units. But if I make an object:
>
> cube([10,10,10]);
>
> and export it to STL and print it on a 3D printer, it comes out 10x10x10 mm.
>
> Normally I would really like this. But lately I have been making some parts
> as models for things that I will ultimately machine into metal. And
> because I live in the US, everything here seems to be be in stuck in the
> Imperial system. So to make an object 1"x1"x1", I do this.
>
> function inch(i) = 25.4*i;
> cube([inch(1), inch(1), inch(1)]);
>
> And while this is perfectly usable, it would be nice if was a switch that
> could change the units from mm to something else. This means that the
> on-screen scale would need to change also.
>
> E.g.
> $imperial=1
>
> Has this already been considered?
>
> Thanks
> Kevin T
M
MichaelAtOz
Mon, May 20, 2019 1:17 AM
I have been finding, however, that 1 unit in the game world, is
aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
this was very helpful, and I'm glad I chose to scale everything.
That may be setting you up or trouble.
You 24"/609.6mm top is the stored as 0.6096, and smaller details, say screw
hole for draw handle 1/8"/3.175mm is stored as 0.003175.
OpenSCAD gets a bit flaky down in such small number scales, with floating
point conversion losing accuracy.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
leebc wrote
> I have been finding, however, that 1 unit in the game world, is
> aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
> this was very helpful, and I'm glad I chose to scale everything.
That may be setting you up or trouble.
You 24"/609.6mm top is the stored as 0.6096, and smaller details, say screw
hole for draw handle 1/8"/3.175mm is stored as 0.003175.
OpenSCAD gets a bit flaky down in such small number scales, with floating
point conversion losing accuracy.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
Sent from: http://forum.openscad.org/
WA
William Adams
Mon, May 20, 2019 1:13 PM
I was trying to work through this a while back --- wanted to provide a unit
setting in the customizer and it was rather problematic.
On 19.05.2019 18:33, Kevin Toppenberg wrote:
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
That would probably be better than what I achieved, but the problem was
that in addition to dimensions of the project itself, tooling needed to be
scaled as well.
I'm currently leaving OpenSCAD to the default of millimeters and working on
a front-end for it which will handle units more gracefully.
William
On Sun, May 19, 2019 at 9:17 PM MichaelAtOz oz.at.michael@gmail.com wrote:
I have been finding, however, that 1 unit in the game world, is
aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
this was very helpful, and I'm glad I chose to scale everything.
That may be setting you up or trouble.
You 24"/609.6mm top is the stored as 0.6096, and smaller details, say screw
hole for draw handle 1/8"/3.175mm is stored as 0.003175.
OpenSCAD gets a bit flaky down in such small number scales, with floating
point conversion losing accuracy.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I was trying to work through this a while back --- wanted to provide a unit
setting in the customizer and it was rather problematic.
On 19.05.2019 18:33, Kevin Toppenberg wrote:
> function inch(i) = 25.4*i;
> cube([inch(1), inch(1), inch(1)]);
That would probably be better than what I achieved, but the problem was
that in addition to dimensions of the project itself, tooling needed to be
scaled as well.
I'm currently leaving OpenSCAD to the default of millimeters and working on
a front-end for it which will handle units more gracefully.
William
On Sun, May 19, 2019 at 9:17 PM MichaelAtOz <oz.at.michael@gmail.com> wrote:
> leebc wrote
> > I have been finding, however, that 1 unit in the game world, is
> > aproximately 1 meter, so I change my scale factor to inch_to_mm=2.54/100;
> > this was very helpful, and I'm glad I chose to scale everything.
>
> That may be setting you up or trouble.
>
> You 24"/609.6mm top is the stored as 0.6096, and smaller details, say screw
> hole for draw handle 1/8"/3.175mm is stored as 0.003175.
> OpenSCAD gets a bit flaky down in such small number scales, with floating
> point conversion losing accuracy.
>
>
>
> -----
> Admin - email* me if you need anything, or if I've done something stupid...
>
> * click on my MichaelAtOz label, there is a link to email me.
>
> Unless specifically shown otherwise above, my contribution is in the
> Public Domain; to the extent possible under law, I have waived all
> copyright and related or neighbouring rights to this work. Obviously
> inclusion of works of previous authors is not included in the above.
>
> The TPP is no simple “trade agreement.” Fight it!
> http://www.ourfairdeal.org/ time is running out!
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
AC
A. Craig West
Mon, May 20, 2019 1:37 PM
I find that it's less of an issue than you might expect. At least in my use
case for imperial units, cut lumber and fasteners mostly, the dimensions
are nominal and not actually that close. A 2x2 board, for example, is about
1.5 inches by 1.5 inches, with a fairly high variability. Once you account
for that, it's just as easy to just use the metric dimensions
On Mon, 20 May 2019, 09:14 William Adams, will.adams@frycomm.com wrote:
I was trying to work through this a while back --- wanted to provide a
unit setting in the customizer and it was rather problematic.
On 19.05.2019 18:33, Kevin Toppenberg wrote:
function inch(i) = 25.4*i;
cube([inch(1), inch(1), inch(1)]);
That would probably be better than what I achieved, but the problem was
that in addition to dimensions of the project itself, tooling needed to be
scaled as well.
I'm currently leaving OpenSCAD to the default of millimeters and working
on a front-end for it which will handle units more gracefully.
William
On Sun, May 19, 2019 at 9:17 PM MichaelAtOz oz.at.michael@gmail.com
wrote:
I have been finding, however, that 1 unit in the game world, is
aproximately 1 meter, so I change my scale factor to
this was very helpful, and I'm glad I chose to scale everything.
That may be setting you up or trouble.
You 24"/609.6mm top is the stored as 0.6096, and smaller details, say
screw
hole for draw handle 1/8"/3.175mm is stored as 0.003175.
OpenSCAD gets a bit flaky down in such small number scales, with floating
point conversion losing accuracy.
Admin - email* me if you need anything, or if I've done something
stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I find that it's less of an issue than you might expect. At least in my use
case for imperial units, cut lumber and fasteners mostly, the dimensions
are nominal and not actually that close. A 2x2 board, for example, is about
1.5 inches by 1.5 inches, with a fairly high variability. Once you account
for that, it's just as easy to just use the metric dimensions
On Mon, 20 May 2019, 09:14 William Adams, <will.adams@frycomm.com> wrote:
> I was trying to work through this a while back --- wanted to provide a
> unit setting in the customizer and it was rather problematic.
>
> On 19.05.2019 18:33, Kevin Toppenberg wrote:
> > function inch(i) = 25.4*i;
> > cube([inch(1), inch(1), inch(1)]);
>
> That would probably be better than what I achieved, but the problem was
> that in addition to dimensions of the project itself, tooling needed to be
> scaled as well.
>
> I'm currently leaving OpenSCAD to the default of millimeters and working
> on a front-end for it which will handle units more gracefully.
>
> William
>
>
> On Sun, May 19, 2019 at 9:17 PM MichaelAtOz <oz.at.michael@gmail.com>
> wrote:
>
>> leebc wrote
>> > I have been finding, however, that 1 unit in the game world, is
>> > aproximately 1 meter, so I change my scale factor to
>> inch_to_mm=2.54/100;
>> > this was very helpful, and I'm glad I chose to scale everything.
>>
>> That may be setting you up or trouble.
>>
>> You 24"/609.6mm top is the stored as 0.6096, and smaller details, say
>> screw
>> hole for draw handle 1/8"/3.175mm is stored as 0.003175.
>> OpenSCAD gets a bit flaky down in such small number scales, with floating
>> point conversion losing accuracy.
>>
>>
>>
>> -----
>> Admin - email* me if you need anything, or if I've done something
>> stupid...
>>
>> * click on my MichaelAtOz label, there is a link to email me.
>>
>> Unless specifically shown otherwise above, my contribution is in the
>> Public Domain; to the extent possible under law, I have waived all
>> copyright and related or neighbouring rights to this work. Obviously
>> inclusion of works of previous authors is not included in the above.
>>
>> The TPP is no simple “trade agreement.” Fight it!
>> http://www.ourfairdeal.org/ time is running out!
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>