View Single Post
  #6   Spotlight this post!  
Unread 30-01-2013, 12:15
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,101
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Velocity PID Programming: Terms dependent on time

Quote:
Originally Posted by Tom Line View Post
While I understand running in a forced timing loop will get good results, forced timing in LabVIEW results in a very high processor utilization.

"Waited" loops are only a minimum. For instance, if you have a 20ms loop and your timing control is a 20 ms wait, the actual loop execution time is never shorter than 20ms, but can be as long as it likes.

Forcing priority so that a loop runs at consistent timing last year added 10-15% processor utilization.
Quote:
Originally Posted by apalrd View Post
I've had good luck with the RT timed loops. They do eat a lot of CPU usage, but they are worth it.
Why do RT timed loops "eat a lot of CPU usage" ? Is the context switching overhead for a timed loop really that much different from a "waited" loop?

For example, let's use Tom's 15% number. Let "X" be the actual execution time, in ms, of the code in his 20ms task. Then we have:

X/20 - X/(20+X) = 0.15

... which gives X = 9.4 ms.

So Tom's "20 ms" waited loop is actually running at a period of 29.4 ms, not 20. No wonder it uses more CPU time when you actually run it at 20 ms (using a timed loop).