LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error: 200279. Problems reading three signal with NI 9234

Solved!
Go to solution

I have trying to read three signal at the same time with NI 9234. But I have problem with the buffer, I have read about this error and tried all the possible solution that they gave (increasing sample per channel or increasing number of sample per channel or decreasing the rate) but still nothing. I also try a Producer/Consumer Design Pattern architecture but nothing, it still get that error. Can somebody know how to fix it?

 

Captura.PNG

 

0 Kudos
Message 1 of 9
(3,673 Views)

Just a thought, try removing the wait until next ms counter in your producer loop



-Matt
0 Kudos
Message 2 of 9
(3,660 Views)

Nothing, it still appear the same error.

 

Captura.PNG

0 Kudos
Message 3 of 9
(3,657 Views)

This code works on my 9234. I would suggest going into NI MAX and checking your hardware. Have you used this device before?



-Matt
0 Kudos
Message 4 of 9
(3,651 Views)

I can't see why you are getting that error.

 

How long does it take before the error comes up?

 

But I do have 2 tips for you.

 

1.  Index Array doesn't need all of those constants.  You get indices 0 1 and 2 by default if they are unwired.

2.  Wire an array of waveforms constant into your Obtain Queue function.  That gets rid of the coercion dots when you transfer the waveform array over.

0 Kudos
Message 5 of 9
(3,650 Views)

Well, I have realised that the error only happened when I was in "highlight execution", that's wear 

0 Kudos
Message 6 of 9
(3,644 Views)

I'll take a stab at it.

 

First, get rid if that coercion dot!  Select the "Analog 2D DBL NChan NSamp" instance of DAQmx Read.vi (Or use a 1D array of Waveform for the Queue data type and a waveform graph.)  Then, lets look into that index array.  The indexes do not need any inputs Smiley Surprised the default would be row 0 followed by row 1 and row 2 that auto indexing is ecaxtly what you want and get without those int constants. AND, find some way to stop that while loop without an error or the abort button.

 

Neither of the first two is likely to be the cause of the slowness of the code!  Yet, your code is not keeping up with the hardware acquisition.   The BD shown is not the reason! (Unless you are hitting the abort button and the stop task vi doesn't run until the error occurs) Again, if you ARE hitting that abort button - STOP that you are only causing yourself guaranteed early hair loss

 

  1. Have you run VI Analyzer? (do your graphs overlap?)  Refreshing the display of any control also forces any overlapped controls to refresh and this can really cause serious bottlenecks in the UI Thread
  2. How Large do those data sets get? Do you really need to visualize 1000 pts / sec / Channel forever? Are those Graphs or Charts? And, Why are there 3 of them a single control with multiple plots (or stacked plots) would be better in 99% of use cases
  3. Tell me the plots are not on separate pages of a single tab control (See my tag "I_Hate_Tabs" for full rants and reasons)
  4. Is there a greedy loop running elsewhere in parallel? 

Things to try:

  • Unload the UI Thread!  does the error still occur if this vi's front panel is not in memory? Close the vi, drop it on a blank BD and run the new caller.
  • Reduce UI Thread Load! 300 new pts per 10mSec is a lot more information than a user can process visually! Humans are really slow like that. Try slowing the loop rate down to 200mSec halving the UI Thread load and users will never see the differance
  • Defer UI Thread workload:  Stick a "Defer FP Updates" write property node ( before and after the consumer loop case structure (True before, False after) and some really nifty stuff changes way down deep in LabVIEW Land 

"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 9
(3,630 Views)
Solution
Accepted by topic author lincoln1991

@lincoln1991 wrote:

Well, I have realized that the error only happened when I was in "highlight execution", that's wear 


So problem solved.  Now you you know why.

Message 8 of 9
(3,622 Views)

@RavensFan wrote:

@lincoln1991 wrote:

Well, I have realized that the error only happened when I was in "highlight execution", that's wear 


So problem solved.  Now you you know why.


Well, That little bit of information makes it a bit easier to figure outSmiley Very Happy And here I was racking my brain for a GOOD reason the code bogged down.


"Should be" isn't "Is" -Jay
Message 9 of 9
(3,617 Views)