realtime runtime code throughput margin monitoring

[Ether]

Originally Posted by plnyyanks

We sent loop execution times to our custom dashboard, where they would be monitored and used to check that everything was running okay.

Were they monitored by software in the dashboard which counted and flagged individual outliers, or did you mean they were monitored by the driver (whenever he had a chance to glance at the screen)?

[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 McKaskle

[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

[plnyyanks]

Originally Posted by Ether

Were they monitored by software in the dashboard which counted and flagged individual outliers, or did you mean they were monitored by the driver (whenever he had a chance to glance at the screen)?

The latter. Although, while debugging, writing, and tuning code, they were watched very closely and we didn't let the code go into "production" until functionality was there, as well as low loop times/CPU usage.

Thankfully, it was never necessary to actively monitor these, although having software do it is a good idea for next year.

[Ether]

Originally Posted by plnyyanks

while debugging, writing, and tuning code, they were watched very closely

How often was your dashboard screen display updated?

[plnyyanks]

Originally Posted by Ether

How often was your dashboard screen display updated?

Not all that often (I don't remember, but maybe ~200 ms). Which, of course, now that I think about it, doesn't really help catch situations like you're thinking of... Anyway, it's a good idea to implement next year.

[Greg McKaskle]

I don't have an overhead number, but I have seen it raise the CPU. The code is in about six loops in the Driver Station and I saw no need to delete it. I decided not to leave it in the default robot code loops and chose to let teams do it for themselves. I hope to get around to adding some high-water mark and stats to it and perhaps I can find a way to leave it in all loops. Time will tell.

Greg McKaskle