Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   blog; Motor Controller Options for 2015 (http://www.chiefdelphi.com/forums/showthread.php?t=130334)

wilsonmw04 26-08-2014 15:46

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Oblarg (Post 1398064)
My only problem with the daisy-chain configuration is that it greatly exacerbates the failure mode. It's rather annoying to lose half of your motor controllers instead of just one of them.

It would be nice if there were a supported alternative.

There is an alternate: PWM's

Oblarg 26-08-2014 15:49

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by wilsonmw04 (Post 1398065)
There is an alternate: PWM's

While in the past I would have wholeheartedly agreed, this is a far less-appealing alternative with the new control system.

Monochron 26-08-2014 15:51

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Oblarg (Post 1398066)
While in the past I would have wholeheartedly agreed, this is a far less-appealing alternative with the new control system.

Do you mean with the robotRIO, or because CAN benefits are now available. If the former, why is everyone so down on using PWMs with the roboRIO?

Oblarg 26-08-2014 15:55

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Monochron (Post 1398067)
Do you mean with the robotRIO, or because CAN benefits are now available. If the former, why is everyone so down on using PWMs with the roboRIO?

The former.

AFAIK, in order to use solenoids, you must use CAN.

notmattlythgoe 26-08-2014 16:02

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Oblarg (Post 1398070)
The former.

AFAIK, in order to use solenoids, you must use CAN.

Correct me if I'm wrong, but I believe that the system is still plug and play with the modules. There is nothing extra needed to make the solenoid module work, the CAN implementation is in the background.

marshall 26-08-2014 16:03

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by FrankJ (Post 1398060)
Since I don't speak for the Cross the Road people, this is based on what I know about CAN. CAN is a two wire bus. It is intended to be daisy chained.

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.

NotInControl 26-08-2014 16:10

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Oblarg (Post 1398070)
The former.

AFAIK, in order to use solenoids, you must use CAN.

This may not be entirely true. While the new system does have a PCM module that automatically controls the compressor/pressure switch and has support for 8 solenoid channels.

Nothing stops you from using the 4 relay ports on the RoboRio to drive solenoids. Without needing to have a PCM.*

You can use One relay for the compressor, and 3 other relays for double acting solenoids. In fact, this is how we were running our pneumatics system using the RoboRio during Alpha testing when the PCM modules weren't supported yet. Only if you exceed 3 double solenoids, would you need to venture to use the CAN PCM module.

And even if you use the CAN module for pneumatics, that doesn't mean you can't or shouldn't use PWM. In fact, I believe most veteran teams will continue to use PWM on their drive train as a minimum despite the new control system, due to PWMs proven reliability and known failure modes. I believe this will be true even if they choose to use CAN motors elsewhere on their robot. Nothing currently prevents a mix use of CAN and PWM on the Robot.

*This is true as long as the 2015 rules do not prohibit this. Doing this is perfectly legal under 2014 rules.

Regards,
Kevin

Jared Russell 26-08-2014 16:35

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by marshall (Post 1398073)
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.

(Passive) star topologies are more susceptible to reflections and fan-out problems than traditional bus topologies and are best avoided for CAN networks in my experience.

NotInControl 26-08-2014 16:40

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by marshall (Post 1398073)
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

marshall 26-08-2014 16:43

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by NotInControl (Post 1398081)
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 ID goes down the entire bus goes down is not correct and shouldn't be perpetrated. 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

Very useful. Thanks for clarifying.

donkehote 26-08-2014 19:37

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by cgmv123 (Post 1397962)
Labeling is a listed exemption in the relevant 2014 robot rules regarding modifying electronics; adding thermal paste isn't.

Quote:

Originally Posted by cgmv123 (Post 1397687)
My common sense doesn't matter. I'm just cautioning against applying thermal paste/grease to motor controllers since the (2014) rule against modifying control system components specifically mentions gluing as an illegal modification.


Again, as Ether pointed out, thermal paste IS NOT GLUE. Glue is an adhesive, thermal paste is not.

Webster defines glue as : a substance used to stick things tightly together
http://www.merriam-webster.com/dictionary/glue
Even if you change glue to adhesive, thermal paste is not there to retain anything. It usually has a very weak bond, and often never sets, remaining a very thick liquid/gel.

Velcro is attached by adhesive or glue, but is legal. Please stop beating the dead horse :deadhorse: and move on. I know at least a few teams will have the thermal paste on these speed controllers, if its explicitly allowed or not. It would be almost impossible for a robot inspector to see the thermal paste in place anyway. Im sure as soon as the Q&A opens, there will be more than one person who asks this. No need to keep dragging up the same ridiculous argument.

RonnieS 26-08-2014 20:37

Re: blog; Motor Controller Options for 2015
 
Will you be able to use all PWM's for your speed controllers and just do a very simple can run to your PCM? I am not a programmer or heavy into electrical beside powers wires so don't kill me haha. Thanks.

Bryce Paputa 26-08-2014 20:40

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Ronnie314 (Post 1398110)
Will you be able to use all PWM's for your speed controllers and just do a very simple can run to your PCM? I am not a programmer or heavy into electrical beside powers wires so don't kill me haha. Thanks.

You should be able to.

RonnieS 26-08-2014 20:42

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by Bryce Paputa (Post 1398111)
You should be able to.

Ty Bryce! We have ran CAN for the last few years and really am ready to throw these $@#$@#$@#$@# jags away. But cost wise, the new victors are a lot more appealing and lending towards PWM use

Tristan Lall 27-08-2014 03:53

Re: blog; Motor Controller Options for 2015
 
Quote:

Originally Posted by donkehote (Post 1398102)
Again, as Ether pointed out, thermal paste IS NOT GLUE. Glue is an adhesive, thermal paste is not.

Webster defines glue as : a substance used to stick things tightly together
http://www.merriam-webster.com/dictionary/glue
Even if you change glue to adhesive, thermal paste is not there to retain anything. It usually has a very weak bond, and often never sets, remaining a very thick liquid/gel.

Velcro is attached by adhesive or glue, but is legal. Please stop beating the dead horse :deadhorse: and move on. I know at least a few teams will have the thermal paste on these speed controllers, if its explicitly allowed or not. It would be almost impossible for a robot inspector to see the thermal paste in place anyway. Im sure as soon as the Q&A opens, there will be more than one person who asks this. No need to keep dragging up the same ridiculous argument.

The caution about thermal paste is due to a plausible analogy between substances, rather than a mere dictionary definition. Like glue, it doesn't fall off the surface, so some phenomenon must be holding it there; is that adhesion significantly different from the adhesion provided by glue? If so, why, and how will you convince the officials of that?

If it's an argument of magnitude of adhesion, would you have the officials permit weak glue as well? If it's an argument of function, would you have the officials permit glue whose adhesion is redundant due to additional fasteners? If it's because thermal paste doesn't set, would that make uncured glue legal? If it's because thermal paste is pretty much inert and can't chemically harm anything, would mostly-inert glue (like mucilage) be allowed? Or if it's a combination of these factors, how should they be weighted when making a determination?

As for Velcro, isn't it (usually) covered by exception G in R64? Its legality is not a very strong argument for thermal paste.

Best to let the Q&A sort it out, but by all means let FIRST know now that you anticipate it being an issue during the season.


All times are GMT -5. The time now is 01:11.

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