From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Reading and writing from/to DAQ-Device more then 10 times a second.
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.
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.
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…
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.
@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.
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!)
