discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Fwd: Re: start a module from a variabel

JB
Jordan Brown
Sun, Oct 24, 2021 8:57 PM

On 10/24/2021 1:47 PM, Ray West wrote:

On 24/10/2021 15:15, Jordan Brown wrote:

A "use" in the middle of a module might in theory be meaningful, but
is not allowed.

Hi Jordan, thanks for the explanation, it is a bug then 😉  .

Eh, shrug.  It's one of those things that could reasonably be designed
either way.  It was designed the way that it was.  That's not a bug,
it's just the way it is.

For me, the differance between use and include, its that if using an
include I have to comment out 'test code' in the file that I am
including.  No big deal.

The differences that I can think of are:

  • A "used" file doesn't create any geometry (which means that you can
    have test/demo stuff in it that doesn't affect its use as a library)
  • File-level variables set in a "used" file are not visible to the
    caller (which can be good, hiding implementation details, or bad,
    making it so that you can't export constants).
  • With "use" Modules and functions are visible only to the file that
    did the "use".  That is, if A uses B and B uses C, A can't see C's
    functions and modules.  This can help hide implementation details.
  • Top-level variables in "include" files are evaluated once, at
    "include" time, just like the variables in the file that does the
    include.  Top-level variables in "use" files are evaluated on every
    call into the "used" file.  It is controversial whether this is a
    bug or a feature.
  • Because "include" does not participate in the syntax, it can be used
    for things like including the body of a table, without including the
    framing assignment, [ ]s, et cetera.
On 10/24/2021 1:47 PM, Ray West wrote: > On 24/10/2021 15:15, Jordan Brown wrote: >> A "use" in the middle of a module might in theory be meaningful, but >> is not allowed. > > Hi Jordan, thanks for the explanation, it is a bug then 😉  . Eh, shrug.  It's one of those things that could reasonably be designed either way.  It was designed the way that it was.  That's not a bug, it's just the way it is. > For me, the differance between use and include, its that if using an > include I have to comment out 'test code' in the file that I am > including.  No big deal. The differences that I can think of are: * A "used" file doesn't create any geometry (which means that you can have test/demo stuff in it that doesn't affect its use as a library) * File-level variables set in a "used" file are not visible to the caller (which can be good, hiding implementation details, or bad, making it so that you can't export constants). * With "use" Modules and functions are visible only to the file that did the "use".  That is, if A uses B and B uses C, A can't see C's functions and modules.  This can help hide implementation details. * Top-level variables in "include" files are evaluated once, at "include" time, just like the variables in the file that does the include.  Top-level variables in "use" files are evaluated on every call into the "used" file.  It is controversial whether this is a bug or a feature. * Because "include" does not participate in the syntax, it can be used for things like including the body of a table, without including the framing assignment, [ ]s, et cetera.
RW
Ray West
Sun, Oct 24, 2021 10:52 PM

On 24/10/2021 21:57, Jordan Brown wrote:

On 10/24/2021 1:47 PM, Ray West wrote:

On 24/10/2021 15:15, Jordan Brown wrote:

A "use" in the middle of a module might in theory be meaningful, but
is not allowed.

Hi Jordan, thanks for the explanation, it is a bug then 😉  .

Eh, shrug.  It's one of those things that could reasonably be designed
either way.  It was designed the way that it was.  That's not a bug,
it's just the way it is.

For me, the differance between use and include, its that if using an
include I have to comment out 'test code' in the file that I am
including.  No big deal.

The differences that I can think of are:

  • A "used" file doesn't create any geometry (which means that you
    can have test/demo stuff in it that doesn't affect its use as a
    library)
  • File-level variables set in a "used" file are not visible to the
    caller (which can be good, hiding implementation details, or bad,
    making it so that you can't export constants).
  • With "use" Modules and functions are visible only to the file that
    did the "use".  That is, if A uses B and B uses C, A can't see C's
    functions and modules.  This can help hide implementation details.
  • Top-level variables in "include" files are evaluated once, at
    "include" time, just like the variables in the file that does the
    include.  Top-level variables in "use" files are evaluated on
    every call into the "used" file.  It is controversial whether this
    is a bug or a feature.
  • Because "include" does not participate in the syntax, it can be
    used for things like including the body of a table, without
    including the framing assignment, [ ]s, et cetera.

I guess that first there was include - it is pretty common in most
compilers that I know of, and then someone thought, for development,
nice to be able to use just the modules, without having to break apart
the original library. Use is handy for development, since you can hop
between files easily,  well, I know what I'm getting at.  I have a
'feeling' that once it is proven, make it into a library that will be
included makes it the same as copy and paste the whole file, as always.

On 24/10/2021 21:57, Jordan Brown wrote: > On 10/24/2021 1:47 PM, Ray West wrote: >> On 24/10/2021 15:15, Jordan Brown wrote: >>> A "use" in the middle of a module might in theory be meaningful, but >>> is not allowed. >> >> Hi Jordan, thanks for the explanation, it is a bug then 😉  . > > Eh, shrug.  It's one of those things that could reasonably be designed > either way.  It was designed the way that it was.  That's not a bug, > it's just the way it is. > >> For me, the differance between use and include, its that if using an >> include I have to comment out 'test code' in the file that I am >> including.  No big deal. > > The differences that I can think of are: > > * A "used" file doesn't create any geometry (which means that you > can have test/demo stuff in it that doesn't affect its use as a > library) > * File-level variables set in a "used" file are not visible to the > caller (which can be good, hiding implementation details, or bad, > making it so that you can't export constants). > * With "use" Modules and functions are visible only to the file that > did the "use".  That is, if A uses B and B uses C, A can't see C's > functions and modules.  This can help hide implementation details. > * Top-level variables in "include" files are evaluated once, at > "include" time, just like the variables in the file that does the > include.  Top-level variables in "use" files are evaluated on > every call into the "used" file.  It is controversial whether this > is a bug or a feature. > * Because "include" does not participate in the syntax, it can be > used for things like including the body of a table, without > including the framing assignment, [ ]s, et cetera. > I guess that first there was include - it is pretty common in most compilers that I know of, and then someone thought, for development, nice to be able to use just the modules, without having to break apart the original library. Use is handy for development, since you can hop between files easily,  well, _I_ know what I'm getting at.  I have a 'feeling' that once it is proven, make it into a library that will be included makes it the same as copy and paste the whole file, as always.
NH
nop head
Sun, Oct 24, 2021 11:02 PM

When you use a file it is only parsed once, no matter how many times it is
used in a project, and then kept in a cache. Include files are parsed
whenever they are encountered.

On Sun, 24 Oct 2021 at 23:52, Ray West raywest@raywest.com wrote:

On 24/10/2021 21:57, Jordan Brown wrote:

On 10/24/2021 1:47 PM, Ray West wrote:

On 24/10/2021 15:15, Jordan Brown wrote:

A "use" in the middle of a module might in theory be meaningful, but is
not allowed.

Hi Jordan, thanks for the explanation, it is a bug then 😉  .

Eh, shrug.  It's one of those things that could reasonably be designed
either way.  It was designed the way that it was.  That's not a bug, it's
just the way it is.

For me, the differance between use and include, its that if using an
include I have to comment out 'test code' in the file that I am including.
No big deal.

The differences that I can think of are:

- A "used" file doesn't create any geometry (which means that you can
have test/demo stuff in it that doesn't affect its use as a library)
- File-level variables set in a "used" file are not visible to the
caller (which can be good, hiding implementation details, or bad, making it
so that you can't export constants).
- With "use" Modules and functions are visible only to the file that
did the "use".  That is, if A uses B and B uses C, A can't see C's
functions and modules.  This can help hide implementation details.
- Top-level variables in "include" files are evaluated once, at
"include" time, just like the variables in the file that does the include.
Top-level variables in "use" files are evaluated on every call into the
"used" file.  It is controversial whether this is a bug or a feature.
- Because "include" does not participate in the syntax, it can be used
for things like including the body of a table, without including the
framing assignment, [ ]s, et cetera.

I guess that first there was include - it is pretty common in most
compilers that I know of, and then someone thought, for development, nice
to be able to use just the modules, without having to break apart the
original library. Use is handy for development, since you can hop between
files easily,  well, * I* know what I'm getting at.  I have a 'feeling'
that once it is proven, make it into a library that will be included makes
it the same as copy and paste the whole file, as always.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

When you use a file it is only parsed once, no matter how many times it is used in a project, and then kept in a cache. Include files are parsed whenever they are encountered. On Sun, 24 Oct 2021 at 23:52, Ray West <raywest@raywest.com> wrote: > > On 24/10/2021 21:57, Jordan Brown wrote: > > On 10/24/2021 1:47 PM, Ray West wrote: > > On 24/10/2021 15:15, Jordan Brown wrote: > > A "use" in the middle of a module might in theory be meaningful, but is > not allowed. > > > Hi Jordan, thanks for the explanation, it is a bug then 😉 . > > > Eh, shrug. It's one of those things that could reasonably be designed > either way. It was designed the way that it was. That's not a bug, it's > just the way it is. > > For me, the differance between use and include, its that if using an > include I have to comment out 'test code' in the file that I am including. > No big deal. > > > The differences that I can think of are: > > - A "used" file doesn't create any geometry (which means that you can > have test/demo stuff in it that doesn't affect its use as a library) > - File-level variables set in a "used" file are not visible to the > caller (which can be good, hiding implementation details, or bad, making it > so that you can't export constants). > - With "use" Modules and functions are visible only to the file that > did the "use". That is, if A uses B and B uses C, A can't see C's > functions and modules. This can help hide implementation details. > - Top-level variables in "include" files are evaluated once, at > "include" time, just like the variables in the file that does the include. > Top-level variables in "use" files are evaluated on every call into the > "used" file. It is controversial whether this is a bug or a feature. > - Because "include" does not participate in the syntax, it can be used > for things like including the body of a table, without including the > framing assignment, [ ]s, et cetera. > > I guess that first there was include - it is pretty common in most > compilers that I know of, and then someone thought, for development, nice > to be able to use just the modules, without having to break apart the > original library. Use is handy for development, since you can hop between > files easily, well, * I* know what I'm getting at. I have a 'feeling' > that once it is proven, make it into a library that will be included makes > it the same as copy and paste the whole file, as always. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
JB
Jordan Brown
Mon, Oct 25, 2021 4:04 PM

On 10/24/2021 4:02 PM, nop head wrote:

When you use a file it is only parsed once, no matter how many times
it is used in a project, and then kept in a cache. Include files are
parsed whenever they are encountered.

That's a good point, that ties into one of my notes:

   * With "use" Modules and functions are visible only to the file
     that did the "use".  That is, if A uses B and B uses C, A
     can't see C's functions and modules.  This can help hide
     implementation details.

In addition to hiding implementation details, "use" handles
multiple-inclusion problems.

If you have A and B, and A depends on B, and both A and B depend on C,
you can use "use" for all of the inclusions (since A's "use" of C is
visible only to A, and B's "use" of C is visible only to B.  You
cannot use "include" for all of them, because C ends up included
twice; everything in C will be defined twice.

"Use" even appears to handle loops, where A and B depend on each other.

On 10/24/2021 4:02 PM, nop head wrote: > When you use a file it is only parsed once, no matter how many times > it is used in a project, and then kept in a cache. Include files are > parsed whenever they are encountered. That's a good point, that ties into one of my notes: >> * With "use" Modules and functions are visible only to the file >> that did the "use".  That is, if A uses B and B uses C, A >> can't see C's functions and modules.  This can help hide >> implementation details. >> In addition to hiding implementation details, "use" handles multiple-inclusion problems. If you have A and B, and A depends on B, and both A and B depend on C, you can use "use" for all of the inclusions (since A's "use" of C is visible only to A, and B's "use" of C is visible only to B.  You *cannot* use "include" for all of them, because C ends up included twice; everything in C will be defined twice. "Use" even appears to handle loops, where A and B depend on each other.
RW
Ray West
Mon, Oct 25, 2021 8:03 PM

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
  [
    ["height",  height ],
    ["width",   width  ],
    ["length",  length ],
  ];

function stepper_motor_bracket( name ) =
  let ( row = search( [name], constants )[0] )
  row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
  cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not
the way I have been doing this sort of thing. If talking about stepper
motors, then I would have one library file with a module for details
of each type that I was interested in, nema 23, nema17, nema 32,
whatever. The mountiong plate details are not related to the numbers
17, 23/whatever, nor the shaft diameter. so it would be a few number
of modules in one file. (with common variables sd, pd, pl, for shaft
diameter, pilot diameter, pilot length etc.) I'd leave in the test
code (but comment it). Mounting plate dimensions would be derived from
the motor details, wrt fixing hole positions pilot diameter, etc. each
module  would draw the object, and could echo dimensions if needed.
For the plate, it would probably be the motor fixing holes and pilot
and shaft clearance details - as cylinders, to be differenced from a
plate defined by length, width, thickness, and its fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values.
for location, etc. for the specific library motor plate module. Most
of the values would be static, within the stepper motor library module
e.g. motor bolt hole details, so it would be just the size of plate,
its location and  its fixing holes I'd need to set. If every plate for
the different motors i was using had a common thickness, then that
could be defined outside of the modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to
do this for my own use, and next week, I'll be onto something else, so
no need for it to look pretty, so to speak, nobody else needs to use
it. If it were just one or two motor plates, say, then I could have a
file for each plate and use it or include it as needed, but I would
most likely need nothing more than this.  (I'm half inclined to test
out what I'm trying to explain...)

Best wishes,

Ray

On 24/10/2021 01:38, Leonard Martin Struttmann wrote: > Ray,  here's a simple working example: > > File: stepper_motor_bracket.scad > ------------------------------------------------- > height = 10; > width = 100; > length = 100; > > constants = >   [ >     ["height",  height ], >     ["width",   width  ], >     ["length",  length ], >   ]; > > function stepper_motor_bracket( name ) = >   let ( row = search( [name], constants )[0] ) >   row!=[]? constants[row][1] : 0; > > module stepper_motor_bracket() > { >   cube( [ length, width, height ] ); > } > ------------------------------------------------- > > > > > File: Assembly.scad > ------------------------------------------------- > use <stepper_motor_bracket.scad>; > > stepper_height = stepper_motor_bracket( "height" ); > echo( "stepper_height", stepper_height ); > > stepper_motor_bracket(); > ------------------------------------------------- > > Thanks Leonard, looks interesting, but for better or worse, it is not > the way I have been doing this sort of thing. If talking about stepper > motors, then I would have one library file with a module for details > of each type that I was interested in, nema 23, nema17, nema 32, > whatever. The mountiong plate details are not related to the numbers > 17, 23/whatever, nor the shaft diameter. so it would be a few number > of modules in one file. (with common variables sd, pd, pl, for shaft > diameter, pilot diameter, pilot length etc.) I'd leave in the test > code (but comment it). Mounting plate dimensions would be derived from > the motor details, wrt fixing hole positions pilot diameter, etc. each > module  would draw the object, and could echo dimensions if needed. > For the plate, it would probably be the motor fixing holes and pilot > and shaft clearance details - as cylinders, to be differenced from a > plate defined by length, width, thickness, and its fixing holes > > I would include the whole library file within a module in the assembly > file, and within that assembly file module, set the required values. > for location, etc. for the specific library motor plate module. Most > of the values would be static, within the stepper motor library module > e.g. motor bolt hole details, so it would be just the size of plate, > its location and  its fixing holes I'd need to set. If every plate for > the different motors i was using had a common thickness, then that > could be defined outside of the modules in the assembly file. > > I would have to include the library  file in a fresh module for every > motor plate I wanted to use, and chose the module I was interested in, > whereas I believe you had one module per library file. I only have to > do this for my own use, and next week, I'll be onto something else, so > no need for it to look pretty, so to speak, nobody else needs to use > it. If it were just one or two motor plates, say, then I could have a > file for each plate and use it or include it as needed, but I would > most likely need nothing more than this.  (I'm half inclined to test > out what I'm trying to explain...) > > Best wishes, > > Ray
NH
nop head
Mon, Oct 25, 2021 9:01 PM

I describe my stepper motors with lists of properties and then use a single
module to draw them, which I pass the list to. I also pass it to a module
to layout the holes, or to functions to return dimensions, etc. That way I
can represent the motor I am using in a project with a variable
assignment and not mention it by name again. That means by changing a
single assignment the project will use a different motor. See
https://github.com/nophead/NopSCADlib#Stepper_motors.

If I had a different module for each motor I would have to change all the
places in the code that use it because there is no way to call a module
from a variable.

Simlarly for all my vitamins, so a configuration for a parametric 3D
printer looks like this:

X_carriage = MGN9C_carriage;  X_rail_length = 200;
Y_carriage = MGN9C_carriage;  Y_rail_length = 250;
Z_carriage = MGN15C_carriage; Z_rail_length = 260;

Y_build = 170;
X_build = 169.55;

XY_motor = NEMA17M;
Z_motor  = NEMA17M8;

XY_motor_pulley = GT2x20ob_pulley;
X_idler_pulley = GT2x16x7_plain_idler;
Y_idler_pulley = GT2x16_toothed_idler;

extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285,
Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285];

On Mon, 25 Oct 2021 at 21:03, Ray West raywest@raywest.com wrote:

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not the
way I have been doing this sort of thing. If talking about stepper motors,
then I would have one library file with a module for details of each type
that I was interested in, nema 23, nema17, nema 32, whatever. The mountiong
plate details are not related to the numbers 17, 23/whatever, nor the shaft
diameter. so it would be a few number of modules in one file. (with common
variables sd, pd, pl, for shaft diameter, pilot diameter, pilot length
etc.) I'd leave in the test code (but comment it). Mounting plate
dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

I describe my stepper motors with lists of properties and then use a single module to draw them, which I pass the list to. I also pass it to a module to layout the holes, or to functions to return dimensions, etc. That way I can represent the motor I am using in a project with a variable assignment and not mention it by name again. That means by changing a single assignment the project will use a different motor. See https://github.com/nophead/NopSCADlib#Stepper_motors. If I had a different module for each motor I would have to change all the places in the code that use it because there is no way to call a module from a variable. Simlarly for all my vitamins, so a configuration for a parametric 3D printer looks like this: X_carriage = MGN9C_carriage; X_rail_length = 200; Y_carriage = MGN9C_carriage; Y_rail_length = 250; Z_carriage = MGN15C_carriage; Z_rail_length = 260; Y_build = 170; X_build = 169.55; XY_motor = NEMA17M; Z_motor = NEMA17M8; XY_motor_pulley = GT2x20ob_pulley; X_idler_pulley = GT2x16x7_plain_idler; Y_idler_pulley = GT2x16_toothed_idler; extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285, Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285]; On Mon, 25 Oct 2021 at 21:03, Ray West <raywest@raywest.com> wrote: > > On 24/10/2021 01:38, Leonard Martin Struttmann wrote: > > Ray, here's a simple working example: > > File: stepper_motor_bracket.scad > ------------------------------------------------- > height = 10; > width = 100; > length = 100; > > constants = > [ > ["height", height ], > ["width", width ], > ["length", length ], > ]; > > function stepper_motor_bracket( name ) = > let ( row = search( [name], constants )[0] ) > row!=[]? constants[row][1] : 0; > > module stepper_motor_bracket() > { > cube( [ length, width, height ] ); > } > ------------------------------------------------- > > > > > File: Assembly.scad > ------------------------------------------------- > use <stepper_motor_bracket.scad>; > > stepper_height = stepper_motor_bracket( "height" ); > echo( "stepper_height", stepper_height ); > > stepper_motor_bracket(); > ------------------------------------------------- > > Thanks Leonard, looks interesting, but for better or worse, it is not the > way I have been doing this sort of thing. If talking about stepper motors, > then I would have one library file with a module for details of each type > that I was interested in, nema 23, nema17, nema 32, whatever. The mountiong > plate details are not related to the numbers 17, 23/whatever, nor the shaft > diameter. so it would be a few number of modules in one file. (with common > variables sd, pd, pl, for shaft diameter, pilot diameter, pilot length > etc.) I'd leave in the test code (but comment it). Mounting plate > dimensions would be derived from the motor details, wrt fixing hole > positions pilot diameter, etc. each module would draw the object, and > could echo dimensions if needed. For the plate, it would probably be the > motor fixing holes and pilot and shaft clearance details - as cylinders, to > be differenced from a plate defined by length, width, thickness, and its > fixing holes > > I would include the whole library file within a module in the assembly > file, and within that assembly file module, set the required values. for > location, etc. for the specific library motor plate module. Most of the > values would be static, within the stepper motor library module e.g. motor > bolt hole details, so it would be just the size of plate, its location and > its fixing holes I'd need to set. If every plate for the different motors i > was using had a common thickness, then that could be defined outside of the > modules in the assembly file. > > I would have to include the library file in a fresh module for every > motor plate I wanted to use, and chose the module I was interested in, > whereas I believe you had one module per library file. I only have to do > this for my own use, and next week, I'll be onto something else, so no need > for it to look pretty, so to speak, nobody else needs to use it. If it were > just one or two motor plates, say, then I could have a file for each plate > and use it or include it as needed, but I would most likely need nothing > more than this. (I'm half inclined to test out what I'm trying to > explain...) > > Best wishes, > Ray > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
LM
Leonard Martin Struttmann
Mon, Oct 25, 2021 10:54 PM

To be precise, I used a stepper motor in the example only because it was
the first thing that popped into mind.

The example was only meant to illustrate "use<>" and functions to publish
data without polluting the namespace.

On Mon, Oct 25, 2021 at 4:02 PM nop head nop.head@gmail.com wrote:

I describe my stepper motors with lists of properties and then use a
single module to draw them, which I pass the list to. I also pass it to a
module to layout the holes, or to functions to return dimensions, etc. That
way I can represent the motor I am using in a project with a variable
assignment and not mention it by name again. That means by changing a
single assignment the project will use a different motor. See
https://github.com/nophead/NopSCADlib#Stepper_motors.

If I had a different module for each motor I would have to change all the
places in the code that use it because there is no way to call a module
from a variable.

Simlarly for all my vitamins, so a configuration for a parametric 3D
printer looks like this:

X_carriage = MGN9C_carriage;  X_rail_length = 200;
Y_carriage = MGN9C_carriage;  Y_rail_length = 250;
Z_carriage = MGN15C_carriage; Z_rail_length = 260;

Y_build = 170;
X_build = 169.55;

XY_motor = NEMA17M;
Z_motor  = NEMA17M8;

XY_motor_pulley = GT2x20ob_pulley;
X_idler_pulley = GT2x16x7_plain_idler;
Y_idler_pulley = GT2x16_toothed_idler;

extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285,
Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285];

On Mon, 25 Oct 2021 at 21:03, Ray West raywest@raywest.com wrote:

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not the
way I have been doing this sort of thing. If talking about stepper motors,
then I would have one library file with a module for details of each type
that I was interested in, nema 23, nema17, nema 32, whatever. The mountiong
plate details are not related to the numbers 17, 23/whatever, nor the shaft
diameter. so it would be a few number of modules in one file. (with common
variables sd, pd, pl, for shaft diameter, pilot diameter, pilot length
etc.) I'd leave in the test code (but comment it). Mounting plate
dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

To be precise, I used a stepper motor in the example only because it was the first thing that popped into mind. The example was only meant to illustrate "use<>" and functions to publish data without polluting the namespace. On Mon, Oct 25, 2021 at 4:02 PM nop head <nop.head@gmail.com> wrote: > I describe my stepper motors with lists of properties and then use a > single module to draw them, which I pass the list to. I also pass it to a > module to layout the holes, or to functions to return dimensions, etc. That > way I can represent the motor I am using in a project with a variable > assignment and not mention it by name again. That means by changing a > single assignment the project will use a different motor. See > https://github.com/nophead/NopSCADlib#Stepper_motors. > > If I had a different module for each motor I would have to change all the > places in the code that use it because there is no way to call a module > from a variable. > > Simlarly for all my vitamins, so a configuration for a parametric 3D > printer looks like this: > > X_carriage = MGN9C_carriage; X_rail_length = 200; > Y_carriage = MGN9C_carriage; Y_rail_length = 250; > Z_carriage = MGN15C_carriage; Z_rail_length = 260; > > Y_build = 170; > X_build = 169.55; > > XY_motor = NEMA17M; > Z_motor = NEMA17M8; > > XY_motor_pulley = GT2x20ob_pulley; > X_idler_pulley = GT2x16x7_plain_idler; > Y_idler_pulley = GT2x16_toothed_idler; > > extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285, > Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285]; > > > On Mon, 25 Oct 2021 at 21:03, Ray West <raywest@raywest.com> wrote: > >> >> On 24/10/2021 01:38, Leonard Martin Struttmann wrote: >> >> Ray, here's a simple working example: >> >> File: stepper_motor_bracket.scad >> ------------------------------------------------- >> height = 10; >> width = 100; >> length = 100; >> >> constants = >> [ >> ["height", height ], >> ["width", width ], >> ["length", length ], >> ]; >> >> function stepper_motor_bracket( name ) = >> let ( row = search( [name], constants )[0] ) >> row!=[]? constants[row][1] : 0; >> >> module stepper_motor_bracket() >> { >> cube( [ length, width, height ] ); >> } >> ------------------------------------------------- >> >> >> >> >> File: Assembly.scad >> ------------------------------------------------- >> use <stepper_motor_bracket.scad>; >> >> stepper_height = stepper_motor_bracket( "height" ); >> echo( "stepper_height", stepper_height ); >> >> stepper_motor_bracket(); >> ------------------------------------------------- >> >> Thanks Leonard, looks interesting, but for better or worse, it is not the >> way I have been doing this sort of thing. If talking about stepper motors, >> then I would have one library file with a module for details of each type >> that I was interested in, nema 23, nema17, nema 32, whatever. The mountiong >> plate details are not related to the numbers 17, 23/whatever, nor the shaft >> diameter. so it would be a few number of modules in one file. (with common >> variables sd, pd, pl, for shaft diameter, pilot diameter, pilot length >> etc.) I'd leave in the test code (but comment it). Mounting plate >> dimensions would be derived from the motor details, wrt fixing hole >> positions pilot diameter, etc. each module would draw the object, and >> could echo dimensions if needed. For the plate, it would probably be the >> motor fixing holes and pilot and shaft clearance details - as cylinders, to >> be differenced from a plate defined by length, width, thickness, and its >> fixing holes >> >> I would include the whole library file within a module in the assembly >> file, and within that assembly file module, set the required values. for >> location, etc. for the specific library motor plate module. Most of the >> values would be static, within the stepper motor library module e.g. motor >> bolt hole details, so it would be just the size of plate, its location and >> its fixing holes I'd need to set. If every plate for the different motors i >> was using had a common thickness, then that could be defined outside of the >> modules in the assembly file. >> >> I would have to include the library file in a fresh module for every >> motor plate I wanted to use, and chose the module I was interested in, >> whereas I believe you had one module per library file. I only have to do >> this for my own use, and next week, I'll be onto something else, so no need >> for it to look pretty, so to speak, nobody else needs to use it. If it were >> just one or two motor plates, say, then I could have a file for each plate >> and use it or include it as needed, but I would most likely need nothing >> more than this. (I'm half inclined to test out what I'm trying to >> explain...) >> >> Best wishes, >> Ray >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
NH
nop head
Mon, Oct 25, 2021 11:04 PM

All the functions and modules that are related to stepper motors are in one
file called vitamins/stepper_motor.scad which I use everywhere I need to
draw a stepper motor, or place its screws, etc, or wrap a bracket around
it. The actual lists that describe motors are in a separate file called
vitamins/stepper_motors.scad that I include where I need to specify an
actual type of motor. The only namespace pollution is those names: NEMA8,
NEMA17, etc. I don't class them as pollution because they are needed to be
able to configure a machine to use one of them.

On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann <
lenstruttmann@gmail.com> wrote:

To be precise, I used a stepper motor in the example only because it was
the first thing that popped into mind.

The example was only meant to illustrate "use<>" and functions to publish
data without polluting the namespace.

On Mon, Oct 25, 2021 at 4:02 PM nop head nop.head@gmail.com wrote:

I describe my stepper motors with lists of properties and then use a
single module to draw them, which I pass the list to. I also pass it to a
module to layout the holes, or to functions to return dimensions, etc. That
way I can represent the motor I am using in a project with a variable
assignment and not mention it by name again. That means by changing a
single assignment the project will use a different motor. See
https://github.com/nophead/NopSCADlib#Stepper_motors.

If I had a different module for each motor I would have to change all the
places in the code that use it because there is no way to call a module
from a variable.

Simlarly for all my vitamins, so a configuration for a parametric 3D
printer looks like this:

X_carriage = MGN9C_carriage;  X_rail_length = 200;
Y_carriage = MGN9C_carriage;  Y_rail_length = 250;
Z_carriage = MGN15C_carriage; Z_rail_length = 260;

Y_build = 170;
X_build = 169.55;

XY_motor = NEMA17M;
Z_motor  = NEMA17M8;

XY_motor_pulley = GT2x20ob_pulley;
X_idler_pulley = GT2x16x7_plain_idler;
Y_idler_pulley = GT2x16_toothed_idler;

extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285,
Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285];

On Mon, 25 Oct 2021 at 21:03, Ray West raywest@raywest.com wrote:

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not
the way I have been doing this sort of thing. If talking about stepper
motors, then I would have one library file with a module for details of
each type that I was interested in, nema 23, nema17, nema 32, whatever. The
mountiong plate details are not related to the numbers 17, 23/whatever, nor
the shaft diameter. so it would be a few number of modules in one file.
(with common variables sd, pd, pl, for shaft diameter, pilot diameter,
pilot length etc.) I'd leave in the test code (but comment it). Mounting
plate dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

All the functions and modules that are related to stepper motors are in one file called vitamins/stepper_motor.scad which I use everywhere I need to draw a stepper motor, or place its screws, etc, or wrap a bracket around it. The actual lists that describe motors are in a separate file called vitamins/stepper_motors.scad that I include where I need to specify an actual type of motor. The only namespace pollution is those names: NEMA8, NEMA17, etc. I don't class them as pollution because they are needed to be able to configure a machine to use one of them. On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann < lenstruttmann@gmail.com> wrote: > To be precise, I used a stepper motor in the example only because it was > the first thing that popped into mind. > > The example was only meant to illustrate "use<>" and functions to publish > data without polluting the namespace. > > > > On Mon, Oct 25, 2021 at 4:02 PM nop head <nop.head@gmail.com> wrote: > >> I describe my stepper motors with lists of properties and then use a >> single module to draw them, which I pass the list to. I also pass it to a >> module to layout the holes, or to functions to return dimensions, etc. That >> way I can represent the motor I am using in a project with a variable >> assignment and not mention it by name again. That means by changing a >> single assignment the project will use a different motor. See >> https://github.com/nophead/NopSCADlib#Stepper_motors. >> >> If I had a different module for each motor I would have to change all the >> places in the code that use it because there is no way to call a module >> from a variable. >> >> Simlarly for all my vitamins, so a configuration for a parametric 3D >> printer looks like this: >> >> X_carriage = MGN9C_carriage; X_rail_length = 200; >> Y_carriage = MGN9C_carriage; Y_rail_length = 250; >> Z_carriage = MGN15C_carriage; Z_rail_length = 260; >> >> Y_build = 170; >> X_build = 169.55; >> >> XY_motor = NEMA17M; >> Z_motor = NEMA17M8; >> >> XY_motor_pulley = GT2x20ob_pulley; >> X_idler_pulley = GT2x16x7_plain_idler; >> Y_idler_pulley = GT2x16_toothed_idler; >> >> extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285, >> Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285]; >> >> >> On Mon, 25 Oct 2021 at 21:03, Ray West <raywest@raywest.com> wrote: >> >>> >>> On 24/10/2021 01:38, Leonard Martin Struttmann wrote: >>> >>> Ray, here's a simple working example: >>> >>> File: stepper_motor_bracket.scad >>> ------------------------------------------------- >>> height = 10; >>> width = 100; >>> length = 100; >>> >>> constants = >>> [ >>> ["height", height ], >>> ["width", width ], >>> ["length", length ], >>> ]; >>> >>> function stepper_motor_bracket( name ) = >>> let ( row = search( [name], constants )[0] ) >>> row!=[]? constants[row][1] : 0; >>> >>> module stepper_motor_bracket() >>> { >>> cube( [ length, width, height ] ); >>> } >>> ------------------------------------------------- >>> >>> >>> >>> >>> File: Assembly.scad >>> ------------------------------------------------- >>> use <stepper_motor_bracket.scad>; >>> >>> stepper_height = stepper_motor_bracket( "height" ); >>> echo( "stepper_height", stepper_height ); >>> >>> stepper_motor_bracket(); >>> ------------------------------------------------- >>> >>> Thanks Leonard, looks interesting, but for better or worse, it is not >>> the way I have been doing this sort of thing. If talking about stepper >>> motors, then I would have one library file with a module for details of >>> each type that I was interested in, nema 23, nema17, nema 32, whatever. The >>> mountiong plate details are not related to the numbers 17, 23/whatever, nor >>> the shaft diameter. so it would be a few number of modules in one file. >>> (with common variables sd, pd, pl, for shaft diameter, pilot diameter, >>> pilot length etc.) I'd leave in the test code (but comment it). Mounting >>> plate dimensions would be derived from the motor details, wrt fixing hole >>> positions pilot diameter, etc. each module would draw the object, and >>> could echo dimensions if needed. For the plate, it would probably be the >>> motor fixing holes and pilot and shaft clearance details - as cylinders, to >>> be differenced from a plate defined by length, width, thickness, and its >>> fixing holes >>> >>> I would include the whole library file within a module in the assembly >>> file, and within that assembly file module, set the required values. for >>> location, etc. for the specific library motor plate module. Most of the >>> values would be static, within the stepper motor library module e.g. motor >>> bolt hole details, so it would be just the size of plate, its location and >>> its fixing holes I'd need to set. If every plate for the different motors i >>> was using had a common thickness, then that could be defined outside of the >>> modules in the assembly file. >>> >>> I would have to include the library file in a fresh module for every >>> motor plate I wanted to use, and chose the module I was interested in, >>> whereas I believe you had one module per library file. I only have to do >>> this for my own use, and next week, I'll be onto something else, so no need >>> for it to look pretty, so to speak, nobody else needs to use it. If it were >>> just one or two motor plates, say, then I could have a file for each plate >>> and use it or include it as needed, but I would most likely need nothing >>> more than this. (I'm half inclined to test out what I'm trying to >>> explain...) >>> >>> Best wishes, >>> Ray >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
PC
Patrick Callahan
Tue, Oct 26, 2021 2:22 AM

nop head's approach seems to separate data and code in a very nice way.
I'm about to try to expand his 7_segment display example to a second type
of 7 segment display with different size features.

On Mon, Oct 25, 2021 at 7:05 PM nop head nop.head@gmail.com wrote:

All the functions and modules that are related to stepper motors are in
one file called vitamins/stepper_motor.scad which I use everywhere I need
to draw a stepper motor, or place its screws, etc, or wrap a bracket around
it. The actual lists that describe motors are in a separate file called
vitamins/stepper_motors.scad that I include where I need to specify an
actual type of motor. The only namespace pollution is those names: NEMA8,
NEMA17, etc. I don't class them as pollution because they are needed to be
able to configure a machine to use one of them.

On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann <
lenstruttmann@gmail.com> wrote:

To be precise, I used a stepper motor in the example only because it was
the first thing that popped into mind.

The example was only meant to illustrate "use<>" and functions to publish
data without polluting the namespace.

On Mon, Oct 25, 2021 at 4:02 PM nop head nop.head@gmail.com wrote:

I describe my stepper motors with lists of properties and then use a
single module to draw them, which I pass the list to. I also pass it to a
module to layout the holes, or to functions to return dimensions, etc. That
way I can represent the motor I am using in a project with a variable
assignment and not mention it by name again. That means by changing a
single assignment the project will use a different motor. See
https://github.com/nophead/NopSCADlib#Stepper_motors.

If I had a different module for each motor I would have to change all
the places in the code that use it because there is no way to call a module
from a variable.

Simlarly for all my vitamins, so a configuration for a parametric 3D
printer looks like this:

X_carriage = MGN9C_carriage;  X_rail_length = 200;
Y_carriage = MGN9C_carriage;  Y_rail_length = 250;
Z_carriage = MGN15C_carriage; Z_rail_length = 260;

Y_build = 170;
X_build = 169.55;

XY_motor = NEMA17M;
Z_motor  = NEMA17M8;

XY_motor_pulley = GT2x20ob_pulley;
X_idler_pulley = GT2x16x7_plain_idler;
Y_idler_pulley = GT2x16_toothed_idler;

extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285,
Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285];

On Mon, 25 Oct 2021 at 21:03, Ray West raywest@raywest.com wrote:

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not
the way I have been doing this sort of thing. If talking about stepper
motors, then I would have one library file with a module for details of
each type that I was interested in, nema 23, nema17, nema 32, whatever. The
mountiong plate details are not related to the numbers 17, 23/whatever, nor
the shaft diameter. so it would be a few number of modules in one file.
(with common variables sd, pd, pl, for shaft diameter, pilot diameter,
pilot length etc.) I'd leave in the test code (but comment it). Mounting
plate dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

nop head's approach seems to separate data and code in a very nice way. I'm about to try to expand his 7_segment display example to a second type of 7 segment display with different size features. On Mon, Oct 25, 2021 at 7:05 PM nop head <nop.head@gmail.com> wrote: > All the functions and modules that are related to stepper motors are in > one file called vitamins/stepper_motor.scad which I use everywhere I need > to draw a stepper motor, or place its screws, etc, or wrap a bracket around > it. The actual lists that describe motors are in a separate file called > vitamins/stepper_motors.scad that I include where I need to specify an > actual type of motor. The only namespace pollution is those names: NEMA8, > NEMA17, etc. I don't class them as pollution because they are needed to be > able to configure a machine to use one of them. > > > On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann < > lenstruttmann@gmail.com> wrote: > >> To be precise, I used a stepper motor in the example only because it was >> the first thing that popped into mind. >> >> The example was only meant to illustrate "use<>" and functions to publish >> data without polluting the namespace. >> >> >> >> On Mon, Oct 25, 2021 at 4:02 PM nop head <nop.head@gmail.com> wrote: >> >>> I describe my stepper motors with lists of properties and then use a >>> single module to draw them, which I pass the list to. I also pass it to a >>> module to layout the holes, or to functions to return dimensions, etc. That >>> way I can represent the motor I am using in a project with a variable >>> assignment and not mention it by name again. That means by changing a >>> single assignment the project will use a different motor. See >>> https://github.com/nophead/NopSCADlib#Stepper_motors. >>> >>> If I had a different module for each motor I would have to change all >>> the places in the code that use it because there is no way to call a module >>> from a variable. >>> >>> Simlarly for all my vitamins, so a configuration for a parametric 3D >>> printer looks like this: >>> >>> X_carriage = MGN9C_carriage; X_rail_length = 200; >>> Y_carriage = MGN9C_carriage; Y_rail_length = 250; >>> Z_carriage = MGN15C_carriage; Z_rail_length = 260; >>> >>> Y_build = 170; >>> X_build = 169.55; >>> >>> XY_motor = NEMA17M; >>> Z_motor = NEMA17M8; >>> >>> XY_motor_pulley = GT2x20ob_pulley; >>> X_idler_pulley = GT2x16x7_plain_idler; >>> Y_idler_pulley = GT2x16_toothed_idler; >>> >>> extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285, >>> Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285]; >>> >>> >>> On Mon, 25 Oct 2021 at 21:03, Ray West <raywest@raywest.com> wrote: >>> >>>> >>>> On 24/10/2021 01:38, Leonard Martin Struttmann wrote: >>>> >>>> Ray, here's a simple working example: >>>> >>>> File: stepper_motor_bracket.scad >>>> ------------------------------------------------- >>>> height = 10; >>>> width = 100; >>>> length = 100; >>>> >>>> constants = >>>> [ >>>> ["height", height ], >>>> ["width", width ], >>>> ["length", length ], >>>> ]; >>>> >>>> function stepper_motor_bracket( name ) = >>>> let ( row = search( [name], constants )[0] ) >>>> row!=[]? constants[row][1] : 0; >>>> >>>> module stepper_motor_bracket() >>>> { >>>> cube( [ length, width, height ] ); >>>> } >>>> ------------------------------------------------- >>>> >>>> >>>> >>>> >>>> File: Assembly.scad >>>> ------------------------------------------------- >>>> use <stepper_motor_bracket.scad>; >>>> >>>> stepper_height = stepper_motor_bracket( "height" ); >>>> echo( "stepper_height", stepper_height ); >>>> >>>> stepper_motor_bracket(); >>>> ------------------------------------------------- >>>> >>>> Thanks Leonard, looks interesting, but for better or worse, it is not >>>> the way I have been doing this sort of thing. If talking about stepper >>>> motors, then I would have one library file with a module for details of >>>> each type that I was interested in, nema 23, nema17, nema 32, whatever. The >>>> mountiong plate details are not related to the numbers 17, 23/whatever, nor >>>> the shaft diameter. so it would be a few number of modules in one file. >>>> (with common variables sd, pd, pl, for shaft diameter, pilot diameter, >>>> pilot length etc.) I'd leave in the test code (but comment it). Mounting >>>> plate dimensions would be derived from the motor details, wrt fixing hole >>>> positions pilot diameter, etc. each module would draw the object, and >>>> could echo dimensions if needed. For the plate, it would probably be the >>>> motor fixing holes and pilot and shaft clearance details - as cylinders, to >>>> be differenced from a plate defined by length, width, thickness, and its >>>> fixing holes >>>> >>>> I would include the whole library file within a module in the assembly >>>> file, and within that assembly file module, set the required values. for >>>> location, etc. for the specific library motor plate module. Most of the >>>> values would be static, within the stepper motor library module e.g. motor >>>> bolt hole details, so it would be just the size of plate, its location and >>>> its fixing holes I'd need to set. If every plate for the different motors i >>>> was using had a common thickness, then that could be defined outside of the >>>> modules in the assembly file. >>>> >>>> I would have to include the library file in a fresh module for every >>>> motor plate I wanted to use, and chose the module I was interested in, >>>> whereas I believe you had one module per library file. I only have to do >>>> this for my own use, and next week, I'll be onto something else, so no need >>>> for it to look pretty, so to speak, nobody else needs to use it. If it were >>>> just one or two motor plates, say, then I could have a file for each plate >>>> and use it or include it as needed, but I would most likely need nothing >>>> more than this. (I'm half inclined to test out what I'm trying to >>>> explain...) >>>> >>>> Best wishes, >>>> Ray >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
PC
Patrick Callahan
Tue, Oct 26, 2021 2:59 AM

Resizing the 7 segment displays was easy.  I added a new vector for
CL02511A (a fictitious part) with the adjusted data and added the new
vector to 7_segments in vitamins/7_segments.scad.

WT5011BSR = ["WT5011BSR", [12.7, 19, 8.2], [7.2, 12.7, 1.2, 10], [5, 2], [
inch(0.1), inch(0.6), 0.4]];
CL02511A = ["CL02511A", [5., 8, 4], [3.5, 6.2, 0.8, 5], [0, 0], [inch(0.1),
inch(0.), 0.25]];

7_segments = [ WT5011BSR, CL02511A];

use <7_segment.scad>

But the displays are still single-digit units, and I don't think they make
a CL02511A.  The real part is CL02531A, as shown below.

I need to do more coding to make multi-digit units without space between
the digits and adjust the pin placement so pins can be distributed
correctly over the combined unit rather than placed on each digit.  This
might just be a move of the pin code from module 7_segment_digit to module
7_segment_digits, with an additional piece of data indicating where to put
the first pin.

-Pat

[image: image.png]

On Mon, Oct 25, 2021 at 10:22 PM Patrick Callahan pat.callahan1@gmail.com
wrote:

nop head's approach seems to separate data and code in a very nice way.
I'm about to try to expand his 7_segment display example to a second type
of 7 segment display with different size features.

On Mon, Oct 25, 2021 at 7:05 PM nop head nop.head@gmail.com wrote:

All the functions and modules that are related to stepper motors are in
one file called vitamins/stepper_motor.scad which I use everywhere I need
to draw a stepper motor, or place its screws, etc, or wrap a bracket around
it. The actual lists that describe motors are in a separate file called
vitamins/stepper_motors.scad that I include where I need to specify an
actual type of motor. The only namespace pollution is those names: NEMA8,
NEMA17, etc. I don't class them as pollution because they are needed to be
able to configure a machine to use one of them.

On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann <
lenstruttmann@gmail.com> wrote:

To be precise, I used a stepper motor in the example only because it was
the first thing that popped into mind.

The example was only meant to illustrate "use<>" and functions to
publish data without polluting the namespace.

On Mon, Oct 25, 2021 at 4:02 PM nop head nop.head@gmail.com wrote:

I describe my stepper motors with lists of properties and then use a
single module to draw them, which I pass the list to. I also pass it to a
module to layout the holes, or to functions to return dimensions, etc. That
way I can represent the motor I am using in a project with a variable
assignment and not mention it by name again. That means by changing a
single assignment the project will use a different motor. See
https://github.com/nophead/NopSCADlib#Stepper_motors.

If I had a different module for each motor I would have to change all
the places in the code that use it because there is no way to call a module
from a variable.

Simlarly for all my vitamins, so a configuration for a parametric 3D
printer looks like this:

X_carriage = MGN9C_carriage;  X_rail_length = 200;
Y_carriage = MGN9C_carriage;  Y_rail_length = 250;
Z_carriage = MGN15C_carriage; Z_rail_length = 260;

Y_build = 170;
X_build = 169.55;

XY_motor = NEMA17M;
Z_motor  = NEMA17M8;

XY_motor_pulley = GT2x20ob_pulley;
X_idler_pulley = GT2x16x7_plain_idler;
Y_idler_pulley = GT2x16_toothed_idler;

extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285,
Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285];

On Mon, 25 Oct 2021 at 21:03, Ray West raywest@raywest.com wrote:

On 24/10/2021 01:38, Leonard Martin Struttmann wrote:

Ray,  here's a simple working example:

File: stepper_motor_bracket.scad

height = 10;
width = 100;
length = 100;

constants =
[
["height",  height ],
["width",  width  ],
["length",  length ],
];

function stepper_motor_bracket( name ) =
let ( row = search( [name], constants )[0] )
row!=[]? constants[row][1] : 0;

module stepper_motor_bracket()
{
cube( [ length, width, height ] );
}

File: Assembly.scad

use <stepper_motor_bracket.scad>;

stepper_height = stepper_motor_bracket( "height" );
echo( "stepper_height", stepper_height );

stepper_motor_bracket();

Thanks Leonard, looks interesting, but for better or worse, it is not
the way I have been doing this sort of thing. If talking about stepper
motors, then I would have one library file with a module for details of
each type that I was interested in, nema 23, nema17, nema 32, whatever. The
mountiong plate details are not related to the numbers 17, 23/whatever, nor
the shaft diameter. so it would be a few number of modules in one file.
(with common variables sd, pd, pl, for shaft diameter, pilot diameter,
pilot length etc.) I'd leave in the test code (but comment it). Mounting
plate dimensions would be derived from the motor details, wrt fixing hole
positions pilot diameter, etc. each module  would draw the object, and
could echo dimensions if needed. For the plate, it would probably be the
motor fixing holes and pilot and shaft clearance details - as cylinders, to
be differenced from a plate defined by length, width, thickness, and its
fixing holes

I would include the whole library file within a module in the assembly
file, and within that assembly file module, set the required values. for
location, etc. for the specific library motor plate module. Most of the
values would be static, within the stepper motor library module e.g. motor
bolt hole details, so it would be just the size of plate, its location and
its fixing holes I'd need to set. If every plate for the different motors i
was using had a common thickness, then that could be defined outside of the
modules in the assembly file.

I would have to include the library  file in a fresh module for every
motor plate I wanted to use, and chose the module I was interested in,
whereas I believe you had one module per library file. I only have to do
this for my own use, and next week, I'll be onto something else, so no need
for it to look pretty, so to speak, nobody else needs to use it. If it were
just one or two motor plates, say, then I could have a file for each plate
and use it or include it as needed, but I would most likely need nothing
more than this.  (I'm half inclined to test out what I'm trying to
explain...)

Best wishes,
Ray


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Resizing the 7 segment displays was easy. I added a new vector for CL02511A (a fictitious part) with the adjusted data and added the new vector to 7_segments in vitamins/7_segments.scad. WT5011BSR = ["WT5011BSR", [12.7, 19, 8.2], [7.2, 12.7, 1.2, 10], [5, 2], [ inch(0.1), inch(0.6), 0.4]]; CL02511A = ["CL02511A", [5., 8, 4], [3.5, 6.2, 0.8, 5], [0, 0], [inch(0.1), inch(0.), 0.25]]; 7_segments = [ WT5011BSR, CL02511A]; use <7_segment.scad> But the displays are still single-digit units, and I don't think they make a CL02511A. The real part is CL02531A, as shown below. I need to do more coding to make multi-digit units without space between the digits and adjust the pin placement so pins can be distributed correctly over the combined unit rather than placed on each digit. This might just be a move of the pin code from module 7_segment_digit to module 7_segment_digits, with an additional piece of data indicating where to put the first pin. -Pat [image: image.png] On Mon, Oct 25, 2021 at 10:22 PM Patrick Callahan <pat.callahan1@gmail.com> wrote: > nop head's approach seems to separate data and code in a very nice way. > I'm about to try to expand his 7_segment display example to a second type > of 7 segment display with different size features. > > On Mon, Oct 25, 2021 at 7:05 PM nop head <nop.head@gmail.com> wrote: > >> All the functions and modules that are related to stepper motors are in >> one file called vitamins/stepper_motor.scad which I use everywhere I need >> to draw a stepper motor, or place its screws, etc, or wrap a bracket around >> it. The actual lists that describe motors are in a separate file called >> vitamins/stepper_motors.scad that I include where I need to specify an >> actual type of motor. The only namespace pollution is those names: NEMA8, >> NEMA17, etc. I don't class them as pollution because they are needed to be >> able to configure a machine to use one of them. >> >> >> On Mon, 25 Oct 2021 at 23:55, Leonard Martin Struttmann < >> lenstruttmann@gmail.com> wrote: >> >>> To be precise, I used a stepper motor in the example only because it was >>> the first thing that popped into mind. >>> >>> The example was only meant to illustrate "use<>" and functions to >>> publish data without polluting the namespace. >>> >>> >>> >>> On Mon, Oct 25, 2021 at 4:02 PM nop head <nop.head@gmail.com> wrote: >>> >>>> I describe my stepper motors with lists of properties and then use a >>>> single module to draw them, which I pass the list to. I also pass it to a >>>> module to layout the holes, or to functions to return dimensions, etc. That >>>> way I can represent the motor I am using in a project with a variable >>>> assignment and not mention it by name again. That means by changing a >>>> single assignment the project will use a different motor. See >>>> https://github.com/nophead/NopSCADlib#Stepper_motors. >>>> >>>> If I had a different module for each motor I would have to change all >>>> the places in the code that use it because there is no way to call a module >>>> from a variable. >>>> >>>> Simlarly for all my vitamins, so a configuration for a parametric 3D >>>> printer looks like this: >>>> >>>> X_carriage = MGN9C_carriage; X_rail_length = 200; >>>> Y_carriage = MGN9C_carriage; Y_rail_length = 250; >>>> Z_carriage = MGN15C_carriage; Z_rail_length = 260; >>>> >>>> Y_build = 170; >>>> X_build = 169.55; >>>> >>>> XY_motor = NEMA17M; >>>> Z_motor = NEMA17M8; >>>> >>>> XY_motor_pulley = GT2x20ob_pulley; >>>> X_idler_pulley = GT2x16x7_plain_idler; >>>> Y_idler_pulley = GT2x16_toothed_idler; >>>> >>>> extruders = [ Flexstruder_JHeadMk5_175, Flexstruder_JHeadMk5_285, >>>> Flexstruder_E3Dv6_175, Flexstruder_E3Dv6_285]; >>>> >>>> >>>> On Mon, 25 Oct 2021 at 21:03, Ray West <raywest@raywest.com> wrote: >>>> >>>>> >>>>> On 24/10/2021 01:38, Leonard Martin Struttmann wrote: >>>>> >>>>> Ray, here's a simple working example: >>>>> >>>>> File: stepper_motor_bracket.scad >>>>> ------------------------------------------------- >>>>> height = 10; >>>>> width = 100; >>>>> length = 100; >>>>> >>>>> constants = >>>>> [ >>>>> ["height", height ], >>>>> ["width", width ], >>>>> ["length", length ], >>>>> ]; >>>>> >>>>> function stepper_motor_bracket( name ) = >>>>> let ( row = search( [name], constants )[0] ) >>>>> row!=[]? constants[row][1] : 0; >>>>> >>>>> module stepper_motor_bracket() >>>>> { >>>>> cube( [ length, width, height ] ); >>>>> } >>>>> ------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> File: Assembly.scad >>>>> ------------------------------------------------- >>>>> use <stepper_motor_bracket.scad>; >>>>> >>>>> stepper_height = stepper_motor_bracket( "height" ); >>>>> echo( "stepper_height", stepper_height ); >>>>> >>>>> stepper_motor_bracket(); >>>>> ------------------------------------------------- >>>>> >>>>> Thanks Leonard, looks interesting, but for better or worse, it is not >>>>> the way I have been doing this sort of thing. If talking about stepper >>>>> motors, then I would have one library file with a module for details of >>>>> each type that I was interested in, nema 23, nema17, nema 32, whatever. The >>>>> mountiong plate details are not related to the numbers 17, 23/whatever, nor >>>>> the shaft diameter. so it would be a few number of modules in one file. >>>>> (with common variables sd, pd, pl, for shaft diameter, pilot diameter, >>>>> pilot length etc.) I'd leave in the test code (but comment it). Mounting >>>>> plate dimensions would be derived from the motor details, wrt fixing hole >>>>> positions pilot diameter, etc. each module would draw the object, and >>>>> could echo dimensions if needed. For the plate, it would probably be the >>>>> motor fixing holes and pilot and shaft clearance details - as cylinders, to >>>>> be differenced from a plate defined by length, width, thickness, and its >>>>> fixing holes >>>>> >>>>> I would include the whole library file within a module in the assembly >>>>> file, and within that assembly file module, set the required values. for >>>>> location, etc. for the specific library motor plate module. Most of the >>>>> values would be static, within the stepper motor library module e.g. motor >>>>> bolt hole details, so it would be just the size of plate, its location and >>>>> its fixing holes I'd need to set. If every plate for the different motors i >>>>> was using had a common thickness, then that could be defined outside of the >>>>> modules in the assembly file. >>>>> >>>>> I would have to include the library file in a fresh module for every >>>>> motor plate I wanted to use, and chose the module I was interested in, >>>>> whereas I believe you had one module per library file. I only have to do >>>>> this for my own use, and next week, I'll be onto something else, so no need >>>>> for it to look pretty, so to speak, nobody else needs to use it. If it were >>>>> just one or two motor plates, say, then I could have a file for each plate >>>>> and use it or include it as needed, but I would most likely need nothing >>>>> more than this. (I'm half inclined to test out what I'm trying to >>>>> explain...) >>>>> >>>>> Best wishes, >>>>> Ray >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> >