IPM Motor Simulation and FOC Software

[Pete9008]

Yes, look here:
grafik.png

So one period isn't just "on" and then "off" but "off", "on", "off". Since the trailing "off" continues into the leading "off" of the next period you can't determine the start of the period from the edge off the PWM signal, unless you set it to a very high duty cycle.

Thanks ,yes I get that, in fact that diagram explains exactly what I'm trying to do (except using CC4 to trigger the ISR rather than the ADC).

It's the comment "So I'm assuming the real latency is exactly one PWM period." that's confusing me??

[Pete9008]

Going to have to give up on using the 4th capture compare unit No matter what I do I can't get it to trigger the tim1_cc_isr().

I can see the CC4IE interrupt enable bit set in the control register and I can see the CC4IF flag set in the status register but nothing I do makes it call the ISR. A google search throws up a couple of other people with similar problems but no solutions. I'm guessing it's either a bug in the CM3 library, a bug in the silicon or the capture/compare interrupts aren't supported in PWM mode.

So much for that idea

[johu]

Have you enabled the interrupt in nvic? See hwinit.cpp

[johu]

Just went on a test drive with just some minor mods:
- 3 ADC samples, 1.5 clocks S&H time
- syncadv changed to 0.5
- your anti-windup mod

Accelerated up to 7500 rpm then let the throttle snap - nothing! No transients, no unwanted regen. Will test a little more with more throttle, was just very light on it. Binary here: viewtopic.php?p=44944#p44944

I think your anti-windup fix actually plays a large role in this.

[Pete9008]

Just went on a test drive with just some minor mods:
- 3 ADC samples, 1.5 clocks S&H time
- syncadv changed to 0.5
- your anti-windup mod

Accelerated up to 7500 rpm then let the throttle snap - nothing! No transients, no unwanted regen. Will test a little more with more throttle, was just very light on it. Binary here: viewtopic.php?p=44944#p44944

I think your anti-windup fix actually plays a large role in this.

Great news

Pretty sure there is instability still there but I'm wondering whether the physical limitations of the throttle pedal and any filtering in the higher code layers are slowing the throttle transient enough to mean it doesn't go outside the stable region?

Have you enabled the interrupt in nvic? See hwinit.cpp

Doh! Thank you, talk about a rookie mistake

With that fixed I've got some promising results, latency down to 70us (A1-A2 is the period, B1-B2 the latency):

It does involve a fair few changes to the code though. Might update the simulator to better reflect the way the hardware works, add in some ramps on the throttle and see whether it's justified.

[johu]

And here are two test runs. Still couldn't provoke any unwanted things.
You do see the currents are quite shaky now with less averaging. Also quite some ringing when entering FW, this might need tuning of fwkp.
Performance has suffered a bit from lowering syncadv from 12 to 0.5. So I guess this is where MTPA tuning comes in

[johu]

It would be really interesting to know whether just your anti-windup fix has cured the problem (and lowering syncadv). Test driving high rev software always makes me break a sweat. Anyone wants to volunteer?

[Pete9008]

Be careful, the id controller in those plots still looks a bit unstable to me. In the simulations the stability seemed to get worse at higher speeds with some pretty aggressive regen if it did loose it.

Does your code still adjust gain with speed? I'm wondering whether that might be reducing stability at higher speeds?

The antiwindup will be helping but Im guessing it will be a few things combined.

[johu]

You mean curkifrqgain? That one I have set to 0.
I will reduce fwkp significantly and see what that does.

I think next steps would be:
- Fix MTPA code (you've already done it, I'd add some optimization)
- Introduce the amplitude-based FW and throttle limiting code

I'd only want to look into larger restructuring if there are remaining issues

[Pete9008]

You mean curkifrqgain? That one I have set to 0.
I will reduce fwkp significantly and see what that does.

I think next steps would be:
- Fix MTPA code (you've already done it, I'd add some optimization)
- Introduce the amplitude-based FW and throttle limiting code

I'd only want to look into larger restructuring if there are remaining issues

Was thinking of the moddedKi variable, I've not played with it yet but it might be worth a look.

Careful with the Mtpa, in Qt I had some trouble with code optimisations, its worth checking a few results with the debugger.

Re the restructuring, if you enable the extra clock cycle in the simulator, and set the sampling point to 50%, it should represent the firmware pretty accurately. I couldn't get it to be unconditionally stable with those settings but with some rate limiting on torque request changes it might be good enough. The other thing that I found helped was limiting how quickly the FW controller could remove Id.

I'm a little worried about how FW and Mtpa will interact. With Mtpa you can get a fair bit of -Id removed very quickly when backing off the throttle. The Id controller has to be fast enough to add this back in before the controller runs out of volts. This is where limiting the throttle rate of change should help.

I'm starting to think that the changes for latency reduction are too likely to break something, especially when trying to maintain operation at multiple PWM frequencies and motor angle sensor types, so it would be best to try and get it working well enough without them.

[johu]

Was thinking ofd the moddedKi variable, I've not played with it yet but it might be worth a look.

Yes that part is disabled by setting curkifrqgain to 0

Careful with the Mtpa, in Qt I had some trouble with code optimisations, its worth checking a few results with the debugger.

Re the restructuring, if you enable the extra clock cycle in the simulator, and set the sampling point to 50%, it should represent the firmware pretty accurately. I couldn't get it to be unconditionally stable with those settings but with some rate limiting on torque request changes it might be good enough. The other thing that I found helped was limiting how quickly the FW controller could remove Id.

I'm a little worried about how FW and Mtpa will interact. With Mtpa you can get a fair bit of -Id removed very quickly when backing off the throttle. The Id controller has to be fast enough to add this back in before the controller runs out of volts. This is where limiting the throttle rate of change should help.

Yes there is quite some rate limiting going on in the vehicle code, I recommend 5%/10ms throttle ramping and sub 1%/10ms for regen ramping.

I'm starting to think that the changes for latency reduction are too likely to break something, especially when trying to maintain operation at multiple PWM frequencies and motor angle sensor types, so it would be best to try and get it working well enough without them.

Yes that's what I'm kind of worried about as well.

[Pete9008]

Yes that part is disabled by setting curkifrqgain to 0

Not sure Ive been setting that to zero - definitely worth a look then!

I'd quite like to get it unconditionally stable but not sure that's going to be possible. Would it worth putting a minimum value on the rate limiting to try and keep it in the safe area regardless of the parameter settings?

[Pete9008]

Just figured out why you are losing power without syncadv!

Its not Mtpa its the rotor angle calculations. The way the code is at the moment syncadv it trying to do two jobs and not doing either properly.

If you run low syncadv you get the correct answer from the park/clarke for iq and id but then use the wrong angle value for the inverse transform andg get vq and vd wrong - better stability but poor power.

If you run high syncadv you get the wrong answer from park/clarke transform for iq and id so any vq and vd calculated from by the inverse transform them will be wrong whatever angle is used for the inverse transform.

What we need to do is calculate iq and id without syncadv but then use scynadv to recalculate the rotor angle before doing the inverse transforms for vq and vd. This will give us iq and id based on the rotor angle at the point of measurement and vq and vd for the projected rotor angle at the point where the new duty cycles are loaded into the timer and vq and vd actually come into effect. It should give us good stability AND good power.

Syncadv will then need to be set to the equivalent of 180us (the measured latency).

Does that make sense?


Edit - thinking about it my attempts to reduce latency have been trying to reduce the need to do the above, however, with the above the latency becomes less of an issue. I'd still like to see the TI observer article if anyone has a copy - pretty sure that tha it was aimed at compensating for latency too.

Edit2 - just tried to simulate this using the standard firmware in the model and it's not showing the torque increase I was expecting which is a little surprising. Will be interested to hear whether it makes a difference on a real motor as there is either a problem with my understanding or a bug in the simulator.

Edit3 - It's my understanding! The actual value calculated for Vd and Vq really isn't that important, it doesn't actually mean anything, it's just the output of the control loops, what matters is the id/iq being right. The loops themselves compensate to a degree for the angle error meaning that the recalculation of the angle prior to the inverse transform is less important than I thought it was. Adding the recalculation will help slightly with stability as it makes life slightly easier for the control loops (and I do see this in the simulation) so it is still worth doing.

Hopefully fixing the Mtpa will help with power- the original one does seem to ask for an awful lot of unneeded Id which does reduce the iq available so it should help. Simulations show around a 10% improvement in torque just by turning Mtpa off!

[johu]

Quite a lot of code and test driving produced today.

Unfortunately I was able to trigger an over current event, I had set ocurlim to 600 and throtcur to 4:

Then I did a full acceleration run with ocurlim=900A and throtcur=5.5A

Acceleration drops off sharply at 4500 rpm. FW controller becomes active but there is no more amplitude left to follow its command. But thats because I'm stupid, d-controller is limited to maxAmplitude-2000 and I set fwMargin=2000 as well. So it kicks in way too late. Will correct that and try again tomorrow.

As for your syncadv theory we should keep it in the back of our head. Traditionally though you see the same angle going into the forward and reverse transformations.

EDIT: code is right on the master branch: https://github.com/jsphuebner/stm32-sine

EDIT2: maybe I should dump the guts of the new FW controller here for your reference:

Code: Select all

void PwmGeneration::SetTorquePercent(float torquePercent)
{
   float is = Param::GetFloat(Param::throtcur) * torquePercent;
   float id, iq;

   uint32_t amplitude = FOC::GetTotalVoltage(Param::GetInt(Param::ud), Param::GetInt(Param::uq));

   float ifw = FP_TOFLOAT(fwController.Run(amplitude));
   float maxIs = Param::GetFloat(Param::throtcur) * 100 - ifw;

   Param::SetFloat(Param::ifw, ifw);

   if (is > 0)
      is = MIN(maxIs, is);
   else
      is = -MIN(maxIs, -is);

   FOC::Mtpa(is, id, iq);

   id += ifw;

   qController.SetRef(FP_FROMFLT(iq));
   idref = FP_FROMFLT(id);
}

"is" is limited to maximum motor current minus FW current.

[Pete9008]

How did it feel outside the field weakening region?

Re the margin I did exactly the same to start with! If FW doesn't come in soon enough, and ud or uq max out, the control loops stop being control loops and it all goes open loop. Have a look in my code, I seem to remember using 2100 or 2400 in the end?

Which Mtpa algorithm are you running? If it's the original one I'd be tempted to disable it for the initial tests.

Is the above called from the 1ms or 10ms task?

I'll have a proper look at the code but afraid it probably won't be until tomorrow evening now. I still think a two stage approach will give best results, increase FW based on Utotal till it hits the limit and then back off the torque request to hold it there.

Re. the syncadv theory you are right, normally the approach would be to get the latency down to a figure where it compensating for it doesn't provide any real benefit. The trouble is that 180us is quite significant, around 54degrees if my sums are right? (at 10krpm with 5pole pairs). The control loops can compensate for a fair bit but that's asking quite a lot of them.

[johu]

How did it feel outside the field weakening region?

Extremely strong!
ldminuslq=1mH and fluxlinkage=0.09 mWeber

Which Mtpa algorithm are you running? If it's the original one I'd be tempted to disable it for the initial tests.
Is the above called from the 1ms or 10ms task?

I rewrote it completely using the formula from "teaching old motors new tricks":

Code: Select all

void FOC::Mtpa(float is, float& idref, float& iqref)
{
   float isSquared = is * is;

   idref = term1 == 0 ? 0 : 0.25f * (term1 - floatSqrt(term2 + 8 * isSquared));
   iqref = SIGN(is) * floatSqrt(isSquared - idref * idref);
}

The terms are precomputed in a setter function

Code: Select all

void FOC::SetMotorParameters(float ldminuslq, float fluxLinkage)
{
   if (ldminuslq > 0)
   {
      term1 = fluxLinkage / ldminuslq;
      term2 = (fluxLinkage * fluxLinkage) / (ldminuslq * ldminuslq);
   }
   else
   {
      term1 = term2 = 0;
   }
}

When ldminuslq is zero no id is generated.

[Pete9008]

You may have some trouble with underflows on that. Have a look a bit earlier in this thread for one that shifts some of the values to prevent it.

Edit - see here viewtopic.php?p=44635#p44635

[johu]

You mean with floats? They go down to 2⁻¹²⁵ or 10⁻³⁷

Because mtpa runs in 10ms task I decided to go all float

[Pete9008]

Missed the floats! Don't know - probably ok. I know an openoffice spreadsheet couldn't cope which probably uses them. 15bit fixed point works fine if you use the bitshifts though.

Edit - thinking about it the spreadsheet did use the intermediate variables. Wonder if these were stored without the full float precision. Either way might be worth running a test case, if it can cope with 0.1mH it's fine.

[johu]

Yes I did test all the code in a separate cpp file. Especially the new square root function Finds square root within 2-3 iterations mostly.

[Pete9008]

If you get a chance could you log a run with Mtpa disabled? There is something going on with the currents in the plots that I don't understand and it would be easier to see what's what without Mtpa. It would also be interesting to know how much of a performance boost it actually gives.

[Ev8]

Happy to test this code with the new MTPA and anti windup once it stops raining here, it’s been raining for days which isn’t best for road testing anything! If you could compile a bin for this one that would be great

[johu]

Did another test run today with fwmargin raised to 3000. It means:
- Maximum total amplitude is 37837 digits
- d-controller amplitude is limited to 35837 digits
- fw controller starts adding d-current at a total amplitude of 34837

Still, it does not work as expected. The moment FW comes in d-voltage has already topped out and d-current completely collapses and of course can no longer implement the added d-current. This already happens at 250 Hz as not even the d-current from MTPA can be held.

I felt when coming off throttle that power increased. You can see that at time 1486.

What is also strange is that d-voltage rises proportional to frequency while q-voltage seems to be just above 0. I think it even wants to go below 0 at time 1318 but that is not allowed.

Before, with high syncadv it was the opposite: d voltage was almost constant and q-voltage frequency dependent. I would sort of expect them both to be frequency dependent.

The attached binary has d-voltage limited to 37637, I will try that later.

[Pete9008]

Interesting!

Could you do a run with Mtpa disabled? I think it would be useful to isolate the contribution it is having to Id.

Are you sure the voltages are logging/plotting right, it doesn't seem to make sense.

If you could update your code on github (complete with the parameters values you are using) I can try to reproduce the effect tonight?

One other thought, is it possible to capture the throttle to a text/csv file? If so it could be played back into the simulator and the settings tuned to see how close it can be made.

Edit - that almost looks like uq and ud are swapped, could the q and d variables have got crossed anywhere?

[johu]

Interesting!

Could you do a run with Mtpa disabled? I think it would be useful to isolate the contribution it is having to Id.

Yes, can do that now by setting ldminuslq=0

Are you sure the voltages are logging/plotting right, it doesn't seem to make sense.

If you could update your code on github (complete with the parameters values you are using) I can try to reproduce the effect tonight?

Never noticed weirdness in the plotting so far.
Code is on github, parameters attached.

One other thought, is it possible to capture the throttle to a text/csv file? If so it could be played back into the simulator and the settings tuned to see how close it can be made.

Yes, datalogger would allow that.

Edit - that almost looks like uq and ud are swapped, could the q and d variables have got crossed anywhere?

Just checked, they are alright.

Just went for another test drive with fwmargin set to 6000 and fwkp=50 (which is really 50/32 because of scaling). Now we come alive! Unfortunately the FW controller oscillated strongly but when it oscillated towards much field weakening I could feel how much power is in there. Reducing fwkp leads to the controller outputting too little FW current (fwkp=5 on the left side, 15 on the right side). So I think adding fwki might help here.