questions about best practices with variable scope and how best to access predefined variables
Well, all of this was a bit painful, but I am finally getting the kind of
parametric functionality I was hoping for. This is only just a start, but
I'll post the results once I actually start making the toolholders and test
them out. Thank you all for various suggestions.
===============
// French_Cleat.scad:
include <BOSL2/std.scad>
include <BOSL2/trigonometry.scad>
include <BOSL2/fnliterals.scad>
// French_Cleat_params: generate a hashmap of [key,val] pairs which hold
// the parameters for this version of French Cleats. By default it
generates
// the parameters for a 45 degree face made by cutting a 1x6" board in
half.
function
French_Cleat_params(type="solid",thickness=0.75,width=5.5/2,chamfer=0.0625,kerf=0.125,angle=45.0)
hashmap(items=[["cleat.type",type],
["cleat.thickness",thickness],
["cleat.width",width],
["cleat.chamfer",chamfer],
["cleat.kerf",kerf],
["cleat.angle",angle],
["cleat.face",_fc_cleat_face
(width,thickness,chamfer,angle,kerf)],
["cleat.face.center",_fc_cleat_face_center
(width,thickness,chamfer,angle,kerf)],
["cleat.profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]]
);
// _fc_cleat_face: generate the profile of the angled face of the cleat.
function _fc_cleat_face
(cleat_width,cleat_thickness,cleat_chamfer,cleat_angle,kerf) =
let(
c = cleat_thickness,
a2 = adj_ang_to_opp(c-cleat_chamfer,cleat_angle),
c2 = c-cleat_chamfer,
echo("**** FIXME: need to add the kerf to the profile")
) [[0.0,0.0], [-c,0.0], [-c,a2],[-c2,a2]]; // FIXME: adjust for kerfs
// _fc_cleat_face_center: generate the translation point where the center of
// the face is at [0,0].
function _fc_cleat_face_center
(cleat_width,cleat_thickness,cleat_chamfer,cleat_angle,kerf) =
let(
c = cleat_thickness,
a = adj_ang_to_opp(c,cleat_angle)
) [0,-a/2,0]; // FIXME: adjust for kerfs
// _fc_cleat_profile: generate the profile of the cleat including the
angled face.
function _fc_cleat_profile
(cleat_width,cleat_thickness,cleat_chamfer,cleat_angle,kerf) =
let(
c = cleat_thickness,
a = adj_ang_to_opp(c,cleat_angle),
a2 = adj_ang_to_opp(c-cleat_chamfer,cleat_angle),
c2 = c-cleat_chamfer
)
[[0.0,0.0],[-c2,a2],[-c,a2],[-c,-cleat_width+(a/2)],[0.0,-cleat_width+(a/2)]];
// example
use<tabbed-box/French_Cleat.scad>
// generate a set of parameters for the French Cleats (with user modified
angle).
FC30 = French_Cleat_params(angle=30);
// grab the French Cleat Parameters (as modified by user), and display
translate(FC30("cleat.face.center"))
color("yellow") linear_extrude(.25) polygon(FC30("cleat.profile"));
// now do it again for a 45 degree )tluafed(cleat for comparison. The
y-axis
// is translated so that the ends line up. Please note that the profiles
assume
// that a board is split in half, and the center of the cleat face in the
middle
// of the board is where the angled cut is referenced.
FC45 = French_Cleat_params(); // default angle=45
translate(FC45("cleat.face.center")+[0,0,0.5])
color("blue") linear_extrude(.25) polygon(FC45("cleat.profile"));
On Sun, Mar 10, 2024 at 10:13 PM John David ebo.2112@gmail.com wrote:
Thank you, Jon, for that pointer. It looks interesting. It gave me some
ideas on where to look inside BOSL2 as well -- where I found hashmap.
I will look at both of them, but I like some of the functionality with the
hashmap (specifically del and additems). I'll give that a try.
EBo --
On Sun, Mar 10, 2024 at 9:48 PM Jonathan Gilbert via Discuss <
discuss@lists.openscad.org> wrote:
https://github.com/jon-gilbert/openscad_objects is perhaps what you're
thinking of?
On Sun, Mar 10, 2024 at 6:46 PM John David via Discuss <
discuss@lists.openscad.org> wrote:
also with regards to manipulating named parameters, I remember reading
about something similar another project was using. Is there a pre-built
library for this functionality? I might have not found it yet, and should
scrap my use that instead.
EBo --
On Sun, Mar 10, 2024 at 9:00 PM John David ebo.2112@gmail.com wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
and then pass these parameters through to other functions. This is
only a small example, but is starting to feel about right:
include <BOSL2/std.scad>
include <BOSL2/trigonometry.scad>
function
French_Cleat_params(type="solid",thickness=0.75,width=5.5/2,chamfer=0.125,kerf=0.125,angle=45.0)
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
function _fc_cleat_profile
(cleat_width,cleat_thickness,cleat_chamfer,cleat_angle,kerf) =
let(
c = cleat_thickness,
b = adj_ang_to_hyp(c,cleat_angle),
a = adj_ang_to_opp(c,cleat_angle),
a2 = adj_ang_to_opp(c-cleat_chamfer,cleat_angle),
c2 = c-cleat_chamfer
) [[0.0,0.0], [-c,0.0], [-c,a2],[-c2,a2]]; // FIXME: adjust for
kerfs
function fc_param(params,catigory,var) =
let(
cat =
search(catigory,params,num_returns_per_match=0,index_col_num=0),
vals = [for(i=cat) for(j=i) params[j]],
scat = search(var,vals,num_returns_per_match=1,index_col_num=1),
val = [for(z=scat) for(k=z) vals[k]],
itm = val[0][2],
echo(".....",itm)
) itm;
// generate a set of parameters for the French Cleats (with user
modified angle).
cp = French_Cleat_params(angle=30);
// grab the French Cleat Parameters (as modified by user), and display
pc = fc_param(cp,"cleat","profile");
echo(" pc = ",pc);
color("yellow") linear_extrude(.25) polygon(pc);
I will clean this up as I start using it, but I think I am starting to
figure out OpenSCAD's syntax and semantics - the variables being static
after defined threw me for a loop).
I am confused about the warnings that are being generated by the
search. Anyone have suggestions on how to fix those?
EBo --
On Sun, Mar 10, 2024 at 12:08 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
On 3/10/2024 1:57 AM, John David via Discuss wrote:
Q1: is there are way to access a nested (sub)module from outside its
parent scope?
No. OpenSCAD modules are black holes. No information comes out of
them.
Also, OpenSCAD variables ... don't vary. Once set, they cannot be
changed. (You can create a new instance of a variable in a block, but
that's a new variable and the outer one is unchanged.)
I was hoping I could find a way to do something like:
module French_Cleat() {
module
define_solid_params(thickness=0.75,width=5.5/2,angle=45.0,chamfer=0.0625,saw_kerf=0.125,laseer_kerf=0.06)
{fc_angle=angle; ...}
function cleat_profile () =....; // uses fc_angle
}
Nope. Can't do anything like that, because there is absolutely no way
for a module to set a global variable.
Q2: it looks like functions are compiled when I include/use a file,
and not when used. Is there a way around this.
No. (Though given the scoping rules, it doesn't matter when the file
is "compiled", or that it's compiled at all.)
Advice:
For a simple model where the user wants to set values, put the
values together at the top of the file, so that the user can set them using
the Customizer. See
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customizer for
information on how to add comments to control the labels and other user
interface aspects.
For a subassembly where a program is going to set the values and
control them, the usual strategy is to have your subassembly's module take
parameters, and have the parameters have defaults.
Combining those two concepts:
cube1_size = 10;
cube2_size = 15;
ratio = 2;
twoCubes();
translate([30,0,0]) twoCubes(cube1_size, cube2_size);
translate([60,0,0]) twoCubes(cube1_size * ratio, cube2_size * ratio);
module twoCubes(c1=5, c2=7) {
cube(c1, center=true);
cube(c2);
}
Note that the file has default values (that the user can change with
the customizer) that control the middle pair of cubes, and the module has
its own defaults that control the first pair.
The usual variable scoping is lexical: you can look at the layout of
the program to see what variables are visible at any given point. Just
walk up the enclosing blocks until you get to the first variable with that
name.
You can use $ variables to pass information into modules or
functions. They are still immutable, but are dynamically scoped. They are
passed down through calls, no matter how the program is laid out. Walk up
the call stack until you find the first variable with that name.
$ variables don't lend themselves to module-level defaults, though you
can do it using is_undef().
You can write a variation on the example above as:
$cube1_size = 10;
$cube2_size = 15;
twoCubes();
translate([30,0,0]) {
$cube1_size = 20;
$cube2_size = 30;
twoCubes();
}
module twoCubes() {
cube($cube1_size, center=true);
cube($cube2_size);
}
... but mostly I wouldn't recommend it.
Related notes:
- In any given block, all assignments are processed before all
module invocations. Don't expect to be able to call a module, then set a $
variable, then call it again. Both calls will get the value from the
assignment.
- With respect to the model, it almost doesn't matter what order
modules get called in. (Exceptions: echo(), rands(), and some cases
involving transparency and coloring that are probably best viewed as
weaknesses in the previewer.)
- The customizer will suck up all constant assignments, until it
hits the first module definition. If you want to have a global variable
that the user *shouldn't* customize, put in a dummy "module stop();" after
the customizable variables.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
- Jon Gilbert
jong@jong.org / jgilbertsjc@gmail.com
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Hi John,
I'm not sure why you seem to be making this so complicated.
The French cleat is all about profiles, so start with 2d. Generally the
wall strips are made first, so here is a parametric wall plate profile.
Simple for the user to change to whatever size you want, using the
customizer. Note that I have included a 'flat' at the top. If you are
routing the profile of the fittings, then that flat will be
approximately the diameter of the router bit, the kerf of the tool used
to cut the mating fittings - else the fittings will not slide down
snugly onto the cleat. Of course, you do not need a flat, but there are
advantages to at least rounding off the top edge. If left pointed, then
you will need to adjust the mating profile in the real world. You can
use offset to get the profile of the fitting, with a negative delta
value for the radius of router to get the shape around the pointy top. I
am not restricting this in any way to the type of materials, method of
construction of the parts, etc. Do not make decisions before you need
to, no need for BOS2L .
This guy - https://www.youtube.com/watch?v=usFRvasGW70 makes his living
from supplying wooden French cleats to Woodworkers!
By initially dealing with profiles, the thickness of the fittings, what
they do, the method of creating the actual parts can be separately
considered afterwards, in other modules.
.
The next step would be to generate the mating part, allowing for
tolerances, and the ability to 'hook over'. Then add on whatever the
fitting needs, (brackets, holes, etc). You will not be able to generate
a working fitting, by simply differencing the profile.
I've also attached the code snippet to generate the illustrated profile.
Best wishes,
Ray
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a
more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the
search. Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match.
Current development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap
(specifically del and additems).
Note that those functions do not modify existing hashmaps; they create
new hashmaps with the changes requested. Again, OpenSCAD variables are
immutable, and that includes arrays.
Hashmap may be overkill here. Why not use structs instead? I think they
have some error checking features you won’t get with hashmap to prevent
creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a
more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the search.
Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match. Current
development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap
(specifically del and additems).
Note that those functions do not modify existing hashmaps; they create new
hashmaps with the changes requested. Again, OpenSCAD variables are
immutable, and that includes arrays.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thank you, Ray,
I have seen a couple of the videos that "A Glimpse Inside" guy does, and as
I start building my toolholders I will likely go back and watch them again
in the future for ideas. You are right. Using BOSL2, or any of this
advanced stuff, is gross overkill. I had already used OpenSCAD to model a
conventional solid cleat, as well as the simpler thin-cleats like in the
video. I spent way too much time learning OpenSCAD syntax and semantics,
building my first couple of toolholders as OpenSCAD assemblies using simple
cube, triangle, calendar, union, difference... (I hope I am using the
correct terminology). Anyway, when I started thinking of making
toolholders out of tabbed-boxes is what send me down the current bunny
trail. I am really only working on this late at night as I am starting to
wind down before I go to bed... My current status is that I build the
profiles (in 2D), and then can add to them, extrude them, etc. At this
point, I can parametrically generate the simplest of the thin cleats, with
a foot/standoff, a top(not sure what to best name it), side width, etc.
designs
The next step will be to take one or two of my toolholder designs and make
one or more. My first modeled toolholder, which I have not made yet, is
for a lasercut Kobalt 24v charging station. A charger is vertically
mounted on the top, there is room for 4 full sized batteries to slide and
lock into place, an open space in the back for the power cord, and the
bottom is flat so it can be carried around and set down on a work table. I
even modeled the locking clip as a sandwiched 1/4" plywood cutouts with a
small finishing nail to act as alignment pin. With any luck, that will
work, but it is a good learning exercise. The one thing I have not figured
out yet is how to modify the cleat so that it also functions as an
erstwhile handle.
Adrian, I agree -- hashmap is WAY overkill, but to be frank, I am still
learning the OpenSCAD syntax and I came across heatmap before I came across
advanced associative arrays and structs.
Thanks all for the suggesting and feedback.
On Mon, Mar 11, 2024 at 12:09 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Hashmap may be overkill here. Why not use structs instead? I think they
have some error checking features you won’t get with hashmap to prevent
creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a
more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the search.
Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match. Current
development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap
(specifically del and additems).
Note that those functions do not modify existing hashmaps; they create
new hashmaps with the changes requested. Again, OpenSCAD variables are
immutable, and that includes arrays.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 3/11/2024 4:35 PM, John David via Discuss wrote:
(snip)
Using BOSL2, or any of this advanced stuff, is gross overkill.
Not if a particular module provides you functionality you'd have to
spend hours writing yourself.
I kinda wish I had discovered BOSL2 earlier for my steam locomotive
project. Although, in the end for the couple of external libraries I
did use I contacted the individual authors to get permission to include
them in-situ in my Github repository. Trying to make it easier for the
intended audience to use, model railroaders, not programmers. Wondering
if asking them to install something like BOSL2 would be a bridge too far...
I'm intermittently playing with parameterized components for making
scale models:
https://github.com/butcherg/modelingtools
Most of them use the OpenSCAD customizer conventions to change things
like width, height, etc. I've web-ified some of them on my personal server:
https://glenn.pulpitrock.net/customizable_models/
Basically the same thing you can do at Thingiverse, just a simpler web
page...
BOSL2 may have lots of stuff that is unneeded the vast majority of the time. However, the basics of BOSL2 have become essential to my use of OpenSCAD. Using up, down, left, right, fwd, and back, xrot, yrot, and zrot, xcyl, ycyl and zcyl, the anchors RIGHT, LEFT, TOP, BOT, FRONT and BACK, make your code so much more readable that I think it is a huge mistake to not use BOSL2. I do nothing without it in OpenSCAD. If I were king it would be incorporated into the base product.
-Bob
On Mar 11, 2024, at 15:35, John David via Discuss discuss@lists.openscad.org wrote:
Thank you, Ray,
I have seen a couple of the videos that "A Glimpse Inside" guy does, and as I start building my toolholders I will likely go back and watch them again in the future for ideas. You are right. Using BOSL2, or any of this advanced stuff, is gross overkill. I had already used OpenSCAD to model a conventional solid cleat, as well as the simpler thin-cleats like in the video. I spent way too much time learning OpenSCAD syntax and semantics, building my first couple of toolholders as OpenSCAD assemblies using simple cube, triangle, calendar, union, difference... (I hope I am using the correct terminology). Anyway, when I started thinking of making toolholders out of tabbed-boxes is what send me down the current bunny trail. I am really only working on this late at night as I am starting to wind down before I go to bed... My current status is that I build the profiles (in 2D), and then can add to them, extrude them, etc. At this point, I can parametrically generate the simplest of the thin cleats, with a foot/standoff, a top(not sure what to best name it), side width, etc. designs
The next step will be to take one or two of my toolholder designs and make one or more. My first modeled toolholder, which I have not made yet, is for a lasercut Kobalt 24v charging station. A charger is vertically mounted on the top, there is room for 4 full sized batteries to slide and lock into place, an open space in the back for the power cord, and the bottom is flat so it can be carried around and set down on a work table. I even modeled the locking clip as a sandwiched 1/4" plywood cutouts with a small finishing nail to act as alignment pin. With any luck, that will work, but it is a good learning exercise. The one thing I have not figured out yet is how to modify the cleat so that it also functions as an erstwhile handle.
Adrian, I agree -- hashmap is WAY overkill, but to be frank, I am still learning the OpenSCAD syntax and I came across heatmap before I came across advanced associative arrays and structs.
Thanks all for the suggesting and feedback.
On Mon, Mar 11, 2024 at 12:09 PM Adrian Mariano via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org> wrote:
Hashmap may be overkill here. Why not use structs instead? I think they have some error checking features you won’t get with hashmap to prevent creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile (width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the search. Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match. Current development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap (specifically del and additems).
Note that those functions do not modify existing hashmaps; they create new hashmaps with the changes requested. Again, OpenSCAD variables are immutable, and that includes arrays.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
It is the opposite for me. I can understand basic OpenSCAD code with
translates and rotates but I can't understand any BOSL2 code. I would have
to learn a new language.
On Mon, 11 Mar 2024 at 23:18, Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:
BOSL2 may have lots of stuff that is unneeded the vast majority of the
time. However, the basics of BOSL2 have become essential to my use of
OpenSCAD. Using up, down, left, right, fwd, and back, xrot, yrot, and zrot,
xcyl, ycyl and zcyl, the anchors RIGHT, LEFT, TOP, BOT, FRONT and BACK,
make your code so much more readable that I think it is a huge mistake to
not use BOSL2. I do nothing without it in OpenSCAD. If I were king it would
be incorporated into the base product.
-Bob
On Mar 11, 2024, at 15:35, John David via Discuss <
discuss@lists.openscad.org> wrote:
Thank you, Ray,
I have seen a couple of the videos that "A Glimpse Inside" guy does, and
as I start building my toolholders I will likely go back and watch them
again in the future for ideas. You are right. Using BOSL2, or any of this
advanced stuff, is gross overkill. I had already used OpenSCAD to model a
conventional solid cleat, as well as the simpler thin-cleats like in the
video. I spent way too much time learning OpenSCAD syntax and semantics,
building my first couple of toolholders as OpenSCAD assemblies using simple
cube, triangle, calendar, union, difference... (I hope I am using the
correct terminology). Anyway, when I started thinking of making
toolholders out of tabbed-boxes is what send me down the current bunny
trail. I am really only working on this late at night as I am starting to
wind down before I go to bed... My current status is that I build the
profiles (in 2D), and then can add to them, extrude them, etc. At this
point, I can parametrically generate the simplest of the thin cleats, with
a foot/standoff, a top(not sure what to best name it), side width, etc.
designs
The next step will be to take one or two of my toolholder designs and make
one or more. My first modeled toolholder, which I have not made yet, is
for a lasercut Kobalt 24v charging station. A charger is vertically
mounted on the top, there is room for 4 full sized batteries to slide and
lock into place, an open space in the back for the power cord, and the
bottom is flat so it can be carried around and set down on a work table. I
even modeled the locking clip as a sandwiched 1/4" plywood cutouts with a
small finishing nail to act as alignment pin. With any luck, that will
work, but it is a good learning exercise. The one thing I have not figured
out yet is how to modify the cleat so that it also functions as an
erstwhile handle.
Adrian, I agree -- hashmap is WAY overkill, but to be frank, I am still
learning the OpenSCAD syntax and I came across heatmap before I came across
advanced associative arrays and structs.
Thanks all for the suggesting and feedback.
On Mon, Mar 11, 2024 at 12:09 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Hashmap may be overkill here. Why not use structs instead? I think they
have some error checking features you won’t get with hashmap to prevent
creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a
more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the
search. Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match.
Current development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap
(specifically del and additems).
Note that those functions do not modify existing hashmaps; they create
new hashmaps with the changes requested. Again, OpenSCAD variables are
immutable, and that includes arrays.
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
Bob, I am looking forward to learning more about anchors, and more. At the
moment, I have not used much of BOSL2 other than some of the trig functions
(like law_of_cosines/sines) to quickly lengths of sides and angles.
Getting to the tabs generation functions is going to be a noodle
scratcher. Thanks for the suggestions!
On Mon, Mar 11, 2024 at 8:07 PM nop head via Discuss <
discuss@lists.openscad.org> wrote:
It is the opposite for me. I can understand basic OpenSCAD code with
translates and rotates but I can't understand any BOSL2 code. I would have
to learn a new language.
On Mon, 11 Mar 2024 at 23:18, Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:
BOSL2 may have lots of stuff that is unneeded the vast majority of the
time. However, the basics of BOSL2 have become essential to my use of
OpenSCAD. Using up, down, left, right, fwd, and back, xrot, yrot, and zrot,
xcyl, ycyl and zcyl, the anchors RIGHT, LEFT, TOP, BOT, FRONT and BACK,
make your code so much more readable that I think it is a huge mistake to
not use BOSL2. I do nothing without it in OpenSCAD. If I were king it would
be incorporated into the base product.
-Bob
On Mar 11, 2024, at 15:35, John David via Discuss <
discuss@lists.openscad.org> wrote:
Thank you, Ray,
I have seen a couple of the videos that "A Glimpse Inside" guy does, and
as I start building my toolholders I will likely go back and watch them
again in the future for ideas. You are right. Using BOSL2, or any of this
advanced stuff, is gross overkill. I had already used OpenSCAD to model a
conventional solid cleat, as well as the simpler thin-cleats like in the
video. I spent way too much time learning OpenSCAD syntax and semantics,
building my first couple of toolholders as OpenSCAD assemblies using simple
cube, triangle, calendar, union, difference... (I hope I am using the
correct terminology). Anyway, when I started thinking of making
toolholders out of tabbed-boxes is what send me down the current bunny
trail. I am really only working on this late at night as I am starting to
wind down before I go to bed... My current status is that I build the
profiles (in 2D), and then can add to them, extrude them, etc. At this
point, I can parametrically generate the simplest of the thin cleats, with
a foot/standoff, a top(not sure what to best name it), side width, etc.
designs
The next step will be to take one or two of my toolholder designs and
make one or more. My first modeled toolholder, which I have not made yet,
is for a lasercut Kobalt 24v charging station. A charger is vertically
mounted on the top, there is room for 4 full sized batteries to slide and
lock into place, an open space in the back for the power cord, and the
bottom is flat so it can be carried around and set down on a work table. I
even modeled the locking clip as a sandwiched 1/4" plywood cutouts with a
small finishing nail to act as alignment pin. With any luck, that will
work, but it is a good learning exercise. The one thing I have not figured
out yet is how to modify the cleat so that it also functions as an
erstwhile handle.
Adrian, I agree -- hashmap is WAY overkill, but to be frank, I am still
learning the OpenSCAD syntax and I came across heatmap before I came across
advanced associative arrays and structs.
Thanks all for the suggesting and feedback.
On Mon, Mar 11, 2024 at 12:09 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Hashmap may be overkill here. Why not use structs instead? I think they
have some error checking features you won’t get with hashmap to prevent
creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to build a named
parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in and we'll have a
more concise syntax for this kind of thing.
I am confused about the warnings that are being generated by the
search. Anyone have suggestions on how to fix those?
Older versions gave warnings when search() did not find a match.
Current development snapshots do not.
[...] I like some of the [BOSL2] functionality with the hashmap
(specifically del and additems).
Note that those functions do not modify existing hashmaps; they create
new hashmaps with the changes requested. Again, OpenSCAD variables are
immutable, and that includes arrays.
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I've never needed BOS2L either, although I have asked one or two who
use/contribute wrt the maths that is incorporated within it (I'm finding
that now I'm forgetting more than what I'm learning). It depends what
the objective is, in my case the journey is usually the destination. For
example, I do not need French Cleats, but interesting for me to be
looking into how I'd approach it for an imaginary 'user'. I'm not sure
if this was going to be of use, as a generic program for all
materials/method of construction, but for generating the shape it will
do. For example, in fdm printing (additive) the fundamental design can
be entirely different than woodwork (subtractive), but the
functionality can be the same, and you can combine both methods to get
the best (or worst) of both systems.Maybe wood for the 'standard'
cleating system, and fdm for the specific tool fittings.
On 12/03/2024 00:07, nop head via Discuss wrote:
It is the opposite for me. I can understand basic OpenSCAD code with
translates and rotates but I can't understand any BOSL2 code. I would
have to learn a new language.
On Mon, 11 Mar 2024 at 23:18, Bob Carlson via Discuss
discuss@lists.openscad.org wrote:
BOSL2 may have lots of stuff that is unneeded the vast majority of
the time. However, the basics of BOSL2 have become essential to my
use of OpenSCAD. Using up, down, left, right, fwd, and back, xrot,
yrot, and zrot, xcyl, ycyl and zcyl, the anchors RIGHT, LEFT, TOP,
BOT, FRONT and BACK, make your code so much more readable that I
think it is a huge mistake to not use BOSL2. I do nothing without
it in OpenSCAD. If I were king it would be incorporated into the
base product.
-Bob
On Mar 11, 2024, at 15:35, John David via Discuss
<discuss@lists.openscad.org> wrote:
Thank you, Ray,
I have seen a couple of the videos that "A Glimpse Inside" guy
does, and as I start building my toolholders I will likely go
back and watch them again in the future for ideas. You are
right. Using BOSL2, or any of this advanced stuff, is gross
overkill. I had already used OpenSCAD to model a conventional
solid cleat, as well as the simpler thin-cleats like in the
video. I spent *way* too much time learning OpenSCAD syntax and
semantics, building my first couple of toolholders as OpenSCAD
assemblies using simple cube, triangle, calendar, union,
difference... (I hope I am using the correct terminology).
Anyway, when I started thinking of making toolholders out of
tabbed-boxes is what send me down the current bunny trail. I am
really only working on this late at night as I am starting to
wind down before I go to bed... My current status is that I
build the profiles (in 2D), and then can add to them, extrude
them, etc. At this point, I can parametrically generate the
simplest of the thin cleats, with a foot/standoff, a top(not sure
what to best name it), side width, etc. designs
The next step will be to take one or two of my toolholder designs
and make one or more. My first modeled toolholder, which I have
not made yet, is for a lasercut Kobalt 24v charging station. A
charger is vertically mounted on the top, there is room for 4
full sized batteries to slide and lock into place, an open space
in the back for the power cord, and the bottom is flat so it can
be carried around and set down on a work table. I even modeled
the locking clip as a sandwiched 1/4" plywood cutouts with a
small finishing nail to act as alignment pin. With any luck,
that will work, but it is a good learning exercise. The one
thing I have not figured out yet is how to modify the cleat so
that it also functions as an erstwhile handle.
Adrian, I agree -- hashmap is WAY overkill, but to be frank, I am
still learning the OpenSCAD syntax and I came across heatmap
before I came across advanced associative arrays and structs.
Thanks all for the suggesting and feedback.
On Mon, Mar 11, 2024 at 12:09 PM Adrian Mariano via Discuss
<discuss@lists.openscad.org> wrote:
Hashmap may be overkill here. Why not use structs instead? I
think they have some error checking features you won’t get
with hashmap to prevent creation of incorrect fields.
On Mon, Mar 11, 2024 at 12:03 Jordan Brown via Discuss
<discuss@lists.openscad.org> wrote:
On 3/10/2024 6:00 PM, John David wrote:
OK. It is starting to take shape. What I did was to
build a named parameter list that looks like:
[["cleat","type",type],
["cleat","thickness",thickness],
["cleat","width",width],
["cleat","chamfer",chamfer],
["cleat","kerf",kerf],
["cleat","angle",angle],
["cleat","profile",_fc_cleat_profile
(width,thickness,chamfer,angle,kerf)]];
That can work. One of these days we'll get PR#4478 in
and we'll have a more concise syntax for this kind of thing.
I am confused about the warnings that are being
generated by the search. Anyone have suggestions on how
to fix those?
Older versions gave warnings when search() did not find a
match. Current development snapshots do not.
[...] I like some of the [BOSL2] functionality with the
hashmap (specifically del and additems).
Note that those functions do not modify existing
hashmaps; they create new hashmaps with the changes
requested. Again, OpenSCAD variables are immutable, and
that includes arrays.
_______________________________________________
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
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org