Set user data - limitations?

[pgaston]

Okay, we successfully have 'Set user data' working - sweet.   We send interesting data from our robot back to a customized dashboard.

How often can/should one send data from the cRio to the driver station?    1X/second?   5X?   10X?   100X?

Somewhat related, will 'Set user data' block that thread if it isn't ready to send the data at that point?

*** ***

For those looking to do this - use the example given about doing this with a Gyro.    Also, note that the dashboard croaks if it trys to decode a data packet it doesn't like - say with a different typedef than the cRio sent.    Get your cRio side running first - you can somewhat see the binary data at least showing up in the user message area, indicating something is coming across - then fix the dashboard side to correctly retrieve that data.   Or at least this helped me when the dashboard side kept croaking.

Thanks to all!

[StephenB]

Im guessing you are referring to the build dashboard data subVI. That subVI actually does not handle sending the data to the dashboard, but rather handles putting it all together for a separate communications subVI to send (driver station start communication).

So calling the build dashboard data subVI at different rates does not affect how fast it is transmitted over the ethernet connection, only how often to update, or rebuild, the information to be sent. If you open up the build dashboard data subVI, you will find that it reads the set user data every 50th call, and it rebuilds the information to be sent over ethernet every 25 calls. So if you are calling build dashboard data at 100 times a second, the set user data will be done 2 times a second, and the information to be sent over ethernet is rebuilt 4 times a second.

I would reccomend leaving everything at its default timings if that works for your specific application because we have done the research to find that these specific timings have low impact on other things going on with the robot code. If you find that you need to be updating the information sent to the dashboard faster, you can:

• Call the build dashboard data subVI more often in your main loop
• Call set user data once every 25 calls instead of once every 50 (so that it is updated at the same rate the entire dashboard data set is rebuilt)
• Increase the rate that the entire data set is rebuilt to be greater than once every 25 calls (with a corresponding increase in calling set user data)

Obviously, doing so will increase the load on the cRIO. This can always be enabled and then disabled later when your debugging is done (as you won't have a dashboard when your robot is on the field)

[pgaston]

Thanks for the fine reply!   No need to update the default data going back  to the dashboard more quickly - that works fine.

Actually, we're using the "Set User Data" vi that allows us to send up to 984 bytes of data up to the driver station, and on to the dashboard application running on a laptop.   That works fine.   And, by the way I was under the impression that this is allowed during gameplay.   No video, but a custom dashboard yes.   As an aside, this is our 'fire control system' - with our 'missile lock' feature.   i.e., taking the autonomous camera tracking/firing functionality and letting it be used in teleop.

We're actually trying to, surprise, get the vision code running faster.   Currently it's at around 4-5 fps.   The camera is configured to run at 320x240 resolution, no decimation - though we've played with those parameters and it doesn't seem to help considerably.   No image processing other than a slight variation on the given example.

Currently after vision processing we send the user data back up to the dashboard.   Every loop.   One idea is that this could be causing blockage on that while loop.   Somehow.    Current test is to move the 'set user data' functionality to an entirely separate while loop running at, say 500MS.

[Burt_S]

Unless you are doing some heavy image processing, you should be able to get a higher frame rate than 4-5 fps.  It is definitely possible that the user data is slowing everything down.  Placing this VI into a new loop at a slower rate is a good idea.  If this does not speed things up, try just running the image processing loop by itself. If this goes a lot faster, than your processor must be heavily loaded by other tasks.  If that is the case, you could try to give the image loop a higher priority or slow down some of the other loops in your program.