This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PGA411-Q1: Resolver Behavior

Part Number: PGA411-Q1

Hi Team,

My customer is doing some failure-mode tests with their main board that uses the PGA411-Q1 resolver, and they have found some behavior that I'd like to confirm with you. First of all, they have the SPI interface to the resolver (which is used for configuration at start-up), but they mostly rely on the encoder A/B output signals to consume data from the resolver; they only use SPI for checking faults.

Case 1: Initialize the resolver via SPI when the input sin/cos signals are not valid (both are at ground).

- The resolver reads that as garbage values (very high, unstable RPM values). We’ve verified DEV_STAT5 and DEV_STAT6, and we see the corresponding garbage values.

- Turning on the motor controller after we start reading garbage values does NOT make the RPM values reasonable. We've looked at the signals at the scope, and the sin/cos input signals look fine; however, my guess is that because we initialized the resolver with invalid inputs, somehow it is not able to parse valid inputs later.

Case 2: Initialize the resolver via SPI when the input sin/cos signals are valid.

- In this case we read correct encoder deltas and RPM values.

- Turning off the motor controller (and thus when sin/cos are valid), the resolver starts reading garbage values (very high, unstable RPM). Similarly, the DEV_STAT5 and DEV_STAT6 register show the garbage values.

-  Turning the motor controller back on sometimes makes the readings stable again, sometimes it doesn’t. We could not find a correlation between when the readings stabilize and anything else.

With this, we have a few questions:

1. Is there anything we can do about the initialization concern? They can guarantee that the resolver is initialized when the input signals are valid, but it'd be nice if we could avoid this behavior.

2. Can we avoid garbage outputs in the failure mode of sin/cos going to ground? This is the most likely failure of the signal.

3. After a motor controller power loss, how can I re-stabilize the output? Do I have to re-initialize the resolver? Any idea why it restores values sometimes, but sometimes it doesn’t?

Thanks,
Mitchell

  • If both SIN/COS are at ground, then one of the AFE diagnostics should identify a fault condition and turn off the exciter amplifier and tracking loop. Toggling FAULTRES will clear the error and allow the tracking loop to start fresh.

    Additionally, the FLOOPE fault should catch this condition if the limits are tightened slightly. Set LPETHH and LPETHL to 10b, and set the AMODE pin high so that the TRDHL deglitch setting is set between 2ms to 8ms instead of from 90ms to 180ms.

    If FAULTRES is continuously held low (ignoring all faults), or if the ENINFAULT bit is set (telling the PGA411 to keep running if an AFE fault occurs), then the issue you outlined above will occur.

    There is no way to guarantee tracking loop recovery after inputting garbage data without resetting the tracking loop. Fortunately, there is an easy way to manually reset the tacking loop without reinitializing the entire PGA411. The LPEN bit in the DEV_CONTROL3 register can be used to disable/enable the tracking loop.
  • Thanks Clancy!

    We were able to make the unit work by resetting LPEN if there was a fault (due to motor power loss/invalid cos/sin). I really appreciate the detailed feedback you provided.

    Thanks,
    Mitchell