Examples for good programming practice with multiple DAQmx tasks

[dsdale24]

I'm writing a program to continuously log data from 8 counters, 8 encoders, and 8 voltages. The proof of concept VI with a single counter was simple and elegant, but scaling up to all signals resulted in a wiring mess. I've been working through the Labview Core courses, and am currently on Core 3. I still haven't come across a discussion on how to work with multiple DAQmx tasks without making a mess of the block diagram. Can anyone point me in the right direction?

Also, say I have a state machine that has a configure, idle, and logging states. I need to set the initial values of the encoders during configuration, and keep up with their changes while in the idle state so I have appropriate starting values when entering the logging state. Can anyone point to an example that shows how this might be accomplished?

Thanks

[JÞB]

Ah, one of those.....

OK you've been up to Core III and not been really introduced to modular code concepts.  First go back to the LabVIEW forum  hit top kudoed posts, select "All time"  you'll read a very nice nugget from Ben.  There is a reason its the top kudoed post of all time.

DAQmx tasks work great on the USR or FBN of a functional global (Action engine or Resource Module)  No other vi really needs access to that data so why pass it around in callers that can't (or shouldn't) use the information anyway?  It will only cause you a "Wiring nightmare"  Just to give a simple example the attachment is a "Resource Module" for a DAQmx Digital Out task.  you can safely ignore the type defd enum I did not attach.

Next get yourself a copy of "A Software engineering approach to LabVIEW"-  It's an eye opener! and Swatts can pass over the royalty check since I promote it so darn much.

[crossrulz]

---

Jeff·Þ·Bohrer wrote:First go back to the LabVIEW forum  hit top kudoed posts, select "All time"  you'll read a very nice nugget from Ben.  There is a reason its the top kudoed post of all time.

---

It is so useful of a post, I keep a shortcut of it in my Macros:Action Engine

[Sam_Sharp]

I'm very familiar with AE's/Functional Globals - but I have struggled in the past with handling multiple DAQmx tasks - particularly when you're using multiple devices and using different types of measurements which require seperate tasks/handling (e.g. such as thermocouples which require extra compensation).

I'm not even sure I know whare the requirements are for needing multiple tasks - I know you can need multiple tasks for a single device if the type of measurement is different but can you share an Analogue Input task amongst multiple devices?

I think in hindsight (and without too much thought now) it looks like a good case for Object Oriented LabVIEW - with a base DAQmx class (initialise, configure, start, acquire, stop, close etc.) and then child classes for each type of measurement (with one task associated with each - and private data unique to that specific class). You then hold an array of objects (one for each task) and iterate through each one with dynamic despatch to get the data.

I don't know your particular experience level of using LabVIEW (and as such, OO may not be appropriate) - but as a wider discussion of 'best practice' it seems like an appropriate method I would use going forward.

[JÞB]

Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

Ah, forgot about the macro.... go figure

And yes, an LVOOP approach would be better. 

[dsdale24]

Thank you all for providing some direction. I've ordered the book, am reading the recommended thread, and will work through the rest of Core 3, the OO course, and the Advanced Architectures course at ni.learn.com over the break.

[Yamaeda]

I think you only need 3 tasks, just group the channels together, it'll madke it easier.

[dsdale24]

I can group my analog signals into a single task, but I have not been able to group counter tasks into a single task. And I thought I read documentation saying this was not possible with counters. Am I mistaken?

[John_P1]

This is true, you can't group the counters into a single task.

Extending your single counter proof of concept VI to multiple channels shouldn't have to create a wiring mess though--you could use some for loops for example (I didn't wire the inputs, but you get the idea):

The AI channels can likely be combined into a single task (you didn't mention your hardware).

If it's a larger scale applicaiton, I would probably consider going the LVOOP route and wrapping up the DAQmx into a class with a more generic parent interface (but I guess that depends on your application requirements).

Best Regards,

[dsdale24]

I'd like to follow up with a question relating to LVOOP and/or the actor framework. Suppose I want to create a controller class that is responsible for instantiating objects to manage acquisition and logging for the various channels for this measurement. The actor framework template includes something sort of analogous to this, with two actors that could be used for this purpose. But those actors, alpha and beta, are hard-coded into the controller classes private data.

Could anyone suggest how I would manage the controller's private data to deal with an arbitrary collection of counters, analog signals, encoders, etc, which might be specified in a configuration file? In my "native" language (python), I would create classes/subclasses with a common interface, and have my controller aggregate the instances of the various classes into a single collection (list or dictionary), and then iterate over the collection.