Help, Slow Data Acquisition Process with Loops

[Franz357]

Hello,

I am currently trying to combine the data acquisition results from a 28 thermocouple NI cDAQ 9174 and 4 other sensors (2 of which are ifm TA2114 and the others are ifm SM6004). I am running the cDAQ directly to my computer via a USB and the other 4 are being sent through the PLCs to a OPC and finally to the datasocket blocks in labview. In short, the data is successfully coming in and being sent to a database I have set up on another laptop.

The problem: The process is incredibly slow. I am fairly new to LabVIEW and was wondering if there was anything I could do within the code to speed things up. I realize without the sensor set up the program cant be run but perhaps there is something that can be observed. Any help would be much appreciated.

[Bob_Schor]

Suggestion -- arrange your VIs so that the Error Line only runs left-to-right without doubling back on itself (making it difficult to tell "Who Runs First?").

I've not done much with cDAQ, so I may be completely wrong about this, but I'm used to having three different DAQ devices (cDAQMod1, cDAQMod2, and CDAQMod4) have their own DAQmx Tasks, not all bundled together on the same Task wire.

Your While Loop only does a single DAQmx Read, as the Task is Cleared after the data are read.  So the longer you run the loop, the slower the acquisition speed will appear to be (N bytes / longer time = slower rate).

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

I've not done much with cDAQ, so I may be completely wrong about this, but I'm used to having three different DAQ devices (cDAQMod1, cDAQMod2, and CDAQMod4) have their own DAQmx Tasks, not all bundled together on the same Task wire.

---

With cDAQ, the chassis is in control of the sample clock.  Most cDAQ chassis have a few clocks, so you can have multiple tasks per chassis.  But you can also use that same sample clock (task) with multiple modules.

I have not tried this either, but you can supposedly use a single task for multiple X-series DAQ cards that are in the same PXI chassis (the clocks are somehow automatically routed through the PXI backplane).  So the world of a single task per device is slowing going away.

[ikaiser · Accepted solution]

Hey Franz,

Welcome to the Forum! I looked at your VI and noticed two things:

1. According to the comment in your code (well done to have comments in your code btw!), you are using one NI-9213. You are reading 16 channels on this one, and want to do this with 10Hz. This equals 160 samples/second. This value is decisive, as the 9213 has only one, multiplexed analog to digital converter (ADC). The NI-9213's ADC supports 75 samples/second maximum. That's less than the 160 aggregates samples/second you planned.
2. Worse for the NI-9211 (I am guessing it is this model; in your comment there is one digit missing): It supports 14samples/second aggregated, your code tries to do 4x10 samples/second. Exceeded by almost factor three.

A possible solution to this limitation is to lower the rate of your readings to 3.5Hz. If this is not suitable for your application, you need more/faster input modules.

Please note:

1. Apart from that you should error-wire the DataSocket Read VIs. That will make it easier to see what happens with them.
2. I don't know what ThermocoupleSUBVIHub.vi does, do you have anything in there that might cause another delay?
3. There are two VIs floating on top your loop. That's not a bug, however it might cause you trouble when trying to find bugs. Especially because of the hidden wires...
    
   (I moved the error wire a bit away so you see they are not connected to this wire. Note the shadow which shows they are not "inside" but above this structure)
4. Also, in terms of an easier to read and maintain block diagram, you might use a SubVI for the DataSocket read as well: From here
   
   
   (marked section will be in the SubVI) to this:
   
   
   That reduced your BlockDiagram's size by more than 50%. Do you think it's more clear to read as well. Please not that I did not introduce error wires to the DataSocket VIs yet which I strongly suggest.

[ikaiser]

---

@Bob_Schor wrote:

I've not done much with cDAQ, so I may be completely wrong about this, but I'm used to having three different DAQ devices (cDAQMod1, cDAQMod2, and CDAQMod4) have their own DAQmx Tasks, not all bundled together on the same Task wire.

---

As long as it is only one task, it works. However, Franz, you can shorten the Channel selection even more: By using a selector string like "cDAQ1Mod4/ai0:3, cDAQ1Mod2/ai0:3, cDAQ1Mod1/ai0:15", you can fit all the modules with J type thermocouples into one Create Channel VI (also see: NI-DAQmx Syntax for Specifying Physical Channel Strings). As the other one uses type K, you need to have that one separately.

Even more information on Channel Expansion here: Channel Expansion Explained

Also, this is a caveat in your current code: There is no order specified in which the three Type J Create Channel VIs (no type wired means standard, here it is "J") are processed, so you never know in which order the read VI will output the channels. In case you need the know the order it is a nasty bug. Use the Task wire as well as the error wire to set up an order (like you did with two of the VIs already).

---

@Bob_Schor wrote:

Your While Loop only does a single DAQmx Read, as the Task is Cleared after the data are read.

---

Am I missing something or were you fooled by the DAQmx Clear Task.vi's position?

[Franz357]

I really appreciate the time you took to respond to my problem that helped a great deal. Thank you