app hangs while ActiveX-Communication

[Joernh]

app hangs while communicating with an ActiveX-Object

Hi there,

is there anybody who can help me to understand why my application freezes while communicating with an ActiveX-Object?

I've just added a parallel while loop to my main application loop. In the added loop i do frequently access a dongle via its ActiveX-Component and it works fine, but....

The duration of the dongle-access is about 600ms and during this time, the whole application is hanging....waiting...sleeping.... even the frontpanel.

I thought that, because the ActiveX-Access is in a separate while loop, my application would not be influenced like that. :headbang:

Is this a "normal" behavior of LabVIEW or where's the problem ?!

Best regards

Joern

[m3nth]

My understanding of LabVIEW's automatic multi-threading is that it doesn't actually multi-thread stuff that's on the same block diagram, only when you're making function calls (subVI's) that can be started up in a different thread. For example (in my understanding) if there are two loop structures running in parallel adding up numbers, they're not really executing in parallel--LabVIEW switches back and forth between the two different loop executions to make it seem like it's happening in parallel. But if you took the contents of both of the loops and placed them each in their own respective subVI's, then it would have the capability to multi-thread the calls to the subVI's which would be parallel processed by the OS as compared to LabVIEW.

If the part of your code where you're communicating with the dongle is in a subVI, try changing the Preferred Execution System under the Execution settings for the subVI so it is not running in the default thread (same as caller). If the caller is running in the UI thread, then it's going to lock everything up (at least I have had problems somewhat similiar).

If that doesn't work or if your code isn't in a subVI already, I'd try taking the whole loop and putting it in it's own subVI and then tweaking the execution settings.

[Rolf Kalbermatter]

My understanding of LabVIEW's automatic multi-threading is that it doesn't actually multi-thread stuff that's on the same block diagram, only when you're making function calls (subVI's) that can be started up in a different thread.  For example (in my understanding) if there are two loop structures running in parallel adding up numbers, they're not really executing in parallel--LabVIEW switches back and forth between the two different loop executions to make it seem like it's happening in parallel.  But if you took the contents of both of the loops and placed them each in their own respective subVI's, then it would have the capability to multi-thread the calls to the subVI's which would be parallel processed by the OS as compared to LabVIEW.

If the part of your code where you're communicating with the dongle is in a subVI, try changing the Preferred Execution System under the Execution settings for the subVI so it is not running in the default thread (same as caller).  If the caller is running in the UI thread, then it's going to lock everything up (at least I have had problems somewhat similiar).

If that doesn't work or if your code isn't in a subVI already, I'd try taking the whole loop and putting it in it's own subVI and then tweaking the execution settings.

5208[/snapback]

While LabVIEW only opened 1 thread per execution system before version 7.0 it does in version 7.0 and higher open 4 threads for each execution system except the UI system. And that means that LabVIEW will switch to other threads when one is tied up by an external call to a reentrant DLL, reentrant CIN or an Automation server.

The problem with Active X is a different one. First Active X can either be a control or an Automation server and sometimes both. A control is placed in the Active X container and inherently opened by this control. A control executes ALWAYS any method and property node in the UI thread for safety reasons. An Automation server is always opened explicitedly through the Automation Open function and does not incoporate a user interface as far as LabVIEW is concerned. Those nodes CAN be called in the actual thread but only if the Automation server is marked as multithreading safe. Most Automation servers however and almost all Active X controls require Apartement threading which means the Active X control or automation server must always be entered from the same thread to work properly. In LabVIEW 7.x this is a problem as LabVIEW might enter into an Automation method or node from any of the 4 threads assigned to an execution system and if you even happen to manually assign different execution systems to different VIs, calling methods or property nodes of the same Automation server control, LabVIEW even in version 6.x has absolutely no way to avoid disaster. So LabVIEW seems to call those Automation servers from the UI thread too which is the only safe thread system to guarantee what the Automation server object told LabVIEW it would require.

Solutions are: Since only the UI thread is really locked the rest of LabVIEW diagrams will actually continue to execute. No updates on the user interface will occur though and calls to non reentrant CINs and DLLs will also block here as they are also forced to execute in the UI thread. So the processing of your application really doesn't need to be affected unless you set front some panel controls to update synchronously for whatever reason as that will force the diagram to wait until the UI can be updated.

IMO1: employing a hardware dongle protection will cost you more money and user credit than it can ever return in additional sales for typical LabVIEW applications. You really need to sell 1000s of copies of an application to even remotely justify use of dongles.

IMO2: Using Active X for this kind of thing is the worst choice one can do. It is a very complicated technique which adds an extra layer of point of failure you will have to support in your future users environment. And believe me end user support for dongle protected applications is always a very significant part of your support cost. If I would use dongles, which I probably never will, I would simply call into the DLL provided by the dongle manufacturer using the Call Library Node. This adds as little complication to the entire system as is possible and will minimise your support significantly.

Rolf Kalbermatter

[Joernh]

Thank you very much Rolf,

your explanations seem to hit the core. I will think about....

Solutions are: Since only the UI thread is really locked the rest of LabVIEW diagrams will actually continue to execute. No updates on the user interface will occur though and calls to non reentrant CINs and DLLs will also block here as they are also forced to execute in the UI thread. So the processing of your application really doesn't need to be affected unless you set front some panel controls to update synchronously for whatever reason as that will force the diagram to wait until the UI can be updated.

5210[/snapback]

...unfortunately, it seems that not only the UI-thread is locked or even panel-independent parts of code is also executed in the UI-thread. I have a parallel while loop with a SubVI-call (parallel to the dongle-check). In the VI settings of the SubVI I chose a different execution system so far...

The execution of this loop definitely stops during the dongle-access even though it is independent from the panel.......

Regards,

Joern