View Single Post
  #2   Spotlight this post!  
Unread 23-02-2015, 15:00
wireties's Avatar
wireties wireties is offline
Principal Engineer
AKA: Keith Buchanan
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Rockwall, TX
Posts: 1,169
wireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond repute
Send a message via AIM to wireties
Re: CAN-based delays

Quote:
Originally Posted by ozrien View Post
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.

Quote:
Originally Posted by ozrien View Post
Are you getting DS messages in the log? section 16.8?

What signals are you reading?
Just the limits

Quote:
Originally Posted by ozrien View Post
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
__________________
Fast, cheap or working - pick any two!
Reply With Quote