Timed Structures Cause vi to Lock

[Saturn233207]

I've been programming with LabVIEW since 1991...  Recently I've had a problem using a timed while loop (1 kHz default clock).  The vi will just intermittently freeze with no error code.  The only way out is to use the Task Manager, then, a reboot is required to get serial COM ports to work again.  The LabVIEW abort button does not work.  Yes, I know that one cannot use two timed structures with the same structure ID on the same PC. One cannot copy and paste a timed structure without changing the structure ID...

When I replace the timed while loop with a regular while loop (millisecond multiple timer) the code runs just fine with no freeze.  We have 3 (identical older reconditioned W7 workstation) PCs to deploy *.exe on.  On one of the three the code runs just fine with a timed loop.  On another it freezes 2 or 3 times a day and on the third will freeze every few minutes.  I removed the timed while loop on the third PC and the vi runs just fine.

I am starting to think that the RTC (real time 1 kHz clock for timed structures) and or its interface to the CPU in the 2 PCs on which code with a timed loop freezes is degraded.  I did put in new CMOS batteries when I received the 3 PCs.

Has anyone else experienced a similar problem?

Is there a vi to perform a RTC accuracy/functionality test?

Code not attached as large with numerous sub vi's in *.lvproj.  However, just an empty timed loop can freeze.

Lloyd

[GerdW]

Hi Saturn,

on a non-RT system you usually don't need the TWL structure…

It has one disadvantage: the TWL forces all code within into one thread and so may change code behaviour when compared with a usual While loop.

Why do you need those three TWLs?

Yes, I know that one cannot use two timed structures with the same structure ID on the same PC. One cannot copy and paste a timed structure without changing the structure ID...

I even had that problem too: having two TWL using the same ID after copy&paste…

[Kevin_Price]

I second the questions from GerdW.   Some years back I dabbled a bit with Timed Loops but haven't used one in a long time under Windows.

While the elevated priority seems to help make timing a little less erratic, it still falls well short of truly deterministic.  So you still have to code in ways that can accomodate indeterminism.   It's more or less the same stuff you'd have to do with regular While loops and Wait functions.

I don't have specific insights for the occasional freezes, but the fact that regular Waits don't show such symptoms might be a good reason to scrutinize the assumptions that led to the choice of TWL's in the first place.  They appear capable of causing serious problems (lockup) -- do you *know* they're delivering a significant benefit when not causing lockup?

-Kevin P

[crossrulz]

On a PC, Timed While Loops are next to worthless.  They add overhead and eliminate parallelization with still no real guarantee on your timing.  Just use a normal WHILE loop with a Wait Until Next ms Multiple to basically match the functionality of a Timed While Loop.

[Saturn233207]

Thank you GirdW, Kevin P and crossrulz.  I'm using LV 2013 full... On some Windows PCs timed while loops work great for me, as long as I make sure all code can execute in each iteration I can discard missed iterations and maintain phase.  Another nice thing about TWL is that if you are running 2 or more parallel codes you can assign the processor...  But on other, particularly older, Windows PCs of the exact same model the exact same code locks up.  I'm pretty sure it is a RTC issue as there is a clear machine dependency...  Not running 3 timed loops in 1 code.  1 timed loop per code.  2 codes per machine with different timed loop ID and in different projects.  2 independent test apparatus on 1 PC...  But on some PCs even just 1 code with a single timed loop crashes.

I'm changing flow rates of toxic gases and looking for electrochemical sensor response times etc.  We try to get as close as possible...

But, in the application for a BIG customer we are working on now we can occasionally go 2 seconds and not 1 between iterations.  So, the normal while loop will work.

I'll wait a bit for more input about possible bad RTC issues then mark this solved.

Lloyd

[Kevin_Price]

FWIW, the ability to maintain phase was one of my motivations for dabbling with TWL's in the first place.  It "felt right" to be able to assign different phasing for different loops running at the same rate to help smooth out CPU demand compared to having them all wake up and do their processing at the same time.  I was carrying over thoughts from RT world where I'd previously done such things to reduce jitter.

Over the years, CPU's have sped up and multi-core has become commonplace.  I found that my caution about CPU contention and jitter wasn't giving me any noticeable benefit.  (Not saying it never could, but in my apps I wasn't seeing it.)   These days when I want to maintain periodicity and phase,  I recalc a self-correcting Wait time each iteration.  Still not deterministic, but at least timing error is non-cumulative.   It's pretty easy to package up this functionality into a subvi that occupies no more space than the Wait primitive.

One little tidbit (that you may very well not need a reminder about): 

- control loops benefit most from consistent iteration timing

- data analysis benefits most from accurate time-stamping (i.e., knowledge of the sample times is more important than maintaining consistent sampling intervals)

While I don't particularly advocate TWL's, I would only *consider* one for a control loop.

-Kevin P

[crossrulz]

---

@Kevin_Price wrote:

While I don't particularly advocate TWL's, I would only *consider* one for a control loop.

---

And for a control loop I would be looking at a cRIO, especially if there is anything remotely safety critical.  I am especially fond of doing control in the FPGA if possible.

[Kevin_Price]

---

@crossrulz

---

And for a control loop I would be looking at a cRIO, especially if there is anything remotely safety critical.  I am especially fond of doing control in the FPGA if possible.

Fully agree with the sentiment, particularly for safety critical control processes.  But I've often found myself in situations where we had to do the best we could with what we had on hand.

In a prior job of mine there were dozens of similar test stands controlling gas flows and where improper mixing could be a serious safety concern.  The control PC's were running Windows.  A combination of electronically controlled valves and a watchdog power control that depended on regular pings from the Windows PC's control loop helped make the overall system safe.

To the OP: having experiyenced lockup -- whatever the cause may be -- you now need to consider the possible consequences of future lockups.  That may push you toward something like cRIO, or perhaps you can do something like we did with a watchdog and valves.   Even if you manage to identify and fix the immediate root cause, don't assume lockup won't happen again for other reasons.

-Kevin P