Error -200279: Unable to Keep Up with Acquisition in DAQmx

[Aljon96]

Hi everyone,

I've been working on Labview for the last month since I needed a data aquisition and control system for my tests. What I really need from my VI is to aquire data (my tests last for at least 6-7 hours and I aquire the signals at 1kHz) and control some devices of my system. I have three analog input which I want to log and continously control. 

I'm new to Labview environment and I cannot overcome the Error-200079. This error manifests after few hours of testing. At first I notice the data in the GUI lagging and then the error 200279 error appears. This happens after I've logged few milions of data points. 

I've implemented the producer consumer architecure and tried to simplify the software as suggested in other discussions but that didn't really solve the problem.

In the code you'll see a subVI ("Conversione_Temperatura") that is used to convert the voltage I read to the value of temperature.

I notice my computer starts the fan at maximum speed for cooling as soon as I run the VI (maybe too much calculation?).

I've attached my Aquisition and Control VI so you can verify.

Thank you in advanced.

[Kevin_Price]

I wanted to take a look, but I don't have LV2021 installed.  Please do a Save for Previous Version back to ~LV2018 or earlier so more of us have an opportunity to help.

-Kevin P

[JÞB]

First get rid of the Dynamic Datatype. it is confusing the bejezus out of you!

You have an array of three waveforms with 100 samples in each waveform (we will come back to that size later- its wrong one way or another)  You are somehow incorrectly converting that to three scalar points and losing %99 of your data.  Everything everywhere that you scale or display the data would also work fine on a waveform datatype.  your queue should be of scalar waveform type.

Next, (and your problem start) pass all of your data into a queue to analyze and display. do not analyze and display the data in the acquisition loop!

Finally, leave the samples per channel input unwired (-1 read all available samples) and throttle the loop to 100mS (Not always the correct decision, but it works very well when you've miswritten a P-C (data) architecture and tried to manipulate or display acquired data  in the same loop as the acquisition.

Now, as an alternate solution to rewriting your vi, you could also THROW THE WHOLE MAIN VI OUT! and simply use the Continuous Measurement and Logging DAQmx project template and revise it in half the time it would take to fix your vi 

[Aljon96]

Thank you so much for you time! I will take your advice and go for the project template and work on it.

[Bob_Schor]

While in principle I agree with @JÞB to "Throw the whole main VI out", suggesting that someone new to LabVIEW tackle modifying a LabVIEW Project Template based on the QMH is only going to lead to more confusion (it even confuses me).

The data rates you are using are modest.  As you are a relatively new LabVIEW user, you need to learn a bit more about DAQmx, and about some simple ways to take advantage of LabVIEW's Data Flow architecture to allow you to "Aquire Your Data and Save It, Too (simultaneously)" (that's a bad pun from a common expression in English).

First, DAQmx.  There are pretty good introductions to DAQmx.  In particular, there is "Learn 10 Functions in NI-DAQmx and Handle 80 Percent of your Data Acquisition Applications".  Ignore the first step -- almost Never use the Dreaded DAQ Assistant (which I abbreviate as the DDA), and especially never use its Evil Twin, the Dynamic Data Wire.

You didn't mention what DAQ device is taking your data.  But plug it in, and "play with it" in MAX.  Build a test panel that does the following:

• Has the Channels you are using (I encourage you to name them something other than AI0, AI1, etc.).
• Has the sampling and timing set properly.  Do use Continuous Samples, and check the data rate.  Think about how big your sample should be -- 1000 points might make sense unless you need to "see every tenth second of data".
• Run your Test Panel.  See if the data being display in MAX looks OK.  If this step fails, then you have hardware issues.
• Save your (working, I hope) Test Panel as a DAQmx Task, with a sensible name (I don't know why Task names can't have spaces, but maybe they changed that while I wasn't looking ...).
• Now write your acquisition routine.  It requires maybe 3-5 DAQmx functions:  Start, Read, Stop.  Right-click the upper-left input of Start Task, and create a Constant.  Now click the little triangle on that Constant, and MAX should show you the Task you just created.  Use that one.  Now put a While loop around the DAQmx Read, wire it to DAQmx Start Task, and continue the Task and Error Line wires out of the While Loop and into the DAQmx Stop Task (and Clear Task, if you want).
• But what about the data?  As @JÞB mentioned, you don't want to waste time processing it in your Acquisition Loop.  You want to "export" the data to a parallel loop that does whatever else you want to do with it.  I see you have some familiarity with Asynchronous Channel Wires (you used a Tag Channel Wire to stop the Control Loop).  I recommend that you use a Stream Channel Wire to connect the cDAQ Reading loop with a "Graph and Save" loop.  This passes the acquired data out of the loop the instant that it comes in, so allows the cDAQ Reading Loop to do nothing but "read the cDAQ".  Put a Case statement around the DAQmx Read statement and wire the Stop DAQ control to the Case Selector.  If it is False (meaning "not stopped"), simply pass the array output (making no changes to the Waveform Array wire) to a Stream Channel Writer.  If it is True (meaning "Stop"), put another Stream Channel Writer (copy the one in the False case, without the inpu wire, right-click on the input, and say "Create Constant" which puts an empty Array of Waveforms there).  Now wire the two left inputs of this "Last Stream" writer with False to the top "Element Valid" terminal and True to the bottom "Last Element" terminal.  There are corresponding terminals on the Reader in the Graph and Save Loop.  You again need a Case Statement to process the Data if valid, and a second wire to go to the "Stop" Control of the Graph and Save Loop if it is the Last Element.
• I see you also have a "Control" loop.  I'm not sure what this does -- if it always runs, then you could put it into the Graph and Save Loop, but if it functions autonomously, then you may need slightly different logic for it.
• That's a lot of talk, so you now need to do a bit of work and thinking about your Project.  Better that you do it yourself, you'll learn (and remember) much better.

Bob Schor

[JÞB]

Excellent post BS however, I am going to point out that the Shipping Project Templates each link to extensive help files and even online developer walk-throughs in video format.  The help even explains each of the concepts involved in the template such as; and link to even more basic concepts the specific template builds on from other sources

• Event handling (Main.vi)—The Event Handling Loop that produces messages based on front panel events, such as the user clicking Start or Settings.
• User interface messaging (Main.vi)—A Message Handling Loop that receives messages from the Event Handling Loop and responds by sending messages to the other Message Handling Loops.
• Acquiring data (Acquisition.lvlib:Acquisition Message Loop.vi)—A Message Handling Loop that continuously acquires data.
• Logging data (Logging.lvlib:Logging Message Loop.vi)—A Message Handling Loop that continuously logs acquired data.
• Displaying data (Main.vi)—A While Loop that updates the waveform chart with acquired data.
•  

Basically everything a neophyte needs to create a running main vi.

Tim, et al ( and even i) might argue better practices on esoteric points.

• Stopping a consumer loop on queue destruction (resolved see edit)
• No AE lvlib with API and example for the Acq loop. 
• The Queue lvlib is unfinished and queues should be named (it should depend on a nice reuse cmd Q ppl)
• Queue Command and Data data types <Enum, Var> vs <String, Cluster>vs <String, Var> 
• Etc...

It's absolutely WEAKEST failing is the missing meaningful ICONS for the Data type defs! (Almost unforgivably lazy programming) 

[EDIT] The type def icons are fixed! AND queues stop with "Exit" commands (and have a default developer error case for bad cmd strings)  at least in 2022Q3 I'm not sure when that happened!

But, it's 99.8% solid working code with justifiable design decisions. 

Advising against the use of the shipping Project Templates is like asking a child to learn to read without a book.

[Bob_Schor]

---

@JÞB wrote:

Excellent post BS however, I am going to point out that the Shipping Project Templates each link to extensive help files and even online developer walk-throughs in video format.  The help even explains each of the concepts involved in the template such as; and link to even more basic concepts the specific template builds on from other sources

But, it's 99.8% solid working code with justifiable design decisions. 

Advising against the use of the shipping Project Templates is like asking a child to learn to read without a book.

---

@JÞB -- Criticism accepted, and probably "on target".  I believe I looked at the QMH about a decade ago (maybe more?), when I was a little greener but knew that having the Producer exit and destroy the Queue to force the Consumer to "error out" was, to say the least, not "polite".  I'd recently learned about the concept of a "sentinel", so I had the Producer send an "empty array" before it exited, leaving the Queue intact, and had the Consumer test for this "sentinel" and exit, and destroy the Queue (knowing that the Producer had already exited).  I sure hope that the QMH doesn't cause deliberate errors any more as part of its shutdown procedure ...

Bob Schor

[mcduff]

---

@Bob_Schor wrote:

• Now write your acquisition routine.  It requires maybe 3-5 DAQmx functions:  Start, Read, Stop.  
• But what about the data?  As @JÞB mentioned, you don't want to waste time processing it in your Acquisition Loop.  You want to "export" the data to a parallel loop that does whatever else you want to do with it.  

Bob Schor

---

I suggest including the "logging" function also. Never use a separate loop to save the data because the built in logging function is really good. You can use another loop to display your data, but one shouldn't be needed to store your data with the built in logging functions. 

[JÞB]

---

@mcduff wrote:

I suggest including the "logging" function also. Never use a separate loop to save the data because the built in logging function is really good. You can use another loop to display your data, but one shouldn't be needed to store your data with the built in logging functions. 

---

In this case. The OP applied a scale to one channel that was not linear, nor logarithmic.   It may be some strange polynomial but is written oddly.   Else I would have mentioned that option myself.  Unfortunately, DAQmx Scales do not support function nodes.  So, DAQmx Logging is off the table.

[mcduff]

---

@JÞB wrote:

---

@mcduff wrote:

I suggest including the "logging" function also. Never use a separate loop to save the data because the built in logging function is really good. You can use another loop to display your data, but one shouldn't be needed to store your data with the built in logging functions. 

---

In this case. The OP applied a scale to one channel that was not linear, nor logarithmic.   It may be some strange polynomial but is written oddly.   Else I would have mentioned that option myself.  Unfortunately, DAQmx Scales do not support function nodes.  So, DAQmx Logging is off the table.

---

Didn't see the VIs, no LabVIEW on the computer. Thanks