Velocity PID Programming: Terms dependent on time

[apalrd]

Originally Posted by Ether

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?

I'm not really sure.

In all tests I've done, they just do.

It's likely the fact that the code is actually running faster than a waited loop.

[Ether]

Originally Posted by apalrd

It's likely the fact that the code is actually running faster than a waited loop.

Running faster, as in "task period is shorter". Makes sense.

[simpsonboy77]

I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms. Before you do your dt calculation you can figure out how much time has passed by asking for the current system time and subtracting the last time you asked for the time. I think this is much better than any loop that you state how long it takes. This will account for anything that changes the cpu load, perhaps vision code or the garbage collector.

new_time = current_sys_time
do pid calculations with dt = new_time - old_time
old_time = new_time

[apalrd]

Originally Posted by simpsonboy77

I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms. Before you do your dt calculation you can figure out how much time has passed by asking for the current system time and subtracting the last time you asked for the time. I think this is much better than any loop that you state how long it takes. This will account for anything that changes the cpu load, perhaps vision code or the garbage collector.

new_time = current_sys_time
do pid calculations with dt = new_time - old_time
old_time = new_time

The same thing exists in LabVIEW. It's the 'Tick Count' block with the same 1ms accuracy.

I *believe* there's a more accurate Tick Count in the RT section that can measure from other clock sources. BUT, I haven't ever needed more than ms accuracy.

In an ideal realtime world there is no garbage collector, all of the RAM is statically allocated in blocks and never dynamically allocated. In an ideal realtime world, people also don't try to run vision on the same processor that runs hard RT control loops without actual RT control loops, when the RT task is already using the majority of the CPU, and expect the non-RT control loop to be reasonably consistent.

[Ether]

Originally Posted by simpsonboy77

I'm not certain about labview's implementation but in C++ you can request the system clock for its time since it powered up. This has a resolution of 1ms.

If the resolution of the "system clock" is truly 1 millisecond (as you said), then if you're running a control loop at 10ms, you could have an error up to 20%.

There's a much more accurate system timer that is available:

Timer::GetPPCTimestamp() has low overhead and returns time in seconds in double precision with 1/3 microsecond
resolution. According to the WPILibC++Source20120204rev3111 source code date February 4 2012, it uses a 64-bit
counter incrementing at 33MHz, which if true wouldn't overflow in your lifetime. Warning: I'm told that earlier versions
of GetPPCTimestamp() used a 32-bit counter instead of 64, and would rollover every 130 seconds. Check the source
code on your machine to make sure.

[kenfox]

Originally Posted by Ether

There's a much more accurate system timer that is available

There are 3 ways to get a timestamp in the 2013 WPILib C++ code. All of them are black box calls into lower level code, so the information here comes from the comments. If I have time tomorrow I will test timing on the cRIO and cRIO-II.

Timer::GetFPGATimestamp() and ::GetClock() -- double precision seconds since FPGA was reset. Uses FPGA clock so is synchronized with other FPGA timers. FPGA clock counts time in microseconds with an unsigned 32-bit integer. Rolls over every 71.6 minutes. (Timer::Reset does NOT reset the rollover.)

Timer::GetPPCTimestamp() -- double precision seconds since cRIO was powered on. Uses PPC system clock so is not synchronized with FPGA timers. Hardcoded assumption of 33MHz in WPILib. The counter is fetched with niTimestamp64() so it's probably 64-bit and rolls over every 9 billion minutes.

::GetTime() -- double precision seconds since January 1, 1970. This uses the vxWorks real-time clock which I can't find documentation on. The API allows nanosecond precision which seems optimistic.

[Tom Line]

Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.

[Ether]

Originally Posted by Tom Line

Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.

Most graphical languages have built-in support for C. Perhaps a LabVIEW guru could post a simple example how to call the 3 timers kenfox listed.

[Ether]

Originally Posted by kenfox

There are 3 ways to get a timestamp in the 2013 WPILib C++ code. All of them are black box calls into lower level code, so the information here comes from the comments. If I have time tomorrow I will test timing on the cRIO and cRIO-II.

I wonder:

1) how many layers of code are wrapped around each of these timers, and

2) can each one be used in a critical section, and

3) how long does each take to execute, and

4) is there anybody who has authoritative answers to these questions

[Mark McLeod]

Originally Posted by Tom Line

Anyone know if there is a common high-resolution timer that can be called from LabVIEW? I'm only familiar with the millisecond resolution timer that's available from the timing palette.

Look under Real Time -> RT Timing

They use a 32-bit internal counter.

[Ether]

Originally Posted by Mark McLeod

Look under Real Time -> RT Timing

I could be wrong, but in the context of this thread I think he wants to read a high resolution timer, not wait.

[Mark McLeod]

Originally Posted by Ether

I could be wrong, but in the context of this thread I think he wants to read a high resolution timer, not wait.

I added the Tick Counter.

[BitTwiddler]

Originally Posted by Ether

Most graphical languages have built-in support for C. Perhaps a LabVIEW guru could post a simple example how to call the 3 timers kenfox listed.

While I do not claim the role of LabVIEW guru here, I remember once using LabVIEW's Code Interface Node (CIN) capability to write C code at a low level. I imagine this capability still exists within LabVIEW. I think it does but it has been years since I used it.

[kenfox]

Originally Posted by Ether

1) how many layers of code are wrapped around each of these timers

Generally 2 layers + the hardware or whatever the black box routines require. WPILib -> ChipObject (FPGA timer), WPILib -> NI (PPC timer), and WPILib -> vxWorks. All of the WPILib routines are short enough to be inlined for free, but the code structure doesn't allow it.

Originally Posted by Ether

2) can each one be used in a critical section

WPILib uses these routines outside of critical regions, so I assume they are either lock-free or have their own independent locks.

Originally Posted by Ether

3) how long does each take to execute, and

4) is there anybody who has authoritative answers to these questions

Testing may be the best way to answer these questions, but I'm also curious about the recommended/official way to handle time. It looks like the FPGA clock is preferred since the other ways of grabbing a timestamp aren't used by WPILib except in Vision. I'll collect some data on our cRIOs tomorrow.

[Ether]

Originally Posted by kenfox

WPILib uses these routines outside of critical regions, so I assume they are either lock-free or have their own independent locks.

My concern was along the following lines. If any of the layers has code like this (pardon the X86speak):

INCORRECT!!
cli   // disable interrupts
/* do something uninterruptable here */
sti   // enable interrupts

... instead of this:

CORRECT:
pushf // save interrupt state
cli   // disable interrupts
/* do something uninterruptable here */
popf  // restore saved interrupt state

.. then you can't reliably use cli in your application code.

It looks like the FPGA clock is preferred since the other ways of grabbing a timestamp aren't used by WPILib except in Vision.

What the overhead of accessing the FPGA, compared to reading the PPC clock?

Testing may be the best way to answer these questions ... I'll collect some data on our cRIOs tomorrow.

Excellent !