[Kevin Sevcik]

I'd just like to point out that as far as I can tell from what's been said here and on the beta forums, there's no information one way or another on whether this communications lag actually affects the function of the disable switch. That question's been asked on the beta forum, but hasn't been answered yet.

Second, I have to disagree that the joysticks holding the last sample is a safety deficiency. In most situations, this implementation is equivalent to the IFI default value system. If the USB device is controlling something like a PID positioned joint, the holding value implementation is arguably safer than suddenly jumping to any default value. As pointed out, the default value implementation is safer for most drive systems. So I think the new control system's functionality is just as safe or unsafe as IFI's. It's just different. If we want to argue them into changing it, I think it'd make a lot more sense to ask for the functionality that we actually need. As opposed to the functionality that we've grown used to dealing with. What we need is for the API to throw an error and/or return an invalid value when we try to address a joystick or axis that doesn't exist. Returning NaN would be perfect for this, as any operation on NaN returns NaN or false. I'm half certain that the PWM functions will already shutdown an output if they're commanded to output NaN. There's probably a few situations where this wouldn't completely safe things or would adversely affect things long after the joystick is replaced... But overall I think this should be preferred over switch from one less than satisfactory solution to another.