what's wrong with timed sequence?

[Wayne.C]

I've attached a snippet that demonstrates how to use the builtin features of the timed sequence to evaluate how it is acually running.  Note that in real life the deadlines would be adjusted to be more realistic.  Looks like the snippet feature doesn't like locals either!

[Ben]

I can not comment on the Timed Sequence But I did get some remarkably good performance from a Timed Loop using a hardware clock under LV 7.1.

The following notes were copied from this post and may be helpful.

"

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.

"

Take care,

Ben

[ben64]

Thanks to all for your help.

In this case the issue definitely seems to be with the OS. Removing the boolean controls update, adding a deadline, removing the while loop to run the timed sequence once and implement Ben advices did nothing to improve the performance (note: the Actual Start value of the middle frame was similar to the delta1 value (47 vs 0.0468674).

Too bad, this would have been a low cost solution. I'm now looking at using a digital IO card with an external clock input or a fpga based solution.

Ben64

[Yamaeda]

Win 7 64 bit with LV2011 64 bit

 

[SteveChandler]

The results on my system are identical. 0.0400023 and 0.100006 deltas. My system is identical except that I have the 32 bit version of LabVIEW.

[ben64]

These are sure better performances than with LV2009 under WinXP. But still I think using FPGA board is a safer (althought more expensive) solution since it's hard to predict the impact on the sequence timing when the write to port functions will be added to the sequence frames (and what other processes will be running at the same time).

Ben64

[Yamaeda]

A small test shows my initial reaction seems right, although i scrapped that post since it sounded wrong ... 🙂

Get Date/Time in seconds is a slow and unreliable function, try it with Get Tickcount instead and you'll get the answer in ms directly.

With that change i get exactly 40 and 100ms resp. 

/Y 

[SteveChandler]

That would be a good one for the micro nuggets thread or the minutia thread or both 🙂

[altenbach]

---

@Yamaeda wrote:

Get Date/Time in seconds is a slow and unreliable function, try it with Get Tickcount instead and you'll get the answer in ms directly.

With that change i get exactly 40 and 100ms resp. 

---

I remembered that this has been discussed in detail in the past, but I was not able to find the old thread or I would have mentioned it earlier. Anyone better at searching? 😉

[elset191]

---

@altenbach wrote:

I remembered that this has been discussed in detail in the past, but I was not able to find the old thread or I would have mentioned it earlier. Anyone better at searching? 😉

---

Maybe?