When designing around hardware, you will often find yourself importing a reference step (.step or .stp) file into FreeCAD. Usually these step files are publicly available and use of these step files is encouraged by the manufacturer to make inclusion of their products in your designs easier. Sometimes, however, the supplier may not make their step files publicly available, and only provide them upon request, or even explicitly ask you not to share this with any other party. Integrating them into an Open Hardware design is still possible, but it requires some consideration.

Goals

We assume we have some ‘proprietary step’ file that we cannot include in our repository, but can still design around. We can assume that in most cases, users may be able to obtain the same step file by asking the manufacturer, but we should provide a fallback – it would be very inconvenient if an external user that is interested in modifying your project would have to wait (and hope) for a reply by a manufacturer before they can get started with your design.

Ideally, we want to: 1) Have the full complexity of this proprietary step file available during our design process. We may not be able to distribute it, but we can and should use it if we have it. 2) Have a workable fallback option that can tie a user over if they cannot obtain the full step file 3) The fallback should be able to integrate the full step file if the user can obtain it.

A relatively simple way to achieve this in FreeCAD is by adhering to the proposed steps below:

1. For each properietary external step file, create a separate FreeCAD file (as an example: ext.FCStd). Keep the original .step file close.
2. In this file, create a Part container (with name matching whatever proprietary part it is modelling) and within the part create a ‘placeholder’ PartDesign object.
3. In this file import the proprietary step file. It should part of the Part container – you can add it by dragging it.
4. Using Sub-Shape Binders, have your placeholder be a coarse proxy for the proprietary step file. Have it contain all the important elements (e.g. fastener points that you will use in your design)
5. In your main design, always reference the Part container, never the Part Design placeholder or the step directly.

The main thing to make sure is to avoid committing ext.FCStd with the imported step geometry inside to git. That means, when you are done with (4), you would have to delete the imported step geometry, commit ext.FCStd, and then re-import the step file to ext.FCStd (and make sure it is included in the Part container) to be able to view the full step file in your design again.

If you ever need to update your placeholder, you can just make the changes to the placeholder based on the re-imported step geometry (e.g. creating new Sub-Shape Binders) and then delete the step geometry again before committing changes to ext.FCStd. After commiting, re-import the step file to get the full geometry instead of just the placeholder.

It is not a super convenient workaround; there is a peristent risk that you accidentally commit the version of ext.FCStd with the step geometry inside it.

If you are sure you are not likely to make changes to the file, you can tell git to stop tracking changes to it with git’s update-index command:

git update-index --no-assume-unchanged <path/to/ext.FCStd>
# track changes again with `git update-index --no-assume-unchanged ...`

That way, you won’t accidentally stage it with git add ..

For users of your repo, when they clone it they will only have access to the placeholder objects which should have all the relevant datums and coarse shape, enough to work with. You should add some documentation that tells the user where they can request the step file and where they should place it. Once obtained, the user can import the step file in ext.FCStd and drag it into the Part container, and be good to go!

Closing Thoughts

I don’t love this workflow, but I think it is a workable solution that will not throw an error when loading the repository without the step file. I think the ergonomics can be improved significantly. If you have ideas, I’d love to hear about it.

Alternative options:

1. Remove the external step geometry from the git repo with a pre-commit hook. This probably also needs a post-commit hook to again re-insert the step data. Quite fragile because it depends on the internal step name in ext.FCStd
2. Add the proprietary step file to a another separate file in another Part container and import that Part into the Part container described above. This solves the accidental commit risk, but it means the user will always get an error when loading the design without the .step file on their system.