CAN-based delays

[ozrien]

Originally Posted by wireties

We are loving the new Talon SRX controllers! There are so many kewl features. But the other day our programmer-students were reporting delays processing commands from the driver station. Our application in the robot is all message-based with multiple threads responding to messages to perform subsystem-specific tasks. The students had inserted some code to query 6 different Talons for information about connected sensors inline with code that answers flurries of messages (100s per sec) and were seeing some delay. The delay was from the CANbus queries. I helped them fix it by only querying the Talons when they needed the data, not all of the time, and by handling the messages more efficiently.

Has anybody else experienced this? Any unexpected delays issuing commands to Talons (to which the Talons must answer)? If Omar is listening, how fast do the Talons respond to messages requesting data about sensor outputs etc?

TIA

If you are getting signals that are unsolicited, then there is zero increased utilization in CAN bus. All those getters just grab the last received decoded value, so they are fast. There is no "command" and "response" to wait for. You could disconnect CANBus completely and it shouldn't affect timing. Almost all the signals work this way and are listed in section 20 (along with the default frame rates).

If you are reading signals that are solicited (motor control profile params or Iaccum) then the CAN bus utilization will increase. So check the can utilization to see if it's high (section 15). I can't imagine why you would need to do that though.

Are you getting DS messages in the log? section 16.8?

What signals are you reading?

What is the observed behavior in the robot that is not meeting your expectations? Is it something you can reproduce with a smaller test app? Sounds like your app is more unique/complex then a typical robot application, which without an understanding of what's going on, we're likely not going to be able to pinpoint what you are seeing in a forum. Seems like the first step should be figuring out what is actually taking more time then what you'd expect. If you want you can send your source to support@crosstheroadelectronics.com and I can take a look.

[wireties]

Originally Posted by ozrien

If you are getting signals that are unsolicited, then there is zero increased utilization in CAN bus. All those getters just grab the last received decoded value, so they are fast.

Then it must not be the CAN queries.

Originally Posted by ozrien

Are you getting DS messages in the log? section 16.8?

What signals are you reading?

Just the limits

Originally Posted by ozrien

What is the observed behavior in the robot that is not meeting your expectations? Is it something you can reproduce with a smaller test app?

The loop time in the task controlling our stacker was long enough to produce perceptible delays getting back to the top of the loop and servicing the next message (not from the DS but from our demultiplexer task).

Not easy to reproduce - you've ruled out the CAN queries. The students were issuing many hundreds of SmartDashboard updates per sec, maybe that was it. I moved the CAN queries and accompanying SmartDashboard updates around so they are only called as needed by the state machine in this area of the code. All is well now but I wondered where the delay came from.

Thanks

[ozrien]

Just the limits

Ok then. Yeah, the limit switches [GetForwardLimitOK() and GetReverseLimitOK() ] are definitely unsolicited.