New Talon SRX and CAN with the 2015 Control System

[tgross35]

Hello everyone,

With the Talon SRX coming around and the 2015 control system being a lot more CAN-friendly, my team is thinking of making the switch to a CAN control system. This will only be our third year as a team, and we have zero experience with the jaguars, though from looking around, it seems that the biggest issue with them were loose connectors (which should not be a problem with the SRX) and low voltage-induced brownouts. That being said, here are some questions I have:

• Does anyone know if the Talon SRX will be as prone to brownouts as the jags seem to be?
• Is there ever a noticible lagtime from one end of the CAN bus to the other? With possibly 10 encoder-enabled Talons, a pneumatics module, and a PDB all operating on CAN this year, is the interface able to handle such a load?
• Are there any other issues that might be problematic this year?

As you can tell, I am a complete CAN novice, and I apologize for that. But thanks for any help!

[Jon Stratis]

To answer your questions in order...

- I don't think anyone except CTRE has seen the new Talon's yet. I *think* Beta teams are going to get them at some point (we have the new Victors already), but until teams can put them through their paces you won't have much information.
- Define "noticeable". The control system does have timing expectations for the CAN bus, and I bet if you search for "CAN Timeout Exception" you'll find some more information on CD for it. As CAN bus is implemented through daisy-chaining one module to the next, you need to be aware of total bus length and actively work to keep that to a minimum. Keep all the components close to each other any you won't have a problem... spread them out all over the robot so your bus is a meter+ long and you could run into issues.
- With it being a whole new control system, I'm willing to bet that yes, there will be other issues this year. Given the work testing it (by the control system team and the alpha/beta testers), i don't expect any issues that do crop up to be show-stopping.

[AustinSchuh]

Originally Posted by Jon Stratis

As CAN bus is implemented through daisy-chaining one module to the next, you need to be aware of total bus length and actively work to keep that to a minimum. Keep all the components close to each other any you won't have a problem... spread them out all over the robot so your bus is a meter+ long and you could run into issues.

The CAN specification for 1 mbps CAN networks says a maximum of 40 meters. (ISO 11898-2) That would be some pretty bad wiring on a FRC robot... Shorter is better, for sure. The specs generally error on the strict side (which is good for a spec).

[nixiebunny]

A CAN Bus does not have increased latency when more devices are added. They are all wired in parallel. The addressing is dealt with when the address is placed on the bus.

The only worry is that a dead device or bad cable can kill the entire bus, so troubleshooting a dead bus is a matter of splitting the bus into sections to see when it starts working.

[Alan Anderson]

Originally Posted by nixiebunny

The only worry is that a dead device or bad cable can kill the entire bus,...

A dead device should act just like a disconnected device. It won't have any affect on the rest of the CAN bus. While a live but badly misbehaving device does have the electrical ability to jam the bus with spurious signals, such a failure is extremely unlikely.

Changing from the Jaguar's RJ12 connectors to the Weidmuller terminals is going to reduce cable and wiring issues significantly.

[jhersh]

Originally Posted by Alan Anderson

A dead device should act just like a disconnected device. It won't have any affect on the rest of the CAN bus. While a live but badly misbehaving device does have the electrical ability to jam the bus with spurious signals, such a failure is extremely unlikely.

It seems to me that a short between the two wires will be the most likely failure mode in the new system. We have diagnostics that report roboRIO's CAN TX overrun which should catch long to intermittent shorts.

Originally Posted by Alan Anderson

Changing from the Jaguar's RJ12 connectors to the Weidmuller terminals is going to reduce cable and wiring issues significantly.

Of course the Talon SRX has no Weidmuller connector, so Talon to Talon will just be twisted or soldered or some custom connector. would be good if there were a Weidmuller block created that allowed a bunch of them to be all connected.

[Alan Anderson]

Originally Posted by jhersh

Of course the Talon SRX has no Weidmuller connector, so Talon to Talon will just be twisted or soldered or some custom connector.

I should probably just have said "Changing from the Jaguar's RJ12 connectors will cut down significantly on wiring-related problems."

would be good if there were a Weidmuller block created that allowed a bunch of them to be all connected.

5-port Wago lever nuts?

The Talon SRX has two sets of CAN pigtails. I don't really see that working well in a star topology, alas.

[jhersh]

Originally Posted by Alan Anderson

5-port Wago lever nuts?

The Talon SRX has two sets of CAN pigtails. I don't really see that working well in a star topology, alas.

That actually probably a decent solution... in most cases the Talons will be close to each other where only the pigtail length is needed. I think a star would work great with such short lengths... you can just ignore one pigtail. If you used those little blocks you could even use one of the extra pigtails to jump to the next cluster of 4.

[FrankJ]

The CAN spec calls a line structure. You might get away with a star topology, but it is not recommended by specification.

[jhersh]

Originally Posted by FrankJ

The CAN spec calls a line structure. You might get away with a star topology, but it is not recommended by specification.

It also allows for taps up to a foot. I believe this should be acceptable for this application.

http://digital.ni.com/public.nsf/all...25795A000FC025

[FrankJ]

Originally Posted by jhersh

It also allows for taps up to a foot. I believe this should be acceptable for this application.

http://digital.ni.com/public.nsf/all...25795A000FC025

Thanks for the references. The physical layer spec (CiA 102) only says in effect that they should be as short as possible. It is nice to have actual numbers.