STEP features | How to communicate threads via a STEP file?

Quaoar

Administrator
Staff member
I came across the following issue recently. A guy asks how a STEP file could help in the following scenario:
  1. The user uploads a STEP file.
  2. All drilled holes are recognized with some simple AFR approach.
  3. The user selects a couple of cylindrical bores and clicks some buttons to associate threads with them.
  4. Now that we know holes with threads, we need to save this whole data to a STEP file so that a CAM system (like the CAM module of Fusion360) can read these threads.
I haven't checked it precisely, but I heard that the STEP format is capable of communicating features. Has anyone ever tried to exploit these capacities of the STEP format? What about threads? Does anyone have any practical experience in communicating threaded holes other than modeling them explicitly?
 

DanB

CAD community veteran
I came across the following issue recently. A guy asks how a STEP file could help in the following scenario:
  1. The user uploads a STEP file.
  2. All drilled holes are recognized with some simple AFR approach.
  3. The user selects a couple of cylindrical bores and clicks some buttons to associate threads with them.
  4. Now that we know holes with threads, we need to save this whole data to a STEP file so that a CAM system (like the CAM module of Fusion360) can read these threads.
I haven't checked it precisely, but I heard that the STEP format is capable of communicating features. Has anyone ever tried to exploit these capacities of the STEP format? What about threads? Does anyone have any practical experience in communicating threaded holes other than modeling them explicitly?
Without having much knowledge on this topic, I am very interested to see if someone knows anything about this. Just started doing some research for developing a more generalized slicer for additive manufacturing, and I think having some special kind of AFR capabilities could bring some really cool results.
 

Jonathan

CAD community veteran
No idea if it's possible to store in the step file.. but
Could it simply be part of the logic? For blind holes.. two cylindrical shape, then if one is thread major diameter and the second is drill size for said major thread diameter.
 

Quaoar

Administrator
Staff member
What I found is that machining features, including threads, are defined in AP224 STEP protocol which is (non-surprisingly) not supported by OpenCascade and other CAD vendors. So one could basically try to communicate this data via STEP AP224 (if he takes care of implementing the missing part of the translator) but all this information will be lost on the next import/export.

1637645808117.png
@Jonathan yes, it seems I'll have pass the features through a supplemenary file, likely JSON. Geometric approach, like you propose, is also possible, and people often use colors just to say there's a thread (you'll anyway need a drawing to define the thread props then). I was looking for a standard way of communicating manufacturing information though. It's funny, given that we're living in the era of "digital twins, industry 4.0, etc.", to find out that CAD vendors do implement open standards. E.g., Fusion 360 will not even read PMI from a STEP file.
 

blobfish

CAD community veteran
IMHO: This is another little dirty secret of cad vendors. They claim they support step and the ignorant will see the imported step geometry on the screen and say "yup we got it". But like most things, the devil is in the details. They choose not to support the extra step data because, they want to keep you locked into their ecosystem and sell you their manufacturing package that has the advantage of all the data and not just a subset. I will stop this rant short. :p

As already mentioned, I have seen colors used. I was never a fan of colors. For one it requires the ocaf to get colors for occt, if I remember correctly. For another, colors are kind of a human recognition thing as apposed to a programmatic/automatic recognition. I want automatic! In the automatic direction, can we rely on rgb float values being consistent across systems or how much control of those color values does the user get from the other system? Equality tolerance on these foreign systems rgb values?

Another way I have seen this done, is unique holes that are indicative of an advanced operation. For example a 10mm x 1.5 thread has a drill size of 8.5mm. The hole in the model might be something like 8.5001 to indicate that this feature is a 10mm x 1.5 thread. Of course no other feature would use that diameter.
 

Jonathan

CAD community veteran
What I found is that machining features, including threads, are defined in AP224 STEP protocol which is (non-surprisingly) not supported by OpenCascade and other CAD vendors. So one could basically try to communicate this data via STEP AP224 (if he takes care of implementing the missing part of the translator) but all this information will be lost on the next import/export.

View attachment 121
@Jonathan yes, it seems I'll have pass the features through a supplemenary file, likely JSON. Geometric approach, like you propose, is also possible, and people often use colors just to say there's a thread (you'll anyway need a drawing to define the thread props then). I was looking for a standard way of communicating manufacturing information though. It's funny, given that we're living in the era of "digital twins, industry 4.0, etc.", to find out that CAD vendors do implement open standards. E.g., Fusion 360 will not even read PMI from a STEP file.
Quaoar,

Thread pitch can be deducted from the two diameters.
Major diameter - pitch = drill size, for 60 degrees threads anyway..

I don't have a lot of cad experience, sorry, but I am here to learn! :)
 

Quaoar

Administrator
Staff member
The hole in the model might be something like 8.5001 to indicate that this feature is a 10mm x 1.5 thread. Of course no other feature would use that diameter.
Loving it. That sounds so engineering lol

Thread pitch can be deducted from the two diameters.
In this context, I'll let the customer decide cause it's also related to the frontend (UI). Still, what's pretty clear already now is that using STEP alone is hopeless in my situation. It will likely be another supplementary file to put near the model once threads are assigned.
 

Quaoar

Administrator
Staff member
Here's a follow-up.

Threads are defined as part ISO/TS 10303-1814:2019 of the STEP standard together with other machining features.

1637905887927.png
EXPRESS specification:
*)
ENTITY Defined_thread
SUBTYPE OF (Thread);
crest : OPTIONAL Numerical_item_with_unit;
minor_diameter : OPTIONAL Numerical_item_with_unit;
pitch_diameter : OPTIONAL Numerical_item_with_unit;
major_diameter : Numerical_item_with_unit;
END_ENTITY;
(*

Attribute definitions:

crest: specifies the distance between the opposing points of the thread. The crest is formed by the intersection of the sides of the thread if extended, if necessary, beyond the top of the thread. The value of this attribute need not be specified.

minor_diameter: specifies the dimension of the smallest diameter of the Defined_thread and is applied to both an internal and an external thread. The value of this attribute need not be specified.

pitch_diameter: specifies the dimension of an imaginary cylinder passing through the threads to make equal the widths of the threads and the widths of the spaces cut by the cylinder. The value of this attribute need not be specified.

major_diameter: specifies the dimension of the largest diameter of the Thread and is applied to both an internal and an external thread.
Would it make sense to try to add machining features support to the STEP translator of OpenCascade? That's a huge effort, just thinking loudly.

Another keyword for further research is STEP-NC, but I haven't checked yet what it's all about.
 
Last edited:

Jonathan

CAD community veteran
I wonder what software actually support this data?

glancing at the STEP-NC document, I am bit surprised that NC-code an be imbedded in a step file.
 

Quaoar

Administrator
Staff member
I wonder what software actually support this data?
I doubt it's supported anywhere. Still, I'm thinking that such innovations could come from the open-source world. Actually, the hard thing is already done: it's the standard itself. I contacted Mikael Hedlind (he had contributed to STEP) to know his opinion on the subject, but haven't received any answer yet.

Still, having machining features communicated via the STEP format looks like a natural completion for feature recognition workflows and alike. I'm quite interested in that, but I'm not sure which AP to take as a reference.
 

Jonathan

CAD community veteran
@Quaoar , I agree it does appear to be a natural completion for feature recognition and it make sense to embed this information in the file if already available. I would love to help. I am a very frustrated with my current project (not liking MFC) . I feel like contributing to an open source project may help me .. and others too.
 

Quaoar

Administrator
Staff member
@Jonathan Contributing to the STEP translator is probably the last thing one wanna do. EXPRESS schema that describes the entities and their relations should be used to generate the corresponding C++ classes, and such generation can and should be automated.

In OpenCascade, there is a tool to convert EXPRESS to C++. More on it here: https://tracker.dev.opencascade.org/view.php?id=31481

ExpToCas tool has been developed in 1999-2002 for generation of new classes in OCCT DE module, representing entities from STEP standard. It includes parser of EXPRESS schema and generator of CDL and CXX files that can be easily added to the OCCT STEP reader.

Contributing new schemas/AP to STEP should likely start from reanimating all these automatic code generators. I believe that the OpenCascade's dev branch for it is operational as it was already used to generate the entities for kinematics. Now what I probably have to do is sit down and try to give it a run.
 

Jonathan

CAD community veteran
@Quaoar you are right, it is probably the last thing I should do.

I hope you succeed. Good luck.

I will try to find a project I can start contributing to.
 

Quaoar

Administrator
Staff member
An update from Mikael Hedlind:

AP224 defines features but since its publication in 2006 all development on feature representation has been made for AP238 and AP242 (both share the same schema specification on features). As you might know AP238 is available here https://stepmfg.github.io/ap238e2/ (it’s the exact same document content as in the ISO publication but without the front page due to ISO copyright).
So I would suppose that introducing features in OpenCascade can be done in the scope of the partially implemented AP242.
 
Top