From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to acquire and manage data from ~30 analog inputs

Hi,

 I'm looking for some advice about simplifying the collection and processing of 30 analog input events. Previously I used the Daq Assistant to configure all 30 events. My understanding is that using daqmx is preferable, so I started a new vi (with just 3 variables to keep track of) that configures each channel individually for the same task (attached). My questions are:

 

1. Given the large number of tasks, is there any advantage to using DAQmx over the DAQ Assistant? If so, is configuring each channel in series, as I've done the best method?

 

2. Once the data is generated, is there a straightforward way to split up the signals from the 2D array that is generated when you collect multiple samples from multiple channels? I used an "In Place Element Structure" but I've read that most people use the index array function - both seem tedious for large numbers of signals.

 

3. Neither DAQmx or DAQ assistant seem to have an option to keep track of an assigned variable name. Is there a way to embed the variable names so that working with 30 separate arrays of data is more straightforward?

 

I've been perusing the help section and the discussion forums to get this far, but I'd be thrilled if someone knows of a relevant thread somewhere that I've missed!

 

Download All
0 Kudos
Message 1 of 4
(2,642 Views)

I'm glad you are using DAQmx instead of DAQ assistant.  You are creating the task very well.  No problems here.  When the number of channels gets larger, you could use a for loop and put all the parameters in arrays and use a shift register to carry the task in/out.  But the way you did it is fine.  I like the fact that you did it in a subvi to keep your main vi block diagram smaller.

 

The data generated will be a 2D array, and whether you use an In Place structure or Index Array doesn't really matter.  Its up to you.  Both perform the same function.

 

Are you wanting to assign a name to each array produced by the In Place (or by Index Array)?  You could use free labels on the wires.  Or you could create another string array and carefully put labels in them so that string 0 is the name of Indexed array 0, and so on.  When you use Index Array, you can use the same index wire for getting the array from the 2D array and for getting the name from the string array.  You can't label each row of a 2D array unless you convert the whole thing to strings and add a label column.  But I wouldn't do that.

- tbob

Inventor of the WORM Global
0 Kudos
Message 2 of 4
(2,630 Views)

@Meg T wrote:

[...] 

1. Given the large number of tasks, is there any advantage to using DAQmx over the DAQ Assistant? If so, is configuring each channel in series, as I've done the best method?

 

2. Once the data is generated, is there a straightforward way to split up the signals from the D array that is generated when you collect multiple samples from multiple channels? I used an "In Place Element Structure" but I've read that most people use the index array function - both seem tedious for large numbers of signals.

 

3. Neither DAQmx or DAQ assistant seem to have an option to keep track of an assigned variable name. Is there a way to embed the variable names so that working with 30 separate arrays of data is more straightforward?

 

I've been perusing the help section and the discussion forums to get this far, but I'd be thrilled if someone knows of a relevant thread somewhere that I've missed!

 


1. I believe you mean "large number of channels", not tasks. I don't mean to nit-pick, but the two are important concepts and should not be confused with each other.

    When I am setting up a few (1 to say 3 or 4 channels) I will do it in series, but if I were doing 30, I would definitely use a for loop.

 

2. The In Place Element Structre has memory benefits. In your application, it is being used just before the program ends, so you are not getting any benefit out of it. It's not hurting anything I guess. I almost always split up the channels and put each channel's data into Mean.vi. The way you are doing it, you are relying on the existence of exactly 100 samples being in the array. What if there were 99 or 101? Doubtful that will happen, but it is bad coding practice IMO.

 

3. There are no "variables" in LabVIEW. If I had 30 data points, I would probably combine them into a Cluster and give meaningful names to each indicator. To work with the data, you would simply undundle whatever you wanted to work with - by name! 

 

p.s. The trigger VI in your setup routine is not necessary. It looks like you created that from a daq assistant or express vi.

 

Richard






0 Kudos
Message 3 of 4
(2,606 Views)

Thanks tbob and broken arrow for the constructive advice. I started with an example that I found on the ni website, so it's true that the trigger is unnecessary for this application. I think I will try to implement free labels and clusters to keep track of the data after it has been split from the array and averaged (mean.vi!)/processed.  I had hoped that if the channel were given a name other than the physical channel name that labVIEW would somehow pass the name along with data, but it sounds like the channel name just serves as a reference within daqmx.

 

I have also realized that since I am only collecting data from 5 different types of devices (flow controllers, thermistors, pressure transducers, and a few other meters) I can simplify the configuration of the 30 channels to take advantage of the redundancy in the parameters. My plan is to configure the device types separately (5 different "create channels")  and then to use a list of physical channels for each. I think this will prevent the configuration from becoming too unwieldy, but won't rely on a for loop with arrays of parameters and shift registers -- though that's a really good idea that I hadn't considered! 

 

 

I really appreciate your suggestions and look forward to implementing them.

 

0 Kudos
Message 4 of 4
(2,589 Views)