Feature recognition

Preamble

On our forum, we discussed how to pass thread features via a STEP file. The workflow to automate is outlined below:

1. The user uploads a STEP file somewhere in a web-based frontend.
2. All drilled holes are recognized automatically.
3. The user selects cylindrical bores and clicks some buttons to associate threads with them.
4. Now that we know holes with threads, we need to save this collected data to a STEP file so that a CAM system (like the CAM module of Fusion360) can read these threads and plan them for manufacturing.

The forum discussion reveals that nobody believes in the standard techniques such as ISO/TS 10303-1814:2019 to communicate threads. That is simply because CAD vendors do not seem to support standards that much. One of the most obvious approaches to say if a hole is threaded or not is to give it a color. This way, instead of using the metadata unsupported by CAD vendors, we cheat them and fall back to the metadata that IS supported. Indeed, it is very unlikely that any industrially proven CAD/CAM system wouldn't read colors from a STEP file. Then, to encode different types of threads, we can use different color codes leaving their interpretation to the backend of the corresponding system.

Modeled thread in a hole.

One can argue that a simpler approach would be modeling threads explicitly. But, there are at least two drawbacks in such an approach:

1. The modeled threads won't be recognized as such only because they are modeled. The receiving system would need to have some sort of automated threads recognition. And that's going to be quite an algorithm.
2. The very existence of modeled threads in a CAD file increases significantly both the file size and processing time for a STEP translator. The latter would have to perform quite a bit of extra job to read and create all the thread features.

Creating modeled threads in Fusion360.

Therefore, a pragmatic solution would be to use that goddamn coloring. Unless support of typical machining features is brought to the next level in the popular CAD systems.

Architecture

There is not much to discuss about the architecture of a coloring service. Let me call this thing a "service" just to emphasize that it can be isolated from the rest of your engineering system. The Service can read the following inputs:

1. STEP file without colors.
2. A list of color IDs with their corresponding face IDs.

The output is simply a STEP file where all the requested faces are colorized with the requested colors. Technically, this service can be implemented as an executable which you can then launch in a command-line fashion and containerize it with Docker if necessary.

The input JSON can have the following format to make it simple:

{
  "faceColors": [
    {
      "color": {
         "h": 30,
         "s": 1,
         "l": 0.5
      },
      "faceIds": [71, 87]
    },
    {
      "color": {
         "h": 140,
         "s": 0.8,
         "l": 0.4
      },
      "faceIds": [14, 15, 16, 17]
    }
  ]
}

In the example above, colors are defined in the HSL format whereas face IDs are packed into the plain arrays of 1-based indices.

ANC101 with automatically colored holes.

Workflow

Technically speaking, the implementation of the coloring service is a matter of few hours. Here is how it would work:

1. Load a STEP file into an XDE document.
2. Find all faces corresponding to the indices coming from the JSON file.
3. In the XDE document, create subshape labels for these faces.
4. Assign the corresponding colors to the newly created sublabels.
5. Save the modified XDE document back to STEP (colors will be transferred).

Here we take advantage of the XDE framework that is a medium layer between STEP and OpenCascade. XDE stores names, colors, assembly hierarchy and even some product manufacturing information (PMI) that is a trendy thing nowadays (bad luck for features though).

Want to discuss this? Jump in to our forum.