Understanding Macros, AddIns, Plugins and iLogic Rules

Understanding Macros, AddIns, Plugins and iLogic Rules

amarinXG8V6
Advocate Advocate
842 Views
5 Replies
Message 1 of 6

Understanding Macros, AddIns, Plugins and iLogic Rules

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)
843 Views
5 Replies
Replies (5)
Message 2 of 6

Pineapple2024
Advocate
Advocate

I'll say addin and plugin are the same.

A dll file in the addin folder.

You can use VBA macro to do quick test of code.

 

And you posted the same thing a few times.

 

Addin is the most flexible but also the most demanding.  A lot more code to do simple thing.

 

I started with macro then addin.

Using iLogic for a few thing now and will need to go back to addin.

Message 3 of 6

amarinXG8V6
Advocate
Advocate
Thank you for the feedback. I apologize for the multiple posts. My forum was in a constant state of loading and so I refreshed the page and clicked post multiple times. As far as flexibility, the Addin/Plugin is the way to go. I wonder why Inventor has 2 separate folder for Addins and Plugins if they are essentially the same thing?

Thanks again!
0 Likes
Message 4 of 6

Pineapple2024
Advocate
Advocate
Accepted solution
Message 5 of 6

amarinXG8V6
Advocate
Advocate

That's interesting. Seems like the best place to put .addins that you intend on sharing with other users through and installer or update script is either in the version dependent or version independent location. It's interesting because in the paragraph regarding this topic, Inventor developers are basically saying that both are good but they don't really give a valid reason why version dependent would be better than version independent. It seems like the most logical place to store .addins would be in the version independent location if Autodesk makes significant efforts to allow the API to be upward compatible. I would think that it would also be on the individual developers in this case (me or my team) to compile and test the .addins when we migrate to a new version of Inventor as opposed to duplicating .addins in multiple version dependent locations. Does this seem like a logical interpretation or am I missing something? Maybe there are other benefits to having the .addins compiled for different versions.

 

What are your thoughts?

0 Likes
Message 6 of 6

Pineapple2024
Advocate
Advocate

Version dependent if you run multiple version of IV.

Used to had 4 versions.  One is beta and one latest for testing addin and other functions.

 

Per User if different users on same computer require different addin.

 

I put mine in Per user.  Version can be mixed for different addin.

AddinFolder-01.jpg