openinverter forum

Weird! wonder why the wifi affects the first sample more?

pushed the ADC2 variant: https://github.com/jsphuebner/stm32-sine/tree/use-adc2

might not be very useful for simulation, harder to mock.

EDIT: right now I don't use any fancy hardware triggering but I call adc_start_conversion_injected(ADC2); right at the start of the ISR, then I update the resolver angle which should take long enough for the conversion to complete, then I read the conversion result.

Can't see it making any difference for simulation, none of the low level code is run. Might bring real life and simulation closer together though

For testing the code a software trigger is easier and should work OK. Prefer hardware triggering in the long run though, much less jitter on the sample point.

mjc506 wrote: ↑Fri Oct 28, 2022 8:27 pm Told you I was being thick Thanks

Don't believe that for a second!

Latest simulator is on github https://github.com/Pete9008/IPMMotorSim - Enjoy

Main changes are:

• More charts including operating point plot.
• Better model.
• Better reset of initial conditions and a few bug fixes.
• Remembers the position of all windows and edit fields and restores when restarted (wish I'd added this ages ago!).
• Values from param file override the above.
• Two param_prj.h files included, rename whichever motor type you want to simulate.
• To be used with the code in https://github.com/Pete9008/stm32-sine (won't build with anything else unless you mess around with the param file).

more Audi test driving, now with ADC2 software. No difference. Since I "fixed" this bug where the angle was updated after forward transform it no longer behaves But I want it to run with the correct angle.

It's not down to FW, it does the same jumps and suddenly locking in at maximum ud with field weakening turned off. Also tried various values for syncadv with no observable change.

Towards the end I let it coast downhill until I reached about 50 kph then touched the brake which brings in a little regen. And boom it goes silly. And here I was kindof trying to maintain speed but instead ud saturated full positive and I got massive regen. Whats wrong with this motor? I thought high inductance was easier to control

EDIT: can too little proportional gain make the controller unstable? It's just set to 10 right now.

Other way round, high inductance are a nightmare to control!

Fairly sure my understanding of motors is right now and one thing I'm sure of is that if the critical current is similar or less than Mtpa current the old control scheme isn't going to work over the full operating envelope. Whenever you cross the critical current the sense of the control loop reverses and it will go full scale. You can see it happening at the right hand side of the plots. With the phase reversal there is no gain setting that will keep it stable

TBH you need to try my code (I'm reasonably confident it will help a lot with the FW stability although if it doesn't I'm out of ideas)

Edit - see what you mean, high inductance makes it easier to keep the ud and uq controllers stable but makes the fw controller a nightmare. With low L motors it is the other way round!

Edit2 - looking at the plots again it might be something else going on. With a high L motor at high speed iq and id start to interact a LOT more, iq produces large amounts of ud and id produces large amounts of uq. This means that a rapid change in one controller can induce a big error in the other which can produce a big change in the output and so on. Essentially the two controllers are no longer independent. Wondering whether the dq compensation you mentioned is a way of limiting this?

Yes, just pulled your changes. I can build the firmware but I'm getting some undefined symbols when building the simulator:
I'm on the experimental branch on both libopeninv and libopencm3

Which symbols?

Just added an edit above while you were posting, might be something else going on too?

Edit - oops, thought I'd removed that, should be ok to just comment out the line causing it

Edit2 - no, that should be ok, will boot up the PC and have a look!

So with my cheap LCR, the leaf motor I have in the garage, the minimum inductance is 0.18mH and largest is 0.71mH other values between those 2 at various angles of rotation.

Bigpie wrote: ↑Sat Oct 29, 2022 5:31 pm So with my cheap LCR, the leaf motor I have in the garage, the minimum inductance is 0.18mH and largest is 0.71mH other values between those 2 at various angles of rotation.

Now that's interesting, not far off my Outlander motor at all:)

Looks like I might have pushed the wrong build, just doing a diff now.

johu wrote: ↑Sat Oct 29, 2022 5:28 pm Yes, just pulled your changes. I can build the firmware but I'm getting some undefined symbols when building the simulator:

Code: Select all

IPMMotorSim/stm32-sine/src/pwmgeneration-foc.cpp:166: undefined reference to `Terminal::BinLoggingEnabled()'

I'm on the experimental branch on both libopeninv and libopencm3

Hopefully sorted, I'd managed to miss adding a couple of new test stub files. Now updated on github.

Bigpie wrote: ↑Sat Oct 29, 2022 5:31 pm So with my cheap LCR, the leaf motor I have in the garage, the minimum inductance is 0.18mH and largest is 0.71mH other values between those 2 at various angles of rotation.

Sorry, just read this properly, thought it was measurements for your Outlander front. Those values would make sense for the Leaf

Pete9008 wrote: ↑Sat Oct 29, 2022 5:09 pm Edit2 - looking at the plots again it might be something else going on. With a high L motor at high speed iq and id start to interact a LOT more, iq produces large amounts of ud and id produces large amounts of uq. This means that a rapid change in one controller can induce a big error in the other which can produce a big change in the output and so on. Essentially the two controllers are no longer independent. Wondering whether the dq compensation you mentioned is a way of limiting this?

Think it is this. Looking at the simulation again it appears this could be causing the oscillation on both the uq and ud control loops. I'd been wondering why I couldn't tune it out but the interaction between id/iq and uq/ud would explain it.

Going to have a go at a compensation scheme. Don't like the idea for firmware as it relies on knowing motor parameters and would be fairly computationally intensive bit trying it is the best way to see if the uq/ud interaction is actually the cause.

Ok I dug out some spare motor parts, only tested with stationary rotor in one position but these are Lexus rx400h transaxle

Mg2

Mg1

Ev8 wrote: ↑Sat Oct 29, 2022 7:05 pm Ok I dug out some spare motor parts, only tested with stationary rotor in one position but these are Lexus rx400h transaxle

Thanks for taking those but any chance you could redo them To measure Lq and Ld you need one lead on one phase and the other two phases shorted together to the other meter lead.

I'm sure there is a way to convert your measurements to Lq and Ld, I just don't know what it is

Sorry, should have mentioned that before.

Edit - I'll have a google first to see if I can find how to convert them. Anyone know if these motors are star or delta wound?

Yes no problem I thought I may have got that wrong, will redo when I’m back on Monday

Pete9008 wrote: ↑Sat Oct 29, 2022 7:18 pm Anyone know if these motors are star or delta wound?

the motor leaf is 100% two parallel stars, their midpoints are not connected.
the rear engine of the alphard or estima is the same.
motor prius mg2 gen2 one star. the Lexus motor in the photo above is one star.

However, I may be wrong about the Lexus. there may also be two parallel stars like the nissan leaf

Romale wrote: ↑Sat Oct 29, 2022 8:41 pm the motor leaf is 100% two parallel stars, their midpoints are not connected.
the rear engine of the alphard or estima is the same.
motor prius mg2 gen2 one star. the Lexus motor in the photo above is one star.

Thank you! Doesn't actually matter for the calculation whether it is one star or two so that's exactly the information required.

Will have a go at calculating Ld and Lq using a star configuration and Ev8's data.

Edit - Is it possible to tell the configuration from the picture or did you already know the Lexus motor configuration?

Ev8 wrote: ↑Sat Oct 29, 2022 7:05 pm Ok I dug out some spare motor parts, only tested with stationary rotor in one position but these are Lexus rx400h transaxle

I think the converted numbers are:

MG2: Lq = 2mH, Ld = 1mH

MG1: Lq = 1.1mH, Ld = 0.6mH

Without spinning the rotor those could be plus or minus a bit but should be fairly close. The Lq measurement will be a bit low as the motor wouldn't have been correctly aligned for them so maybe 2.2mH and 1.2mH respectively??

Not low inductance but then nowhere near as high as some of the numbers we have been working with

Threw these numbers into the simulator and with 300V it gave a peak power of 100kW dropping to a steady 30kW at higher speeds for each of MG1 and MG2 (MG1 stronger at low speeds, MG2 happier spinning up to higher speeds). No idea how that compares to reality? (Edit - Hmm, those power numbers don't seem quite right, need to have another look at that)

In case the conversion equations are useful to anyone else:

Phase measurement to winding inductances La=(M1+M2-M3)/2, Lb=(M2+M3-M1)/2, Lc=(M1+M3-M2)/2
Winding inductance to Ld/Lq measurements L1 = La + ((Lb*Lc)/(Lb+Lc)), L2 = Lb + ((La*Lc)/(La+Lc)), L3 = Lc + ((La*Lb)/(La+Lb))

Assuming the motor has naturally come to rest aligned on one phase one measurement will be low and will be Ld the other two should be larger, roughly equal and a bit smaller than Lq (for example MG1 above came to 0.6mH, 1.1mH and 1.0mH).

Woohoo! Virtual spinning

Now to get my head around tuning this thing..

If you figure it out let me know how to do it!

Did it build OK, have I managed to fix all the bugs in the git repository now?

Built fine. A load of warnings (mostly 'depreciated') but that's probably a QT version thing. But it compiled and ran, and produced pretty graphs of control loops losing the will to live (You don't want any notes on tuning from me hahaha)