Lishui "Open Source Firmware" project / KingMeter 5S

!? What do you mean with step? Try with p=0 and i=1 for id and iq, this is the slowest setting without going in the depth of the PI control.
How much should I increase it for every step? I take it that I have to start from p=0, i=1 and increase the values until I get to a smooth rotation?
 
I am doing something wrong with debug. Have it set at 9600 asci with hterm data is flowing but i am only seeing squares so something is wrong in my setting. I hgave done this
 
Last edited:
Yes tried three different cables only one worked :) Now I get with nothing hooked up to the controller
phase current offsets: 2040, 2044, 2056 <\r><\n>
internal temperature raw reading: 1143, <\r><\n>
Hall_Order: -1 <\r><\n>
Hall_45: 27 <\r><\n>
Hall_45: 334036992 <\r><\n>
Hall_51: 90 <\r><\n>
Hall_51: 1073741824 <\r><\n>
Hall_13: 152 <\r><\n>
Hall_13: 1825308672 <\r><\n>
Hall_32: -151 <\r><\n>
Hall_32: 2505375744 <\r><\n>
Hall_26: -90 <\r><\n>
Hall_26: 3221225472 <\r><\n>
Hall_64: -29 <\r><\n>
Hall_64: 3960864768 <\r><\n>
KV: 224 <\r><\n>
Lishui FOC v1.0 <\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
0, 5, 5000, 32000, 0, 0, 0, 0, 3<\r><\n>
 
No. This are the extreme values. If it doesn't work with this settings, we would have to try completely other ways.
This time it's faster at finding the combination and coming up to speed although is still vibrating at lower speeds. It also continues to do the "emergency stop" on the first autodetect and then just continues spinning and vibrating at a low speed after the second.
 

Attachments

  • out6.txt
    59.2 KB · Views: 3
  • config.h
    2.5 KB · Views: 0
is still vibrating
Of course, as the hall sequence still is not proper.
I think it makes no sense to do further testing in this way. We could try constant ud without current control, but this would need some coding. But I think it's easier to try constant angles in the main.h
 
index.php
Yes, with 2^31 = 180°, -2^31 = -180°

Of course the hall states in the sketch are not representative. The sense of the autodetect is to find the angle of each switch from one hall state to the next....
 
Last edited:
Any ideas
As said before, your motor seems to have an extreme cogging torque, the rotor bounces.
I never had this strange behaviour with a motor I tested...
Maybe the motor has a trapezoidal BEMF waveform and would better be driven by a simple square wave controller....
 
Strangely a 6 FET Kunteng (with your firmware) can drive it without issues.
The Kunteng uses the same logic as I've suggest for several times already. It uses a motor specific angle and uses 60° steps between the hall sectors.

If you look at your various log files, you will find a reasonable start angle for sure....

regards
stancecoke

edit:

I've analyzed your latest logfile and come to the conclusion, that the angles should be:

Hall_45
90​
1073741824​
Hall_51
30​
357913941​
Hall_13
-30​
3937053354​
Hall_32
-90​
3221225471​
Hall_26
-150​
2505397588​
Hall_64
150​
1789569705​

So you can edit your main.h from line 95 to 104:

Code:
#define USE_FIX_POSITIONS 1
//Put values from the startup message after autodetect here, if you want to use fix positions. 32bit values for the hall angles!
#define KV 80
#define HALL_ORDER 1
#define HALL_45 1073741824
#define HALL_51 357913941
#define HALL_13 3937053354
#define HALL_32 3221225471
#define HALL_26 2505397588
#define HALL_64 1789569705

The KV value is not right in this case, but that only matters, if you start rolling without the motor engaged and later asking power from the motor.

For the tricky signed 32bit representation here a little tool ;)
 
Last edited:
Hall_45
90​
1073741824​
Hall_51
30​
357913941​
Hall_13
-30​
3937053354​
Hall_32
-90​
3221225471​
Hall_26
-150​
2505397588​
Hall_64
150​
1789569705​
Thank you, will try.

For the tricky signed 32bit representation here a little tool ;)
Made my own quick script in python but yours is much better.

Just as a sanity check. I can feel the motor cogging when no throttle is applied (in standby) which does not happen on the Kunteng. Is that normal?
 
I can feel the motor cogging when no throttle is applied
The phases are floating, when the PWM is switched off. So there can't be any influence of the controller on the motor.
Maybe your throttle offset is too low, so you get a little power demand with throttle closed. You can disconnect the throttle to check if this has an effect on the cogging.
 
I'm looking at building a trike w/two hub motors(+also likely a mid-drive), and would prefer using this over KT,
but i didn't come across any with reasonable pricing on aliexpress. Given current options at pswpower.com i'm
likely to buy 500w hubs at first, but would prefer controllers which could handle upgrading to 1000w hubs later.

Any ideas/tips on compatible controller models to search for? i mean one that would work with this fw, and have
the rated current around 20A or so for 48V.
 
How is the behaviour with the motor cable disconnected?
Or with the motor connected but the battery disconnected?
The motor spins fine while disconnected or connected to another controller. It's also fine with the battery disconnected.

Hall_45
90​
1073741824​
Hall_51
30​
357913941​
Hall_13
-30​
3937053354​
Hall_32
-90​
3221225471​
Hall_26
-150​
2505397588​
Hall_64
150​
1789569705​
Seems to work better than what autodetect spits out although the motor refuses to accelerate past a certain speed and continues to spin even if I let go of the throttle. It also sometimes just resets while in motion and then stops the motor.
 
That's OK. So you can check the signal between GND and the three phase wires first. There should be no signal, if the motor has been in standstill for several seconds. If you turn the throttle slightly, there should be a square wave with an amplitude of the battery voltage with a duty cycle of about 50% on all three phases.
I expect, that the PWM doesn't turn off with closed throttle. In this case you should comment out the line 510. Then the default value from the config.h will not be overwritten.
The autozero function may fail, if the voltages are not stable fast enough after switching on.

regards
stancecoke
 
Back
Top