Re: Velocity PID Programming: Terms dependent on time
 

That may be a problem, but I couldn't figure out a way to test it. I/O interrupts in WPILib are partly handled by the FPGA. Reading the FPGA clock looks similar to reading a global variable from the FPGA, so if there are bugs with interrupts, it probably affects more than just the clock. Reading the PPC clock is so fast it probably doesn't mess with interrupts--I'm not even sure if it's a system call.

FPGA clock access takes 50x the PPC clock.

Over 100,000 calls, mean clock access times were:

FPGA = 0.02320 msec
PPC = 0.00048 msec
vxWorks = 0.00172 msec

The max elapsed time between subsequent calls was around 0.002 msec for all of them so my test was getting time sliced and the reported numbers are a bit high.

The FPGA and PPC clocks have similar accuracy. I was wondering if the PPC clock wouldn't accurately track the FPGA clock, but elapsed times over short periods are within the error of my measurement.

We also experimented measuring system performance with an external clock by generating a digital signal and capturing it with a logic analyzer sampling at 8MHz. We captured good data watching our periodic teleop code, but ran out of daylight before digging into system clock stuff.

Re: Velocity PID Programming: Terms dependent on time
 

I won't claim to be an authority on the LV-RT side of this, but I can help out a bit.

The ms timestamp in LV is very portable and has been in LV since the mac days. It is often used for simplicity when doing slower I/O and timing. Often, NI would have a card on the bus with a better time source that was synched to the I/O, but it would generally need to keep that timer operation controlled by the driver or the board. Bringing out out to user code in the loop would generally not make sense.

RT OSes change that. You'll find there are numerous clocks and ways to access them. The simplest step is to use the RT Tick Count. In the attached image, it is configured for microseconds and I did a quick jitter test at time critical priority. It is zoomed in, but this is how it looked for the 100,000 iterations I took. Again, I'm not the authority, but this looks like it is based on the OS timer and clearly has some overhead. But it is a simple drop in replacement of the ms ticks and works for the OP question.

For the PPC timer, I think you would use RT Get Timestamp.vi. I say think because I now realize that I don't have all of RT installed. I have much of it synched from a source server and not all of it is functional. If you read the help on the node, there is an example at the bottom for measuring an operation using this node. But I can't run it to give data. I'm curious to see if typical FRC install can.

For the FPGA timer, access from RT code is via the serial bus and while available, the better use of this timer is within the FPGA circuit itself. This gives you implicit access to the 25ns clock that is driving your circuit.

Greg McKaskle

Re: Velocity PID Programming: Terms dependent on time
 

Here's far more than anyone probably wanted to know about the clocks available with WPILib C++. I used 10 runs of 1000 clock accesses for each of the 3 clocks. I did this with the default task (thread) priority, high task priority, and high priority locked (which prevents the task from being scheduled off the cpu unless it explicitly blocks).

The clock of choice is definitely the PPC clock: Timer::GetPPCTimestamp.

I experimented more with external timing with a signal analyzer and the external timing matched the PPC clock to +/- 4 microseconds. I only measured durations between 0.5 msec and 1.5 sec. It's kind of fun to see code profiled on a signal analyzer.

Here's the inner loop of the test:

Here's the raw data from a cRIO (older 8 module hardware):