Error -1418, timed loop

[tbd]

Greetings,

      I have two timed-loops starting/running in parallel (in seperate sub VIs.)  One of the loops is immediately exiting with error -1418.

Searching on this error turns up this thread, but it doesn't seem to explain why the error occurrs on my platform (WinXP,LV2009.)

On the subject of timing-source, I noticed something odd:  With either timed-loop, if I repeatedly open/close the "Configure Timed Loop" dialog, "Frame Timing Source" may display "This structure does not have multiple frames..." or it may show source-selection options.  Both loops are single-frame, but LabVIEW is displaying some uncertainty about this.

Re: error -1418 

The timing-source is the default 1 kHz.  The loop's only input-node parameter is "period", 50ms, the same as the "working" loop.  At this point in debugging, everything in the loop, except for quit-condition-monitoring is disabled.

Q. What's causing this error?

Any help is appreciated,

Cheers!

[George_P_Burdell]

tbd-

I have a few additional questions for you about your application:

1. Are you using a Timed Loop or a Timed Sequence Structure?
2. Can you take a screen shot of the error and post it here?

[tbd]

Hi Mike,

      It's definately a Timed Loop.  Though it's possible to add frames to a timed loop in LV09, this loop has only one frame, and no frame shows around loop border.

Here's an example that's producing an error here.

Are multiple timed-loops not supposed to be used in parallel?

One further note (in case any app-engineers follow these threads,) there was some interaction between the two subVIs (each w/timed loop.)  I'd make a debugging change to one timed loop, and the other would start throwing the same error instead!  Very occasionally I'd see the error -820 (bad input), though, this example is throwing -820 most often.

Thanks/Cheers!

[GoCougs]

You are definitely able to run multiple timed loops, you just want to make sure that you aren't inducing a priority inversion.  Make sure that the priorities on your loops will get what they need, if a loop thinks that it needs more resources to accomplish the task than you have given it, it will hijack the CPU and take all the process until it is done running it's process.  look further into your code to make sure that this isn't happening

[tbd]

Hi Scott,

Thanks for the reply - but I'm still not understanding why the simple example provided is producing an error, since both loops are doing almost nothing.

Is this example causing a priority inversion?

Any further insight is appreciated!

Cheers.

[Stephen_S.]

When I run the attached VI, I am getting error -1444 on one (random) error indicator on the first run, and error -820 on one indicator each subsequent run. There is no way to determine which subVI will give the error because it appears to be whichever loop runs second, and there is nothing to define which loop runs first. Beware of possible race conditions due to this, if you want to dictate execution order, use a wire to connect the two (an error wire for example).

As for the errors, when I run the subVIs with highlight execution, it seems that the real problem is that error -808 is occurring in the initial running of the loop. Looking at a KnowledgeBase about Error -808 with Timed Loops, the solution seems to be to replace a timed loop with a while loop.

I found that if I right-clicked one timed loop, selected "Replace with While Loop", right-clicked again and went back to "Replace with Timed Loop", rewired the necessary broken wires, and ran the top level VI, I no longer got any errors.

I hope this helps.

Regards,

Stephen S.

[tbd]

Hi Stephan,

      Apparently there weren't any glaring errors in my code - it's just a timed-loop ideosyncrascy feature?

I converted both to while loops days ago, but would prefer timed-loops for more deterministic timing.  We want to read/write fresh data at 200Hz.  Testing shows there's plenty-enough CPU-cycles - we're at about 6% CPU - but I fear Windows will interject small/random delays.  I've used the timed loop before (not in parallel with other loop(s)) and will probably switch one loop back per your suggestion.

Thanks/Cheers!  

[Stephen_S.]

I believe the error you were seeing is a relatively rare corruption that can occur, and I personally had not seen it before.

A couple of points about timed loops:

Timed loops can give you more information about the timing of the iterations, but just using timed loops on a Windows machine will not give you determinism. The small delays and jitter that are inherent in the Windows OS can still cause delays in your loop. The only way to run deterministic code is to run on a real-time operating system, on a real-time hardware target.

Also, there is normally no problem with running multiple timed loops in parallel. In fact, if you have multiple timed loops in one VI running on a real-time system, the priority input allows you to assign parallel loops relative priority, which allows better control over what processes run when.

Regards,

Stephen S.

[tbd]

Hi Stephen,

      I appreciate the insight - thanks for your patience. 

I thought the timed loop offered "more deterministic timing", that is, improved timing precision - better than just using "Wait until next ms multiple".

When Scott said "if a [timed] loop thinks that it needs more resources to accomplish the task than you have given it, it will hijack the CPU and take all the process until it is done running it's process.".

... I took this as a good sign!

Regarding:

---

... just using timed loops on a Windows machine will not give you determinism. The small delays and jitter that are inherent in the Windows OS can still cause delays in your loop. The only way to run deterministic code is to run on a real-time operating system, on a real-time hardware target.

---

While I didn't imply a timed-loop should offer [absolute] determinism, your statement makes me wonder - are you implying the timing-precision of a timed loop is not inherently better than a loop gated with "Wait until next ms multiple"?  If so, that would be good to know.

[Jim_S]

Yes, the time loops only using the dt input will act like a normal while loop with "Wait until Next Multiple". If you are only using the period function of the timed while loop, I would suggest to use the regular while loop with a "Wait until Next Multiple". The timed while loop has many different functions and options which causes it to have a larger overhead than the while loop. Since you aren't using any of these functions with it and since this is machine has Windows OS, the timed while loop wouldn't be the best option for your system.