Fast spinning motors.

[nyagic]

Think of the fastest spinning motor you have heard of... Then, how fast does the control loop need to read the position angle in order to close the feedback loop, and of course, control the motor?

It would help if you tell me the application/market where these things happen...

The fastest I heard is 100 Ksps... More?

Much appreciated...

 

[itsmoked]

Well in the nearby active post they are talking 36,000rpm.

Real rough approximation would be 10X that for even the most basic control/revolution. 360,000points-p-m = 6000p-p-s

Somewhere around 6kHz. This is not the same as what a VFD for a 36,000RPM motor would require.

You didn't say what kind of motor...

 

[coconutalley]

If I recalled correctly, from my digital control course, if you are using digital controller, the sampling inner loop [usually current] should be 20-30X of the natural frequency of the plant [motor]. Remember though that it is not simply multiplying 30X shaft speed. It's really the electrical speed, e.g. if motor has 4 poles then it 4xrevx30. For 36kx4x30 = 4.3 Msps.
I have come across customers wanting 50k rpm. But, this would not be a motor with physical bearings.

 

[cswilson]

From my experience with closed-loop control of very high-speed motors (up to 120 krpm) in applications like flywheels:

First, you need to realize that different tasks can and should be done at different update rates. The phase commutation and digital current loop should be updated a minimum of 6 times per electrical cycle of the motor for a 3-phase motor (a 4-pole motor has 2 electrical cycles per mechanical revolution). In the lab, I have generally "stalled out" at about 4.5 samples per electrical cycle, so I think 6x is a good rule of thumb. If using PWM to modulate your bus power, your PWM frequency must be a minimum of 3x your maximum electrical-cycle frequency (you get to make 2 decisions per PWM cycle -- when to turn it on, and when to turn it off).

To get close to these limits, you will need advanced control techniques like Park/Clarke transforms, and delay compensation advance algorithms.

Velocity and possibly position loops, which determine the torque (current magnitude) commands, can be closed at significantly lower update rates. With properly designed algorithms, these loops do not "see" the AC nature of the phase waveforms, so their update rate is determined more by physical bandwidth requirements.

So, for 36 krpm (600 rps) on a 4-pole motor, your electrical frequency is 1200 Hz, so you will need at least a 7200 Hz commutation/current-loop update rate.

For 120 krpm (2 krps) on a 2-pole motor, your electrical frequency is 2 kHz, so you will need at least a 12 kHz update rate for these algorithms.

Curt Wilson

 

[coconutalley]

Thanks CSWILSON, for the corrections. Electrical speed = Mechanical speed x 2 pole pairs. Also, really goofed on the rpm vs rps. It was late...
Good point: The sampling rate depends on what one is trying to accomplish. If one is trying to control speed down the motor response [very fine resolution like holding tight tolerance on speed] then you need higher sampling rates because the control loop needs the highest bandwidth it can get. Otherwise, the control would be too slow and the response sluggish. Also, too slow a loop will add phase lag which can cause torque ripple and other issues.

I should state a dislaimer for future postings: my responses, suggestions, & advice, are my opinions which are offered freely and yes they might be wrong, and I am not responsible for any damages caused as result of following my suggestions or advice. The reader is adviced to double check any suggestions by getting second opinions, running simulations, and checking against sound princples, before actually carrying out suggestions.

 

[RalphChristie]

See faq731-376

point no. 14:

Members of the Eng-Tips.com community who may respond to your questions assume no liability, and are only offering you their opinions during discussions on the fora. As an engineering professional yourself, you are responsible for all final engineering work and calculations, not anyone else.

 

[nyagic]

Hi all. Thank you for your responses and disclaimers ) It is appreciated.

I need to clarify something too. I don't care about the motor type; I am only interested in how fast one needs to read the POSITION (using, say resolver) of a very fast moving motor. I don't even care what they want to cotrol - speed or position itself.

However, I have heard that the folks who are interested in position typically deal with slow spinning motors. On the other hand, the folks who control speedy motors like to read the position at least 10 times faster than the angular speed / bandwidth and consequently are interested in calculating the velocity; if the motor spins at 1000 rps, then they get the position at 20Ksps.

So, regardless of the application, or control objective (position or velocity) I need to know how OFTEN people want to read that resolver.

 

[cswilson]

nyagic:

To clarify my above post, for the purpose of commutation of a brushless motor, you will need to sample the rotor position at least 6 times per electrical cycle of the motor. You need to do this so you can orient the stator current properly with respect to the rotor magnetic field in order to create torque, and you must do this regardless of whether you are closing position and/or velocity loops. That is, even if you applied an "open-loop" torque (current magnitude) command to the motor, closing no position or velocity loops, you would need to sample the rotor position at this frequency.

Angular speed and bandwidth are really completely unrelated here, so you are really muddying the waters if you use them interchangeably as you just have. In the example I just gave of the open-loop torque command, you could have very high angular speed, but very low (or even no) closed-loop bandwidth.

As I said before, the required sample rate for closing position/velocity loops is quite different (and usually lower) than that for the commutation. Ten to twenty times the desired closed-loop bandwidth is a good rule of thumb, but you most certainly do not need 1000 Hz closed-loop bandwidth on a position or velocity loop to spin a motor at 1000 rps, to use your example. A system of this type can often work well with a 50 Hz velocity bandwidth and even lower position bandwidth (if any).

Oh, and don't try to use a resolver for a very high-speed application. It won't keep up due to the inherent limitations of the excitation frequency and the conversion electronics. Optical encoders can keep up better if they are physically up to the high speeds. At the highest speeds, usually some sort of hall-effect magnetic pickup is used.

Curt Wilson

 

[alexit]

On some of our products we run 256 ppr magnetic encoders up to 42,000rpm (1400Hz 4-pole motors) this is a closed speed/position control loop (quadrature & z-flag) the speed feedback signals are up to 720kHz but we have to sample >1.4MHz to get any useful control. When we switch the system to position control we keep the same sampling for noise rejection.

 

[nyagic]

Alex, thanks for the info. What is 720kHz frequency? Is that how fast the AquadB signals are coming at you?

 

[alexit]

Yes, A/B quadrature is ~720kHz at max speed.

 

[nyagic]

Alex, what do you use to decode - an encoder? Where does the 1.4Mhz come into play?

 

[cswilson]

nyagic:

The receiving hardware circuitry for the quadrature encoder must sample the A & B inputs fast enough so that there is only one quadrature edge per sample at most. In alexit's systems, there can be up to 720k quadrature edges per second (the quadrature waveform signals are up to 180 kHz).

If everything were perfect, your digital clock signal for sampling these inputs could be as low as this frequency -- 720 kHz in this example. But of course, things are not perfect, so you need a margin of safety. I generally recommend driving the clock at at least 125% of the maximum edge frequency for reasonable-quality input signals (900 kHz in this case); alexit wants 200%, hence 1.4 MHz.

Keep in mind that this is just a hardware clock signal to drive the encoder sampling, decoding, and counting circuitry. No software action is required at this frequency. At the much lower update frequencies of the phase commutation and servo loop, the clocks would latch the encoder counter values and interrupt the processor to take the appropriate action based on the latched position.

 

[alexit]

cswilson, you explain better than I could, thank you!