Induction motor control strategy  [SOLVED]

User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

See https://openinverter.org/parameters/view.html?id=15
This confirms that the SDU encoder it's 36 PPR. This isn't great but it's definitely enough, depending on how you process it. Unfortunately my previous experience was with a *600* PPR encoder, so I'm having to put a lot of thought into how to properly use this instead.
I will go ahead and look at adapting my code to vary slip with throttle, but decouple voltage a bit.
I strongly suspect that what I end up with at that point will basically be what Johannes did!
My main desire is to get rid of the idea of an fslipmin and just make it completely linear.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Induction motor control strategy

Post by EV_Builder »

Do we have a picture of how that wheel is fitted?
That's indeed not allot.

The issue with not allot of PPR is minimum speed detection.
My gut feeling says that for slow motor speed we need a strategy and for driving (higher speeds) we need another.

Maybe we should go under 240rpm (4kph) or something with V/Hz with no encoder. And above we start blending in the encoder?

No clue how it's done right now but I'm sure that at low speed the resolution is needed and on full tilt it's when we need to keep up counting it.

When i'm at this fase I'm sure I will come up with ideas.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

EV_Builder wrote: Sun Apr 17, 2022 5:16 pm Do we have a picture of how that wheel is fitted?
It's literally just pushed onto the end of the motor shaft. Here's a teardown of mine.
Attachments
PXL_20220323_113426879.jpg
PXL_20220321_150312199.jpg
PXL_20220321_142006993.jpg
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Probably be missing something here but you may be able to get better resolution on frequency.

It sounds like at the moment you are counting encoder edges (rising, falling or both?) to work out speed. Instead I would have a hardware timer running in the background and latch the timer value each time there is an encoder edge. A timer interrupt would then use time difference between the last two edges to give a high resolution measure of the speed during the last period accurate down to very low rates. The range of speeds covered is limited at the high end by timer clocking speed and at low speeds by the timer depth but I can't see a 32bit timer not covering the full range. The effectiveness is limited by the accuracy of the encoder (essentially the error on the consecutive edge positions), and it would be worth checking it, but my guess is it would easily be good enough to give a pretty precise speed readings. The other benefit of this approach is that you can work out the exact current position by extrapolating from the last measured edge using the current timer value eiter the last delta or an IIR/FIR filtered version of the historical deltas.

I'd suggest just using rising edges or just using falling edges as I have a feeling that the encoder output won't be precisely 50% duty cycle. If you want better resolution you could use two timers, one for rising edges and one for falling edges and then combine the results.

This does assume relatively slowly changing motor speed but then even rapid changes in motor speed are relatively slow as measured by encoder edges. Also this approach is likely to need floating point division to give good resolution but I'm sure the processor can cope as the interrupt will be fairly low rate.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

EV_Builder wrote: Sun Apr 17, 2022 5:16 pm That's indeed not allot.

The issue with not allot of PPR is minimum speed detection.
My gut feeling says that for slow motor speed we need a strategy and for driving (higher speeds) we need another.
It is indeed not a lot. At 1Hz, it generates one edge every 14ms. This means if we calculate speed every 14ms (as I do in my concept code), we have a resolution of 1Hz, which IMO sucks, when you consider that the throttle range is about 5Hz of slip.

This same absolute error exists whether the rotor is spinning at 1Hz or 100Hz, so I'm not convinced that a dual strategy really solves anything.

In terms of maintaining the correct slip, this error really doesn't matter. The errors cancel each other out over the course of the rotation. The problem only arises when I try to calculate V/Hz. Throttle scale is 6Hz, so a 1Hz oscillation is equivalent to the throttle oscillating by 15-20%, and this isn't cool.

I don't understand openinverter as well as I should, but it's my understanding that it gives more weight to the throttle when choosing the voltage and less weight to the frequency, By doing this, we can probably minimize the impact of the 1Hz error.
arber333
Posts: 3241
Joined: Mon Dec 24, 2018 1:37 pm
Location: Slovenia
Has thanked: 74 times
Been thanked: 223 times
Contact:

Re: Induction motor control strategy

Post by arber333 »

catphish wrote: Sun Apr 17, 2022 6:35 pm I don't understand openinverter as well as I should, but it's my understanding that it gives more weight to the throttle when choosing the voltage and less weight to the frequency, By doing this, we can probably minimize the impact of the 1Hz error.
Thanks for that explanation. I have felt results of that deficiency at slow speed. Though it is not so pronounced when motor does not make a lot of torque. Mine did and it caused some oscillations every time i would try to drive in slow traffic. In the end i burried 3 clutches and went for the lovejoy coupler.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

Pete9008 wrote: Sun Apr 17, 2022 6:34 pm Probably be missing something here but you may be able to get better resolution on frequency.

It sounds like at the moment you are counting encoder edges (rising, falling or both?) to work out speed. Instead I would have a hardware timer running in the background and latch the timer value each time there is an encoder edge. A timer interrupt would then use time difference between the last two edges to give a high resolution measure of the speed during the last period accurate down to very low rates. The range of speeds covered is limited at the high end by timer clocking speed and at low speeds by the timer depth but I can't see a 32bit timer not covering the full range. The effectiveness is limited by the accuracy of the encoder (essentially the error on the consecutive edge positions), and it would be worth checking it, but my guess is it would easily be good enough to give a pretty precise speed readings. The other benefit of this approach is that you can work out the exact current position by extrapolating from the last measured edge using the current timer value eiter the last delta or an IIR/FIR filtered version of the historical deltas.

I'd suggest just using rising edges or just using falling edges as I have a feeling that the encoder output won't be precisely 50% duty cycle. If you want better resolution you could use two timers, one for rising edges and one for falling edges and then combine the results.

This does assume relatively slowly changing motor speed but then even rapid changes in motor speed are relatively slow as measured by encoder edges. Also this approach is likely to need floating point division to give good resolution but I'm sure the processor can cope as the interrupt will be fairly low rate.
Thank you for taking the time to read and understand the problem. You are absolutely correct that a MUCH better solution would be to time the number of 72MHz clock cycles between each edge. This would give good accuracy throughout the rev range.

I love this approach, and I *almost*went with it, but there are two problems that make me sad.

1) There is no detection of direction. This means that +1Hz is detected the same as -1Hz, which is a problem, unless we make some unpleasant assumptions. This matters when you want to get as close as possible to stateless, as I do.
2) When near stationary and changing direction, pulses could occur very close together, indicating a high speed, though I think this is strongly mitigated if we only look at one rising edge rather than all four edges.
3) The encoder is connected to TIM3 which is only 16 bits. This dramatically limits our options for resolution.

With all of that said, it's hard to know if I'm on the right track here, or whether I'd be better not worrying about the phase-accuracy of the sine output, and trying to control voltage in other ways.

In my previous inverter, I ignored V/Hz entirely, and controlled voltage by doing negative feedback on measured current. I'm tempted to look at this in parallel.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Thought you would already have considered it!

I'm not familiar with the SDU encoder, does it have quadrature outputs? How is direction normally determined?

I high priority GPIO edge interrupt with sampling done in the ISR should be good enough (just not quite as good as hardware!)
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Have had a quick look and it appears that the SDU has A and B outputs so guessing that these are quadrature. Given the limitation on TIM3 I would go with using another timer to get 32bit, sample the count from a pair of high priority ISRs triggered by the A and B channels and do the direction detection within the ISR.

This should also solve the stationary bit as it would recognise the direction change.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Induction motor control strategy

Post by EV_Builder »

@pete9008; to big to quote but yes that's what I was thinking.

But when one depends on the interrupt it means that a slow speed.

The stm32f1xx series has a special encoder mode for quadrature mode so that's maximum resolution. But at slow speeds it's always a problem...(large update rate or big oscillations)

I will try to explain my idea later more.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Ahh OK, hadn't twigged it was using built in encoder functionality. Never needed it in the past so had never even noticed it was even there!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

One other thought, could the TRG0 line from TIM3 be used to latch one of the other timers to give 32bit resolution?
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Induction motor control strategy

Post by EV_Builder »

I don't know if it's currently in the SW implementation but I checked if the CPU has HW provisions for it and it has.

I still feel we should go with plain V/Hz table to throttle mapping until we do like 300rpm. There we start blending over to regen and or slip mode (if no voltage left) and start looking at slip.

Just ideas. Worked with motion systems but never went this deep. (Could just configure VFD and servo and program motion (servo) systems).

The directon is means of is de increment counter going up or down.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

Pete9008 wrote: Sun Apr 17, 2022 7:21 pm One other thought, could the TRG0 line from TIM3 be used to latch one of the other timers to give 32bit resolution?
If I could work out how to do that, I'd be extremely happy! Using 2 timers would allow the ideal combination of hardware up/down counting with accurate hardware timing.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

EV_Builder wrote: Sun Apr 17, 2022 7:56 pm I still feel we should go with plain V/Hz table to throttle mapping until we do like 300rpm. There we start blending over to regen and or slip mode (if no voltage left) and start looking at slip.
But V/Hz is exactly where the problem lies, because we don't have an accurate value of Hz :(
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

catphish wrote: Sun Apr 17, 2022 7:57 pm If I could work out how to do that, I'd be extremely happy! Using 2 timers would allow the ideal combination of hardware up/down counting with accurate hardware timing.
I seem to remember using TRGO in this way before but it was on a STM32F4 and not with an encoder. I do also remember it being a bit of a pain to set up though.

Agree it would appear to offer the best of both worlds, maintains the hardware encoder ease of use and speed while offering improved resolution at low speeds. Must be a catch though!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Take that back I was using it to trigger an ADC.

Just had a look at the data sheet and I'm not sure it is possible, TRGO only feeds the ITR inputs (clocking, reset) while to do a capture it would need to feed the TI lines. :(

Might be possible to route it off chip and back in but it's unlikely that the required pins are spare though.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

Take it back, it can be done, ITR drives TRC which can be selected as an input on the TI channels :) See P367 of the RM00008 reference manual.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

Another take on this... given that V/Hz is 1.56V/Hz, this 1Hz ripple is only a voltage ripple of 1.56V, and the full throttle (6Hz) voltage range is only 9V!

This tells me that under this control scheme, voltage is a negligible factor, and in fact the torque control will be dictated almost entirely by the slip (0-6Hz). With that in mind, I think I will put aside my worries, and try my strategy as-is. I guess we'll find out as soon as I have the time to test it!
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

Pete9008 wrote: Sun Apr 17, 2022 8:16 pm Take it back, it can be done, ITR drives TRC which can be selected as an input on the TI channels :) See P367 of the RM00008 reference manual.
Thank you, I will definitely look into this. It really depends whether instantaneous accuracy of the rotor speed matters or not. If I find that it does, I will explore this, as it would hugely improve the accuracy. One benefit of the "counter" method is that the errors average to zero over a longer period.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Induction motor control strategy

Post by EV_Builder »

catphish wrote: Sun Apr 17, 2022 7:58 pm But V/Hz is exactly where the problem lies, because we don't have an accurate value of Hz :(
V/Hz is the most simple form of sensorless vector control.
You could map the throttle to it.

It's how a basic VFD ramps. With a acc. of x Hz/sec increment.

When above 300rpm's we blend in slip control.
So 100% Throttle becomes x amount of maximum slip.

P.D. if I'm right it's a openloop control method.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Induction motor control strategy

Post by Pete9008 »

catphish wrote: Sun Apr 17, 2022 8:30 pm Thank you, I will definitely look into this. It really depends whether instantaneous accuracy of the rotor speed matters or not. If I find that it does, I will explore this, as it would hugely improve the accuracy. One benefit of the "counter" method is that the errors average to zero over a longer period.
No problem, hopefully you'll find your code works fine as is but it's always nice to have a backup plan.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

EV_Builder wrote: Sun Apr 17, 2022 8:34 pm V/Hz is the most simple form of sensorless vector control.
You could map the throttle to it.

It's how a basic VFD ramps. With a acc. of x Hz/sec increment.

When above 300rpm's we blend in slip control.
So 100% Throttle becomes x amount of maximum slip.

P.D. if I'm right it's a openloop control method.
What are you calling "slip control"?

My implementation is both V/Hz and "slip control". The throttle controls slip. Voltage is then set according to the total output frequency.

The only thing I've not yet added is "boost". The intent there will be to add a fixed voltage proportional to throttle, regardless of frequency.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Induction motor control strategy

Post by catphish »

Pete9008 wrote: Sun Apr 17, 2022 8:42 pm No problem, hopefully you'll find your code works fine as is but it's always nice to have a backup plan.
I think it'll be nothing short of a miracle if my code work fine. This is (right now) nothing more than an idea. The fact that it's so simple suggests that it will certainly require some tweaking before it has any chance of working well, but it's a good way for me to learn and share ideas.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Induction motor control strategy

Post by EV_Builder »

Slip control I call that you measure rotor speed and depend Hz setpoint on that plus requested torque. The more requested torque the more you add. That will induce current because the motor tries to follow (maybe combined with V increase??).

But below a certain speed I would fallback on sensorless control.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Post Reply