#$%@$#@ <--- (insert favorite swearword here), IT WORKS !!!!

[Lebowski]

This is the latest result (5 minutes old ) of my 30F controller.

Sensored startup, then sliding transition to sensorless. Full UN-interrupted sinewave output on all 3 motor phases.


The motor control algorithm does NOT use the motor inductance / resistance, it has no knowledge of these parameters (unlike
Field Oriented Control )



The transition to sensorless is around 10V, you can really hear the change in tone (around 25 sec in the video).

For the video I increased the rpm where the transition is made to show the sound difference between
sensored and sensorless. The transition can be made at a much lower RPM (but then the transition
would not be very audible)

[liveforphysics]

That is awesome! Such a fantastic job!

I love it!

[Alan B]

Very nice. I would like to see sensored transitioning to sensorless in all our controllers!

On the sinewave drive, IIRC the BEMF was trapezoidal, so I would expect sinewave to have more torque ripple than trapezoidal drive, and produce less torque due to less integrated current over time. What is your experience in actually trying it?

Excellent work!

[Lebowski]

Very nice. I would like to see sensored transitioning to sensorless in all our controllers!

On the sinewave drive, IIRC the BEMF was trapezoidal, so I would expect sinewave to have more torque ripple than trapezoidal drive, and produce less torque due to less integrated current over time. What is your experience in actually trying it?

Excellent work!

The controller actually feeds the motor with an amplified version of it's own back-emf. During the calibration phase it samples
the back emf and disects it into its fundamental, 3rd, 5th, 7th and 9th harmonic. I asked the controller to report the
parameters, it turns out the back emf of my motor is 97% fundamental, 2% 3rd harmonic and fractions of the other harmonics.

I altered the first post to mention that the algoritm has NO knowledge of the motors resistance or inductance, I think it
would maybe be a prime candidate for low R / low C motors

The algorithm is blindingly fast by the way, it can update the motor voltages easely at over a 20 kHz rate, possibly up to 50 kHz
(though going faster than the PWM frequency doesn't make sense, my output stage can handle 50 kHz PWM but over a 100 kHz
the FET drivers start heating up)

[flathill]

Very nice. I would like to see sensored transitioning to sensorless in all our controllers!

On the sinewave drive, IIRC the BEMF was trapezoidal, so I would expect sinewave to have more torque ripple than trapezoidal drive, and produce less torque due to less integrated current over time. What is your experience in actually trying it?

Excellent work!

The controller actually feeds the motor with an amplified version of it's own back-emf. During the calibration phase it samples
the back emf and disects it into its fundamental, 3rd, 5th, 7th and 9th harmonic. I asked the controller to report the
parameters, it turns out the back emf of my motor is 97% fundamental, 2% 3rd harmonic and fractions of the other harmonics.

I altered the first post to mention that the algoritm has NO knowledge of the motors resistance or inductance, I think it
would maybe be a prime candidate for low R / low C motors

The algorithm is blindingly fast by the way, it can update the motor voltages easely at over a 20 kHz rate, possibly up to 50 kHz
(though going faster than the PWM frequency doesn't make sense, my output stage can handle 50 kHz PWM but over a 100 kHz
the FET drivers start heating up)

Excellent work! So the back emf of your motor is very close to a sine wave (which is why your controller is outputting sine waves)? Have you tried it with other motors? Could it account for a non perfect motor (winding/magnet/steel variations) if it always knew the position through self learning, or is the feedback delayed assuming a "perfect" motor (this is problem not a real world issue but could reduce noise)?

[Gordo]

Wonderful development!
Your test set up appears to have a load on it? How many amps are you pulling and does the controller care?
Thanks

[liveforphysics]

20Khz loop is pretty awesome. That's as good as the fastest Sevcon stuff.

I think the Rhinehart motion stuff that is used for running the super insane low inductance/resistance motors have to run around 40khz to be capable of current control without overshoot. Does your layout leave headroom to kick your loop speed up a notch or two?

[Burtie]

Excellent job man

I love the idea of calibrating it to match the back emf signature of the motor.
It will be interesting to see how it works with a range of different motors.

Subscribed.

Burtie

[bigmoose]

Congrats!!! Great accomplishment in a short time.

[Lebowski]

Excellent work! So the back emf of your motor is very close to a sine wave (which is why your controller is outputting sine waves)? Have you tried it with other motors? Could it account for a non perfect motor (winding/magnet/steel variations) if it always knew the position through self learning, or is the feedback delayed assuming a "perfect" motor (this is problem not a real world issue but could reduce noise)?

Yep, the back-emf of my motor is accidently close to a sine and this is why the controller is outputing a sine.

I haven't tried it yet but the program in the 30F has a gain factor in it to amplify a (RAM) stored back-emf
waveform to the final voltages in the PWM output stage. In the multiplication routine I added clipping which
flattens the top of the sines when the gain is high. This effectively changes the sine to a trapezoid. I tried
with the trapezoid when the algorithm was still in a kind of 'corrected' sensored mode, was fine then...

I build the motor in the video myself. The spacing inbetween the magnets and inbetween the coils has quite some
spread on it, the motor is far, far from perfect. But this is no issue for the algorithm, it doesn't need a perfect
motor. The algorithm extracts it position information at every clock cycle, it's not limited to only 6 sampling
moments per e-revolution as in a windmilling type algorithm. So, the feedback it not 'delayed' and does not
assume a perfect motor. There's no 'self learning' type algorithm as these are typically computationally expensive
and introduce delay in the system.

I haven't tried it with another motor (I only have the one from the video) but all throughout the design I've made
the system such that it is as general as possible. Therefore I didn't like the FOC algorithms you can find in the
application notes of Microchip or NXP, they all require knowledge of the motor (being Kv, winding resistance R
and/or winding inductance L). I find using motor parameter kind of tricky as they probably change with temperature
so I wanted something that's not dependent on them (ever see the series resistance explode with temp ? its scary)

I would love some input on how the algorithm works with different motors. It's not ready for it at the moment as
the video was literally made 5 minutes after I got it to work, but maybe it's an idea to mail some programmed
30F4011 chips around so people can try it in their own controllers (you would need to build the power stage etc
yourself or do a brain transplant on a Lyen controller)...? Your motor has to be able to deal with field weakening
though (I read somewhere that field weaking can damage the permanent magnets but I don't know how tricky this is).

[Lebowski]

20Khz loop is pretty awesome. That's as good as the fastest Sevcon stuff.

I think the Rhinehart motion stuff that is used for running the super insane low inductance/resistance motors have to run around 40khz to be capable of current control without overshoot. Does your layout leave headroom to kick your loop speed up a notch or two?

Yes. The main 'time consumers' at the moment are the ADC's, to get 4 voltage readings they need 5 usec (in total). After that
it's some simple sine lookup table, a few multiplications, some adding/substracting and some moving data around (all at 33 ns per instruction).

[salty9]

Looks like it would be a good tool for building a better motor.

[John in CR]

Great work Lebowski ! Isn't it almost time to escape the cold to visit tropical paradise? I've got a wide variety of motors for testing your controller on. Just let me know how someone low on the e-totem pole can help you.

[Lebowski]

Yesterday I tried to run the motor with trapezoidal signals by upping the amplitudes of the sines going
to the motor to above the clipping level. Everything worked fine but (logically, as it's a less ideal
situation than using sine waves) the power consumption went up a bit (around 200 mA instead of
100 mA at 30 V for an unloaded motor).

Another interesting test, I disabled the lower rpm limit. Normally (as in the video) the controller
switched back to sensored commutation below a certain rpm. I managed to bring the motor
all the way down to 3 rpm (this is 1/3 e-revolution per second), the motor supply was at 0.3 V (10 mA,
so 0.03 W to spin a motor !). Sensorless !

I'd love to sit in a tropical paradise now It's cold and foggy here

[strantor]

awesome! excellent job sir.

[markobetti]

incredible...dont know if its possible to implement it to xie chang hardware ... but that would be crazy cool .....and you could sell us the chip with program and instructions....

[Lebowski]

I would love some input on how the algorithm works with different motors. It's not ready for it at the moment as
the video was literally made 5 minutes after I got it to work, but maybe it's an idea to mail some programmed
30F4011 chips around so people can try it in their own controllers (you would need to build the power stage etc
yourself or do a brain transplant on a Lyen controller)...? Your motor has to be able to deal with field weakening
though (I read somewhere that field weaking can damage the permanent magnets but I don't know how tricky this is).

I think it would work in a standard controller. You need to de-solder the microcontroller, connect the 30F4011 the correct
way (halls, 6 signals to the 6 FET drivers, 5 V supply) and add two high-current current sensors. I think
these sensors would work:

http://ch.farnell.com/allegro-microsyst ... dp/1791392

(it needs to be a sensor that for 0 amps gives out 2.5V from a 5V supply with 5V out for 50 Amps and 0V out
for -50 Amps. there's also 200amps versions)

[Arlo1]

Awesome once I get my controller finished I would love to use your code to flash my dspic and try it out on colossus.

[parabellum]

Bravo Lebowski, looks like a huge step or two in right direction. It was long period since last significant controller breakthrough.

[gtadmin]

...
I think it would work in a standard controller. You need to de-solder the microcontroller, connect the 30F4011 the correct
way (halls, 6 signals to the 6 FET drivers, 5 V supply) and add two high-current current sensors. I think
these sensors would work:

http://ch.farnell.com/allegro-microsyst ... dp/1791392

(it needs to be a sensor that for 0 amps gives out 2.5V from a 5V supply with 5V out for 50 Amps and 0V out
for -50 Amps. there's also 200amps versions)

This looks good, well done mate. These current sensors are the ones I use, and available from the US (more applicable to Arlo1 though)

[Arlo1]

...
I think it would work in a standard controller. You need to de-solder the microcontroller, connect the 30F4011 the correct
way (halls, 6 signals to the 6 FET drivers, 5 V supply) and add two high-current current sensors. I think
these sensors would work:

http://ch.farnell.com/allegro-microsyst ... dp/1791392

(it needs to be a sensor that for 0 amps gives out 2.5V from a 5V supply with 5V out for 50 Amps and 0V out
for -50 Amps. there's also 200amps versions)

This looks good, well done mate. These current sensors are the ones I use, and available from the US (more applicable to Arlo1 though)

I will have to look at them again but I got 4 Alegro ACS758ECB-200U-PFF-T http://www.allegromicro.com/~/Media/Fil ... sheet.ashx

[Lebowski]

Just put in a 'lost of lock' detection It has the capability to detect a 3 degree
phase error (at 6000 e-rpm) and shut down the controller.

Still thinking about recapturing lock after such an event... maybe I'll cheat and use the
hall sensors which are there for startup anyway, what do you guys think ?

[Alan B]

I was wondering if the algorithm could be configured so the halls and the BEMF were both used together in an intelligent fashion. Perhaps the halls for coarse lock and the BEMF for fine tuning. Then it could not get too far out of sync.

[parabellum]

Lebowski, how is your throttle working in given case? Changing multiplication factor to BEMF and then chip modifies PWM accordingly?

[Lebowski]

I was wondering if the algorithm could be configured so the halls and the BEMF were both used together in an intelligent fashion. Perhaps the halls for coarse lock and the BEMF for fine tuning. Then it could not get too far out of sync.

That was an earlier version... It interpolated between the hall signals using a timer and then
corrected for the remaining phase error with a 1st order control loop. The loop is now 2nd
order so it doesn't need the halls anymore.

some info: a 1st order loop can control a system to 0 error when the input is constant (like a phase error)
a 2nd order loop can control a system to 0 error also for a constantly rising / falling input. Since the position
of a running motor is represented by a constantly rising phase I use a 2nd order for control to 0 phase error