How to guarantee accurate starting time of each frame of a sequence?

[Christ0phe]

[Labview 8.21] Code attached

Hello,

I am trying to implement a LIN sequence.
Each frame must be executed at an accurate time:
Frame  0: time  0ms
Frame  1: time 30ms
Frame  2: time 55ms
Frame  3: time 65ms
Frame  4: time 80ms
Frame  5: time 105ms

Each frame with code (between the wait ms operations) takes less than 5ms to execute.

If I measure the execution time per iteration I get a lot of discrepancy between cycles. Moreover the exeution
time is very dependant upon mouse activity, window scrolling or other Windows related processes.

I have tried to use 'Timed Sequence' but with no luck as there is no Stacked Timed Sequence to assemble the 5 frames of my code and without stacking my code will become unreadable, spreaded way too far horizontally.

What is the easiest solution to guarantee that my frames 0,2,4,6,8,10 get executed at determined times?

Thanks a lot to shed some light on this.
Christophe

[Britoa]

---

@Christ0phe wrote:

I have tried to use 'Timed Sequence' but with no luck as there is no Stacked Timed Sequence to assemble the 5 frames of my code and without stacking my code will become unreadable, spreaded way too far horizontally.

What is the easiest solution to guarantee that my frames 0,2,4,6,8,10 get executed at determined times?

---

There are a lot of people who are of the opinion that Stacked sequences themselves make for unreadable code (I agree), but that isn't the question here.

Try putting your Waits inside the even numbered frames, this will cause the frame to not complete until the wait is done.  That should improve your results.  Honestly though, if you want the times to be exact, you're going to need a real-time system.  With windows (or other non-realtime OS of choice), you have no control over when antivirus will kick in, or that hard drive indexing, or a redraw of a screen because the mouse moved, etc. 

[johnsold]

Here is a way to do it with a state machine. If your platform and version of LV support timed loops, you may be able to get the timing precision you want.  Otherwise, as Britoa pointed out the OS will occasionally disrupt the timing.

If you do go to a state machine, you will find that only one Wait state is required because the End of Wait Time is passed as a parameter in the shift register.  Also making the State enum at typedef has many advantages which have been discussed at length in the Forums.

Lynn

I do not have LV 8.2 on this computer so I have not checked this VI after Saving for a Previous Version.

[Christ0phe]

Thanks for the answer. Putting the waits parallel to the code does not change the discrepency of the results unfortunately. Definitely I thought that a sort of Timed Sequences would do the trick but i do not know how to implement it.
Thanks a lot

Christophe

[Ben]

unless you can play some game with your hardware to get hardware timed actions, you will have to go with a Real-Time OS to enusre this happens at the proper timing.

Ben

[Christ0phe]

Lynn,

Thanks for your proposal. I made some tests that I attach to this answer.

LIN zoom v1 is a bit of the original vi with the wait ms.

LIN zoom v2 is a rewrite of v1 using some Timed sequence

LIN zoom v3 is a rewrite of v1 using your proposal (machine state).

v2 and v3 similarly bring a little improvement to v1. They respect more the iteration time (time between first and last frame) and are a little bit less sensitive to mouse clicks and other Windows related activities. But still the iteration time can vary sometimes between 110ms and as high as 300ms.

It is also very possible that my implementation is lacking some basic knowledge of proper sequence timing.

Also is it possible to give a sort of 'very high' priority to this while loop as compared to other loops of the code or possibly to tell the processor that this bit of Labview code has to run as a CIN for instance?

I hope this is clear enough and once again thanks for the quality of your support

Christophe

[Britoa]

So what is happening in kvLinWriteMessage? (and read message) what is it writing to/reading from (serial, ethernet, usb, a daq, etc.)?  Usually, writes and reads tend to be where the timing problems sit.

Consider using the VI Profiler to check the timing of all the VIs run in your code (Tools->Profile->Performance and Memory)

[Christ0phe]

kvLin is part of the library that reads/write LIN messages over the serial bus at 19.2kbds.

I have run several times the Performance and Memory window as you suggested but could not interpretate the results shown (see attached). All kvLin subVis are displayed with execution times of 0ms at the end of the list.

The Waveform chart (time to execute the whole sequence of frames that I refered in my previous messages) below shows the issues when clicking, moving the Performance Window,... This is really The issue that I try to fight against...

Thanks

Christophe

[LV_Pro]

Unfortunately your comments about the various "improvements" still being sensitive to mouse movements/clicks shows that you are working towards diminishing returns as long as you are in a non-Real Time OS environment. Windows is notoriously bad about throwing in lags in performance when what it considers a higher priority task comes along. You might be able to alleviate some of this with some of the timed structures available if you are running on a multicore machine, delegating some of the time critical parts to a core that doesn't seem too loaded by Windows activities, but to get real determinism (things happening precisely when planned) really requires a real-time system.

[Ben]

Let me second (third, forth?) the need for a RT OS to do this right.

But if you are stuck on Windows I'll quote myself from this thread.

---

Ben wrote:

Since this code work most of the time, we should see if there are other things with the OS that could be causing it to forget about your app and make it go off and waste its time. Here are some ideas.

1) Set Windows to optimize background services.
Windows by default will attempt to optimize its scheduling to make foreground processes perform well. For single threaded applications this is fine but for LabVIEW, some of its background threads can suffer.

A) Start >>> Control Panel
B) Open "System" and choose the "Advanced" tab
C) In the "Performance" section click "Settings"
D) On the "Advanced" tab in the "Processor Scheduling" section select "Background Services"
E) Save or apply everything.

2) Stop Indexing services.
Windows will by default do file indexing. File indexing is functionality that tells windows to maintain in memory a cache of files on a disk or in a folder. This makes files show up in the Explorer faster and also makes searching for files faster.

A) Start >>> Accessories >>> Windows Explorer
B) Right-click C: drive and select "Properties"
C) On the "General" tab un-check "Allow Indexing Service to Index This Drive for Fast File Searching"
D) Save and apply everything

3) Set LabVIEW priority in Task manager. Windows will by default treat all processes that are ready to run as peers and will share the CPU evenly.

A) Open the Task Manager and select the "Processes" tab.
B) Locate "LabVIEW.exe" in the list of processes.
C) Right -click "LabVIEW.exe" and choose Set Priority >>> High
Note: Setting LV to run at higher than "High" will put it on equal footing with interrupt service routines etc. This could result in the machine "locking up" because LV is using all of the CPU and there is no opportunity to respond to interrupts from your mouse moving.

4) Shutdown Virus Checking. Virus checking gets its hooks into everything!

5) Disconnect Ethernet cable. Ethernet traffic requires intervention by the OS. No cable, no traffic, no distractions.

With all of that in-place watch your Task Manager while the "problem" is occuring. If the CPU drops off, and you see the LV process is page Faulting, then memory allocations is definately a suspect.

If the CPU spikes, this may be due to the work required to graph the data. If disconnecting the data from the graph/chart eleminates this issue, concider using "defer FP Updates" before updating the indicator.

Does any of the above help?

Ben

---

 Adding to the above...

Putting the code in question inside a Timed seq structure will let you assign a priority to the code.

Ben