Lebowski's motor controller IC, schematic & setup, new v2.A1

Futterama said:
Great work Lebowski. Did you have to tweak the code, or did the CAN bus just work with no code changes?
Click to expand...
The actual CAN bus operation worked straight away. What I did have to look at was the watchdog timer.
When receiving throttle over CAN, as a safety measure when it doesn't receive throttle info for more than 48 msec, the chip resets itself.
 
zombiess said:
Lebowski said:
HighHopes said:
that's a nice feature. i think CAN bus also has error correction built in too no?
Click to expand...
Yep, i wouldn't trust the throttle signal to something without error correction / detection... plus it makes it very easy to have have multiple masters and slaves on a single bus.
Click to expand...

Do you think we could do 6 phase operation on john in CR's hubmonster using CAN bus?
Click to expand...

Since I have the setup, I'm now actually playing around with that. I re-wound my little RC motor to be a 6-phase motor with 30 degrees
difference between the two 3-phase motors. Unfortunately though my RC motor has only 12 stator teeth while Johns motor has
24, this has an impact on how the magnetic field lines go (there's more coupling between the windings for only 12 teeth).

Anyways, the motor runs but something is wrong. To spin at 50k-erpm (7000 rpm) one single controller needs about 65W (1A from 65V), when I use
both controllers the power taken from the supply goes to 130W. This is not logical though, the power needed to spin the motor at
50k-erpm should remain at 65W. I can feel the motor getting much hotter than normal with 2 controllers.

Also, I'm using the new v2.21 in both (just send you 2 chips yesterday) which can capture a running motor. This works good with one controller
but with 2 typically one runs the motor and the other 'hangs' in the capture mode (drive_1). I can get both to capture and run the motor if
I slowly increase throttle, but then the power makes no sense and the motor runs hot.

Looking at the controller output sine waves, they do run 30 degrees out of phase so this fits. What I can see is a slow oscillation on the amplitude
of the internal amplitude variable, but it's only 1% so not that big. The fact that it has trouble capturing though is indicative of something going on
with the (output signals of) the current sensors. What doesn't really help is that the big controller has 150A current sensors, but the phase current
is set to only 8A and the capture current to 1A. 1A is only 13mV at sensor output, or between 2 and 3 LSB's of the controller IC's ADC.

More investigation is necessary...
 
Lebowski said:
When receiving throttle over CAN, as a safety measure when it doesn't receive throttle info for more than 48 msec, the chip resets itself.
Click to expand...
That's pretty good to know before starting to work with the CAN bus :lol:

But it does fit fine with the fact that the servo pulses from an RC receiver is sent at 50-100Hz (10-20ms between pulses) so it is enough for the CAN transmitter to transmit for every servo pulse from the RC receiver.
 
Hey Dude...
Changing to 6 phase has changed the mechRPM to elecRPM ratio.
assuming you have the same rotor.

So if 50k eRPM gives 7000 mRPM for 6phase
then 50k eRPM would be 3500 mRPM for 3phase.

The 65W would be part bearing and aero loss which would more than double as the relationship is more than linear.

7c
 
7circle said:
Hey Dude...
Changing to 6 phase has changed the mechRPM to elecRPM ratio.
assuming you have the same rotor.

So if 50k eRPM gives 7000 mRPM for 6phase
then 50k eRPM would be 3500 mRPM for 3phase.

The 65W would be part bearing and aero loss which would more than double as the relationship is more than linear.

7c
Click to expand...
Ehm, how shall I put this....

no.
 
The easiest way to understand electrical rpm is its how many magnet polls pass 1 stator tooth in 1 mechanical revolution.
So it doesn't matter how you wind it or how many stator teeth there are or how many phases it is. if you have 20 magnet polls then you have 10 north and 10 south then you have a 10x electrical to mechanical rpm ratio.
 
With 12 coils, and two three-phase groups, there are only two ways to connect the coil three-phase groups. Which way did you connect them? One approach increases mutual inductance between the coil groups? Does one approach require 30 degree phase skew between the two three-phase groups and one puts them in sync? I know that in the AF designs, this is the case. I have been told by my professor friend that the mutual inductance between three-phase coil groups is very bad but I have never seen actual results that show that to be the case. If your results show this, that would be very interesting.
kenkad
 
I connected them such that I have 30 degrees between the two 3 phase groups:

ADBECFadbecf with one 30phase group made with ABC, the other with DEF.

I know AaDdBbEeCcFf is also possible but this doesn't give you the 30 degree difference I'm after, as I want to model John's situation.

 
That is the configuration I suspected you did. Each successive coil (every other coil) is in one three-phase group. That is what I was told not to do on the AF design I am pursuing. The professor at LSU said to me not to do that type of configuration because of mutual inductance issues. I too was going to offset the sine wave for each group. I have 24 coils so I end up with four three-phase groups. So instead, each three successive coils, and the opposing 180 degree coils are in a three-phase group. The result is that all sine drives are in sync. I argued against that because of bearing loading if not all three-phase coils are being driven.

I would really like to understand what you have encountered. I asked at LSU about a paper that discusses the mutual inductance issue and was never provided one. I did not press the issue because I just assumed that they were right and common knowledge among motor designers.
kenkad
 
I think I figured out what is going on, most of it anyways. The new is good :D

With the real time data out over RS232 the controllers allow me to see what is going on, so I can see what voltages and currents they are providing. It turns
out it takes only 20W to run the motor at around 50 k-erpm. If I use either one on it's own, it wlll provide 20W to the motor. If I use both the power is split
(not equally but close, as the controllers are running different deadtimes etc etc) but the total is still 20W.

What had me stumped though was that even a single controller takes about 60W, meaning 40W is lost somewhere. An apparently with both they take 120W so
100W is lost. Looking at the power consumption of a single controller, one takes about 5W, the other about 8W (as it has a fan). So there's quite some power
lost and it's going to the motor as this gets pretty hot with 2 controllers.

And then it hit me, the motor is only 15uH (see picture above) with the PWM stages running at 21 kHz, all the extra power that is lost is due to the 21kHz currents
from the PWM ! Increasing the PWM of one controller to 33kHz immedately saved 20W, reducing it to 11kHz increased consumption by more than 25W extra.

So, one of these days I'll try to measure the motor resistances and run a simulation, see if the PWM totally explains the mysterious power loss (not tomorrow as
Holland is playing agains Australia :D ).

What also still needs explaining is why it has trouble capturing when only one controller starts....

Interestingly also, the PWM losses is a fundamental issue where a dual 3-phase is at a disadvantage w.r.t. if it were wound as a single 3-phase.
 
Is this constant (same in all three cases) torque regardless of the PWM frequency? Is the integral of on and off time for the PWM the same for each 360 degree cycle? Sometime earlier you had mentioned that you are using a 256 point lookup table to output the sine. How are the lookup table entries affected by the PWM frequency? What is your reason for saying that PWM losses are worse for multiple three-phase grouping?
kenkad
 
For measurement what I did was limit the amplitude of the voltages the controller can output. If you then give full throttle the motor will basically run at the preset voltages (based on the motors kv) and you can look at the controllers internal current variables to see how much current it is delivering. Based on all this I would say torque is constant (just enoug to make it spin at that speed).

The motor speed is unrelated to PWM so the integral of the on and off times over a 360 e-cycle is not likely to be 0.

The output signals are internally processed in 32 bits, between -1 and 1. Then as the last step this is multiplied with a PWM frequency based constant (the constant is the ratio between the CPU clock frequency and the PWM frequency) to get the value that is written into the PWM registers (there is some noise shaping done too). So PWM frequency has no effect on all the variables used in the algorithm.

About the PWM losses worse for multiple 3-phase groups, I may have spoken too soon there. Cause in the case of my RC motor, if you connect it all to one 3-phase group
you get double the inductance but you also need double the supply voltage to be able to have the same speed. So the PWM current level will be the same (as is the resistance)
so dissipation is equal.

P.S. there's also some sort of technical stuff going on making it a 768 step table lookup...
 
Dual controller, throttle and reverse switch interconnected via CAN bus. The controllers are fully
independent (no information sharing except one sends throttle info to the other). Together they drive
an RC motor having two independent 3-phase groups with a 30 degree timing offset. The controllers
are fully sensorless.

[youtube]pGfiw9EVbSA[/youtube]
 
Again, two controllers driving the same RC motor with a 30 degree offset. In this video I
reset one of the controller, to show how it captures and regains control. The 4 LEDs, from
red to green are for: -drive_0, drive_1 which is capture, drive_2 which is sensorless wiggle
start and drive_3 which is running.

[youtube]0KACnkYfEvI[/youtube]
 
In this video I increased the allowed battery current upto a point where it is above the capability
of the power supply. You can see from the LED's and hear from the motor sound that the drop in
power as the supply is overloaded causes the controllers to reset. After a reset the controllers
capture the motor and commence powering it, causing the power supply to overload again...

P.S. it's a 2.5A supply which conks out at around 2.7A. In the beginning of the video it conks
out at a higher rate as the motor still is spooling up, meaning the controllers take more power than
later in the video when the motor is up to speed.

[youtube]Tf6fOUns7ok[/youtube]
 
Awesome Lebowski! I love it!
I'm working hard on other stuff in my life incl. getting ready for my wedding. SO once I have things under control I will be back on this :) I also became OIL independent this week :)
 
gratz arlo!

lhey lebowski, is there a relationship between DC voltage droop and excessive current pull for random battery pack? at startup, before motor operation, DC bus could be measured, and then controller could watch for 20% (or whatever) droop when high current is commanded and say "hey, this is overload for this particular battery size". just an idea :)
 
Lebowski said:
Hey man congratilations ! When is the big day ?
Click to expand...
Well I got off oil on Monday....
Oh you mean the wedding date? August 2 :)
 
one motor with the windings split over two groups of three phases, but this time the two groups are on the same stator teeth
View attachment 1
DSC01549.jpg
This basically shows for your motor where you have lets say 6 strands in parallel, you can chose to run this with 1, 2, 3 or 6 controllers in parallel !
The only coupling between the two controllers is the throttle and reverse info over the CAN bus
[youtube]D7FyR5Y0mSw[/youtube]
because of the extremely low inductance I ran with 60kHz PWM...
 
I'm interested to see how this works under load.
 
What about start up under load? And resetting one controller under load? I think you have some figures left I think I can find 8 more tests for you. :)
 
In your June 18 post, you ended with saying you are now using a 768 entry lookup table. The coefficients (whatever they are based on) for any phase have to sum to zero for an e-cycle (your term). It is interesting that your PWM on/off integrals are not zero (your comment) as well over an e-cycle. So it seems that your cycling through the lookup table entries is not synced to the PWM?

Since I am old and easily get confused, I can imagine that it is not necessary to sync the two, but it would seem that the uC has a lot more work to do as a result. I would assume that the shape of the resulting phase driving waveform would show this. I do not recall in any of your previous posts showing the waveform of this lookup table/PWM process. Can you post such a o-scope shot for an e-cycle using your current setup?
kenkad
 
You must log in or register to reply here.

Similar threads

H
Modular ESC - Schematic/PCB Review wanted
Replies
10
Views
2,136
hightechasshole
H
Arlo1
Fuji 1MBI800U4B-120 IGBTs new for sale DISCOUNT! Updated September 9 2023
Replies
3
Views
1,678
Arlo1
Arlo1
Sparfuchs
reduce voltage drop between battery and controller
2
Replies
31
Views
4,507
jigs
J
mxlemming
    • Like
    • Doin' Science
GaN and IMS MESC controller boards
2
Replies
31
Views
6,606
mxlemming
mxlemming
argo
Resources for building the Lebowski open-source motor controller in 2020?
Replies
12
Views
7,880
amberwolf
amberwolf
Back
Top