[Mariss Freimanis]

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

[cyclestart]

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.

[Mariss Freimanis]

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

[morestuff]

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

[Mariss Freimanis]

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

[H500]

That's an interesting project. Close loop stepper control looks quite a bit more difficult than I thought it would be at first glance.

[Mariss Freimanis]

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

[H500]

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. =)

[Mariss Freimanis]

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

[H500]

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?

[H500]

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.

[Mariss Freimanis]

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

[thseng]

Mariss, based on your 5-microstep CPLD tutorial, I think I see how you're generating the sine cosine terms and performing the analog multiplications.

Leave it to you to put state of the art DSP's to shame with a pair of tri-state CMOS outputs, a couple of comparators and handful of passives.

[Mariss Freimanis]

tseng,

Thanks for the kind words. My original working prototype used digital potentiometers (SPI interface) for 4-quadrant analog multiplication. Inverted and univerted analog signals were applied to the ends of the "potentiometer" and the wiper was multiplier output (0 to +/-1 * analog voltage).

Although it gave beautiful results and performed flawlessly, the drawback was 8 multiplications by sine and cosine are necessary to perform the Park transform and its inverse. At over a $1 apiece (1K+ qty), $8 becomes a show-stopper.

A much more attractive ($0.04 per "multiplier") solution was found by using analog multiplexers instead. Another breakthrough was replacing the PWM modulation scheme used in the logic-starved CPLD with a more complex modulation method that can only be afforded if FPGAs are used. In essence, the PWM carrier frequency is CLK freq / 2^n where n is the number of bits resolution required. The new scheme has an effective carrier frequency of CLK freq / 2. This means a single-pole low-pass filter can be used yet easily keep the analog signal bandwidth comfortably above 20kHz.

The new scheme also gives beautiful results and performs flawlessly. It is a $0.32 solution for what was an $8 one. This makes me happy. :-)

Mariss

[thseng]

I view most of your posts as a cross between a textbook, an open-ended word problem and a crime scene. Your should edit your sig to say “… and from this point the solution is trivial and should be obvious to a skilled practitioner in the field. The working out of the remaining details has been left as an exercise to the student.”

I’m guessing that you add an n-bit pwm duty cycle to an n-bit register once per clk. If it overflows you drive the output high until the next clk. At 50% it overflows every other clk.

I was actually thinking analog switches would be the way I would try it but I assumed you had found a way to do it with a green LED or something.

In any case, you’ve motivated me to gain some intuitive understanding of FOC. It’s nothing more than vector rotation (or reference frame rotation, depending on how you think about it). The beauty is that it reduces all the frantic micro-managing of trying to get the motor currents to track reference wave forms into two big knobs labeled applied voltage and phase lead.

I do wonder what happens when speed increases and the current waveforms stop looking like sine waves.

[Mariss Freimanis]

1) Your guess is correct; The resulting carry output gives the most even distribution of the number of "0's" and "1's" possible while a true PWM output has the worst distribution possible. Cursory examination shows the filtered PWM output has a worst case (50% duty cycle) ripple voltage 2^n / 4 greater than the accumulator overflow method.

2) The Park transform returns stationary flux and torque vectors (D,Q). The flux vector is forced to zero via PI filtering at low speeds. As speed increases, the flux vector is intentionally unbalanced from the zero value. This is called field-weakening and it allows the motor to reach really high speeds.

This action can be understood when you consider inductive current vs. voltage phase lag increases from 0 degrees to -90 degrees above some speed. Forcing the flux vector away from a non-zero value compensates for this inductive phase lag.

Mariss

[thseng]

Ok, field weakening is just reducing the current vector phase lead to something less than 90 degrees ahead of the rotor. This reduces the effect of back-emf and allows you to go faster than what would be the equivalent of the "no-load" speed if it were a PMDC brush motor. But with no available torque to speak of.

Putting that aside for the moment and leaving the Id setpoint at zero, I *think* the integral terms should drive the Vq and Vd voltage commands to the appropriate additional phase lead to try to keep the current vector at 90 degrees to the rotor without any outside correction needed.

[H500]

Mariss,

Analog FOC. That's quite ingenious. I hope you have a patent on it, so that I don't feel guilty about discussing what could be your trade secrets.

Your posts are always intriguing. If I were to guess, a multiplier can be realized with analog switches by using a weighted resistor network to scale the analog current with the digital sine/cosine value.

Something I don't understand is why a DSP is not fast enough for FOC. The Park and inverse transform takes 8 multiplications. On a 40 mips DSP, that would only take .2 uS total. On my open loop drive, running a very sloppy PID code to control the phase currents takes 6 uS.

An eight microstep equivalent drive spinning at 3000 rpm would step every 12.5 uS. If the FOC PID calculations were done at each step, it seems like there would be plenty of cycles available. Yet, I don't see a single low cost FOC stepper drive out there. I must be missing something.

[Mariss Freimanis]

H500,

What a shame. I spent 45 minutes writing a reply, FOC code and all, when CNCzone's robot forum control decided to dump my work because it couldn't handle the TAB key. I'm not going to re-write it. :-(

All that's left is to comment on ideas. Ideas are a dime to the dozen to me. Some people never have any, some have one or two while others are lucky and they sprout every day.

Patenting an idea is good if you only get a few. Ideas are a rare gift to have so you may want to protect yourself with a patent if your ideas are few and far between.

Unfortunately patents are expensive and time consuming; we have on retainer two law firms (general and intellectual property). I like to keep my distance from both as much as possible because time spent there is non-productive.

Ideas are also volatile; they evaporate with time. No one is interested today how I used a CD4028 IC to generate a sin/cos look-up table today; technology moves on and leaves outdated ideas in its wake.

What we employ for protection is proprietary art. We don't reveal how we do what we do. If you originate an idea, you probably have mastery of it before anyone else does. By the time your idea diffuses into common knowledge, you have moved on to a better, newer idea.

The weakness of this scheme is when a predator patents your idea out from under you. It happened to me once over 20 years ago and I was outraged. Someone stole my idea and I couldn't use it myself unless I paid royalties to the predator.

The workaround has been to use CNCzone and other forums to give us protection. To be granted, a patent requires an idea being patented has no prior art. That's why you can't patent the wheel.

I reveal enough of an idea to establish it as prior art. I document when the idea was put into the public domain. This serves as protection against patent infringement claims.

We rebuffed two claims in the last 20 years. That last one was particularly sweet because it was against how we dealt with mid-band resonance. The granted patent was withdrawn after we showed how our method was prior art and how it nullified that patent.

Mariss

[H500]

H500,
What a shame. I spent 45 minutes writing a reply, FOC code and all, when CNCzone's robot forum control decided to dump my work because it couldn't handle the TAB key. I'm not going to re-write it. :-(

=( That is too bad. It happened to me before also. I would really be interested in your perspective. The calculations seems straight forward, but I've seen paper after paper on the topic without any viable products resulting. Perhaps I will need to try implementing the on my board just to satisfy my curiosity.

I just noticed that NXP has a dual core 200 mips Cortex M4 processor with DSP capabilities and a floating point coprocessor. for about $10 in singles. Cheap processors are getting quite powerful.