IPM Motor Simulation and FOC Software

[johu]

Could an injected conversion be triggered from the timer output to do the current sampling (either single or burst) and then the ADC injected ISR be used to trigger PwmGeneration::run()?

Yes and no. Injected conversions are used for resolver sampling. There are 4 injected channels so theoretically one could put il1,il2,sin,cos in there, but: the first injected channel always seemed very noisy. So I'm not using it.
Also calculated with 1.5 clocks sampling time we could take 12 samples of both currents within one period and IIR filter them. That will be subject of another test then.

[Pete9008]

Yes and no. Injected conversions are used for resolver sampling. There are 4 injected channels so theoretically one could put il1,il2,sin,cos in there, but: the first injected channel always seemed very noisy. So I'm not using it.
Also calculated with 1.5 clocks sampling time we could take 12 samples of both currents within one period and IIR filter them. That will be subject of another test then.

A possibility then, is the resolver frequency tied to the pwm at all or is it separate?

Surprised it's so noisy, I've used single shot injected conversions before without noise problems. Could it be that the measurement for the first channel is coincident with a noise source on the board?

[johu]

A possibility then, is the resolver frequency tied to the pwm at all or is it separate?

Surprised it's so noisy, I've used single shot injected conversions before without noise problems. Could it be that the measurement for the first channel is coincident with a noise source on the board?

Resolver is tied to PWM.
Basically when, say, I assign cos to the first injected channels I get a lot of noise. If I assign it to the first and second injected channel and only use the second channel it is fine. Maybe it is an issue with interrupting the regular sampling and switching over to injected sampling.

On another note I put your binary on Audi (with Prius inverter) today and it was rather scary. Existing controller parameters are loaded from flash, the ones you added receive your defaults. So when stepping on throttle the whole drive train started to rattle and it took a few seconds to taper off after releasing throttle.

[Pete9008]

Good news, bad news!

The good news - been having another look at adding the mid period sample point and in the process have discovered why SyncDel needs to be set so high

The bad new - it's a fundamental error on my part that throws some of the results to date into question

The motor model had been taking the angle and phase voltages to calculate Iq and Id then using the equations to calculate the new Iq and Id values before translating these back into phase currents. Unfortunately it was doing the conversion from Iq and Id to voltages before updating the rotor position, it should have been calculating them after updating the motor position. Fixing this removes the extra 113us on SyncDel that has been bothering johu and I for a while. The other 167us correctly matches the SynDel setting of 10 (which is probably too high for other reasons).

Unfortunately this change does bring into questions some of the results produced to date so this evening job to go though the results and check whether the conclusions drawn from them are still valid.

I've also messed around with the model code a bit to allow it to produce phase voltages at variable sample points within the preiod so that it can be used to gauge the impact of the various ADC sampling schemes that could be used in the OpenInverter software. So the first question is does it all still work?

First plot is a rerun of the simulator agains the original OpenInverter software using all the same settings:

Near enough for me to say it's still working. You can see the effect of the code change though. The Iq and Id in the motor plot are gently drifting with motor speed because it's still running with SyncDel of 280. Changing SyncDel to 167 (280-113) gives:

Much better.

The next question is does it still demonstrate the unexpected deceleration so a 15sec run to above base speed followed by a 5sec coast:

That's a yes so that finding still stands

I'll run though the next few tests/plots now and post when they are ready.

[Pete9008]

Resolver is tied to PWM.
Basically when, say, I assign cos to the first injected channels I get a lot of noise. If I assign it to the first and second injected channel and only use the second channel it is fine. Maybe it is an issue with interrupting the regular sampling and switching over to injected sampling.

I've had one running regular conversions on DMA with single injected being triggered by an external pin change (which should be fairly similar) without experiencing noise problems in the past. That's why I'm wondering if it could be noise generated by say a pwm switching event?? The only difference I can think of is it was a F103 with the three ADC so maybe the processor hardware behaves differently?

On another note I put your binary on Audi (with Prius inverter) today and it was rather scary. Existing controller parameters are loaded from flash, the ones you added receive your defaults. So when stepping on throttle the whole drive train started to rattle and it took a few seconds to taper off after releasing throttle.

Sorry about that Some of the Pi parameter would have changed by, well by LOTS. Is everything OK?

Edit - it's probably the curki parameter, it's 20000 in your code and only 50 in mine!

[johu]

No reason to be sorry, that's how we do it here
So curkp/ki have to be changed?

Yes all is well, it is still Prius after all

[Pete9008]

No reason to be sorry, that's how we do it here
So curkp/ki have to be changed?

curki, curpi and fwkp are all reused so will need changing, I think the other parameters are either new or not used.

Yes all is well, it is still Prius after all

That's a relief I need to get on with my conversion so that I have some hardware to test on!

[Pete9008]

Next set of plots using the revised code to see if that still behaves. First a simple run using all the same PI parameters as before:

Looks OK so one with SyncDel dropped from 167us to 16us and ScynAdv dropped to 0:

Looks unchanged which is correct. Finally a 100% run to above base speed followed by a coast and then 100% deceleration:

Again looks good.

Based on that I'm going to conclude that fixing the error hasn't significantly affected any of the results/conclusions made so far. That is also a relief

And one more new plot - what happens if we move the sampling point for the currents and angle to the midpoint of the period to more accurately reflect the way sampling is actually done on the real hardware?

This one is interesting. Effectively all that has changed is the sampling point, nothing else. This means that the motor currents are actually changing by about twice as much as the OpenInverter code sees. Acceleration is fairly similar but it continues to accelerate to a higher speed. The field weakening current also seems to be brought in much more gradually. Overall I would have to say it improves things although not sure why!

[Pete9008]

And here is the downside wit hthe 50% sampling position, if the model is run for 20seconds this happens:

And if you try to coast after accelerating for 10sec:

We're back to the unwanted deceleration due, I think, to the control loops running out of headroom due to the under-reported currents.

Options I can think of to fix are are either leave more headroom on the ud and uq calculations to allow for it, but this will reduce max power too, or move the sampling points to later in the period. Any other ideas?

[Pete9008]

It isn't really, it's in the hardware. The counter counts up and down to achieve the center aligned PWM. At 8.8 kHz the ISR is called as soon as it has reached the top value. Then you have 113 us of time to complete your calculations. After those 113us your new duty cycles will take effect

I'm not sure this is being simulated properly. Does the above mean that it's 1.5 periods from the measurement point to where the new dutycyles are loaded into the timers and take effect (0.5 before the ISR and then a full period from the ISR start till the timers load)? If so I think the simulator needs a one period extra delay before using the new duty cycles.

Edit - Just simulated this extra delay and it has the same effect as the mid period sampling only worse

And one last plot showing what is happening at the point where control is lost:

You can see in the controller voltages where it it cuts the Iq in response to the throttle cut. It also seems to reduce the -Id which doesn't quite make sense. These seem to recover pretty quickly but it's already too late and they have caused a slight drop in -Id and the loops never recover. Motor currents peak at around 2000A but the controller only sees around half this.

@johu - I would strongly suggest that you don't do ANY testing above base speed for the time being!

[Pete9008]

Final thoughts for the evening-

The root cause now seems to be the relatively long time between the measurement and the point where the new duty-cyles take effect. There would appear to be two approaches to take here:

1) Try and fix the root cause - reduce the time between sample and action. Is there time between the existing angle/current measurement point and the next timer reload to execute the ISR, This could potentially reduce the delay to 30% or what it is at the moment.
2) Try to mask the effect. For example could we slug the -Id control so that it can't back it off so quickly and ride out the delay till the new duty cycles takes effect? Or have some feed forward from the Iq controller to the Id controller?

Note - the above are with MTPA disabled. Enabling it will add throttle dependant -Id which is highly likely to make the problem worse

[Pete9008]

And one final plot showing the controller's requested Ifw and Id in more detail:

You can see the Id controller backs off because Id initially increases- and how it never quite recovers. It's not helped by the reducing Ifw that occurs at the same time. Maybe slugging the controllers would work but it is likely to cause other control loop stability problems as well.

Edit - just noticed the phase reversal on the controller voltages caused by Vd briefly going positive. Just checked and the Id controller is allowed to request positive Vd. Question - should it be allowed to?

Edit2 - A zero limit on Vd actually seems to make things worse:

[johu]

Yes, Vd needs the full swing, terrible things happen when limited. Used to have a 50% limit to find it banging terribly when regenning at high rpm (not FW, more like 5000 rpm)

I did a little experiment myself but I'm not sure I found out anything.

I'm feeding one of the current inputs with a 100 Hz sine wave and then output the measured value on the first PWM channel. That way I was hoping to see the phase shift between sampling and outputting. Not sure if that's what I found as the scopes butterworth filter adds a bit of phase shift as well (set to bandpass-mode 90-110 Hz)
The bright blue line is my input waveform and the dark blue line is the filtered PWM output. The phase delay is 250 us with 12 samples. It isn't just the average but the average of 4 medians. (Median(1,2,3)+Median(4,5,6)+Median(7,8,9)+Median(10,11,12))/4

Then I repeated with 3 samples and decreased S&H time to find the delay dropped to 208 us

Also added a GetIIR function to AnaIn class but since that is a ring buffer it wouldn't feed the latest sample to the filter last but rather weigh some random sample as the last one. Little surprise the phase delay was all over the place on that one

[Pete9008]

Yes, Vd needs the full swing, terrible things happen when limited. Used to have a 50% limit to find it banging terribly when regenning at high rpm (not FW, more like 5000 rpm)

I did a little experiment myself but I'm not sure I found out anything.

I'm feeding one of the current inputs with a 100 Hz sine wave and then output the measured value on the first PWM channel. That way I was hoping to see the phase shift between sampling and outputting. Not sure if that's what I found as the scopes butterworth filter adds a bit of phase shift as well (set to bandpass-mode 90-110 Hz)
The bright blue line is my input waveform and the dark blue line is the filtered PWM output. The phase delay is 250 us with 12 samples. It isn't just the average but the average of 4 medians. (Median(1,2,3)+Median(4,5,6)+Median(7,8,9)+Median(10,11,12))/4

Then I repeated with 3 samples and decreased S&H time to find the delay dropped to 208 us

Also added a GetIIR function to AnaIn class but since that is a ring buffer it wouldn't feed the latest sample to the filter last but rather weigh some random sample as the last one. Little surprise the phase delay was all over the place on that one

Good idea and that's an interesting result. It does agree with the 1.5 period delay mentioned above. As long as you are using the same filter on both scope channels it should be common to both channels so shouldn't add any error to the measurement. Shame about the IIR.

Got a little further this morning. One problem is some bias in the FW controller. Because the target is set to around 30668 in a range of -30768 to 30768 the error term has a much larger value in the dangerous (decreasing FW) direction than the safe (increasing FW direction). Limiting the max error in the dangerous direction helps but doesn't fix it. Moving the FW controller into the 1ms task also helps, as it slows the change and removed the drop in Ifw, but again doen't fix it. Moving Mtpa() into the 1ms or 10ms task as as per your suggestion might help too.

I think the fundamental problem is this though:

The currents seen by the motor and controller don't match. In particular the -Id has a slow drift in the dangerous direction on the motor which isn't seen by the controller! This builds up to a point where the FW breaks down and then both the Iq and Id control loops go unstable leading to the uncontrolled deceleration. Not sure whether this is due to the sampling delay or whether I still have a slight mismatched SyncDel value. I find the later hard to believe and if it is then it is VERY sensitive and probably beyond the accuracy possible when setting up on a real car.

Going to have to leave it there for now but will have another look this evening.

[johu]

Ok, I'll let you figure that out. Suffice to say that the discontinuity also exists in reality so your model is in check here. We can't work around the basics of discretised control loops I'm afraid. You always take the results of the current interval and use them for the next interval. But of course the delay of the acquisition can be worked on.

EDIT: thought about this again. So you calculate your next duty cycle and at the very instant they go in effect your ISR is called. So currents are from an early point in time of that PWM interval. By stretching this back almost an entire interval (104us) to the past you are effectively using values from the previous interval as well. Probably not a brilliant idea.

So I extended my experiment a little. I should also mention that the waveform generator is phase locked to the internal "oscillator" by means of a sync pulse. Whenever the angle wraps around a rising edge is generated on an IO pin and that is connected to the trigger input. The falling edge is the end of the ISR
So the instant we trigger is already towards the end of the ISR, like 30us into it.

From the digital capture we see that increasing the sample window does indeed move the reaction to the input one PWM interval later. Don't worry about the exact time value for reasons stated above. Also note that the duty cycle in the diagram always belongs to the previous interval as it can only be computed after the interval is finished

[Pete9008]

So which of those plots is normal operation, the 282us or the 174us? Also am I understanding that plot correctly in that the ISR execution time is around half a period or 57ish us?

This evening I can either continue trying to find a solution for this or figure out github and get the simulator online (I wouldn't call it finished, probably just about usable). Which would you consider most useful?

[johu]

I think getting it on github one way or another would be a good idea. Then we can all have a play.

Repeat my edit from above: thought about this again. So you calculate your next duty cycle and at the very instant they go in effect your ISR is called. So currents are from an early point in time of that PWM interval. By stretching this back almost an entire interval (104us) to the past you are effectively using values from the previous interval as well. Probably not a brilliant idea.

[Pete9008]

Will do re github. That was the plan anyway before this issue popped up.

Sorry for all the questions but need to get this clear in my mind - On the plot above does the isr start when the pin goes high and end when it goes low? Is the timer duty cycle reload on the rising edgeof the line? Where would the analogue and current sampling points be with respect to those edges?

[johu]

Went into this also and added the trigger signal to the plot. Also moved it more to the beginning of the ISR, but we still have the position sampling before it. It still shows that the ISR is called right at the mid point. So taking a single sample early in the ISR would yield mid point sampling

[johu]

Just checked, ProcessCurrents() is quite late in the ISR, so moving this forward should be a good idea.
Also remembered this code for position sampling: https://github.com/jsphuebner/stm32-sin ... 563aa996b5
and here: viewtopic.php?t=1546&hilit=observer&start=50

It uses some kind of observer and worked well at speed but caused jitter at startup. So never integrated it.

[Pete9008]

So is this anywhere near right?

Ignore the number of analogue sampling point shown (I didn't count them when drawing)

I think that observer code is a software implementation of the phase locked loop approach so might be worth another look. The trouble with them is the control loop does need tuning to be stable otherwise you do get a lot of jitter.

Edit - Ignore the above about the observer, its nothing to do with the phase locked loop. Unfortunately the original TI link doesn't seem to work - if anyone has a saved copy I'd be interested to read it.

[Pete9008]

Assuming that the above is what we currently have I think this is what we should be aiming for:

Move PwmGeneration::Run() so that is triggered on completion of the injected ADC capture for the resolver. Remove everything from the front of the Run() routine except for the Id and Iq controllers with the aim of getting to the new dutycycle values in as short a time as possible so that the new values can be written back to the timer before the reload. This should reduce the latency down from 180us to below 50us and make life for the control routines MUCH easier. PwmGeneration can continue to execute past the reload (the dotted area in the diagram) to perform tasks that do not affect the duty cycle (such at FW and voltage limiting control loops, maybe even Mtpa although I like johu's idea of moving it to the 10ms task) so that the values are ready to use on the next pass round.

One thing that would also be worth adding in this scheme is a read of the PWM count value and direction just after the dutycycle load and a save of the worst case value to a parameter. From this it would be possible to check whether the ISR is reliably meeting timing and raise a warning if not.

What do you think?

Edit - the 50us above is probably pessimistic, hopefully we could get well below this. If it is would it be possible to move the injected conversion back a little to gain the benefit of any reduced latency?

Edit2 - Have just run the simulation and to guarantee stability need to get the latency down to around 20us! Might be a bit ambitious but is it worth a try?

[Pete9008]

The simulator is now on github, here is the link https://github.com/Pete9008/IPMMotorSim

A warning, I really don't get on with github and have no idea whether I've done this right. The directory structure on there looks right and when I check it out it looks OK locally but Qt is complaining about not being able to find the OpenInverter files. They are correctly listed in the Qt browser tree and open from it so I've currently got no idea what the problem is. If you would like to give it a try feel free. I also don't seem to be able to push changes!

It needs the stm32-sine source code dropping in as a subdirectory of the IPMMotorSim directory.

One other comment, I'm still using Qt 5.11.2 (because I use it to do static builds for another platform and can't face rebuilding all the libraries if I update). It should work fine on newer versions of Qt but it hasn't been tested with them.

Final question - can anyone recommend a 'Dummies Guide for Git' because I could do with one!

Edit - It's compiling and running now, if anyone else has the problem just delete the backslash from the end of the 'stm32-sine/libopeninv/src/params.cpp \' line in the IPMMotorSim.pro file, save it, try to compile (it will fail), put the backslash back in, save it and it should now compile. Still no idea why though!

Edit2 - Please bear in mind that this is a work in progress!

[Pete9008]

Just wondered how hard it would be to run the motor model on another processor and generate signals. But that would be a whole lot of DACs! At least 4 anyway for resolver and 2 phase currents.

EDIT: hmm, the interface for the AD2S chip (resolver to digital) runs via SPI. So the 2 DACs of an STM32F4 would suffice!

Just had another thought on this - instead of another processor why not have a another build of the OpenInverter code that integrates the motor model (bit like a debug build but with an extra module)? Avoids the complexity of another board, wiring, adcs, dacs, filters, etc.

It would take up a bit more processor resource but it looks like there is enough spare (and could always do a simplified version of the model if not).

[Bigpie]

Does it require a specific version of Qt? Bit of a Qt noob, not able to get it to compile on Qt 6.3.1 for macOS, I've installed the Charts package with the maintenance tool. Googling isn't brining up much of use.

Code: Select all

error: unknown type name 'QT_CHARTS_USE_NAMESPACE'
error: no viable conversion from 'int' to 'Qt::WindowFlags' (aka 'QFlags<Qt::WindowType>')