Understanding Macros, AddIns, Plugins and iLogic Rules (External)

Understanding Macros, AddIns, Plugins and iLogic Rules (External)

amarinXG8V6
Advocate Advocate
359 Views
2 Replies
Message 1 of 3

Understanding Macros, AddIns, Plugins and iLogic Rules (External)

amarinXG8V6
Advocate
Advocate

Hi everyone,

 

I have a bit of a loaded question here and I realize that I will likely get a lot of folks pointing me to already existing posts and that's all good 😊.

 

Here goes. I'm trying to understand the best approach to creating a custom Inventor environment that can be deployed via an installer to different users. Here's the scenario.

 

Assume I can create the installer myself. The goal is to have a brand-new user who just installed Inventor version 20xx (assume no older than 2022) run an installer that sets up their Inventor with all of the customization tools that my team and I have developed.

 

I'm currently struggling with understanding the differences between macros, addins and plugins. I understand how to properly use iLogic rules, specifically we use external rules because it's easier to deliver updated resources via an update script to user's computers. Assume that our application options paths stay with the directories that Inventor recommends when you first install it except that we convert the paths to variable types (%path%).

 

So now that part that I'm fuzzy on. We want to develop more robust tools than what can be handled in iLogic. I've done this in the past with a previous employer and we opted to do almost all of the automation with a custom .dll automation file and iLogic rules embedded in parts and assemblies. We essentially created a custom Frame Generator tool (back in the day when frame generator was quite finicky) and we developed BOM automation tools for exporting to ERP systems, drawing automation that created IDW's from scratch and placed multiple views of parts (sheet metal, extrusion, structural steel, etc) on sheets and drafted them out, ballooned assembly views, configuration tools that allowed customization of products, etc.

 

That being said, is the best approach to code our complex customizations (drawing automation, complex configurators, BOM output automation) in Addins (.addin) or Plugins (.addin/.dll) or Macros (.ivb)? I understand that we will also always have iLogic rules and that part I'm comfortable with. I'm not sure I understand when it's appropriate to create an Addin (using VB.NET) or a plugin (also using VB.NET) and what the difference is.

 

0 Likes
Accepted solutions (1)
360 Views
2 Replies
Replies (2)
Message 2 of 3

SReitberger
Contributor
Contributor
Accepted solution

Maybe you will find the following links helpful: 

IV Help - Getting Started with Inventor's API 

https://www.autodesk.com/autodesk-university/class/Creating-Add-Ins-Inventor-2018 

 

VBA seems to be at end of life (or close to). For example, the VBA installer has been moved out of IV installation since IV2021. (but it can be installed separately). IMHO you can use VBA macros for first programming tests to find a algorithm and needed API objects (because easy to start within IV, debugging, ... ). Also many sample programs are available in VBA (even in the IV help). But for "productive code" you should implement it afterwards in an Add-In or iLogic. 

 

iLogic is good to implement some automation into some IV files. "If dimension d0 is greater than x then set dimension d1 to y". Also to use event triggers. 

 

If you want to implement functions on the GUI of Inventor an Add-In could do this. Loaded on startup

Message 3 of 3

amarinXG8V6
Advocate
Advocate
Thank you for the resource links and explanation. I think this reinforces what I already suspected. Add-Ins are the way to go long term. I've also heard that C++.net maybe the longer term supported language as opposed to VB.net. All good things to note as I start down this new chapter of feeding the machine! Instead of creating the assemblies, parts and drawings I foresee myself just creating programming solutions to produce more work!
0 Likes