Conveyor and LoadPlugIn error

We’re using Rhino Conveyor in Revit and experiencing the following error when loading Rhino objects:
“LoadPlugIn cannot be called while a plug-in is being loaded”

We have identified the error to take place in a plug-in that we use to load additional plugins from a network location. The LoadPlugIn() method is called during the RhinoApp.Idle event that works fine when Rhino runs as a standalone application (similar to this), but Conveyor launches Rhino in an automated state and when the idle event is called Rhino appears to still be in a plug-in loading state. We also noticed that while Rhino is running as a background process, the RhinoApp.IsRunningHeadless property is set to false, which isn’t what we expected and so we can’t use this as a condition for calling the LoadPlugIn() method. We also tried using the property RhinoApp.IsRunningAutomated, but we’re still experiencing problems with some of our users.

Does the idle event function the same when Rhino is automated or not? Is there another way to call LoadPlugIn during startup? Is there a way to know if Rhino was launched by Conveyor?

Rhino Version 6 SR18 (6.18.19266.14201, 9/23/2019)
Conveyor Version 2019.10.4.0


Hi all,
To add some additional context here: we are using a COM connection to automate Rhino externally and send a series of Rhino script commands. It appears that the code @ian_sheardwright is using in their custom plugin is having Rhino enter an idle state before the PluginManager has fully loaded and the LoadPluginMethod() method is failing as a result. Is there a difference in how Rhino loads plugins in automated mode vs when a user opens Rhino normally?

It appears they have a plan of attack to catch when Rhino is running in an automated mode and continue accordingly. Are there any other things we can be doing to factor this in?


Any thoughts @scottd or @stevebaer? Sorry for the callout but this is mission critical for a deployment that is currently in progress. Thanks Ian and Nate for getting into the weeds on this!


@kike - may also need to look at this.

Hi @ian_sheardwright, @archinate1, @marcsyp:

This message is displayed when a plug-in is loading, and that plug-in is doing thing when it is loading (perhaps in a constructor on in a PlugIn.OnLoad override) that triggers the loading of another plug-in.

In programming-ese, the internal Rhino function that loads a plug-in cannot be called recursively.

Not sure this helps anyone…

– Dale

We’re calling LoadPlugIn from the RhinoApp.Idle event, which works when we run Rhino as a standalone application, but doesn’t work when automated (here). For now we’re using the RhinoApp.IsRunningAutomated property to avoid calling LoadPlugIn(), but we would like to be able to call the method in both automated and normal modes.

What if you register for the Idle event right at the end of your OnLoad callback?

I do agree that this is something @kike should take a look at since it involves running inside of Revit.


Well, seems like here Rhino is not running inside of Revit, in that case it’s called as a COM external process right?.
I have no experience running Rhino that way, but I can take a look to it for sure.

Since you are running script commands why not relay on the fact that Rhino loads plugins on demand when a command runs the first time? doesn’t it work either?

My guess is while loading those plugins, your plugin or Rhino itself is doing UI stuff. Maybe updating a progress bar or maybe showing a message box popup, this eventually may kick in the Rhino message loop, and the last thing the message loop does is calling OnIdle if there are no messages.
Does any dialog popup while plugins are loading in the Rhino side?

What @stevebaer said has a lot of sense because makes this less probable to happen. Does it fix anything?
If this is the case, we may try to avoid calling OnIdle while a plugin is being loaded.

In order to reproduce it here, may I have access to some prototype that shows the problem?
Do you have a C++ or .NET plugin in the Rhino side?

1 Like

Thank you @stevebaer, this was a great thought but unfortunately didn’t fix the issue. For now it seems we have a workaround for our current use case with the RhinoApp.IsRunningAutomated property, but I’ll follow-up with @kike and send a prototype to reproduce the problem. Thanks again!

1 Like