[DRIVING] Renault Clio Electrique -97

[bexander]

Depends what you would like to use it for, if it is just for measuring the motor then any of the cheap ones should be ok (both Ev8 and Bigpie have detailed the ones that they used in the simulator thread). If you do any electronic work then a slightly better one may be worthwhile.

I do some electronic work so figured a little bit better wouldn't hurt. Found a UNI-T UT612 that seem to provide good value for the money. What model do you have/use?

The current probe technique should be fine if you have the kit for it, in fact due to the higher currents it is probably a bit more representative. I'm guessing it might need the motor shaft locking accurately to get a good value for Lq (as the higher currents might start to move the rotor which would invalidate the result).

I agree and thats why I think my measurement is not to be trusted as I couldn't look the rotor on the motor shaft.

I'm wondering whether it is possible to calculate Ld and Lq from your plots too. What's needed is a step change in throttle below FW, from the change in Iq and Id and the corresponding change in Vd and Vq it should be possible to work them out. There is a bit towards the end of one plot that might do so Ill try to have a look later today.

Let me know if I should try and produce another plot with a better step in it. I will try and ad in some dead band on the accelerator pedal so it is easier to coast meanwhile.

[Pete9008]

I do some electronic work so figured a little bit better wouldn't hurt. Found a UNI-T UT612 that seem to provide good value for the money. What model do you have/use?

I was lucky enough to pick up a Mastech MS5308 on Amazon for a very good price (it was branded wrong and badly described). I'm fairly sure it was a faulty return that had tested as OK and been repacked for sale as there was an iffy connection on the Kelvin probe adaptor but with that sorted it seems pretty good (not quite as good as the old Wayne Kerr 4250 bridges I'm used to but not far off). It uses the same chipset as the DE-5000 which gets good reviews. Probably be a bit over the top unless you are fairly serious about electronics (especially at the full price) but it has the advantage of the Kelvin probes and more control over the display and measurement frequency.

Let me know if I should try and produce another plot with a better step in it. I will try and ad in some dead band on the accelerator pedal so it is easier to coast meanwhile.

I've had a look at your previous data. This is the plot I have ended up using with the transients marked:

Those points were selected because the speed was constant, it was outside FW and there were clear steps in Iq and Id. The way to work it out is measure the size of the voltage and current steps, convert the voltage steps to V ((val/32768) x (BatVolt/2)) and then

Code: Select all

Lq = deltaVd / ( 2 x PI x freq x deltaIq)
Ld = deltaVq / ( 2 x PI x freq x deltaId)

For the above plot this gives deltaIq = 17.5A, deltaId = 22.8A, deltaVd = 67.5V, deltaVq = 16.5V and freq = 91Hz which then gives:
Lq = 6.7mH
Ld = 1.3mH

Which is interesting! Now there is a lot of scope for error here, the transients were pretty small and I was reading them off a low res plot but the numbers are in the right ballpark and do suggest that LqminusLd is going to be fairly big for this motor. This may be why it seems prone to the power falling off in the constant power region rather than staying flat? If you do get some better data/plots it would be worth repeating these calculations.

Edit - just worked out flux linkage based on your coasting plot and got 103mWb so very similar to your 97mWb.

Based on that I would expect your critical current to be flux linkage/Ld = -77A so not far off what you have found. I would guess that if you do another run and get better data you will find that Ld increases a bit which will bring the critical current down a bit.

Quite nice that all the numbers are in the right ballpark

Edit2 - just had a look at the bridge you found, looks good. See https://www.eevblog.com/forum/testgear/ ... lcr-meter/ for a full review.

[bexander]

Allright, I will try and create a more high res plot with steps.

Your calculation suggest that I should test with increased LqminusLd of 5 or even 6.
Always good when the numbers line up!

Will try and test Johu version with increased overmodulation as well.

Another interesting issue I've found is that the tmphs reading is effected by acc pedal input! I suspect it is rather motor current then potnom but just thought of this after I recorded these quick plots.
This is with D selected and car forced stationary with brakes.

Then R selected.

I find this issue very strange and don't know if it is an HW or SW issue but will look into it at a later stage.

[Pete9008]

Allright, I will try and create a more high res plot with steps.

Your calculation suggest that I should test with increased LqminusLd of 5 or even 6.
Always good when the numbers line up!

I think it is probably being over estimated, I'd try to get some better plots and recalculate first.

Will try and test Johu version with increased overmodulation as well.

Good idea, that should help lift the power overall but I wouldn't expect it to do much for the drop off as speed increases.

Another interesting issue I've found is that the tmphs reading is effected by acc pedal input! I suspect it is rather motor current then potnom but just thought of this after I recorded these quick plots.
This is with D selected and car forced stationary with brakes.
Screenshot_2023-01-08_15-04-13.png
Then R selected.
Screenshot_2023-01-08_15-06-48.png
I find this issue very strange and don't know if it is an HW or SW issue but will look into it at a later stage.

I'd guess at noise pickup within the inverter. The cable that feeds the heatsink temp sensor on the Gen3 is quite long and runs past the power stages so it wouldn't be too surprising.

[johu]

Strange it's less pronounced in "R"... If it's die temp sensing then it's quite normal to be somewhat proportional to current, I observe the same in the Leaf inverter which doesn't have a long cable run.

[Pete9008]

If it's the one I'm thinking of it's on the heatsink on top of coolant pipe outlet.

With the motor stationary the direction will affect which IGBTs are switching which could have an impact? Could also be a ground loop issue if the coolant outlet is earthed somehow? It is only a degree though so not that surprising!

There is die sensing on each IGBT but don't believe it's brought out as an analogue just on the MG fault lines.

[bexander]

It is not the one on the heatsink on top of the coolant pipe. It is only connected to the board but doesn't really go anywhere on the logic board.
I think it is the temp sensor from the IGBT:s so it wouldn't surprise me if it is picking up noise, I'd just never noticed it before.
Will drop it and continue the search on how to get the motor running properly.

[Pete9008]

Ahh OK, I may have wired my own logic board up wrong then , does the one on the coolant get read in the firmware?

Was I looking at the wrong axis, is that a 70degree rise


Edit - Ignore my question on the sensors, just checked and it's called coolant temp, it's on a dedicated 2pin header and I have made provision for it on my board (which is a relief!). Temphs comes from the Toyota IGBT driver board, there is a separate output for MG1 and MG2.

[bexander]

It seem like I get very different result from the simulator every time I use it...
I did some changes to the param_prj.h to match what I use in the actual inverter:

param_prj.h

(16.14 KiB) Downloaded 114 times

And then restart sim and this is the result:

Does not match at all what I get in the car and I can't find why?

[bexander]

I don't understand fully what "fwcurmax" does but it does limit the motor current FW?
My thinking is that I get 27kW at base speed (~150Hz) and then limited to 18kW or 50A battery current in FW, fwcurmax at -70. This limit in FW corresponds to fwcurmax? I got more power (22kW) in FW with higher value on fwcurmax (-100) but can reach my desired top speed (400Hz).
So my question is then, isn't this just what you would expect, if you limit the current in FW, the motor power will be reduced?
Then, why do I need to limit the current in FW?

Under base speed with throtcur set to 2 I should allow 200A motor current if I floor the pedal and then in FW I allow 70A with fwcurmax at -70. Do I correctly understanding of the parameters?

[Pete9008]

It seem like I get very different result from the simulator every time I use it...
I did some changes to the param_prj.h to match what I use in the actual inverter:
param_prj.h
And then restart sim and this is the result:
image_2023-01-09_053627208.png
Does not match at all what I get in the car and I can't find why?

That doesn't't look right! Thanks for posting the param file, Ill try running with it this morning, just checking, that is the one from the IPMMotorSim directory isn't it?

This sounds similar to the issues Ev8 had, could really do with finding and fixing. What OS are you on?

Edit - is that the right file, resolver and motor pole pairs are both set to 1 in it which doesn't match the value seen in in the gui (4)?

[Pete9008]

I don't understand fully what "fwcurmax" does but it does limit the motor current FW?
My thinking is that I get 27kW at base speed (~150Hz) and then limited to 18kW or 50A battery current in FW, fwcurmax at -70. This limit in FW corresponds to fwcurmax? I got more power (22kW) in FW with higher value on fwcurmax (-100) but can reach my desired top speed (400Hz).
So my question is then, isn't this just what you would expect, if you limit the current in FW, the motor power will be reduced?
Then, why do I need to limit the current in FW?

Under base speed with throtcur set to 2 I should allow 200A motor current if I floor the pedal and then in FW I allow 70A with fwcurmax at -70. Do I correctly understanding of the parameters?

It sounds like you understand them correctly.

FWcurrentmax limits the max FW current and should match the critical current. FW is needed when the back EMF voltage causes the Uq term to max out, the critical current is the Id that fully cancels the back EMF and so reduces Uq to a minimum. At high speed moving the operating point away from Icrit limits the amount of cancellation and so reduces the volts available to keep the motor accelerating/spinning and so will limit top speed.

Below base is another matter, as mentioned before the current algorithms don't distinguish between voltage saturation due to Uq (FW) and saturation due to Ud (seen on high saliency motors at lower speed) and so in this region adjusting the max current may well give improved performance low down (but sacrifice it at higher speeds). I did have another look at this yesterday but wasn't thinking straight and didn't get anywhere. Really ought to review the MTPV algorithm options as these may provide more optimum operation in this region.

Edit - need to review what the latest firmware does but I think FW current is still added to MTPA current so if there is a torque request current in FW can exceed that set by currmax. Without a torque request it will drop to whatever is needed to control the voltages (but will not exceed maxcurr).

Edit2 - realised I didn't answer one question. If you go past the critical current in FW the voltages start rising again. If you go too far this can cause the Uq and Ud control loops to saturate, go open loop and essentially lose control of the motor, at this point you may be lucky and the motor continues to do vaguely sensible things or you might get strong uncontrolled regen or acceleration.

Edit3! - just had a proper look at your screen grab - linux mint. Also looks like the control loops have gone unstable (the sawtooth blips) followed by uncontrolled regen back down to base speed. Will try and reproduce here later this morning. I would guess that if you drop FWmax to -50A (flux linkage/Ld) it may stop doing that?

[johu]

There is no addition of MTPA and FW current. See here: https://github.com/jsphuebner/stm32-sin ... oc.cpp#L83

First it limits MTPA d-current (after limiting q current) to stay within the amplitude limit. Then it uses whatever has the higher absolute magnitude, ifw or idMtpa. This makes sure d-current doesn't suddenly drop because you're coming off throttle.

[bexander]

That doesn't't look right! Thanks for posting the param file, Ill try running with it this morning, just checking, that is the one from the IPMMotorSim directory isn't it?

This sounds similar to the issues Ev8 had, could really do with finding and fixing. What OS are you on?

Edit - is that the right file, resolver and motor pole pairs are both set to 1 in it which doesn't match the value seen in in the gui (4)?

Yes, it's the file in IPMMotorSIM. Running on Linux Mint.

I thought you set it by changing the default value, which is 4?

[Pete9008]

Yes, it's the file in IPMMotorSIM. Running on Linux Mint.
image_2023-01-09_115556705.png
I thought you set it by changing the default value, which is 4?

Yep you're right, brains still not working, doesn't bode well for trying to reproduce your results! (just turned on the computer and about to run the sim).

[Pete9008]

There is no addition of MTPA and FW current. See here: https://github.com/jsphuebner/stm32-sin ... oc.cpp#L83

First it limits MTPA d-current (after limiting q current) to stay within the amplitude limit. Then it uses whatever has the higher absolute magnitude, ifw or idMtpa. This makes sure d-current doesn't suddenly drop because you're coming off throttle.

Thanks, that's good, couldn't remember whether that had made it into the firmware.

[Pete9008]

That's interesting, I get a different result, posting a screen grab in case I'm missing something obvious:

There is the same sign of instability as the speed gets near 360Hz but the vehicle is accelerating much slower, were any of the parameters modified after your run was made?

This is using my default param file, going to compare with yours next.

[Pete9008]

OK looks like the problem is the changed value of syncofs in your param file, with that changed in mine my results agree with yours. The simulator assumes the resolver is perfectly aligned with the motor and so that value needs to be left at zero (I need to document that!, similar with pinswaps although your setting doesn't seem to upset things as much as I would have expected).

Very interesting the increase in torque though - need to have a think about the implications of that!

[Pete9008]

There is something very odd going on there that needs a bit more looking at, essentially your syncofs value reverses the motor currents seen by the controller (so pos Id/Iq in the motor is seen as neq Id/Iq by the controller, can be seen in the motor current and operating point windows) so it is actually driving the motor with pos Id and neq Iq which I would expect to drive the motor backwards - but it doesn't in the sim? Also the torque is roughly 2/3 compared to zero offset yet the car is accelerating faster - something else to look at! Not got time to look at this now but will investigate further this evening.

For now revert all the settings in the param_prj.h file to the ones that that come with the one simulator repository https://github.com/Pete9008/IPMMotorSim ... aram_prj.h and just change the ones that appear in the sim's gui to match you car's param_prj file. That should work well in the simulator but still default to your motor parameters. I'll update the documentation to reflect this. Sorry about not being clearer on modifying the param file before, this could explain both your and Ev8's problems.

Edit - Ignore comment about accelerating faster, just looks that way from the shape of the plot, it's actually reaching a much lower speed.

Regarding the motor still running forward despite neg Iq all I can assume is that the reactance torque is stronger than the direct field torque and overrides it. This is a very high saliency motor so I suppose it's possible.

The syncoffs value also explains why the control loops are losing control, can't really expect them to cope with running in this mode.

Edit2 - dropping lqminusld to zero and the motor runs backwards as expected but any saliency at all and Id dominates. Wondering whether in this mode the motor is behaving more like a stepper motor and continues to do so until it hits a frequency where the balance of torque shifts and Iq starts to dominate again. At that point there is not much that the control loops can do - it's a hardware (simulated) problem!

[bexander]

So it was a user error, as I suspected. It works great now after I reverted the param_prj.h.

[bexander]

Did some simulations according to "don't think, just test" and found that if I increase Kp I can also increase FWcurmax which in turn increases power output in FW.

Kp 500 and fwcurmax -60

Kp 1400 and fwcurmax -85, still stable over 320-400V DC up to 400Hz

But not that big of a difference, going from 15kW to maybe 18kW in FW. Those motor parameters (Ld, Lq and LqminusLd) really have a large effect so I will have to measure them more precisely. Hopefully better weather tomorrow, so I can create a good current step and also a better coast up test.

[Pete9008]

So it was a user error, as I suspected. It works great now after I reverted the param_prj.h.

Or designer/documentation error

On the next release I'll change it so that anything in the param_prj file that could disrupt the simulation is overridden at program start. That would make it possible to just use the car's param file without modification. It would also be a better solution than just trying to document it.

Did some simulations according to "don't think, just test" and found that if I increase Kp I can also increase FWcurmax which in turn increases power output in FW.

Kp 500 and fwcurmax -60

image.png

Kp 1400 and fwcurmax -85, still stable over 320-400V DC up to 400Hz

image.1png

But not that big of a difference, going from 15kW to maybe 18kW in FW. Those motor parameters (Ld, Lq and LqminusLd) really have a large effect so I will have to measure them more precisely. Hopefully better weather tomorrow, so I can create a good current step and also a better coast up test.

With high salience motors those parameters do matter, if too low you lose reluctance torque, if too high you waste power in excess Id and loose direct torque.

What road speed does the 400Hz/6krpm work out to?

Edit - if more power/speed would help have you considered using the Prius boost converter to increase the DC bus voltage? At these power levels it should be up to it.

Edit2 - btw a coast down from speed (without regen) should work just as well as a coast up when going down a hill.

[bexander]

400Hz is 91km/h, or a divisor of 4,4 if you will or more precise I use divisor of 65,8 from shaft rpm to speedometer.

Yes, that is an option but my strive is towards maximum efficiency not acceleration performance and using the booster will most likely reduce efficiency. I'm quite ok with the current performace but if it is possible to squeez a little bit more out of it I wouldn't mind.
The advantage of using the booster besides higher voltage would be a constant voltage as well. If I were to use say a 130S battery the voltage from full to empty would differ 100V. Thats quite a lot when you try to creep up close to the limits.

EDIT: I'm really more interested in smoothing out the power curve rather than rasing it.

[Pete9008]

So that's a 0-60mph time of around 15sec on the simulator, that doesn't seem too bad at all.

In theory it should be possible to just use the voltage boost when needed. There would still be a bit of loss due to the IGBT and inductor voltage drop but it would eliminate the switching losses in normal use.

Edit - very curious to see what kind of efficiencies you can achieve. I'm hoping for 160Whr/mile but unsure whether it is realistic.

Edit2 - in that case there are lots of ways to drop the initial high power values

Edit3 - regarding efficiencies boosting the voltage does mean that the motor is running at lower current and lower fields, now this should move it into a more efficient region of operation (and may also slightly reduce inverter losses?). Wonder which is bigger, the efficiency improvement in the motor or the losses in the boost converter?

[johu]

Is it possible to wire the unused "user PWM" pin to the low side switch of your boost converter (instead of wiring it to the atmega)? Then you could try this: viewtopic.php?p=22644#p22644 (instructions for Gen2 but you get the idea....)

You could probably have the atmega do the job as well by putting speed on the CAN bus, but you've gotta be really careful not to blow up your boost converter.