Reading/Writing Channels Concurrently in LabView

[darrenlwoodson]

I was hoping to find out if there is a method in which to make the following images work as they are designed in the examples:

By my understanding the "correct" way to handle the reading/writing of multiple channels would be to either create a list of channels (in which the task associated with those channels would be created automatically, or create the task myself with the appropriate channels) and feed that into a read/write vi, then accept an array of multiple channels as data out, separate that date, and use it however I need. 

However it would be much more convenient due to the nature of the data coming in and out of these shapes to run them separately and concurrently. I am reading data from gauges and writing data out via my DAQ module to regulators. I'm interacting with two regulators and two transducers each with their own gains and offsets as well as their own value checks when read in. Doing all the necessary arithmetic, sticking those values in an array, then sending that data out via Write to each channel, then accepting that data in as an array via Read, separating the data from the array into each channel's individual output, then doing additional arithmetic to check if the values in have the correct properties seems tedious and inconvenient compared to creating a standard SubVI that I can send each gauge's corresponding information to, have the shape read that data, do the arithmetic and then spit it out.

It might be one of those "suck it up" moments where I do have to just to conform to the arrays in and out method, but I figured I'd ask to see if anyone knows whether there's a way to run these shapes independently and simultaneously while avoiding race conditions. 

To further add to my example by including some specifics: I have a valve that has inlet pressure supplied by muscle air regulated programmatically to a desired PSIG. This valve also has a pilot pressure inlet whose supply is linearly related to the inlet pressure via a formula. So for example if the inlet pressure is 91 PSIG the outlet is 267 PSIG. Each pressure transducer has its own gain and offset when reading in the raw voltage to translate its reading to pressure and each regulator has its own nuanced 'near linear' curve to what mV value they need to reach a certain pressure given its muscle. Here are two examples of what each would look like if I did it the array method versus the concurrent SubVI method:

I threw these examples together to demonstrate my intent so they may not be perfect but the spirit of the question should be prevalent within them. The second option seems cleaner to me, more manageable, more scalable, more modular. But as far as I can tell through my trying to put these together, the second setup is not really an option due to my getting the "This resource is reserved" error when attempting to read/write multiple channels at once from separate Read/Write VIs. 

Any feedback anyone has to offer about these two different methods, if it is possible to tweak the, in what is my opinion, more efficient method (#2), or if I'm stuck with using only one read/write shape at a time. 

Please feel free to engage me for more details with questions if I have not made any one thing clear enough. 

I'll appreciate any and all help. Thanks a million in advance for those who reply!

[GerdW]

Hi darren,

---

@darrenlwoodson wrote:

the second setup is not really an option due to my getting the "This resource is reserved" error when attempting to read/write multiple channels at once from separate Read/Write VIs.

---

You forgot to include important information: which DAQ device do you use?

Why don't you put all channels into just one DAQmx task to avoid that "reserved resource" problem?

Why don't you define the DAQmx task completely with sample rate etc.?

Why do you need string datatype to handle DAQmx channel references?

[darrenlwoodson]

Sure thing! Let me go by each question:

1. DAQ Device: NI USB-6343

2 and 4: When it comes to creating a 'list' of DAQ channels to send to a DAQmx VI to create the task automatically this method of using strings to concatenate was the only way I found one would use if not using tasks. I did mention that I recognized that a task makes that particular portion of the examples cleaner, but it does not avoid the 'reserved resource' because I need to read constant data throughout the entire run of the program to be recorded. That means I'll have a separate while loop running with a constant read shape feeding me data from my transducers. The standard way for me to do this would be to use channels, or a task, into one read shape, then separate the read data out of the array and manipulate as needed. However with this loop constantly running I cannot use a read shape later on in the program (specifically in a pressure commanded VI where I want to write data and read data so that I can value check the outputs when the regulator opens or closes more). This second read VI would cause the 'reserved resource' error. So if there is not a way around that then I'll have to use something like references or global variables, which I'd rather avoid if possible.

3: I'm not sure what this would have to do with my question to be honest, but I normally would specify the sample rate of any task or channel read/write that I would do, if I did not do so in my examples its because they're just that, an example, not my actual program. 

I appreciate you reaching out for clarification. I expected a little more response with 50 something views on this post so far but alas I'll be grateful for any feedback I can muster so thank you GerdW!

[darrenlwoodson]

GerdW also helped me realize that I forgot to mention that I am running LabVIEW 2016. In case the version specifically affects any potential feedback. 

[GerdW]

Hi darren,

---

@darrenlwoodson wrote:

1. DAQ Device: NI USB-6343

2 and 4: … I did mention that I recognized that a task makes that particular portion of the examples cleaner, but it does not avoid the 'reserved resource'…

---

When using just one (1) DAQmx task containing several/all channels you can easily avoid that "reserved resource" error!

Especially with your MUX-type DAQ device…

[santo_13]

To handle the varying scaling per sensor, DAQmx has the scale feature where you can create custom scales and link it to the physical channel when you're adding that channel to the DAQmx task.

Typically, put all AI tasks into a single DAQmx task, you can read specific channels by wiring the channel list to the property node before reading.

Put all AO tasks into a single DAQmx task, here the trick is that you have to provide data for all channels whenever you write to the task, you can work around by maintaining an array of values of all channels, updating the values for required channels and write the array to the DAQmx Write, this way you change only the intended channels.

[darrenlwoodson]

So I tried this and to my surprise it didn't run into the same issues that simply using a channel (and allow the DAQmx SubVI to create the task on its own) ran in to:

However a task based setup would still require me to separate the data before manipulating it, I don't quite see a way to incorporate a task into this setup that posted above: 

The two tasks I would have are the read tasks which in my actual application has three different channels for reading data, and a write task that contains two different channels. With that the read task, I'd still have to separate the data and within the same VI space in order to apply the arithmetic to it for each channel's various gains and offsets, as well as value checks. So it doesn't appear much different using a task than the array method I mentioned in my original post. 

I'm recognizing that the real root of the question boils down to whether or not I can run multiple DAQmx Read Tasks at once. Because the task is created automatically, but even if I create the task myself, without some additional setup I cannot run two Read tasks at the same time. Another forum post mentioned the sample rates and buffer sizes on my module needing to be the appropriate settings to ensure the buffer doesn't overflow or that I don't try to read samples that have not been sent. I'm chasing this down now to figure out what configuration I need to make this work for my loop/module.

[darrenlwoodson]

Santo_13, would you be willing to elaborate on the AI Read Task feedback you gave? 

Specifically when you say Channel List do you mean the concatenated string in my examples? Which property node, DAQmx Task or DAQmx Channel property node?

Thank you!

[santo_13]

Hope this helps to understand my idea of using custom scales and bunching all Analog Input channels into a single task.

[Kevin_Price]

The AI will probably be a bigger constraint than the AO.

AI channels & tasks have to share access to the single A/D converter on your device.  So you can't have 2 separate active AI tasks that both need to "own" that resource.  You *can* define most of the config for 2 separate tasks if you only make them *active* one at a time.  To do this, you'd need to have your subvi start the corresponding task, do the reading, then stop the task again.

    This creates some overhead with all the starting and stopping, but perhaps your app isn't highly sensitive to this issue?

With AO, as long as you stay software-timed, you probably *can* have 2 separate active AO tasks.  AO channels on MIO devices typically have their own dedicated D/A converters.  However, only 1 "timing engine" is available for AO, so you can't have 2 separate active hardware-clocked AO tasks at the same time.

-Kevin P