Create an Inventor HSM API

[al.whatmough]

We are starting to work on delivering an API for Inventor HSM. This will be made available as a COM library, similar to Inventor’s own API. We are very interested in your feedback regarding what kinds of things you’d like to be able to do in an Inventor-based API.

Initially, we would likely support capabilities along the lines of those supported in the APIs within Fusion 360 and HSMWorks, for example:

• Access to the list of operations in a document
• Generating/regenerating toolpath data
• Checking availability of toolpath data
• Post processing
• Setting model geometry

We expect to be able to leverage an API in Inventor HSM to be able to enable interesting iLogic-based workflows. We’d love your feedback of what you’d do with such a capability.

[ArjanDijk]

I talked to a customer today and we came up with a great usecase:

Make a webpageform containing the most critical values of a CAM program and be able to adjust and repost without touching the Inventor PC. This could be done one a tablet @machine

1. So for a 3D piece: Form field: "Axial Stock to leave" to -0,1 
2. For a cilindrical turning piece (suggestion from customer)  adjust front diameter with ,01mm to compensate for taperedness (is that a word?) of the machine

For this the following conditions are needed that are not possible today:

• Adjust operation parameters from API
• Select operation(s) to post
• Post and set filename.
• Automatically send via HSM edit (don't expect this point to happen)

I think this is "low hanging fruit" but it kills the argument of a machinist that he is faster adjusting a program at his machine.

[eric_hagenaars]

very glad that this is finally happening

now we can work on a totally automated production proces

Eric

[jeff.pek]

Hi all -

An update on this. We have been working on getting what I would call a "basic API" working. A dev build should be available soon with what we have so far. (Note that we did not add this to the R4 update).

Briefly, the current capabilities include:

 - Getting an "HSM Document" from an existing Inventor Document. This gets access to the CAM data in the document.

 - Getting the list of operations (including setups, etc.) from the document.

 - Generating toolpath for a set of operations.

 - Post processing a set of operations.

We need to add more items from the suggestions above, such as setting model geometry based on input Inventor objects. I'm also interested in limited ability to create new operations -- e.g., from templates.

I'm interested in the Vault suggestions above -- what sort of information do you see made available as Vault properties?

Thanks for your ides and suggestions!

Jeff

[matthias.schindler]

Hi,

I've seen that the API should be available in a Inventor HSM 2019 Build, but haven't found any reference or documentation of it.

It is planned to develop it for users?

Many thanks!


Regards

Matthias

[BrianEkins]

It seems to me that as far as being able to create and modify setups and operations, the simplest approach would be to be able to create the desired setup or operation manually and then save it as a "template".  In this step, you would set all of the settings the way you want and then be able to save it.  Then through the API you can use this template to create a new setup or operation.  Then there could be minimal functionality on the API objects representing the setup or operation instead of trying to expose every little setting.  The main things would be geometry and possibly tooling. 

With this, someone could write smart geometry creation tools that would create features but the features would have additional information about what they're for and then this can be used to automatically create the desired toolpaths.  For example, I might create a mold base design package and instead of just placing holes, it would have commands to place cooling line holes, and leader pin holes.  The CAM program would then find these holes and add the appropriate operations to machine them correctly.  For example, I might just drill the cooling lines, but the leader pin holes will need to drilled and reamed. 

With this, once you have a "smart" model, the CAM is automatic.  Using templates makes it easier because most of the settings can be defined using the UI, where most people are more comfortable, and makes it easier and faster to implement and support because there is less API.

[scottmoyse]

@BrianEkins the toolpaths, within the templates have inputs which need to be tied to geometry. Without API access to those inputs, how could you associate the toolpath to the geometry?

[BrianEkins]

After creating an operation using a template, it probably wouldn't be able to compute.  It would be like an operation that lost its geometry.  In some cases, just using the model geometry defined in the setup might be enough, but most operations will require more.  Using the API, the programmer would add the geometry to the operation so it would be complete and can compute successfully.  With this approach, you can pick and choose which geometry would be available through the API.  Of course, ideally all of it will be but it would be possible to do it in stages.   For example, for a 2D adaptive you might expose the ability to define the pocket selections but not the stock contour selections until later if you felt that was not commonly used. 

It could be that there are settings that would exist in the template but their values tend to change a lot depending on the geometry so it would be good to also expose those through the API.

One big advantage of the template approach is that every setting should always be saved in a template.  So if new features are added to CAM, a user to re-create their templates with desired settings for those new features and not have to wait for those settings to be exposed in the API to use them.  And they would be able to set even obscure settings that may not ever have enough priority to be exposed in the API.

[scottmoyse]

Yeah I agree with this template style approach as long as the important stuff has been exposed in the API still. I think I can agree solidly with your last comment.

[jeff.pek]

This is exactly the approach that we're talking about. We are also working closely with the iLogic team to try to expose aspects of the API in interesting ways (e.g., capture current state) to make working with the API in iLogic easier.

And yes, even if you create operations, etc. via templates, you would need the ability to set/update geometry and selected other parameter values.

Jeff

[ArjanDijk]

Good discussion guys! Indeed being able to insert a template of a setup would mean the world.

If you can start with a few clicks by inserting a setup that has a part zero on the right place, a few standard operations with feeds and speeds that match the choosen material and a program name and number that match to company policy, work would be much easier.

What I still miss is communication between the CAD envoirement and the NC code. Much of the time there is data stored in the CAD model that needs to translate somehow to the code. There is no way to tell from the API (for example based on model geometry what the axis limitations need to be.) what information whould be in the NC code. This would also open up posibilities to add "in operation parameters" like "it needs to output M0 15mm above the part before starting this operation", or "it needs to start cooling only then it starts machining in this operation". You can put some things like this in manual NC passthrough but it will never be in the operation where you want it.

The easiest way to tranfer data would in my opion be the operation "notes". If these could be writable, we would me able to go ahead. I think this can be a small challenge 

[Anonymous]

Hello,

I've searched for the COM model, but was unable to find it in my Installation (unlike Inventor, where the API and COM model is available via Autodesk.Inventor.Interop.dll).

In the Autodesk.InventorHSM.Interop.dll, nothing of use is visible (only enumerations regarding HSM Versions like Ultimate, Premium, …).

Is there a plan when to publish the COM? I have several use cases for that (e.g. implementing tool libraries with automatic cutting data calculation, etc.)…

Best regards,

    Carsten

[jeff.pek]

Hi Carsten -

We provide a InventorHSMAddinAPI.tlb file, which represents the type library interface, in the c:\Program Files\Autodesk\Inventor HSM 2019 directory. This should give you access to what's available in the API.

Jeff

[dylanTEV9W]

Hello, 

I'm trying to get access to the Inventor CAM 2020 api. I found InventorHSMAddinAPI.chm in the help files and Autodesk.InventorHSM.Interop.dll in the R24 folder. I can't seem to get access to the InventorHSMAddinAPI object even though autodesk.inventor.interop is added as a reference to my project. Is there another component I'm missing?

Thanks for any help you can give me.

Dylan

[Anonymous]

I'm facing the same exact issue as dylan's.

I can access the plugin and load the `Automation` object, but I cannot access `Automation.HSMDocuments` objects that's fundamentally the root of the CAM Api, according to the help. For instance, code below is not working:

Option Explicit

Public Sub MyExplorer()
    Debug.Print ThisApplication.Caption

    Dim hsm As ApplicationAddIn
    Set hsm = ThisApplication.ApplicationAddIns.ItemById("{749E667C-2560-416A-A5E7-68B96FF997B1}")

    Debug.Print hsm.Automation.HSMDocuments
End Sub

Also, there is very, very limited behavior in the current API (Inventor 2020). AFAIK it's not possible to create operations, most stuff looks read-only.

Is this being taken care of, and if yes, is there an ETA ?

[skunkworksllc]

This is an old thread I am resurrecting. Is there any buzz, updates, or news about future plans for this API? I am about to move our massive CAM automation system from AutoCAD/Autolisp/ARX (Mechanical Desktop 2009) to Inventor and it would be nice to leverage an existing CAM to do the heavy-lifting instead of completely rewriting our own as we did originally in the early 90s.

Is this a you-asked-for-an-API-and-here-it-is checkbox scenario?

Or is there ambitions to give the people what they want?

Just looking for some direction before I spend the next six months of my life going in the wrong direction.

[Anonymous]

Hi skunkworksllc,

We also needed fully automated CAM generation at my company, and in the end the only tool that we identified as capable to get the job done was FeatureCAM.

It's been pretty tough to set up initially, but the great features for us of this software is its complete COM32 api, which lets you control the entire software from any script language, and its automated feature recognition which is not totally smart but still capable to identify machining operations without a single button click. Even though it's not detailed at all, the documentation is complete, and the API is intuitive, it follows tightely what the interface/UX does and so by trial and error + using search it's pretty easy to figure out how to automate a given series of buttons and actions.

Now our system is able to generate CAM data from any STEP file, using a python script, in < 8 seconds. We've tried numerous other approaches, including Inventor CAM API, but Inventor is very lacking in terms of API and most of what we needed was not (and likely never will) be implemented.

However, the downsides is that FeatureCAM is hell to configure, it took us a lot of trial and error, and many of the relevant settings are hidden within submenus found in odd location. Getting good support is also pretty difficult, because Autodesk delegates this to 3rd party companies, whose instructors and support teams are either way too busy or sometimes not very well qualified.

Hope this help,

[dylanTEV9W]

I've personally found that you can do quite a bit with the very limited API that Inventor CAM has. With that being said I can't say I'd recommend it to most others. The Inventor CAM API is only available in VBA which is a deprecated language, the only documentation is this thread and a single program. I have not personally had any indication that Autodesk has anymore improvements or updates to Inventor CAM currently in the works. 

[jeff.pek]

A point of clarity: The Inventor CAM API is not only available in VBA. It can very easily be driven from C#/VB.NET, which are both quite modern environments. It's also accessible from C++, though that can be more awkward.

Jeff

[skunkworksllc]

remiAZUSZ,

Thanks for the reply. I’ve checked FeatureCAM out and it looks a possibility. I had really hoped for an extensive HSM/Inventor CAM API to form a tightly coupled automation solution inside Inventor. Introducing another CAM package adds another layer of complexity as data has to leave Inventor and move to FeatureCAM (beyond just STEP, as we pack a lot of intelligence into our designs). In this scenario I would likely use HyperMILL API since we are already using HyperMILL for our more complex 5 axis work. I really wish a software engineer from Autodesk could chime and let us know if Autodesk even has so much as an inclination to extend HSM API.