Solution
In short, LabVIEW OOP and TestStand play nicely as long as you're not passing back and forth a lot between interfaces and your application is well-architected.
A summary of general considerations is outlined below:
- You can certainly call a LabVIEW OOP object into TestStand to use the instrument handle
- TestStand can store the reference that LabVIEW outputs as an Object Reference
- With regard to parallel sequences, as long as you aren't trying to use the same hardware resource in two simultaneous calls, there shouldn't be any major concerns using this methodology. Much like using a hardware resource in LabVIEW exclusively or even in NI MAX, you cannot run two tasks on the same individual channel at once, for example, which would throw a resource reserved error (limitation of the device, not the software environment).
- You'd be able to use the instrument handle object to run tests with your hardware, but you will need to use LabVIEW or another code module to change/get the properties of the device, as that cannot be achieved in TestStand directly. If you make objects for those as well, that is also likely an option.
- If you have well organized classes and objects in LVOOP and the application is well-architected, you can leverage more with LVOOP than with stations globals, as OOP can be more powerful (which I imagine is also why you're considering it!)
Essentially, depending on your goals, LVOOP can be a way to organize and use your instrument handles for use in TestStand.