Re: New Talon Speed Controller
 

May I ask: how do you know this?


I wouldn't recommend using the transient inrush current test to draw that conclusion.

Look at the curves in the speed vs torque report. The Victor888 and the Talon create virtually identical power output from the CIM at max PWM. See attached graph showing the max PWM traces from the report overlaid for Talon and Vic888.

Re: New Talon Speed Controller
 

I forward MAX continuous = 60mA
I forward Peak = 3 amps

I turn-on MAX= 1.6mA

Vrev MAX = 6 volts.

Re: New Talon Speed Controller
 

OK great. My existing cables will work fine. Thanks.

Re: New Talon Speed Controller
 

I was looking at Mike's post which states "lower on resistance" as difference between the Victor 888 and the Talon. Thanks for plotting both the Victor 888 and Talon together. I would agree, if the Talon does have a lower on resistance, it does not show when plotting the test data together.

Re: New Talon Speed Controller
 

What are these differences in respect to? The Jaguar? The Victor?
Also, what is locked anti-phase rectification? I've never heard that used before. Most of the other features are already available in some form on either the Jaguar or Victor, with the exception that they don't occur on both at the same time.

Re: New Talon Speed Controller
 

I take back what I said about the driver, as it could also quite easily be the increased switching speed and better MOSFET's, but for maximum power output, the newer controllers can achieve a much higher speed at a given torque than the old Victor 884. This might just be due to the switching issues though that 120 Hz present.

Re: New Talon Speed Controller
 

Additionally, question about the test: Was there time allowed between runs for the motor to cool down to ambient before starting up again? If not, which runs were done "hotter" than others?

Re: New Talon Speed Controller
 

so does anyone know why the heatsink on a talon only touches the cap and not the board?

Re: New Talon Speed Controller
 

I've never seen a Talon controller, but are you sure that's a cap not a MOSFET?

Re: New Talon Speed Controller
 

It touches both.

Re: New Talon Speed Controller
 

Nothing I've seen supports the above statement.

What data are you using to draw this conclusion?

Re: New Talon Speed Controller
 

Talons are FRC legal as per the AndyMark email blast.

Seems that they're responding to market pressure ($50 pricing for IFI 888's), and dropped the price to $59.00. Hard to pass up at that price.

http://www.andymark.com/Talon-p/am-2195.htm

Re: New Talon Speed Controller
 

Wow. That basically makes them an automatic buy for us, unless the price of the Jaguars is also reduced.

Re: New Talon Speed Controller
 

As I pointed out in another thread, an email from AndyMark doesn't make something FIRST legal; that ruling can only come from an official communication from FIRST. However, the fact that it is in FIRSTChoice appears to make it legal according the the FIRST Blog.

In this case it appears that the net effect is the same, just be careful on jumping to conclusions.

Re: New Talon Speed Controller
 

They are legal. A couple of phone calls confirmed that. No word confirming it on the 888 yet.

In addition, I just got confirmation that the 888 is legal as well.

Data for the failure amperage has been retracted: it appears we made have had some measurement errors. We'll reupdate after we fry a couple more.

Re: New Talon Speed Controller
 

Tom, I think the relevant metric that's missing here is: "how much torque can each motor controller generate (driving a locked-rotor CIM) without popping the breaker".

If we had a locked-rotor-CIM torque vs battery rms current for each controller, I think that would answer the question.

Re: New Talon Speed Controller
 

Looking through everything that's been generated about the different speed controllers, I think we have enough information to come to some general conclusions for each (please note these are my own conclusions, yours may vary):

Victor 884 - It's been the go-to speed controller for many, many years. However, it's failings in linearity and the introduction of the Victor 888 have relegated it to a back shelf. It's still great for applications where fine-tuned speed control (especially slow speed) isn't necessary, if you have some laying around collecting dust.

Victor 888 - A step up from the Victor 884 in linearity. In fact, Ether's graph's put it on par with the other speed controllers, although those from 1718 show that they "over corrected", which could cause a loss in definition at high speeds. More work may need to be done to show which graph is more accurate for FRC uses.

Jaguar - No real surprises here. The Jaguar has maintained its linear response nicely for years. The addition of CAN (and the associated limit/encoder/potentiometer feedback) may make this the ideal speed controller for many teams. The most obvious downside, however, is the larger footprint the Jaguar has, which may also make it less than ideal for many teams. Also note that the Jaguar has a slightly larger deadband than the other controllers.

Talon - The Talon seems to be a great mix of all the others. It provides the small deadband and small size we got from the Victor, and the linear response we got from the Jaguar. The fact that it can be used only with passive cooling and no fan is a great bonus (although I would still put a fan on any used for the drive train or other strenuous applications).

With this combination of speed controllers, it seems that we have one for every situation. I think the difficult part for most teams is going to be finding a noticeable difference between the Victor 888 and the Talon, aside from the passive cooling in the Talon.

Re: New Talon Speed Controller
 

Hi Jon, could you please elaborate on the following:

1) what specifically are you referring to: "those from 1718"

2) what do you mean by "over corrected"

3) what do you mean by "a loss of definition"

Thanks.

Re: New Talon Speed Controller
 

The AndyMark product page for the Talon (http://www.andymark.com/Talon-p/am-2195.htm) says something interesting:

"Do you want your motor to hold it's position after power is cut?"

How does the Talon provide this? Does it stay in brake mode even after power is removed?

Re: New Talon Speed Controller
 

I'm referring to these images:


from 1718's beta testing: http://www.fightingpi.org/Resources/...12_Day_9.shtml

Basically, the Victor 884 curved away from being linear in one direction, while the 888 seems to curve a little bit away in the other (thus over corrected when adjusting the 888 to be more linear than the 884).

The result would be the exact opposite of the 884 - you would be able to finely tune the speed of your motor at the low end, as each step change in input would be a smaller change in output, but would have worse control at the high end, as the same step size would result in a much larger change in output.

Of note, the data you gathered didn't seem to show this same result, which leads to a question of which data set more accurately reflects real-world usage on a FIRST robot. Only having two data points makes it tough to reach a conclusion on this.

Re: New Talon Speed Controller
 

The first graph you linked was using a Window motor, not a CIM, with unknown torque load.

The second graph you linked was using a CIM with unknown (and possibly changing) torque.

All the testing I did was with a CIM motor on a dynamometer with measured torque load.

So it's difficult to compare the data.

Re: New Talon Speed Controller
 

That is correct, and we're verified it.

It stays in brake after pwm signal is removed.

Re: New Talon Speed Controller
 

Is there still a jumper to enable/disable brake mode?

Re: New Talon Speed Controller
 

Yes there is.

However, one thing we didn't verify is what happens if the jumper is set to coast and the pwm signal is killed.

Mike C. can probably answer that without us doing another test.

Re: New Talon Speed Controller
 

Agreed!

Ultimately, graphs can only tell you so much... the real "proof" is what the drivers think when you stick some of these onto a drive train. I know when we switched from Victors 884's to Jaguars, there was a noticeable improvement in our ability to control the robot. Would there be a noticeable difference switching between Victor 888's, Jaguar's, and Talon's? Personally, I wish I had about $400 to spare so we could buy 4 Talons and 4 Victor 888's and swap them out on last year's robot!

Re: New Talon Speed Controller
 

When you're trying to do closed-loop control of speed, you might want to see what the torque response vs command looks like at various speeds.

So I just wrote an awk script to re-arrange the raw RPM vs Nm data to provide a family of curves of Nm vs IPW¹ at various RPM levels.

Here's the result:
http://ether.comeze.com/FRC/WMCT801/


¹ input pulse width in ms

Re: New Talon Speed Controller
 

The way I'm interpreting this is that, after the main breaker is switched off, dynamic braking still occurs (i.e. the output is still shorted). This is very different from saying that the behavior at a neutral command is to dynamically brake the motor.

Could you confirm that brake mode persists after the main breaker is switched off? This could become a serious issue when teams need to push the robot around by hand.

Also, if this really is the case (I'm skeptical), could someone answer how this (feature apparently?) was implemented.

Re: New Talon Speed Controller
 

I would not have interpreted it they way you have. I would have interpreted it as that when the PWM signal is disabled (flatlined) the Talon continues to apply brake mode if the brake/coast jumper is set to brake.

When the main breaker is switched off, power is cut to everything, including all Talons, Victors, and Jaguars. At that point, the MOSFETs in the H-Bridge turn off and the only conduction possible is through the reverse body diodes.

Re: New Talon Speed Controller
 

That makes sense, and matches the behavior of every other FRC-legal motor controller.

This is why I'm skeptical -- and why I was curious to know how my interpretation is possible.

I'll assume your interpretation is correct, then, unless someone comes in and confirms that mine was correct.

Thanks for clearing that up.

Re: New Talon Speed Controller
 

This is a misprint. It should read "when disabled" not "after power is cut".

Re: New Talon Speed Controller
 

Scott, you are correct.

Re: New Talon Speed Controller
 

Has anyone with a Talon trying to control it with a cRIO/WPILib found a set of PWM signal timings that work well? The source for the Victor notes that signal acceptance between units was a bit off and I was wondering if this can be attributed to the signal generator or consumer side. I have a feeling this can be chalked up to poor calibration on the Victor as the cRIO generating sloppy signals seems less likely.

If no one responds we will run a test across 4 Talons to find timings that work, then post the results here and to WPILib.

From Victor.cpp:

Re: New Talon Speed Controller
 

Using a custom PWM signal generator, I have run the Vic888 with periods from 5ms to 20ms, and with pulse widths from .5ms to 2.5ms with no problems. I believe I did the same with the Talon, also with no problems.

[edit] I have not tested whether the motor controllers would calibrate properly to this pulse width range [/edit]

Re: New Talon Speed Controller
 

The problem that the comment that Tom is referring to was finding what values work best with factory default calibration, and with the Victor 884, it varied unit to unit.

Re: New Talon Speed Controller
 

FWIW. Vic888 calibration using 500 ohm resistive load.

Re: New Talon Speed Controller
 

Here's another calibration chart for the 888, this time with reduced range and asymmetric calibrations. The 1.625 is not a typo.

Re: New Talon Speed Controller
 

Ether - In practical terms (aka what a team would see from the Victor on the field), what all do those charts tell us about how we should be calibrating the Victors? I understand what the values mean, I'm just not sure how to best apply them.

Re: New Talon Speed Controller
 

The primary intent of the charts was to give a peek under the hood of what actually happens when a motor controller is calibrated.

A practical application is that the charts suggest that the 888 seems to have an adequately large range of calibration to handle expected min/max/neutral variations in joysticks and other UI devices, and provides some overtravel at each end to prevent any throttle clipping.

Re: New Talon Speed Controller
 

FRC Blogged


It's official

2013 Control System

First, the list of approved motor controllers will be expanded. Specifically, Cross the Road Electronics’ Talon and Innovation First’s Victor 888 motor controllers will be legal.

Re: New Talon Speed Controller
 

We drove 2 side comps with no fans on our drives. Temp never went above 83 degrees and only took 10 mins to drop back to room temp. Our team is sold and we just bought 12 more for this upcoming season.

Re: New Talon Speed Controller
 

This is a lengthy thread I haven't been able to keep up with. I know Ether has done a lot of testing. Can someone give me the cliffs notes of the motor performance differences between the Victor 888, Talon, and Black Jaguar ?

Re: New Talon Speed Controller
 

Short version:

Talon linearity is nearly as good as a Jaguar. Talon is less susceptibile to shorting due to swarf.

Victor 888 linearity is much better than Victor 884, but not as good as Talon or Jag.

Jags have CAN now. Talons will have it later.

Competition has provided customers with better performance and prices.

Re: New Talon Speed Controller
 

Number one reason to buy the talons. Not jumping back 4 feet when you brush you finger against a fan and you think you just lost your knuckle lol.::ouch:: I think i did more injury to myself jumping from fans then everything else combinded.

Re: New Talon Speed Controller
 

Maybe I missed it somewhere, but how does the width of the terminal space compare to the Victors? On the Victors (at least the 884s) I've found some terminals to be too wide to fit.

Re: New Talon Speed Controller
 

Yeah, I've seen that problem also. When I found the right terminals, I bought a big bag of them. That was about six years ago, and now my supply is running low -- time to figure it out again.

Based on the day we spent testing Victors, Talons, and Jaguars in my lab, I recall that our terminals fit Talons and Victors the same way. I think Victor and Talon footprints are the same, and their terminal layouts also match. Mike and Paul should be able to confirm or counter.

Re: New Talon Speed Controller
 

I wanted to follow up on our promise to toast the Talon. We didn't really accomplish it the way we meant to. First, we ran the Talon without a fan. We connected 2 cims to the output, and 4 inputs from the PD board. We locked the drivetrain in place, and then started ramping up the voltage.

Initially, we thought we had an infant mortality when the Talon dropped out at around 60 amps. The truth of the matter (after disassembly and testing back at the manufacturer) was that the Talon got SO hot that it desoldered components from the board. That's what happens when you run 60 amps through an uncooled speed controller for an extended period. It still didn't actually smoke for us, though I understand it did when it had cooled and resoldered some of the joints at the manufacturer.

Today we retested the Talon with a fan on it. We hooked it up to 1 cim, 2 inputs, and ramped the amperage up. In this case, we had a borrowed Cross The Road engineer with a datalogger in-line with the input to the Talon, so we know exactly how much amperage we were running. We couldn't kill it. We ramped up to 74 amps continous (for an extended period). The silly thing just wouldn't die.

The Victor provided equally good results in both cases. The bottom line is that there is NO way an FRC team should be able to fry either one of these with a fan on.

We have one more 'test' we'd like to try: we're going to bolt a talon to an aluminum bar (simulating a chassis bar) and see if it sinks enough heat to keep the Talon happy over extended periods at high amperage. I think that will wrap up our Beta season this year.

Re: New Talon Speed Controller
 

I'd be curious about this same test but with no fan. Did you happen to perform that at any point?

Re: New Talon Speed Controller
 

No, we didn't. I'm not sure how much additional practical data we'd get from that. Here's my take on it. We found that a Talon without a fan can be killed by a very high (by FIRST standards) amount of current for an extended time period. In fact, you can't generate that much in FIRST because of the 40 amp breakers.

I think the data in the user manual really covers the rest of the questions with regards to FIRST applications. For instance, look at the 30 amp data in the user manual. Keep in mind that a single cim pulling 30 amps through an entire match is fairly unlikely.

The graphs show data for a 3 minute match and a 7 minute cool down. Using that data you'll be wandering into a temperature zone you probably don't want to stay in after four consecutive back-to-back matches. So, it appears that unless you find a novel way to keep them cool without a fan, you may want a fan on a drive train application.

Of course, we could attempt to quantify this further with more scientific tests, but I think it would be a waste of time. If teams choose to go without fans in high-current applications, they should grab an infrared thermometer and check the Talon after practice matches to see how much your temps are changing. Or measure the current you're drawing, and extrapolate from there using the User Manual charts. Or get really fancy and wire a thermistor back to the cRio and log the data.

If only we had endless time to play :D

Re: New Talon Speed Controller
 

Key word in this quote is "should". So I don't need to cover my speed controllers when I'm grinding aluminum now? Excellent.

Re: New Talon Speed Controller
 

Tom,
That is a static resistive test. You are most likely testing the current carrying capacity of the FET bond wire. The thin wire that connects the FET leads to the chip die. Most recent heavy duty FETs are current limited by the bond wire. The die can carry more current than the bond wire. It's a one shot thermal fuse. Hook a FET up to a direct short and watch the case pop. The bond wire vaporizes and blows the case. To really test the Talon you need a dynamic test to stress the die. You need to have the H-bridge coping with switching transients. A good test would be to but a cim into a gear box with a fly wheel attached. Say like a AM pneumatic wheel or a little heavier. Test by applying full power till it is up to speed and then reverse the direction. Wait till it gets up to speed reverse direction. This will stress the FET die in addition to the bond wire. Again with modern power FETs This repetitive avalanche condition affects the FET thermally. It's more like a real world FRC condition. My robot goes forward my robot goes backwards. Especially in this years game. If a Fet is allowed to heat beyond Tj max they fail fast. However if they are subjected to high temps close to Tj max they will have a shortened life. High energy switching transients tend to damage the structures around the gate. For these reasons teams should monitor the talons heat sink temp and a small fan would be a good idea in most drive train applications. Drive teams tend to go hard on the robot way beyond the 2 minute match time. Andy Mark has a IR thermometer on First Choice. A wise purchase for Talon running teams.

Re: New Talon Speed Controller
 

Given that a hot Talon gets de-soldered vice totally melting down I wonder if the reliability of the Talon goes down with age, particularly if a team decides to NOT use a fan along the way.

Re: New Talon Speed Controller
 

When designing robots, we also factor into the design offseason use such as parades and demos. With our most recent robot, we did a week-long demo doing light running continuously every day without pause except for battery changes (which were approximately once every hour). Victor 884s never gave a hiccup. I want to make sure we have the same success with whatever future controller we went with. It would be nice to not have fans, but but I suppose we could add them if needed.

Re: New Talon Speed Controller
 

Tom, just to be clear what "both cases" means. Are you saying the Victor survived this test:

Re: New Talon Speed Controller
 

I can see why that was a little confusing. I suppose I should have been more concise and listed it out in table form.

Test 1:
Talon with no fan.
Driving 2 stalled cims with 4 inputs from the PD board.
Fluke ammeter reporting amperage on the positive battery lead.
Died at 60 amps.
Root Cause: Temps were above 100 C, and the board desoldered.

Test 2:
Victor with fan.
Driving 2 stalled cims with 4 inputs from the PD board.
Fluke ammeter reporting amperage on the positive battery lead.
Ramped up to 80+ amps and the robot began turning off and on.
Ramped back to 80 amps and ran for about 30 seconds without a problem.

Test 3:
Talon with fan driving 2 stalled cims with 4 inputs from PD board.
Fluke ammeter reporting amperage.
Ramped to 80 amps without a problem, held at that point for 30 seconds without a problem.

Test 4: (verification of our fluke ammeter readings)
Talon with 1 stalled cim and 2 inputs from PD board
Inline datalogger ammeter plugged via USB to laptop.
Datalogger was placed on the positive lead from the PD board and fastened to the speed controller.
Ramped to 74 amps without a problem: above this the 40 amp breakers began resetting.

In each case with the fluke, we zeroed it when the robot was enabled with no pwm signal sent to the motor. The robot ran between 3-5 amps on the positive battery lead when enabled with all motors at rest.

Re: New Talon Speed Controller
 

Anybody out there comfortable with using a fan-less Talon for competition?

Re: New Talon Speed Controller
 

Not me. Not when fans are so cheap.

I want my drive team free to push their robot to its limits.

Re: New Talon Speed Controller
 

So then what's the benefit over a Victor 888, which can be purchased for less cost? Just the fact that it isn't open for debris to fall inside?

Re: New Talon Speed Controller
 

That, and better linearity. Talon linearity is almost like a Jaguar, Victor is not.

Re: New Talon Speed Controller
 

Based on what I've seen, I'd feel comfortable using it sans fan on anything that's not a CIM or Fisher-Price motor and/or isn't on a 40-amp circuit. I'd use a fan or Victor or Jaguar for everything else.

Re: New Talon Speed Controller
 

So at a recent off season competition our team had tested out the Talons and so I thought I would post a few notes.

- Friday we were practicing with Jags still attached, Saturday with Talons on we noticed a slight speed difference

- The Talons didn't heat up though its debatable to account this since the schedule was light weight

Re: New Talon Speed Controller
 

For better or worse speed difference?

Re: New Talon Speed Controller
 

For the better

Re: New Talon Speed Controller
 

Could you please clarify what you mean by a "better speed difference"?

For example:

- faster speed for a given open-loop throttle setting

- more linear response to open-loop throttle commands

- more stable closed-loop speed control

- something else?

Also, did you measure it or is this a subjective judgement of the driver?

Re: New Talon Speed Controller
 

This is a subjective judgement of the driver

- The stability of closed loop control is debatable due to the recent drive train change though open loop control was tested with both the Jags and Talons with the new drive train.

- The speed and agility on carpet with the Talons equaled the speed and agility off carpet with the Jaguars.

- Difference of response time between the two motor controllers were either subtle or not there.

Re: New Talon Speed Controller
 

When exactly is later? And if we buy Talons now, will they be compatible with CAN once Talons support CAN?

Re: New Talon Speed Controller
 

Mike, do you want to jump in here? You have both the Talon and the 2CAN. When will they start talking to each other?

Re: New Talon Speed Controller
 

The present model Talons have only a PWM input. I'm trying to picture how they could "be compatible with" CAN. What did you have in mind? Some sort of CAN-to-PWM interface?

Re: New Talon Speed Controller
 

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.

Re: New Talon Speed Controller
 

Mike, this feels like an area that would require a much longer conversation than I'm willing to type out. I will make a few points, though:

- CAN is a great system, but the current implementation is a little lacking. For example, you can't have a single encoder help control two Jaguars, when the bidirectional communication would seem to allow for that.
- In order for CAN to really become popular, we have to get more than just our speed controllers on it. It's incredibly useful in automotive applications simply because so much stuff is on it and able to talk back and forth.
- In the tradeoff between size and capabilities, I'll always choose capabilities. We've used Jaguars on the drive train since they came out specifically for that reason - the linear response was worth the increased size. Now that the Talon offers a near-identical response at a similar price point, the decreased size is the key differentiator (assuming the capabilities of CAN aren't required).
- To add CAN to the Talon, how big would the footprint get? If it's the size of the Jaguar (for example), then we would need to see some additional capabilities to make it worth purchasing over using our current stock of Jaguars.

I, for one, would absolutely love to see what you could do with CAN!

Re: New Talon Speed Controller
 

I, personally, favor a LIN bus. The ~10kb/s data flow should be enough (but maybe it isn't?), and it is dirt cheap to implement.

Oh, and another data point: If you connect 12 VDC to the output side, and the motor to the input side, the Talon doesn't work properly anymore.:ahh:

Excuse me, I have some students to harass counsel.:rolleyes:

Re: New Talon Speed Controller
 

Not knowing anything about LIN... I'll assume an essentially perfect bit packing for minimal operation.

4 motor controllers * 8 bits/controller/cycle = 312 Hz control

Note that that number goes down if individual addressing is supported, more than 4 controllers are on the bus, more than 8 bits are transmitted (i.e. you're actually using it to gain capabilities not available through PWM -- also, the Talon has 10 bits of output resolution).

I'm not so optimistic that this will be fast enough -- I highly doubt that it would be nearly this efficient.

For running just 1 controller (not the drivetrain), this might be more suitable. I'll look more into the LIN bus.

Edit: It appears the minimum packet size is 5 bytes (there might also be other delays -- I'm just looking at the extreme basics here). That puts the control rate for 1 controller at under 300 Hz... for 2, that's under 150 Hz (and under PWM).

Re: New Talon Speed Controller
 

OK, nevermind. CAN it is....:o

Re: New Talon Speed Controller
 

You don't send 8-bit LIN commands.

http://en.wikipedia.org/wiki/Local_Interconnect_Network

LIN, like CAN, is a message based protocol, with generally lower bus speeds than CAN and significantly simpler implementation. Unlike CAN, LIN has a bus master which is in charge of bus arbitration and scheduling. Vehicles generally use it to connect slave IO modules to a central ECU, for example to connect buttons on a steering wheel to a body control module, where the button modules act as LIN slaves. The smarter LIN bus masters are then connected to the full CAN busses, CAN being a faster and master-less bus which is often used for sending many messages very fast.

But, you communicate by sending message frames. Frames consist of various header information fields (including an ID) and 2,4 or 8 bytes of data.

It would be just fine for 50hz motor updates. It's really easy to wire, as it dosen't care about splits or segments and can run at rather long wire lengths (for FRC use) with no issues, it uses a single wire with 12v signal voltage, and is implemented using UART hardware, meaning a simple level shifter is all you need to use the RS-232 port to speak LIN.

Re: New Talon Speed Controller
 

An RS-232 port can speak PWM servo signal, too.

http://www.chiefdelphi.com/media/papers/2702

Re: New Talon Speed Controller
 

What is the verdict on talon and encoder integration? Do you have to manage the encoders through the cRIO as before? If so, is it impossible to do the kind of speed control that was used with the Jaguars (for large speeds, i.e. fly wheel)?

Re: New Talon Speed Controller
 

I've been slowly trying to do that over the last few seasons. However, with some of the issues with CAN for FRC as well as the Jaguars(ie.. brownout & forget closed loop configuration) I haven't been able to do that. If those issues could be corrected, I'm in 100%. As I understood it, not many if any teams do BETA testing with CAN, so that alone would help.

Agreed, CAN is a much more elegant and neater(no more rats nest of pwm wires) solution than PWM. The ability to do asynchronous co-operative processing with controllers over the CAN bus is really awesome. We did some of that this season.

I would be willing to pay more for a CAN enabled Talon with a slightly larger footprint. Of course, how big a price difference matters, as well as how much bigger it is. For example, 1.25 - 1.50 times as much, and smaller than a Jaguar I'd be sold on. Again it's something that needs to be thought about as it's a Price/Performance/Value question which is hard to answer right now.

We've used the larger Jaguars on our drive system with PWM because we wanted the better linearity of the Jaguar. So for some teams perhaps size matters, it all depends on what their objectives are. Of course now that the Talons have that great linearity too, we'll most likely switch to Talons.


I don't know if this would be viable, but what about 2 different Talon models? A PWM only as is today that has the small footprint and low price point, and a CAN only as an optional model? I don't know if there's enough market for the CAN only model, but it's a thought.

Re: New Talon Speed Controller
 

Could you please elaborate what is your intended meaning of the phrase "asynchronous co-operative processing with controllers over the CAN bus" ?

Re: New Talon Speed Controller
 

What I mean, is exploiting the closed loop functions in the Jaguar which at this time is only available via CAN.

Such that I can send a command(s) on the CAN bus to one or multiple Jaguars running in closed loop mode to perform some function(s) while other code and processing is performed on the CRIO all simultaneously.

For example, if I have 8 Jaguars on the CAN bus, that perform 8 distinct functions that are not tied to one another, I can have 8 different operations happening concurrently, along with what ever other processing I might need on the CRIO.

So, now we've offloaded processing from the CRIO to the Jaguar to achieve a joint task that's (co-operative) processing.

Since these processes can now happen simultaneously and no one process need wait for another they are said to be asynchronous. You could call it parallel processing if you wanted.

You could in theory have the CRIO be relegated a message handling agent, sending messages, reading status, and sending other messages based on status received.

I do stuff like this in my day job.

Re: New Talon Speed Controller
 

That doesn't appear to be a discriminator for us; we have performed the same test on a Jaguar before with equivalent results. It was an unsupervised experiment and not in a lab environment but I'm pretty sure it's repeatable. :o

Re: New Talon Speed Controller
 

Thanks for all the fine testing and analysis, folks. I snagged half a dozen Talons through First Choice today. I hope they provide joy. I intend to use them for CIMs, with fan. You'd be crazy to not use a fan if you can use one, as the lifetime of electronics is exponentially increased by cooling it a few degrees.

Having designed a smaller motor controller for underwater stuff, I have long been mystified at the behavior of the Victor 884. I'm under the impression (from reading the CD archives) that it doesn't short the motor winding in the off phase of the PWM cycle. Is this the case, or does it do something else to make it so nonlinear?

Re: New Talon Speed Controller
 

The nonlinearity of the 884 is largely due to the 150Hz output PWM switching frequency.

Re: New Talon Speed Controller
 

If there is ever a redesign of the Talon board and case, it would be nice if there was a separate plug in for the fan. Stacking the 2 power connectors is irritating.
Not a big deal but would be nice. As to fans, teams just put one on. If there is a problem with the Talon it will probably be thermally related. The cooler the heat sink the better the heat will flow out of the chips. Veteran teams should have a box of 40 20 mm fans from previous years. Just need 2 screws and 2 terminals. Easy.

Re: New Talon Speed Controller
 

You're going to need to stand the fan off too. The idea is to keep the air circulating, not necessarily draw the heat straight out

Re: New Talon Speed Controller
 

Looking forward to getting my hands on some Talons. They are being shipped now.

Re: New Talon Speed Controller
 

I'd be wiling to pay $75-100 for a CAN enabled controller but footprint is super important. Something slightly larger than the Victor would be acceptable, the Jag is too big.

Re: New Talon Speed Controller
 

Seeing this part of the thread made my eyes light up...

As one of the few 10% who use CAN and have been using CAN since our championship year in 2010, I would be all for this.

However its not the interface in which we are looking a rather it is the data and the bidirectional functionality that makes us use Jags. Even though Jags are 'big and fat' compared to the Talon/Victor, the fact that we can pull a ton of telemetry off the Jag plus do a simple PID (a nice addition.) is what separates it from the Victor/Talon. In 2010 we were using current feedback from the Jag to identify if we had a ball or not. Essentially we got a lot more versatility off the Jag/CAN bus other than just commanding motors.

In addition, one interesting thought would be a redundant control path. Since most teams stay away from CAN due to potential reliability problems(only year we had an issue was traced to a 775 case short) What would the prospects be to putting a redundant PWM/CAN interface ie. if CAN messages die, the motor controller can still be controlled via PWM. (disclaimer.. I work in the space industry so redundant paths are usually a must)

Bottom line, if you could put a talon with CAN + similar telemetry data in a better form factor, (even with a larger footprint) I would jumping and singing for joy. Oh yeah also make the hole spacing a nice number!

Re: New Talon Speed Controller
 

That would be really something. The reliability problems are what is prompting our switch away from CAN/Jaguars to Victor 888's for 2013. The amount of time we spent pulling up the 2Can webpage and troubleshooting intermittent connectivity problems was far too great (it's really difficult to know the true source of the issues - it could have been anything from a bad connector, as some of our Jaguars shipped with bent connectors, or something more complex). That's not to diminish the benefits of CAN, but our experience with it was less than ideal.

Re: New Talon Speed Controller
 

Even more so, I agree with this. I don't think it would be very hard to implement in software - correct me if I'm wrong. I know a feature like this would cause us to take a second, very long look at running CAN.

Re: New Talon Speed Controller
 

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.

Re: New Talon Speed Controller
 

Last time I checked, having dual controls hooked to a speed controller was Illegal, so the rules may need to change as well.

However, I agree 100%. The reason we have never switched to CAN is because of the reliability issues some teams have had. We've Beta tested CAN on our robots with no problem, but right or wrong, I see PWM as a more robust option.

Is there a quick way to troubleshoot CAN, short of plugging in a computer and polling the devices? I.e. - is there a LabVIEW VI for the dashboard that shows each device and it's communication status?

Re: New Talon Speed Controller
 

Tom,

You are correct with the rules. I agree though that it would be a tweak in the rules. Just as long as they can show good compliance to the robot safety side.

As for the CAN reliability, we have some issues with the CAN bus but not tons. The biggest issues include some of the Jags losing ID's, some 2CAN boot issues. But it is obvious that others have had many more issues. Our Debugging usually consists of rebooting the 2CAN then checking the 2CAN page to verify all the Jags. In my mind CAN is a widely used Bus standard why FIRST cannot make it reliable is beyond me.
I really like this idea. It can allow for more seamless data transfer between Jags and or data to the cRio! I am a big proponent of utilizing CAN for sensor/Telemetry data!

Re: New Talon Speed Controller
 

Myself and another team programmer were talking to a NI representative at MSC last year - he was going around, doing an informal feedback survey on the control system. We remarked about the reliability of CAN to him. He told us that there was a CAN module for the cRIO (a Google search finds this, although it doesn't have the same 6p6c connectors on the Jaguars). He said that the way FIRST/WPILib implementation of CAN is done, in terms of hardware, was not well done - whether using 2CAN or the RS232 interface. This seemed to be a standard routine he was giving to people.

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!

Re: New Talon Speed Controller
 

The 2012 LabVIEW CAN Library implemented an isochronous mode. It does not block, but also doesn't look for the Ack. It's designed for sending periodic updates where you don't care if a particular message is received. There's a boolean input for whether you want isochronous or blocking.

Re: New Talon Speed Controller
 

Block wait.

The Netcomm library (black box compiled code) includes a Read and Read Async function.

Read is fed a message ID and timeout, and returns either 8 data bytes or failure after no more than timeout. So, the function is blocking.

Read Async is fed a message ID and Occurrence. The VI then does a Wait On Occurrence with timeout specified, if the Occurrence is triggered then it calls another function to retrieve the data. This function is not blocking at a Netcomm level, but is blocking at a system library level (Lower than the exposed CAN message interface is the Netcomm interface which is used by the CAN message interface).

Since WPIlib generally pushes teams to put all of their code in Teleop or Timed Tasks, putting a blocking read command in Teleop and having it fail is very bad for deterministic Teleop timing (which is already really jittery because it's timed by Ethernet packets). It gets even worse with multiple jags, or multiple commands per jag (e.g. Set Speed and Get Current would both block-wait, if that jag goes offline then there's 20ms of timeouts just for that one jag to be waited through by the user code).

Basically, all of the CAN send-response interactions are all synchronous, which is a huge time penalty over an asynchronous architecture if it ever has to wait for a response and dosen't get it.

Re: New Talon Speed Controller
 

I see the isochronous mode for the Motor Control Set, but nothing else.
I also see that Read Status sets a timeout of 0 for messages continually transmitted, but could also do a transaction (with 10ms timeout) if requesting something on-demand.

Everything else is still blocking (set parameters require Ack, read parameters are synchronous).

Really, CAN is designed to never care if a message is received, and to transmit everything continuously (with less important information at a slower rate). Having an Ack message makes no sense to me.

Edit: Motor Set defaults to synchronous mode, and the Isochronous input is not in the help. I'm guessing many teams still run in synchronous mode. It should default to isochronous mode, IMO.

Re: New Talon Speed Controller
 

Is it possible to revert a Talon to factory calibration?

Re: New Talon Speed Controller
 

No it is not.

Re: New Talon Speed Controller
 

Mike, could it be done with a PWM signal generator which generates a known pulse width accurate to 0.001 ms ?

Re: New Talon Speed Controller
 

Mike, our last Beta update included a new class for the Victor 888's. I haven't seen one for the Talon yet.

Is one going to be released? If not, what's the recommended class to use? We haven't had any problems using the victor class with it at all.