Multiple thread starts

[adrianschlatter]

threadlib currently does not support multiple thread starts but it would be nice to add the capability. This would enable the addition of PCF-33P-1 thread (#26, #27). Most probably there are other thread types with multiple starts although it does not seem to be common.

ToDos

• extend THREAD_TABLE by a column N_THREADSTARTS or similar
• modify module thread() with multiple-thread-start capability
• decide on meaning of "turns" parameter: number of pitches or number of leads? Given the name, leads is probably more intuitive
• existing personal THREAD_TABLEs ("table" argument) are endangered to become incompatible (they are missing the new column):
  • modify function thread_specs to add this column if it is not there (defaulting to 1)
  • preferably, the function also gives a deprecation warning
  • risk: Can these be done inside an OpenSCAD function?
• build scripts have to be modified (simple)
• tests have to be adapted (maybe restricted to parse() inside test_table.awk)
• documentation: DesignOfThreadlib.md

[zaped212]

Just a thought about this.
I think you could mitigate the concern around existing personal THREAD_TABLEs by using the len() function.

I havent looked at your code directly yet, but I presume you have a public API that is essentially parsing user input and then sending that to a private worker function to do the work on the thread params.

If true, then it seems like it would be pretty easy to extend your internal table to include the # starts column, and then when you go to pass that information back to the private function you first check if the number of starts is provided for that thread profile, else you default to 1. and possible kick off a warning.

pseudo code concept:

table = [ A, B, C, D ];
search for thread C profile.
profile = C // [ name, ..... , ... , ... , num starts ] or [ name, ..... , ... , ... ] if num starts is not specified.
num_starts = 1; // quick assignment to default value
if( len( profile ) == max_profile_len )
{
num_starts = profile[x];
}
private_function( ......... )

[adrianschlatter]

I'd have to look into that. What makes life a bit nasty is that OpenSCAD apparently allows only a single statement inside a function. As far as I understand, you cannot lookup first, then decide.

The current code is this:

function thread_specs(designator, table=THREAD_TABLE) =
/* Returns thread specs of thread-type 'designator' as a vector of
[pitch, Rrotation, Dsupport, section_profile] */

table[search([designator], table, num_returns_per_match=1,
               index_col_num=0)[0]][1];

[alainchiasson]

I have not looked at the code, so I'm not sure this would work for functions ( Recall them not being very friendly .

I have seen either extenttion blocks at the end as well as version information. The version information is more future proof. It's too late to do that since you already have a structure, but - if you add the version as the last parameter, and you make it obvious ( v1 ), entry without it is assumed v1/v0.

There are two slippery slopes:

• It makes it too easy to pile on features, that maybe should not be there ( lets just make a new version )
• You may endue with "Dead Info" fields. unused in most cases, but you still need to deal with it.

Thinking about that last one - maybe the "version block" can contain some type of "structure" that describes the blocks ( thread+multi ) - but again, this is an increase in complexity.