Engineering heeft dat resultaat alleen nog nodig als een echte AutoCAD-tekening. Niet als een eenmalige afbeelding van lijnen, maar als een DWG met de juiste dynamische blocks die verder bruikbaar blijft in AutoCAD.
Voor een recente vraag bouwde ik bij Kubuz een klein lokaal MVP dat precies die brug legt. Het leest een XML-report uit Tacton, koppelt elk geconfigureerd onderdeel via configuratie aan een AutoCAD-block en laat AutoCAD 2026 op dezelfde Windows-pc de uiteindelijke tekening genereren.
De belangrijkste ontwerpkeuze daarbij is eenvoudig:
Tacton configureert. AutoCAD voert uit. De middleware bouwt geen tweede productmodel.
Tacton blijft de source of truth
Bij een generieke "XML naar CAD"-koppeling is de verleiding groot om informatie uit namen te gaan afleiden.
Zie je bijvoorbeeld iets als Dynamic_rectangle 50 x 50, dan zou een generator kunnen besluiten dat dit een rechthoek van 50 × 50 mm moet worden en zelf geometrie tekenen.
Dat lijkt handig, maar schaalt slecht.
In het Tacton-model is Dynamic_Block het onderdeel. Rectangle of circle is de gekozen realisatie via realized-by. Length, Height, Radius en positie zijn attributen van het geconfigureerde onderdeel.
De tekeninstructie zit dus al in het configuratieresultaat.
De middleware hoeft alleen te vertalen welk AutoCAD-block bij die realisatie hoort, welke Tacton-attributen de dynamische block properties sturen en op welke positie en rotatie het block moet worden ingevoegd.
Ze hoeft niet opnieuw te beslissen wat het product betekent.
Dat onderscheid is belangrijk. Als realized-by bijvoorbeeld Dynamic_rectangle 999 x 999 zou heten, maar de attributen zeggen Length = 50 en Height = 50, dan wordt het block 50 × 50 mm. De naam is een mapping-key, geen bron voor de geometrie.
Drie lagen, één machine
De architectuur is bewust klein gehouden:
Tacton → XML report → Kubuz middleware → AutoCAD 2026 Core Console + plugin → output.dwg
Alles draait lokaal op dezelfde Windows-pc.
| Laag | Rol |
|---|---|
| Tacton | Configureert het product en exporteert het report. |
| Kubuz middleware | Leest XML, mapt onderdelen, beheert jobs, toont een preview en controleert het resultaat. Tekent zelf geen CAD. |
| AutoCAD 2026 | Maakt de echte DWG via Core Console en een kleine .NET-plugin. |
De browserpreview is handig voor de gebruiker, maar niet de autoriteit. De opgeslagen DWG uit AutoCAD is dat wel.
1. Configureren in Tacton
De gebruiker configureert het product in Tacton.
In het XML-report onder /session/view/report bevat elk relevant Dynamic_Block de informatie die nodig is om te tekenen.
In dit MVP zijn dat onder andere Length, Height, Radius, x_position, y_position, qty en realized-by.
Andere informatie uit de sessie — cookies, metadata, statistieken — hoort niet bij de tekeninput en wordt genegeerd.
De parser loopt recursief door het report en verzamelt de geconfigureerde blocks.
Voor deze eerste versie accepteer ik alleen qty = 1. Als Tacton twee afzonderlijke onderdelen nodig heeft, verwacht ik ook twee onderdelen in het report. De middleware verzint zelf geen arrays of extra plaatsingslogica.
2. Uploaden in een lokale webinterface
De middleware draait als een kleine ASP.NET-app op localhost.
Voor het MVP is de interface bereikbaar op http://127.0.0.1:5088.
De gebruiker uploadt het Tacton-report en de parser zet het om naar een interne, eenvoudige jobbeschrijving.
Belangrijk daarbij: de parser interpreteert geen maten uit productnamen. Hij leest uitsluitend de expliciete attributen die Tacton heeft berekend.
Als Tacton twee onderdelen op (0, 0) zet, staan er in AutoCAD twee onderdelen op (0, 0). De app probeert de tekening niet automatisch "mooier" te maken.
3. Tacton naar AutoCAD mappen via configuratie
De koppeling tussen Tacton en AutoCAD staat niet hardcoded in de generator.
Een catalogus in appsettings.json beschrijft welke realisatie welk bronbestand gebruikt en welke attributen aan welke dynamic properties gekoppeld worden.
| Tacton | AutoCAD |
|---|---|
| Dynamic_Block + realization bevat rectangle | Dynamic block uit Dynamic Rectangle.dwg |
| Length, Height | Dynamic properties Length, Height |
| Dynamic_Block + realization bevat circle | Dynamic block uit Dynamic Circle.dwg |
| Radius | Dynamic property Radius |
| x_position, y_position | Insertion point in mm |
| optionele rotatie | Rotatie rond dat insertion point |
Een nieuw block toevoegen betekent daardoor in de eerste plaats een nieuwe catalogusregel toevoegen, niet de generator herschrijven.
Attributen die niet bij de gekozen variant horen worden genegeerd. Een rechthoek mag bijvoorbeeld een Radius = 0 in het report hebben zonder dat de AutoCAD-koppeling daar iets mee doet.
Het bronbestand is niet hetzelfde als de blocknaam
Een detail dat bij AutoCAD belangrijk wordt: de bestandsnaam van de aangeleverde DWG is niet automatisch de naam van het dynamic block in AutoCAD.
De aangeleverde bestanden bevatten elk een dynamisch block — in recente AutoCAD-termen een enhanced block — dat op model space staat als voorbeeld.
De plugin inspecteert het bronbestand, importeert de blockdefinitie, verwijdert overgebleven voorbeeldgeometrie en voegt daarna zelf nieuwe block references toe voor de Tacton-instances.
De library-DWG's zelf worden daarbij nooit aangepast.
4. AutoCAD genereert de tekening
Elke generatie krijgt een eigen jobfolder.
De benodigde bron-DWG's worden naar die folder gekopieerd en gehasht. AutoCAD werkt dus altijd op jobkopieën en nooit op de oorspronkelijke library files.
Daarna start AutoCAD Core Console headless.
Een kleine .NET-plugin wordt geladen en voert één generate-command uit. De plugin importeert elke unieke dynamic-blockdefinitie die voor de job nodig is, plaatst één block reference per Tacton-instance, zet alleen de properties die in de mapping staan, gebruikt millimeters met schaal 1 en slaat het resultaat op als output.dwg.
De positie komt rechtstreeks uit Tacton. Hetzelfde geldt voor de rotatie wanneer die aanwezig is.
Er zit bewust geen automatische layout-engine tussen.
5. Niet alleen genereren, maar ook controleren
Een bestand zonder foutmelding opslaan is niet genoeg.
Na het genereren opent de plugin output.dwg opnieuw en leest ze de geplaatste blocks terug uit AutoCAD.
De middleware vergelijkt vervolgens de aanvraag met het werkelijke resultaat: aantal blocks, insertion points, rotaties, dynamic property values en de geometrische extents van het resultaat.
Dat laatste vind ik belangrijk.
Dat AutoCAD meldt dat een property op 50 mm staat, betekent nog niet automatisch dat de geometrie ook werkelijk 50 mm groot geworden is. Door de opgeslagen DWG opnieuw te openen en de extents te meten, controleer je het resultaat in plaats van alleen de opdracht.
De opgeslagen DWG is het bewijs.
De oplossing opgesplitst
De code is in drie delen gehouden.
TactonCad.Core
Deze laag heeft geen dependency op AutoCAD.
Hier zitten de XML-parser, variant-resolver, mapping en verificatielogica. Daardoor kan dit deel normaal met unit tests getest worden zonder AutoCAD te starten.
TactonCad.App
Dit is de lokale ASP.NET-app.
Ze verzorgt de UI, uploads, jobfolders, mappingconfiguratie en het starten van Core Console. Voor het MVP verwerkt ze één job tegelijk en gebruikt ze gewone bestanden op disk.
Geen Docker, Redis, database of login.
Die infrastructuur zou in deze fase niets aan het eigenlijke technische probleem toevoegen.
TactonCad.Plugin
Dit is het kleine .NET-gedeelte dat daadwerkelijk binnen AutoCAD draait.
Via NETLOAD en het commando TACTONGEN kan dezelfde generatie ook rechtstreeks getest worden. De plugin kan een bron-DWG inspecteren, blocks importeren, de tekening genereren en de opgeslagen DWG opnieuw uitlezen.
Dat is bewust de enige laag die AutoCAD hoeft te kennen.
Preview is iets anders dan generatie
Naast de DWG-download toont de lokale webinterface ook een canvaspreview.
Die preview is een convenience feature. Ze mag nooit bepalend worden voor het resultaat.
In het MVP wordt daarvoor een LibreDWG-gebaseerde parser in de browser gebruikt. Een AutoCAD 2026-DWG met dynamische blocks is voor zo'n parser niet altijd even eenvoudig. Als een preview niet geopend kan worden, moet de DWG-download nog altijd gewoon werken.
AutoCAD blijft de controle.
Als dit ooit een gesloten product wordt, moet ook de licentie van zo'n previewcomponent afzonderlijk bekeken worden. Dat staat los van de CAD-generatie zelf.
De ontwerpregels die ik bewust eenvoudig hou
Voor mij zijn dit de belangrijkste grenzen van de oplossing.
Tacton configureert. CAD voert uit. De middleware bevat geen kopie van de productregels.
Mapping is data. Welk block geladen wordt komt uit realized-by of eventueel een expliciete CAD-identificatie. Niet uit geometrie die de middleware probeert te herkennen.
Dynamic blocks blijven dynamic. Ze worden ingevoegd en via hun properties aangepast, niet geëxplodeerd naar statische polylines.
Millimeters, schaal 1. Afmetingen en posities worden gebruikt zoals Tacton ze aanlevert.
Geen verzonnen plaatsing. Als Tacton twee onderdelen op dezelfde plaats zet, blijft dat zo.
Library files blijven library files. Een job werkt altijd met kopieën.
Controle gebeurt op de opgeslagen DWG. Niet alleen op de waarden die we probeerden te zetten.
Wat dit MVP wel en niet is
Dit is een werkende lokale brug op een Windows-pc met AutoCAD 2026.
In de huidige test worden een rechthoekig en een rond dynamisch block vanuit een echt Tacton-report in één DWG geplaatst, met hun geconfigureerde afmetingen en posities.
Het is geen cloud-CAD-service, geen multi-user portal en geen vervanging voor Tacton of AutoCAD.
Een andere pc kan dezelfde middleware draaien, maar heeft daar ook AutoCAD 2026 nodig.
Voor dit MVP is dat net een voordeel. De uiteindelijke DWG wordt gemaakt door dezelfde AutoCAD-engine die de klant al gebruikt en vertrouwt.
De kern
De koppeling hoeft productconfiguratie niet opnieuw uit te vinden.
Tacton heeft de keuzes en afmetingen al bepaald. De middleware vertaalt die informatie via een expliciete mapping naar dynamic-block insertions. AutoCAD maakt vervolgens de tekening die engineering kan openen, controleren en verder gebruiken.
Dat is een kleine architectuur, maar precies daardoor blijft de verantwoordelijkheid helder:
Tacton weet wat gebouwd moet worden. AutoCAD weet hoe de DWG wordt gemaakt. De middleware verbindt de twee.