Hi everyone. I am working on a digital PLL design for a motor control application and I need some help with the control-loop aspects. The end goal is to have my motor achieve phase lock with a reference signal. Some background information: My system consists of an FPGA which implements the "digital logic" end of things such as the Frequency/Phase detector + error counters, PWM controller, etc. The PFD is setup to drive a counter which keeps track of the phase difference(in terms of counts) between my motor and a reference clock. The FPGA is also paired up with a micrcontroller which I am using to implement a PID loop, provide debug output, etc. The DC motor I am using has an output that goes high once per revolution ("tach sense") which feeds one input of the PFD(realized in the FPGA). The other input to the PFD is an external clock signal, so the PFD compares a reference clock and the motor tach pulse train and spits out an error between the two in terms of counts(it also has an output lets me know if the motor is faster or slower than the reference clock). The problem: Since I am implementing a digital PID controller (in software on the uController), usually the sampling rate ("Ts") is factored in the conversion from a continuous-time to discrete-time control-loop. If it's important, I am using the Tustin or Bilinear transform to go from C-->D. The issue I face is that my error counter can only be read when the only when the motor has spun around and the reference clock has come by(the FPGA logic provides a signal that interrupts the uC when a new error is available and then the uC reads the error counter in the FPGA). Given that the motor will probably be speeding up/slowing down as a result of the control-loop, this means that I probably will not receive errors at periodic intervals, thus I cannot factor in one Ts into my PID code for my discrete-time implementation. My question: Can I just keep track of the time between each error event, convert that to a Ts and use that as my Ts each time I get a new error ("variable sampling rate")? Are there any draw backs to this technique? Are there any alternative methods? I appreciate all suggestions and information. Best regards. -- Jay.
Help with Digital PLL motor control
Started by ●December 15, 2003
Reply by ●December 15, 20032003-12-15
"Jay" <invalid@127.0.0.1> wrote in message news:JWfDb.188$0E1.7@fe10.private.usenetserver.com...> Hi everyone. > > I am working on a digital PLL design for a motor control application and > I need some help with the control-loop aspects. The end goal is to have > my motor achieve phase lock with a reference signal. > > Some background information: > > My system consists of an FPGA which implements the "digital logic" end > of things such as the Frequency/Phase detector + error counters, PWM > controller, etc. The PFD is setup to drive a counter which keeps track > of the phase difference(in terms of counts) between my motor and a > reference clock. The FPGA is also paired up with a micrcontroller which > I am using to implement a PID loop, provide debug output, etc. > > The DC motor I am using has an output that goes high once per revolution > ("tach sense") which feeds one input of the PFD(realized in the FPGA). > The other input to the PFD is an external clock signal, so the PFD > compares a reference clock and the motor tach pulse train and spits out > an error between the two in terms of counts(it also has an output lets > me know if the motor is faster or slower than the reference clock). > > The problem: > > Since I am implementing a digital PID controller (in software on the > uController), usually the sampling rate ("Ts") is factored in the > conversion from a continuous-time to discrete-time control-loop. If it's > important, I am using the Tustin or Bilinear transform to go from C-->D. > > The issue I face is that my error counter can only be read when the only > when the motor has spun around and the reference clock has come by(the > FPGA logic provides a signal that interrupts the uC when a new error is > available and then the uC reads the error counter in the FPGA). > > Given that the motor will probably be speeding up/slowing down as a > result of the control-loop, this means that I probably will not receive > errors at periodic intervals, thus I cannot factor in one Ts into my PID > code for my discrete-time implementation. > > My question: > > Can I just keep track of the time between each error event, convert that > to a Ts and use that as my Ts each time I get a new error ("variable > sampling rate")? > > Are there any draw backs to this technique? > > Are there any alternative methods? >Jay, Yes, I believe there's an alternative method. It hinges on why you need Ts in the first place. First of all though, I've not used PID controllers as such but only the old-fashioned linear control design. I suppose that it's easy enough to translate. A quick look suggests that Ts is simply part of the gain coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are constants anyway, right? I see that there's KP, KI, KD and Ts in the PID equations. However, the actual coefficients are: KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just to be sure, try this: Let's say that KP=3, KI=2, KD=4 and Ts=0.1. Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and KD=20, will the system be any different? From what I'm reading, it appears not - although it perturbs the bilinear transformation. Does it matter in practice? That's the question. It might be a good test to see if my conjecture is OK or not OK. Anyway, this is just an argument and I'm not sure that it matters in getting to a design. See below: I have designed motor controls using a tach. One of the issues you will face is whether you're truly building a speed control or a position control. Using a tachometer for feedback with a PLL often becomes a position control and you add an integration term by doing this - since the position is the integral of the velocity. If the PLL tries to lock the motor tachometer to the reference clock, then it's a position servo because you're trying to control the position of the shaft relative to the clock - even though it's a rotating position, it's still a position at an instant in time. One thing I might suggest is to select that value of Ts that matches the speed you're trying to achieve. That's where the control loop is critical. Otherwise, you do have a velocity servo for dealing with the shaft speed being much too low or too high. Your controller "switches" from velocity to position when you go from frequency control to phase control. My suggestion here is something like using "describing functions" in analyzing a nonlinear system - where an approximation is plenty good enough. So, this will be an approximation. Given that you'll need gain and phase margins in the end anyway, it should be fine. Then, if you have a range of values of Ts / motor controlled speed to deal with, I would analyze the system at the extreme values to see which dominates / is worse...... Somehow you need to consider the delays that are introduced in the implementation you've described. The interrupt service and associated processing time is quite concerning. You may not be able to do what you want with this kind of implementation. You'll need to run the numbers to see. With only one sample per revolution, you don't have much data to go on. How can you be sure that you're meeting the sampling criterion? I guess the motor could be very slow to respond to any changes but..... Let me explain further: What if you apply either drive voltage to the motor or a load that will vary sinusoidally (just as one example) or perhaps as a square wave AND the frequency of this forcing function is such that the shaft speed will be forced to increase during one rotation and decrease during the other rotation? Will there be appreciable change in the shaft speed at the frequency of this perturbation? If so, the one-sample-per-revolution tachometer is insufficient sampling because it doesn't meet the Nyquist criterion for sampling. This could be a very big deal. It also suggests that the lowest shaft speed you need to control to is the most critical in this sense - rather than the largest shaft speed / smallest Ts. I'm sure it could cause some discussion but let me say this: I think it doesn't matter what you *think* the perturbation bandwidth can be. What matters is what the motor is capable of responding to. I think that determines the bandwidth that you have to be able to sample - since you really can't predict what frequencies will be present in motor position. Hope this helps. Fred
Reply by ●December 15, 20032003-12-15
Fred: I think you are missing the point. Because he can't measure the feedback at a well-defined sample rate (he can only see that it crosses when it crosses, and has no idea about the phase of it at any given time of applying a new input), there is no firm application of Ts. That is, the notion of Ts in a digital control system implies that, at every Ts, you know the system output, and apply a new system input. Your discourse implies that Ts might be "unknown", but in fact it is time-varying (or at least on the feedback end of things). There has been much work done for digital controllers with *fixed* phase delay, meaning that you apply an input, but the D/A time plus the A/D time creates a *fixed* time delay (but variable phase delay, as phase depends on current system frequency). However, I'm not sure about his situation, with variable *time* delay, as he doesn't know the plant position when he applies control vector at Ts--he only knows plant position when it happens to cross one of the encoder/zero-crossing positions. There is hope, though. My thesis advisor at MIT has done some work in precisely these type of situations (Kamal Youcef-Toumi), and also there is a wealth of information on the subject from people who provide encoders for motors, and tell you how to use the encoders to control the motor (just google "control of motors", or something like that). Jim Gort "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message news:Reqdnb81qdTmjUOiRVn-uw@centurytel.net...> > "Jay" <invalid@127.0.0.1> wrote in message > news:JWfDb.188$0E1.7@fe10.private.usenetserver.com... > > Hi everyone. > > > > I am working on a digital PLL design for a motor control application and > > I need some help with the control-loop aspects. The end goal is to have > > my motor achieve phase lock with a reference signal. > > > > Some background information: > > > > My system consists of an FPGA which implements the "digital logic" end > > of things such as the Frequency/Phase detector + error counters, PWM > > controller, etc. The PFD is setup to drive a counter which keeps track > > of the phase difference(in terms of counts) between my motor and a > > reference clock. The FPGA is also paired up with a micrcontroller which > > I am using to implement a PID loop, provide debug output, etc. > > > > The DC motor I am using has an output that goes high once per revolution > > ("tach sense") which feeds one input of the PFD(realized in the FPGA). > > The other input to the PFD is an external clock signal, so the PFD > > compares a reference clock and the motor tach pulse train and spits out > > an error between the two in terms of counts(it also has an output lets > > me know if the motor is faster or slower than the reference clock). > > > > The problem: > > > > Since I am implementing a digital PID controller (in software on the > > uController), usually the sampling rate ("Ts") is factored in the > > conversion from a continuous-time to discrete-time control-loop. If it's > > important, I am using the Tustin or Bilinear transform to go from C-->D. > > > > The issue I face is that my error counter can only be read when the only > > when the motor has spun around and the reference clock has come by(the > > FPGA logic provides a signal that interrupts the uC when a new error is > > available and then the uC reads the error counter in the FPGA). > > > > Given that the motor will probably be speeding up/slowing down as a > > result of the control-loop, this means that I probably will not receive > > errors at periodic intervals, thus I cannot factor in one Ts into my PID > > code for my discrete-time implementation. > > > > My question: > > > > Can I just keep track of the time between each error event, convert that > > to a Ts and use that as my Ts each time I get a new error ("variable > > sampling rate")? > > > > Are there any draw backs to this technique? > > > > Are there any alternative methods? > > > > Jay, > > Yes, I believe there's an alternative method. It hinges on why you needTs> in the first place. > > First of all though, I've not used PID controllers as such but only the > old-fashioned linear control design. I suppose that it's easy enough to > translate. A quick look suggests that Ts is simply part of the gain > coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are > constants anyway, right? > > I see that there's KP, KI, KD and Ts in the PID equations. However, the > actual coefficients are: > KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further > about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just > to be sure, try this: > Let's say that KP=3, KI=2, KD=4 and Ts=0.1. > Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and > KD=20, will the system be any different? From what I'm reading, itappears> not - although it perturbs the bilinear transformation. Does it matter in > practice? That's the question. It might be a good test to see if my > conjecture is OK or not OK. Anyway, this is just an argument and I'm not > sure that it matters in getting to a design. See below: > > I have designed motor controls using a tach. One of the issues you will > face is whether you're truly building a speed control or a positioncontrol.> Using a tachometer for feedback with a PLL often becomes a positioncontrol> and you add an integration term by doing this - since the position is the > integral of the velocity. If the PLL tries to lock the motor tachometerto> the reference clock, then it's a position servo because you're trying to > control the position of the shaft relative to the clock - even though it'sa> rotating position, it's still a position at an instant in time. > > One thing I might suggest is to select that value of Ts that matches the > speed you're trying to achieve. That's where the control loop iscritical.> Otherwise, you do have a velocity servo for dealing with the shaft speed > being much too low or too high. Your controller "switches" from velocityto> position when you go from frequency control to phase control. Mysuggestion> here is something like using "describing functions" in analyzing anonlinear> system - where an approximation is plenty good enough. So, this will bean> approximation. Given that you'll need gain and phase margins in the end > anyway, it should be fine. > > Then, if you have a range of values of Ts / motor controlled speed to deal > with, I would analyze the system at the extreme values to see which > dominates / is worse...... > > Somehow you need to consider the delays that are introduced in the > implementation you've described. The interrupt service and associated > processing time is quite concerning. You may not be able to do what you > want with this kind of implementation. You'll need to run the numbers to > see. > > With only one sample per revolution, you don't have much data to go on.How> can you be sure that you're meeting the sampling criterion? I guess the > motor could be very slow to respond to any changes but..... > Let me explain further: > What if you apply either drive voltage to the motor or a load that willvary> sinusoidally (just as one example) or perhaps as a square wave AND the > frequency of this forcing function is such that the shaft speed will be > forced to increase during one rotation and decrease during the other > rotation? Will there be appreciable change in the shaft speed at the > frequency of this perturbation? If so, the one-sample-per-revolution > tachometer is insufficient sampling because it doesn't meet the Nyquist > criterion for sampling. This could be a very big deal. It also suggests > that the lowest shaft speed you need to control to is the most critical in > this sense - rather than the largest shaft speed / smallest Ts. > > I'm sure it could cause some discussion but let me say this: I think it > doesn't matter what you *think* the perturbation bandwidth can be. What > matters is what the motor is capable of responding to. I think that > determines the bandwidth that you have to be able to sample - since you > really can't predict what frequencies will be present in motor position. > > Hope this helps. > > Fred > > > > > > >
Reply by ●December 16, 20032003-12-16
"Jim Gort" <jgort@comcast.net> wrote in message news:pbvDb.401932$275.1275736@attbi_s53...> Fred: > > I think you are missing the point. Because he can't measure the feedbackat> a well-defined sample rate (he can only see that it crosses when itcrosses,> and has no idea about the phase of it at any given time of applying a new > input), there is no firm application of Ts. That is, the notion of Ts in a > digital control system implies that, at every Ts, you know the system > output, and apply a new system input. Your discourse implies that Ts might > be "unknown", but in fact it is time-varying (or at least on the feedback > end of things). > > There has been much work done for digital controllers with *fixed* phase > delay, meaning that you apply an input, but the D/A time plus the A/D time > creates a *fixed* time delay (but variable phase delay, as phase dependson> current system frequency). However, I'm not sure about his situation, with > variable *time* delay, as he doesn't know the plant position when heapplies> control vector at Ts--he only knows plant position when it happens tocross> one of the encoder/zero-crossing positions. > > There is hope, though. My thesis advisor at MIT has done some work in > precisely these type of situations (Kamal Youcef-Toumi), and also there isa> wealth of information on the subject from people who provide encoders for > motors, and tell you how to use the encoders to control the motor (just > google "control of motors", or something like that). > > Jim Gort >Jim, If I understood his question, it was about how to analyze the control equations for stability, etc. So, a variety of values of Ts might actually suffice for this purpose. The results wouldn't be exact but might be adequate. I know it's time varying and I purposefully substituted treating it as static but with a range of values. That isn't too much different than using describing functions for nonlinear system components. It would be scary to think that if the sample rate went up that the system would go unstable. I think that's right. Thus the lower bound on the sample rate could be the interesting case. Presumably if the system delays are small enough then he knows (nearly enough) the system state at the time of applying the next control vector. But, that remains a concern - being small enough. I find the sensor to be strange. An encoded tach with 1024 states is surely possible - I think that's what we were using in our low-flutter tape drive controller. A tach with but one "blip" per revolution seems strange to me. But that's what he says he has. Fred
Reply by ●December 16, 20032003-12-16
Hello Fred, Jim First, thank you both for your response. I read your original post Fred, but ran out of time to respond, and I see there is a new post so I'll try to answer all your questions (and pose some new ones of my own) in one shot... In article <ZI2dnY_KBqkeBkOiRVn-uw@centurytel.net>, fmarshallx says...> > "Jim Gort" wrote in message > news:pbvDb.401932$275.1275736@attbi_s53... > > Fred: > > > > I think you are missing the point. Because he can't measure the feedback > at > > a well-defined sample rate (he can only see that it crosses when it > crosses, > > and has no idea about the phase of it at any given time of applying a new > > input), there is no firm application of Ts. That is, the notion of Ts in a > > digital control system implies that, at every Ts, you know the system > > output, and apply a new system input. Your discourse implies that Ts might > > be "unknown", but in fact it is time-varying (or at least on the feedback > > end of things).This is what I was trying to get at in my first post -- Ts is not fixed but is a function of the motor rotational frequency and it's crossing with the reference clock.> > > > There is hope, though. My thesis advisor at MIT has done some work in > > precisely these type of situations (Kamal Youcef-Toumi), and also there is > a > > wealth of information on the subject from people who provide encoders for > > motors, and tell you how to use the encoders to control the motor (just > > google "control of motors", or something like that).I'll check into the research done by your thesis advisor, thank you for the name. I did try to read all available information with respect to motor control including data sheets from a lot of vendors, but I didn't seem to find the information I was looking for (or I misunderstood?). See below on my explanation about the motor outputs and what I found about motor control ICs.> If I understood his question, it was about how to analyze the control > equations for stability, etc. So, a variety of values of Ts might actually > suffice for this purpose. The results wouldn't be exact but might be > adequate. I know it's time varying and I purposefully substituted treating > it as static but with a range of values. That isn't too much different than > using describing functions for nonlinear system components.Fred, if I understood your original post and your text above, you are essentially saying that I should figure out my gains to account for the range that Ts might take on. Thus, my PID gains are effectively time varying gains (like an adaptive filter?) and I should pick my "fixed" gains to so that I'm stable across the range that Ts might take on?> It would be scary to think that if the sample rate went up that the system > would go unstable. I think that's right. Thus the lower bound on the > sample rate could be the interesting case.I think this would be the case as well, which gets into some details I wanted some comments on too... It is my understanding that the motor setup (which in my case has a fixed load for which I know the moment of inertia for) will effectively set the bandwidth for my system. The motor is effectively a second-order system and can be modeled as a typical RLC circuit. It is also my understanding that the PID compensator I design cannot increase the final bandwidth of the system(since that is limited by the "RLC" network) but can and will vary the gain/phase over the frequency range that the motor responds to. The Integrator should (when designed properly) provide gain at lower frequencies and eliminate steady-state error while the Differentiator term should increase the phase response at higher frequencies and also provide for some gain at high frequencies. The D term should reduce overshoot, decrease settling time, etc. This also means, if my understanding is correct, my digital PID loop should not apply or provide control changes at a rater faster than the motor can respond to. My feeling is if I continue with my existing control-loop approach (using the tachometer output) I would have to provide some kind of hysteresis or slew-rate limiting so even if my motor is spinning at say 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB frequency is say 10 Hz, I would not issue updates any faster than 10 Hz. Is my reasoning correct?> Presumably if the system delays are small enough then he knows (nearly > enough) the system state at the time of applying the next control vector. > But, that remains a concern - being small enough.> I find the sensor to be strange. An encoded tach with 1024 states is surely > possible - I think that's what we were using in our low-flutter tape drive > controller. A tach with but one "blip" per revolution seems strange to me. > But that's what he says he has.Actually the motor *does* have a quadrature encoder on it (a 2000 count/revolution if I use the quadrature counts) and I have designed my FPGA logic to properly interface to the these signals. I have software on the uC that can read the quadrature counts either asynchronously or synchronously (the FPGA will interrupt the uC when a new count has come by). However, I was unable to visualize a complete mechanism that utilized the quadrature counts of the motor to help get phase-lock with my reference clock. In most of the motor controller data sheets/appnotes that I looked at, the devices are attempting to position some load, say a printer head, at a particular location. In these applications, the IC will zero a quadrature counter, then move the motor (following a trapozoidal velocity pattern), sampling the quadrature counts at a fixed Ts, until the total quadrature count is = value where the load should be. For those kinds of "position" control systems, the final position can be expressed in a total number of quadrature counts from starting location (I.e. when the quadrature count starting from 0 reads 1 million, the print head will be in the desired spot). However, my system is not trying to position a load at a fixed location, but is instead trying to have the tachometer output be phase-aligned with a reference clock. The only scheme I have some up with that can utilize the quadrature encoder is the following: 1. Accelerate the motor so it is spinning at a frequency close to the reference clock to speed-up phase clock(aka do an FLL first). ( Right now, the FPGA is setup to allow it to time the reference clock and the uC can convert the count to a frequency. The uC also knows the Kv (voltage constant) for the motor so it can backsolve for a voltage and have the DAC/PWM circuit output a value that gets the motor close to the desired frequency. ) 2. Use the index/tachometer pulse from the motor is used to zero-out a quadrature counter(in the FPGA) on each revolution and have the quadrature counter start counting upward. 3. The quadrature count is stopped when a reference clock comes by and the quadrature counter (error) should be read by the uC and used in the control-loop as an error. Since the reference clock *IS* periodic and the error will be available on each reference clock tick, this means my Ts can be fixed. Note: My external clock range is between 1 to 50 Hz but is set on the system start-up, so I don't have to track a varying clock. Keeping in mind that the reference clock rate (thus "Ts" if I use the above scheme) could be higher than the bandwidth of my system, I still think I would need to limit the rate at which I can issue a new output. That is, I would NOT issue a new output on each error sample but somehow space them out so I don't cause the motor to go sinusoidal. Is the above scheme more sane? Is my reasoning sound? I did find one other PDF that seemed relevant: http://www.st.com/stonline/books/pdf/docs/1383.pdf It's an ST part that basically does what I'm trying to do, and also only uses a tach sense. The relevant pages, 14-18 give an idea of how they are doing their control but it still does not say what they do to rate limit the output. Finally, I guess related to digital controllers, I am wondering, how do other systems cope with not issuing outputs faster than the system can respond? Typically, the sampling rate is, to meet Nyquist, @ 2x the highest frequency component. That means that an error signal is available at this rate too. How do other digital-control loops avoid spitting outputs too fast? Do they not process a new output based on each error they get? Thanks for all your responses, hopefully with some time I might get phase lock on solution =) -- Jay.
Reply by ●December 16, 20032003-12-16
I avoided answering at first because it seems to me to be an attempt to build a silk purse from a sow's ear. The only indication of motor position seems to be a once-around signal. In effect, the sample rate is the rotation rate. Servos should be oversampled by at least a factor of five -- i.e., five times the Nyquist rate -- to keep the processing delay low enough for stability. What kind of angular accuracy is wanted at lock? Either the speed of the motor changes so slowly that the time of the last revolution is an adequate estimate of the current speed, or the system can't work. There's not even a way to directly measure the direction. To make it work (it's seductively easy to make it almost work), replace the once-around indicator with a quadrature position encoder that has an auxiliary once-around track. And have a look at http://users.erols.com/jyavins/servo.html Jerry -- Engineering is the art of making what you want from things you can get. ����������������������������������������������������������������������� Jim Gort wrote:> Fred: > > I think you are missing the point. Because he can't measure the feedback at > a well-defined sample rate (he can only see that it crosses when it crosses, > and has no idea about the phase of it at any given time of applying a new > input), there is no firm application of Ts. That is, the notion of Ts in a > digital control system implies that, at every Ts, you know the system > output, and apply a new system input. Your discourse implies that Ts might > be "unknown", but in fact it is time-varying (or at least on the feedback > end of things). > > There has been much work done for digital controllers with *fixed* phase > delay, meaning that you apply an input, but the D/A time plus the A/D time > creates a *fixed* time delay (but variable phase delay, as phase depends on > current system frequency). However, I'm not sure about his situation, with > variable *time* delay, as he doesn't know the plant position when he applies > control vector at Ts--he only knows plant position when it happens to cross > one of the encoder/zero-crossing positions. > > There is hope, though. My thesis advisor at MIT has done some work in > precisely these type of situations (Kamal Youcef-Toumi), and also there is a > wealth of information on the subject from people who provide encoders for > motors, and tell you how to use the encoders to control the motor (just > google "control of motors", or something like that). > > Jim Gort > > "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message > news:Reqdnb81qdTmjUOiRVn-uw@centurytel.net... > >>"Jay" <invalid@127.0.0.1> wrote in message >>news:JWfDb.188$0E1.7@fe10.private.usenetserver.com... >> >>>Hi everyone. >>> >>>I am working on a digital PLL design for a motor control application and >>>I need some help with the control-loop aspects. The end goal is to have >>>my motor achieve phase lock with a reference signal. >>> >>>Some background information: >>> >>>My system consists of an FPGA which implements the "digital logic" end >>>of things such as the Frequency/Phase detector + error counters, PWM >>>controller, etc. The PFD is setup to drive a counter which keeps track >>>of the phase difference(in terms of counts) between my motor and a >>>reference clock. The FPGA is also paired up with a micrcontroller which >>>I am using to implement a PID loop, provide debug output, etc. >>> >>>The DC motor I am using has an output that goes high once per revolution >>>("tach sense") which feeds one input of the PFD(realized in the FPGA). >>>The other input to the PFD is an external clock signal, so the PFD >>>compares a reference clock and the motor tach pulse train and spits out >>>an error between the two in terms of counts(it also has an output lets >>>me know if the motor is faster or slower than the reference clock). >>> >>>The problem: >>> >>>Since I am implementing a digital PID controller (in software on the >>>uController), usually the sampling rate ("Ts") is factored in the >>>conversion from a continuous-time to discrete-time control-loop. If it's >>>important, I am using the Tustin or Bilinear transform to go from C-->D. >>> >>>The issue I face is that my error counter can only be read when the only >>>when the motor has spun around and the reference clock has come by(the >>>FPGA logic provides a signal that interrupts the uC when a new error is >>>available and then the uC reads the error counter in the FPGA). >>> >>>Given that the motor will probably be speeding up/slowing down as a >>>result of the control-loop, this means that I probably will not receive >>>errors at periodic intervals, thus I cannot factor in one Ts into my PID >>>code for my discrete-time implementation. >>> >>>My question: >>> >>>Can I just keep track of the time between each error event, convert that >>>to a Ts and use that as my Ts each time I get a new error ("variable >>>sampling rate")? >>> >>>Are there any draw backs to this technique? >>> >>>Are there any alternative methods? >>> >> >>Jay, >> >>Yes, I believe there's an alternative method. It hinges on why you need > > Ts > >>in the first place. >> >>First of all though, I've not used PID controllers as such but only the >>old-fashioned linear control design. I suppose that it's easy enough to >>translate. A quick look suggests that Ts is simply part of the gain >>coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are >>constants anyway, right? >> >>I see that there's KP, KI, KD and Ts in the PID equations. However, the >>actual coefficients are: >>KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further >>about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just >>to be sure, try this: >>Let's say that KP=3, KI=2, KD=4 and Ts=0.1. >>Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and >>KD=20, will the system be any different? From what I'm reading, it > > appears > >>not - although it perturbs the bilinear transformation. Does it matter in >>practice? That's the question. It might be a good test to see if my >>conjecture is OK or not OK. Anyway, this is just an argument and I'm not >>sure that it matters in getting to a design. See below: >> >>I have designed motor controls using a tach. One of the issues you will >>face is whether you're truly building a speed control or a position > > control. > >>Using a tachometer for feedback with a PLL often becomes a position > > control > >>and you add an integration term by doing this - since the position is the >>integral of the velocity. If the PLL tries to lock the motor tachometer > > to > >>the reference clock, then it's a position servo because you're trying to >>control the position of the shaft relative to the clock - even though it's > > a > >>rotating position, it's still a position at an instant in time. >> >>One thing I might suggest is to select that value of Ts that matches the >>speed you're trying to achieve. That's where the control loop is > > critical. > >>Otherwise, you do have a velocity servo for dealing with the shaft speed >>being much too low or too high. Your controller "switches" from velocity > > to > >>position when you go from frequency control to phase control. My > > suggestion > >>here is something like using "describing functions" in analyzing a > > nonlinear > >>system - where an approximation is plenty good enough. So, this will be > > an > >>approximation. Given that you'll need gain and phase margins in the end >>anyway, it should be fine. >> >>Then, if you have a range of values of Ts / motor controlled speed to deal >>with, I would analyze the system at the extreme values to see which >>dominates / is worse...... >> >>Somehow you need to consider the delays that are introduced in the >>implementation you've described. The interrupt service and associated >>processing time is quite concerning. You may not be able to do what you >>want with this kind of implementation. You'll need to run the numbers to >>see. >> >>With only one sample per revolution, you don't have much data to go on. > > How > >>can you be sure that you're meeting the sampling criterion? I guess the >>motor could be very slow to respond to any changes but..... >>Let me explain further: >>What if you apply either drive voltage to the motor or a load that will > > vary > >>sinusoidally (just as one example) or perhaps as a square wave AND the >>frequency of this forcing function is such that the shaft speed will be >>forced to increase during one rotation and decrease during the other >>rotation? Will there be appreciable change in the shaft speed at the >>frequency of this perturbation? If so, the one-sample-per-revolution >>tachometer is insufficient sampling because it doesn't meet the Nyquist >>criterion for sampling. This could be a very big deal. It also suggests >>that the lowest shaft speed you need to control to is the most critical in >>this sense - rather than the largest shaft speed / smallest Ts. >> >>I'm sure it could cause some discussion but let me say this: I think it >>doesn't matter what you *think* the perturbation bandwidth can be. What >>matters is what the motor is capable of responding to. I think that >>determines the bandwidth that you have to be able to sample - since you >>really can't predict what frequencies will be present in motor position. >> >>Hope this helps. >> >>Fred
Reply by ●December 16, 20032003-12-16
Jay, When you think about it, a phase-locked servo is a position servo following a moving command. I hesitate to call anything impossible, but it's very hard to make a position servo without position feedback. In order to adjust the motor's phase, you have to know (or be able to pretty accurately guess) where it is. All the details that you need to work out follow from that. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●December 16, 20032003-12-16
Jay, When you think about it, a phase-locked servo is a position servo following a moving command. I hesitate to call anything impossible, but it's very hard to make a position servo without position feedback. In order to adjust the motor's phase, you have to know (or be able to pretty accurately guess) where it is. All the details that you need to work out follow from that. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●December 16, 20032003-12-16
"Jerry Avins" <jya@ieee.org> wrote in message news:3fdf3a6a$0$4757$61fed72c@news.rcn.com...> Jay, > > When you think about it, a phase-locked servo is a position servo > following a moving command. I hesitate to call anything impossible, but > it's very hard to make a position servo without position feedback. In > order to adjust the motor's phase, you have to know (or be able to > pretty accurately guess) where it is. All the details that you need to > work out follow from that.Jerry, Yeah, it depends on your reference if the "command is moving". If the command isn't in velocity space but, rather, is in phase space then the command is fixed - say at zero phase. I think that's what this type of phase-locked servo tries to accomplish - to keep the phase difference at zero. The idea isn't so much to "adjust" the motor's phase as to "control" it. By this I mean, it's not the objective to control the motor shaft position to be, for example, 90 degrees removed from a particular point of rotation. There's no command of that sort when the overall objective is to control velocity. The objective is to control the motor tachometer output to be in phase with a clock - which translates to an *arbitrary* shaft / tachometer position. While the words may seem contradictory, we agree that it's a position servo Fred
Reply by ●December 16, 20032003-12-16
Hi Fred, Thanks for the detailed response. In article <9fqdnRLwzZTAGEKiRVn-vA@centurytel.net>, fmarshallx@> > ***Yes, that was the idea. But, I think you need to get away from this > approach anyway.I agree, the variable Ts / variable gains is an interesting problem but perhaps for another time? :).> ................................. > > > > This also means, if my understanding is correct, my digital PID loop > > should not apply or provide control changes at a rater faster than the > > motor can respond to. > > ***Oh, I don't see why not if you have the compute power - if what you mean > is the drive voltage to the motor. Actually, the issue is that it might not > have an *adequate* rate!I am slightly confused here(more below). My system has enough computational resources to issue an update rates probably on the order of a kHz or so. I also have enough drive voltage and drive current, so that isn't what I was getting at.> > My feeling is if I continue with my existing control-loop approach > > (using the tachometer output) I would have to provide some kind of > > hysteresis or slew-rate limiting so even if my motor is spinning at say > > 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB > > frequency is say 10 Hz, I would not issue updates any faster than 10 Hz. > > > > Is my reasoning correct? > > ***I don't think so. You probably want to generate them even faster than > that! Our concern was that one indication per revolution might be > undersampling. Jerry's rule of thumb of a factor of 5 times oversampling is > a good thing to focus on. That is, 5 times the Nyquist rate or 10 times the > bandwidth of the data. If the shaft rate is 50Hz then this would mean a > single sample per revolution would be OK if the motor could not appreciably > change speed with a superimposed drive voltage at 5Hz - more or less. This > translates into a motor step response that's much slower than 0.2 seconds. > That's a little hard to imagine.> Turning the numbers around: > If you sample at intervals around 1/50=0.020 seconds then the <bandwidth has > to be less than 1/(10*0.020) or 5Hz. > Hysteresis or slew-rate limiting generally make things worse.What you are saying is that if my motor bandwidth is around 5Hz, 50Hz would be an acceptable sampling rate for errors. My point of confusion is if my motor bandwidth is only 5Hz, and I receive error information at the rate of 50Hz, process the error and produce a new output at a rate of 50Hz with some slight time delay from when I get the error does this not mean that I could end up with a limit cycle since I am driving the motor at a rate faster than it can keep up with? An illustration of the condition *I think I want to avoid* is shown on this page: http://www.engin.umich.edu/group/ctm/freq/freq.html search for "higher than the bandwidth frequency". If I'm missing something or have something flipped in my head, I'll gladly welcome any corrections!> .....snip the details..... > Take advantage of the full tachometer output! The phase lock control chips > that I'm familiar with do the rough velocity control that you describe - so > that part sounds OK. You adjust the frequency coming out of the motor tach > until it's close.> Then, when it's close, the controller switches to a different mode of > operation - so you really have two control loops to analyze: the rough > control and the fine control. I guess as long as the rough control gets you > into the fine range, it's OK if the rough control has a limit cycle (it may > oscillate around the desired velocity if left by itself).Right, my idea is to bring the motor up to the desired speed or very close to it so phase lock occurs quickly.> For the fine control, what if you do a typical phase detection between the > clock and the tach? That would be a more normal thing to do rather than to > use counters. Surely the FPGA is plenty fast enough to do that. Then you > phase lock the two in a normal sort of phase-locked loop approach. I should > think that all of this would be in the FPGA. Something like the single > ended falling edge detector in: > http://www.cs.binghamton.edu/~csekhar/AN8017.PDFActually this is *exactly* the kind of setup I have now. I have a Phase/Frequency detector in the FPGA, as I mentioned in my original post. Normally the edge-type phase detectors just provide the Up/Down signals and the duration that the Up/Down signals are on signifies the amount of error between the reference and clock(until both of them are in the on state). My "addition" to the edge type detector was to take the Up/Down signals and XOR them. The XORed output is used as an Enable to a counter clocked around 1.5MHz or so. The result is the counter holds the error between the reference and the motor tach output in terms of counter ticks which could be converted to a numerical time or a numerical phase error rather easily. My goal in using the counter was to have the control-loop chew on the error which is now numerical instead of being a square-wave of varying duty cycle.> Of course, in your case, the motor and its drive is the VCO and the > reference clock is the reference into the PLL, etc. And, I believe, the > integrator in the PID is the integrator in the VCO, right? I haven't seen a > block diagram of what you're doing.....My original approach to this solution was just to treat the motor as a VCO and use the PFD to produce an error signal(or error count) used by the control-loop and just to approach the whole problem as a PLL design. But this sort of brings us back all the way around to my original variable Ts problem. See the error information from the Edge Phase/Frequency detector is only valid when the motor spins around once and the reference clock comes by. Even if I don't use a counter to numerically keep track of the time difference between the reference clock and the motor tach, I would still need some meaningful way to use the Up/Down signals...> I'm not the expert in how to implement this but here's a wild guess: > Build the single ended falling edge detector as above. Use the output to > count up and down. While the phase is too positive, count up. While the > phase is too negative, count down. The result is an integration of the > errors which should integrate to zero when it's locked. The count drives a > DAC that creates the motor control voltage. I imagine the whole thing looks > something like this. So, whether the counter is in the FPGA or in the uC, > is up to you but I imagine that the responsiveness will be better if it's in > the FPGA. Then the PID in the uC *can* be implemented with a fixed Ts > because you might sample the counter output regularly from the uC - which > puts the sampling control in a better place. This all assumes that you use > the full capability of the tachometer and have 1000 or 2000 pulses per > revolution of the motor shaft. It looks like it means that your reference > clock will increase in frequency by a factor of 1000. Well, anyway, this is > really a "cartoon" of what might work.... and there must be some fixed > output from the DAC somehow - maybe from the rough loop.What you're suggesting is sort of what I threw together in an hour (just to demonstrate to myself the PFD and all the logic in the FPGA was working). My one hour setup: First bring the output* to a value so the motor speed is very close to the reference clock. Then, each time the PFD circuit produced a new error (which meant one reference clock came by and the motor had spun one revolution), I had the uC read the error counter in the FPGA(which also provides leading/lagging information). If the motor was leading the reference signal, I decreased the output* by one binary count. If the motor was behind the reference clock I advanced the output* by one binary count. * The output in my case is the output from a 16-bit PWM controller housed in the FPGA. The PWM output drives an H-bridge whos output goes to the DC (brushed)motor. What I found is that the motor tach would hover around the reference clock but would never stop or lock. In my case I had set the reference clock to 20 Hz and I noticed +/- 100 deg variation in the motor output with respect to the reference. I figured that this approach was too simplistic and I wasn't taking into account the phase/frequency response of the motor, so I started on the PID approach. I don't see how what you are suggesting (+/- the output based on leading/lagging) could really be extended to using the quadrature outputs(as I think you are suggesting) unless I do something like what I suggested in my previous post where I use the quadrature counts as a positional error(established by the motor 1 pulse-per-revolution and the reference clock). I say that because if I use the quadrature output simply as a "tachometer", I would also have to multiply my reference signal frequency by a factor of 2000, which I don't have the facilities to do easily. In my case the reference clock is provided by an external circuit and I don't have the room for a normal PLL to perform frequency multiplication. Technically it is possible for me to build some kind of DDS in the FPGA but having THAT phase lock to the reference signal, etc, etc seems like a lot of trouble. I appreciate your help(and everyone elses) so far, it has been very valuable. As usual I welcome comments, criticisms and suggestions =). Thanks! -- Jay.