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

[stancecoke]

not completely.

if motor is rotating already, it generates a voltage on his phase wires(the BEMF) and we need to put the same voltage with PWM duty_cycle, other different value is like a "short-circuit"/high currents flowing.

That's wrong, if both voltages are exactly the same you can't get any mechanical power out of it. (see "nominal speed")

We want phase B current to be zero at a hallsensor interrupt, therefore the voltage has to be 90° ahead. You have already used a proper configuration in the older branches, e.g. in the J-LCD, here the efficiency is good!

If you look at the "shift_of_angles_transparancy" branch you will find:
1. The ui8_position_correction_value sets the advance angle at higher speeds / loads and is zero at low speed without load (defined as signed integer, as it can get negative...).
2. The MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT is the deviation in the mecanical position of the hallsensors (not exactly 120° due to manufacturing tolerances) and is something about zero
3. The phase shift between voltage and current is taken into account in the start value of the SVM table.

It should be possible to start the SVM table with zero, but then you have to consider the 90° phase shift in the MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT value. Looking at the sketch, I assume, that it has to be set to 30° (21@8bit) in the "shift_of_angles_transparancy" case. I havn't tried that in hardware.

regards
stancecoke

 

[casainho]

not completely.

if motor is rotating already, it generates a voltage on his phase wires(the BEMF) and we need to put the same voltage with PWM duty_cycle, other different value is like a "short-circuit"/high currents flowing.

That's wrong, if both voltages are exactly the same you can't get any mechanical power out of it. (see "nominal speed")

Sorry for missing the subjects. This is about trying the startup the motor while it is already running. And you are correct, both voltages equal, no mechanical power out of it, because it has already mechanical power and that is the reason why it is already running/coasting without using electric power.

We want phase B current to be zero at a hallsensor interrupt, therefore the voltage has to be 90° ahead. You have already used a proper configuration in the older branches, e.g. in the J-LCD, here the efficiency is good!

I must say it was with luck / many testing. I think I didn't spotted before this issue because I was running the motor without load. Tomorrow I hope to make many tests and use all the information you shared so I can make it working well!! -- the bike training rollers, I should bought them since the beginning

 

[stancecoke]

As I see, in your recent SVM7 branch, you are using the same SVM-Table as in the J-LCD branch. So that's not the problem.
That leads me back to the assumption, that the ADC is not working properly in interpolation mode in the SVM7 branch, so FOC is not working, and efficiency is bad...
Perhaps you can try the thing with the reading of phase B current at every hallsensorstate change and print these values in the slow loop, see the "shift_of_angles_transparancy"-branch.

BTW: I still don't understand, why you start up in 6 step mode. In my eyes, theres no need to do so, as we use hallsensors for position-detection. In sensorless mode it is necesseary of course.

Regards
stancecoke

 

[casainho]

As I see, in your recent SVM7 branch, you are using the same SVM-Table as in the J-LCD branch. So that's not the problem.
That leads me back to the assumption, that the ADC is not working properly in interpolation mode in the SVM7 branch, so FOC is not working, and efficiency is bad...
Perhaps you can try the thing with the reading of phase B current at every hallsensorstate change and print these values in the slow loop, see the "shift_of_angles_transparancy"-branch.

As I told, yesterday I did some very quick tests. Today I found:
- speed at 6 steps is measured as half of real value, so as I am using a speed controller, on the transition did happen to a double speed and so the double current I was seeing. Although I could not yet understand why this error measuring the speed, I just correct it with an if and I can see the sinewave follow the same current value as 6 steps so I don't think sinewave have less efficiency than 6 steps. Also, seems that on transition, the speed jumps up but then goes down, I really think that duty_cycle value in sinewave should be lower to represent the same electric motor input -- I need to setup my system to be able to log this transition over UART.

BTW: I still don't understand, why you start up in 6 step mode. In my eyes, theres no need to do so, as we use hallsensors for position-detection. In sensorless mode it is necesseary of course.

I use because as I tested before, my Q85 motor could not startup with torque (it did startup but without torque). Also original firmware statups in 6 steps: https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S_series--BMSBattery_S06S--PWM_signals--very_low_speed_-_6_steps.html

Note that S06P just runs with 6 steps: 6 steps = square wave = block commutation.

 

[casainho]

BMSBattery did sell to me 1 unit of the BB Torque sensor and 1 unit of the Bluetooth module, I just had to ask them with a message and here is the answer with the costs -- if anyone want to buy, just ask them with a message:

You need pay more $59 ($50 for B. B. Torque Sensor and $9 for bluetooth controller) to this link: https://bmsbattery.com/ebike-parts/637-extra-shipping-cost-or-other-cost-parts.html

I bought some new material from BMSBattery that I will use to help develop of:
- S06S: to have a controller with original firmware to compare with our OpenSource firmware
- Torque sensor: to develop and test the code for the torque sensor
- Q11 36V1Kw direct drive motor: help to develop regen/braking and startup the motor while it is already running
- Bluetooth module: to develop the Android app

 

[stancecoke]

I don't think sinewave have less efficiency than 6 steps

Can you please do the test with the current value at all six hall interrupts and correction value printed out. I won't believe it until i see it :wink: , as it doesn't work with your hex-file at my controller.

Thank you,
stancecoke

 

[casainho]

I don't think sinewave have less efficiency than 6 steps

Can you please do the test with the current value at all six hall interrupts and correction value printed out. I won't believe it until i see it :wink: , as it doesn't work with your hex-file at my controller.

I will prepare my setup to log by UART and I will take oscilloscope screenshots of phase B current and hall sensors. Yes, I want to make sure FOC is working, maybe I will try to take some screenshots with and without FOC.

 

[casainho]

I don't think sinewave have less efficiency than 6 steps

Can you please do the test with the current value at all six hall interrupts and correction value printed out. I won't believe it until i see it :wink: , as it doesn't work with your hex-file at my controller.

So you are correct, for some reason FOC control isn't working....

Without FOC working, the efficiency of sinewave seams equal to the of 6 steps. With FOC working, will we get better efficiency on sinewave??

See the variables - ui8_position_correction_value is always at the reset value of 127.
ui8_motor_interpolation_state = 2 when 6 steps
ui8_motor_interpolation_state = 3 when sinewave

printf ("%d, %d, %d, %d\n", ui8_duty_cycle, motor_get_motor_speed_erps (), , ui8_position_correction_value);

 

[stancecoke]

So you are correct, for some reason FOC control isn't working....

I guess that we are running out of time in the fast loop, as ADC works properly in 6 step mode. We have to shift some of the control work back into the slow loop, I think. Undervoltage protection and speed limit can be done in the slow loop with no problems. Even the current limiting should be uncritical in the slow loop, as we have the OC interrupt active to protect the hardware....

regards
stancecoke

 

[casainho]

I got FOC working again and the issue was this


In sinewave, 1 phase was disabled, only 2 were working -- that was why that different motor noise on my last videos.

I also corrected the issue of incorrect measuring erps speed while in 6 steps. On the other side, now the motor now always start unless we rotate a bit by hand -- will correct tomorrow.

So here is FOC working:


Here the current and see how it is near the signal of the hall sensor:


And now with FOC disabled: motor was running at the same speed - 16km/h and with the same load, so with the same mechanical power ouput. But as we can see, the amplitude of the phase B current is higher to maintain the same speed and we can see that the sinewave is now a bit more far from the hall sensor transition signal:

 

[stancecoke]

Hey, that's great, then I was completly wrong with my guess!!! I'll try it with my motor tomorrow, when you've uploaded the bugfixes to github. I hope it will run if it's compiled with windows....

regards
stancecoke

 

[casainho]

Hey, that's great, then I was completly wrong with my guess!!! I'll try it with my motor tomorrow, when you've uploaded the bugfixes to github. I hope it will run if it's compiled with windows....

The code seems stable now, I corrected:
- issue where the motor sometimes didn't start
- motor quick start / draw current when powering on the system

This commit: https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/commit/ff7066fb172cca7c37e091aa011d4d01fda85b2a

 

[casainho]

Seems that a very fast change on duty_cycle / trying to accelerate fast the motor, gives problems and it fails to run well. The original firmware also accelerates kind of slow.
The "very low resolution FOC" implemented needs time, it is slow, the motor can't change rapidly. For this, seems to me that a value of 50 steps of PWM is ok for motor not failing:

motor_set_pwm_duty_cycle_ramp_inverse_step (50); // each step = 64us

Another limitation that makes everything working well, is limiting the motor max ERPS speed, to be 40 points for the sinewave at max speed -- other than that the motor starts to use to much current:

#define MOTOR_OVER_SPEED_ERPS 390 // motor max speed, protection max value | 40 points for the sinewave at max speed

390 ERPS on my Q85 RPM 328 24V, 26'' wheel, it is about 28km/h.

Also the current controller using the current shunt signals seems kind of bad, it also lacks resolution. For now it is ok if we do not use torque control with it but just control the motor max current, that seems to work ok now when accelerating to max / pushing throttle from 0 to max.
So this torque control should not be used:

  // throttle will setup motor current from 5A to 15A
  ui16_temp = (uint16_t) (map ((int32_t) ui8_ADC_throttle, ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 10, ADC_MOTOR_CURRENT_MAX));
  motor_set_current_max (ui16_temp);

And put instead a fixed value at start of main:

#define ADC_MOTOR_CURRENT_MAX 30 	// 30 = 15A; 1 --> 0.5A
  motor_set_current_max (ADC_MOTOR_CURRENT_MAX); // 1 --> 0.5A
  motor_set_regen_current_max (4); // 1 --> 0.5A

I had exchanged some e-mails with a contact from minshine.cn (Kunteng) and I now think phase B is also used for torque control. Looking at the oscilloscope screenshots of FOC working, we can see that measuring Iq current seems to be possible and that is how torque control is done on FOC systems. This my next task!!

 

[stancecoke]

Hm, I tried the recent master branch.
edit: very strange, just after powering up the system, the UART and motor works for 2-3 seconds, then motor and UART stops. Stack Overflow?!

I think, again, it's a topic of the windows compiler. But I have no idea how to solve this problem (execpt of switching to Linux, but that's no option)

I've opened a discussion at the SDCC forum, perhaps we can get a solution from there..
https://sourceforge.net/p/sdcc/discussion/1864/thread/0fe344c3/

regards
stancecoke

 

[casainho]

Hm, I tried the recent master branch. Nothing works. The controller is just doing nothing. I think, again, it's a topic of the windows compiler. But I have no idea how to solve this problem (execpt of switching to Linux, but that's no option)

I've opened a discussion at the SDCC forum, perhaps we can get a solution from there..
https://sourceforge.net/p/sdcc/discussion/1864/thread/0fe344c3/

In your situation I would use the Stlink debugger and try find where the code hangs, etc. But I guess you don't have the debugger also working on Windows. SDCC is not bug free, sometimes I see myself put variables global otherway the code simple fails...

 

[casainho]

So today I found:
- as Stancecoke reported before, phase B currnt ADC signal is not working in full, works enough to do FOC but not to read the current full amplitude - as reported, I didn't verified but seems it works ok when running 6 steps but with the issue when running with sinewave, maybe it is something with the changing configuration of the pins to output symmetric PWM...

- the PI speed controller, altough it works, don't take in account the negative errors - I want to test another way to do it and if works, I will try to do the torque controller in the same way

 

[stancecoke]

In the SDCC forum it was suggested to compare the assembler files from the Linux and Windows output to find the difference. Can you upload your .asm files from linux, please, then I will take a look at it.

regards
stancecoke

 

[casainho]

In the SDCC forum it was suggested to compare the assembler files from the Linux and Windows output to find the difference. Can you upload your .asm files from linux, please, then I will take a look at it.

Here: http://myaccount.dropsend.com/file/214f72aae314ea9a
Since they are text files, use Meld to compare you folder and the folder I am sending. It will show visually which files have differences and which are them.

 

[stancecoke]

Your zip file can't be downloaded, there's a message, that it was downloaded 10 times already...
Please pack only the .asm files into the archive, I don't need to download 160MB for a few lines of text

Thank you!
stancecoke

 

[casainho]

Your zip file can't be downloaded, there's a message, that it was downloaded 10 times already...
Please pack only the .asm files into the archive, I don't need to download 160MB for a few lines of text

View attachment OpenSource-EBike-firmware-ASM.zip

 

[stancecoke]

Thank you!

The difference seems to be in the debug information, mainly. I've compiled without the --debug option already, but it still doesn't work :-(

regards
stancecoke

 

[daffy99]

The difference seems to be in the debug information, mainly.

Your screen shot shows one additional difference: push and pop interaction with the stack (line 112 vs line 138). This is almost certainly a result of debug builds vs optimizing builds, or a difference between compiler versions.

In any event, try getting "push fp" on the Windows side, too, by turning off optimization at large, or by explicitly turning off specific code generation options related to register usage and / or stack-relative addressing (frame pointer whatever)

FWIW, and that's just a remark, because I don't know anything, I do notice a very pronounced absence of the C keyword "volatile" in the firmware C source code (git repo search). I keep reading about interrupts and global variables all the time, though, which we would indicate that volatile would rather be expected ...

 

[casainho]

FWIW, and that's just a remark, because I don't know anything, I do notice a very pronounced absence of the C keyword "volatile" in the firmware C source code (git repo search). I keep reading about interrupts and global variables all the time, though, which we would indicate that volatile would rather be expected ...

Must say that I just use local/static local or global variables. I don't know why the need of volatile, need to read about that.

And the optimizations, I have them turned off on the makefile options inside. I need no optimizations to be able to better debug the code.

 

[daffy99]

And the optimizations, I have them turned off on the makefile options inside. I need no optimizations to be able to better debug the code.

That much is evident from all the push/pop in _your_ assembly output

 

[stancecoke]

I think I got the solution now

I took the SDCC installation from the original source:
https://sourceforge.net/projects/sdcc/files/
This leads to different compiler output.

Now I tried the SDCC version from the STM8 binutils:
https://sourceforge.net/projects/stm8-binutils-gdb/files/cygwin/x86/release/sdcc/

With this I get the same output as you 8)

regards
stancecoke