openinverter forum

EV_Builder wrote: ↑Sun Apr 17, 2022 9:14 pm 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.

That makes sense. What you're describing as slip control is indeed exactly what my code does. It increases slip with throttle. V/Hz is a necessary secondary component of this.

As for "sensorless control", I suppose the obvious option there is simply to ignore the rotor speed at low speed, set a minimal slip, and begin to increase voltage. I believe this is what openinverter currently does, but it it my hope that I can instead extend slip control right down to stationary, and beyond into reverse.

Of course, there's real sensorless control, using the current sensors to calculate everything, but sadly nobody has ever published a working open source implementation of this.

Ahhh ok. But I think you can't control slippage wel at low speed because of the encoder resolution. One thing we could do is feedback ABS sensor speed into the drive unit. And knowing tyre size etc. You know rpm again... but no clue if it would help or makes things worse (wheel spin)

We have a +/-10 degrees slip control with current encoder setup / SW
That means we might don't use the quadrature resolution. I checked the SINE software, it's using the counter mode when AB mode is selected. Maybe we could improve that but no clue if it's worth the effort.

EV_Builder wrote: ↑Sun Apr 17, 2022 9:44 pm Ahhh ok. But I think you can't control slippage wel at low speed because of the encoder resolution. One thing we could do is feedback ABS sensor speed into the drive unit. And knowing tyre size etc. You know rpm again... but no clue if it would help or makes things worse (wheel spin)

We have a +/-10 degrees slip control with current encoder setup / SW
That means we don't use the quadrature resolution. I checked the SINE software, it's using the counter mode when AB mode is selected. Maybe we could improve that but no clue if it's worth the effort.

The low resolution is a worry, but at low speed, my hope is that the the slip added by the throttle will swamp the frequency of the rotor anyway, so it'll be close to sensorless, but in a more organic way. Again, this is all my speculation, as I have no proof yet that this strategy works!

With regard to the encoder, I am pretty sure that "AB" mode uses counter mode with the full quadrature resolution (ie it counts up 4 times for each notch on the wheel). This mode is trivial to enable on the STM32, so it's very unlikely that Johannes didn't use it already

catphish wrote: ↑Sun Apr 17, 2022 9:54 pm With regard to the encoder, I am pretty sure that "AB" mode uses counter mode with the full quadrature resolution (ie it counts up 4 times for each notch on the wheel). This mode is trivial to enable on the STM32, so it's very unlikely that Johannes didn't use it already

Yes; it counts in quadrature mode but later we divide /4 again. Maybe i'm wrong. Didn't do a complete study of it.

No, every edge is counted

johu wrote: ↑Mon Apr 18, 2022 2:42 pm No, every edge is counted

Yes, it's counted; but what is the resolution used in the firmware?

EV_Builder wrote: ↑Mon Apr 18, 2022 9:01 pm Yes, it's counted; but what is the resolution used in the firmware?

It uses all of it, I see no reason why it would willingly discard this resolution.

catphish wrote: ↑Mon Apr 18, 2022 9:03 pm It uses all of it, I see no reason why it would willingly discard this resolution.

Me neither; well if it isn't needed that precise..

But did you check the encoder code?
If the counted pulses is divided by 144 what do you get?
A: revolutions..

If you want to understand me, take a look at the code.

Are you referring to these lines? https://github.com/jsphuebner/stm32-sin ... r.cpp#L185

It is first multiplied by 2¹⁶ then divided by numimp*4. So no resolution loss there.

Thank u for jumping in

Yes indeed; can you elaborate more on that part?
The increments are in 2.5 degrees steps (360/(36*4)).
2^16 isn't two-pi or am I misreading that too?

Before I'm mis untherstood I doubt we will come up with something better easyly since the current code works and I doubt Johu with his experience dropped the ball somewhere big. But curious as I was I checked the code out a bit. Probably not enough

EV_Builder wrote: ↑Tue Apr 19, 2022 9:21 am Thank u for jumping in

Yes indeed; can you elaborate more on that part?
The increments are in 2.5 degrees steps (360/(36*4)).
2^16 isn't two-pi or am I misreading that too?

Before I'm mis untherstood I doubt we will come up with something better easyly since the current code works and I doubt Johu with his experience dropped the ball somewhere big. But curious as I was I checked the code out a bit. Probably not enough

Yes the detected steps are 2.5 degrees apart (5 degrees of sine angle because the motor is 4 pole). This is the best accuracy we can achieve. What matters more is how this value is used later. At its simplest, you could just increment the field by 5 degrees immediately for each pulse, but there are plenty of ways to smooth it out. Basically you count the pulses over a 10ms period, which gives you a speed accurate to about 1Hz, and use this for the following 10ms. Errors will average out over a longer time period. Johannes can correct me if I'm not explaining this correctly.

My implementation does something very similar, but on the basis of an overlapping moving average.

You dive into implementation; or new implementations; first I suggest we know/ discuss the current one. To know it's strengths and weaknesses.

I'm gonna park this discussion for now since I don't have an engine running in the car yet and I'm not familiar with the current implementation and don't know the need for change at all.

EV_Builder wrote: ↑Tue Apr 19, 2022 9:57 am You dive into implementation; or new implementations; first I suggest we know/ discuss the current one. To know it's strengths and weaknesses.

I'm gonna park this discussion for now since I don't have an engine running in the car yet and I'm not familiar with the current implementation and don't know the need for change at all.

I would argue there is clearly no need for change. Many people are perfectly happy with the current implementation, and it's absolutely not my intent to criticize it.

I'm far from certain that my oversimplified design can be an improvement, but I wanted to post it here to demonstrate and discuss my ideas

I spent a couple more hours reading and doing simulations. It seems that exactly as Johannes said, there are different ways to do this, but the difference in performance and efficiency are petty negligable. The voltage-then-slip approach favoured by openinverter, while initially confusing, certainly works well.

hi catphish, here is a book for you, see page 13, in my product I used 180 degrees, there is a video, and I conducted experiments with reduced voltage, 96 volts on a 220-380 volt motor, I received power by expanding the PWM signal and kept it at 180 degrees, sorry about that my english i am from russia
https://drive.google.com/file/d/1WPyG3D ... drive_link


https://drive.google.com/drive/folders/ ... drive_link
https://drive.google.com/drive/folders/ ... drive_link

Hello people, have any of you ever wondered where to get energy? one evening I was drinking red wine and a crazy idea came to me, drinking is sometimes useful, the idea is to go for high voltage, about 800-900 volts, I bought a mosfet for 1700 volts, and with span drivers, only for 1200 volts, ideally I need I get 1200 volts from the generator but the drivers are slowing me down, if you have suggestions and wishes then let’s talk, we simple and working people need to prepare for bad times and be ready
that's my dream