realtime runtime code throughput margin monitoring

[Ether]

Originally Posted by Greg McKaskle

The LV template project contains a folder called Support Code. In it is a VI called Elapsed TImes.vi. Placing it into any loop or recurring code will result in a table of elapsed times being updated to calculate and show the period of the calls. The easiest way to view the times is to open the Elapsed Times panel. This is typically used for debugging and later deleted, but could be transmitted back to dashboard if a team wanted. I have no idea how many times it was used.

Greg, do you know roughly how much runtime overhead is incurred by this? e.g. Could it reasonably be put into all the parallel tasks in an FRC robot project?

[apalrd]

Originally Posted by Ether

Greg, do you know roughly how much runtime overhead is incurred by this? e.g. Could it reasonably be put into all the parallel tasks in an FRC robot project?

We ran a slightly modified Elapsed Times in our robot code, and it wasn't the biggest cause of CPU usage (sorta...)

The biggest cause of CPU usage while not permanently deployed seems to be updating VI front panels. If you have enough inclusions of Elapsed Times, it seems to update the front panel array every time it changes (Every tick of every loop). If you create a slower loop somewhere (we ran ours at 75ms I think) to read the array of times from Elapsed Times, it is significantly less CPU hungry than simply opening Elapsed Times. We used the same loop to read the CPU load cluster and print it to the same debug screen, and that information (CPU usage by thread priority) was also extremely useful.

It was a very useful VI. We had it in about 10 or so tasks.

[Greg McKaskle]

If you create a slower loop ...

Good to know. The panel was the simplest way to see the data, but it will transmit all modifications to to the host each call, and the array is constantly changing. Maybe something like that will allow it to be in the framework by default.

Thanks.
Greg McKaskle