Sending an API command while Inventor is busy causes crash; how to fix?

[Anonymous]

I'm writing a C# application using the Inventor 2016 API to automate the creation of some custom assembly drawings. After making only subtractive changes to an assembly model (removing components) and calling AssemblyDocument.Update2(true), Inventor labors for anywhere from 2-5 minutes performing the model update. Now here's the problem: as soon as Update2 is called, the .NET application is ready to send another command to Inventor, but for those following few minutes during the update operation, Inventor is "unresponsive," showing Windows 7's "spinning blue swirl" (though not truly unresponsive in the Win32 sense, where Task Manager would show it as such). The next command I call after Update2 is AssemblyDocument.SaveAs("path", true), but this crashes Inventor unless I wait those few minutes for it to finish its update.

So far I have tried:

• Looking at System.Diagnostics.Process.Responding. It is always true during the update operation.
• Looking at Inventor.Application.CommandManager.ActiveCommand. This is always the default command. (cf https://forums.autodesk.com/t5/inventor-customization/check-inventor-is-idle/m-p/6017453)
• Using a timer to delay call of the SaveAs method. This works, but is an unacceptably fragile solution.

It seems to me that this must be an issue encountered before, but I'm not really finding any information out there. Anyone with some insight? Thanks!

[adam.nagy]

Hi,

Would you be able to provide a non-confidential set of files and a small sample code that would enable us to reproduce the behaviour?

Concerning ActiveCommand. I assume you are not creating a command for your program and run the code from it, so the ActiveCommand would be the DefaultCommand.

I could not find anything logged against Update2() not executing synchronously. What about using Update()? Does that have the same problem? 

If this turns out to be an issue then maybe placing your code inside a command, running that synchronously, and then waiting for the OnTerminateCommand() event to run the SaveAs part might be a workaround. We'll see.

Cheers,

[Anonymous]

Hi Adam,

It would be difficult to provide any non-confidential example model here, but our company has a support agreement with Autodesk, and we have an Autodesk implementation consultant with whom we may be able to work something out. I will try to get in touch with him.

Both Update() and Update2() result in the same behavior. I'm using Update2() to provide the "accept errors and continue" option. It's probably worthy of noting that other API calls prior to Update2() also cause Inventor to appear busy while my program is ready to proceed to other calls... it isn't only Update2(). But Update2() seems to be the only one that, if another call is made before Inventor is "done", throws an exception and crashes Inventor. The calls made before Update2() are: OccurrencePattern.Delete(), ComponentOccurrence.Delete(), and BrowserFolder.Delete().

---

If this turns out to be an issue then maybe placing your code inside a command, running that synchronously, and then waiting for the OnTerminateCommand() event to run the SaveAs part might be a workaround. We'll see.

---

I'm unsure what you mean by this, and I suspect that "placing [our] code inside a command" isn't something I've done with the API before. It sounds at least somewhat promising. Could you link to more information about this? (When I refer to "executing an API command", I mean only executing a line of code that accesses the Inventor API.)

[adam.nagy]

Hi,

This is how you can run things inside your own command.

Here is a VBA sample.

E.g. have a class named "MyCommand" with this code:

Option Explicit

Dim WithEvents bd As ButtonDefinition

Private Sub bd_OnExecute(ByVal Context As NameValueMap)
  Dim ie As InteractionEvents
  Set ie = ThisApplication.CommandManager.CreateInteractionEvents
  
  ' Set name of ActiveCommand
  ie.Name = "MyCommand"
  Call ie.Start

  ' Do something as part of the command
  Call MsgBox("ThisApplication.CommandManager.ActiveCommand = " + _
    ThisApplication.CommandManager.ActiveCommand)
    
  Call ie.Stop
End Sub

Private Sub Class_Initialize()
  Dim cm As CommandManager
  Set cm = ThisApplication.CommandManager

  Set bd = cm.ControlDefinitions.AddButtonDefinition( _
    "MyCommand", "MyCommand", kNonShapeEditCmdType, , "MyCommand", , , , kAlwaysDisplayText)
    
  ' Run it Synchronous=True
  Call bd.Execute2(True)
  
  ' If it was really synchronous then by the time we get
  ' here we're done and don't need the command anymore
  Call bd.Delete
End Sub

Then instantiate it from a module:

Dim mc As MyCommand

Sub RunMyCommand()
  Set mc = New MyCommand
End Sub

This way while your command is running, the ActiveCommand will be "MyCommand" and OnActivateCommand/OnTerminateCommand events should fire as well.

PS: I have a couple of largeish assemblies I just could not make Inventor think too much after an Update yet.

I'll try to find a way for that.

Cheers,

[adam.nagy]

Got a comment from a colleague that you could also try just simply running the "Update" command synchronously from your original code: 

http://modthemachine.typepad.com/my_weblog/2009/03/running-commands-using-the-api.html

I assume that would be the "AssemblyGlobalUpdateCmd":

Public Sub RunUpdateCommand() 
    ' Get the CommandManager object. 
    Dim oCommandMgr As CommandManager 
    Set oCommandMgr = ThisApplication.CommandManager 

    ' Get control definition for the line command. 
    Dim oControlDef As ControlDefinition 
    Set oControlDef = oCommandMgr.ControlDefinitions.Item( _ 
                                                 "AssemblyGlobalUpdateCmd")  
    ' Execute the command. 
    Call oControlDef.Execute2(True) 
End Sub

More info on Execute and Execute2:

http://adndevblog.typepad.com/manufacturing/2015/02/execute-vs-execute2-of-controldefinition.html

[adam.nagy]

"we have an Autodesk implementation consultant with whom we may be able to work something out. I will try to get in touch with him."

Did you do that in the end? Any luck?

Did either of the workaround ideas I came up with was of any help? 😕

[Anonymous]

I did try your suggestions but didn't have any luck with them. Our Autodesk consultant set up a session with an Inventor specialist and myself, and we determined that the crashing problems are resulting from some components in the assemblies not being migrated to the latest version of Inventor. It wouldn't seem like migration is necessary, but sure enough after migrating all the components and assemblies, our crashing problems disappeared. So it appears that what seemed on the surface like one issue was really another. Since then, our focus has been entirely on migrating everything in our Vault, which has been dogged with many setbacks and complications. Getting there though.

[adam.nagy]

Thanks for the info!

I'm just glad you're not stuck on this! 🙂

[DynamicObjects]

Hi Adam - i think i am experiencing the same issue.

I am putting a Thread.Sleep(36 seconds or more) in my c# code after any COM call to the following Inventor methods in order to avoid moving on to the next api call too quickly...

• myAssembly.Update()
• myAssembly.Save()
• myAssembly.Close()
• InventorApp.Quit()

 (that's not an exhaustive list btw, it's just the ones i have currently noticed and am troubleshooting)

The Thread.Sleep() is not required for assemblies less than about say 500 parts - but where we get the COM errors is when our assemblies are typically 1000 to 5000 parts.  In my case, we are not using Vault and all our parts are created in Inventor 2016 - and so we do not have the underlying issue of badly migrated parts that the OP had.

So it seems to me that our c# code moves on to the next call even though Inventor is still actually busy finishing the .Save() the .Close() or the .Update() methods.  

I really don't like the vulnerability of the Thread.Sleep() workaround.  How long a sleep is enough?? - depends on the assembly!

So I shall follow your advice above and try to swap out our API calls above for the equivalent command and call the command with the Execute2() method as you advise.  I will report back if this is successful.

However, is this as issue that can be properly addressed by Autodesk so that the vulnerability in the API is removed in future releases?

Please advise

regards

Dan

[Anonymous]

I am putting a Thread.Sleep(36 seconds or more) in my c# code after any COM call to the following Inventor methods..

-  myAssembly.Save()

-  myAssembly.Close()

- InventorApp.Quit()

Actually, after eliminating this issue in Inventor 2016 (as I stated above), it was back in 2018. This is exactly what I ended up having to do in Inventor 2018 after struggling with it for an unreasonable amount of time. Not an elegant solution, but it works. The crash could never be duplicated when stepping through the code, so I concluded it had something to do with the timing of COM calls.

[chandra.shekar.g]

Hi @Anonymous,

Try to add the following C# code after every update() API call.

Inventor.Application m_inventorApplication;
m_inventorApplication = (Inventor.Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Inventor.Application");
m_inventorApplication.UserInterfaceManager.DoEvents();

The DoEvents() API call will allow the Inventor to complete its update and then back to the Inventor to proceed.

Please feel free to contact if there is any queries.

Thanks and regards,

[dba78]

Actually I'm dealing with some similar issue. The UserInterface.DoEvents (as Chandra described in Message 11) worked for my case, I believe a better apporach were to introduce an "Application.Idle" event (like the "Editor.EnteringQuiescentState"-Event in Acad) to be fired, when Inventor is really ready for the next command, or even better a Read-Only Property "Application.Idle". Currently there is only an Application.OnReady Event, which fires on AppStart only...

Alternatively the TransactionManager.CurrentTransactoin could be cast as null if the default UI-Transaction is running (though this would return false result on nontransacting commands, like Measure). 

I really hope, the "idle" State/Event will be considered to implement in future releases (maybe it's already in the idea station - didn't check )

BR,

Daniel

[chandra.shekar.g]

@dba78,

Please log this wish list at idea station using below link.

https://forums.autodesk.com/t5/inventor-ideas/idb-p/v1232

Thanks and regards,

[bradeneuropeArthur]

@Anonymous

Does this solve the problem

Public Sub main()

Dim a As inventor.Application
Set a = ThisApplication

If a.Ready Then

'PUT YOUR CODE HERE

Else
MsgBox "Not ready try again"
End If
End Sub