what's wrong with timed sequence?

[ben64]

I'm setting the first frame duration to 40 ms et the second frame duration to 60 ms. There is not much happening in the frames so I would expect a relatively precise result but what I'm measuring is way out, 47 ms for the first frame and 109 ms for both frames! Am I setting somethings wrong? I want to use something like this with an IO board (PCI-6518) as a custom drive for a stepper motor. Now, with this imprecision on the timing I should probably start to think of an alternate solution. Note: by changing the first frame duration to a lower value the delay jump from 47ms to 31ms (and jump back to 47ms by increasing it back) so htis may very well be related to the OS.

Using LV2009 with winXP.

Ben64

[Yamaeda]

Welcome to windows. Timings are never guaranteed in a multitasking OS.

I get very little delta on your .vi, but still. 

Often free waits seems better, but much of it surely related to the OS.

/Y 

[ben64]

I tried the wait function and the result was similar. Still I would have expected a slightly better performance with the timed sequence.

Ben64

[altenbach]

It runs pretty reproducibly in my newer version of LabVIEW. One thing is of course the fact that your "get time"  function is not necessarily synchronized exactly to the start of the sequence. Why don't you get the timing information from the actual sequence terminals?

[SteveChandler]

Get out of the UI thread. Using locals in the structure forces you into it. Delete the three Boolean locals and indicators and see if that changes anything.

[elset191]

---

@Steve Chandler wrote:

Get out of the UI thread. Using locals in the structure forces you into it. Delete the three Boolean locals and see if that changes anything.

---

I thought the advantage locals had over Value properties is that they don't run in the ui thread?

[SteveChandler]

I just edited while you were typing. I think that having any front panel controls or indicators will cause the structure to run in the UI thread. Using another loop with controls and indicators inside of it, then updating those from the sequence structure using a queue might help.

[elset191]

---

@Steve Chandler wrote:

I just edited while you were typing. I think that having any front panel controls or indicators will cause the structure to run in the UI thread. Using another loop with controls and indicators inside of it, then updating those from the sequence structure using a queue might help.

---

Oh, I hadn't looked at the code, didn't realize there were controls/indicators in the loop.  I gotcha now.

[SteveChandler]

Take a look at this thread:

http://forums.ni.com/t5/LabVIEW/Front-Panel-decorations-affect-loop-execution/m-p/2023194#M662952

The poster was trying to get a 100 iteration per second loop. Putting a recessed frame on the front panel caused the loop to iterate between 60 and 80 times per second. Removing the frame (or just minimizing the front panel) allowed him to get very close to 100 times per second. He was verifying the iteration time using an oscilloscope connected to an IO he was toggling.

Putting the timed sequence structure in a subVI and changing the execution environment from "same as caller" to something else might help. Also try turning off debugging and changing the execution priority. These are just guesses but they might help.

Edit: Even if you get it to work you are still at the mercy of Windows. If something horrible will happen if you don't update the motor phases at exact intervals you will want to reconsider Can you set a hardware timing source with your IO card? I don't know anything about those but they might have a timer you can use to drive the loop. But even then I am not sure it will be guaranteed to be deterministic.

[Wayne.C]

ben64,

You need to give each frame a deadline.  Depending on how this gets used in your app, consider using a timed loop with additional frames instead of the timed sequence.