NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing LabVIEW Objects from LabVIEW to TestStand


The API for the LabVIEW GUI will need a LabVIEW object(which has a message queue) to be shared with the Teststand, so that it can then use it to call all API functions. I see in the thread above that you were doing something similar, but not sure if the Operator Interface(OI) being refereed to in your comments is actually an independent LabVIEW GUI app or not. Could you please advice me if my approach to the problem is in the right direction.? I am not sure about how the application instances and memory spaces between TestStand code module VI's(API for my GUI exe) and LabVIEW GUI Exe will workout.

Yes, the Operator Interface in my case was a LabVIEW application. Managing application instances with TestStand is tricky because it changes in the IDE vs executable. NI has a help article. If you get your LabVIEW application and the TestStand code modules into the same instance of LabVIEW, you can share queues and objects. 

 

For simplicity sake and ease of transitioning between IDE and built code, I would recommend either:

  1. Let TestStand handle all the API calls and treat the LabVIEW application like a nice front end for TestStand. 
    1. If you want some control from the LabVIEW app you can scope your sequences to have single function subsequences and let users run those.
  2. Separate out the API and give it a RESTful interface. Your application would then have 3 components:
    1. LabVIEW GUI (executable)
      1. Calls TestStand Sequences
      2. Calls APIs over HTTP or TCP from Hardware/Driver REST App
    2. TestStand (sequence)
      1. Calls APIs over HTTP or TCP from Hardware/Driver REST App
    3. Hardware/Driver REST App (separate LabVIEW executable)
      1. Waits for requests and doesn't care who calls LV or TS
Andy Corbato
DMC Inc.
CLD, CTA
0 Kudos
Message 11 of 11
(49 Views)