04-19-2022 04:51 PM
I'd like to have the option of single or two channel acquisition. I'm able to accomplish this using a for loop. However, my issues are
1. If the first run is two channel acquisition, I cannot "disable" the second channel option and revert back to single channel mode.
2. Vi will not run unless a name is given for each channel. I'd like the channel names to be blank as default unless given a name.
3. A switch between one or two channel acquisition. So if the previous run was two channel and you revert back to one, the second physical channel array will revert back to one cell.
My thinking is, if there is no other way, I'd make a case structure for one and two channels. But I's still have the problem of requiring a channel name to run the VI. Any suggestions?
04-19-2022 05:25 PM - edited 04-19-2022 05:28 PM
The way I would approach this is to configure the task to contain the maximum number of channels, then during execution, do a subset of channel read.
VI attached in LV2016 format.
Edit: if the VI errors out at DAQmx Read Property node, I guess, the channel should be the Physical channel name and not the user-provided name, to fix it, just wire the Physical channel control to the code at the bottom instead of the channel names control.
04-30-2022 08:13 PM
Could you run me through this? So you made an array the size the number of channel names, filled it with boolean true's, and sent that to a local variable, which then goes into the for loop?
05-02-2022 01:57 PM - edited 05-02-2022 01:59 PM
The technique I have used here is to include all the channels in the task (the possible ones that you will need to use through the execution) and thereby you don't need to create a new task whenever the channels change.
You can set "ChannelToRead" property to read only a subset of the channels available in the task, this allows you to change what channels you read, out of all the available channels in the task.
In terms of software architecture, I have added a boolean for each channel (Enable Channel) which allows the user to enable each channel selectively during runtime. At the start of execution, all channels are forced to be enabled (by writing an array of True to the local variable). Inside the loop, the "Enable Channel" control is read for every iteration to know which channels are enabled, based on which the array of channels are subset (using conditional indexing in the for loop) and flattened into a comma-separated string that is accepted by the DAQmx property node.
Edit: on second thought, even if you don't wire a True array to the local array, things will work mostly well. Initializing the Enable Channel array using the True constant array will ensure that the "Enable Channel" array size matches the Channel array.
05-02-2022 07:56 PM
As food for thought, here's another possibility. My guess is that Santhosh's solution might be a bit more efficient b/c it lets disabled channels get filtered out inside the driver rather than in the application code. But the code gets pretty simple if you filter after the fact on the application side.
The basic idea is to read all possible channels, then use a For Loop with a conditional auto-indexing output to determine which ones to retain. I learned DAQ long long ago before the DAQmx driver existed, and in the old driver, you *had* to do this kind of channel filtering after the fact b/c the traditional driver didn't offer any other options. That's what I got used to and that's what I generally still think of first in these situations.
-Kevin P