LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading and writing from/to DAQ-Device more then 10 times a second.

Hey Guys,

for my Bachelor-Project I am using the NI USB-6216 DAQ-Device. I want to read 2 Analog Inputvoltages and once a threshhold is reached i want to set a digital Output to 1 (5V). In Labview i am using the DAQ-Assist inside a whileloop and for reading I set the mode to continous samples, the samples to write to 100 and the Rate to 1kHz. Now the Daq-Device needs 0.1 Seconds to gather the 100 samples. Therefore my Whileloop needs 0.1 Seconds for each iteration. It would be nice for my Project, if i can acquire the data faster, so that my whileloop only needs 0.01 Seconds for example. But when i increase the rate from 1kHz to 10kHz i get Labview error 200279.

Do you have an idea how i can fix that or is 0,1 Seconds per iteration the fastest I can achieve?

Thanks for your help in advance!

 

Greetings overhandshuffle

0 Kudos
Message 1 of 10
(231 Views)

Error code -200279 (the negative is important) states that the "application is not able to keep up with the hardware acquisition."  In other words: there is other things in your loop slowing it down so that you cannot iterate within 10ms, therefore filling up the buffer for the analog inputs.

 

This typically means you need to use a Producer/Consumer setup.  But you may also be able to get away with optimizing your code.

 

You will have to supply some code if you want any more detailed help.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 10
(214 Views)

In addition to what crossrulz said I would recommend getting rid of the DAQ Assistant and use DAQmx functions. DAQmx is not hard and the added flexibility often makes achieving your goals much easier.

0 Kudos
Message 3 of 10
(211 Views)

Thanks for your help so far. So pobably the other "things" in my while loop are slowing down the process. 

I just created a blank Vi and u are right i can use much higher sample rates without the error.

Since i am very new to Labview i only use the DAQ-Assist and a normal while Loop.

Here is my code so far, i know its a bit messy since i am trying a few things right now.

Maybe u see a big mistake why the other code takes so long...

Thanks for your help again!

 

Greetings overhandshuffle

0 Kudos
Message 4 of 10
(162 Views)

Hi shuffle,

 


@overhandshuffle wrote:

Since i am very new to Labview i only use the DAQ-Assist and a normal while Loop.

Here is my code so far, i know its a bit messy since i am trying a few things right now.

Maybe u see a big mistake why the other code takes so long...


Several mistakes:

  • Trying to read 1k samples at a samplerate of 100kS/s and so trying to iterate at just 10ms. And also trying to write data to file(s) also within this 10ms using VI not made for fast file access (WriteDelimitedTextfile)!
  • Lots of Rube-Goldberg code! Example: What about using QR (Quotient&Remainder) to keep your counter in a range of 0…59?
  • Way too much local variables! Why do you need the "Elapsed time" local in your statemachine twice? Just use a wire instead! There are also race conditions, like with "Ausfahren" boolean, due to local variables…
  • Wrong datatypes: that enum constant left of the loop should be typedefined - and it should use the very same items as your ring control. Why is this a ring anyway and not an enum control? All those numeric constants within the statemachine should be instances of that typedefined enum! ("Standard" is written without a "t" in German as well as in English!)
  • Updating charts at 100Hz is pure nonsense. Typically 10Hz is fast enough…
  • Use better labels for all your controls/indicators! "Numerisch2/3" is too generic! Never hide labels of terminals in the blockdiagram, this just prevents code documentation…
  • Cleanup: straight wires from left to right…
Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 5 of 10
(153 Views)

Thank you for your tips.
I have now tried as far as I could to improve the program and use 2 loops.
Now the "processing loop" runs with about 100Hz. Since it is a press control, which is to extend to a certain distance, a high loop speed is important.
In the 1st case of the event structure the press is supposed to ramp up a certain time, so I have to use the "elapsed time" 2 times I think. At least I don't know a better solution than the current one.
Now to track the delay, I need to store the variable "position in mm" and the time in a csv file. Best as often per seconds as possible. Which option in Labview do you think is best for this to not slow down the loop further?
Thanks again for the help!

 

Kind regards
overhandshuffle

 

0 Kudos
Message 6 of 10
(134 Views)

Did you even study at all about a Producer/Consumer? What you have created is NOT a Producer/Consumer and will result in lost data. You have a significant race condition with your local variables. Use a queue or channel wires to transfer the data from one loop to the other.

 

Did you read GerdW's comment about acquisition rate? You've actually made that problem worse by reading fewer samples. Increase the number of samples that you are reading during each iteration of the loop.

 

There is no event structure in your code. When you have a timer you need to implement code to reset the timer when you're ready to start it. A shift register is helpful for this.

 

You should take GerdW's advice and make all of your constants use the same typedef as the enum outside the loop - it's of little use otherwise.

 

To write your data, open the file before starting writing, write data to the file, and then close once it's all completed. This means don't use the Express vis as they open and close the file each time.

 

 

0 Kudos
Message 7 of 10
(122 Views)

Regarding the Producer/Consumer Structure: I think that is not working in my case, since i have to process the data in real time. When i use Producer/Consumer loops, i will have a long delay until i can use the data right? But when i use the press i want to to stop after it reaches the setpoint asap, so it has to be in realtime right?  The data i am loosing is not important. Its important that when my Way-sensor is giving me a value above a certain threshhold the Press stops asap.

 

The reset timer sounds great i try to implement that.

 

I tried to use the same typedef, but right now i dont fully understand how to do that. I will look into that next.

 

Would it be a good way to make a shiftregister and expand an array every iteration with the new data, and safe the data after i end the program?

 

 

0 Kudos
Message 8 of 10
(113 Views)

@overhandshuffle wrote:

Regarding the Producer/Consumer Structure: I think that is not working in my case, since i have to process the data in real time. When i use Producer/Consumer loops, i will have a long delay until i can use the data right? But when i use the press i want to to stop after it reaches the setpoint asap, so it has to be in realtime right?  The data i am loosing is not important. Its important that when my Way-sensor is giving me a value above a certain threshhold the Press stops asap.

 Your comments don't make sense. You previously said that you have to acquire at high rate, but now you're saying that it's OK to throw out the data. Which is it? Also, if it absolutely has to be in real-time then you need to get a real-time operating system. As long as you consumer is running as fast as the producer then you will have approximately real-time operation without losing data.

 


@overhandshuffle wrote:

 

The reset timer sounds great i try to implement that.

 

I tried to use the same typedef, but right now i dont fully understand how to do that. I will look into that next.

To use the same typedef you have to save the typedef and then use it.

 


@overhandshuffle wrote:

 

Would it be a good way to make a shiftregister and expand an array every iteration with the new data, and safe the data after i end the program?


As long as you're not collecting too much data that will work.

0 Kudos
Message 9 of 10
(100 Views)

Hi shuffle,

 


@overhandshuffle wrote:

Now the "processing loop" runs with about 100Hz. Since it is a press control, which is to extend to a certain distance, a high loop speed is important.


Now your DAQ loop is set to run at 1kHz. Please check your math!

 

Still a lot of Rube-Goldberg: what's the point of using array constants containing exactly one boolean element and ORing them with another boolean value while needing another BuildArray to create the needed datatype? Why not use scalar booleans and building the array just before the DAQAssistent? (This would also remove the error of having an empty array constant as you did implement in your case structure!)

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 10 of 10
(95 Views)