Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Permanent Magnet Synchronous Motor drive
Hello all

I'm trying to drive a PMSM rotary stage, but the open loop test fails.

The motor is an Aerotech Motor Type: S-180-69-A
- Rated Speed: 500 rpm
- Inductance 1.7mH
- Resistance 4.4Ohm
- 18 poles (9 pairs)
- Continuous Current Stall: 5.1 Apk.

The encoder is a Tonic Renishaw 23.600 Line wave with an x10.000 digital interface which gives 236.000.000 counts/rev.

I have been following step-by-step the Manual Brushless setup of the PowerBrick LV User Manual.

For while I could successfully do:
- current loop step (please see attachment)
- setup and read the encoder. (I manually turned 360° the motor and I could see the 236.000.000 counts on Motor[].ActPos)
- Stepper Phasing (After the Stepper phasing the Motor[].PhaseFound = True)
- Hall phasing

Even with the steps above I can't the see sawtooth expected wave (please see attachment the open loop test result). It seems the motor locks up to a phase.

I have tried all the manuals troubleshooting tips, but I can't see the sawtooth anyway.

The Motor[].PhasePosSf is configured as below

GLOBAL NoOfPolePairsMtr1 = 9; // Motor1 Number of Pole Pairs – User Input
GLOBAL CountsPerRevolutionMtr1 = 236000000; // Motor1 Encoder counts per Revolution - User input

Motor[1].pPhaseEnc = PowerBrick[0].Chan[0].PhaseCapt.a
Motor[1].PhaseEncLeftshift = 0
Motor[1].PhaseEncRightshift = 0
Motor[1].PhasePosSf = 2048 * NoOfPolePairsMtr1 / (256 * CountsPerRevolutionMtr1)

Attached is all the project files and the scripts used (.pmh files, StepperPhasingPLC, HallPhasingPLC, etc.)

What may am doing wrong?

Thanks in advance

Attached Files Image(s)

.zip   DCM Brushless 03 december (Size: 264.52 KB / Downloads: 1)
I think the cause of the problem is the high encoder resolution.

The encoder has 236.000.000 counts/rev, it means that the PowerBrick[0].Chan[0].ServoCapt will overflow a lot of time during the operation.

PowerBrick[0].Chan[0].ServoCapt has 256 times the encoder resolution, i.e., 236.000.000*256 = 60416000000 counts/rev! Thus, 32 bits aren't enough (log2(60416000000) = 35.8), so I can see many overflows during the commutation.

Plotting the Motor[].PhasePos I could see just 0 and 2048 (saturated values).

How can I handle this?

I think the first limitation you will hit is the frequency limit of the differential line receivers. They are rated to 10 MHz signal cycle input (they usually can go a little higher than this, but not robustly). With a "times-4" decode, this is a limit of 40 MHz count rate.

Also, the ASIC must be set up to sample the resulting signals at a high enough frequency to detect all of the edges that pass through the receivers. At most, one edge per sample cycle is permitted.

At the default sampling frequency of 3.125 MHz, you are limited to this count frequency (with perfect signals!), so about 750 kHz signal frequency. You should set PowerBrick[i].EncClockDiv to 0 so the sampling frequency is 100 MHz.

With the 40 MHz count rate limitation of the receivers, your speed limitation is:

4x10^7 [cts/sec] / 2.36x10^8 [cts/rev] = 0.17 [rev/sec] = 10 [rev/min]

You will not be able to move significantly faster than this, and it looks to be easy for an open-loop test to cause higher speeds than this.

PMAC software can handle the rollover of the encoder counter as long as less than half the range of the counter register is changed in a single sample cycle. With 24 bits of full counts in the 32 bit register, the range is 16M counts, so you are limited to 8M counts in a single sample cycle. But with sample rates above a kHz, this is many billions of counts per second, which the hardware cannot support.

Most people who want resolution this high use a serial numeric data format from the encoder (even if incremental) to get around the hardware frequency limitations. Do you have this interface format available?
Hi @curtwilson

Thank for your answer, it was really helpful

Now I can drive the brushless.
0. I set the PowerBrick[i].EncClockDiv = 0
1. Skipped the open loop test
2. Did a Manual Phasing with IbBias
3. Finally, I tuned the servo with very low gains due to high encoder resolution

PMAC software is handling the rollover of the encoder counter very well, I don't see any problem in commutation as I expected before.

At this time, I'm trying to fine tune the motor

With an x1.000 interpolation @4MHz digital encoder interface I could achieve 2 counts (0.26 urad - peak to peak) in-position stability
But with an x10.000 interpolation @50MHz digital encoder interface the max in-position stability I could achieve was 50 counts (6.7 urad - peak to peak) in-position stability, with the higher interpolation the expected in-position stability is 0.026 urad.

Do you think the higher encoder clock frequency (which the hardware doesn't sample robustly) is causing this behavior?
When you are trying to hold position at zero desired velocity, I don't think you will be getting a high-frequency signal that the ASIC sampling cannot handle.

If the sampling limitations cause an error, the PowerBrick[i].Chan[j].CountError bit will be set. This means that there is an unrecoverable position error from the decoding (from two signal edges -- real or noise -- in the same sample cycle).

In general, you should not expect a 10x increase in position resolution to result in a 10x improvement in position stability. However, with good feedback and tuning, it should be somewhat better, and it should not be worse.

(I think your math is off on the x10K interpolation. It looks like 0.67urad ptp.)

When you increase your resolution by a factor of 10 -- from x1K to x10K -- you should first reduce your Kp and Kvfb by a factor of 10 to see if you get equivalent physical performance. Then, in theory, you should be able to raise these gains somewhat to get tighter control.

If you do not get the same physical performance with 10x increase in resolution and 10x reduction in gains, I would be concerned about the quality of your feedback signal. I emphasize again that the digital quadrature signal output from encoders like these comes from a feedback loop in the encoder trying to track the value of the sine and cosine signals. I worry about its ability to represent the true position as it dithers back and forth about a position, and it may be that the higher interpolation setting is worse.

Forum Jump:

Users browsing this thread: 1 Guest(s)