[Ether]

This thread is a continuation of a discussion which began here.

I'll post a couple of excerpts (these excerpts are not replies to each other, just pertinent info):

The periodic rate can be controlled either by a fixed value or follow the driver station. If it is set to follow the driver station, which is the default, then the period time will vary because of being a windows app. If you set the period to a specific value the cRIO will maintain a very precise periodic rate. (Hugh Meyer)

At competition the DS packets are still sent by the DS.
FMS only orders the DS to change modes, but the DS has to send that command to the robot.
Any slow down in the DS PC will delay packets.

One of the checks for slow or lost packets is the CPU utilization on the DS.
(If in the Classmate Driver acct. use: CTRL-Shift-Esc -> Performance)
A saturated netbook can be a cause of lost and delayed packets. I see that pretty often. (Mark McLeod)

We use C++. There is a configuration variable that sets the periodic rate. If it is zero then the rate will follow the driver station. If it is not zero then the value entered will be the periodic rate. I tell our programmers to ALWAYS set the rate. We have not settled on a value for this year yet. (Hugh Meyer)

What does your team do? In LabVIEW, would the equivalent be to leave TeleOp completely blank and put all your code in Periodic Tasks (or would that break something)? Has anyone done this in Java?