• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 1455 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Sensorless FOC - expectation and TI software parameters (HVPM motor/PFC Kit)

Andrew Steer
Prodigy 50 points

I'm developing a motor driver heavily based on both the hardware and software from the TMDSHVMTRPFCKIT, but with various components uprated for more power - a 2.5kW PMSM motor. We're using the Piccolo F2803x controlCARD.

Our software is a derivative of the supplied  "HVPM_Enhanced_Sensorless_2803x" code.

After struggling for some time with the driver and motor losing sync as the speed was increased (at around 0.6-0.7pu) when under load ('level 7' of the software getting-started guides), I eventually realised that the problem lay with the sensorless rotor position-estimation part of the code - and by modifying the software constants BASE_CURRENT, Rs, Ls managed to get the drive working satisfactorily to full speed and full load.

I would however really appreciate it if you could clarify the expected 'definitions' of these constants - which are all inputs to the SMO module.

For other newbies, this will hopefully highlight some potential ambiguities/pitfalls!

In the file HVPM_Enhanced_Sensorless-Settings.h the following constants (among others) are set:

// Define the electrical motor parametes (Estun Servomotor)

#define RS 2.35     // Stator resistance (ohm)
#define LS 0.0065 // Stator inductance (H)

// Define the base quantites

#define BASE_VOLTAGE 236.14 // Base peak phase voltage (volt), Vdc/sqrt(3)
#define BASE_CURRENT 10 // Base peak phase current (amp), Max. measurable peak curr.

If the 3-phase motor is wound in a 'Y' configuration, can you confirm that the Rs and Ls constants should correspond to the resistance and inductance in each branch of the 'Y'?

So the Rs, Ls constants should be set to values which are half of the values which would be physically measured between external phase-to-phase connections? Can you confirm?

I interpret from the limited documentation and comments on this forum that the BASE_VOLTAGE is meant to represent the full-scale measurable voltage for the voltage-feedback circuits... which will depend on the potential-divider / resistor values. On our PCB we anticipate working with a DC bus around 370 to 400V, and have potential dividers as per your Kit with (300k+820k) [top] and 9.09k [bottom]. I reckon this gives 0...410Vdc --> 0...3v3.

Can you confirm that the BASE_VOLTAGE constant should therefore by 413/sqrt(3) = 236.6V ?    Which is near-enough what's pre-supplied in the .h file.

We've uprated our current sense circuitry such that "-30A"(dc) would give 0V at the op-amp output, and "+30"(dc) would give 3v3 at the op-amp output.

It becomes unclear then whether BASE_CURRENT should be 60 (the full span peak-to-peak measurement range), 30 (the "peak" range either side of nominal), or perhaps 30/sqrt(2) = 21.2A the maximum measurable RMS current ... or perhaps even 30/sqrt(3) for a 3-phase "special"?

Empirically I'm finding values around 21 work well in practice for BASE_CURRENT - but would like to know what the software design-intent was, to ensure I'm not naively 'hacking' this value to compensate for a problem elsewhere.

The above graph shows how the pi_id.Out and pi_iq.Out behave as the target speed is increased.

With worse/wrong settings for the Ls,Rs, BASE_CURRENT my pi_iq.Out flattens out and my pi_id.Out ('D') line nose-dives at lower speeds (e.g.reaches -0.6 to -0.7) at speeds around 0.7, and control is lost. I interpret this as meaning that my rotor-angle estimation had appreciable errors/offsets.

What I'd really like to understand is what the expected behaviour of "D" should be as the motor speed and power is increased.

My 'D' is still falling (at -0.4) at the right of my graph. Is this normal? Should I be aiming to make 'D' less-negative at speed, or is it ok as-is?

My current waveforms are looking like very pure sinewaves, which I take as a good sign.

Thanks for any help or advice you can offer.

Andrew

  • 0
    Prodigy 50 points

    Clarification, I meant: Can you confirm that the BASE_VOLTAGE constant should therefore by 410/sqrt(3) = 236.6V ?

    Further question: having changed the hardware 'gain' on the current-sense amplifiers, can you confirm there is no other "ADC gain" parameter to adjust in the software? Is changing the BASE_CURRENT the only value that needs to be changed?

    Further question: Is there any other software parameter to adjust for tuning out any phase-offset in the sensorless position-estimation, or should the maths make it work near-perfectly just as long as the BASE_VOLTAGE, BASE_CURRENT, Rs and Ls are all correct?

    Thanks again,

    Andrew

  • 0 in reply to Andrew Steer
    Prodigy 50 points

    And in the software HVPM_Enhanced_Sensorless.c

    // Initialize the PI module for speed

    pi_spd.Kp = _IQ(1.5); //10.); //3.0);//_IQ(1.5);
    pi_spd.Ki = _IQ(T*SpeedLoopPrescaler/0.2);//_IQ(0.005); //0.003); //
    pi_spd.Umax = _IQ(0.95);
    pi_spd.Umin = _IQ(-0.95);

    Is there any reason why the spd.Umax and .Umin are only ±0.95 rather than ±1.0 ?

    Would I run into any trouble (e.g. with the underlying fixed point maths 'Q-values') if I used ±1.0 ?

    If I want to run at 100% of nominal speed, can I use Umin/Umax ±1.0, or is it preferable to work-around by increasing the BASE_FREQ such that "0.95" is my actual required physical top-speed?

  • 0 in reply to Andrew Steer
    TI__Mastermind 27240 points

    Hi,

    The software treats currents and voltages in per unit. Per unit is based on the max values the sense circuit is capable of sensing. Hence, for current measurement, when the ADC reads 0xfff (1.0pu), the current through shunt resistor is 10A, and when it reads 0x000, shunt current is -10A. Like wise, for voltage measurement, when the ADC reads 0xfff (1.0pu), the dc bus voltage is 410V. The actual Rs and Ls of the motor are internally scaled based off these pu values.

    Profile of D voltage:

    It may be valid, you can simulate and see if you want. The dynamics of Vd depends on the speed, Iq current and motor Ls and Rs. What you should be concerned is getting the Id current the way you want. If it saturates the D voltage, then that is what it is and you may have change your strategy.

    Reason why Umax and Umin are not 1.0:
    Mathematically, if you set Umax at 1.0, then in the PI controller for the next stage that it feeds to, as the feedback can never go >1.0pu, the error comparator will not generate negative error and hence it may not bleed the integral control part.

    Moreover, this is supposed to represent the max current the motor is allowed to. Technically, sqrt (Id*Id + Iq*Iq) should not be greater than Imax. Likewise, sqrt (Vd*Vd + Vq*Vq) should not be greater than 0.90pu because current sensing needs the ON time of bottom switch to be force current through shunt resistor and measure it.

    Hope it helps.

    rgds,

    ramesh

  • 0 in reply to Ramesh Ramamoorthy
    Prodigy 50 points
    That's helpful, thanks.
    I think I've just found a hardware issue in my DC bus voltage-measurement - which I observe is very non-linear. As that was under-reading, it may explain why I was having to 'hack' my BASE_CURRENT value to be smaller than it should, to make the SMO do something vaguely reasonable!
  • 0 in reply to Andrew Steer
    Prodigy 50 points

    Further to previous comment, on our circuit we had 3V3 zeners on all FOUR motor-feedback voltage-sense lines, Vfb-bus, Vfb-U,  Vfb-V,  Vfb-W (ostensibly 'protecting' the controlCard) - these were significantly affecting the voltage measurements. On the TI Kit circuit you only have the zeners on the U,V,W.

    Removing the zener from the Vfb-bus line restored correct voltage-measurement for us. For anyone implementing a scheme which actually makes use of the Vfb-U/V/W measurements, you may want to check whether the the zeners are an issue here too....

    An aside, I notice that while USB (and other IO) isolation is provided by the ISO7220 (4kV isolation) parts, capacitor C17 (DigiKey 445-7758-1-ND, TDK C3216X7T2W104K160AA) on the dev kit (last page of HVMotorCtrl+PFC-SCH[R1.1].pdf ) bridges the isolation and system GNDs, and appears to be merely a standard 450V capacitor part.

    This would appear to significantly compromise the safety-isolation otherwise provided. Can you comment on this? Why is a capacitor fitted at all?

    Thanks.

  • 0 in reply to Andrew Steer
    TI__Mastermind 27240 points

    The zeners are meant to protect the ADC input against over voltages, but you are right, they interfere with voltage measurements. If you need accuracy, they are worth removing. You may consider some other protection methods if you are looking for one.

    Reg the cap across the isolation barrier, please refer to the thread below:

    RE: Is 450 volt cap across isolation barrier on HVMotor kit and F28069ISo control card adequate?

    rgds,

    ramesh