SparkMax setCANTimeout() meaning

[anon37142155]

I’ve seen this line of code used by teams, but I don’t fully understand what it does.

setCANTimeout(0);

I’ve put it in our code and found that it seemed to mess with the hard limit switches that go in to the SparkMax, which is confusing as I thought this only affected setting and getting parameters. As soon as I removed this one line, the problem went away, which led me to believe that this was causing the problem. With this line in the code, the limit switches would flicker on and off in the code when independent of their actual state. Is anyone able to explain better what this function does and why it would affect the limit switches?

Here are the docs for reference:

  /**
   * Sets timeout for sending CAN messages with SetParameter* and GetParameter* calls. These calls
   * will block for up to this amoutn of time before returning a timeout erro. A timeout of 0 will
   * make the SetParameter* calls non-blocking, and instead will check the response in a separate
   * thread. With this configuration, any error messages will appear on the drivestration but will
   * not be returned by the GetLastError() call.
   *
   * @param milliseconds The timeout in milliseconds.
   * @return {@link REVLibError#kOk} if successful
   */

[SLAB-Mr.Thomas]

I have no special knowledge of this exact configuration but I’m willing to guess it’s related to the general misuse of non-blocking methods. You are using data before it is available.

If you start an asynchronous process, you are responsible for synchronizing when you want the correct data. You are likely trying to use data before or during its update. This results in garbage (“flickering” data). I’ve made this mistake with reading camera images. I got pretty flashing colors but not what I wanted.

If others use this non-blocking feature, they might be ignoring errors or hoping they notice them on the DS. I prefer to use a timeout and handle any errors more positively - retry the failed method or put out an error that is obvious. Most parameters’ settings are made before the robot loop and you have as much time to get them right as you want.