LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

deterministic timing getting out of sync

Hi, I'm running a program where I'm writing and polling an oven temperature every five seconds. It seem very simple just like in this RT help module:

 

http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtconcepts/deterministic_apps_timed_loop/

 

In my case, the only thing going on in the program is the timing loop. In this loop I write a temp to an environmental chamber (part temp a temp cycling step) and I then read and record the temperature with at time stamp, compare this value to a setpoint and then either increase or decrease the temperature as needed. The loop iterates until the required temperature is met.

 

What's happening is my timing is getting out of sync. This can happen almost immediately after starting or days into the cycling. When this happens the temperature data reads zero. Here's an example of the output. In the first set of data there's a measurement every five seconds (this was derived from the time stamp), it then went out, 5s, 5s, 7s, 4s, and then came back in. At the point it went out labview did not read the new data and gave a 0 temp. Other times, as in the non recovered data it just gets lost; 5s, 5s, 9s, 10s, 7s, etc and LV just gets stuck in an endless loop doing this while constantly not reading the data.

 

Recovered   Non Recovered
Time  Temp   Time  Temp
0:00:05 93.8   0:00:05 28.2
0:00:05 94.7   0:00:05 27.2
0:00:05 95.5   0:00:05 26.5
0:00:05 96.4   0:00:05 25.6
0:00:07 0   0:00:05 24.8
0:00:04 98.4   0:00:09 0
0:00:05 99   0:00:10 0
0:00:05 99.9   0:00:07 0
0:00:05 100.7   0:00:06 0
0:00:05 101.4   0:00:06 0
0:00:05 102.3   0:00:07 0

 

 

I've tried discarding missed periods, maintaining original phase, and changing the timing source to 1kHz <reset at structure start> to no avail. I've also tried extending the time from 5 seconds all the way up to 20 seconds. It's hard to find out what's happening when I might not see the issue for days.

 

I do not understand this behavior and I'm at a loss why it's not working and what to try next. While I need this to be pretty darn accurate, in the grand scheme of things if one loop gets off by a couple of seconds and then recovers I'm OK with that. Any help would be appreciated.

 

Thanks,

Mike

 

 

0 Kudos
Message 1 of 22
(3,097 Views)

What RT hardware are you using? The whole point of RT is that it is deterministic and your application sounds pretty simple on the face of it so I suspect that something else is at play here and causing your problems. Do you have some code you can post to show your VI?

 

Have you tried using the distributed system manager and/or putting something in your code to get CPU/memory diagnostic information?


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 22
(3,092 Views)

Here's what I'm doing in a nutshell. Thanks for looking!

0 Kudos
Message 3 of 22
(3,081 Views)

If no-one else does I'll take a look at your VI tomorrow (as long as it's not LV2014) unless you want to post a screenshot and I might be able to look at it later.

 

My previous question still stands - what RT hardware are you using?


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 4 of 22
(3,072 Views)

screenshot.jpg

0 Kudos
Message 5 of 22
(3,062 Views)

Where do I find what RT version?

0 Kudos
Message 6 of 22
(3,057 Views)

It may have to do with your change setpoint and read temperature SubVI's; can you attach a copy of them as well?

 

Also, you should not be writing to disk in your timed loop.  Disk operations can introduce significant, sometimes unstable, jitter.  You should use a method of determinist data transfer to a nondeterministic logging section, such as buffering the data in a FIFO in your timed loop, then reading the FIFO and logging it to disk in a parallel normal loop (just like is shown in the example that you linked).

 

 

Btw Sam, the source is 8.5.



0 Kudos
Message 7 of 22
(3,038 Views)

I was figuring someone would ask that. Smiley Happy These read and setpoint vi's have been working for years in an older versions of this program that we use all the time. We've never seen 0's being written out of them like this. The main difference between the programs is how it is being timed - this new version (which will add new functionality) uses these timed loops whereas the old version uses timers (made by reading the current time and comparing to the input time) and case structures. This new version also collects less data than the old. Also if I stop the program and start again it always writes/reads properly.

 

The timed loops seemed like a more elegant - and readable - solution. It just seems that somehow the timing loop is getting out of sync - maybe from a slow read/write communication - and then not getting back in sync, which can be seen in the data I posted. As mentioned, I've increased the loop timing up to 20 seconds, as well as placing time delays before, after, between the read/write vi's and still had this same issue.

 

On top of all that, my predecessor loved to make little boxes with very little functionality. Which means I'd have a bunch more vi's to post...

 

I'll look into moving the write to file. BTW, can I upload a project?

0 Kudos
Message 8 of 22
(3,023 Views)

You can upload a project.  However, the .lvproj file itself is just project settings and a list that points to the contents, so you should do something such as compress your files into a zip file an then upload that.

 

Timed loops are great, but you also need to understand exactly what they are doing and how they change LabVIEW's view of your VI.  They are not just loops with a built-in Wait Until Next ms Multiple function that you don't have to see on your block diagram Smiley Happy.



0 Kudos
Message 9 of 22
(3,006 Views)

Just a comment on your comment about style.  Wouldn't it be a lot easier to read on the top level if all that spaghetti code in your example were placed into "little boxes?"  SubVIs are okay, provided that they aren't used merely to save space on the BD.  Use them to group related functions together.  My rule of thumb is every major paragraph in a requirement gets its own SubVI and possibly subparagraphs, too.  By the time you get to sub-sub paragraphs, though, you're usually describing intricate details and you probably shouldn't slice them up any further.  If you do, you're usually "violating" LabVIEW best practices.

 

This way you can rather quickly zero in on just where any problems are occuring.  (Not to mention it's ultra easy to match up requirements with code, assuring coverage of each requirement.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 22
(3,004 Views)