Je kent het moment wel. Voor de zoveelste keer loop je in Autodesk Inventor hetzelfde rijtje handelingen af: iProperties invullen, tekeningen naar PDF en DWG zetten, een stuklijst naar Excel exporteren. En je denkt: dit moet slimmer kunnen. De voor de hand liggende route is iLogic. Je schrijft een paar regels code, koppelt er een knop aan, klaar. Maar dan groeit het. Het ene script wordt er tien. Een collega vraagt of jij even zijn variant kunt fixen. En op een dag, meestal als jij net op vakantie bent, valt er iets stil en vraagt iemand: wie onderhoudt dit eigenlijk?
Dat is precies het punt waarop veel engineering-afdelingen gaan zoeken naar een iLogic alternatief. Niet omdat iLogic slecht is, het is een krachtig stuk gereedschap, maar omdat zelf bouwen verborgen kosten heeft die pas zichtbaar worden als het script al diep in je proces zit. In dit artikel leggen we de twee routes eerlijk naast elkaar: zelf automatiseren met iLogic en losse scripts versus een onderhouden toolbox als Thundercad. Geen verkooppraatje van "scripten is dom", want dat is het niet. Wel een nuchtere afweging van onderhoud, Inventor-updates, teamafhankelijkheid en samenhang, zodat je voor jouw situatie de juiste keuze maakt.
Wat iLogic wél en niet is
iLogic is de ingebouwde regel-engine van Inventor. Je schrijft regels (in feite VB.NET) die parameters aansturen, features onderdrukken, iProperties uitlezen en wegschrijven, of complete configuraties opbouwen. Voor parametrische, productspecifieke logica is dat goud waard. Denk aan een trappenfabrikant die hoogte, breedte en aantal treden invoert en daar een compleet model uit laat rollen. Of een machinebouwer met een standaard transportband die in lengtes van 1 tot 12 meter geleverd wordt, waarbij het frame, het aantal steunpoten en de aandrijving zich automatisch aanpassen. Dat is iLogic op zijn best: kennis over jóuw product, vastgelegd in regels.
Waar iLogic minder geschikt voor is, is generiek, terugkerend productiewerk dat bij élk project hetzelfde is. Alle tekeningen van een samenstelling in één keer publiceren. Metadata consistent beheren over al je documenttypes heen. Een samenstelling van 200 onderdelen razendsnel openen en daarna weer netjes sluiten. Een stuklijst in een vast Excel-sjabloon krijgen dat inkoop direct kan inlezen. Dat zijn geen productspecifieke regels, maar workflow-handelingen die voor iedere Inventor-gebruiker grotendeels hetzelfde zijn. En juist daar gaat zelfbouw vaak wringen.
Het verschil zit in de aard van het probleem. Productlogica is uniek voor jouw product en hoort bij jou thuis: niemand anders kent jouw configuraties en bouwregels. Workflow-automatisering is generiek; elke Inventor-afdeling worstelt met dezelfde exportdialogen en metadata-velden. Bouw je dat zelf, dan ben je het wiel opnieuw aan het uitvinden, en blijf je het daarna ook zelf onderhouden.
De verborgen kosten van zelf bouwen
Een script schrijven is goedkoop. Een script onderhouden is dat niet. Dat is de kern van de afweging, en de reden dat zoveel afdelingen een iLogic alternatief overwegen zodra hun eerste verzameling scripts is uitgegroeid tot een kluwen die niemand meer in zijn geheel overziet.
Onderhoud kruipt waar het niet gaan kan
Het eerste script werkt perfect. Het tweede ook. Bij het zevende ontdek je dat ze elkaar in de weg zitten: de ene gebruiker draait een aangepaste versie, de andere de originele, en niemand weet meer welke de "echte" is. Iemand wijzigt de mapstructuur op de server en de helft van de export-scripts struikelt over een pad dat niet meer bestaat. Een sjabloon krijgt een extra iProperty-veld en je BOM-script gooit ineens lege kolommen uit. Onderhoud aan zelfgebouwde automatisering is geen project met een einddatum: het is een vaste kostenpost die nooit verdwijnt. En hij hindert juist op de drukste momenten, want fouten vallen pas op als je onder druk een set moet uitleveren.
Updates van Inventor breken dingen
Autodesk brengt elk jaar een nieuwe Inventor-versie uit. Soms verandert de API, soms gedraagt een methode zich net anders, soms verdwijnt een functie. Bij een onderhouden toolbox is dat de zorg van de leverancier: die test tegen de nieuwe versie en levert een update uit. Bij eigen scripts is dat jouw zorg, en meestal op het slechtst denkbare moment. Stel: de hele afdeling is net overgestapt naar de nieuwe versie omdat een klant daar een model in vroeg, en dan blijkt dat je publish-script niet meer draait. Nu zit je met productie die wacht en een collega die tussen zijn eigen deadlines door moet uitzoeken welke API-aanroep is veranderd. Die rekening is lastig vooraf in te schatten, maar hij komt elk jaar terug.
Teamafhankelijkheid: de bus-factor
Dit is de stilste en gevaarlijkste kostenpost. Vaak is er één collega, laten we hem de scriptheld noemen, die alles heeft gebouwd en als enige snapt hoe het in elkaar zit. Zolang hij er is, loopt het. Maar wat als hij twee weken op vakantie is, ziek wordt, of een andere baan vindt? Dan staat er code in productie die niemand durft aan te raken, met variabelennamen die alleen hij begreep en zonder een regel uitleg erbij. We noemen dat de bus-factor: hoeveel mensen mogen er onder de spreekwoordelijke bus komen voordat je proces stilvalt? Bij veel zelfbouw-oplossingen is het antwoord: één. En dat is een risico dat geen enkele engineering-manager bewust zou kiezen als hij het zwart op wit zag staan.
Tip: Wil je weten hoe kwetsbaar je bent? Vraag je af of een willekeurige collega morgen een bestaand iLogic-script zou kunnen aanpassen zónder de oorspronkelijke bouwer erbij. Is het antwoord nee, dan heb je een teamafhankelijkheid die je beter zichtbaar maakt vóór die zich tegen je keert dan erna.
Samenhang ontbreekt
Losse scripts zijn precies dat: los. Elk script heeft zijn eigen knop, zijn eigen logica, zijn eigen aannames over mappen, namen en instellingen. Er is geen gedeelde configuratie, geen consistente interface, geen overkoepelend beheer. Een nieuwe medewerker moet stuk voor stuk leren welk knopje wat doet, welke volgorde klopt en waar de valkuilen zitten, meestal door één keer iets fout te doen. Een toolbox die als samenhangend geheel is ontworpen, biedt één manier van werken over alle tools heen: dezelfde instellingen, dezelfde logica, hetzelfde gedrag. Dat scheelt enorm in inwerktijd en in het soort fouten dat ontstaat doordat de ene tool nét anders werkt dan de andere.
Benieuwd of een onderhouden toolbox jouw scriptkluwen kan vervangen? Installeer Thundercad en test het in je eigen Inventor-omgeving, op je eigen projecten, geen creditcard nodig.
Probeer 30 dagen gratisiLogic alternatief in de praktijk: de directe vergelijking
Genoeg theorie. Laten we de twee routes naast elkaar leggen op de punten die er in de dagelijkse praktijk toe doen. Onderstaande tabel vat samen wat je krijgt en wat het je kost: niet alleen in euro's, maar in tijd, risico en gemoedsrust.
| Aspect | Zelf bouwen (iLogic / scripts) | Onderhouden toolbox (Thundercad) |
|---|
| Startkosten | Laag, een paar uur scripten | Abonnement per gebruiker |
| Onderhoud | Doorlopend, intern, nooit klaar | Bij de leverancier |
| Inventor-updates | Jouw probleem bij elke nieuwe versie | Opgelost in updates |
| Teamafhankelijkheid | Hoog, vaak één scriptheld | Laag, niemand onmisbaar |
| Samenhang | Losse knoppen, eigen logica | Eén werkwijze over alle tools |
| Inwerken nieuwe collega | Mondelinge overdracht, valkuilen | Consistente interface, documentatie |
| Productspecifieke logica | Sterk, hier blinkt iLogic uit | Niet de focus |
| Generiek productiewerk | Telkens opnieuw bouwen | Kant-en-klaar, direct bruikbaar |
| Risico bij vertrek bouwer | Proces kan stilvallen | Geen, kennis zit in product |
De tabel maakt iets duidelijk: het is geen kwestie van goed versus slecht, maar van het juiste gereedschap voor het juiste probleem. iLogic wint op productspecifieke logica. Een toolbox wint op generiek, terugkerend productiewerk waar samenhang en onderhoud zwaarder wegen dan maatwerk. De fout die afdelingen maken is niet dat ze iLogic gebruiken, maar dat ze iLogic óók inzetten voor generiek werk waar het geen voordeel biedt en wel een onderhoudslast oplevert.
Reken eens mee: wat kost zelfbouw echt
Laten we een voorbeeld nemen, duidelijk als aanname gepresenteerd. Stel dat een engineer twee dagen besteedt aan het bouwen van een batch-publish-script dat tekeningen naar PDF, DWG en DXF zet. Dat lijkt eenmalig en daarmee "gratis na de eerste investering". Maar reken eens verder mee. Elke nieuwe Inventor-versie kost zeg een halve dag aanpassen en testen. Een gewijzigde mapstructuur of een nieuw sjabloon kost nog eens een paar uur. Een collega wil een extra formaat erbij: weer een middag. En als de bouwer vertrekt, kost het inwerken van een opvolger, of het script helemaal opnieuw bouwen, al snel meerdere dagen.
Tel je dat over een paar jaar op, dan is "twee dagen" allang geen twee dagen meer. En dat zijn engineering-uren: de duurste en schaarste uren in huis, die je liever aan ontwerp besteedt dan aan het repareren van een PDF-exportscript. Bij een toolbox als Thundercad doe je Batch Publish in één klik in plaats van twaalf stappen, en zet je bijvoorbeeld 48 PDF's in 6 seconden weg, inclusief samenwerking met Autodesk Vault. Geen onderhoud, geen versie-stress, geen afhankelijkheid van één persoon. Of het abonnement het waard is hangt af van je situatie, maar de rekensom valt vaak heel anders uit dan het onderbuikgevoel dat "zelf bouwen gratis is".
Wat een onderhouden toolbox concreet dekt
Om het tastbaar te maken: een toolbox neemt juist die generieke, terugkerende handelingen uit handen waar zelfbouw het meeste onderhoud vraagt. Bij Thundercad gaat het onder meer om:
- iProperty Menu: metadata en iProperties beheren via één instelbare datakaart per documenttype, in plaats van per script of per hand.
- Batch Publish: alle productiedocumenten in één stap: PDF, DWG, DXF en STEP, werkend met Vault.
- BOM Export: stuklijsten naar Excel in een vast sjabloon, zonder dat je de export-logica zelf hoeft te onderhouden.
- Batch Open & Close: bestanden in samenstellingen snel openen en weer netjes sluiten.
- Quick Save / Load: werk parkeren en het exact terughalen zoals je het achterliet.
- Model Cleaner: achtergebleven geometrie verwijderen en de browser opschonen.
- Sheet Buttons: bladformaat omhoog of omlaag zetten en roteren.
- Dashboard: tools activeren en beheren, en koppelen aan je ERP of andere software.
Dat laatste, het Dashboard met koppeling aan ERP, laat zien waar de twee werelden elkaar raken. Een toolbox sluit de deur niet voor maatwerk; hij geeft je een onderhouden basis waarop je je eigen integraties kunt aanhaken. Je houdt dus de vrijheid om met iLogic je echte productlogica te bouwen, terwijl het generieke werk eromheen is afgedekt. Bedrijven als Little Giant Europe, Van Egten, Banzo en Mannen van Staal werken er al mee om precies dat repetitieve werk uit hun engineeringproces te halen.
Op de roadmap staan trouwens nog meer tools die nu typisch met zelfbouw worden opgelost: Batch Flat Pattern, Find Item, een Drawing Checker/Cleaner en een Drawing Updater. Nog niet beschikbaar, maar ze laten de richting zien: steeds meer generiek handwerk verschuift naar een onderhouden geheel.
Wanneer kies je dan wat?
De eerlijke conclusie is geen "altijd dit" of "altijd dat". Het is een afweging, en die valt per type werk anders uit. Hieronder een vuistregel die je direct kunt toepassen op je eigen scriptverzameling.
Kies voor iLogic / zelf bouwen als:
- het gaat om productspecifieke logica die uniek is voor jouw product: configuratoren, parametrische families, bouwregels die niemand anders kent.
- je in huis structureel iemand hebt die dit kan bouwen én onderhouden, en je die afhankelijkheid bewust accepteert en documenteert.
- het probleem zo specifiek is dat geen enkel bestaand product het dekt en maatwerk echt een onderscheidend voordeel oplevert.
Kies voor een onderhouden toolbox als:
- het gaat om generiek productiewerk dat bij elk project hetzelfde is: publiceren, exporteren, metadata beheren, samenstellingen openen en sluiten.
- je onderhoud, Inventor-updates en teamafhankelijkheid liever niet zelf draagt.
- je samenhang en een consistente werkwijze over je hele team belangrijk vindt.
- je wilt dat een nieuwe collega snel productief is zonder dat iemand eerst de valkuilen moet komen uitleggen.
In de praktijk kiezen veel afdelingen voor beide: iLogic voor het echte maatwerk dat hun product onderscheidt, en een toolbox voor alles eromheen. Zo besteed je je schaarse engineering-uren aan waar ze het verschil maken, aan het ontwerp dat je klant koopt, en niet aan een PDF-exportscript dat bij elke update kan breken. Het mooie is dat je dat niet vooraf hoeft te bewijzen op een spreadsheet: je test het op je eigen projecten voordat je iets aan je proces verandert.
Veelgestelde vragen
Is een toolbox een vervanging voor iLogic?
Nee, en dat is ook niet de bedoeling. iLogic is sterk in productspecifieke logica zoals configuratoren en parametrische families; een toolbox als Thundercad dekt generiek, terugkerend productiewerk zoals publiceren, exporteren en metadata beheren. Veel afdelingen gebruiken ze naast elkaar: iLogic voor het maatwerk, de toolbox voor de dagelijkse workflow eromheen.
Wat gebeurt er met mijn bestaande iLogic-scripts?
Die kun je gewoon blijven gebruiken. Een toolbox vervangt niet je productlogica, maar neemt de generieke handelingen over waar je nu losse scripts voor onderhoudt. Je kunt dus geleidelijk overstappen: begin met de scripts die het meeste onderhoud kosten of het grootste bus-factor-risico vormen, en laat die als eerste los. Je hoeft niets in één keer om te bouwen.
Wat als ik wil koppelen aan onze eigen software of ERP?
Dat kan via het Dashboard, waarmee je tools beheert en koppelt aan ERP en andere software. Zo houd je een onderhouden basis voor het generieke werk en haak je je eigen integraties en maatwerk daarop aan. Wil je het zelf ervaren? Je kunt Thundercad 30 dagen gratis proberen zonder creditcard, op je eigen Inventor-omgeving en projecten.
You know the moment. For the umpteenth time you run through the same string of actions in Autodesk Inventor: filling in iProperties, turning drawings into PDF and DWG, exporting a bill of materials to Excel. And you think: there has to be a smarter way. The obvious route is iLogic. You write a few lines of code, hook a button to it, done. But then it grows. One script becomes ten. A colleague asks if you can quickly fix his variant. And one day, usually right when you happen to be on holiday, something grinds to a halt and someone asks: who actually maintains this?
That is exactly the point at which many engineering departments start looking for an iLogic alternative. Not because iLogic is bad, it is a powerful piece of tooling, but because building it yourself has hidden costs that only become visible once the script is already deep in your process. In this article we lay out the two routes honestly side by side: automating yourself with iLogic and standalone scripts versus a maintained toolbox such as Thundercad. No sales pitch of "scripting is dumb", because it is not. Instead a sober trade-off of maintenance, Inventor updates, team dependency and coherence, so that you make the right choice for your situation.
What iLogic is and is not
iLogic is the built-in rule engine of Inventor. You write rules (essentially VB.NET) that drive parameters, suppress features, read and write iProperties, or build complete configurations. For parametric, product-specific logic that is worth its weight in gold. Think of a stair manufacturer who enters height, width and number of steps and lets a complete model roll out of that. Or a machine builder with a standard conveyor belt that is supplied in lengths of 1 to 12 meters, where the frame, the number of support legs and the drive adjust themselves automatically. That is iLogic at its best: knowledge about your product, captured in rules.
What iLogic is less suited for is generic, recurring production work that is the same on every project. Publishing all drawings of an assembly in one go. Managing metadata consistently across all your document types. Opening an assembly of 200 parts at lightning speed and then closing it neatly again. Getting a bill of materials into a fixed Excel template that purchasing can read straight in. Those are not product-specific rules, but workflow actions that are largely the same for every Inventor user. And that is precisely where building it yourself often starts to chafe.
The difference lies in the nature of the problem. Product logic is unique to your product and belongs with you: no one else knows your configurations and build rules. Workflow automation is generic; every Inventor department struggles with the same export dialogs and metadata fields. If you build that yourself, you are reinventing the wheel, and you keep maintaining it yourself afterwards too.
The hidden costs of building it yourself
Writing a script is cheap. Maintaining a script is not. That is the heart of the trade-off, and the reason so many departments consider an iLogic alternative as soon as their first collection of scripts has grown into a tangle that no one fully oversees anymore.
Maintenance creeps into every corner
The first script works perfectly. The second one too. By the seventh you discover that they get in each other's way: one user runs a modified version, another the original, and no one knows anymore which one is the "real" one. Someone changes the folder structure on the server and half the export scripts trip over a path that no longer exists. A template gets an extra iProperty field and your BOM script suddenly spits out empty columns. Maintaining home-built automation is not a project with an end date: it is a fixed cost that never goes away. And it gets in the way precisely at the busiest moments, because errors only show up when you have to deliver a set under pressure.
Inventor updates break things
Autodesk releases a new Inventor version every year. Sometimes the API changes, sometimes a method behaves slightly differently, sometimes a function disappears. With a maintained toolbox that is the vendor's concern: they test against the new version and ship an update. With your own scripts it is your concern, and usually at the worst conceivable moment. Suppose the whole department has just switched to the new version because a customer asked for a model in it, and then it turns out your publish script no longer runs. Now you are stuck with production waiting and a colleague who has to figure out, between his own deadlines, which API call has changed. That bill is hard to estimate in advance, but it comes back every year.
Team dependency: the bus factor
This is the quietest and most dangerous cost. Often there is one colleague, let us call him the script hero, who built everything and is the only one who understands how it fits together. As long as he is around, it runs. But what if he is on holiday for two weeks, gets sick, or finds another job? Then there is code in production that no one dares to touch, with variable names only he understood and without a single line of explanation. We call that the bus factor: how many people can get hit by the proverbial bus before your process grinds to a halt? With many home-built solutions the answer is: one. And that is a risk no engineering manager would consciously choose if he saw it spelled out in black and white.
Tip: Want to know how vulnerable you are? Ask yourself whether a random colleague could modify an existing iLogic script tomorrow without the original builder present. If the answer is no, you have a team dependency that you are better off making visible before it turns against you than after.
Coherence is missing
Standalone scripts are exactly that: standalone. Each script has its own button, its own logic, its own assumptions about folders, names and settings. There is no shared configuration, no consistent interface, no overarching management. A new employee has to learn one by one which button does what, which order is correct and where the pitfalls are, usually by getting something wrong once. A toolbox designed as a coherent whole offers one way of working across all tools: the same settings, the same logic, the same behavior. That saves enormously on onboarding time and on the kind of mistakes that arise because one tool works just slightly differently from another.
Curious whether a maintained toolbox can replace your tangle of scripts? Install Thundercad and test it in your own Inventor environment, on your own projects, no credit card required.
Try 30 days freeiLogic alternative in practice: the direct comparison
Enough theory. Let us lay the two routes side by side on the points that matter in daily practice. The table below summarizes what you get and what it costs you: not only in euros, but in time, risk and peace of mind.
| Aspect | Build it yourself (iLogic / scripts) | Maintained toolbox (Thundercad) |
|---|
| Startup cost | Low, a few hours of scripting | Subscription per user |
| Maintenance | Ongoing, internal, never finished | Handled by the vendor |
| Inventor updates | Your problem with every new version | Solved in updates |
| Team dependency | High, often one script hero | Low, no one indispensable |
| Coherence | Standalone buttons, own logic | One way of working across all tools |
| Onboarding a new colleague | Verbal handover, pitfalls | Consistent interface, documentation |
| Product-specific logic | Strong, this is where iLogic excels | Not the focus |
| Generic production work | Build it again every time | Ready to use, immediately usable |
| Risk when the builder leaves | Process can grind to a halt | None, knowledge sits in the product |
The table makes one thing clear: it is not a question of good versus bad, but of the right tool for the right problem. iLogic wins on product-specific logic. A toolbox wins on generic, recurring production work where coherence and maintenance weigh heavier than custom work. The mistake departments make is not that they use iLogic, but that they also deploy iLogic for generic work where it offers no advantage and does create a maintenance burden.
Do the math: what does building it yourself really cost
Let us take an example, clearly presented as an assumption. Suppose an engineer spends two days building a batch publish script that turns drawings into PDF, DWG and DXF. That seems like a one-off and therefore "free after the first investment". But do the math further. Every new Inventor version costs, say, half a day of adjusting and testing. A changed folder structure or a new template costs another few hours. A colleague wants an extra format added: another afternoon. And when the builder leaves, onboarding a successor, or rebuilding the script from scratch, quickly costs several days.
Add that up over a few years and "two days" is no longer two days at all. And these are engineering hours: the most expensive and scarcest hours in the building, which you would rather spend on design than on repairing a PDF export script. With a toolbox such as Thundercad you do Batch Publish in one click instead of twelve steps, and you save, for example, 48 PDFs in 6 seconds, including collaboration with Autodesk Vault. No maintenance, no version stress, no dependency on one person. Whether the subscription is worth it depends on your situation, but the sum often works out very differently from the gut feeling that "building it yourself is free".
What a maintained toolbox covers in concrete terms
To make it tangible: a toolbox takes over precisely those generic, recurring actions where building it yourself demands the most maintenance. At Thundercad it concerns, among other things:
- iProperty Menu: manage metadata and iProperties through one configurable data card per document type, instead of per script or by hand.
- Batch Publish: all production documents in one step: PDF, DWG, DXF and STEP, working with Vault.
- BOM Export: bills of materials to Excel in a fixed template, without having to maintain the export logic yourself.
- Batch Open & Close: open files in assemblies quickly and close them neatly again.
- Quick Save / Load: park work and bring it back exactly as you left it.
- Model Cleaner: remove leftover geometry and tidy up the browser.
- Sheet Buttons: scale the sheet size up or down and rotate.
- Dashboard: activate and manage tools, and link them to your ERP or other software.
That last one, the Dashboard with a link to ERP, shows where the two worlds meet. A toolbox does not close the door on custom work; it gives you a maintained foundation on which you can hook your own integrations. So you keep the freedom to build your real product logic with iLogic, while the generic work around it is covered. Companies such as Little Giant Europe, Van Egten, Banzo and Mannen van Staal already work with it to take exactly that repetitive work out of their engineering process.
On the roadmap, by the way, there are even more tools that are now typically solved with home-built scripts: Batch Flat Pattern, Find Item, a Drawing Checker/Cleaner and a Drawing Updater. Not available yet, but they show the direction: more and more generic manual work is shifting to a maintained whole.
So when do you choose what?
The honest conclusion is not "always this" or "always that". It is a trade-off, and it works out differently per type of work. Below is a rule of thumb you can apply directly to your own collection of scripts.
Choose iLogic / building it yourself when:
- it concerns product-specific logic that is unique to your product: configurators, parametric families, build rules that no one else knows.
- you structurally have someone in house who can build and maintain this, and you consciously accept and document that dependency.
- the problem is so specific that no existing product covers it and custom work truly delivers a distinguishing advantage.
Choose a maintained toolbox when:
- it concerns generic production work that is the same on every project: publishing, exporting, managing metadata, opening and closing assemblies.
- you would rather not carry maintenance, Inventor updates and team dependency yourself.
- you consider coherence and a consistent way of working across your whole team important.
- you want a new colleague to be productive quickly without someone having to come explain the pitfalls first.
In practice many departments choose both: iLogic for the real custom work that sets their product apart, and a toolbox for everything around it. That way you spend your scarce engineering hours where they make the difference, on the design your customer buys, and not on a PDF export script that can break with every update. The nice thing is that you do not have to prove that in advance on a spreadsheet: you test it on your own projects before you change anything about your process.
Frequently asked questions
Is a toolbox a replacement for iLogic?
No, and that is not the intention either. iLogic is strong in product-specific logic such as configurators and parametric families; a toolbox such as Thundercad covers generic, recurring production work such as publishing, exporting and managing metadata. Many departments use them side by side: iLogic for the custom work, the toolbox for the daily workflow around it.
What happens to my existing iLogic scripts?
You can simply keep using them. A toolbox does not replace your product logic, but takes over the generic actions you now maintain standalone scripts for. So you can switch over gradually: start with the scripts that cost the most maintenance or pose the greatest bus factor risk, and let those go first. You do not have to rebuild everything in one go.
What if I want to link to our own software or ERP?
That is possible via the Dashboard, with which you manage tools and link them to ERP and other software. That way you keep a maintained foundation for the generic work and hook your own integrations and custom work onto it. Want to experience it yourself? You can try Thundercad free for 30 days without a credit card, on your own Inventor environment and projects.
