LinkBack URL
About LinkBacks
Jon Elson of Pico Systems did some testing and mentioned it on the emc mailing list.
Link:
Gmane Loom
It may not be the info you're trying to remember but hope it helps in some way.
| | |
Hi,
I recall a post from someone who had done tests on the AMT102 encoder and reported processor time delays in the quadrature signals coming the encoder.
A failing on my part was at the time it didn't have relevance to what I was doing so I neglected to note the name of author or investigate his findings. My error then has now taken on an unexpected urgency now and I would dearly love to revisit what he found.
Let me give a little bit of background for what prompts this request. This is kind of technical so feel free to tune out here.
I have pursued designing a step-motor servo for over 12 years. All of my attempts from all different directions over the years met with failure. It also puzzled why no one else had come up with one.
A successful solution is one that uses the Clark-Park and inverse Clark-Park transform equations. In literature these transforms are universally solved using DSP-enabled microprocessors for brushless DC motors.
Brushless-DC motors, properly called PSMS (permanent magnet synchronous motors) typically have 6 poles. The microprocessor running them can barely execute the firmware in 50 microseconds (20,000 times a second).
A step motor, (also a PMSM motor) has 50 poles instead of 6 poles. The math transforms would have to execute over 8 times faster (50 poles / 6 poles). This is beyond the ability of any microprocessor to handle.
Of the transforms, the Clark transform and its inverse is more trivial. It converts a rotating 3-phase vector into an orthogonal rotating 2-phase vector. A step motor is an orthogonal 2-phase motor to begin with so the Clarke transform and its inverse can be discarded.
The Park transform converts a rotating 2-phase vector to a stationary reference. The servo PID magic is applied to stationary vector and the inverse Park transform restores it to a rotating vector to move the motor.
The problem is the Park transform requires requires 4 multiplications by sine and cosine and its inverse requires 4 more multiplications by sine and cosine for a total of 8. At 6.000 RPM, these calculations and the sum of the products as well as 2 proportional-integral calculations have to be done in 5 microseconds. This cannot be done even with a fast MCU.
I just found a way around this problem and then some and it doesn't involve an MCU at all. It works so well I destroyed some perfectly fine NEMA 23 step motors well past 18,000 RPM (the motor ball-bearings failed). The Park transform and its inverse is solved using an analog circuit technique.
Regards to the encoder and my original request. The Park transform yields intermediary results in the form of D and Q signal components. Both decompositions were expected to be near constant DC volt values yet they were not. There was considerable modulation on these signals indicating there was a phase delay from encoder signal.
This calls into question the signal phase delay integrity from the encoder. I'm hoping the author of the AMT102 encoder study will respond. Otherwise I will have to revert to using an optical encoder.
Mariss
Jon Elson of Pico Systems did some testing and mentioned it on the emc mailing list.
Link:
Gmane Loom
It may not be the info you're trying to remember but hope it helps in some way.
Anyone who says "It only goes together one way" has no imagination.
cyclestart,
Thanks! That is what I was looking for.
The attached jpeg shows a repetitive, once per revolution waveform on vQ that shouldn't be there. This makes me think the CUI encoder is the source of this artifact.
Mariss
The issue with the CUI encoders is the quality of the
internal phase lock loop that tries to generate quadrature
pulses that represent the result of the sine/cosine signals
provided by their internal capacitive sensors being
interpolated to provide sufficient resolution. This PLL
has issues with acceleration causing lag and overshoot
in the quadrature that it outputs. The higher the
resolution setting, the worse the problem. Of course
the problem is less if acceleration is low. Moderate
performance servo motors can usually get by with
them, but low inertia and high performance servos
may have problems.
Jon Elson of Pico Systems did a good bit of testing
with small servos running on an EMC controlled system.
The discussion that this caused can be found here in
the archives of the EMC-developers discussion list. See:
http://thread.gmane.org/gmane.linux....emc.devel/4499
He has used HAL Scope (the internal "scope" in the EMC
software) to capture simultaneous feedback from AMT
encoders and traditional optical encoders mounted on
the same motor.
Regards,
Steve Stallings
www.PMDX.com
Steve,
I'll be sure to thank Jon for discovering this CUI encoder behavior. The attached jpeg shows the same test setup but the motor is being commanded to run in the opposite direction. Ignore the 366Hz ripple on the yellow trace; I didn't have a summing node properly nulled.
What's interesting is the yellow trace waveforms are markedly different depending on the direction of rotation; if the motor was the cause of this then I would have expected to see a mirror image of the previous waveform.
The CUI encoder was set to 1,000 lines resolution (4,000 counts per rev). Monday I will replace the CUI encoder with an optical encoder. It will be interesting to see if the waveform flattens to an expected single minima and maxima per revolution.
Note the FOC control causes the 3.5A motor winding to draw only 130mA RMS (green trace) at no-load.
Mariss
That's an interesting project. Close loop stepper control looks quite a bit more difficult than I thought it would be at first glance.
What's also interesting is when I realized there is really no fundamental difference between a brushless DC motor (BLDC) and a step motor. Both are permanent magnet synchronous motors (PMSM).
Their only differences are pole-count and the number of phases. Step motors are 50-pole 2-phase motors while BLDC motors are typically 6-pole 3-phase motors.
There is a lot of literature on controlling 3-phase PMSM motors. The most popular control method is field oriented control (FOC) using the Clarke-Park transforms.
The Clarke transform converts a 3-axis current vector to a 2-axis current vector. The Clark transform isn't needed because a step motor's currents are already 2-axis vectors.
The Park transform converts the rotating orthogonal 2-axis vector to a stationary vector. The math is:
Id = Ia (cos theta) + Ib (sin theta)
Iq = Ib (cos theta) - Ia (sin theta)
and:
Vq = Kp (Iq + REFq) + integral Ki (Iq + REFq)
Vd = Kp (Id + REFd) + integral Ki (Id + REFd)
Inverse Park math:
Va = Vd (cos theta) - Vq (sin theta)
Vb = Vd (sin theta) + Vq (cos theta)
Microchip has a excellent application note AN1078 that summarizes the FOC math.
The FOC math computations are normally done by an MCU at a 20kHz repetition rate. This is fine for a BLDC motor because the low pole-count allows for a high RPM at a 20kHz sampling rate. To work with a step motor which has about 8 times more poles, the sampling rate would have to be 8 times higher for the same RPM. In effect, the math would have to be computed in 6uS instead of 50uS. This is beyond what is practical with an MCU.
My approach gets around this sampling problem entirely and doesn't use an MCU for these calculations.
Mariss
Thanks for the reference. I will take a look at it.
Not knowing any better, my initial approach to a step servo would be to scale the set point current in response to the positional error. But if it was that easy, it would not have taken you years to perfect. =)
H500,
When run with an FOC drive, a step servo (and a BLDC servo) takes on attributes of a true servo:
1) Motor current is proportional to torque load. A normal step motor drive running a 3A motor at 60 RPM from 24VDC at no load put 11 Watts into the motor. The FOC servo put only 0.5 Watts into the same motor at no-load at 60 RPM and the no-load phase current was less than 125mA. The only torque demand from the motor at no-load is the ever-present detent torque. Detent torque is listed as 3% of the motor's holding torque, and it requires 0.48 Watts to overcome that torque at 60 RPM. Theory meshes with experimental measurements very well here.
The Park transform generates two intermediate vector terms; iQ and iD. iQ is the torque producing vector and iD is the non-productive flux vector. The FOC algorithm nulls the iD vector to zero at low speeds while a step motor drive (open-loop) has this vector at a maximum (near zero iQ component, near maximum iD component). Big "thumbs-up" for the FOC algorithm.
2) An open-loop step motor drive excites the motor into various vibration producing resonance modes. The open-loop drive requires careful design to mitigate this bad behavior; 3rd harmonic compensation to limit low-speed resonance, 2nd order damping for mid-band resonance.
An FOC closed-loop servodriven step motor exhibits no resonant behavior at all because the motor response is entirely bound the encoder. The closed-loop's damping factor completely suppresses all native resonances and the motor is utterly vibration free at all speeds.
3) Accuracy: An open-loop step motor drive accuracy is determined by motor characteristics; its cyclic error non-accumulative tolerance, inductive reactance phase lag and its angular position error versus restoring torque transfer function. The first is least significant because it accounts for +/- 0.09 degrees error. The second introduces a 1.8 degree lag error and the third introduces an additional 1.8 degrees angular error.
Simply put, a stopped or slowly moving open-loop motor has to be displaced from its position by +/-1.8 degrees to develop full torque. At high speeds (inductive phase lag), an unloaded motor lags 1.8 degrees behind where it should be and develops full torque when its 3.6 degrees behind.
A closed-loop motor develops full torque when it's displaced +/-0.09 degrees (using a 1,000-line encoder). The servoed motor's "stiffness" is much higher than for an open-loop drive.
4) Motor power. An-open-loop step motor has to have at least a 50% power reserve to insure reliable operation; one momentary overload event will stall the motor. A closed-loop drive is more forgiving; an momentary overload event will generate a following error which is then made up once the event passes.
5) Finally, why bother with a difficult step motor servo design when there are perfectly reliable BLDC servo designs available?
Step motors are high pole-count permanent magnet synchronous motors. They are high-torque, low RPM motors when compared to their low-torque, high RPM BLDC brethren.
On most mechanisms a BLDC motor has to be geared down to trade in unneeded RPM for badly needed torque. A step motor generates about 8 times more low-speed torque for the same frame size motor and often requires no gearing down at all. Gearing is expensive, adds to a mechanism's complexity and subtracts from its reliability.
Mariss
Close loop definitely have very desirable characteristics. The only drawback is the cost of the encoder. But the improved efficiency might allow the use of smaller motors to offset the cost.
When do you expect to have a commercial product ready?
Mariss,
Have you experimented with sensorless FOC? I see several write-ups describing deducing the rotor position from the back EMF. At low speeds, regular microstepping is used since there is no EMF. At higher speeds, the drive switches to FOC. The drive would lack the resolution of an encoder base system, but it's not needed for common applications. I think the option to not pay for an encoder would be very appealing.
I'm familiar with the literature regarding sensorless motor drives. Some of the techniques are very clever in implementation using Kalmann equation filters. Sensorless FOC is viable if your intent is to manufacture a PMSM (permanent magnet synchronous motor) speed control. It isn't a viable solution if the intent is to manufacture a PSMS servodrive.
Mariss
Posting Permissions
| | |
