discuss@lists.openscad.org

OpenSCAD general discussion

View all threads

Re: Fwd: Re: start a module from a variabel

PC
Patrick Callahan
Sat, Oct 23, 2021 5:48 PM

Ray,

For the moment, I'm just trying to avoid re-inventing the wheel.

nopScadLib looks pretty good as an example of how to go about complex
projects. I'm exploring the library this weekend.
Any other suggestions for projects to examine?

My project is flight simulation gauges, instruments, radios, and controls.

As for avoiding frameworks becoming more onerous than the problem, that's
something I'd prefer to avoid.  I know from experience that it's easy to
let the tail wag the dog.

I'm not so much looking for a library or method that solves all problems,
as seeking a small set of strategies or guidelines for creating modules,
functions, and variables, then putting them in separate files that play
nicely together across a larger project.

On Fri, Oct 22, 2021 at 10:18 AM Ray West raywest@raywest.com wrote:

I think 'granularity' is the word. It depends on how you go about things.
Some things will need a ton of parameters. For example if you grouped
together everything into say 'parts that make an aeroplane fly' - and then
you'd have to do it again for 'parts that make an aeroplane land'.

Nophead has a very nice solution, but for what I do, it is not worth the
effort. I am not manufacturing, or too interested in keeping a record of
complex constructions. For that, I'd probably be looking at software
systems designed for that, because my time would be money.

I started writing a library of things i used often, but it is just as easy
for me to rewrite the script for those parts, instead of opening the
library and trying to find/remember the variable names i used last week,
say.

I'm not sure if you can have a very generalised system that will work in
all cases, however, if you are only interested in a particular type of
project, then it becomes more useful. What is your particular area of
interest?

I think i would just have parts and layouts. each would have their own
measurements. Would have to decide if you were measuring from centre of
part, and what centre? For example, a stepper motor. measure from the
shaft, or fixing holes, or which end of shaft, etc. depending on the
application, i.e. designing a mounting plate, or a gear box?  You could
just deal with Nema23 say, as how you pass the details, or you could use
the specific measurements.

I find, that in general, I end up devising my own systems, I can take
shortcuts, abbreviate names, etc. I tend to be a pragmatist, so if talking
about 3d printing, then self tappers or woodscrews are more than adequate
fasteners, and if necessary, I'm quite happy to drill or otherwise machine
the plastic, since it is for my use, one -off's /whatever. If for cnc
machining, then the precision comes in the correct  tooling, offset values
/machine taps, etc.

I think, if you aim for a general purpose solution, it will fit in every
situation worse than an individual solution tailored to the  specific
situation.

Unfortunately, you can not refer to a value by including its module name
as a dot name. e.g. a module named 'big', has a value named 'width' and a
module named 'small' also has a value named 'width' you can't access  the
small width by using small.width  you either have to put it inside another
module, or expose the variable name as 'module small(width)' which becomes
cumbersome.

I think openscad was developed as a sort of theoretical/academic  thing,
and folk are trying to push it towards something it was not designed for -
for example trying to edit text within it, or trying to get measurements.
It is a quick precise method of parametrically generating objects,
everything else has to be a work around.

If you can give more specific details of what you are trying to use it
for, then I can probably give some suggestions more suited to the
specifics, but sometimes the framework becomes more onerous than the
problem.

If it was easy, everybody would be doing it...

Best wishes,

Ray

PS, mock something out - two or three part files - simple cubes or echoes,
and see how you can collect them in a layout file, and how to pass values.
Send it to me, so I can dismantle it 😉 General solutions are generally
difficult, e.g. how to store nuts and bolts, travelling salesman, and all
that good stuff.

On 22/10/2021 13:13, Patrick Callahan wrote:

Ray,

I think I'm trying to get to some rules for code and interface
organization specific to OpenSCAD.

Your comments on the separation of components as modules and the treatment
of variables exemplify the kind of structural thinking I want to clarify.

I think everyone who uses openSCAD will eventually find that they are
solving this kind of problem whether they think about it directly or not.
I'm hoping to avoid duplicating work others have already done as I organize
my work.

Certain "kinds" of OpenSCAD code would be in each of those "types" of
files.  The question is, what specific kind of code

I've got my first project written as individual modules, one module per
part usually and sometimes one per feature. But some interfaces have many
parameters. That's not a good sign.

I'm thinking of files with names like:
*.measurements.scad
*.feature.scad
*.part.scad
*.layout.scad
*.animation.scad
*.component.scad
etc.

On Thu, Oct 21, 2021 at 2:08 PM Ray West raywest@raywest.com wrote:

Speaking generally, in an example where you have a number of component
items, and a layout/collection file.

if you write each component/part/group of parts as separate modules, and
if you extract all the values that you want to change as variables, you can
test each part individually. then you can comment out the variables that
you want to change in the 'layout file' and save it as a component file.
Then in the layout file,  you can include each component file inside a
module, and set the variables inside the module, or outside, if you want.
That allows you to use simple variable names  like length, width, whatever
for each component, and to have the values individually adjustable in the
layout file, without having to alter values in the component files.
On 21/10/2021 16:55, Patrick Callahan wrote:

I'll want to arrange the data for parts and assemblies in an organized
way.

Today, my measurements for a project are in a single .scad file. I import
this file in each part file. But it's becoming unwieldy.
So, I'm looking for advice and examples of ways folks have dealt with the
structure of data in OpenScad projects.'

-Pat

As for scripting, language does not matter to me.
Ideally, I'd like to see the features addressed by scripting handled by
extending the OpenSCAD language, but that's a bit beyond my skills for now.

Data Usage

- absolute measurements for single or multiple sizes
- relative measurements between parts
- clearances
- calculated measures
- re-use of a measurement in multiple parts
- location and orientation data
- movement
- part selection

Goals:

- exploded views
- animated movement showing the assembly process and movement within
the final assembly
- 2d Drawings with labels and measures
- 3d print compatible files with one or more parts
- parts lists (with pictures)
- assembly instructions (with pictures)

On Mon, Oct 11, 2021 at 3:07 PM Ray West raywest@raywest.com wrote:

If it is for my own use and i can't bother with typing a list of if's, I
just rem out what's not needed - e.g. like

// body();
// translate([0,0,-2.5])flor();
translate([0,-0.5,-12-thickness]) underframe();

On 11/10/2021 18:44, Matthieu Hendriks wrote:

Yes I do the same, it's still a workaround for the extra coding effort
:)
Groet Matthieu

Jan Wieck schreef op 2021-10-11 19:34:

On 10/11/21 11:59 AM, Matthieu Hendriks wrote:

Is it possible to execute a module depending on a variable name. Example:

When I have "assemblies" I usually create a drop-down list and then
create modules depending on the value. Like:

part = "body"; // [body, arm, leg, head, all]

if (part == "body") { body(); }
if (part == "arm") { arm(); }
...
if (part == "all") {
body();
arm();
leg();
head();
}

That way I can select individual parts to work on, render and export for
printing, but I can also see the entire assembly together. The "all"
selection often has some rotate() and translate() for the actual parts to
put them at the right position within the assembly.

Regards, Jan

module_to_start = "create_plate"

sys(module_to_start) or &module_to_start

module create_plate () { ...}

module create_head () { ...}

Groet Matthieu



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

Ray, For the moment, I'm just trying to avoid re-inventing the wheel. nopScadLib looks pretty good as an example of how to go about complex projects. I'm exploring the library this weekend. Any other suggestions for projects to examine? My project is flight simulation gauges, instruments, radios, and controls. As for avoiding frameworks becoming more onerous than the problem, that's something I'd prefer to avoid. I know from experience that it's easy to let the tail wag the dog. I'm not so much looking for a library or method that solves all problems, as seeking a small set of strategies or guidelines for creating modules, functions, and variables, then putting them in separate files that play nicely together across a larger project. On Fri, Oct 22, 2021 at 10:18 AM Ray West <raywest@raywest.com> wrote: > I think 'granularity' is the word. It depends on how you go about things. > Some things will need a ton of parameters. For example if you grouped > together everything into say 'parts that make an aeroplane fly' - and then > you'd have to do it again for 'parts that make an aeroplane land'. > > Nophead has a very nice solution, but for what I do, it is not worth the > effort. I am not manufacturing, or too interested in keeping a record of > complex constructions. For that, I'd probably be looking at software > systems designed for that, because my time would be money. > > I started writing a library of things i used often, but it is just as easy > for me to rewrite the script for those parts, instead of opening the > library and trying to find/remember the variable names i used last week, > say. > > I'm not sure if you can have a very generalised system that will work in > all cases, however, if you are only interested in a particular type of > project, then it becomes more useful. What is your particular area of > interest? > > I think i would just have parts and layouts. each would have their own > measurements. Would have to decide if you were measuring from centre of > part, and what centre? For example, a stepper motor. measure from the > shaft, or fixing holes, or which end of shaft, etc. depending on the > application, i.e. designing a mounting plate, or a gear box? You could > just deal with Nema23 say, as how you pass the details, or you could use > the specific measurements. > > I find, that in general, I end up devising my own systems, I can take > shortcuts, abbreviate names, etc. I tend to be a pragmatist, so if talking > about 3d printing, then self tappers or woodscrews are more than adequate > fasteners, and if necessary, I'm quite happy to drill or otherwise machine > the plastic, since it is for my use, one -off's /whatever. If for cnc > machining, then the precision comes in the correct tooling, offset values > /machine taps, etc. > > I think, if you aim for a general purpose solution, it will fit in every > situation worse than an individual solution tailored to the specific > situation. > > Unfortunately, you can not refer to a value by including its module name > as a dot name. e.g. a module named 'big', has a value named 'width' and a > module named 'small' also has a value named 'width' you can't access the > small width by using small.width you either have to put it inside another > module, or expose the variable name as 'module small(width)' which becomes > cumbersome. > > I think openscad was developed as a sort of theoretical/academic thing, > and folk are trying to push it towards something it was not designed for - > for example trying to edit text within it, or trying to get measurements. > It is a quick precise method of parametrically generating objects, > everything else has to be a work around. > > If you can give more specific details of what you are trying to use it > for, then I can probably give some suggestions more suited to the > specifics, but sometimes the framework becomes more onerous than the > problem. > > If it was easy, everybody would be doing it... > > Best wishes, > > Ray > > PS, mock something out - two or three part files - simple cubes or echoes, > and see how you can collect them in a layout file, and how to pass values. > Send it to me, so I can dismantle it 😉 General solutions are generally > difficult, e.g. how to store nuts and bolts, travelling salesman, and all > that good stuff. > > > On 22/10/2021 13:13, Patrick Callahan wrote: > > Ray, > > I think I'm trying to get to some rules for code and interface > organization specific to OpenSCAD. > > Your comments on the separation of components as modules and the treatment > of variables exemplify the kind of structural thinking I want to clarify. > > I think everyone who uses openSCAD will eventually find that they are > solving this kind of problem whether they think about it directly or not. > I'm hoping to avoid duplicating work others have already done as I organize > my work. > > Certain "kinds" of OpenSCAD code would be in each of those "types" of > files. The question is, what specific kind of code > > I've got my first project written as individual modules, one module per > part usually and sometimes one per feature. But some interfaces have many > parameters. That's not a good sign. > > I'm thinking of files with names like: > *.measurements.scad > *.feature.scad > *.part.scad > *.layout.scad > *.animation.scad > *.component.scad > etc. > > > On Thu, Oct 21, 2021 at 2:08 PM Ray West <raywest@raywest.com> wrote: > >> Speaking generally, in an example where you have a number of component >> items, and a layout/collection file. >> >> if you write each component/part/group of parts as separate modules, and >> if you extract all the values that you want to change as variables, you can >> test each part individually. then you can comment out the variables that >> you want to change in the 'layout file' and save it as a component file. >> Then in the layout file, you can include each component file inside a >> module, and set the variables inside the module, or outside, if you want. >> That allows you to use simple variable names like length, width, whatever >> for each component, and to have the values individually adjustable in the >> layout file, without having to alter values in the component files. >> On 21/10/2021 16:55, Patrick Callahan wrote: >> >> I'll want to arrange the data for parts and assemblies in an organized >> way. >> >> Today, my measurements for a project are in a single .scad file. I import >> this file in each part file. But it's becoming unwieldy. >> So, I'm looking for advice and examples of ways folks have dealt with the >> structure of data in OpenScad projects.' >> >> -Pat >> >> >> As for scripting, language does not matter to me. >> Ideally, I'd like to see the features addressed by scripting handled by >> extending the OpenSCAD language, but that's a bit beyond my skills for now. >> >> Data Usage >> >> - absolute measurements for single or multiple sizes >> - relative measurements between parts >> - clearances >> - calculated measures >> - re-use of a measurement in multiple parts >> - location and orientation data >> - movement >> - part selection >> >> Goals: >> >> - exploded views >> - animated movement showing the assembly process and movement within >> the final assembly >> - 2d Drawings with labels and measures >> - 3d print compatible files with one or more parts >> - parts lists (with pictures) >> - assembly instructions (with pictures) >> >> >> On Mon, Oct 11, 2021 at 3:07 PM Ray West <raywest@raywest.com> wrote: >> >>> If it is for my own use and i can't bother with typing a list of if's, I >>> just rem out what's not needed - e.g. like >>> >>> // body(); >>> // translate([0,0,-2.5])flor(); >>> translate([0,-0.5,-12-thickness]) underframe(); >>> >>> >>> On 11/10/2021 18:44, Matthieu Hendriks wrote: >>> >>> Yes I do the same, it's still a workaround for the extra coding effort >>> :) >>> Groet Matthieu >>> >>> >>> Jan Wieck schreef op 2021-10-11 19:34: >>> >>> On 10/11/21 11:59 AM, Matthieu Hendriks wrote: >>> >>> Is it possible to execute a module depending on a variable name. Example: >>> >>> >>> When I have "assemblies" I usually create a drop-down list and then >>> create modules depending on the value. Like: >>> >>> part = "body"; // [body, arm, leg, head, all] >>> >>> if (part == "body") { body(); } >>> if (part == "arm") { arm(); } >>> ... >>> if (part == "all") { >>> body(); >>> arm(); >>> leg(); >>> head(); >>> } >>> >>> That way I can select individual parts to work on, render and export for >>> printing, but I can also see the entire assembly together. The "all" >>> selection often has some rotate() and translate() for the actual parts to >>> put them at the right position within the assembly. >>> >>> >>> Regards, Jan >>> >>> >>> >>> module_to_start = "create_plate" >>> >>> sys(module_to_start) or &module_to_start >>> >>> module create_plate () { ...} >>> >>> module create_head () { ...} >>> >>> >>> >>> Groet Matthieu >>> ------------------------------------------------------------------------ >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> >>