LabVIEW Queues and TestStand

[ShaneDonn]

Hi,

I have a VI that uses multiple loops/queues to acquire data from a datalogger and write this data to a csv file. 

What I want to do is start this VI from TestStand and leave it running acquiring/writing data until certain conditions require the datalogger to be stop/restarted.

Is it possible to somehow pass a reference of the queue from the running VI back to TestStand and update the queue from TestStand to stop/start datalogging as needed?

Maybe there is a better way to do this?

Any help greatly appreciated!

Thanks & Regards,

Shane.

[JÞB · Accepted solution]

TestStand will not directly access a Queue in LabVIEW.  TestStand and LabVIEW do not share an application instance.

I Assume you called the QMH asynchonously so that the launcher completes while the QMH stays running

Pass the Queue Reference back to TestStand (U32) and call a specific LabVIEW Module "Enqueue to MySpecific Queue.vi" with the appropriate ref and data.  This all pre-supposes that the QMH remains in memory.

This gets to be overly complex so, I tend to use Action Engines with TestStand.  The Load and Unload options do need attention though so that the shift register (and therefore the private data) does not leave memory until you want to close the rescourse

[ShaneDonn]

Hi Jeff,

Thanks for the reply and sharing your expereince.Yes I call the QMH asynchonously.

I will try both solutions but based on your experinece/feedback I think an Action Engine may the the way to go!

Thanks & Regards,

Shane.

[crossrulz]

---

@ShaneDonn wrote:

Hi Jeff,

Thanks for the reply and sharing your expereince.Yes I call the QMH asynchonously.

I will try both solutions but based on your experinece/feedback I think an Action Engine may the the way to go!

Thanks & Regards,

Shane.

---

The Action Engine is definately the way to go.  I don't like the idea of TestStand handling references for LabVIEW.  Plus it reduces errors for those trying to do the programming.  I do this for my drivers as well.  Keep what is for LabVIEW in LabVIEW is my philosophy.

[ShaneDonn]

Hi Guys,

So another question on AE/FGV for LabVIEW drivers & TestStand.

What if I have a driver for a power supply that make use of action engine or a simple FGV to store the instrument handle rather than passing it around TestStand.. If I wanted to update this to update this code to control more than one power supply from the same execution in TestStand how best would you recommend doing it??

Thanks & Regards,

Shane.

[tyk007]

Unfortunately the gain you get from using an AE/FGV construct as a globally visible object (if you can call this a gain) makes this situation a little more complex. The best approach in your situation would be to expand the AE / FGV's capability to maintain an array of multiple references to the power supplies. So each call to the AE/FGV must also specify which reference to operate on via the connector pane (eg. Supply #1, #2 etc.).

While it is tempting to be flexible and allow an unlimited number of references (ie. dynamically increasing the array size based on the client call) I would recommend hard-coding a maximum number of references (and thus pre-allocate the array) to simplify the logic and any testing that you need to perform.

[crossrulz]

---

@ShaneDonn wrote:

Hi Guys,

So another question on AE/FGV for LabVIEW drivers & TestStand.

What if I have a driver for a power supply that make use of action engine or a simple FGV to store the instrument handle rather than passing it around TestStand.. If I wanted to update this to update this code to control more than one power supply from the same execution in TestStand how best would you recommend doing it??

Thanks & Regards,

Shane.

---

As has already been said, change your AE to save an array of your references.  You can then choose which supply to control via an index or, as I did it, by some type of lookup that also needs to be saved in your AE.  I did a lookup of a string to figure out which supply to talk to.  Worked out really well.  It is flexible and expandable.

[ShaneDonn]

Thanks to you all for the great feedback!

Shane.