openinverter forum

Posted: **Fri Jul 09, 2021 5:56 am**

Made more calculations.

IdIq.ods: Sheet "Base speed"; (46.04 KiB) Downloaded 152 times

I'm back to thinking Imax is a constant. The pedal input adjusts MTPA and when it no longer can deliver the torque requested depending on current and speed the VCLMT takes over and supplies as much torque that is possible for given speed. If the driver decreses the pedal input, i.e. request less torque, the MTPA might be back in action, limiting the torque output.

Under the assumption T_ref is the pedal input, I don't understand the Im = max(). To me it makes more sens min(), otherwise max current all the time??

: image_2021-07-09_075453.png (3.42 KiB) Viewed 4914 times

Posted: **Fri Jul 09, 2021 1:04 pm**

Showing my level of ignorance here, but I had to look up MTPA

Had it been written as MT/A, I *might have* had a chance

While doing the research on it, I stumbled on this 2017 paper, and while I do not understand more than the general idea, it appears to be relevant.

https://mplab.ee.columbia.edu/sites/def ... ao2017.pdf

Posted: **Sat Jul 10, 2021 1:54 am**

Some reasoning to justify my theory.
Motor torque vs speed (Nissan Leaf motor)

In above picture the grey 80kW line would also be the base speed of the motor.
If requesting 200Nm by applying a certain amount of pedal the MTPA will provide current distribution along the blue line up to about 3500rpm which is the base speed for this current. Above 3500rpm the request is till 200Nm but VCLMT will provide as much torque as possible using another current distribution. Then, when reaching desired speed of 7000rpm the pedal is changed to a request of 25Nm and the current distribution is back to MTPA as soon as the requested torque is below the base speed limit, roughly 110Nm @ 7000rpm.

The VCLMT will provide as much torque as it can independent on the throttle position but it will only command current above base speed so as soon as the requested torque is below base speed the MTPA is back in control providing pedal controlled torque.

At this point it makes sens to me.

Posted: **Sat Jul 10, 2021 9:07 am**

That looks very promising. So with that reference current regime the field weakening controller would be no longer needed as MTPV provides sufficient field weakening current anyway. On the downside we would need parameters for flux linkage, Ld and Lq. Maybe with some sane defaults tuning can be kept to a minimum.

Posted: **Sat Jul 10, 2021 10:50 am**

At this point using some default values for fluxlinkage, Ld and Lq for the MGR make sens. I expect these parameters to vary between different motors but they are possible to measure but requires a oscilloscope, a current probe and a decent current supply.
I think it might be possible to meassure these parameters using the inverter and some sort of measuring SW/interface but probably reqires a lot of work.

When looking in the ods calculation it seems one runs out of Iq faster (at lower speed) if setting Imax higher which makes no sens to me so I'm clearly missing something?

Posted: **Sun Jul 18, 2021 9:06 am**

I have decided to give up on the MGR at the moment. I can't understand how to change the current distrubution calculation in the inverter for this to make sens. More about this i my project thread.
I guess celeron55 whas right about this, one needs to study a lot of research papers to get a better understanding.

Posted: **Fri Jul 30, 2021 11:23 am**

My MGR powered Cappuccino is off the road at the moment due to working away and a charger problem. However, I’m planning to stick with the MGR so would be happy to help with testing any ideas. I think I need to do a lot of reading to catch up with where you guys are at though…

Posted: **Fri Sep 10, 2021 5:33 pm**

I did my first test drive moving the Previa around with the MGR. Here's the graph. I haven't found anything unexpected there yet.

The tire circumference is about 2075mm and the graph shows fstat peaked at about 175Hz. This means my speed peaked at 47km/h. (4 polepairs, 6.9:1 gearing)

It does look like ud is maxing out so it's running out of voltage, which is as expected.

At the middle of the graph I was driving up a hill (the one I coasted down a bit earlier in the graph) and you can see even while the motor drive was maxing out the speed dropped about 5km/h. This is not surprising as the motor was accepting only about 8kW. I have measured I need about 9kW to move the other Previa at a steady 50km/h on a level gravel road, so this all checks out.

EDIT: My plan is to try the throtid/throtiq firmware next. Once I have reasonable acceleration I'll try going on the highway, but I'll have to figure out battery management and charging before that.

Posted: **Sat Sep 11, 2021 5:40 am**

I still have my MGR in my Clio, which now is road legal, so I can test stuff if needed.

I also have some SW from a evaluation kit from a large semiconductor manufacture regarding salient PM motors which I'm thinking is a good starting point for better FW functionality.

celeron55: Would you be interested to have a look at this SW?

Posted: **Sun Oct 03, 2021 8:32 am**

johu wrote: ↑Wed Jul 07, 2021 6:52 pm Now given the hunch that MTPA does nothing useful at higher currents I decided to bring back an old friend: throtid and throtiq. So now you can manually set which current component you want. I think you might obtain higher torque at high speed when throtid exceeds throtiq. So like throtiq=1.5 and throtid=-2 or so.

Maximum FW current is throtid*50.

The firmware has some quirks at low speed, ignore that for now.

source here: https://github.com/jsphuebner/stm32-sin ... oMTPA-test

What do you think about ffwstart combined with this?

I'm currently readying the car for the next test run, might still take a day or two.

Posted: **Sun Oct 10, 2021 4:09 pm**

johu wrote: ↑Sun Oct 10, 2021 2:46 pm
bexander wrote: ↑Sun Oct 10, 2021 9:38 am Regarding the timing of the SW I think the offset in the syncadv calculation maybe coule be removed?
int syncadv = (frq - FP_FROMINT(20)) * Param::GetInt(Param::syncadv);
What will happen if this is set to 0?
there will be a bit more oscilation when driving slowly.

Ok. Is it possible that ffwstart can make the low speed oscilation less pronounced?
Maybe I can test this when my car is working again.

Posted: **Mon Oct 11, 2021 3:30 am**

I'm planning to continue this now: viewtopic.php?p=29393#p29393

The plan:

I think the syncadv trick is doing something like this:

And the FW controller is trying to do something like this:

The cross reference: viewtopic.php?p=32535#p32535

Posted: **Mon Oct 11, 2021 8:22 am**

bexander wrote: ↑Sun Oct 10, 2021 4:09 pm Ok. Is it possible that ffwstart can make the low speed oscilation less pronounced?
Maybe I can test this when my car is working again.

Yes, but those are two independent "oscillators". syncadv causes oscillation because the frequency calculation jitters. fwkp causes oscillation because iq always deviates from iqref a bit and that change translates to fwkp*delta amps. So if fwkp=-100 and there is a deviation of 1A it would cause -100A extra id

edit: that said, maybe using a filtered frequency for syncadv would be superior to just blanking it below 20 Hz.

Posted: **Mon Oct 11, 2021 10:13 am**

johu wrote: ↑Mon Oct 11, 2021 8:22 am Yes, but those are two independent "oscillators". syncadv causes oscillation because the frequency calculation jitters. fwkp causes oscillation because iq always deviates from iqref a bit and that change translates to fwkp*delta amps. So if fwkp=-100 and there is a deviation of 1A it would cause -100A extra id

edit: that said, maybe using a filtered frequency for syncadv would be superior to just blanking it below 20 Hz.

In my mind the blanking part contradicts what the syncadv is meant to do. To my understanding it is to compensate for a time delay of 153us in position measuring circuitry. But using (frq-20)*gain gives a delay that is only correct for on speed? For any other speed it either overcompensates or undercompensates.
For correct compensation at 6000rpm (100Hz rotor, 200Hz stator) with pole pair ratio of 2 the syncadv needs 2000 (65536*153u/( 1/(100*2))) and so a gain of 11,1.
Then at 3000rpm needs 1000 but gets (100-20)*11,1 = 888 and at 9000rpm needs 3000 but gets 3108.
So if it is possible to use a filtered frq I think it will be better. I don't think this will effect the FW behavior though. Just trying to avoid having to compensate for something that shouldn't be there in the first place.

EDIT: Maybe better to move this to the "Halved current during FW" thread as this is a bit of topic?

Posted: **Mon Oct 11, 2021 7:30 pm**

I'm trying to beat myself in my syncadv game using a custom frequency-dependent MTPA function like this. Not much luck so far. Still needs syncadv to perform well, which is a mystery to me. I'm also disabling the FW controller because it's so uncontrollable and that's unacceptable for tests. Attached also some drawings that probably mostly show I'm descending into complete madness.

What I think I'm doing is trying to hunt the sweet FW spot where the motor is getting exactly the right amount of id, not too much and not too little, to most effectively weaken the field, and I think I'm not hitting it. I'm trying to figure out where I might actually be in relation to that spot, but no luck so far. It's a 3-dimensional space with id, iq and frq and I really only can figure out the average torque at a single squiggly line per each breakneck run through the woods.

And I don't even know if the inverter is actually doing what it says - the way syncadv is affecting everything in ways I can't otherwise recreate isn't reassuring at all. It's like there's a physical delay somewhere that we don't know about.

I wish I had a dyno. Maybe I need to make one. EDIT: ...well, if someone sponsors me 2 more MGRs, I'll weld them locked and connect the flanges. Then I can drive one and use the other as a load.

Code: Select all

void FOC::Mtpa(int32_t frq, int32_t is, int32_t& idref, int32_t& iqref)
{
   // This control is an attempt to run the Q211 MGR optimally without syncadv
   // changes
   // Mapping from frq to iq, id factor:
   const int32_t map_length = 9;
   static const float map[map_length][2] = {
      {1.2f, -0.55f}, // 0 Hz
      {0.6f, -1.15f}, // 50 Hz
      {0.38f, -1.1f}, // 100 Hz
      {0.27f, -1.04f}, // 150 Hz
      {0.22f, -1.02f}, // 200 Hz
      {0.19f, -1.00f}, // 250 Hz
      {0.18f, -1.00f}, // 300 Hz
      {0.17f, -1.00f}, // 350 Hz
      {0.16f, -1.00f}, // 400 Hz
   };
   const int32_t frq_step = 50;
   int32_t frq_i = frq / frq_step;
   if(frq_i > map_length - 2)
      frq_i = map_length - 2;
   float frq_f = (float)(frq - frq_i * frq_step) / (float)frq_step;
   if(frq_f >= 1.0)
      frq_f = 1.0;
   
   iqref = ((1.0f - frq_f) * map[frq_i][0] + frq_f * map[frq_i+1][0]) * is;
   idref = (((1.0f - frq_f) * map[frq_i][1] + frq_f * map[frq_i+1][1]) * is) *
         (is < 0 ? -1 : 1);
}

Code: Select all

frq             is1     iq1     id1             is2     iq2     id2
0               100     120     -55             -100    -120    -55
10              100     108     -67             -100    -108    -67
20              100     96      -79             -100    -96     -79
30              100     84      -91             -100    -84     -91
40              100     72      -103            -100    -72     -103
50              100     60      -115            -100    -60     -115
60              100     55      -114            -100    -55     -114
70              100     51      -113            -100    -51     -113
80              100     46      -112            -100    -46     -112
90              100     42      -111            -100    -42     -111
100             100     38      -110            -100    -38     -110
110             100     35      -108            -100    -35     -108
120             100     33      -107            -100    -33     -107
130             100     31      -106            -100    -31     -106
140             100     29      -105            -100    -29     -105
150             100     27      -104            -100    -27     -104
160             100     26      -103            -100    -26     -103
170             100     25      -103            -100    -25     -103
180             100     24      -102            -100    -24     -102
190             100     22      -102            -100    -22     -102
200             100     22      -102            -100    -22     -102
210             100     21      -101            -100    -21     -101
220             100     20      -101            -100    -20     -101
230             100     20      -100            -100    -20     -100
240             100     19      -100            -100    -19     -100
250             100     19      -100            -100    -19     -100
260             100     18      -100            -100    -18     -100
270             100     18      -100            -100    -18     -100
280             100     18      -100            -100    -18     -100
290             100     18      -100            -100    -18     -100
300             100     18      -100            -100    -18     -100
310             100     17      -100            -100    -17     -100
320             100     17      -100            -100    -17     -100
330             100     17      -100            -100    -17     -100
340             100     17      -100            -100    -17     -100
350             100     17      -100            -100    -17     -100
360             100     16      -100            -100    -16     -100
370             100     16      -100            -100    -16     -100
380             100     16      -100            -100    -16     -100
390             100     16      -100            -100    -16     -100

Posted: **Tue Oct 12, 2021 7:48 am**

I probably should begin doing some no-load testing with the wheels off the ground, just to see what kind of id, iq, syncadv parameters I need in order to get to the highest possible speed. If the optimal FW spot exists and can be found, I think it should be possible to reach at least 700Hz and more as that's what Toyota's graph shows (viewtopic.php?p=13087#p13087).

Posted: **Tue Oct 12, 2021 8:10 am**

That lookup table is most flexible, nice job. Lets hope it works! We could eventually introduce an MTPA parameter that can be set to "Generic" or "MGR" and whatever other motors need LU tables

Posted: **Tue Oct 12, 2021 8:49 am**

I'm expecting the lookup table isn't needed. But it's nice to have when testing and you have no idea about what the final result should look like. Instead I'm expecting some system is needed that is able to set id very accurately, as it seems in this case it can't just flail around along with the throttle position.

Posted: **Tue Oct 12, 2021 8:59 am**

Also just pushed code that uses filtered rotor frequency for calculating syncadv instead of blanking the first 20 Hz. Filter constant is a bit arbitrary, hope it is still quick enough.

Posted: **Fri Oct 15, 2021 1:26 pm**

Just found some interesting code in googles makani firmware: https://github.com/google/makani/blob/m ... foc.c#L290

Posted: **Fri Oct 15, 2021 3:34 pm**

I have the vehicle on jackstands with the wheels off now. If needed, I can try any code as long as you promise fmax works.

My plan is to first try to smooth it out - the code and settings it's currently running are absolutely terrible above about 50Hz. In fact that's why I removed the wheels: It felt like I wasn't going to have any splines left in my wheel hubs after testing. Looks like the only reason it felt stable at 80km/h was because it couldn't maintain speed without full throttle.

Posted: **Fri Oct 15, 2021 6:19 pm**

In today's testing it looks like a high fwkp is absolutely necessary for reasonably smooth operation. The critical speed above which the field weakening controller is needed is 150Hz. My code edits don't affect the smoothness really at all - it's all terrible without using the field weakening controller at high gain.

Posted: **Sat Oct 16, 2021 6:31 pm**

How high is your gain?

Forgot to comment and that code above, it seems to try and restrict modulation to 95% by increasing id. It's a thought I had way back but thought it was stupid. Will try and implement that and have some of you masochistic guinea pigs try it

Posted: **Sat Oct 16, 2021 7:07 pm**

johu wrote: ↑Sat Oct 16, 2021 6:31 pm How high is your gain?

Forgot to comment and that code above, it seems to try and restrict modulation to 95% by increasing id. It's a thought I had way back but thought it was stupid. Will try and implement that and have some of you masochistic guinea pigs try it

Who exactly do you mean???

Posted: **Sat Oct 16, 2021 8:13 pm**

I tried fwkp=300 and it seemed ok but not perfect. Of course no load behavior can also be completely different to full load behavior.

However my CV axle flew off and I had to pause testing. Will get back to it of course once I get my axle sorted.

openinverter forum

Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Previa madness vol.2, (i.e. oh no, celeron55 is messing around again!)

Re: Halved current during field weakening

Re: Previa madness vol.2, (i.e. oh no, celeron55 is messing around again!)

Re: Previa madness vol.2, (i.e. oh no, celeron55 is messing around again!)

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening

Re: Halved current during field weakening