LabVIEW OI / TestStand Communication

[Aaron_W.]

All,

Looking for some general recommendations on how to pass data from LV to TestStand. Here is the situation:

We commonly use custom LabVIEW OIs for ATEs and we will often times include a EStop or Part-in-place. These are typically using a DAQ card to read the lines. We want to monitor these lines consistently, even if a TestStand Sequence isn't running in the custom OI. However, I still need to send this data down to TestStand when the sequences are running to stop tests (for the EStop condition) or start tests (for Part-in-place).I need to be able to monitor this data even if I'm not logged in to TestStand.

I'm trying to figure out the best way to do this and I can't seem to come across a good answer. Things I have at least looked at:

Using a Functional Global like this: Using Functional Global Variables to share data between the TestStand Operator Interface and Code mo...
Problem is it only works when LV and TS are both in the runtime environment, making it difficult to troubleshoot.

I feel there should be a way to do this with the TestStand API and write to a StationGlobal, I've been looking at this, but not sure if this will work when I'm not running a TestStand sequence.

I'm happy to write an action engine in the LabVIEW OI and monitor those DAQ lines there, but I just need to find a good way to consistently send the data to TestStand (if open and / or running).

Thanks for any recommendations.

[Norbert_B]

Aaron,

this is somehow a common requirement but there is sadly no "this is the only way" solution.

Things i recommend for discussions:

1. Use another application as IO Server:

The IO Server controls the hardware and reads/writes data as requested by clients. Essentially, the UI and several TS Sequence Executions can be clients, requesting data.

Transfer is of course some TCP based technology.

Advantage:

+ IO Server PC does not need to be the same as the sequence controller

+ Number of clients can be "arbitrary" (question of performance)

+ Well defined interfaces make debugging easier

+ IO Server can be started as "Startup Application" or a defined caller (e.g. UI)

Disadvantage:

- Not suitable for time critical IO connections as there is a lot of delay and jitter

- Not suitable if hardware cannot be abstracted to a single handler

- Possibly requires firewall/anti-virus settings

2. Create an "agent" in the UI:

As you already stated, this is very good way to gather data regardless of the state of TS. Problem is: how do i best transfer data from here to TS?

Solutions:

a) FGV (already mentioned). Current Value Table (CVT) is similar to this. Works only if UI and code modules are written in LV.

b) Custom UI Message: Requires a callback with given code. Works independantly of used languages (LV vs. .NET for instance) as data is passed directly to the TS dataspace using the ThisContext reference.

c) Internal TCP Stack: Similar to the first option, "IO Server". Therefore, rules, gains and losses are comparable.

d) ....

3. Use a TS Model Plugin:

This option is not suitable as your requirements are that TS does not need to run in order for your monitoring. But i add it for completeness.

The idea is to execute a parallel running Model Plugin, not for reporting but for IO Management. You can use internal TS synchronization methods (queues, ...) to pass data.

I think this should be tho top most options. Time to discuss 😉

Norbert

[Aaron_W.]

Norbert,

Thanks for the reply. Yeah, we have been looking at a bunch of different options and there doesn't seem to be a clear winner. I think a couple other things we looked at were the following.

1) Networked Published Shared Variables - I know there is a lot of overhead with these, but it can get the job done.

2) TCP on localhost - The issue I was running into is if there isn't a listener and you keep enqueueing data then you can overflow your buffer, so you would need to almost flush the buffer before every write.

3) Little more complicated, but, we thought about modifying the FrontEnd callback and moving the Login / Logout to a different place. I think TestStand could be made to "always run" but we just need to make sure that even if a user logs out that we are still able to write data to TestStand without it throwing errors.

I have not looked at things like CVT, but I will look into that.

I really believe the problem is with hardware or other resources like DAQ where you can't have multiple listeners. For instance you can't have a task open in the LV OI and in a LV (or whatever adapter type) TS step type.

[Aaron_W.]

I was able to find a way to complete this with the TestStand API from LabVIEW. I was able to create a Station Global in TS (I can probably do this pragmatically through LV, just haven't tried yet) and then call it from LabVIEW OI. My question on this is what is the disadvantage with doing this? I know that I don't want to call the API so much that I bog down the TS Engine, for static DIO this is probably alright. My understanding from the TestStand Help is that TestStand holds the Station Global variables in a property object (memory) until the TestStand Engine is closed. So as long as I writing to the Station Globals while the TestStand engine is live, I'm not hitting the disk every time I write to that variable.

I know the disadvantage of using Station Globals and the race conditions you can get yourself into, but in my case with only one writer and multiple readers I think I can avoid the race condition.

Also, what would happen if I had a sequence open in TestStand and called another sequence from a LabVIEW OI, both of the sequences would need the Station Globals.ini file, would there be a conflict?

Anyway, looks like this option works, still considering the possibility of using the shared variable engine, but just think that's a lot of overhead. Any thoughts are welcome.

Norbert is right, there is no right way to do this, only less wrong ways of doing this. Wish TestStand would implement a feature to make this easier.

[Norbert_B]

Aaron,

the best option in my opinion is to have a clear client/server model.

Client requests, server performs and replies.

It doesn't matter what technology you use to connect client and server, but it has to be a well defined way.

Take UIMessages for example:

They always "flow" from the TS engine to the "consumer", the UI. The TS execution is the client, the UI the server.

Most likely, UI Messages will update information on the UI, so a reply of the UI is not necessary, but you can also use UI Messages to send requests/"questions". E.g. "Is the checkbox checked?"

In order for the UI to answer/reply, you have to pass the ThisContext.

In this situation, the UI has to use the TS API to get data into the execution (SetVal-function). So using the TS API in the UI is mandatory and far from "discouraged to use". The point why some developer state the latter is that most developer start to bind the UI to a specific sequence or process model. And that, indeed, is not recommended.

Wether you are using UIMessages or a TCP based client/server protocol is totally up to you. But i recommend to design this protocol comparable to UI Messages as this technology is mature and well tested.

Regarding the use of StationGlobals:

I discourage you to use those as they are saved at least once the engine shuts down. So it "blows" up overhead for initializing/shut down as well as might lead to popup dialogs like "StationGlobals have been modified from an external task. Do you wish to update them for your current application?" or something similar. This is what you already suspect, so it definetly is some kind of cultrip.

From my perspective, planing and discussing options is improved if the counterpart is aware of the content of the LV Advanced Architecture class. It discusses exactly these kind of "issues" as they are common to any application consisting of several, independant components.

hope this helps,

Norbert