[NotInControl]

Originally Posted by marshall

Sorry Frank, but I'm really not sure where you are getting this from... In fact, you said it yourself, CAN is a two-wire BUS. Daisy chaining is just an easy method to accomplish it. There is nothing stopping you from putting terminating resistors at each one of your end points and then running everything back to a central hub rather than daisy chaining.

To my knowledge (and I haven't looked at all of the ISO standards and heaven only knows I could be wrong) there is nothing prohibiting the use of a star topology with a CAN network rather than a daisy chain topology.

This is not accurate. CAN can not be wired like any other network.

The protocol is named CAN Bus because it should only be used in a bus as it was intented, a bus is a type of topology. CAN can not be used in a STAR or Ring topology or Hub type topology natively without having additional CAN modules, or increasing the complexity of the layout, and even so, in the end, the Ring or Star implementation will only be a cosmetic one, and will not be more efficient then the original Bus topology. You will also loose a lot of link speed.

The current CAN products we have available in the FRC control system, including 2015, are internally hardwired, such that if a device fails, only the device fails, it does not bring down the entire physical bus. The device CANs act as pass-through so you can communicate beyond a failed device. How the software reacts to an ID that does not exist because it failed is a different story. WPI is currently working on implementing a NON-blocking CAN implementation for 2015, which should help teams have more graceful software failures.

Saying that if one CAN module goes down the entire bus goes down, or saying anything beyond the failed device is unreachable after that module goes down is not correct and shouldn't be perpetuated. However, it is a true statement that if you were to CUT the wires on the CAN BUS, you would loose all communication beyond the cut. This is where PWM differs marginally. If you wired every motor to an individual PWM channel, then you would have to cut every PWM cable to have the same effect, making PWM more robust. However, the reason I said marginally is because most teams I have encountered in my FIRST decade use PWM Y cable or even tri cables to drive up to 3 motors off one PWM channel. In this scenario if you cut the one cable, you loose all downstream communication making it very similar to the CAN problem, although you do not need to worry about what the software does if you loose the PWM connection. (Maybe this will be true for CAN in 2015 as well, I haven't beta tested the new CAN implementation yet).

I am not trying to say one is better than the other, I am just trying to clarify the rumors around these technologies so that teams can have all the proper information when choosing which one best suits their needs, based on robot design criteria and experience.

Regards,
Kevin