Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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

Re: Velocity PID Programming: Terms dependent on time
 

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

Re: Velocity PID Programming: Terms dependent on 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.

Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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

Re: Velocity PID Programming: Terms dependent on time
 

Look under Real Time -> RT Timing

They use a 32-bit internal counter.

Re: Velocity PID Programming: Terms dependent on time
 

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

Re: Velocity PID Programming: Terms dependent on time
 

I added the Tick Counter.

Re: Velocity PID Programming: Terms dependent on time
 

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.

Re: Velocity PID Programming: Terms dependent on time
 

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.

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

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.

Re: Velocity PID Programming: Terms dependent on time
 

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

... instead of this:

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


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

Excellent !