View Single Post
  #13   Spotlight this post!  
Unread 12-12-2012, 20:16
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: New Talon Speed Controller

All my opinions on how CAN should be implemented:

-Speed controller should have a pair of connectors which are easier to wire properly than. I'm not a fan of RJ11's. Some positive locking connector would be nice, but the 3-pin header style would work as well. You could choose to connect through the two connectors, or make your own splice inline (this would help with reliability if a single connection comes out, assuming your splices are well done). The bus really doesn't care about 6" splits.

-Speed controllers should require enable signal to operate, it should be a different and reserved message ID. This should only affect the status of the output and reset the integrals, nothing else (you should still be able to send commands, read sensors, command gains, etc.)

-Software on controller side should be architected to pass CAN messages between the application and the CAN bus, restricting the reserved enable message and sending it itself, but otherwise doing nothing. Also, it seems reasonable for each speed controller to get it's own group of CAN ID's.

-The user software on the controller side should never block-wait for anything, ever.

-Basically, if there are any errors, or a speed controller is disconnected, then you loose only that controller and go on, and it's no worse than where we are when a PWM cable comes out. The CAN cable coming disconnected from the 2can would be like the DC37 connector coming loose, it's a single point of failure that we already have, but it's just one point and not a point at every speed controller that can kill the entire bus.

I really do like CAN, just not the way it's implemented now.

I read over the LV implementation and I was really really really really horrified by some of the things they did. It block-waits for an Ack every time it sets a motor speed! For every motor! *gasp* Why should it care if the motor got it if it's going to send the motor something else in 10ms? If it times out at 10ms, and you have two motor controllers off-bus, then you will use up all of the 20ms loop interval waiting for two controllers to Ack when they will never Ack, and when you loose 5, then you've already missed two loops just waiting for controllers to never send you stuff! This is why blocking waits are bad!
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack