IPM Motor - Auto-setup

Post Reply
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

IPM Motor - Auto-setup

Post by Pete9008 »

I think I may have finally worked out how to do a full auto setup of an IPM motor. I don't have hardware yet, and when I do it will be for the wrong processor, so I have no plans of actually implementing this at the moment (some bits of it may end up in my code) but thought it worth putting here to both record the ideas and also in case anyone else fancies having a go at it (on the condition that any code produced is open source). It's also far from a complete solution and there is plenty of detail which would need to be added.

Thie idea it so get from a basic setup to one that is fully characterised for full MTPA/MTPV field oriented control of a motor in an automated process.

It is worth noting that at a number of points in the test the motor needs to be spun before it has been fully characterised. To allow this the motor is always run in 'stepper motor' mode, i.e. just following a fixed rotating magnetic field (direct Id current). While this offers fairly poor torque, and poor control of the rotor position, it is safer (no potential for motor speed run-away) and needs no complicated control processes. This is equivalent to the use of the sin software in the existing set up process.

The basic process is:
1) Setup basics
It would be up to the user to set up the basics, essentially check the board version is being reported right (so that pins are in the right place and being driven correctly), calibrate the sensors/analogue inputs and ensure that the dead-time is setup correctly.
2) Spin the motor.
This would just apply a low current, low frequency, rotating magnetic field to the stator (no control just fixed rotation speed, current would be set based on manualid). It would be up to the user to determine whether the motor span, if the motor did spin then the firmware would look at the phase of the voltages driven onto the motor and the currents measured and set up the pin-swaps accordingly.
3) Learn resolver parameters.
The firmware would then step the motor windings through a pattern. First it would inject current into phase 1, then into phase 2 and finally into phase 3. For each of these states it would measure the resolver output. It would then repeat this pattern until the resolver output matched the initial output with phase 1 energised. From the measurements it would be possible to determine whether either the configuration is correct, a sin/cos swap in the firmware is needed or a hardware pin swap is needed. If either of the last two the pin swap would be made and the test repeated. Once the resolver output gave an increasing angle delta of 120degrees for each step, with the pattern repeating after x rotations, it would be possible to calculate the motor to resolver pole pair ratio and the scynofs value. While this can't actually determine the absolute value of pole pairs for both the resolver and motor all that is needed to control the motor is the ratio of the two. If the absolute values are important then the user would need to enter the value for the motor pole pairs. Due to the poor rotor position control in stepper motor mode the process would be run a few times with increasing Id, once the readings settle then there is enough Id to hold the rotor accurately in position.
4) Test spin
The firmware would spin the motor, at low speed and check that the phase relationship of the Ud, Uq, Id and Iq currents make sense. If they do then it confirms that the resolver is correctly set up.
5) Learn flux linkage
To learn the flux linkage the firmware would again spin the motor up to a modest speed then set the currents to zero and measure Uq as the motor span down. From this the flux linkage can be calculated. Steps 4 and 5 could be combined.
6) Learn Lq and Ld
To learn Lq and Ld the motor again has to be spun at a modest speed. Once up to speed 1ms? long pulses of current are injected into either Iq or Id. The resulting voltage deltas on Ud and Uq are measured and the voltage delta, current delta and speed used to calculate Ld and Lq. The 1ms pulse would hopefully be too short to affect motor speed while being enough to measure the delta. While the resolution will be such that a single measurement will be noisy the average of a few hundred will hopefully give good accuracy. This technique could also be used to measure Ld and Lq live in the real FOC code too. It could also be used at varying load currents to fully characterise how motor Lq and Ld change with load.

This should work with either a bare motor or with a motor attached to a drivetrain (but with axles free to spin).

Once all the above are done it should be possible to run the motor in full FOC mode with both MTPA and MTPV fully characterised.

Interested to hear thoughts, problems, alternatives, etc.

My main thought is whether it's worth the bother? If the user can use existing techniques to get to a basic setup that is good enough to spin the motor (step 4 equivalent) then a log can be generated and fed into the calculator viewtopic.php?t=3047 and that would give the same results. Not quite as polished but already available.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 154 times
Been thanked: 960 times
Contact:

Re: IPM Motor - Auto-setup

Post by johu »

Yes good to discuss these ideas again. Resolver auto-tuning has often been proposed but I never picked up on it because lazy.
Would this be in a separate firmware? During the chip shortage I had to sell a few boards with 64k flash, leaving 57k for firmware. Right now we're at 49k. The sine table could be shortened from 8k to 2k by storing just a quarter period. Different topic though.

Concerning resolver detection, after determining that stator field and resolver field spin in the same direction, it could be more straight forward to do it similar to #5. Spin up the motor (speed calculation already works with wrong syncofs) then let it coast and adjust syncofs until ud is 0 (on average). What do you think?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

johu wrote: Tue Jan 17, 2023 7:12 pm Yes good to discuss these ideas again.
Any links from previous discussions (I'd rather not waste time repeating stuff if it's been covered somewhere before)?
johu wrote: Tue Jan 17, 2023 7:12 pm Would this be in a separate firmware? During the chip shortage I had to sell a few boards with 64k flash, leaving 57k for firmware. Right now we're at 49k. The sine table could be shortened from 8k to 2k by storing just a quarter period. Different topic though.
Not fussed either way. Can't see it taking up much additional space. At the moment a different firmware (the sin build) has to be used for the first spin anyway so maybe a separate app is the way to do it?
johu wrote: Tue Jan 17, 2023 7:12 pm Concerning resolver detection, after determining that stator field and resolver field spin in the same direction, it could be more straight forward to do it similar to #5. Spin up the motor (speed calculation already works with wrong syncofs) then let it coast and adjust syncofs until ud is 0 (on average). What do you think?
Couple of reasons why I went this route. Firstly it minimises the amount, and speed, of spinning before confidence is built up. Secondly it allows the measurement to be validated in the next step - the resolver characteristics are measured in step 3 using one technique and then validated using a different technique in step 4 (when checking that Uq, Ud, Iq and Id make sense). To some extent the step 3 measurement also acts as a validation for the pin swaps in step 2. The resolver setup is fairly critical and this increases confidence that it's right.
User avatar
mikmur
Posts: 46
Joined: Sat Jul 18, 2020 7:37 am
Location: Georgia/Batumi
Has thanked: 33 times

Re: IPM Motor - Auto-setup

Post by mikmur »

I think you will be interested
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: IPM Motor - Auto-setup

Post by celeron55 »

I think as long as someone has the time and knowledge to do this, it should be done. Not because it's strictly needed, but to:
- Make it safer to set up a new motor
- Make it easy to get the most out of a motor
- Make a better new user experience
- Show off

I agree it should take just a few kB of flash to implement this. It should be just a simple state machine with about 10...20 states that mostly progress step by step (with an inactive state, start state and some extra error states where it may jump in case of issues), where every step state is checking for a few conditions, saving a few values, adjusting a few parameters and timing out after a while.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

mikmur wrote: Thu Jan 19, 2023 8:27 am I think you will be interested
Thanks for that, I'm actually using the AU6802 resolver to digital converter to provide the resolver interface on my own board which does exactly this.
celeron55 wrote: Thu Jan 19, 2023 10:51 am I think as long as someone has the time and knowledge to do this, it should be done. Not because it's strictly needed, but to:
- Make it safer to set up a new motor
- Make it easy to get the most out of a motor
- Make a better new user experience
- Show off

I agree it should take just a few kB of flash to implement this. It should be just a simple state machine with about 10...20 states that mostly progress step by step (with an inactive state, start state and some extra error states where it may jump in case of issues), where every step state is checking for a few conditions, saving a few values, adjusting a few parameters and timing out after a while.
Struggling for time and energy at the moment so for me it's going to have to stray on the back burner. Will probably have a go at step 3 and possibly 5 and 6 when I start commissioning my hardware but the code will be for the F405 processor. Should be easy enough to port over to the F103 though.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Just started writing some code to test my motor, essentially steps 2) Spin the motor and 3) Learn resolver parameters from above. On running it in the simulator it has become clear that, as normal, it's not quite as simple as it first seems. The motor tends to oscillate around the D position when first energised and the degree of oscillation and the time for it to decay depend on quite a few things (mass of drivertrain, PI parameters, motor parameters, etc). So I'm going to give up on automating it for now.

Instead I've reinstated manual mode which now completely ignores the resolver and instead forces the motor to run at low speed using current set using idmanual. This can then me used for initial motor phase connection testing in place of the sin firmware build. I've also added an extra parameter, testangle, which is the angle the motor is driven to. By plotting or logging this against the existing angle parameter (the measured angle from the resolver) it should be straightforward to work out the correct value for syncofs (either iteratively visually, when they overlay, or via a spreadsheet).
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Had another thought on this overnight, on step 6) Learn Lq and Ld in the first post.

It's occurred to me that a simpler way to do this would be with the motor stationary. If a lowish Id is applied to the motor, say 10-20A it will lock the rotor into a position aligned with the D axis. It would then be possible to apply brief pulses, say 1ms long, of current to the D and Q axis in turn. Measuring the voltage change vs current change during the pulse would allow Ld and Lq to be calculated. Will probably try implementing this to see if it works.

I'm thinking of adding another parameter, something like learnmode, to allow this. This should default to none on power up. Before going into manual mode this would need to be set to either testspin or learnldlq (if left at none manual mode would be disabled), then when manual mode was entered the inverter code would either slowly spin the motor or learn Ld and Lq. Other modes could be added in the future to add the other features. The reason I like this is it makes it difficult to accidentally get into manual mode as it effectively becomes a two step process.

Question - is it possible to have a parameter that ISN'T persisted to flash but that is reset to the default value on every power up?

Edit - looks like you just set the ID to 0 to stop a parameter being persisted to flash.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 154 times
Been thanked: 960 times
Contact:

Re: IPM Motor - Auto-setup

Post by johu »

Pete9008 wrote: Sat Feb 11, 2023 1:48 pm Question - is it possible to have a parameter that ISN'T persisted to flash but that is reset to the default value on every power up?

Edit - looks like you just set the ID to 0 to stop a parameter being persisted to flash.
Yes you found it although this might change in the near future: viewtopic.php?p=52741#p52741
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

New idea for step 1) (Setup Basics) above, adding here so I don't forget.

Until the current sensor and phase pairings are correct none of the other steps will work so this needs to be done as part of step 1. To automate this we just need to impose a small sinusoidal voltage onto each phase in turn (other two phases obviously driven in antiphase). The frequency and voltage are selected so that a relatively low level current is generated. Then monitor i1 and i2 currents, calculate i3 and check their phase of each with regard to the phase being driven.

The output is the phase of each measured current for each driven phase displayed as an ascii string in the form:
^vv : v^v : vv^ (or 0 if no current measured)
I.e. increasing current only on the driven phase. If a different pattern was produced it would be up to the user to implement pin swaps or fix problems to get to the correct pattern.

Could also check that the current ratios are as expected too.
User avatar
Romale
Posts: 441
Joined: Fri May 20, 2022 4:16 pm
Location: Romania
Has thanked: 204 times
Been thanked: 45 times

Re: IPM Motor - Auto-setup

Post by Romale »

Pete9008 wrote: Wed Apr 12, 2023 6:14 pm New idea for step 1) (Setup Basics) above, adding here so I don't forget.
I wish I could see it in the working firmware already :!: :o
evil neodymium :twisted:
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Finally got back to having a look at the automatic detection of the CT vs IGBT phasing/polarity.

The initial idea didn't work too well - essentially performing the measurement quickly means that the motor inductance adds phase lag to the current which messes up the measurements. Doing it slowly means you can ignore the inductance but allows the rotor to start to move which also invalidates all the results. Was about to give up when I realised I was being a bit dim - the trick is to do it quickly but then use the rate of change of current rather than the absolute value (a positive signal on phase 1 should cause the current on phase 1 to ramp up). This has the advantage that it works whether the rotor is free to move or locked.

Only run in the simulator so far bit it seems to work. Plot of the measurement process:
Phasing.png
The first bit where the voltages are ramping up is the firmware trying to find a safe level to perform the measurement. It tries to use the smallest PWM value that will give 5A measurement current. It also trips out if any phase current exceeds 20A. It then generates phase voltages with the rotor field at 0, 120 and 240 degrees and looks to see what the currents do. The current waveform doesn't make a lot of sense unless you look at rates of change rather than amplitude.

Currently the results are only available via the debugger and look like this:
PhasingRes.png
PhasingRes.png (13.32 KiB) Viewed 3162 times
Could be clearer but you can see that:
On check 1 (c1) only phase 1 (p1) is positive
On check 2 (c2) only phase 2 (p2) is positive
On check 3 (c3) only phase 3 (p3) is positive.

Which indicates that the phasing is correct. Eventually this will be presented as described in the above post.

The idea mentioned in the last post about checking current ratios doesn't really work because of motor saliency and variable rotor position.

Still need to test it on a real motor but it's looking promising.
User avatar
Romale
Posts: 441
Joined: Fri May 20, 2022 4:16 pm
Location: Romania
Has thanked: 204 times
Been thanked: 45 times

Re: IPM Motor - Auto-setup

Post by Romale »

Pete9008 wrote: Mon May 01, 2023 7:12 pm
Still need to test it on a real motor but it's looking promising.

I would be happy to test it if there is a similar one.the bin file for the firmware. a motor with an inverter and a battery is always at home on the desktop to check various systems.
evil neodymium :twisted:
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Thanks for the offer but afraid it's only coded up for the STM32F405 processor at the moment. Once it's been tested on a motor I'll look at how to get it ported back onto the F103 family.

Really hoping to get some testing done on a real motor soon so hopefully won't be too long.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Had a first go at an inverter/motor setup using the new technique and so far it seems to work quite well.

Basically I've reintroduced the manual run mode which now has 4 modes of operation. I'll cover each in a separate post as it's probably a bit long to do all in one. In this one I'll just cover the basics.

First up Resolver testing. To use you first go to the Testing section of Parameters in the web page:
testmode.png
Change 'testmode' to 'Resolver' (note this parameter always defaults to off on power up):
resolver.png
Then go to the commands section and hit 'Start Inverter in manual Mode':
Start.png
You should see this in the Messages section of the web interface:
resStart.png
resStart.png (8.32 KiB) Viewed 3075 times
This will start sampling the resolver but without starting the PWM (so there is no power to the motor). The motor shaft can then be rotated while plotting the 'angle' parameter so see the result. You are looking for something like this:
resPlotRev.png
Now this is with the motor being turned in my notional forward direction but it can be seen that the angle is decreasing. To fix this swap the wires on either the sin or cos resolver connections to get:
resplot.png
Final thing worth noting. If the motor and resolver pole pairs are both set to 1:
pp1.png
pp1.png (7.51 KiB) Viewed 3075 times
Then this plot can be used to determine the resolver pole pairs. On the above plots you can see that a single rotation of the motor shaft gives three rotation on the plot so this resolver has 3 pole pairs.

The resolver pole pairs should then be set to the value found. If the resolver came with the motor then safe bet is to also set the motor pole pairs to the same value (later steps will check whether this is correct).
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Next is the PhaseCheck.

This is used to make sure that the CTs are on the correct PWM phases and that their polarity is correct.

This test needs a HV supply to be connected although it doesn't actually need to be high voltage, I'm using around 20V. The udc parameter also needs to be reading correctly (udcofs and udcgain correctly set) as it uses the value to scale how much PWM value is needed to achieve the desired motor voltage (the higher the voltage the smaller the PWM value for the same motor voltage). The ilxgains should also be in the right ballpark.

First change the testmode to PhaseCheck:
PhaseCheck.png
An then 'Start Inverter in manual Mode' as before. This will start the PWM up, perform the test, disable the PWM and then the result will be reported in the message are of the web interface. At the end of the test the inverter opmode will be back to the Off state.

The results will vary depending on the motor and how it is connected. The test aims to apply the lowest voltage needed to the motor and ramps it up till the current is high enough for a reliable test. If the max voltage allowed (up to ~20V) is applied the motor and it isn't enough to get 5A to flow then it will report:
LowCurrent.png
LowCurrent.png (7.62 KiB) Viewed 3064 times
If the current exceeds 25A at any point during the test then this will be seen:
HighCurrent.png
HighCurrent.png (7.56 KiB) Viewed 3064 times
Otherwise the test will ideally give this:
PassResult.png
PassResult.png (5.67 KiB) Viewed 3064 times
This is showing the result of three tests, the first apples current to phase 1, second to phase 2 and third to phase 3. It then reports how the phase of the currents on each phase relate to the applied voltage. A ^ indicates that the current is in phase, a v indicates that the current is out of phase. For a correctly connected motor phase 1 should be the only one in phase on the first test (^vv), phase 2 should be the only one in phase for the second test (v^v) and phase 3 should be the only one in phase for the final test (vv^).

If the motor connection isn't correct different patterns will be seen.

This will be seen if the CTs are connected the wrong way round (current polarity inverted):
InvertedResult.png
InvertedResult.png (5.4 KiB) Viewed 3064 times
This will be seen if two of the phases (2 and 3) are swapped:
PhaseSwap.png
PhaseSwap.png (5.61 KiB) Viewed 3064 times
Which would normally be fixed by enabling the PWMOutput23 pinswap:
PinswapParam.png
PinswapParam.png (5.26 KiB) Viewed 3064 times
If the CTs are inverted and there are phases swapped then:
InvertedAndPhaseSwap.png
InvertedAndPhaseSwap.png (5.43 KiB) Viewed 3064 times
If any currents drop below a threshold then the v or ^ is replaced by a 0. I've not been able to get this to occur yet though (works in simulation but on a real motor it just fails the test on low current when a phase wire is disconnected).

Hopefully this is a fairly clear way of presenting the data and makes it clear what needs to be done (it also works in with the ascii message response) but if anyone thinks there is a clearer way please let me know.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

And finally syncofs tuning using the ForwardTestSpin and BidirTestSpin modes.

These modes simply run the motor with pure D current but very slowly so that the motor has time to align itself closely to the field. In this mode the torque is pretty limited so it's best done with the motor shaft isolated from any gearbox or clutch.

The first mode to use is ForwardTestSpin. It is selected in testmode as before, the value of Id to be used is set (10A seems a safe starting value):
ForwardSpin.png
and then start the inverter in manual mode as before (note the inverter will continue to run in this mode until stopped using the Stop Inverter button).

The motor should turn slowly and on plotting 'angle' and 'testangle' something like this should be seen:
DirWrong.png
Now the thing to check on this plot is that the two plots move together, they clearly don't on this one and that is because the motor is actually spinning backwards! Swapping two of the motor phases and re-running gives:
DirRight.png
The plots are now moving together and are parallel to each other. If they are this is an indication that the ratio of motor poles to resolver poles is correct. If the resolver poles have already been set in the resolver step you can be confident that the motor poles value set is also right. If one trace is moving faster than the other adjust the motor poles till the pair move together.

There is still an offset between the two. This is because syncofs hasn't been set up yet. To do that just measure the vertical separation between the two plots using the web page cursor. I measured 198.71deg for angle and 236.06deg for testangle. The difference here is 37.35deg. This needs to be multiplied by 65536 (syncofs for 360deg) and then divided by 360 to give the value for syncofs. So 37.35*65536/360 = 6799, call it 6800. Now because the angle is lagging testangle this value needs adding (if it was leading it would need subtracting) to whatever value was in syncofs (ideally 0) when the above test was run. So setting syncofs to 6800 and re-running gives:
SyncofsCorrected1.png
Much better but not quite there yet. Because of the low torque on the motor in D only mode any drag on the rotor will cause an offset. To try and address this the BidirTestSpin mode is used. To use stop the inverter, change the mode and restart. On plotting again this is seen:
BiDir_10A.png
This looks reasonable but it can be seen that on the forward rotation the angle is actually leading slightly and on the reverse rotation the angle is lagging. This is because the measurement above is compensating for lag in one direction but making things worse in the other. To show the effect reducing the D current from 10A to 2A makes things worse:
BiDir_2A.png
The lower torque means more lag and it angle is now lagging in both directions. To minimise this the D current is increased a bit to 15A (in real life you could go a lot higher but I'm running this from a bench PSU) giving a new baseline plot of:
BiDir_15A.png
The next thing is to swing the syncofs value by 1000 in each direction and see which way helps. So increasing to 7800 gives:
BiDir_14A_7800.png
And decreasing to 5800 gives:
BiDir_14A_5800.png
So 5800 is better. Going another 1000 down to check - 4800:
BiDir_14A_4800.png
Worse again so 5800 is the optimum value for syncofs.

Now the sensible thing to do next would be to work out syncofs the traditional way and see how they compare - but not tonight.

Not sure whether this technique is going to be quite as sensitive as the old way and it might still be necessary to tweak this value using the old technique. It does have the big advantage that it provides a clear (hopefully!) step by step process without the trial end error previously needed.

This technique also avoids any confusion associated with the second null seen in the traditional syncofs technique. This approach should always find the right syncofs value.

Edit - Forgot to say, the ripple on the angle plots is due to slight cogging on the motor meaning the speed isn't quite constant. Not much that can be done about it apart from visually averaging it out when adjusting things.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 154 times
Been thanked: 960 times
Contact:

Re: IPM Motor - Auto-setup

Post by johu »

Pete9008 wrote: Wed May 10, 2023 3:41 pm Hopefully this is a fairly clear way of presenting the data and makes it clear what needs to be done (it also works in with the ascii message response) but if anyone thinks there is a clearer way please let me know.
Good stuff!
just a rough idea: maybe print something along the lines "il1 expected: 10A, il1 measured: -10A -> inverse polarity, set il1gain=-il1gain"
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Syncofs setting section now added above!
johu wrote: Wed May 10, 2023 4:02 pm Good stuff!
just a rough idea: maybe print something along the lines "il1 expected: 10A, il1 measured: -10A -> inverse polarity, set il1gain=-il1gain"
I did wonder about putting some values in the result message but didn't because the numbers within the algorithm are fairly meaningless. It uses rates of change of current rather than current and then pushes these through a phase sensitive detection type algorithm giving an integrated result over the whole test. The results are repeatable and robust enough to be reliable in the presence of noise (important as the first tests are likely done at low current levels) but don't actually mean anything so are not worth including. The 5A and 25A limits mentioned above are likely to need changing too once its been tried on a few different motors.

I'd like to keep the existing 1:^vv type format as it seems simple while also giving quite a lot of detail but I agree that it would be worth adding some interpretation. My thought was that we could add a set of 'common' patterns, each one having a string associated with it with guidance on how to fix. The code would then compare the 'v^' strings with the common ones and if it found a match append the associated guidance string.

Something like:

"1:^vv 2:vv^ 3:v^v", "Phases 2 and 3 swapped, please add/remove PMWOutput23 pinswap"
"1:vv^ 2:v^v 3:^vv", "Phases 1 and 3 swapped, please add/remove PMWOutput13 pinswap"
"1:v^v 2:^vv 3:vv^", "Phases 1 and 2 swapped, please add/remove Current12s pinswap"
etc

There are going to be quite a few of them though and I can't be bothered going through and working them all out at the moment!

I think the next thing to do is try an old style syncofs calibration and see how the two compare. Assuming it looks OK I'll port it back to a branch on the F103 repository and people can give it a try.
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor - Auto-setup

Post by Ev8 »

Awesome work it’ll be interesting to compare what syncof I get using your system!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

Just tried finding syncofs using the traditional way and came up with exactly the same answer :-)

Still think the traditional method is probably a little more sensitive. It may therefore make sense use the testmode method to find the right null and get close and then use the traditional method to fine tune.

Will try to get it ported to a version of the F103 code in the not too distant future!
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 154 times
Been thanked: 960 times
Contact:

Re: IPM Motor - Auto-setup

Post by johu »

Great!
Did you add more opmodes for the various test sequences or how did you structure it?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Mhs
Posts: 43
Joined: Fri Jul 26, 2019 8:06 pm
Location: Bahrain
Has thanked: 130 times
Been thanked: 7 times

Re: IPM Motor - Auto-setup

Post by Mhs »

Pete9008 wrote: Mon May 15, 2023 4:47 pm
Will try to get it ported to a version of the F103 code in the not too distant future!
Thanks Pete! I will be waiting to give it a try on the Outlander rear motor with the F103 code!
Prius gen3 inverter
Outlander rear motor
Pajero 1990
User avatar
Romale
Posts: 441
Joined: Fri May 20, 2022 4:16 pm
Location: Romania
Has thanked: 204 times
Been thanked: 45 times

Re: IPM Motor - Auto-setup

Post by Romale »

Pete9008 wrote: Mon May 15, 2023 4:47 pm Just tried finding syncofs using the traditional way and came up with exactly the same answer :-)

Still think the traditional method is probably a little more sensitive. It may therefore make sense use the testmode method to find the right null and get close and then use the traditional method to fine tune.

Will try to get it ported to a version of the F103 code in the not too distant future!

I have repeatedly noticed that the traditional method has become inaccurate. For example, by changing the syncofs with a rotating motor, I get to the situation that the motor stops rotating at 5000 at any large manual current. I add 32768 to this number and register it in the syncofs. however, it is worth adding a FW later and stable work is obtained forward but uncontrolled rotation backwards! and only after reaching from 37768 to 42000, I get really stable work in both directions with any FW and the same rotation speed in any of the directions.

therefore, I am very much waiting for your firmware version to try to configure it with it.
evil neodymium :twisted:
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor - Auto-setup

Post by Pete9008 »

johu wrote: Mon May 15, 2023 4:51 pm Great!
Did you add more opmodes for the various test sequences or how did you structure it?
I've tried to keep the new code as separate as possible. It still just uses the MOD_RUN and MOD_MANUAL opmodes so it's compatible with the existing web interface. If in run mode then the Run() function gets called from the ISR, if in manual mode then a new function TestModeRun() gets called from the ISR instead. Means there is a bit of duplicated code between the two but keeps them nicely separated and avoids complicating the existing Run function. There is also a new parameter that selects which test is to be run if in manual mode.

Edit - the code will probably still need a bit of tidying up though ;)
Post Reply