Chief Delphi
Page 4 of 4 < 123 4
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   CAN (http://www.chiefdelphi.com/forums/forumdisplay.php?f=185)
-   -   CAN reliability (http://www.chiefdelphi.com/forums/showthread.php?t=86259)

Ether 15-09-2010 21:40
Re: CAN reliability
 
Quote:
Originally Posted by kamocat (Post 974265)
sometimes only some of my Jaguars will work
Is it always the same Jags which sometimes don't work ?

Try swapping them with Jags that always work and see what happens.

kamocat 16-09-2010 21:23
Re: CAN reliability
 
I'll record which Jags it is next time it happens.

jhersh 10-12-2010 19:43
Re: CAN reliability
 
I'd like to address the implications of the lessons learned for the upcoming season...

Quote:
Originally Posted by kamocat (Post 974195)
  • CAN messages take a long time over serial due to the current implementation. (messages wait for errors on the CAN bus before completing). If there is an error, the function takes longer still. There is a driver update expected to help alleviate the issue. I have no data on the 2CAN module.

NI and TI are each working to improve performance of the parts of the system they are responsible for.

As for the timeout, the default timeout for a single device transaction has been reduced from 100ms to a much more reasonable 10ms.

The 2CAN plugin is another place where performance needs to be considered (but has not yet been addressed... support from CTRE is needed).

Quote:
Originally Posted by kamocat (Post 974195)
  • There are multiple issues with the Jaguar firmware:
    • Speed is dealt with in RPM (the documentation states revolutions per second). Although only the encoder can be used to calculate speed, the "speed reference" configuration is required. The "Speed" status is reported as zero until the Jaguar has been enabled in speed mode. The speed status reports positive regardless of the direction the encoder is turning.
This was an issue with the library implementation and has been fixed for 2011.

Quote:
Originally Posted by kamocat (Post 974195)
    • The "Position" status is reported as zero until the Jaguar has been enabled in position mode.
Same issue, also fixed for 2011.

Quote:
Originally Posted by kamocat (Post 974195)
    • There is no status message to tell if the Jaguar is enabled or disabled.
This is sort of implied... if you can talk to it and you told it to enable, it's enabled. If it's not enabled, but you told it to be, then you probably can't talk to it to ask it if it's enabled. ;)

Quote:
Originally Posted by kamocat (Post 974195)
    • The "control mode" status is not implemented.
It is for 2011.

Quote:
Originally Posted by kamocat (Post 974195)
    • "Device Query" takes half a second to execute, but returns nothing.
I'm not sure what the utility of this message is... I've never tried it. Are you implementing this yourself?

Quote:
Originally Posted by kamocat (Post 974195)
  • The current sensor is only accurate within 1 amp. This makes current control unsuitable for all FRC motors smaller than the CIM.
This is a known feature request at TI. No change in this respect for 2011.

Quote:
Originally Posted by kamocat (Post 974195)
  • There are occasional reliability issues on startup. Sometimes only some of the motor controllers will function. When my auto-configuration utility is running, the quickest way to fix this is to cycle power to the nonfunctioning devices.
I haven't experienced this behavior. Any information that would help reproduce the issue would allow me to investigate.

We are working hard to make using CAN with Jaguar a competitive advantage and not a liability. We need the help of people like you to identify issues and bring them to our attention.

Thanks for all of your investigation and feedback!

-Joe

kamocat 10-12-2010 23:05
Re: CAN reliability
 
Thanks for posting this reply! I'm under oath of NDA until the info is made publicly available.

The "Device Query" message is something that would be useful if there was more than one type of device that worked on CAN.
Quote:
Originally Posted by SW-RDK-BDC-UG-5228.pdf
Device Query
This command indicates that the motor controller should return some basic information about itself. This command uniquely addresses a device and only the addressed device will respond to this message. In response to this message, the motor controller will send back eight bytes of data. The first byte indicating the motor controller’s function and the second indicates the manufacturer. The remaining bytes are reserved for future use.
I'm assuming there's a typo in here, and they meant "the device's function".

I'm not sure if this command has practical usage. If you send a CAN device a message, using the wrong device type and manufacturer in the device ID, will it respond with the wrong device type and manufacturer?

Mike Copioli 12-12-2010 02:19
Re: CAN reliability
 
Quote:
Originally Posted by jhersh (Post 984800)

The 2CAN plugin is another place where performance needs to be considered (but has not yet been addressed... support from CTRE is needed).

A new plugin and firmware version for the 2CAN will be released shortly. Joe you should be hearing from Omar soon regarding this if not already. I believe he has some CAN traffic snap shots that you may find helpful.

jhersh 12-12-2010 02:35
Re: CAN reliability
 
Quote:
Originally Posted by Mike Copioli (Post 985014)
A new plugin and firmware version for the 2CAN will be released shortly. Joe you should be hearing from Omar soon regarding this if not already. I believe he has some CAN traffic snap shots that you may find helpful.
Sounds great... Thanks Mike!

ozrien 12-12-2010 15:15
Re: CAN reliability
 
New Firmware and plugin is available at http://www.crosstheroadelectronics.com/2CAN.htm

Marshall (or any one), have you observed any latencies issue with a 2CAN? I know you've done the extensive testing with the BlackJaguar.

One reproducible problem I can report is if I create a Robot app that drives throttle for several jaguars (say 1-10). Then only put one jaguar (id 1) on the CAN bus. When I do this the Jaguar does not drive at all (massive delays and timeout issues). Looking at the CAN bus it looks like the cRIO is attempting to reestablish tokenization with the other jags. When this happens the throttle CAN frames are not going out for Jaguar 1, which causes Jaguar 1 to timeout as well.

This tokenization that occurs to keep the Jaguars enabled seems to block the transmit requests from the user's code (CANJagar::sendmessage) if the Jag on the other side doesn't send it's ack with token response, presumably because cRIO internal logic is waiting on the response. Now this could happen because of an intermittent cable issue somewhere, or because a jaguar is left unplugged (deliberately or accidently) or because of software.

Mike Copioli 12-12-2010 18:07
Re: CAN reliability
 
Also note that there are now two different versions of the 2CAN firmware. Please be sure to download the correct version based on your application. A seperate link to a zip containing the plugin and the 2CAN firmware has been added under the Downloads for FIRST section at the bottom of the page.

kamocat 13-12-2010 00:35
Re: CAN reliability
 
Quote:
Originally Posted by ozrien
Marshal (or any one), have you observed any latencies issue with a 2CAN? I know you've done the extensive testing with the BlackJaguar.
I have not tested with 2CAN.
I know I was originally complaining about the low throughput of serial port. (The 2009 Beta threads are gone now, or I would link to it.) However, the 2CAN wasn't released until January, by which time I was busy with the new season. By the time I was purchasing more Jaguars to make a test robot in late spring, the Black Jaguars were the only ones available.
And so, having some of the capabilities of CAN with almost no increase in cost, I couldn't rationalize buying a 2CAN.
That's not to say I wouldn't like one.


All times are GMT -5. The time now is 03:59.
Page 4 of 4 < 123 4
Show 100 post(s) from this thread on one page

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