LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI 9212 - Issues with Sampling rate, number of samples and buffer size or just overall sluggishness with thermocouple module

Solved!
Go to solution

To start, I'm very new to labview and unfortunatley my first task is to build something rather complicated for a project my company is working on. Thankfully it's mostly monitoring rather than controlling critical processes.

 

At this moment I have a cDAQ with DO, DI ,AO, AI and TC modules.

 

cDAQ-9133

NI 9472

NI 9421

NI 9263

NI 9205

NI 9212

 

I am running reads/writes for all 5 of these modules in paralell while loops and the analog and digital inputs/output modules all operate as intended. Each loop asks for 1 sample per channel via the DAQmx assistant etc. for each module and I succesfully can interact with all the inputs and outputs asyncronosly which for now is the goal. I can toggle on/off for each module to save memory or whatever if the need arrives later.

 

My problem is that the TC module (NI 9212) when toggled on which enables the 1 sample acquisition loop seems to take much, much longer to gather samples. I've played with the different acquistion settings and can seem to get a continuous stream of data when using the continuous samples mode, or even when specifying N-samples but I come into issues where the "application cannot keep up with the hardware".

 

I've tried finding an optimal number of samples/sampling rate, etc. so that I can get a temperature update more than every 1-2 seconds but if i set the number of samples high enough to seemingly get a constant stream, what ends up happening is the waveform charts seem to lag behind the actual data and this is where I get errors. I really only want 1 sample per channel per cycle anyways. Again, all the other modules cycle with less than 100 ms delays between acquisitions but the thermocouple module ends up being 1-2 seconds. This is okay because in our application temperature shouldn't rise/fall very quickly but its annoying nonetheless.

 

I have the acquisition set up for the thermocouple module (NI 9212) the same was as my analog and digital input modules(NI 9421 and NI 9205) to take 1 sample each time the task is called so I'm having a hard time understanding why doing the same for the TC module introduces such a delay. The max sampling rate is supposed to be 95 samples/s/ch so I guess the delay must be coming from calling the task over and over again in a loop.

0 Kudos
Message 1 of 6
(6,945 Views)

First, some basic suggestions:

  • Make an Array of Boolean Controls on the Front Panel.  Drag the array "sideways" until you have 8 Controls showing (they'll all be greyed out, since the Array, at this point, is empty).  Click to turn on the right-most one, which will bring into existence all of the Controls.  Now turn it off.  You now have an 8-element Array of Boolean that you can immediately wire into Boolean Array to Number.  It also "looks prettier" on the Front Panel.
  • Do the same for the 8-element Boolean Indicator Array.  Note that once you have the Arrays on the Front Panel and have them sized properly, you can get rid of the Array Index (since you can "see" all the elements) by right-clicking the Array on the Front Panel, choosing Visible Items, and turning off Index Display (I think that's what it is called).
  • See how dramatically this "shrinks" your While loops!!

This is the second time today I've basically advised someone to "Write the Documentation First".  It is not at all clear what you want to do, but it is pretty clear that you are not "doing it correctly".  Try writing down a description that says something like the following:

  • I want to simultaneously collect signals from X, Y, Z, A, B, and C.
  • I want to sample each one at the same time.
  • I want to sample at 100 Hz.
  • As each point comes in, I want to process it as follows:  (description here)
  • When (condition description here) occurs, I want to (further description here).

Now, it may well be that you are mostly doing "simultaneous monitoring", hence don't need "immediate processing".  In which case, you might say

  • For Channels X, Y, and Z, I want to sample at 1KHz, and deliver 1000 points once/second for further processing.
  • For Channels A, B, and C, I want to sample at 1Hz, and deliver each point for further processing.
  • I want to display (whatever) and save (whatever) to a log file.
  • I will use Buttons <Start> and <Stop> to control acquisition.

One of LabVIEW's strengths is that it is a Data Flow language, which means that it is inherently parallel and can have multiple loops running more-or-less simultaneously and asynchronously.  Something that is very useful for data acquisition/control situation is the Producer/Consumer Design Pattern -- you have a Producer loop running and gathering data (say, 1000 points at 1KHz), and as fast as the data comes it, the Producer puts it into a Queue which immediately goes to the (parallel) Consumer Loop, patiently "waiting" for data.  When the data arrives, the Consumer "eats it up", displaying it, writing it to disk, doing FFTs, whatever.  Because the Producer loop is mainly "waiting on the hardware", it tends to use a tiny fraction of the CPU time, leaving the bulk of the time to the Consumer.

 

If you don't know about this, there is Sample code available.  Open LabVIEW, go to File, New ... (the dots are important), and look under Templates for Producer/Consumer Design Pattern (Data).  Choose it, let it build, then study it.  Now adapt it to your situation.

 

Bob Schor

Message 2 of 6
(6,905 Views)

Thanks for the reply I appreciate it. I made the modifications to my front panel as you suggested and I see the advantages and disadvantages with the approach. The advantage being smaller block diagram and more manageable though the disadvantage seems to be I can't easily assign a label to each element as I would have liked to as ultimatley each element will represent some specific control/monitor for our equipment but my workaround is to just place a welel sized string array adjacent so that I can easily re-name inputs/outputs as I see fit.

 

My purpose is mainly for control and not for just collecting/monitoring data and so I've no need to consume 1000 samples each iteration before processing (has since changed since my first post) , just one though it might be worthwhile to perform an average of some sort if it makes sense but for now i need for example:

 

1 analog thermocouple acquisition --> then a process check for overtemperature --> then write to interlock analog/digital outputs --> repeat.

 

To me it seems that for whatever reason the hardware of the NI 9212 is just slow to generate the data (maybe there is some internal noise reduction required before producing a sample?)

 

I have found that the slowdown seems to be associated with the creating of a task and that before I was using the DAQ assistant too frequently (called in each loop). I have sinced created a new task for all the inputs/outputs, placed these outside of my loops and have seen my speed across all input/output modules improve dramatically however the Thermocouple input still seems capable of updating only 2x a second (Still an improvement from once every 2.5 seconds.)

 

At this point I'm thinking there is some inherent delay in calling this particular task as again, the other modules i'm interacting with don't seem to pose any sampling issues (all producing data as quickly as I can process it). I suppose it might make sense as there generally seems to be noise associated at the start of reading a thermocouple so this might be the limiting factor.

 

 

0 Kudos
Message 3 of 6
(6,813 Views)
Solution
Accepted by topic author alaut

What timing mode do you have configured for the 9212?

If in high resolution, it can only achieve 1.8 Samples/sec. See page 7 of the spec sheet here for rates for teh modes supported:

 

http://www.ni.com/pdf/manuals/374389a.pdf

 

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
Message 4 of 6
(6,800 Views)

Yep that did the trick! Thank you.

 

Now I had the oppurtinity to figure out what channel nodes are.

0 Kudos
Message 5 of 6
(6,783 Views)

alaut:

 

Please my my post as the solution so others in the future know how to directly solve the issue if relevant. A kudo would be an added bonus 🙂

 

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
0 Kudos
Message 6 of 6
(6,777 Views)