BOLTS, a standard parts library for OpenSCAD and FreeCAD

I thought I answered this this morning. Maybe I forgot to press "post". Here I Go again:

Last weekend I downloaded a clone and got to work trying to understand everything. I have nut.sldprt and .base files, but I didn't get as far as getting BOLTS to generate output based on them. I have Python and the relevant dependencies installed, I just ran out of time learning how to actually get BOLTS to generate a spreadsheet for SolidWorks use. Any pointers would be helpful. I also didn't figure out all of parameters in the .base file. Documentation for OpenSCAD and FreeCAD .base files only took me so far.

Or is it simply too early for me to be able to generate a SolidWorks release from BOLTS? Should I focus on a particular task first?

Edited 1 time(s). Last edit at 01/10/2014 01:02PM by Dale Dunn.

Hi again

it is not too early, actually the timing is pretty good, I wanted to do another release in the next few weeks. This means we have a bit of time to get the solidworks part running smoothly, but can have a release then.

The SolidWorks backend is not really thoroughly tested, and the little, existing documentation is well hidden. So I am not surprised that you didn't succeed. But I hope we can figure this out together.

I can not give precise hints, because I do not know where exactly you hit a roadblock, and how your files look. Maybe you can publish your BOLTS branch on GitHub, then I can see what you got. And a few questions: How well do you know git? And how well do you know python? What operating system do you use?

Until then a few general hints:

The BOLTS repo contains everything, i.e. the parts data, the models and all the code that operates on them. A quick overview over the directories:

* bolttools contains code to parse blt and base files
* backends contains code to generate output of a certain form from the data
* data contains the blt files
* freecad, openscad and solidworks contain models and base files that live in subfolders for each collection
* drawings contains drawings and base files that live in subfolders for each collection
* output contains the results of a backend export
* downloads contains all releases
* icons contains a few icons

So you are probably mainly concerned with the data, solidworks and output folders.

To use all the machinery from bolttools and backends a commandline application is provided: bolts.py. See also here: [jreinhardt.github.io]

The first step is to put the base and sldprt files into the solidworks folder in a subfolder with the name of the collection, i.e. nut.

Then you can run "python bolts.py export solidworks". Then BOLTS tries to generate design tables for all parts for which it has sufficient informations. The result is placed in the output/solidworks folder.

For the .base file parameters, there is a (very short and technical) description of all the possible fields in bolttools/doc/blt_spec_0_3.rst or here:
[github.com]


Greetings

Johannes

A few more things:

* the .base file has to have the same name as the directory it is in, i.e. nut.base
* the .base file that I posted earlier in this thread is not valid and crashes with uninformative error messages (I will fix that). You need to supply a email address for the author and a url for the licence in <>.

Thanks, I think that will help immensely. I got as far as figuring out that BOLTS is a command-line tool, and even did "./bolts.py --help" to convince myself that I had the install correct.

I'm on Win7, I can't write Python (though I might be able to read it slightly), and I barely know Git. I think I understand fork, commit, pull, pull request, and the reporting of issues. So I was well satisfied when ./bolts.py --help actually worked!

In the morning, I'll work out what it means to "publish" a branch. Is it anything more than fork, clone locally, edit, commit, and push to my fork? A pull request to let you know I've done it?

I think you have correctly deduced which parts of this project I will mainly be concerned with. I won't be able to make any significant contribution to [*].py other than to report issues and offer endless opinions on what it should do. I think I can mainly contribute by adding data and SolidWorks models.

Quote
Dale Dunn
In the morning, I'll work out what it means to "publish" a branch. Is it anything more than fork, clone locally, edit, commit, and push to my fork? A pull request to let you know I've done it?

I think you have correctly deduced which parts of this project I will mainly be concerned with. I won't be able to make any significant contribution to [*].py other than to report issues and offer endless opinions on what it should do. I think I can mainly contribute by adding data and SolidWorks models.

With publish I meant to have your modified clone somewhere where I can look at it, probably on GitHub. GitHub has relatively good documentation about how to do that. A pull request is a good idea at some point, but maybe not yet.

I am very happy if you add data and SolidWorks models. I tried to design everything so that this is possible to do that without detailed knowledge of the *.py machinery, and we will now see to what degree I succeeded.

Another thing that will be necessary, and that I can not do, is to write documentation about how to use BOLTS for SolidWorks. The Documentation in general needs to be improved, it is often too technical and too cumbersome and not well structured. So if you have comments and suggestions for the documentation, please tell me.

I figured a SolidWorks user's supplement would eventually become necessary. I should be able to make some contribution there, but I'll wait until I have some idea what I'm talking about.

OK, I've worked through the GitHub processes to fork, clone, edit and sync to my repository. I added files for nuts to my repository here. It should be visible as a fork of BOLTS as well. Please feel free to open issues for items you need from me to proceed.

I also did this:

c:\Python27>python C:\0Home\GitHub\BOLTS\bolts.py export solidworks
Traceback (most recent call last):
File "C:\0Home\GitHub\BOLTS\bolts.py", line 249, in
args.func(args)
File "C:\0Home\GitHub\BOLTS\bolts.py", line 71, in export
repo = BOLTSRepository(args.repo)
File "C:\0Home\GitHub\BOLTS\bolttools\blt.py", line 44, in __init__
raise e
bolttools.errors.MalformedRepositoryError: No data directory found. Repository
path: c:\Python27

I also tried to export openscad with similar results, so I think it's probably a problem with my install rather than something in the SolidWorks backend. Or perhaps I need to specify a path somewhere.

I'll keep generating models for now.

Edited 1 time(s). Last edit at 01/11/2014 11:03PM by Dale Dunn.

Got it. I needed to add python to my path so I could run it from the BOLTS directory. I failed to glean that from the "How to use a development checkout" page.

How should backwards compatibility be dealt with? With few exceptions, SolidWorks files are not compatible with older versions of the software. It's not at all unusual for users to be using older versions. I have a customer who requires SolidWorks 2011 files, when I'd rather be working with SolidWorks 2014. So, I work in 2011. That's what I'm using for BOLTS at the moment, being aware of the backwards compatibility issue.

I would think that for a particular release of BOLTS there should be a target version of SolidWorks. Deciding which version should be targeted will depend on features we want available in BOLTS. Right now, the design tables created by BOLTS are compatible with SolidWorks versions so old they wouldn't run on XP. The model files themselves may have some features in different versions, and that needs to be evaluated.

Once I have a handle on BOLTS, I expect to bring it to the attention of the SolidWorks forums to see if anyone there wants to contribute models and data. Once others get involved in contributing models, there will need to be some way to communicate which version of SolidWorks is targeted for the next release. (I'm sure other users will have input on which version to target as well. Maybe even contribute SolidWorks macros to automate adding design tables to model files.)


At what point should we take this conversation out of the RepRap forums?

Edited 1 time(s). Last edit at 01/11/2014 08:45PM by Dale Dunn.

I'm experimenting with metadata, and I need to be able to add more than the key and columns. I need to be able to add description and standard as metadata.

Unless we append units to every number the params put in a design table, we will need separate model files for inch and metric hardware. Perhaps convert units on export to standardize on mm in the design tables? I would prefer separate model files for different units.

Do parameters need to be a data type that includes units? It's not inconceivable that some standard specifies cm or m for something is it? Some data might even be given in µm or µin.

I see you've given units some thought already. How do you plan to manage this? Split the output directories into inch and mm and use different .base files referencing different classes in the .blt?

Edited 3 time(s). Last edit at 01/11/2014 11:00PM by Dale Dunn.

You have been very busy!

Quote
Dale Dunn
OK, I've worked through the GitHub processes to fork, clone, edit and sync to my repository. I added files for nuts to my repository here. It should be visible as a fork of BOLTS as well. Please feel free to open issues for items you need from me to proceed.

This will be very useful. I never have used git to work with someone who was not in the same room, so we might need to figure out how to do this.

I had a look at your commits so far, and they look good. A common problem for people new to version control is that they commit too rarely and too many things at once. But you got it right, and also have good commit messages, which is very important when dealing with binary files.

Quote
Dale Dunn
How should backwards compatibility be dealt with? With few exceptions, SolidWorks files are not compatible with older versions of the software. It's not at all unusual for users to be using older versions. I have a customer who requires SolidWorks 2011 files, when I'd rather be working with SolidWorks 2014. So, I work in 2011. That's what I'm using for BOLTS at the moment, being aware of the backwards compatibility issue.

I would think that for a particular release of BOLTS there should be a target version of SolidWorks. Deciding which version should be targeted will depend on features we want available in BOLTS. Right now, the design tables created by BOLTS are compatible with SolidWorks versions so old they wouldn't run on XP. The model files themselves may have some features in different versions, and that needs to be evaluated.

I would propose to have different distributions for different version of SolidWorks. The user would download something like BOLTS_SolidWorks_2011_0.3.zip or BOLTS_SolidWorks_2014_0.3.zip. For that I would need to adapt the base file format, so that the version of the model file can be specified. The distribution would then only include parts for which model files are available.

The advantage of this approach would be that it makes BOLTS useful for a large audience. The downside is that developer time is spread out over several versions, but I guess it is not so difficult to convert a model from one version to another (open, save as cycle?).

Quote
Dale Dunn
Once I have a handle on BOLTS, I expect to bring it to the attention of the SolidWorks forums to see if anyone there wants to contribute models and data. Once others get involved in contributing models, there will need to be some way to communicate which version of SolidWorks is targeted for the next release. (I'm sure other users will have input on which version to target as well. Maybe even contribute SolidWorks macros to automate adding design tables to model files.)

At what point should we take this conversation out of the RepRap forums?

Cool, I would like to have many people contribute models.

I would wait a bit until we have ironed out the biggest problems, settled on a process and have a few parts available, so that it is a bit more than a proof of concept.

I want to start advertising BOLTS more aggressively after the next release, so this might be a good time.

Quote
Dale Dunn
I'm experimenting with metadata, and I need to be able to add more than the key and columns. I need to be able to add description and standard as metadata.

I am not sure I understand. You can work with all parameters provided by the class, which are listed below the drawing in the online documentation:
[jreinhardt.github.io]
If you want to add more, you can add it to the blt file.

The description and standard are class properties, so all variations of a class would have the same value for this field. I am not sure how useful that is.

Quote
Dale Dunn

Unless we append units to every number the params put in a design table, we will need separate model files for inch and metric hardware. Perhaps convert units on export to standardize on mm in the design tables? I would prefer separate model files for different units.

Do parameters need to be a data type that includes units? It's not inconceivable that some standard specifies cm or m for something is it? Some data might even be given in µm or µin.

I see you've given units some thought already. How do you plan to manage this? Split the output directories into inch and mm and use different .base files referencing different classes in the .blt?

Good point. That requires some thought.

BOLTS knows about the units of the parameters in the blt files, but currently does not use this when exporting to a design table. Currently BOLTS assumes that a parameter is a length given in mm, unless stated otherwise (like e.g. [github.com]). It should be not a problem to add other units if needed.

Can Solidworks read units from designtables? And can you mix parts from designtables with metric units with parts from designtables with imperial units?

I am thinking about a possibility to specify the unit per model in the base file. This way a model can be designed in a whatever unit the designer is comfortable with, and BOLTS can convert the numbers on export. Or is this becoming too flexible?

I am a bit reluctant to have different models for each unit. The model files will be essentially identical, so if a change is made to the class it has to be applied manually to each unit (potentially for each version of SolidWorks). This has a lot of potential to forget to change something and introduce bugs and inconsistencies.

SolidWorks version compatibility:

You have correctly guessed the process for moving a SolidWorks file to a newer version: just open and save using the new version. With the small files in a BOLTS distribution, the update process will be effectively transparent when the file is opened to add the design table.

Because the update is so easy, I don't think it will be worthwhile to maintain separate BOLTS distributions unless we identify a feature of a newer version of SolidWorks that merits the effort. Right now, I don't know of anything that merits maintaining multiple releases. The kind of model features we need for BOLTS have been stable in SolidWorks for over a decade. The only thing differentiating different versions (for our purposes) is which versions of SolidWorks can open the files.

What I propose is to target the earliest version that is supported on current platforms (Win7/8). The earliest version of SolidWorks supported on Win7 is 2010. Unfortunately, that means anyone who wants to contribute to BOLTS will need to install SW2010. But it would always be the case that a contributor would need to install an old version in order to support anything but the very latest release.

Description and standards metadata:

It didn't occur to me to add description and standards parameters to the .blt files. For many classes, that will result in the same data for each key. But not for all. Yes, I think this is the correct thing to do.

Units in design tables:

I've run out of time to write on this today. I'll try to get to it tomorrow.

Metadata character case:

Some drawing standards require a particular character case. In particular, ANSI/ASME specifies that all text on a drawing is all upper case unless otherwise required (Hz, McMASTER, etc.). What this means is that metadata inserted into a design table for use in ANSI/ASME drawings needs to be upper case. Would it be at all difficult to implement different capitalization options for export? Or would it be better to consider this part of the translation issue and maintain separate .blt files for each translation?

Quote
Dale Dunn
SolidWorks version compatibility:

You have correctly guessed the process for moving a SolidWorks file to a newer version: just open and save using the new version. With the small files in a BOLTS distribution, the update process will be effectively transparent when the file is opened to add the design table.

Because the update is so easy, I don't think it will be worthwhile to maintain separate BOLTS distributions unless we identify a feature of a newer version of SolidWorks that merits the effort. Right now, I don't know of anything that merits maintaining multiple releases. The kind of model features we need for BOLTS have been stable in SolidWorks for over a decade. The only thing differentiating different versions (for our purposes) is which versions of SolidWorks can open the files.

What I propose is to target the earliest version that is supported on current platforms (Win7/8). The earliest version of SolidWorks supported on Win7 is 2010. Unfortunately, that means anyone who wants to contribute to BOLTS will need to install SW2010. But it would always be the case that a contributor would need to install an old version in order to support anything but the very latest release.

Can newer version save in old file formats? Something like "Save as" -> SW2010?

Targeting only one version requires a difficult tradeoff:
* BOLTS is usable for everyone with the targeted version or newer, so to maximise audience one should target a maximally old version
* Contributors need to have the targeted version or older, so to maximise contribution one should a maximally young version
You mentioned that the userbase is spread out over many versions, which makes this tradeoff even more difficult. Are there many people using versions older than SW 2010? Also this tradeoff changes over time, as people switch to newer versions.

On the other hand, keeping track of model file versions would allow to accept contributions from everybody, and build distributions for different versions with all models that are compatible with this version. This could be automated. But
* which model to use if there is more than one compatible?
* this leads to many more files that need to be maintained manually.

I am not sure what is the best way to handle this.

Quote
Dale Dunn
Description and standards metadata:

It didn't occur to me to add description and standards parameters to the .blt files. For many classes, that will result in the same data for each key. But not for all. Yes, I think this is the correct thing to do.

For which classes will be description and standards not be the same for each key?

Quote
Dale Dunn
Metadata character case:

Some drawing standards require a particular character case. In particular, ANSI/ASME specifies that all text on a drawing is all upper case unless otherwise required (Hz, McMASTER, etc.). What this means is that metadata inserted into a design table for use in ANSI/ASME drawings needs to be upper case. Would it be at all difficult to implement different capitalization options for export? Or would it be better to consider this part of the translation issue and maintain separate .blt files for each translation?

Hmm. Do you mean something like a "capitalize" field in the base file? And the best I can do automatically is to capitalize everything, so the special cases would not be covered.

Quote
jreinhardt
...
Good point. That requires some thought.

BOLTS knows about the units of the parameters in the blt files, but currently does not use this when exporting to a design table. Currently BOLTS assumes that a parameter is a length given in mm, unless stated otherwise (like e.g. [github.com]). It should be not a problem to add other units if needed.

Can Solidworks read units from designtables? And can you mix parts from designtables with metric units with parts from designtables with imperial units?

I am thinking about a possibility to specify the unit per model in the base file. This way a model can be designed in a whatever unit the designer is comfortable with, and BOLTS can convert the numbers on export. Or is this becoming too flexible?

I am a bit reluctant to have different models for each unit. The model files will be essentially identical, so if a change is made to the class it has to be applied manually to each unit (potentially for each version of SolidWorks). This has a lot of potential to forget to change something and introduce bugs and inconsistencies.

Units in design tables:

SolidWorks units work like this: The modeling kernel does everything in meters, but each file has a default units setting that SolidWorks will use to present quantities to the user (also for angles, mass, etc.). When a design table is added to the model, SolidWorks assumes the quantities in the table are in the model's default units. The design tables can contain and pass units to the model file, but the model will present the quantities to the user in the default units after conversion. A design table can pass different units for each quantity. SolidWorks will convert everything on import, or assume the default units if the table does not specify.

I spent some time thinking about allowing a contributor to build a model in any units, as long as they're specified in the base file. Setting the default units for a model file is almost trivially easy. I don't think it will be a burden to allow a contributor to model a part in whatever units, then set the units to mm before pushing.

If the design table includes units with every quantity, it shouldn't matter. SolidWorks will do the conversion when the table is imported. Then we just need to be sure the units are presented in a way SolidWorks understands (all the common abbreviations seem to be supported, spaces between numbers and units are optional but more readable). We may also need to be aware of whether decimal degrees are specified or degrees, minutes and seconds. Is this option the most similar to how other CAD systems are supported?

If BOLTS can specify the units for each quantity in the design table, I think we will have a good solution and correct geometry in every model.

Ok, that is nice. It seems that is well doable.

I have now a branch where I will keep track of your work and add experimental stuff:

[github.com]

I just added some code that adds the units to the design table. I hope that works, as I write strings to the spreadsheet instead of numbers. Can you test that?

Edited 1 time(s). Last edit at 01/13/2014 03:05PM by jreinhardt.

Quote
jreinhardt
Can newer version save in old file formats? Something like "Save as" -> SW2010?

Targeting only one version requires a difficult tradeoff:
* BOLTS is usable for everyone with the targeted version or newer, so to maximise audience one should target a maximally old version
* Contributors need to have the targeted version or older, so to maximise contribution one should a maximally young version
You mentioned that the userbase is spread out over many versions, which makes this tradeoff even more difficult. Are there many people using versions older than SW 2010? Also this tradeoff changes over time, as people switch to newer versions.

On the other hand, keeping track of model file versions would allow to accept contributions from everybody, and build distributions for different versions with all models that are compatible with this version. This could be automated. But
* which model to use if there is more than one compatible?
* this leads to many more files that need to be maintained manually.

I am not sure what is the best way to handle this.

A fully licensed SolidWorks user may download and install older versions. So, anyone wishing to contribute to the maximally old version will be able to do so if their OS allows it. One catch is that some users will be using Win8 now. Win7 supports SW2010, and Win8 begins with SW2013. It may make sense to target a specific OS rather than a specific SolidWorks version.

I just checked the download web site, and 2011 is the oldest version currently available. This may be a limitation of support from SolidWorks, similar to the way WinXP is about to exit extended support from Microsoft. Anyone wishing to contribute older version files will need access to physical install media. I don't think there is any published data on what people are using, but I think there are very few users who are not within a few versions of the latest.

This is indeed a thorny question. If we allow contributions in any version, and request the oldest possible from each contributor, the library will grow at the fastest rate. In the space of 3 years, I think almost all users will be using a version new enough for almost anything contributed in the near future. If a user needs something from an older version of a model than is available, it should be only a moderate effort to make a new model in the required version and apply the design table. In my experience, compiling the data is by far more effort than building the model. When I first read of BOLTS, I was excited just by the idea of tabulated data.

Quote
jreinhardt
For which classes will be description and standards not be the same for each key?

I'm thinking of set screws. The description will change depending on the point style. Hex socket set screw, cone point, hex socket set screw, flat point, etc. For standards that might change for each key, I don't have an example ready. I'm not sure I've ever seen it, other than a suffix for a subsection of a standard. But I do need a way to add the standard as metadata so it can be pulled into a BOM. The only way to do that via design table is to include the standard with each key.

Quote
jreinhardt
Hmm. Do you mean something like a "capitalize" field in the base file? And the best I can do automatically is to capitalize everything, so the special cases would not be covered.

The special cases are what I'm not sure how to handle. That's why I thought maybe it should be considered a translation issue. BTW, it seems the "type 2" tables might be useful here (this forum doesn't handle tables well):

key...................ANSI English.............DIN Deutsche.....ISO Français.......JIS katakana(?)
description ........DESCRIPTION...........Beschreibung.....Description..........説明
set screw..........SET SCREW.............Stellschraube.....la vis de réglage...ネジを設定する

Edited 1 time(s). Last edit at 01/13/2014 04:28PM by Dale Dunn.

Quote
Dale Dunn
I'm thinking of set screws. The description will change depending on the point style. Hex socket set screw, cone point, hex socket set screw, flat point, etc. For standards that might change for each key, I don't have an example ready. I'm not sure I've ever seen it, other than a suffix for a subsection of a standard. But I do need a way to add the standard as metadata so it can be pulled into a BOM. The only way to do that via design table is to include the standard with each key.

I looked up set screws, and I think I understand the problem.

With set screws the situation is a bit confusing, because DIN and ISO seem to have separate standard numbers for different point types, while ANSI seems to have one for all types.

As a general rule one should collect only identical standards into one class. So DIN 913 and ISO 4026 are identical, they can go in one class. ANSI B18.3.6M contains all different point types, while the DIN and ISO standards have separate numbers for that.

So one would have five different classes

hexsocketsetscrewflat [DIN913, ISO4026]
hexsocketsetscrewcone [DIN914, ISO4027]
hexsocketsetscrewdog [DIN915, ISO4028]
hexsocketsetscrewcup [DIN916, ISO4029]
hexsocketsetscrewall [ANSI B18.3.6M]

Also the free parameters are different. While the first four classes have the diameter and the length as free parameters, the last one has diameter, length and point type.

This would prevent us from having all these classes in one design table (for SW) or share a geometry (for freecad and openscad), because the first four classes miss the point type parameter, because it is implicit in the class. To make this parameter explicit, one could add a literal parameter for that. Literal parameters are parameters that have the same value for all parts of class.

Now all five classes have the same set of parameters, so a design table cam pull in all five of them.

To find a way to cleanly map the situation on the structures that can be expressed in BOLTS is not easy. And I am sure there are situations that can not be described in BOLTS.

I have started to add set screws to the hex_socket.blt file in my solidworks branch. I used data from [www.fullermetric.com] Maybe you can try add the remaining point types and the class for the ANSI standard.

Edited 1 time(s). Last edit at 01/13/2014 06:18PM by jreinhardt.

I'll try to get that done this week. I'm building a quite a to-do list.

Quote
jreinhardt
Ok, that is nice. It seems that is well doable.

I have now a branch where I will keep track of your work and add experimental stuff:

[github.com]

I just added some code that adds the units to the design table. I hope that works, as I write strings to the spreadsheet instead of numbers. Can you test that?

I almost missed this post.

Yes I can test that. It should work, since I've done the same thing manually entering units in design tables.

I have a Git question. If I clone your solidworks branch to my desktop, changes you make will be tracked and updated? I'm not sure of the best way to keep a current copy of that branch for testing. Or should I be doing all my work with your solidworks branch upstream of my master?

I have your repo set up as a remote

git remote add daledunn [github.com]

whenever you make some commits I can fetch them

git fetch daledunn

and then get your current state by

git checkout daledunn/master

or merge it to my solidworks feature branch

git checkout solidworks
git merge daledunn/master

You could do the same with my solidworks branch, and merge it to your master if I have added something that you want to have.


For git questions I find this book extremely useful: [git-scm.com]

Edited 1 time(s). Last edit at 01/15/2014 10:27AM by jreinhardt.

Oh, it's downstream from my fork. I totally missed that.

I will need to pull your experiments from there? For example, I'm not sure if the units in design tables code is in your master branch or solidworks branch.

Thanks for the link. I've found that book a few times while searching for answers. I was so focussed on finding answers that I didn't notice what it is. I need to take the time to read that. I'm stumbling along so far, and I really need to make sure I have the big picture of Git and fill in a lot of missing details. That looks like the reference I need. I don't think it was available two years ago when I first tried using Git.

Edited 1 time(s). Last edit at 01/15/2014 10:50AM by Dale Dunn.

The units stuff is in my solidworks branch.

OK. I won't be able to test until tomorrow evening.

You seem to excel at giving me tasks that require me to fill in the vast holes in my GitHub skill set. Most likely, I probably still have not achieved competence.

The test with mm units was successful. I have some more work to do to be able to test something with inch units. Specifically, using the key in a configuration name is a problem. The forward slash in the fractional inch thread sizes is not a legal character in a design table. I'll have to replace them with decimal equivalents in the .blt file I'm working with. This might be a problem, because it forces a limitation on the .blt files for all systems, only for the sake of SolidWorks.

Edit:

Successful test adding inch and mm units to SolidWorks configuration data via design tables.

Comments:
1- The forward slash in the fractional inch thread sizes is not a legal character in a design table. I renamed the keys in hexagonnut3 to decimal equivalents and added some thread pitches (much more to be done there)
2- Because of item 1 above, the inch fasteners need "name" metadata column so the size can appear on drawings in the correct fractional form, instead of the decimal form. Why can't we all just use mm?
3- The units were successfully added to the parameters, but they should not appear in the metadata. I apologize for not pointing that out earlier. The problem is, the metadata is most likely to appear on a drawing, where the units should only be specified if they are not the default units for the entire drawing (rare). I looked in solidworks.py to see if I could figure out where to change this myself, but had no success.

Edited 4 time(s). Last edit at 01/18/2014 10:49PM by Dale Dunn.

Quote
jreinhardt
...
I have started to add set screws to the hex_socket.blt file in my solidworks branch. I used data from [www.fullermetric.com] Maybe you can try add the remaining point types and the class for the ANSI standard.

I haven't forgotten this. Adding a model and base file for the hex screw took the whole afternoon, and I'm out of time for today. Well, the new files and learning some Python string formatting, merge conflict resolution, inscrutable Python errors, etc.

Sorry, I had missed your answers. I think it is good to keep big picture discussions here. GitHub is somehow not really suitable for general discussions.

Quote
Dale Dunn
You seem to excel at giving me tasks that require me to fill in the vast holes in my GitHub skill set. Most likely, I probably still have not achieved competence.

I hope I am not too demanding. I have to say that I enjoy the collaboration and I think it is going quite well. Git is a beast, I also had my fair share of problems with it. And for using it to collaborate, I am still in the process of figuring out a good workflow. I think the two solidworks branches are a good idea, this allows us to bounce code back and forth and test. Issues seem to be nice for keeping todo lists, but not so much for discussions. And in general I feel that there are too many places where you can comment on stuff, so conversations get too much disconnected.

Quote
Dale Dunn
The test with mm units was successful. I have some more work to do to be able to test something with inch units. Specifically, using the key in a configuration name is a problem. The forward slash in the fractional inch thread sizes is not a legal character in a design table. I'll have to replace them with decimal equivalents in the .blt file I'm working with. This might be a problem, because it forces a limitation on the .blt files for all systems, only for the sake of SolidWorks.

This is not really a problem because this limitation affects other systems. For example the IGES backend can not use forward slashes in filenames. Are decimal equivalents something that people understand (i.e. 0.375 instead of 3/8), or is this too uncommon?

Quote
Dale Dunn
Edit:

Successful test adding inch and mm units to SolidWorks configuration data via design tables.

Comments:
1- The forward slash in the fractional inch thread sizes is not a legal character in a design table. I renamed the keys in hexagonnut3 to decimal equivalents and added some thread pitches (much more to be done there)
2- Because of item 1 above, the inch fasteners need "name" metadata column so the size can appear on drawings in the correct fractional form, instead of the decimal form. Why can't we all just use mm?
3- The units were successfully added to the parameters, but they should not appear in the metadata. I apologize for not pointing that out earlier. The problem is, the metadata is most likely to appear on a drawing, where the units should only be specified if they are not the default units for the entire drawing (rare). I looked in solidworks.py to see if I could figure out where to change this myself, but had no success.

Good that the units work.

1 and 2 - This is a bit a problem in the current infrastructure. I think for solidworks one can work around that pretty well by having a string parameter "size_name" that contains the fractional form, put a extra column in the table and include size_name as metadata in the designtable. But for example in FreeCAD the keys are used in the ui to let the user choose the size he wants. So having the uncommon decimal form there is suboptimal. On the other hand, for filenames (e.g. IGES backend), the common form causes problems.

The imperial system is really quite curious.

3- There is no way the designtable can know about the default units of the drawing, so I guess the best we can do is to omit the units for metadata. I pushed the code to my solidworks branch

Quote

I haven't forgotten this. Adding a model and base file for the hex screw took the whole afternoon, and I'm out of time for today. Well, the new files and learning some Python string formatting, merge conflict resolution, inscrutable Python errors, etc.

I had a bit of time this evening, and I finished the set screw data, also pushed it to my solidworks branch.

Quote
jreinhardt
This is not really a problem because this limitation affects other systems. For example the IGES backend can not use forward slashes in filenames. Are decimal equivalents something that people understand (i.e. 0.375 instead of 3/8), or is this too uncommon?

Quote
jreinhardt
The imperial system is really quite curious.

That's being generous. It's a mess. It's not uncommon for engineers and especially machinists to have decimal equivalents memorised for all the 1/16 and 1/32 fractions, and sometimes even 1/64. Can you imagine reading drawings with dimensions like 47/64"? I've seen it. A few decades ago, engineers stopped using fractions on drawings, but still designed for fractional sizes because all the standard stock and components are available in nominal fractional sizes. (Carpentry is still in whole feet and inch fractions, down to 1/16 for construction. That's right, mixed units for a single measurement. It's all inches when you're actually doing the work, though.)

Continuing the suck, inch hardware has numbered and lettered sizes in addition to the fractional sizes. An "E" twist drill is 0.25". A #10-32 screw thread is 0.19". A "-109" o-ring is Ø0.313 x 0.103. Drill and hardware suppliers gave away free decimal equivalent charts for most of these things, with their advertising on top, of course. In most mechanic's and machine shops, they could be found hanging on the wall within sight of almost any workspace. I see this less often now. The trend is toward using decimals everywhere, even for tapped hole sizes. Fractional sizes for hardware are still used in BOMs though.

That reminds me: Is "#" a legal character in file names? Even if it is, I would want to keep everything in decimal equivalents for ease of use. Something like this: "0.1250-40(#5) x 0.1875" for a #5-40 x 3/16 screw. If for no other reason than to maintain a sane sort order. That's how I've set up my work library.

Quote
jreinhardt
Good that the units work.

1 and 2 - This is a bit a problem in the current infrastructure. I think for solidworks one can work around that pretty well by having a string parameter "size_name" that contains the fractional form, put a extra column in the table and include size_name as metadata in the designtable. But for example in FreeCAD the keys are used in the ui to let the user choose the size he wants. So having the uncommon decimal form there is suboptimal. On the other hand, for filenames (e.g. IGES backend), the common form causes problems.

OK. I'll add "size_name" to my list of things to add. Is there a reason for replacing spaces with underscores?

Quote
Dale Dunn
That reminds me: Is "#" a legal character in file names? Even if it is, I would want to keep everything in decimal equivalents for ease of use. Something like this: "0.1250-40(#5) x 0.1875" for a #5-40 x 3/16 screw. If for no other reason than to maintain a sane sort order. That's how I've set up my work library.

Quote
jreinhardt
Good that the units work.

1 and 2 - This is a bit a problem in the current infrastructure. I think for solidworks one can work around that pretty well by having a string parameter "size_name" that contains the fractional form, put a extra column in the table and include size_name as metadata in the designtable. But for example in FreeCAD the keys are used in the ui to let the user choose the size he wants. So having the uncommon decimal form there is suboptimal. On the other hand, for filenames (e.g. IGES backend), the common form causes problems.

OK. I'll add "size_name" to my list of things to add. Is there a reason for replacing spaces with underscores?

I think # is ok in filename

Spaces are in principle no problem, but I personally find spaces in filenames annoying and dangerous. I work a lot on the command line, and if one uses a filename with spaces as argument to a command line tool, things might go wrong if one forgets to escape or quote things properly. But for the average Windows user this is probably not much of a problem.

I just released version 0.3 of BOLTS. Read more about this release here.

@Dale: Sorry, I have been quite quiet for a long time, but now I will be able to spend more time with BOLTS again. Are you still interested in a SolidWorks version?