I posted this subject a while ago: http://forums.ni.com/t5/LabVIEW/Labview-8-6-1-does-not-respond-when-I-control-a-com-component/td-p/1...
Since then I worked more and I reached some conclusion which I would like to detail here after I reformulate a little the subject: I have a COM component controlling a very high speed camera for which NI Japan developed Labview drivers. With drivers together I received a code example which worked very well. Camera is Ethernet controlled responding exclusively with events. My task was the integration of this camera into a complex application (DAQ and field points and other camera types) having a complex GUI interface for being used on site by medium level operators. My application has configuration interface for camera as well (configuration being saved into database), interactive control and automatic test. The camera integration encountered problems blocking the code with Vi open reference (very difficult for detecting in such a big application).
My work around was building a separate executable having only this camera control with camera events, application which is communicating with my main application using data socket. In this way I avoided the COM interaction with any open reference of any type or with any other open object.
I would like to have a written explanation from NI Labview experts how this interaction can be possible or in which conditions can be expected considering COM was a sharable component. I would like not being misinterpreted with this issue, it is for me to understand the two application: Labview and COM and to avoid next time the approach of this type mostly because it took to me a lot of time and frustration.
I am thinking anyone else can comment this approach of the code implementation.
Here is our best documentation t=on using shared variables:http://zone.ni.com/devzone/cda/tut/p/id/4679
However to more specifically answer your question the VI reference open will not work as expected in a number of cases:
Parallel Loops: The problem happens because opening a VI with a conditional disable structure, behind the scenes, starts executing VI code. The LabVIEW execution engine does not differentiate between the VI loading code it wants to execute and any other code that is presently loaded. This could mean executing the second Open VI Reference function before the current Open VI Reference is finished loading. If the two Open VI Reference operations end up loading common subVIs, then one load is unfinished when another one begins, which is unsafe and usually results in a crash.
Data sockets alleviate this issue as you found because they don't allow you to open up 2 reference at the same time (essentially eliminating parallel loops behind the scenes)
Here are some tutorials and examples of things that are benefited from using Vi Open Reference:
I hope this helped 🙂
Thank you for your documented email.
I want to be very clear here because in my previous attempt with this issue someone from NI understood COM as com port not as windows COM component, as a dll. Camera has Ethernet communication but the SDK consists on a dll which is build as windows registered COM for which I can see in Labview properties and methods as well as events. Building COM component is an old programming technique of building sharable application which is replaced now by dlls and activeX.
I recognize the executable alleviated the open Vi reference that exist in my main application conflicting with COM reference.
I will give you an example: I simplified the camera executable very much until I had at one moment to open the COM reference then launching the data socket server (dynamically launched with open reference) and the com reference blocked Labview in the only Open Vi reference. I was happy in this case changing the sequences: first launching the data socket server then open the COm reference.
So I am asking programmer experts how can Labview be blocked for the case I described (COM represented by dll blocking Labview in Open vi reference)?
This is in fact my title issue.
I just want to clarify about what is going on:
1. Are you calling a DLL in LabVIEW twice in the same application, or same VI?
2. Are you using a dynamic subVI that you are waiting to see finished before calling into the DLL again?
LabVIEW will block the occurrence of the second DLL if it is still being used in the first instance. The easiest way to make these multiple references is to set them up pragmatically such that one does not open another reference until the first call has been finished and closed. (You can use semaphores, or error wires etc)
If your exe has multiple calls to the same DLL the first one will execute and the others may return these blocking errors.
I hope this helps and I look forward to your response. 🙂
I am glad you trying to understand the issue that is not that easy.
I want to let know that for the COM I am using I open a reference to it only once using Open automation function and the program that controls camera runs like an independent loop using this opened reference in shift register (as in ActiveX procedure) and using some properties and methods for configuring camera.
My filling is that this opened reference interferes with any new open VI reference and in fact this is my work around avoiding any open reference after I opened the reference to the COM in the camera executable and separating this camera control from my main application which has a lot of GUI open VI reference. The interference I am talking about does not happened consistently at the same time and conditions, things that make me understand that it might be a memory violation when Labview open another reference with already opened COM reference (because Labview blocks I can not see any error and I have to kill it).
I think this are more details. Any idea why it might be this way? Is my understanding wrong?
I am having trouble going through exactly what is going on. Would it be possible to either post screen shots of this occurrence, post a snippit of the code, or make a small example which shoes this happening? I believe you are correct in your assertion that once a dll is opened LabVIEW does not like to open the same dll again and may cause a memory violation. This is similar to multiple reentrant VI calls. 🙂