What are plug ins used for?

What are plug ins used for?

TK.421
Advisor Advisor
1,371 Views
5 Replies
Message 1 of 6

What are plug ins used for?

TK.421
Advisor
Advisor

i know a lot of users use plug ins with powermill. what kinds of things do you use them for? What makes it worth the time to write a plug in? I've written a ton of macros to help automate powermill, but not a plug in. I'd like to write one as i feel that is the next step in automating even further, but I'm at a loss for how i would use one? what can I do with them?

 

thanks!


the numbers never lie
0 Likes
1,372 Views
5 Replies
Replies (5)
Message 2 of 6

Anonymous
Not applicable

A plugin allows you to interface with the software in almost any custom way imaginable. It allows you to access object information in your sessions, such as tool properties, toolpath info and settings, etc. You can then do things with these objects to help automate processes similar to the macros you have written in the past, but with a much more robust arsenal at your disposal. 

 

For instance, i created a plugin that automatically creates setup sheets for each NC program in a session and prints them to the user's printer as well as save a pdf copy in the proper network location. 

 

Another example, we couldn't get the built in tool database module to function the way we need it to, so i created a plugin that is a modified version of the tool database form which works as desired. These are a little more advanced and require a bit of knowledge of VB.NET or C#, but it gives you an idea of the potential. 

 

There is also the new API (primarily what is discussed on this forum) which can accomplish much of the same as the plugin interface. Either way you will need to get familiar with a small amount of VB or C#, if you are new to coding i would recommend Visual Basic. the API documentation is much shorter/easier to get started than the plugin doc, which can be found on your C:\ drive in this location:

 

C:\Program Files\Autodesk\PowerMill 2018\file\plugins\documentation 

 

The API doc can be found at the top of this forum in the sticky thread that Luke Edwards has put together. Walking through that and creating your own project will give you a good starting point

 

Good luck!

 

 

 

Message 3 of 6

TK.421
Advisor
Advisor

thanks for the reply. I guess I'm limited then by my imagination. Here's a follow up question: It seems an API would be easier to create than a plug in (just a console application, correct?). Could I create an API to take my posted program from it's location and copy it to an different location? If I already have a lengthy macro that I don't want to re write in an API , is there a way to call it from inside the API?

 

One more: Can an API gather information from one open powermill session and use it in another open session?

 

Thanks again!

 

David


the numbers never lie
0 Likes
Message 4 of 6

Vasago
Advocate
Advocate

From my experience at work I can say that both macros and plugins can coexist in the same environment, I think the simple macro has more use in day to day, more speed of response in the work for certain jobs that require A direct push, and the plugin is more for automating arduous tasks with which you find yourself daily. They have their advantages and disadvantages, but the two are direct to the solution of a problem.

Message 5 of 6

VitorMartinsAugusto
Advocate
Advocate

Hi,

 

For automation you have these options:

 

1) Macro language:

 

Pros:

- can do most things

- will work on any open PowerMILL session

- can be easily deployed

- can be easily integrated in custom menu bar, user menu, etc.

 

Cons:

- cannot hide/protect the source code

- very limited user interface

- difficult to maintain big projects

- difficult to access/manage files or other Windows functionality

 

2) Visual Studio App (i.e. VB .net)

 

Pros:

- can do most things

- easy to debug

- great user interface

- allows protecting the source code

 

Cons:

- more difficult to deploy, but still pretty easy

- only works with the FIRST PM session

 

3) VBScript embedded in HTML page

 

Pros:

- can do most things

- great user interface

- works on any PM session

 

Cons:

- source code cannot be protected

- slightly harder to program (hint: do it in VB .net first and then convert to VBScript)

 

4) Plugin

 

Pros:

- can do most things

- RECEIVES EVENTS! When user creates entity or activates entity, the plugin receives an event -> this is the coolest thing of the plugin!

- great user interface

- works with any PM session

- works within PM window

- can protect source code

 

Cons:

- much harder to develop (by several magnitudes)

- requires development knowledge on .net, windows, etc.

- harder to deploy

 

Regards,

Vitor

 

Message 6 of 6

Anonymous
Not applicable

In addition to the great response by Vitor, there is an intermediate/hybrid option between Macro Language and Visual Studio App (let's call it 1,5). You can create an application using the IDE you prefer (Visual Studio mostly recommended but paid option for commercial purposes) and using your preferred programming language, c# or vb (I recommend c#), and within that app call a previously created/recorded macro using the API.

 

It is a hybrid because you can reuse macros in a custom program, but, as Vitor stated, the code in that macro is not protected, is in a file that can be accessed to. You could embed that file within the executable of the program to further protect it but despite it should work I haven't tried this approach because I prefer using the API.

 

Regarding the API vs Plugin, let me try to explain something that I think it might be confusing you. You actually would not be creating an API, but using one (PM and PS API). An API allows you to access the functionality of a software, but can be restricted to what the provider (i.e., Autodesk) wants. It’s like a window to all the functions implemented in PM and PS, but the window can be small/restrictive or big/full access/maybe dangerous.

 

Example, you create an application, you include the PM/PS API and call that API to import a model in PM. You now have access to that model within your program and you can do whatever you want with it (or what the API lets you do), such as create Tools, Toolpaths, NCPrograms... You can also show the 3D view of PM/PS on your program for example. As for the limits of the API, you can always use a special command included in the API called “Execute” which allow you to execute the same commands as you would in a macro or in the commands window of PM.

 

If you already knew this API stuff sorry to over explain, but I think it’s always worth it to have everything clear.

 

Regards,

 

Carlos.