Frameworks/templates for multiple asynchronous tests using shared DAQ device?

[BertMcMahan]

I have a few potential customers that are looking to create some fairly simple tests- for example, read a couple temperature sensors/booleans/analog values and record them to file. Sometimes there will be a few outputs (analog or boolean) but nothing fancy.

The customers are asking for multiple asynchronous tests be to run on the same hardware. For example, they may have four test bays where they can load a DUT and hit "Start test 1", let it run, grab some coffee, then load DUT 2, hit "Start test 2", and so on.

Are there any existing frameworks that let you use the same DAQ across multiple tests like this? Normally, the single test will lock down the DAQ card even if it just uses one AI channel. Adding a second test wouldn't work with normal DAQmx calls. Requiring 4 DAQ cards when a single DAQ would work is an expensive way to do this when many DAQ cards have literally dozens of analog inputs.

My initial thought is to create the whole thing in the Actor Framework and make a background "DAQ scanner" that reads all potential DAQ channels all the time. Individual test actors would then "subscribe" to the individual channels they need, and would read data from the Scanner actor instead of DAQmx calls directly. That solution is definitely doable, but it's certainly not trivial. Does such a beast already exist somewhere, at least as a starting point?

(A side benefit to this setup is that multiple subscribers can read common inputs- for example, a supply pressure dropout boolean might trigger an abort across multiple tests.)

Edit: Forgot to mention, I don't think this is something TestStand does natively, but if it is that would definitely be a possible way to go rather than LabVIEW.

[Ben]

---

@BertMcMahan wrote:

...

My initial thought is to create the whole thing in the Actor Framework and make a background "DAQ scanner" that reads all potential DAQ channels all the time. Individual test actors would then "subscribe" to the individual channels they need, and would read data from the Scanner actor instead of DAQmx calls directly. That solution is definitely doable, but it's certainly not trivial. Does such a beast already exist somewhere, at least as a starting point?

(A side benefit to this setup is that multiple subscribers can read common inputs- for example, a supply pressure dropout boolean might trigger an abort across multiple tests.)

---

That is what I have done many times over.

It is not that hard until get to the details like calibration mapping channels to each test station etc.

If you need to be able calibrate on one station while another test is running then you will not be able to DAQmx scales but will have to do the scaling explicitly. Other things you may want to consider is;

Simulation - So you can test without hardware.

On the fly calibration - so you can tweak one channel while the others are running.

Symbolic Name to physical  translation - So that your code uses names that make sense in the context of the code and you are not constantly using indexes based on which station and which channel

Use an INI file - to configure your hardware so that you just have to edit the config file to add more channels or adapt it to another application

Error Logging - SO that you can trace back to explain why "SOMETHING" happened when you were not looking.

Averaging - that is configurable since the real world is "so messy".

THat is all that I can offer to help out. Hopefully some of that helps you think through what you need.

Ben

[crossrulz]

I would also go with the DAQ actor.  I advise to keep it simple on the DAQ side.  You can add all the complications (averaging, scaling, etc) you want on the test side.  I am thinking the subscriber sends the actor a queue (to send the data through) and a list of channels it cares about.  You can then do a simple FOR loop to go through the list of subscribers, grab the data they want, and send it through the respective queue.