TestStand sequence and GUI communications

[Mark Yedinak]

I have run into a bit of a problem and wonder if anyone has solved this or knows of a solution that will work. We have an extensive library of reusable LabVIEW classes that we are utilizing both or automation framework GUI and TS sequences. A part of these libraries is a generic application messaging systems that is based on a networked based queue. Our messaging classes are self contained and designed to not require any external input. They use internal data for references to the queues. The problem we have encountered is that in our application the GUI and the TS sequence actually share different application space and cannot share a reference to a queue. We need a method to programatically determine which memory space we are in. We would use this information to do a look-up for the correct queue reference. We do provide an initialize method for our messaging class which will create the queue and store the reference. We need a way to get a unique identifier based on the memory space it is running in. This method needs to be generic and not assume we are running in a TS environment. The process ID and application name will not work since both the GUI and TS sequence will share this. Any ideas on a workable solution?

[asbo]

Have you compared application instances? I'm not sure if you're using a particular (Windows-specific) definition for memory space or application space, but my understanding of named queues is that the look-up is bounded by LabVIEW's concept of application instances and my presumption would be that these cannot span different processes or working sets.

[Mark Yedinak]

We have confirmed with NI that the memory space is not shared between the LabVIEW GUI (application which starts and controls the TS sequence) and the TS sequence. The queues we are using pass the data over the network so that is not the issue. We can pass data. The issue that we have is our generic messaging system is using a functional global to hold the queue reference and unfortunately this FG does get shared by the GUI and the TS side. However, neither side can use the other's queue reference. We need a very generic method to obtain a unique ID of some sort that can be derived programmatically. This value would need to be consistent within the confines of the GUI or the TS side of things yet be different from each other. Our current approach using the application name and process ID does not work since this is the same for both instances. In addition, I don't want this method to assume the presence of TS. It has to be TS agnostic. Some thoughts I had would be something along the lines of a thread ID. Though I am not sure this would work since I can't find a way to get that value and I believe that NI's scheduler can place the execution on different threads which would not guarantee uniqueness across multiple calls. This solution cannot use a wired in value since these message objects are several levels deep in the library code as well as being used within different libraries. We have already tried the owning application reference thinking this may be unique but it isn't.

[lvb]

Mark,

Have you found a solution to this? I haven't heard of "memory space" in relation to TestStand or LabVIEW. My best guess is that TestStand and LabVIEW are not running in the same Application Instance as Asbo previously mentioned.

If this occurs on a deployment with a LabVIEW EXE only, then there is a work-around for code sharing between the OI and TestStand.

A few questions regarding your framework:

• What process model are you using?
  
• Is the LabVIEW GUI LabVIEW Development or an EXE (Run-Time Engine)?
  
• What TestStand LabVIEW Adapter (LabVIEW Development or Run-Time Engine)
  
• Does this occur on both development AND deployment systems?
  
• Did you verify that your LabVIEW GUI and TestStand LabVIEW Adapter match?
  

The following snippet should list all the Application Instances (Contexts):

There is a good thread regarding Accessing VIs across contexts here on LAVA. That thread has a VI Server method that can be used to obtain a VIs Application Instance.

If it turns out the Application Instance is the same, I would be very curious to find out more details from you.

[Mark Yedinak]

I will have to look at the application instance specifics. To answer your questions though, we are using a custom process model, we are deploying this as an exe and we do ensure that we keep the development environment/run-time engine settings in synch. When we deploy TestStand is set for the run-time enviroment. We have seen cases where it would work in the development environment but not the deployment. In the past we had asked NI about sharing a queue from the GUI to TestStand. We were told it was not possible. This was why we opted for a network based solution. We did find a solution to this issue. Our messaging libraries had been using a single client queue to post messages to our message server (network based). The problem with this was that TestStand and LabVIEW could not share that queue. Our message class orignally only provided for a single quueue reference. Our solution was to allow it to manage multiple queue references. This all happens internally to the class. As a result we had to create an initialize method for our messaging class which would provide a unique "client ID" for it's messaging. Calls to the post message method simply needed to use the "client ID" when posting messages. The message class manages the various client queues and everythign is working now. Everything is neatly bundled up and if our messaging class is used in a single application the client ID is not necessary, therefore nothing special has to be done to use the messaging class.