Built operator interface communicating with VI code modules.

[MichaelAivaliotis]

Using TS4.0 - I'm treading on new territory here so I'll ask the experts.

I've made some changes to the default LV operator interface (8.5). I'm communicating from it to individual LV code modules in my sequence and vice versa. I'm just simply calling functional globals. This all works fine. Now I want to build the UI into an executable and still want to maintain communications. I haven't done this yet but I assume it won't work since the code modules will be plain VI's that will be outside the executable.

Is there a way for me to build the LV executable so this can work?

[AllenP]

If you are running VIs that are using the same version of LabVIEW that you used to build the OI, the VIs will be loaded with the same version of the runtime engine and I think this would work.  If you are running the VIs in a different version of the runtime engine or running them in the Development System, I would not expect this to work.  I haven't tested this, but if the assumptions I made were true, this should work.

Allen P.
NI

[MichaelAivaliotis]

My concern is figuring out where to place the common code. As external vi's (or LLBs) or within the exe.

[AllenP]

This is a good point.  When you build the EXE, it will take in the functional global internally.  The code modules that call the functional global would then pull their code into the support VIs.  Once the EXE starts, it will load one copy of the VI.  Once it calls a VI that uses these globals, you will have a problem since LabVIEW RTE cannot load two copies of the VI from different locations.  It won't be easy to force these to be the same VIs.

Normally it is not recommended to couple your OI to your code modules in this manner.  If you must send information between them, it is recommended to use UI Messages.  UI Messages can also be used to return information to a sequence (or code module) when the synchronous parameter is set to true.  This allows your sequence (or code module) to post a message asking for some information and wait until the message is handled.  Usually it would pass in a TestStand variable as the ActiveX parameter and allow the OI to modify it.  The OI could then get this message, get the parameter, then set the value of it.

Another option, although it is also more coupled, is to use LabVIEW Queues to pass data back and forth.  You could preview the element from the consumer, and when a new element was ready, pop off the old element.  This will work as long as the above conditions are met (same version of RTE loaded, and always in the same process).

Hope this helps!

Allen P.
NI

[MichaelAivaliotis]

---

@AllenP wrote:

Another option, although it is also more coupled, is to use LabVIEW Queues to pass data back and forth.  You could preview the element from the consumer, and when a new element was ready, pop off the old element.  This will work as long as the above conditions are met (same version of RTE loaded, and always in the same process).

---

I like this approach. Hmm, how would I get the queue reference? By name I guess, right?

[AllenP]

I would recommend getting a Queue by name.

[Joe_H]

Michael,

My condolences, I have just went down the same exact road and ran across most of the problems discussed. What I found to work the best for me was to use the UIMessage and have it trigger an event and pass data that way. I created a message handler to handle the event and updated my user interface by functional globals or change events (you could also use quequs).

Be careful though I have seen many bugs in the communication and I have reported them all to NI and the have confirmed them as bugs and have been able to reproduce them.

I LOVE LAVA, See YA there

If you want you can E-mail me personally and I'm sure I can help you out (I'm sure you get my E-mail from LAVA).