LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

timing issue yields error -200279

Solved!
Go to solution

Hey

I'm having some issues in my program concerning timing and read. The issue arises with the part of my code concerning a Vaisala PTB-110 barometer. (additionally the program is connected to 4x Rotronic HF5 transmitters and 3x Brooks MFC's). It ran fine for months with available samples per channel alternating between 0 and 1, but now it just keeps on increasing before giving error -200279.

 

The intention is to have it sample every second. I have tried making the read function use the 'available samples' for the 'number of samples' but this results in every other value read being 0. I have also tried setting the number of samples to read to 2 but this messes with my save function, which is built to collect based on time.

 

The problem has me stumped as nothing has been changed compared to when it worked fine.

 

Included is the section of the code which deals with the PTB-110.

 

I hope someone can help me figure out what's wrong. If anything else is needed to figure this out let me know.

 

Thanks in advance

Morten Tschiskale

0 Kudos
Message 1 of 3
(2,582 Views)
Solution
Accepted by topic author MTtinglev

Not sure I understand everything that you're trying to do but....

 

 

It looks like you're setting up a continuous sample with a sample rate of x ms/sample (say 500ms).  You then feed the 500ms into the while loop and I imagine off the screen is a wait function.  This means the while loop will iterate at a little more than 500ms/iteration (assuming there's nothing slower inside the loop) and come back to see if there's a sample ready.  This means that the effective read rate is slightly slower than the sample rate and the # available will creep up indefinitely. If something is much slower inside the loop (e.g. something takes 750ms to execute) you're problem will be worse.  I would try outputting a millisecond timer reading to an indexing output of the while loop to see what your loop rate really is.

 

Seems odd that you're using "N channel, N sample" and immediately indexing out the first sample of the first waveform.  No other comment other than is seems odd.

 

If you can tolerate a little bit of jitter in the timing of your readings you might try a single reading (1 channel, 1 reading, not continuous) inside the while loop (or better yet inside a dedicated parllel loop) and do away with the sample clock and available readings stuff.  

Message 2 of 3
(2,541 Views)

Hey

Sorry it took such a long time to get back to you. We had to move the lab and set everything up before i could test anything. Your explanation on the timing gave me an idea. I inserted instances of the overall code in sequence structures, added a loop time counter that i used to fixate the "wait-until-next-multiple". I used this to monitor the running of the of the program.

 

With all 12 parts operating at the same time I now have that One second it reads "700ms" and the following second it reads "1300ms". It changes continously between these two values which I think is fine as it adds up to 2 seconds.

 

So thanks alot for bringing me towards the right answer.

0 Kudos
Message 3 of 3
(2,287 Views)