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.
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.
Solved! Go to Solution.
First, some basic suggestions:
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:
Now, it may well be that you are mostly doing "simultaneous monitoring", hence don't need "immediate processing". In which case, you might say
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.
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.
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:
Yep that did the trick! Thank you.
Now I had the oppurtinity to figure out what channel nodes are.
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