OCCRA
Go to Post Mind you... if your ball kicker has as much energy stored up as a trackball launcher, you ought to be able to kick balls up into the stands. - dtengineering [more]
Home
Go Back   Chief Delphi > Technical > Electrical > CAN
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 02-22-2015, 12:27 PM
wireties's Avatar
wireties wireties is online now
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,226
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
CAN-based delays

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
__________________
Fast, cheap or working - pick any two!
Reply With Quote
  #2   Spotlight this post!  
Unread 02-22-2015, 02:01 PM
GeeTwo's Avatar
GeeTwo GeeTwo is offline
Technical Director
AKA: Gus Michel II
FRC #3946 (Tiger Robotics)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 4,916
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: CAN-based delays

I haven't looked up the specific CAN algorithms, but this is a common problem on many baseband (shared) busses. A likely cause of the problem is your use of multiple threads all trying to ping CAN at the same time. If you wrote a dedicated CAN thread, then had all the subsystems that need it submit (possibly prioritized) requests to that one thread for processing, you may reduce collisions.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
Reply With Quote
  #3   Spotlight this post!  
Unread 02-22-2015, 02:30 PM
wt200999's Avatar
wt200999 wt200999 is online now
Texas Instruments
AKA: Will Toth
FRC #3005 (Robochargers)
Team Role: Mentor
 
Join Date: Mar 2006
Rookie Year: 2004
Location: Dallas, Texas
Posts: 342
wt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud of
Send a message via MSN to wt200999
Re: CAN-based delays

Quote:
Originally Posted by GeeTwo View Post
If you wrote a dedicated CAN thread
If you look at section 20 of the Talon SRX manual it looks like the implementation is already only using the CAN bus in a single thread, with different data requests at different times. So (based on the document) it looks like whenever you call the CAN functions for the SRX, all you really are doing is accessing a global that already contains the data.

We are running 9 talon SRX controllers, and three of them are reading their sensor data in seperate threads. We have not seen any issues, though we do see strange, and quite large spikes, in the CPU usage data at a very periodic rate (~7 seconds?) that line up with small increases in CAN utilization. Not sure if that is related but I could imagine this would cause issues if the spikes hit 100% for any extended time.
__________________
Programming in LabVIEW? Try VI Snippets!

FIRST LEGO League 2004 - 2005
FRC Team 870 Student 2006 - 2009
FRC Team 3005 Mentor 2013 -
Reply With Quote
  #4   Spotlight this post!  
Unread 02-22-2015, 02:52 PM
GeeTwo's Avatar
GeeTwo GeeTwo is offline
Technical Director
AKA: Gus Michel II
FRC #3946 (Tiger Robotics)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 4,916
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: CAN-based delays

Based on the threads he's started, wireties' team is using C++, not LabView. It appears they may be using SampleRobot, not IterativeRobot. That may make a difference.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.

Last edited by GeeTwo : 02-22-2015 at 03:22 PM. Reason: expanded
Reply With Quote
  #5   Spotlight this post!  
Unread 02-22-2015, 03:05 PM
wt200999's Avatar
wt200999 wt200999 is online now
Texas Instruments
AKA: Will Toth
FRC #3005 (Robochargers)
Team Role: Mentor
 
Join Date: Mar 2006
Rookie Year: 2004
Location: Dallas, Texas
Posts: 342
wt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud ofwt200999 has much to be proud of
Send a message via MSN to wt200999
Re: CAN-based delays

Quote:
Originally Posted by GeeTwo View Post
Based on the threads he's started, wireties is using C++, not LabView. That probably makes a difference.
Shouldn't make too big of a difference, they should both be calling the same library.
__________________
Programming in LabVIEW? Try VI Snippets!

FIRST LEGO League 2004 - 2005
FRC Team 870 Student 2006 - 2009
FRC Team 3005 Mentor 2013 -
Reply With Quote
  #6   Spotlight this post!  
Unread 02-22-2015, 04:01 PM
wireties's Avatar
wireties wireties is online now
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,226
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 GeeTwo View Post
I haven't looked up the specific CAN algorithms, but this is a common problem on many baseband (shared) busses. A likely cause of the problem is your use of multiple threads all trying to ping CAN at the same time. If you wrote a dedicated CAN thread, then had all the subsystems that need it submit (possibly prioritized) requests to that one thread for processing, you may reduce collisions.
The requests are inter-leaved by the Linux drivers. A dedicated CANbus thread won't help - I think.
__________________
Fast, cheap or working - pick any two!
Reply With Quote
  #7   Spotlight this post!  
Unread 02-22-2015, 04:02 PM
wireties's Avatar
wireties wireties is online now
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,226
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 GeeTwo View Post
Based on the threads he's started, wireties' team is using C++, not LabView. It appears they may be using SampleRobot, not IterativeRobot. That may make a difference.
Ours is totally custom and in C++. We use the WPI libraries but none of the example infrastructures.
__________________
Fast, cheap or working - pick any two!
Reply With Quote
  #8   Spotlight this post!  
Unread 02-22-2015, 07:44 PM
ozrien's Avatar
ozrien ozrien is offline
Omar Zrien
AKA: Omar
no team
Team Role: Mentor
 
Join Date: Sep 2006
Rookie Year: 2003
Location: Sterling Heights, MI
Posts: 611
ozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond repute
Re: CAN-based delays

Quote:
Originally Posted by wireties View Post
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.
__________________
Omar Zrien - CTR Electronics - Cross The Road Electronics - Chief Software/Owner
CTRE New products | CTRE/FRC Source Examples | FRC Installer (for Talon SRX and more)
Get Latest Updates on Facebook | Twitter
Reply With Quote
  #9   Spotlight this post!  
Unread 02-23-2015, 03:00 PM
wireties's Avatar
wireties wireties is online now
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,226
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
  #10   Spotlight this post!  
Unread 02-23-2015, 03:11 PM
ozrien's Avatar
ozrien ozrien is offline
Omar Zrien
AKA: Omar
no team
Team Role: Mentor
 
Join Date: Sep 2006
Rookie Year: 2003
Location: Sterling Heights, MI
Posts: 611
ozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond reputeozrien has a reputation beyond repute
Re: CAN-based delays

Quote:
Just the limits
Ok then. Yeah, the limit switches [GetForwardLimitOK() and GetReverseLimitOK() ] are definitely unsolicited.
__________________
Omar Zrien - CTR Electronics - Cross The Road Electronics - Chief Software/Owner
CTRE New products | CTRE/FRC Source Examples | FRC Installer (for Talon SRX and more)
Get Latest Updates on Facebook | Twitter
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:46 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi