IPM Motor - Auto-setup

[Ev8]

Didn’t Romale also have no resolver angle plot ?

[Bigpie]

oops, been a long week. It seems the angle plot doesn't work. I tried resolver check and nothing. Swapped to a release version (4.94) and resolver works fine.

Edit - udc sounds like a software rather than hardware issue but not sure what it could be, do all the other analogue inputs work?

Not sure, need to debug further maybe probe the stm32 pin

[Pete9008]

That's wierd, didn't think I touched any of the resolver code (and double checked after Romale had problems). Have to have another look, must have messed up something.

Are the other analogue inputs working (temperatures and currents)? Just wondering if it's something to do with the adc given the problems with udc too?

[Bigpie]

Not looked at temperature. But I'm guessing the current sensors are working, the inverter has control of the current.

[Pete9008]

Just wondering if I forgot to hook in the code that generates the resolver output square wave? Thought it was part of the code that updates the angle but need to double check.

[Pete9008]

Might have found it. The resolver code is working fine, the value just isn't getting written to the angle spot value correctly.

Line 355 of pwmgeneration-foc.cpp needs to change from

Code: Select all

Param::Set(Param::angle, DIGIT_TO_DEGREE(angle));  

To

Code: Select all

Param::SetFixed(Param::angle, DIGIT_TO_DEGREE(angle));  

Sorry about that Will update on the PC and push to github tomorrow.

[Ev8]

Nice one good find!

[Bigpie]

Seems to plot now, suspiciously the angle and test angle seem to be the same regardless of syncoffs value

[Pete9008]

One step forward ......

Doesn't look right, fairly sure both are showing the resolver angle but no idea why, had another look through the code and it seems to be ok. Does a resolver check now read the angle correctly?

Could you try grabbing a plot with both the plot size and burst length set to 1000 to see what it looks like then?

Long shot but might be worth doing a full chip erase and reloading the code. Bit suspicious that going back from 5.27 to earlier versions leaves something in flash that the parameter store doesn't like, if so an erase and reload might help??

Edit - just trying a couple of things here and I'm having trouble getting the plotting to work well enough, best seems to be with burst set to 1 and 100 data points (anything else gives a stepped waveform due to the bursts).

Edit2 - Even then there are sometimes fairly nasty plotting artefacts. Going to code up the syncoferror stuff which should give better results.

[Bigpie]

I do a full chip erase and reflash bootloader and firmware each time. The WiFi seems too poor to stream reliably even though the laptop is less than a meter away and the esp8266 is not inside a metal case or anything.

[Bigpie]

The angle plot looks ok in resolver test mode.

[Pete9008]

Looks OK, not sure what to make of the test angle bug

Just done the sync error bit on the F405 (as that's what I can test here), results look ok. This is what a plot looks like with syncofs set to 0:

You can see the average value of the syncoferror is around 5800. If this value is then written to the syncofs parameter you then get:

So an average error of 0 (allowing for the offset due to rotor drag/id only drive in each direction).

Tried filtering the error signal but could only get the IIR filter to work well with floating point arithmetic, which is no good on the F103, so the user will just have to visually average it for now. There are other averaging approaches I could try on the F103 but see if this works first.

Going to port it over to the F103 now and then push to github, will post here when done.

Edit - Changes now on github in the auto-setup-withlogging branch.

[Pete9008]

Averaging now working. Added an extra parameter syncofferrav (need a better name!) which is updated once per motor cycle and contains the error, on my setup it is surprisingly clean and gives an offset repeatable to within around 10 units!

This is the result with syncofs set to 0:

after it's run for a few motor cycles the value of syncoferrav is the value that should be written to syncofs (as long as syncofs was previously 0), in this case 5681.

If the test is then rerun you get this:

error of 0 now reported.

Worth noting that syncoferr is always reported as a signed number (to stop errors around 0 causing the plot range to go from 0 to 65535) while syncoferrav is always reported as an unsigned number so that it is easy to use it to set syncofs. Not quite intuitive (especially if syncoferr is negative) but it seems to be the best compromise.

Porting it over to the F103 now.

Edit - now on github

[Pete9008]

Just had a look at the options for getting manual test mode to close the contactors and the conclusion I've come to is I don't know that area of the code well enough (an my brains not currently working well enough to figure it out) to be confident that any changes won't have unforeseen consequences.

Afraid it's going to have to wait a little while longer.

[Bigpie]

Still the same for me, nothing jumps out from the code, but I'm not an expert

Values are exactly the same

[Pete9008]

I was hoping it was just a problem reading the parameter (and so the new code would still work) but it looks like it is something actually in the test code. I'll have another look

No idea! Had another look through the code and I just can't see how they can be the same.

If you plot both in resolver check mode do they still track (testangle shouldn't be updated at all in that mode)?

Assume the value of syncofs still has no effect on them in test spin modes?

[Bigpie]

syncofs still has no effect. I've been trying to follow the code as best I can and can't see anything.

Test angle stays at 0 in resolver check

EDIT

is this macro the issue

Code: Select all

#define DIGIT_TO_DEGREE(a) FP_FROMINT(angle) / (65536 / 360)

should it be?

Code: Select all

#define DIGIT_TO_DEGREE(a) FP_FROMINT(a) / (65536 / 360)

[Pete9008]

Nice find!

Just pushed the change to github and was just about to post here, found it around the same time as you by the look of it!

Hopefully that will sort it

Edit - this is why I dislike burying too much in macros, I must have looked at that line a hundred times without diving into it because it has always worked!

Edit2 - Just checked my F405 code, I'd already fixed it without realising when changing things to use float arithmetic

[Bigpie]

Getting there now. Forward test doesn't spin anymore though. It starts to rotate then rotates back. I tried more Id but no full rotation.

This one shows I had incorrect ratio for motor pole pairs and resolver pole pairs

Forgot to screenshot the bidir test.

Will pick back up tomorrow. This is awesome

[Pete9008]

Looking good

No idea why the forward test isn't working now, had changed a small bit of the code round there (just to zero the error parameters in that mode) but nothing that should affect the rotation. Just had a look over it and can't see anything obvious.

Looks like there are still some plotting artefacts there that aren't helping. I've started using a burst length of 1 which seems to help a little.

Looking forward to seeing whether the calculated offset it gives matches the value you found before.

Thanks for all the testing and debugging!

Edit - One thought, what values are you using for curkp and curki, are they sensible for the motor inductance? If the loops are a little unstable that could cause problems on the forward and bidir tests. Might be worth plotting the currents to see what they are doing?

[Bigpie]

I'm using same values for those that I use in the car.

I let it run a minute and it resulted in an average error of 11778.

I put this in syncofs and run another minute

average error was 0 after this.

I then though I'd try normal running and the motor started spinning up and accelerating without any throttle input. Still progress
Packing up for the night for sure now

[Pete9008]

Looking good although it realy should be following the field better than that, those errors seem very large. What Id are you running at the moment?

What syncofs value did you get using the iq null method?

Edit - which motor is this?

Edit2 - something also doesn't look right on the second plot, there is no way the syncoferr trace averages to 0, there must be a lot of other stuff going on that isn't being captured by the plot??

[Bigpie]

This is an outlander front motor. That was I think 35A Id

I'm not convinced I found the offset with manual, I didn't have throttle control either on pre Pete firmware, but it was in the 34000 region.

[Pete9008]

Ki/kp should be near enough then and I'd have thought 35A would be enough.

Is the intermittent udc problem still there? Is the forward spin still stalling?

Edit - I'm wondering if there could be a resolver noise problem that is only present while the pwm is running? It might be worth doing a forward spin test tomorrow with id and iq set to zero (so pwm is on but no current and so no torque) and slowly manually turning the motor while plotting the angle?

[Pete9008]

This is an outlander front motor. That was I think 35A Id

I'm not convinced I found the offset with manual, I didn't have throttle control either on pre Pete firmware, but it was in the 34000 region.

Just realised why it's not working too well, it's something else I've done before but forgotten (brains really not working too well at the moment, pretty sure I even commented on it in my build thread when getting my motor spinning!).

Because it's running at a lower voltage all the gains (ki, kp) are way too low, they need increasing, ideally by the ratio of normal to test voltage, so in yor case by around a factor of 8! (probably best do it as a number of steps, each a factor of two till it stops improving, shouldn't need the full x8 as we're not after max performance here).