Tacton and Inventor without every variant in the assembly

Tacton Design Automation works from an Inventor master assembly that already contains every part the product could ever need. The configuration then switches parts on or off, changes dimensions and writes the result away. That is how it is meant to work, and for a small product it is fine. For a structure with many repeated elements it becomes heavy.

So I built a small middleware as a proof of concept. It does not drive a master assembly. It reads the XML report Tacton produces after a configuration and builds the Inventor model from a library, part by part.

What the master assembly costs

The product was a metal frame structure. One structure can hold up to 18 frames, each frame has 5 beams, and there are two kinds of beam element. With Design Automation every beam has to exist in every position, so the same beam ends up copied into the project up to 180 times.

The folder for one configuration was 330.9 MB.

Size was not the only problem. Every placeholder had to be maintained in Inventor, the link between Tacton and Inventor was made by hand through auxiliary properties, and Tacton could not use instances properly, because each instance needed its own fixed counterpart in the assembly. Work that the configurator could have done once was repeated in CAD.

Let the report describe the model

After a configuration, Tacton can export a report: an XML tree with every configured part, its attributes and its children. The configuration has already decided what exists and where it goes. The report only needs a few extra attributes to also say how Inventor should build it.

I added a small set of tags to the Tacton model, all starting with IA_:

A beam in the report then looks like this, shortened:

<part name="beam" no="1">
  <attributes>
    <attribute name="IA_Type">part</attribute>
    <attribute name="IA_source_part">Part</attribute>
    <attribute name="IA_target_part">Beam_Left</attribute>
    <attribute name="IA_x_position">-400.0</attribute>
    <attribute name="IA_y_position">0.0</attribute>
    <attribute name="IA_z_rotation">0</attribute>
  </attributes>
  <subparts>
    <part name="beam_01_extrusion" no="1">
      <attributes>
        <attribute name="IA_type">extrude_rectangle</attribute>
        <attribute name="IA_workplane">Y_axis</attribute>
        <attribute name="IA_extrusion_operation">join</attribute>
        <attribute name="IA_length">50.0</attribute>
        <attribute name="IA_height">140.0</attribute>
        <attribute name="IA_depth">2160.0</attribute>
      </attributes>
    </part>
  </subparts>
</part>

The beam is not a modelled beam from a catalogue. It starts as an empty part from the library, and the report says which rectangle to extrude and how long. A stopper slot is a second extrusion with cut. A joint is a third one on another work plane.

The library becomes small

Because the geometry comes from the report, the library only needs a handful of starting points: an empty assembly, an empty part, and a few parts with existing parameters or features. I sorted them by shape and features, not by what they are in the product. A wooden beam and a fire strip can come from the same file with another material and other dimensions.

The library for the same frame structure was 5.9 MB.

The middleware copies only what the configuration uses. A configuration with four frames gives a project folder with one main assembly, four frame assemblies and, per frame, four beams and four stoppers. Nothing else.

How the middleware runs

The first version ran as an iLogic rule inside an Inventor assembly. Later I moved it into a small WPF application in C#, which starts Inventor (visible or in the background), reads the report, builds the structure and shows the result in a 3D viewer.

The steps are always the same:

1. Read the report and walk the part tree.
2. Skip Tacton parts without IA tags; they only group other parts.
3. For every assembly or part, copy the source file from the library under its target name.
4. Fill in parameters with the same name as a Tacton attribute.
5. Build the features listed under the part.
6. Place it in its parent at the given position and rotation.

In Reading a Tacton XML report in iLogic I show those steps as one iLogic rule you can run yourself.

What it costs

This is custom software. When Inventor changes its API, someone has to update it, and that someone needs to understand both Tacton and Inventor. Design Automation is supported by Tacton; this is not.

There was also an open point on the Tacton side. In the demo I exported the report from Tacton Studio. To run it from the web configurator, the same report has to come out of the server through a supported route, and at the time that route was not obvious.

Where it ended

It stayed a proof of concept while I was there. I left the company not long after, and heard later that much of the approach was taken over. I cannot show how it runs today, so I will not claim more than that.

What I take from it is the split. Tacton decides what the product is. The report carries that decision. Inventor only builds it. As soon as the CAD side stops holding every possible variant, the configurator can use its own strengths again, such as instances, and the CAD data stays as small as the product that was actually configured.