Vector parameter type

[jreinhardt]

This would allow to handle higher dimensional tables, like they occur for pipes, and to more cleanly solve the alternatives for b in http://jreinhardt.github.io/BOLTS/html/classes/DINENISO4014.html

[jreinhardt]

Not sure if this is a good idea, what to do e.g. with the SolidWorks Excel Sheets?

[DaleDunn]

Hmmm. I don't have that problem at 127.0.0.1...

If I look at http://jreinhardt.github.io/BOLTS/html/classes/DINENISO4014.html, I see a 2D table. If I imagine that table with the possible lengths added, then it's a 3D table. In SolidWorks spreadsheets, I create the different lengths right in the 2D spreadsheet table, with all the different lengths of a nominal size grouped together.

If you look at the example spreadsheets I uploaded to the RepRap forum (http://forums.reprap.org/read.php?80,264283,291203#msg-291203 post dated November 17, 2013 05:50PM), you'll find a good example in "Socket Head Cap Screw DIN 912, ISO 4762.xlsx ".

I've been planning to ask about this in relation to the naming parameters in the base files. I assumed it was a matter of merely needing to study the YAML format. Now I'm not so sure. That probably is really a separate issue.

I haven't yet needed more than 3 dimensions of data.

Perhaps I'm not understanding the issue. Is it a question of how to deal with a parameter expressed as a tolerance range? In those cases, I take the most pessimistic geometry available. I've always modeled screws with the minimum thread length. Someone else may have a different opinion about what is pessimistic. For all of these cases the contributor creating the model will need to make a guess at what most users will need. In some instances I have created separate columns in the table for maximum and minimum values, and used only the pessimistic one in the model. The other was kept for reference.

HTH

[jreinhardt]

The issue that I wanted to address here is a bit different. In some cases it would be nice to have a table where you do you lookup a value not by selecting a certain row (this is how all the tables I have right now work), but by selecting both a row and a column.

The first kind ("type 1") of table gives you a (one row key) -> (many parameter values)

"key1" : value1, value2, value3
"key2" : value4, value5, value6
...

The second kind ("type 2") of table gives you (one row, one column index) -> (one parameter value).

        "col1"  "col2"   ...
 "row1"  val1    val2    ...
 "row2"  val3    val4    ...
 ...     ...      ....   ....

Examples for the second are found e.g for pipes, where it would be nice to let the user choose a "nominal diameter" and a "DIN range", and lookup the inner and outer diameter from that. But these values depend on both the nominal diameter and the DIN range.

There are several ways how to handle that.

One could build in first class support for type 2 tables, so that they can be written to the yaml file, and all the mechanics of BOLTS know how to handle them.

Or one could create a separate class for each DIN range. This would separate the problem, and each range has then a type 1 row lookup table, consisting of one row or column of the type 2 table.

Another way would be to to have one of the parameter values actually be a vector of values, and then use only one of these values depending on the col key. This selection would need to happen in the model, and while it is doable in OpenSCAD and FreeCAD, it would be very kludgy.

I thought this last approach would be clever, but the more I think about it, the less I like it.

[DaleDunn]

That does sound a lot like my socket head cap screw example, where both a diameter and length are required to make a selection. Sometimes pitch is required too (even for metric), so that would be a 3 dimensional example.

[jreinhardt]

I think we differ a bit in what we refer to as n-dimensional tables. And there are three distinct concepts of tables

1) The diameter, length and pitch are what I call "free" parameters in BOLTS. The user specifies the free parameters (like length and diameter), and from that we can get everything else (like socket depth, head length, but also things like parts of the part name). Even with the current infrastructure a class can have arbitrarily many free parameters, but at the moment no class in BOLTS has more than 3. As you said, more than 3 free parameters are very rare.

The step from the free parameters to everything else could in principle be realized by a (number of free parameters)-dimensional table, i.e. for 1 free parameter a list, for 2 free parameters a matrix, for 3 free parameters a cube of entries. Each entry contains values for "everything else".

2) However, this is not what I do. High dimensional tables are cumbersome to write down in files. Ans it turns out that in most cases, each parameter depends only on one free parameter, e.g. the socket depth only depends on the diameter, and is the same for all lengths. In this case we can get away by having one or several 1 dimensional tables (or type 1 as I called them in the previous post), which is much nicer to work with. This is what BOLTS does right now, and it works well in most cases.

There are a few cases where a non-free parameter depends on two free parameters at the same time. Actually only one case: One wants to represent this with 2 free parameters, "nominal diameter" and "DIN range". But inner and outer diameters then depend on both free parameters at once. This issue suggested one particular way of dealing with this, but I do not like the idea anymore. And one can work around the pipe.

3) The third step is building a design table from all that. The design table is a 1 dimensional table, essentially a list of sets of parameters. We can get this by simply taking all (or a subset of all) possible combinations of values for the free parameters and put each in one row of the design table.

I hope this is not causing more confusion, but writing it up certainly helped me to see more clearly.

[DaleDunn]

I've never noticed that most parameters are dependent on a single free parameter. I think that's most likely because I've only had the option to build lists.

What I don't understand is how BOLTS is dealing with 2 free parameters right now. When I look at something like ISO4017 hex head screws, I see a list with diameter as the only free parameter. There is no length data other than "l=20" in the incantations section. For pipes I see OD, but not DIN range.

[jreinhardt]

I think the reason why most parameters are dependent only on a single free parameter is, that it is easy to tabulate the parameters, which you need to do also in print.

For ISO4017 none of the other parameter depend on l, so there is no table necessary that finds the value of a parameter depending on the value of l. l is the most simple kind of free parameter, because it doesn't affect anything else than itself.

For pipes the reason that there is only OD is that currently there is only a single DIN Range, namely 2. There are others, but not in BOLTS. If one includes the other ranges, then one either has to work around or handle the two parameter dependencies. In OpenSCAD incantations these two possibilities would be

DIN11850_Range_2(dn=10, l=500);
DIN11850_Range_1(dn=10, l=500);

or

DIN11850(dn=10,l=500,range=2);
DIN11850(dn=10,l=500,range=1);

The first one is possible right now, because the range is not a free parameter, the second one would need some kind of "type 2" table lookup. The second one is a bit nicer, but considering that there are not many different ranges, the first one is also not so bad.

But in the end I guess such cases very rare, so I am tending to not implement anything, but work around it. If there turns out to be more demand for two parameter dependencies, then I can still implement it, without much impact on the rest of BOLTS.

[DaleDunn]

I don't think I can agree that this is rare. Every kind of screw, bolt, nail, rivet, etc. have both a nominal diameter and a length. Also plain bearings, bushings and a large variety of pins. While the length parameter for most of these (not all) have no dependent parameters, there needs to be a way to generate all the combinations. If SolidWorks design tables don't contain the common combinations of diameter and length, then BOLTS on SolidWorks will be crippled. I would think the same would be true for STEP and IGES implementations, and maybe FreeCAD (I don't know what FreeCAD usage looks like).

I don't think we should ask the users to manage or add length parameters when the "type 2" table can be used to generate a very complete set of combinations. With all the combinations generated, it should be rare for a user to need to add a new length to a model. With only one length generated per size, it will be frustratingly common. That's been my experience with component libraries in the past.

So, please implement the "Type 2" table, even though the value generated from each combination of parameters will usually only describe whether or not that combination should exist. Tables of available lengths are published in catalogs, so populating the tables shouldn't be difficult.

[jreinhardt]

Don't worry, the "type 2" tables really are a very rare case.

The tables in the blt file essentially describe a mapping from free parameters to all parameters. You give it value for the length and diameter, and it gives you back the length, the diameter, the socket depth, the name, the head diameter, ...

FreeCAD and OpenSCAD only need this mapping, as the parts are created on the fly from the input of the user.

For SolidWorks and IGES, we need to settle on a certain set of parameter combinations. For this the blt file also has a section to write down common free parameter combinations. An example is here:

https://github.com/jreinhardt/BOLTS/blob/master/data/hex.blt#L166

This notation allows to write down a subset of the square or cube or hypercube of possible free parameter combination in a very compact way. I have blogged about that here, with examples and more detailed explanations:

http://jreinhardt.github.io/BOLTS/2013/11/29/BLT-file-progress.html

To come back to "type 2" tables. They are only needed if the mapping between free parameters and all parameters is difficult in the sense that a parameter value depends on two free parameters, not just on one. And the pipe case is the only case where I have seen that. All the bolts and nails and rivets that I have seen for know should work with the current infrastructure.

By the way, I managed to finish the IGES backend:

http://jreinhardt.github.io/BOLTS/2014/01/07/IGES-backend.html

The BOLTS for IGES distribution can be downloaded here:

http://jreinhardt.github.io/BOLTS/downloads.html

There you can also check out all the common combinations for e.g. ISO4017.

[DaleDunn]

Ah, that is exactly what I wanted to do. It looks as though I have more reading to do to learn my way around.

Of course, all day long today, when I look something up in a catalog, I'm looking for something that requires the "type 2" tables to control dependent parameters. Just a few minutes ago I ran across a candidate, which is why I looked in on GitHub. These Norelem "Locking Cylinders" (http://www.norelem.com/xs_db/DOKUMENT_DB/www/NORELEM/DataSheet/en/03/03153_Datasheet_2666--en.pdf) are specified by diameter and plate thickness, and the actual length of the pin is different depending on plate thickness. The example is weak however, because the length appears to be a simple offset from the plate thickness. Also, the part is not covered by a standard I know of and Norelem already provides models.

Well, as you concluded a few posts ago, this need not be implemented now. Don't let me keep you from closing the issue.

Edit: Replying directly from Gmail makes ugly comments.

[jreinhardt]

In this case one could also use the order number as free parameter, and then the table from the datasheet could be used directly.

I will move this issue to my "In the far future or when needed" milestone.

Thanks for being a sparring partner in this discussion. As usual, one understands the problem much better, when one tries to explain it. I certainly gained some insight today.

[jreinhardt]

I was thinking a bit about #71 when I realised, that thread pitches are a textbook example of "type 2" tables. One wants to lookup the pitch for a metric thread, which depends on both the diameter and the thread type (i.e. coarse, fine I-IV):

http://almetal.nl/en/techinfo/gti/ticm.htm

So after all, I might implement it

[DaleDunn]

Haha, yes. Not only pitch, but major and minor diameters for male and female forms, etc. (SolidWorks and other commercial CAD systems have a "cosmetic thread" feature that allows schematic representation of threads in drawing views, so any fastener or threaded feature needs both major and minor diameter data, along with thread length.) I've built such a table of thread data for work, but it's not mine to contribute. I was lazy about attribution anyway, so I have no idea where the data came from or what standards were referenced. Not complete, either. I can add such tables to my to-do list, but I don't know where to put it when done.

Since each combination of diameter and type identifies more than one piece of data (pitch, major, minor, etc.) we have the question again of how to structure the data. Should there be a separate lookup table for each of pitch, major, minor, etc., or should they be in a single table with diameter and type combined in a single key for rows of pitch, major, minor, etc.?

[jreinhardt]

At the moment I prefer to have a separate type 2 table for every quantity.

I want to have a mechanism to have such tables globally available (see #71). Otherwise this leads to duplication in many places, which is a mess. In this context I stumbled about a few interesting ideas how to make the parameter system more powerful, but this will need more thought and work and experimentation.

[DaleDunn]

I think I agree with the preference for separate tables. After posting my comment, I began thinking about how it is probably a bad idea to create a new key that is really a combination of two others.

[jreinhardt]

I just merged support for type 2 tables. For an example see https://github.com/jreinhardt/BOLTS/blob/master/data/hex.blt#L91