Jaguar "Whiplash"

[Ligerbytes]

Our team has had issues with fried Jaguars in the past, mostly from drivers going from full forward to reverse too quickly. Theoretically, the Jags should cut off automatically when there's too much load on the circuit, but they don't.

Have other teams dealt with this? Does anyone have precise numbers (or a spec sheet somewhere with numbers) for how much "whiplash" it takes to kill a Jag? (eg, signal changing faster than 500%/sec or whatever)

We can easily program around this, using the same kind of trick everyone used for traction control for Lunacy, but we need a max-acceleration parameter first because experimenting to figure it out could get expensive...

Thanks,
Team 2877

[The Lucas]

Can't say I have ever experienced that but I realize it can happen. I haven't had a Jag burnout since 09 Grey Jags with the faulty gate driver (U6).

The Jaguars have a voltage ramp feature built into their firmware. You can set it via the CAN bus using CANJaguar::SetVoltageRampRate(double rampRate) in C++ (I assume there are similar VIs for LV). I have never used it personally but like most things that require tuning, I recommend you set the rate using a throttle on the joystick. That way you can drive around and adjust the throttle (start with the slowest rate to save your Jags) till you find a setting that works for your drivers. Then you can hard code that rate.

Of course if you don't like the built in voltage ramp or don't use CAN, you can always code one yourself.

[Al Skierkiewicz]

Liger,
It is possible that the jag isn't fried in the strict sense. You may have developed so much heat in the current sense resistor that it unsoldered itself. There should be no harm in going full forward to full reverse unless there is so much slop in your drivetrain that the motors are repeatedly in stall during the transition.

[Zme]

as i understand it they won't trip out for "whiplash" specifically but rather as you said for load on the circuit.
from the FAQ pdf for the the jaguars provided here :http://www.luminarymicro.com/index.php?option=com_remository&func=download&id=1 361&chk=4e8cfc18e4989e83fa05e3cd5f167f70&Itemid=59 1

The Jaguar modules have a self-protection feature that do not allow excessive current to be drawn.
This feature protects both the motor and the motor controller from damage. The Jaguar module
typically provides up to 40 A of continuous current to a heavily loaded motor. However, it is capable
of providing much higher currents, but for shorter periods of time. Jaguar provides 60 A for up to
two seconds and provides 100 A for approximately 0.2 s. The 2011 version of the Jaguar firmware
provides a unique LED error code when this self-protection feature is tripped; the LEDs flash an
repeating slow red then yellow sequence.

[Al Skierkiewicz]

Zme,
When the Jag overcurrent protect feature cuts in, the LED comes on indicating a fault and all output is inhibited for about 3.5 seconds. If the fault is removed then the Jag resumes normal operation.

[Zme]

My understanding was that they were looking for numbers on what the jaguar could withstand with out causing issues, faulting out like it would for a current fault would be an issue, but i do not believe it is possible to fry a jag from flipping directions like is being described, but then stranger things have happened.

Theoretically, the Jags should cut off automatically when there's too much load on the circuit, but they don't.

seems to indicate they are looking for the current fault to occur and to find out when it will occur, as i understood the question this was what was being asked for, if not then perhaps some clarification is in order.

[Racer26]

In 2009, many Jags toasted the U6 gate driver chip from high-speed transitions from full-reverse to full-forward, usually resulting in a Jag that could no longer provide forward direction output.

If I'm understanding correctly, this problem has been subsequently fixed (1075 toasted 3-5 jags in 2009, 1 in 2010 IIRC) at the hardware level, but also, many teams have put in code restricting the maximum rate of change so that this doesnt happen.

[Zme]

alright, this makes much more sense, i think we may have had one fail like this but never really bothered explaining why... is there a specific fault code/blink that this generates?

[Al Skierkiewicz]

When TI took over Luminary Micro, they dropped the use of Fairchild components and started using other devices. The black Jag uses an Allegro gate driver.

[s1900ahon]

Originally Posted by Zme

alright, this makes much more sense, i think we may have had one fail like this but never really bothered explaining why... is there a specific fault code/blink that this generates?

Yes, but the blink code depends on the firmware revision of the Jaguar in question.

In previous year's Jaguars, the over current fault was bundled into the standard fault and is slow blinking red. With revision 92 of the Jaguar firmware, this was changed to a slow alternating red/yellow blink (all other fault conditions generating the original slow red blink still). You can update older Jaguars to v92 using CAN.

[Zme]

for the over current fault yes but i was referring to the behavior described by 1075guy, is there a way to diagnose this as being the problem or is it simply a "it doesn't work right"

[Al Skierkiewicz]

Zme,
Not sure what you are asking. The gate driver failures in early production models did not show a fault indicator. They would either not drive in one direction or not drive at all. If the power supply was not affected by the failure, (some were) then the internals thought everything was fine. When Jags were first introduced, CAN was not allowed. So there was no way to get any info back from the device.

Scott,
Does the v92 firmware change the delay time for an overcurrent fault? That would be a handy change. Show the LED fault but let the Jag go back to output enable.

[Team2944]

Hey so I don't know if this will be any help, but if the issue actually is whiplash, I've made a quick little VI that when put between a joystick output and a drive input, will change the motor speed value at a constant rate in the direction of the joystick value. Since the rate of change is dependant on the time taken to complete the loop it's in, I've added another input kind of as a scaler. 2-4 seems to work nicely.