Tacton Design Automation vertrekt van een Inventor-masterassembly die al elk onderdeel bevat dat het product ooit kan nodig hebben. De configuratie zet onderdelen aan of uit, past maten aan en schrijft het resultaat weg. Zo is het bedoeld, en bij een klein product werkt dat prima. Bij een structuur met veel herhaalde elementen wordt het zwaar.

Daarom bouwde ik een kleine middleware als proof of concept. Die stuurt geen masterassembly aan. Ze leest het XML-rapport dat Tacton na een configuratie maakt en bouwt het Inventor-model op vanuit een bibliotheek, onderdeel per onderdeel.

Wat de masterassembly kost

Het product was een metalen framestructuur. Eén structuur kan tot 18 frames bevatten, elk frame heeft 5 balken, en er zijn twee soorten balkelementen. Met Design Automation moet elke balk op elke positie bestaan, waardoor dezelfde balk tot 180 keer in het project gekopieerd wordt.

De map voor één configuratie was 330,9 MB.

Grootte was niet het enige probleem. Elke placeholder moest in Inventor onderhouden worden, de koppeling tussen Tacton en Inventor gebeurde met de hand via auxiliary properties, en Tacton kon instances niet goed gebruiken, omdat elke instance een eigen vaste tegenhanger in de assembly nodig had. Werk dat de configurator één keer kon doen, werd in CAD herhaald.

Laat het rapport het model beschrijven

Na een configuratie kan Tacton een rapport exporteren: een XML-boom met elk geconfigureerd onderdeel, zijn attributen en zijn kinderen. De configuratie heeft dan al beslist wat er bestaat en waar het komt. Het rapport heeft maar een paar extra attributen nodig om ook te zeggen hoe Inventor het moet bouwen.

Ik voegde een kleine set tags toe aan het Tacton-model, allemaal beginnend met IA_:

Tag Betekenis
IA_type assembly, part, of een feature zoals extrude_rectangle
IA_source_part van welk bibliotheekbestand vertrekken
IA_target_part de naam in het nieuwe project
IA_x_position, IA_y_position, IA_z_position positie in mm
IA_z_rotation rotatie in graden
IA_workplane, IA_length, IA_height, IA_depth schetsvlak en maat van een feature
IA_extrusion_operation join of cut

Een balk ziet er in het rapport dan zo uit, ingekort:

<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>

De balk is geen gemodelleerde balk uit een catalogus. Hij begint als een leeg part uit de bibliotheek, en het rapport zegt welke rechthoek geëxtrudeerd wordt en hoe lang. Een sleuf voor een aanslag is een tweede extrusie met cut. Een verbinding is een derde, op een ander werkvlak.

De bibliotheek wordt klein

Omdat de geometrie uit het rapport komt, heeft de bibliotheek maar een handvol vertrekpunten nodig: een lege assembly, een leeg part, en een paar parts met bestaande parameters of features. Ik sorteerde ze op vorm en features, niet op wat ze in het product zijn. Een houten balk en een brandstrip kunnen uit hetzelfde bestand komen, met een ander materiaal en andere maten.

De bibliotheek voor dezelfde framestructuur was 5,9 MB.

De middleware kopieert alleen wat de configuratie gebruikt. Een configuratie met vier frames geeft een projectmap met één hoofdassembly, vier frame-assemblies en per frame vier balken en vier aanslagen. Niets meer.

Hoe de middleware werkt

De eerste versie draaide als iLogic-regel in een Inventor-assembly. Later zette ik ze om naar een kleine WPF-toepassing in C#, die Inventor opstart (zichtbaar of op de achtergrond), het rapport leest, de structuur bouwt en het resultaat in een 3D-viewer toont.

De stappen zijn altijd dezelfde:

  1. Lees het rapport en doorloop de boom van onderdelen.
  2. Sla Tacton-onderdelen zonder IA-tags over; die groeperen alleen andere onderdelen.
  3. Kopieer voor elke assembly of elk part het bronbestand uit de bibliotheek onder zijn nieuwe naam.
  4. Vul parameters in die dezelfde naam hebben als een Tacton-attribuut.
  5. Bouw de features die onder het part staan.
  6. Plaats het in zijn parent op de opgegeven positie en rotatie.

In Een Tacton XML-rapport lezen in iLogic toon ik die stappen als één iLogic-regel die je zelf kan draaien.

Wat het kost

Dit is maatwerk. Als Inventor zijn API verandert, moet iemand het bijwerken, en die persoon moet zowel Tacton als Inventor begrijpen. Design Automation wordt door Tacton ondersteund; dit niet.

Er was ook een open punt aan de kant van Tacton. In de demo exporteerde ik het rapport vanuit Tacton Studio. Om het vanuit de webconfigurator te laten lopen, moet hetzelfde rapport via een ondersteunde weg uit de server komen, en die weg was toen niet duidelijk.

Waar het eindigde

Het bleef een proof of concept zolang ik daar was. Ik vertrok niet lang daarna, en hoorde later dat een groot deel van de aanpak is overgenomen. Ik kan niet tonen hoe het vandaag draait, dus meer dan dat beweer ik niet.

Wat ik eruit meeneem, is de verdeling. Tacton beslist wat het product is. Het rapport draagt die beslissing. Inventor bouwt het alleen. Zodra de CAD-kant niet meer elke mogelijke variant moet bevatten, kan de configurator zijn eigen sterktes weer gebruiken, zoals instances, en blijft de CAD-data zo klein als het product dat echt geconfigureerd werd.