• State Answer Suggested
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 2124 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Software PLL

Javier Vara
Expert 1635 points
Other Parts Discussed in Thread: TMS320F28069, CONTROLSUITE

Hello,

We are using sensored Instaspin to run an 8 pole pair, 10000rpm, 200kW, 700 Volts motor. We are also using a resolver as the position sensor, the output of the resolver is fed to a resolver to encoder converter chip and the encoder output fed to the microcontroller (TMS320F28069).

The inverter is being working pretty well up until 3000-4000 rpm, but then we started to have lots of control issues. After a lot of investigation we found out that there is a problem with the output of the resolver. If we run up the motor with an external motor to 5000rpm and read the speed calculated you can see it going up and down up to +-200 rpm (when its real speed is completely constant).

Then we run the motor with a comercial inverter and saw the same problem, but that inverter has a PLL option to apply to the encoder signal and when we turned it on the speed becomes much more constant (within +-3rpm). Therefore, even though we are investigating the source of that resolver problem it seems that having a software PLL would be very useful for cases in which the quality of the encoder or resolver signal is not very good.

My question is therefore, is there any available code about how to implement a software PLL for this kind of application? I have seen that there is a software PLL implementation for solar applications when connected to grid to align the generated voltage with the grid's voltage, can this be somehow modified to fit my application? Has anyone done something like this before that could give me some advice on how to do it?

Any help or advice would be pretty much appreciated.

Regards,

Javier

  • 0
    TI__Guru 57255 points

    Hi Javier,

    Utilizing a PLL routine is certainly a feasible option.  And the PLL implementation utilized in the solar library is likely a good starting point for you.  Obviously, you'll likely want to change the PLL controller coefficients and there may be other changes necessary to match what you desire.

    For the resolver algorithm, are you aware of the resolver library we offer:
    \controlSUITE\libs\app_libs\motor_control\libs\resolver

    If your issue is at high frequency, I might recommend sure that the resolver wires are twisted and shielded appropriately.  It may even be worthwhile probing the resolver signal before getting to the C2000 to make sure that they are relatively clean - which will help you focus on your issues as a software or a hardware problem.

    Hopefully this helps!


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    TI__Mastermind 27240 points

    Javier,

    You mentioned that resolver feeds into an encoder chip, I guess QEP, which then feeds in to 28069. At higher speeds, QEP is supposed to be more accurate. It leads me to believe that the encoder chip may be the weaker link in the chain.

    You seem to be looking for a PLL that will work with encoder (QEP ?), and I don't think we have anything like that. However, we do have a PLL to interface with the resolver, which is what Brett has pointed out in his response above. You can try one of two things.

    1. Either use a F28027 based resolver interface and SPI the position/speed data to 28069

    2. Implement the resolver in CLA, but make sure to arbitrate the ADC without contention between current sensing for current loop and sin/cos sensing for resolver.

    You can adjust the PLL coefficients to fit the speed range.

    Hope it helps.

    rgds,

    ramesh

  • 0
    Intellectual 395 points

    Hi Javier,

    I agree that the decoder IC might be the troublemaker here, I think it might be best and simplest to implement the RDC directly in the uC.

    The main drawback in this option is you need to provide Sine wave reference from uC, maybe you can implement it by using very high frequency spwm(carrier 200kHz and sine frequency at your sampling frequency), then use some simple filter and amplifier.
    For the decoding part, you might find 3-phase PLL useful, however instead of 3 phase input, you will already have alpha-beta signal, then simply use Park transform to transform your sin cos output of the resolver then follow the common PLL algorithm. For some reference, you might find this link useful

    Arief,

  • 0 in reply to Ramesh Ramamoorthy
    TI__Mastermind 27240 points

    3 phase pll may not apply for resolver feedback, which is two phase. You can find an example oroject in control suite.

  • 0 in reply to Ramesh Ramamoorthy
    Expert 1635 points
    We have fed the resolver output to an external resolver to encoder box and feed that to the inverter with same results. We are pretty sure that since the wobbling we are seeing in the signal is twice per rev the problem is likely to be in the mounting of the resolver. There must be some kind of offset due to mounting excentricities that modifies the coupling between the excitation and the sin and cos coils, once that goes through the resolve to encoder IC it translates to a non-perfectly smooth ramp (for constant speed) which at the end means a non-constant speed calculation.

    We are looking into how to reduce this offset problem but I am not sure about how much we can reduce it so the PLL would still be a good idea.

    Yes, I want to have a PLL that works with the encoder counter (the ramp). My first idea was to transform that signal into a square waveform (it can be as simple as signal < 8192, being 8192 half the number of encoder lines) and work from there as a clock PLL.

    Thanks for your suggestions but they would mean that we have to modified the hardware and we would like to try to avoid that. If there is no workaround we might have to go for that option.
  • 0 in reply to Javier Vara
    TI__Mastermind 27240 points
    If the underlying feedback from the resolver has a wavy nature, then you can not avoid the ripple in speed estimate and the speed controller will always try to adjust the torque ref all the time and will never stabilize. If anything, I will consider reducing the speed controller gain in that speed range so that it will take a little longer to react. This can only minimize the magnitude of speed swing but will not fix.
  • 0 in reply to Ramesh Ramamoorthy
    Expert 1635 points

    We have tried with a commercial inverter that has the PLL option, without it activated the inverter has the same problem as ours but when we turn it on, the wavy nature of the encoder signal gets greatly reduced (a factor of 40x), therefore allowing for much better speed control.

    Let me try to explain why the PLL would work with an example in the following image.

    .

    The black line is how the encoder counter (QEP) should look like if the motor is running at a constant speed. Due to the wavy nature of the encoder, we rather have the red one. Of course for the current control loop that position estimate is bad, but if you differenciate it is even worse for the speed control. 

    On the other hand if we manage to have a PLL locked in to the encoder counter, the PLL output should be a sawtooth signal with a perfectly constant slope and a frequency and phase exactly equal to the red curve (should look exactly like the black curve). Using the output of the PLL as our encoder counter, therefore, should eliminate any problem derived from the wavy encoder signal.

    I had a look to the PLL used in the solar library but I am afraid that is so different from the one I am trying to develop that is is not very useful. I have written a first version of such PLL in Matlab and it seems to work (at least in simulation) although I am a little bit worried about its dynamics and how it might respond to ramps in speed and things like that.

    Thanks to all for your help