blog; Motor Controller Options for 2015

[Boe]

Wow I really love how much smaller these are, hopefully everything works out and they're available this year.

[NWChen]

Stupid question. I don't see any screw terminals on the info sheet, how do leads connect to the motor controllers?

[Bryan Herbst]

Originally Posted by NWChen

Stupid question. I don't see any screw terminals on the info sheet, how do leads connect to the motor controllers?

One of the listed features is:

Robust embedded power & output cables will never shake loose during a match

So the cables are embedded, similar to CIMs.

Not sure how I feel about this yet. On one hand, it will ensure that the cables don't come out of these controllers. On the other hand, it means we either have less reusability by permanently splicing the cables, or the same problem we currently have by using an intermediate connector.

I also have never had a big problem with cables getting jiggled loose from the existing controllers with a proper crimp.

[D.Allred]

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

David

[Steven Donow]

Originally Posted by D.Allred

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

David

The new controllers probably will be available, but it's not offical and will depend on results of beta testing (though it seems they most likely will end up being legal)

[ttldomination]

Originally Posted by D.Allred

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

Yeah, that struck me as weird, too. However, with FIRST opting to go into somewhat of a limbo, I think the fact that is not "approved" is only a formality at this point.

- Sunny G.

[timytamy]

Wow, those things are bloody tiny!!!

I'm still skeptical about having permanent cables, but I can see the benefits. Namely the PWM cable will never fall out again, and it will require significant talent to cross make the wrong connections between M+, M-, +12v, and GND.

I'm curious as to how AndyMark fits in with all this. With the Talon being discontinued and it seems like both the Victor SP and Talon SRX being distributed by VEX, will AndyMark find another controller? Or will the be able to distribute them as well?

Can't wait to hear more from the beta teams!

[ebmonon36]

I am curious to see what kind of connectors are on the CAN leads.

I hope it would be within the relaxed rules about repairing speed controllers to replace the cables if necessary. Many teams still have PWM cables getting eaten by drivetrains.

[dmaki]

Originally Posted by ebmonon36

I am curious to see what kind of connectors are on the CAN leads.

I talked to CTRE at CMP and he said he was considering using a 2 row 20 pin 2mm pitch connector for CAN, limit switch, and encoder inputs in order to fit on the small body of the motor controller. The same type of connector commonly used for JTAG debugging on ARM microcontrollers. Based on the drawing, 2mm pitch looks about right, but went down to 10 pins for limit switches and encoders and moved CAN to dedicated pigtails.

Also, I've just mounted 2 prototype Victor SP on a testbot. The wires are very supple and flexible. "Noodley", good stuff.

[FrankJ]

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. That would be the reason for two pairs. One in & one out. The legs of the pairs would be connected together in the Talon. I know some people use the star configuration for CAN & get away with it. It is not to the standard & it in not a best practice.

[Oblarg]

Originally Posted by FrankJ

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. That would be the reason for two pairs. One in & one out. The legs of the pairs would be connected together in the Talon. I know some people use the star configuration for CAN & get away with it. It is not to the standard & it in not a best practice.

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.

[wilsonmw04]

Originally Posted by Oblarg

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]

Originally Posted by wilsonmw04

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.

[marshall]

Originally Posted by FrankJ

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.

[Jared Russell]

Originally Posted by marshall

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.