Custom Dashboard Program Ideas?

[tutkows1]

I suggest having a larger video screen, and having a space were messages from the programmer can show up. For example, you are now cocked at position three. Having a pressure gauge is also a good idea.

On a side note: were did you find a gauge that can send the air pressure as an analog signal to the control system?

Edit: More about what we did.

Last year my team didn't use the classmate for the dashboard, we sent it to another computer so we could have a larger screen and it seemed to run the feed better.

[ViperChris3]

Originally Posted by tutkows1

I suggest having a larger video screen, and having a space were messages from the programmer can show up. For example, you are now cocked at position three. Having a pressure gauge is also a good idea.

On a side note: were did you find a gauge that can send the air pressure as an analog signal to the control system?

Edit: More about what we did.

Last year my team didn't use the classmate for the dashboard, we sent it to another computer so we could have a larger screen and it seemed to run the feed better.

@tutkows1

Our Robot has an analog pressure sensor on it hooked into one of the analog imputs on cRios. We played around with the data communication and have a guage on our large video screen with the air pressure. I think that the while loop on the dashboard has a slow iteration rate however, because it is quite slow responding, about 1-1.5 seconds per responce, hardly real-time.. But we might consider putting dashboard onto another computer. Did the program run faster on a different laptop than it did on classmate?

[apalrd]

The default dashboard is really slow. Apparently this is because of the graphs.
The iteration time is not set directly. The main loop iterates every time it gets a data packet from the robot. (Those data packets should be sent by the robot every time its main loop runs, and those runs are triggered by the packets coming from the driver station, etc.)

I noticed during testing that it takes around 10 seconds for the inputs to update while disabled (I have no idea why this is), and around 1.5 seconds while enabled, using the default dashboard. My custom dashboard is about 1 second, all the time. This is because of the default handling of the crio end, only updating the low priority dashboard data every 25 iterations (the high priority data, which in the default code is the tracking data, is updated every iteration).

[Greg McKaskle]

The default dashboard setup attempts to read most of the I/O channels, and send them to the ds and dashboard about twice a second. Reading that many channels through the Apis could place quite a load on the CRIO if done at 50 hz. If wou trim the channels being read to just the ones you are using or interested in, wou could easily up the rate. It is your CPU, so use as much as you like.

Greg McKaskle