[Thad House]

Originally Posted by Jaci

Imma interject for a minute.

Joystick calls are not slow. They access variables stored in memory that are received from the driver station at regular intervals (around every 20ms for a Driver Station Control Packet). When one of these packets is received, the joystick values are stored in memory, and those are accessed through the Joystick class. There is nothing slow about this at all, in fact, it's probably the fastest way to do something like this. I don't usually applaud WPILib for doing something right, but this is one of those times.

This is true for a majority of WPILib's get functions, as it enables control loops to run quickly without 'blocking' for an external resource. Reading up on the different types of frames used by CAN, The Driver Station and FMS will give you a good idea of why all of these methods are non-blocking.

If you're wondering about your 'taking too long to loop' issue, I'm afraid there's not much help we can provide unless you provide some code. If the loops are taking too long, there are two possible things.
a) The issue is occurring within the loop. Somewhere in the loop, your code is running slowly. This may be an intensive math problem or a function call. If you're using reflection anywhere, that will be your culprit.
b) The issue is occurring outside the loop and bogging down the system. This can be caused by delayed Driver Station / FMS Control Packets (check your wifi router), or by having too many active threads. A good status indicator is your RSL (Robot Signal Light). If it's flashing irregularly, it's an issue outside the loop and your RoboRIO is being bogged down by an intensive process.

If you're running any kind of vision on your RoboRIO, this can also be an issue with the system being bogged down.

If you actually look at the code, Joystick get button and get axes calls are cached, however calling GetJoystickName or GetJoystickIsXbox are not cached, and are slow. The Robot State methods are not cached either, and directly call into the FPGA and are slow. And finally, in CANTalon, whenever some parameters are requested, there is an explicit Thread.sleep for about 1ms called, which also causes a context switch, and could be delaying even longer. So even though these methods should be non blocking, in the current implementation they are not exactly, however they are known block times, rather then indefinite waits like actual blocking calls would be.