Establishing task names in DAQmx with LabView: a conceptual question

[BikeSki]

We're working with the latest versions LabVIEW and DAQmx.  The goal is to control a CompactDAQ 9173 chassis with a set of modules (AI, relays, thermocouples).  I would like to use low-level routines (rather than the DAQ Assistant) so I have some control over information flow.

Our hope is to...

• Create a VI to establish a task using "DAQmx Create Task" for one particular function (e.g. read a specific temperature) and save the output task name to a global variable.
• Create another VI that will fetch the appropriate task name from the global variable and use it to do the appropriate action (e.g. actually read the temperature with "DAQmx Read"). 

This is the bare outline of course, and ultimately there will be many task names in the global variable and many different reads and writes, happening asynchronously, as well as proper cleanup of tasks etc.

At this initial stage, we're having trouble saving the output task name to our global variable.  A probe seems to show nothing going in, and when we try to fetch the task name from the global variable, there's nothing to retrieve.  If we simply wire "create task" directly to the "read" it works.

Is there something fundamentally wrong with this approach?  Is there something conceptually special about task names that we are missing?

I know we need to set "auto cleanup" to be false in "DAQmx create channel", but beyond that, I can't see what we're doing wrong.

[Bob_Schor]

I am forced to "imagine" the DAQmx code you created.  I do not understand why you use Global Variables rather than the DAQmx "Task Wire".

On the other hand, I commend you from avoiding the Dreaded DAQ Assistant (DDA, for short) in favor of DAQmx and a few DAQmx functions.  There is a White Paper Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications that will illustrate how 3 to 5 DAQmx functions can set up many Acquisition and Control tasks.  There are also many "loaded" Examples of DAQmx tasks that ship with LabVIEW -- they tend to be "overloaded" (and try to show you all the Bells and Whistles).

Bob Schor

[otto__]

What does the rest of your app/program look like, generally? How is the data from the task being moved through the application? That would help me make an example.

What actions are you trying to take on your daqmx task by making it a global variable? In my own travels, the task wire does not (nor should it) travel far from its origins.

I *think* a queued message handler plus leveraging some form of the producer/consumer structure for your daq process might meet your needs, if you aren't already familiar. You could use the message handler to communicate daq-task level commands from another process without worrying too much about managing the lifecycle of the task itself.

[Bob_Schor]

I just realized that about five years ago, I developed a project to monitor the cooling system for a number of fMRI machines.  The basic idea was to take readings from 7 flow meters in the cooling system and a temperature reading from the coolant (water) reservoir once/minute and if the flow was too low or the temperature was too high, to send an e-mail message to "responsible people".

I created two VIGs that acted like "callable State Machines", one called VIG Flow Task, the other VIG Thermocouple Task, that had the following "States" (defined as an Enum called "Task State") -- Create, Start, Read, Stop, and Quit.  In addition to the input "Task State", there was a "Clock" input, used in the "Start" state to set the Sample Clock.  There were also "Sample" outputs, as well as a "Task OK" Boolean that returned "False" if the "Create" state failed.

Note that the "Task/Channels In" line for the DAQmx Calls remained "inside" these VIGs.  No need for Globals (well, VIG does mean "VI Global") and the "wiring" is confined to the single VIG Flow Task (or VIG Thermocouple Task).

Additionally, you can write (while you are developing, and might not have access to, say, the Thermocouple and associated DAQ hardware) a "Simulator Thermocouple Task" that has the same calls and structure as your "real" Flow Task, but generates "simulated Temp Data" when you give it the proper sequence of calls to Create and Start the Task and then do periodic Reads.

I tend to use "Text" Icons for my sub-VIs, with Yellow backgrounds for most of them.  For the "Simulator" top-level and Stimulator-specific sub-VIs, I just made the background bright Green, which made them very easy to spot.

Feel free to adapt to your situation.

Bob Schor