How to control motor relative position/speed

Thread Starter

strantor

Joined Oct 3, 2010
6,782
I feel dumb, like this is something I should be answering, not asking, and on top of that I don't even trust myself to ask it properly. But I am stumped.

I have two 3ph motors controlled by VFDs. Both have encoders feeding back to the VFDs, and to a PLC high speed input card. The PLC controls the VFDs via analog output. I want "Motor B" to turn some ratio to "Motor A." Not sure how to word that, but note that I didn't say "some ratio of speed." It's more like some ratio of position, even though this is a speed control application.

Right now I have both motors in a speed control loop and it's not good enough. Let's say for example I want Motor A to spin 342RPM, and motor B should spin 88.5% as fast, or 302.67RPM. I can get nearly that level of performance, but nearly isn't good enough. If motor B instead spins 304 RPM, that's 88.89%, which is entirely different than 88.5%. I can tolerate periodic +/- speed errors but I can't tolerate a steady state error. It's cumulative error that's a problem for this process, so I need cumulative/totalized error correction. I need Motor B to "catch up" to where it's supposed to be relative to Motor A.

The way I envision it, motor A would be the master, running in a simple speed control mode, while motor B would be a slave, and operating in more of a position control mode. Or maybe Motor B is a hybrid speed/position control, with 90% of reference a constant and 10% a trim from calculated error.

I have an idea how I would go about this if I wanted both motors spinning the exact same speed, but they don't go the exact same speed. Half my brain says "it's still the exact same concept" but the other half just can't see it. If they were going the exact same speed, I would have Motor A add pulses to a register, and have Motor B subtract them, and the remainder is the error and the offset to add to the scaling for Motor B's analog output. But I can't make the ol noodle see how that works for motors that aren't going the same speed.

Any ideas?
 

MrChips

Joined Oct 2, 2009
30,711
I’m thinking AC grid power generators.
They must record the number of cycles. By the end of each day the total number of cycles must be an exact number.

(As an afterthought, since all generators connected to the grid must be in phase, there must be one master generator that regulates the cycle frequency and total number of cycles.)
 

LesJones

Joined Jan 8, 2017
4,174
Just controlling the frequency ratio of the two VFDs would not be enough as normal 3 phase motors are not synchronous they have some slip. (Which will vary with loading.) This sounds like creating an electronic leadscrew on a lathe. (For screwcutting.)
This is normally done with an encoder on the lathe spindle and a stepper motor driving the leadscrew. The stepping rate of the stepper motor is controlled by a phase locked loop synchronised with the pulses from the encoder on the lathe spindle. The ratio could be done by using counters but is normally implemented using a microcontroller. It should be possible to have a closed loop servo system to keep the encoder on the slave motor synchronised in the correct ratio with the master motor. There is a servo design which emulates a stepper motor using a PM DC motor with an encoder that would probably work if a DC motor could be used instead of the slave 3 phase motor. This is a link to this servo.

Les.
 

Sensacell

Joined Jun 19, 2012
3,432
You need to accumulate the total encoder counts of the master motor to create an absolute position, then scale this position by whatever ratio. This then becomes the position command for the slave motor. This must be constantly updated obviously.
The problem of register roll over must be solved, but that should not be too hard.
 

MaxHeadRoom

Joined Jul 18, 2013
28,617
In the CNC world I know it as 'Electronic Gearing' where one servo is slaved or geared off the encoder of another.
I would not want to attempt this in a VFD environment, at least not to any degree of accuracy.
The Motion cards i have used in the past are the Galil Motion products.
Induction motors would be very difficult to synchronise, at least with any accuracy.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
the dynamics of the application often afford a resolving component, suggesting that disclosure may help.
Reminds me of when an engineer struggled to pass an object between independently indexed conveyors. His routine, titled 'cruise control', based on accumulative error, worked well, given time to lock in. In practice, that time did not exist. Help. Observation led to bringing the stop phase to a known state, which then allowed the start phase to ramp up in unison.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
Just controlling the frequency ratio of the two VFDs would not be enough as normal 3 phase motors are not synchronous they have some slip. (Which will vary with loading.) This sounds like creating an electronic leadscrew on a lathe. (For screwcutting.)
Yes I am familiar with the ELS and that is a good analogy. You can think of it just like an ELS that is infinitely long so runs continuously in one direction, ramping up/down in speed as needed.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
In the CNC world I know it as 'Electronic Gearing' where one servo is slaved or geared off the encoder of another.
I would not want to attempt this in a VFD environment, at least not to any degree of accuracy.
The Motion cards i have used in the past are the Galil Motion products.
Induction motors would be very difficult to synchronise, at least with any accuracy.
Yes, electronic gearing, I need to write this from scratch in a PLC that does not have an electronic gearing FB and I can't picture what I would see if I looked up the skirt of an electronic gearing FB.

Agreed on the difficulty of synchronizing AC motors and if I were doing this again I would use a pair of 15kW servos. But the motors and drives are already paid for and installed, and thankfully the application is forgiving. It's a cabling machine, twisting wire wires into a cable, and this electronic gearing establishes the lay length of the cable twist. There's maybe 10-15ft between the gathering die and the twisting device, so as I said I can tolate a bit of fluctuations, as long it "catches up" in a reasonably brief time. It just can't run with steady state error or the lay length will be off.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
the dynamics of the application often afford a resolving component, suggesting that disclosure may help.
Reminds me of when an engineer struggled to pass an object between independently indexed conveyors. His routine, titled 'cruise control', based on accumulative error, worked well, given time to lock in. In practice, that time did not exist. Help. Observation led to bringing the stop phase to a known state, which then allowed the start phase to ramp up in unison.
Sorry that was over my head. Are you asking me to divulge the application? If so it's like the first piece if equipment shown in this video:
the two coordinated axes are the bobbin in the center and the cage ("flyer") that spins around the outside of it.
 

cmartinez

Joined Jan 17, 2007
8,219
This sounds pretty much like a PID application to me. If some degree of error is allowed, then I'd build a small controller circuit using an MCU in charge of counting the position steps of both motors at the same time, and then I'd assign a master and a follower motor. Based on that, I'd use one of the MCU's analog outputs so that it would either increase or decrease its voltage according to the difference between the encoder counters, and plug that output into the follower motor's VFD to make it either go faster or slower until it catches up.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
This sounds pretty much like a PID application to me. If some degree of error is allowed, then I'd build a small controller circuit using an MCU in charge of counting the position steps of both motors at the same time, and then I'd assign a master and a follower motor. Based on that, I'd use one of the MCU's analog outputs so that it would either increase or decrease its voltage according to the difference between the encoder counters, and plug that output into the follower motor's VFD to make it either go faster or slower until it catches up.
Agreed, PID is the next logical step, but I'm having trouble with step 1. In order to have a PID I need a reference, or process variable. What is that process variable? Speed? Angular position? How do I get it? The error term needs to be derived not from Motor B's own PID calculation, but from its error relative to Motor A. Motor A may have (will have) its own speed fluctuations, and Motor B needs to mimic them, within reason.
 

cmartinez

Joined Jan 17, 2007
8,219
Agreed, PID is the next logical step, but I'm having trouble with step 1. In order to have a PID I need a reference, or process variable. What is that process variable? Speed? Angular position? How do I get it? The error term needs to be derived not from Motor B's own PID calculation, but from its error relative to Motor A. Motor A may have (will have) its own speed fluctuations, and Motor B needs to mimic them, within reason.
As I said, the way I visualize it is keeping an accurate register of each motor's position at all times. And the easiest way to do that is to attach an incremental encoder to each motor. It's up to your application to determine the resolution needed for those encoders. The MCU would then keep track of both motor's positions in real time, and it would adjust the speed of the slave motor as needed.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
Sorry I realize I'm being dense here; trust that it's more frustrating for me than it is for you. I know the answer has probably been given more than once already but I can't see it. It's like a blind spot. I guess the point I am stumbling over is this:

As I said, the way I visualize it is keeping an accurate register of each motor's position at all times. And the easiest way to do that is to attach an incremental encoder to each motor. It's up to your application to determine the resolution needed for those encoders. The MCU would then keep track of both motor's positions in real time, and it would adjust the speed of the slave motor as needed.
My mind would be well equipped to process this suggestion if we were talking about a linear application, but it's a continous rotary application. The position will be resetting to zero every 360 degrees. I can't wrap my mind around how these positions would be tracked, and the error between them accumulated, when they're both perpetually resetting to zero, at different times and rates from each other.
 

cmartinez

Joined Jan 17, 2007
8,219
Sorry I realize I'm being dense here; trust that it's more frustrating for me than it is for you. I know the answer has probably been given more than once already but I can't see it. It's like a blind spot. I guess the point I am stumbling over is this:



My mind would be well equipped to process this suggestion if we were talking about a linear application, but it's a continous rotary application. The position will be resetting to zero every 360 degrees. I can't wrap my mind around how these positions would be tracked, and the error between them accumulated, when they're both perpetually resetting to zero, at different times and rates from each other.
I see... the way I'd track the position is by assigning an x-bit register to each motor. The size (in bytes) of those registers would have to be enough to account for the maximum positional difference possible between the motors. Said difference could easily be the size of several motor turns... no need to reset the positional counters every motor's revolution.

A simpler (but brute-force) approach would be to assign a positional register of, say, 8 bytes to each motor ... each register would therefore be able to count up to 18,446,744,073,709,551,616 encoder steps. Which should be enough to last an entire run of the machine before those registers are reset when production stops.
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
Ok I might have just had a glimpse past the blind spot. Maybe I could do this:

  • Motor A is master
  • Motor A encoder pulses are accumulated in a register that does not reset to zero every rev. If motor A were to run by itself, the register would eventually overflow.
  • Motor B pulses are multiplied (scaled up) by the desired ratio and the result is subtracted from the register
  • The remainder of this register is the error signal.
  • If perfect sync is achieved, this register should remain at or near zero value.
Since the scaling factor will be something like (ex) 1.1267 the register will either need to be configured as floating point or else multiplied integers. For example a value of 1,000 is added to the register for every one pulse of Motor A, and a value of 1127 is subtracted for every one pulse of Motor B.

Does that sound workable? Optimal? Any better suggestions?
 

Thread Starter

strantor

Joined Oct 3, 2010
6,782
I see... the way I'd track the position is by assigning an x-bit register to each motor. The size (in bytes) of those registers would have to be enough to account for the maximum positional difference possible between the motors. Said difference could easily be the size of several motor turns... no need to reset the positional counters every motor's revolution.
I might have just posted the same idea. Are you describing the same thing I did in post #16?
I see... the way I'd track the position is by assigning an x-bit register to each motor. The size (in bytes) of those registers would have to be enough to account for the maximum positional difference possible between the motors. Said difference could easily be the size of several motor turns... no need to reset the positional counters every motor's revolution.
I'm not sure I can do 8 bytes. At least not in a way that is natural to the PLC. The maximum tag size is 32 bits.
 

cmartinez

Joined Jan 17, 2007
8,219
Does that sound workable? Optimal? Any better suggestions?
Yes, it sounds perfectly workable. If your PLC or MCU or whatever you're planning to use has a problem with floating point operations, then you could use large integers and scale them in very few and quick instructions using Bresenham's algorithm

I might have just posted the same idea. Are you describing the same thing I did in post #16?
Yup... same thing alright.

I'm not sure I can do 8 bytes. At least not in a way that is natural to the PLC. The maximum tag size is 32 bits.
You could concatenate two 32 bit tags, incrementing the higher one when the lower one overflows, or decrement the lower one if the higher one underflows ... if it ever does.
 
Last edited:

LesJones

Joined Jan 8, 2017
4,174
I don' know the capabilities of a PLC so I don't know if you could implement this idea.
Each motor would have an encoder with the same number of pulses per rev.
From the 342 rpm motor we would divide the pulses by 200. From the other motor we would divide the pulses by 177. (The smallest integers to get a ratio of 88.5%) The outputs of the dividers would clock a counter. one would clock it up the other would clock it down. For example if we made this an 8 bit counter and initialised it to a value of 128 when the motor speeds were in the correct ratio it would would remain within 1 count of that value. If the speed ratio was wrong it would increase or decrease from the value of 128. The value of this counter would be the error signal with 128 being zero error. The value from this counter could be fed into a DAC and used to adjust the control voltage to the slave VFD.

Les.
 

MrChips

Joined Oct 2, 2009
30,711
I like the idea proposed by @LesJones.

Here is my modification using PLL concept.

Motor A -> encoder -> divide by 200
Motor B -> encoder -> divide by 177
Feed the two signals into the DATA and CLOCK of a D-type flip-flop.
D-type flip-flop -> low-pass filter -> error voltage output -> VFD

You can also use an XOR gate or CD4046 phase detector.
 
Top