Quote:
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.