KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

stancecoke said:
endlessolli said:
But when actually using the setup / driving, it does not work properly.

Yes, the app is known to freeze the system sometimes. We have the bugfix in the branch "torque from X4" already. @Xnyle has used very much floating point and division operations in the master branch. In combination with the massivie UART communication of the BluOSEC app, we get an overload on the processor. The solution is to replace all the floating points and divisions by integer arithmetics and shifts. It's just half an hour of work to port the solutions of the "torque from X4" branch to the master, but nobody have done this job so far.

stancecoke

Thanks, @stancecoke!
Can you tell / do you know: Is the "torque from X4" branch usable? I.e. for my use case, where I only use the throttle (plus BlueOsec App)?
(No Torque sensing, no PAS, no Regen- just: throttle, rotor angle correction, 'external' Speedsensor and "360 deg interpol at 75")

P.S. I would be glad to help to port to the main branch, but I don't know enough about programming and especially what does what in the OSFM, so I don't want to mess things up.... (Probalby the situation for many others here as well)
You - being deeply familiar with the code - probably think its an easy task and: "These lazy bastards - just want to freeload and when it comes to work, nobody is there...." I definetely would spend the time to do it. But, as said, I am unfortunately pretty clueless. (However, if you want to give some guidance....)
 
endlessolli said:
I.e. for my use case, where I only use the throttle

in this case, you can delete lines 206 to 290 in the ACAsetpoint.c and replace all of the stuff with the simple line (no guarantee, for this simple solution, of course...)

Code:
uint32_current_target = (ui16_sum_throttle*ui16_battery_current_max_value)>>8 + ui16_current_cal_b;

regards
stancecoke
 
stancecoke said:
endlessolli said:
I.e. for my use case, where I only use the throttle

in this case, you can delete lines 206 to 290 in the ACAsetpoint.c and replace all of the stuff with the simple line (no guarantee, for this simple solution, of course...)

Code:
uint32_current_target = (ui16_sum_throttle*ui16_battery_current_max_value)>>8 + ui16_current_cal_b;

regards
stancecoke

Great - I will try that.
One clarification question: Would I apply the above on the master branch or in the Torque from X4 branch?
 
I had a ride on the bike and the resistance from the motor when trying to coast is definitely noticeable. The bike is very easy to pedal if I switch the controller off. On a more positive note, regen works really well and is good fun.

I tried again to do a diagnostic with the exact parameters you were looking for but it won't compile when I add them in. This is what I changed the printf line to

Code:
printf("%u,%u, %u, %u, %u, %u\r\n", ui8_control_state, uint32_current_target, ui16_motor_speed_erps, ui16_BatteryCurrent, ui32_SPEED_km_h, ui16_current_cal_b);

And this is the error. I have attached my current config.h


C:\BMSBattery_S_controllers_firmware-Master>PATH = C:\Program Files (x86)\STMicr
oelectronics\st_toolset\asm;C:\Program Files (x86)\Common Files\Oracle\Java\java
path;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32
\WindowsPowerShell\v1.0\;C:\EDIABAS\BIN\;C:\Program Files (x86)\Universal Extrac
tor;C:\Program Files (x86)\Universal Extractor\bin;C:\Program Files\SDCC\bin;C:\
Program Files\STMicroelectronics\st_toolset\stvp;C:\Program Files (x86)\STMicroe
lectronics\st_toolset\stvp;C:\SDCC\usr\local\bin

C:\BMSBattery_S_controllers_firmware-Master>REM ;C:\BMSBattery_S_controllers_fir
mware-Master\tools\cygwin\bin

C:\BMSBattery_S_controllers_firmware-Master>cd C:\BMSBattery_S_controllers_firmw
are-Master\

C:\BMSBattery_S_controllers_firmware-Master>del main.hex
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\main.hex

C:\BMSBattery_S_controllers_firmware-Master>sdcc --version
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININativ
e/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.0 #11528 (MINGW64)
published under GNU General Public License (GPL)

C:\BMSBattery_S_controllers_firmware-Master>make -f Makefile_windows clean
echo "Cleaning files..."
"Cleaning files..."
cmd /C del *.asm
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.asm
cmd /C del *.rel
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.rel
cmd /C del *.lk
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.lk
cmd /C del *.lst
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.lst
cmd /C del *.rst
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.rst
cmd /C del *.sym
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.sym
cmd /C del *.cdb
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.cdb
cmd /C del *.map
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.map
cmd /C del *.adb
Could Not Find C:\BMSBattery_S_controllers_firmware-Master\*.adb
echo "Done."
"Done."

C:\BMSBattery_S_controllers_firmware-Master>make -f Makefile_windows
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oBOdisplay.c BOdisplay.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oACAcontrollerState.c ACAcontrollerState.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oACAeeprom.c ACAeeprom.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oACAsetPoint.c ACAsetPoint.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oACAcommons.c ACAcommons.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -ogpio.c gpio.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -ocruise_control.c cruise_control.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -ouart.c uart.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oadc.c adc.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -obrake.c brake.c
brake.c:23: warning 110: conditional flow changed by optimizer: so said EVELYN t
he modified DOG
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -otimers.c timers.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -opwm.c pwm.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -omotor.c motor.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oPAS.c PAS.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -oSPEED.c SPEED.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -odisplay.c display.c
sdcc -c -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debu
g -odisplay_kingmeter.c display_kingmeter.c
sdcc -IStdPeriphLib/inc -I. -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug
main.c StdPeriphLib/src/stm8s_itc.rel StdPeriphLib/src/stm8s_clk.rel StdPeriphLi
b/src/stm8s_iwdg.rel StdPeriphLib/src/stm8s_gpio.rel StdPeriphLib/src/stm8s_exti
.rel StdPeriphLib/src/stm8s_uart2.rel StdPeriphLib/src/stm8s_tim1.rel StdPeriphL
ib/src/stm8s_tim2.rel StdPeriphLib/src/stm8s_adc1.rel StdPeriphLib/src/stm8s_fla
sh.rel BOdisplay.rel ACAcontrollerState.rel ACAeeprom.rel ACAsetPoint.rel ACAcom
mons.rel gpio.rel cruise_control.rel uart.rel adc.rel brake.rel timers.rel pwm.r
el motor.rel PAS.rel SPEED.rel display.rel display_kingmeter.rel
main.c:193: error 20: Undefined identifier 'ui8_control_state'
main.c:193: error 20: Undefined identifier 'ui32_SPEED_km_h'
make: *** [main] Error 1
 

Attachments

  • config.h
    1.4 KB · Views: 14
endlessolli said:
Would I apply the above on the master branch or in the Torque from X4 branch?

to the master.

sylvain_wm said:
I had the same issue : ui32_SPEED_km_h and ui8_control_state don't exist.

Ah, the variable names in the wiki seem to be outdated.
ui16_control_state (is already printed by default)

the speed in kph * 100 has to be calculated from ui16_virtual_erps_speed/ui16_speed_kph_to_erps_ratio (not sure about the 100)

so the print command can could be

Code:
printf("%u,%lu, %u, %u, %u, %u\r\n", ui16_control_state, uint32_current_target, ui16_virtual_erps_speed, ui16_BatteryCurrent, ui16_virtual_erps_speed/ui16_speed_kph_to_erps_ratio, ui16_current_cal_b);

regards
stancecoke
 
stancecoke said:
endlessolli said:
I.e. for my use case, where I only use the throttle

in this case, you can delete lines 206 to 290 in the ACAsetpoint.c and replace all of the stuff with the simple line (no guarantee, for this simple solution, of course...)

Code:
uint32_current_target = (ui16_sum_throttle*ui16_battery_current_max_value)>>8 + ui16_current_cal_b;

regards
stancecoke

@stancecoke
When I do that, I get the following compile error:
Code:
C:\BMSBattery_S_controllers_firmware-Master>make -f Makefile_windows
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oBOdisplay.c BOdisplay.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAcontrollerState.c ACAcontrollerState.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAeeprom.c ACAeeprom.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAsetPoint.c ACAsetPoint.c
ACAsetPoint.c:328: error 20: Undefined identifier 'ui8_walk_assist'
ACAsetPoint.c:354: error 1: Syntax error, declaration ignored at 'ui16_control_state'
ACAsetPoint.c:354: syntax error: token -> '=' ; column 21
make: *** [ACAsetPoint.rel] Error 1
(It states something about 'ui8_walk_assist'. I don't use walk_assist, but I don't see, where I would disable that in the configurator either)

To double check, if I did this as intended by you, I'll attatch the ACAsetpoint.c fileView attachment ACAsetPoint.c

If you have time, it would be great, if you coud give me a hint.

Thanks, again
 
stancecoke said:
endlessolli said:
If you have time

very simple solution: you have to comment out just one line more ( the "}") :wink:

regards
stancecoke

Doh! Thank you, @stancecoke!

However, 1 error remains after your suggested correction:

Code:
C:\BMSBattery_S_controllers_firmware-Master>make -f Makefile_windows
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oBOdisplay.c BOdisplay.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAcontrollerState.c ACAcontrollerState.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAeeprom.c ACAeeprom.c
sdcc -c -IStdPeriphLib/inc -I.  -mstm8 --std-c99 --nolospre --out-fmt-ihx --debug  -oACAsetPoint.c ACAsetPoint.c
ACAsetPoint.c:328: error 20: Undefined identifier 'ui8_walk_assist'
make: *** [ACAsetPoint.rel] Error 1

Do you have further hints?
 
endlessolli said:
Do you have further hints?

Hm, I have no problems with compiling.
ui8_walk_assist is defined in the ACAcontrollerState.h, that is included by the ACAsetPoint.c
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/search?q=ui8_walk_assist

In doubt, just comment out the line 328....

regards
stancecoke
 
stancecoke said:
Hm, I have no problems with compiling.
ui8_walk_assist is defined in the ACAcontrollerState.h, that is included by the ACAsetPoint.c
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/search?q=ui8_walk_assist

In doubt, just comment out the line 328....

regards
stancecoke

Strange, that it works for you and not in my case.
But - commenting out line 328 works -> compiles w/o error.
Thanks!
I will try it on the bike tomorrow.

Update:
I noticed that I did not work off the latest github version. (mine was from July last year and after that there were changes done to walk assist. That explains the different behavior)
Updating to the newest version resolves the compiling error and now I do not have to comment out line 328.

-> All good - will test tomorrow
Thanks again @stancecoke!
 
Well I tried to program the controller again tonight to get more debug logs to you but it won't program anymore as it has probably been programmed about 300 times and the chip can't be written to now. I have another 6 fet kt controller without phase current sensing which still programs without issue. I think I am just going to have to leave it now and find a different foc controller as this is just costing too much time and money.

>>> Programming PROGRAM MEMORY
(API) ERROR : Cannot communicate with the device !
Check the SWIM cable connection and check all the needed pin connections on the
SWIM connector.

If the application code uses Swim Disable and Reset pin as Output or has disable
d SWIM Clock Divider:
Try Now to SWITCH OFF and ON the application Power Supply while NRST Reset pin i
s forced low.

<<< Programming PROGRAM MEMORY fails

C:\BMSBattery_S_controllers_firmware-Master>pause
Press any key to continue . . .
 
OK, here is another log file of the motor giving quite strong drag and the controller consuming about 650ma at 46.4v while doing this.

This log was made using this printf line
Code:
printf("%u,%lu, %u, %u, %u, %u\r\n", ui16_control_state, uint32_current_target, ui16_virtual_erps_speed, ui16_BatteryCurrent, ui16_virtual_erps_speed/ui16_speed_kph_to_erps_ratio, ui16_current_cal_b);

We really need to have the software changed so that whenever the throttle is closed, or less than the current speed of the bike, all pwm is off unless regen is called for in which case the bottom mosfets of the h bridge are pulsed at the required duty cycle to give the desired regen.

Additionally, how can I enable field weakening?
 

Attachments

  • drag2.log
    6 KB · Views: 15
sdobbie said:
the controller consuming about 650ma at 46.4v while doing this.

I guess, it is producing 650 mA, not consuming. As you said before, your wattmeter can't show negative values...

As you can see in the graph, the cal b value is lower than the current reading at standstill. So the battery current is controlled to be slightly negative (this means regen) during dragging. As I suggested several times now, just tune the offset a little. e.g ui16_current_cal_b += 1; instead of ui16_current_cal_b -= 1;

The speed log doesn't work obviously, so I calculated the speed in kph x10 from the erps by the formula
speed (kph x10) = erps/gearratio*3600*wheel circumference/1000000*10

Switching on the PWM while the wheel is turning with a direct drive is dangeorus for the FET's as you're getting high voltage and current peaks, if the duty cycle does not match exactly with the recent BEMF....

regards
stancecoke

p.s. please draw the graph yourself next time, I'm not your plotting service... :wink:

Drag with speed and target.JPG
 
endlessolli said:
stancecoke said:
Hm, I have no problems with compiling.
ui8_walk_assist is defined in the ACAcontrollerState.h, that is included by the ACAsetPoint.c
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/search?q=ui8_walk_assist

In doubt, just comment out the line 328....

regards
stancecoke

Strange, that it works for you and not in my case.
But - commenting out line 328 works -> compiles w/o error.
Thanks!
I will try it on the bike tomorrow.

Update:
I noticed that I did not work off the latest github version. (mine was from July last year and after that there were changes done to walk assist. That explains the different behavior)
Updating to the newest version resolves the compiling error and now I do not have to comment out line 328.

-> All good - will test tomorrow
Thanks again @stancecoke!

@stancecoke
So, programming worked as stated. However - with the suggested change, my motor spins at a constant speed, ignoring any (thumb-) throttle input.

But don't bother with this too much - I don't need BlueOsec App functionality that urgend.
My setup works with your std. masterbranch (w/o display) very quiet and nicely. That is all I really need .
Anything else is 'icing on the cake' / toying around.

Thanks again!
 
Nope, it's definitely consuming. I have found my watt meter which can register negative flow and it does regenerate a bit when I spin it up as we saw in another graph and then it starts consuming power and creating a noticeable drag. As I said before, changing the cal value to negative makes the wheel turn slowly and if I add speed to that by turning the pedals, it starts consuming power. The least drag was achieved by setting the cal value to zero but I am looking for no noticeable drag. Every other controller I have ever used does not place a drag on the motor when coasting so I don't see why this one should be any different. I also wasn't asking you to be my plotting service, I was only providing the log files YOU asked for.

PWM auto off is a great feature but I need to bring the bike to a stop to get the pwm to turn off if I use the throttle during coasting .

Again, how do I enable the field weakening?
 
sdobbie said:
if I add speed to that by turning the pedals, it starts consuming power

very strange, the current reading from the internal shunt say's clearly, that there is slight regen. No idea where a positive current should come from, that not passes the shunt :?

I'm using a BionX IGH3 direct drive with a Kunteng 6 FET and this firmware on my bike for my daily commuting, I have no drag at all. So I can't help any further at this point.

Regarding field weakenig: This feature is not implemented in the firmware. It could be implemented easyly by increasing the advance angle with speed and load more than we are doing actually for max torque and min loss. Feel free to do it, make a pull request at github, then I can merge your solution to the master.
I can't see any sense in field weakening. Increasing the battery voltage is the better way to get higher speeds.

Regarding switching PWM on while the wheel is turning: You have to know the kv constant of your motor excactly, then you can preload the PI-control to have the correct dutycyle directly at the start of the PWM. I've implemented something similar to optimize the regen at low speed. But I won't make it a feature in this firmware, as it carries a massive risk to burn your controller.

regards
stancecoke
 
It is definitely puzzling. Do you think that maybe I should try mechanical calibration on the battery current shunt by fililing away small amounts of material or adding a tiny bit of solder?

Does your 6 fet controller have the phase current sensor? I have a 6 fet which doesn't and could test tonight and see if the issue affects that one too.
 
sdobbie said:
Do you think that maybe I should try mechanical calibration on the battery current shunt

No, I guess this would only influence the battery current cal a factor.

sdobbie said:
Does your 6 fet controller have the phase current sensor?
yes, but I think it's not a matter of the controller, but of your specific motor. A geared motor with regen was never used before in this project, I think.

Perhaps, it would be interesting, what happens with the advance angle during dragging. You could print out ui8_position_correction_value and make a new log.

regards
stancecoke
 
Will do. I will make a graph of it too to save you time. I think my hall angles 1 to 6 being slightly off might have something to do with it also. I made a separate topic about that because I was using osec app to look at the hall angles and you don't use the osec app.
 
Hi guys, what max phase motor current can I configure? I have a 18fet KT (stock hardware, didn't mod the fets or caps), running at 16S. My battery is limited to 50A so I though that 120A would be an OK value. is there any risk to burn the fets ? What is the absolute max phase amp in stock configuration?
 
Hi,
atkforever said:
My battery is limited to 50A so I though that 120A would be an OK value.
I don't know what kind of motor you have, but 20 amps in a motor winding is already a lot.
If your motor is a 1000W, a 16S battery provides 60V
power = voltage times current => current = power / voltage = 1000/60 = 16.7A
I would start testing 15 amps max for the battery current.
If the wires don't heat up at all, I would increase the value little by little.
Only the battery current is limited by the program.
 
My motor is a MXUS 3K rated at 3000W nominal (90N.M torque and 800RPM at 60V)

Hef194db223824b0898acf0b8d6490035s.jpg


Hfba20b3e64e24e8c9f25bdb07ff4f94cd.jpg
 
I did another motor drag test and noted ui8_position_correction_value and it stayed at 127 constantly. I also connected an old analog ammeter up to the controller just in case my digital wattmeter was getting confused. The ammeter showed 1 amp power consumption while the motor was dragging.

Surely it must be possible to disable pwm when one lets off the throttle as the rotor position can be sensed with the hall sensors so when power is needed again, the pwm can switch on with correct timing. Every other controller does this. I sadly don't have any programming skills so I can't implement that feature.
 
Back
Top