Reading from a single channel defined in DAQmx task

[spastichawk]

Using MAX I have created tasks to read subsets of digital channels that are logically named. The intent is to read status and not waveforms. When in my block diagram I try and read  a single channel it seems my options are: read a single channel sample (presumably the 1st channel in the channel list) or all channels from the task in an array. This is great but the point of having logical names for the channels is now lost. Is there a way to specify which channel to read from the task or is the only efficient workaround to create a task/channel (simultaneous sampling is not required)?

[DuncanW.]

Hi spastichawk,

To my knowledge, you cannot sample individual physical channels from a task using the task reference. The whole point of bundling the channels as a task is so that you can simultaneously sample/read from them easily. If you want to sample channels individually, you should create tasks for each channel/subset of channels you want to measure. You can create an array of task or virtual channel references and index it however you want to conditionally read from any subset of channels.

Duncan W.

[ben64]

I never tried this but there is a DAQmx Read node that have a ChannelsToRead property. Note that it is device specific. Have a look at the help file.

Ben64

[spastichawk]

---

@DuncanW. wrote:

Hi spastichawk,

To my knowledge, you cannot sample individual physical channels from a task using the task reference. The whole point of bundling the channels as a task is so that you can simultaneously sample/read from them easily. If you want to sample channels individually, you should create tasks for each channel/subset of channels you want to measure. You can create an array of task or virtual channel references and index it however you want to conditionally read from any subset of channels.

Duncan W.

---

Sampling as a set would be ok but the result does not preserve the logical names assigned to the channels (making the code read unintuitively). Other than IO checks having the logical names assigned in the task seems pointless. Ill keep stabbing at it for a bit but i think i may break down and have to create single channel tasks.

[DuncanW.]

If your goal is simply to improve readability, I would consider using comments and descriptions in tandem with any channel labels. Once you abstract physical channels to a task, you are working with the task, not an array of channels, even though the task is more or less an array of channels. This is a key distinction.

I am confused as to exactly what you are asking for here. You said "the result does not preserve the logical names assigned to the channels". What is this result you are referring to? If you are talking about the resulting task, of course it doesn't preserve channel names. It abstracts out the notion of a channel so that you can deal with the task as a whole. If you are talking about the resulting array after a read, it wouldn't preserve labels either. You will need to track your data structures yourself throughout your program and ensure that they are all well documented. By labeling a channel, you may have documented what the channel handles, but it is not always obvious what its encapsulating task handles, what the data coming out of it is, or what the data is after you have processed it. Consistent documentation is extremely important.

Keep in mind that you can also label DAQ tasks (and wires) to describe what subset of channels they are handling.

Duncan W.

[DuncanW.]

By the way, you can retrieve the channels within a task using a property node. I don't think this is really the best way to solve your problem though.

[cbutcher]

If you wanted to put all of the results into a cluster so that you can see their names using Bundle By Name, you could use the Array to Cluster node and right click to set the appropriate number of values?

Edit: Oops, my cluster doesn't have enough values so you see Status 7 wired twice at the bottom. The point should be clear though 🙂 And you can use this more clearly because the unbundle by name from the output cluster allows you to easily get the status you want, without needing a bunch of different tasks.

[GerdW]

Hi cbutcher,

please don't advice the usage of ArrayToCluster followed by Unbundle, when a simple IndexArray function would be sufficient!

IMHO there is absolutely no advantage from using those two functions, but beginners are often trapped by the possibility/need to configure ArrayToCluster in it's context menu!

[cbutcher]

---

@GerdW wrote:

Hi cbutcher,

please don't advice the usage of ArrayToCluster followed by Unbundle, when a simple IndexArray function would be sufficient!

IMHO there is absolutely no advantage from using those two functions, but beginners are often trapped by the possibility/need to configure ArrayToCluster in it's context menu!

---

Above is the snippet that GerdW suggests - he rightly points out that the Array To Cluster node has some configuration that can easily be missed and can take some time to troubleshoot. I just thought it was a little clearer visually, but I see the point. I didn't need to wire the indices of the Index Array node because I wanted consecutive values from 0.