LabVIEW OI / TestStand Communication

Question

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.
Aaron W.
National Instruments
CLA, CTA and CPI

Answer 1

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
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.