.NET Interruption from LabVIEW

[EthanHenry]

Heyo,

        We've been having a problem for quite a while now with a SECSGEM driver.  It seems like there are times when connection is suddenly interrupted and get delayed or completely disconnected.  It only seems to happen with a single command, and it doesn't happen all the time.  We have a callback structure that watches the .NET events to trigger, however, logs show that sometimes when this command is called, it will run, and then a large amount of time before the next command is sent/answered.  It's almost like the pipeline is getting clogged for lack of a better term.  Anybody have any experience with LabVIEW losing/delaying windows events when using embedded .NET components?

[santo_13]

More details about the SECS/GEM driver will help understand it better on how it is used with your LabVIEW application.

Do you've any simple implementation of how your larger application architecture looks like?

[EthanHenry]

The Architecture of the Project is pretty simple, we register callbacks for the .NET Events. 

This works for the most part, however as I mentioned, after some time, it seems like the Callbacks just stop getting run.  At this point everything starts to error and spiral as Timeouts for replies are surpassed.  The Callback is just a shell we set up in an attempt to log all callbacks

And then the Vi it calls is just a simple state machine that parses, does the action, and replies.  The interesting part about the command that error is that it is the only command (that I know of) that has to wait for some time for other processes to complete before it can send the Response back.  The Logs show that all SECSGEM commands are sent as expected, however our LabVIEW logs seems to show that the callbacks just suddenly stop running all together.

[EthanHenry]

Interesting Breakthrough:  While testing, it seems like something interesting is happening when the UI is hung up.  I noticed that when a file selection window is openned, the callbacks are sometimes delayed and don't appear to be called.  when the file selector windows closes, all the callbacks are shot off right away.  This seems to correspond with some behavior we've noticed whenever there seems to be a delay, the customer complains that the UI is hung up and they can't control it at all.  Is there any reason why a blocking call could stop Callback functions from taking place?  

[Kyle97330]

Could be a "root loop" problem maybe?

http://www.labviewcraftsmen.com/blog/the-root-loop

Your opening a VI by reference there is a common trigger of the issue.

[EthanHenry]

Huh interesting, reading through the article and trying it out, I do think this may be the problem.  Using a One Button Dialog and/or a file path control does seem to block the callbacks from running.  That being said, is there anyway to get around this?  I tried putting it in a different thread (other 2) and even gave it the highest priority, but it still seems to get blocked.

[rolfk · Accepted solution]

Open VI Reference always is executed in the UI thread, because this is the one single thread that is guaranteed to prevent any race conditions. Open VI Reference has to access and update several global variables that record what VI resources are loaded and are regularly accessed by various GUI elements in LabVIEW, so by forcing this access into the UI thread it is automatically safe from race conditions.

You need to get that Open VI Reference out of that callback VI or you will block on anything that opens a dialog in LabVIEW (and long lasting functions set to execute in the UI thread, including Call Library Nodes to call external dynamic libraries that are set to execute in the UI thread). Do you really need to create a new VI reference on every call? Can't you allocated that at the time when you register your callback event and simply retrieve in the callback?

[Kyle97330]

If you open the VI reference by name (not path) and not typed, it doesn't need the root loop.  This means it has to be loaded in memory already and you can't use the connection pane to launch it, so that's not much of a help.

I had a problem similar to this.  I was managing a motion controller with 8 axes that might all need to move at once (with continuous polling to check its location and see if it finished moving), so I made 1 motion control VI to manage that and each time a separate axis needed to move, I started a new dynamic async call to a copy of that VI.

This was a problem because if someone opened a menu or whatever, no new motion control would start until they closed it.  My eventual solution was to pre-open 8 references to that VI during instrument initialization, and put them in an array, and call the one assigned to each axis when it needed to start a movement command.  When I was done with the instrument, I would close all 8 references.

I don't know exactly how your program is set up, but I suspect you could do something similar.  During startup, open references to N copies of each potential VI you need to call (with N being the most you would need at one time).  Store those references somewhere with whatever management attached to it that you need (to prevent two of the same one from being used at once, etc.).   Replace the "Open VI" call with a call to get one of those pre-opened references and you should be able to continue without the root loop.

[EthanHenry]

You're the MAN! This worked perfectly.  I thought that may be it, however because of the way I was monitoring whether the callbacks had been launched or not I seem to have misinterpreted the logs.  Moving the reference out works flawlessly (as far as I can tell).  I'll have to go back and make sure there wasn't a specific reason we openned a reference each callback, but having it not be blocked is a huge amount of progress.  Thanks!