Quote:
Originally Posted by Mike Copioli
The short answer is never. PWM and CAN are two completely different interfaces. PWM is unidirectional(one way) CAN is bidirectional(twoway). PWM is time based measurement, CAN is serialized data over a differential BUS.
The Talon was designed to meet the needs of the majority of users. Since only about 10% of users prefer CAN, it did not make sense for our first release to include the additional features and cost associated with CAN.
Additionally, CAN would increase the footprint of the TALON to accommodate the additional connectors used for the various forms of feed back. In short the decision to withhold CAN functionality from the Talon was mostly business and partly design.
The situation with CAN is a bit paradoxical, we would like to release a CAN enabled version of the TALON, we feel that if we were to correct some of the issues with CAN in FIRST teams would see the benefit and slowly migrate away from PWM and into CAN thus increasing the demand. However, There needs to be a demand in order for us to justify the additional cost and increase in footprint.
This becomes even more challenging with the new reduced pricing. I truly believe that a properly implemented CAN interface is a better solution for FIRST than PWM.
The questions I have for the FIRST community are: What would you be willing to pay for a CAN enabled motor controller that had a footprint slightly larger than the Talon? Second would the increase in footprint make the Talon less desirable for PWM users?
After all it is your support that would make all of this possible. We appreciate your patronage and feedback.
|
We'd probably pay up to $90 for CAN Talons, although we'd buy less of them (4-6), and supplant that with an order for PWM Talons unless CAN Talons were marked down so much that their price was on par with their PWM counterparts.
Some features that I know I'd like to see on the CAN Talon:
- Keep the analog & encoder inputs.
- Redo the limit switch inputs to make them more intuitive and easier to understand for people that aren't on the electrical team.
- Allow controllers to communicate with each other more in-depth; namely, allow sensor input (specifically encoders) to be duplicated (in the CAN) between controllers. This has been a problem whenever teams have Jags on motors that feed into a gearbox that only has one encoder, since the encoder has to be read through the DSC, and then passed to the cRIO and then back to the Jags.
- Allow controllers to double as sensor interfaces - the closed-loop feature of the Jags was nice, but it would've been nicer if we could've read the sensors feeding into the Jags in our code.