Is it possible to use a "for loop" structure to represent DAQ of 16 channels?

hefanme · ‎05-07-2015

Hi,

I tried to search but I failed to find a similar problem so I am posting this problem here.

I have a temperature DAQ board which has 16 channels, and I am using all 16 channels to record and monitor temperature data.

When I writed blocks for all 16 channels, a mess was created (as you can see in my attached program). I have noticed that all the VIs for the 16 channels have similar structure, so I was thinking whether we can represent all 16 channels with a "for loop" strucutre with a pointer i scanning from i=1 to 16 as we usually do in Matlab or Fortran.

For instance, we may try to simplify the code like:

for i=1:1:16

acquire data from channel i

show data from channel i in X-Y graph

write data from channel i to excel in every 10 seconds

end

I could not do it myself because I cannot find a "pointer" to represent each channel.

Does anyone know how to do this in LabVIEW? Thank you.

It is said that it is best if we can put all of our code within the screen of a monitor we use by using subVIs to divide the code into many subroutines. But I found it quite difficult to do so as I have too many controls as inputs and indicators as outputs. Also, I use property node to read and write frequently, which make things harder....

Attached code does not work as it requires the 9213 hardware, and for simplicity I deleted irrelavent modules. But if you need I can upload one that may work by modifying the read VI.

Thank you.

Dennis_Knutson · ‎05-08-2015

I can't look at your VI since I'm posting by phone and I don't think I want an image. It sounds like your code is very poorly written. A single DAQmx Read or DAQ assistant will capture all 16 channels and the data can be wired directly to a single waveform graph. There is no need for any for loop or silly pointers. I'm sure you are also abusing the property nodes as well. Please look at the examples that come with LabVIEW.

altenbach · ‎05-08-2015

Yup, instead of all these 1D arrays, use a single 2D array. Your code could be reduce to <10% of the current size. I am sure it would fit easily on a single screen.

Also try to do some tutorial or take some courses. I realy don't think you are ready to tackle a system of this magnitude at this time.

Your code is just peppered with very poor choices. Some things you apparently haven't figured out:

index array is resizable. There is no need to create dozens of parallel instances, all wired to the same array and all with a unique index diagram constant. If you want all elements in order, the indices don't need to be wired at all.
Replace all your value property nodes with local variables. Much more efficient. Then redesign the code so you don't even need most of the local variables. 🙂
You can use built array to append elements to an existing array. Using "insert into array" is much more complicated an error prone.
It is not a good idea to have deeply stacked while loops with the innermost loop having long delays and indeterminate stop conditions. That just gums up the gears.
Learn about proper code architectures, state machines, etc.
Get rid of that gigantic, all encompassing stacked sequence. I am sure you can find a better way to reset three booleans when the code is about to stop. In fact it is typically more reasonable to set things to a defined state when the program starts to avoid problems due to accidental value changes at edit time.
Don't use hidden control/indicators as data storage and interloop communication via local variables. There are better ways.
You can wire the reminder or Q&R directly to a case structure. No need for e.g. "=0".
Don't use ambiguous labels, e.g.a boolean labeled "Dampers on or off". Nobody will be able to later figure out if TRUE corresponds to ON or OFF. Could it be that TRUE mean it is either ON or OFF and FALSE that it is in some imternediate position?
...