Don’t Panic: LabVIEW Developer’s Guide to TestStand

[MaryKoehler]

ID: TS6421            

Abstract: TestStand and LabVIEW integrate so well together that developers often find their projects tightly coupled; their LabVIEW control code can’t be run independently, and their TestStand sequences can’t be validated without hardware. It doesn’t have to be like that. Watch a demonstration of how the free Delacor Queued Message Handler helps developers create reusable, scalable LabVIEW modules that plug directly into TestStand but can just as easily be tested separately or deployed unchanged in stand-alone control applications.

Speaker: Christopher Roebuck, Delacor, Software Architect

A video recording of the presentation can be found here

The complete playlist for all demo's used in this presentation can be found at https://www.youtube.com/playlist?list=PLZ3A_SIOKdQvK3JJay7EOXbunXKqAliMq

The NI Week Presentation

Demo 1 - "The VI"

Demo 2 - "TestStand is amazing !"

Demo 3 - Using DQMH with TestStand

[pawhan11]

Nice video presentation 🙂

One thing that I do not understand. You create drivers in LV that share events with TestStand. These drivers are used by other application that provides an interface, data logging and other functions that were required. This might work if You do that in the source code. When You build these drivers into exe these events cannot be exposed to other apps like TestStand.

I had one project where all drivers and UI was made in LV, drivers had to run continuously in LV exe do data logging and some displays in the background. TestStand used to execute some sequences interacting with this drivers. Sharing queue or event was not possible since this was another application. I used TCP calls for each driver so it became available for TS.

How did You expose these user events to other applications?

To my understanding You can start this driver from TS/LV and use this events only in that context. Or is theresomething fundamental that I do not understand here ?