Lishui "Open Source Firmware" project / KingMeter 5S

You are definitely reading only the last message.

Thanks for the offer.

Let me check everything myself first. I suspect the STM32 itself. Maybe it's too fake. Why didn't it want to start on the latest firmware versions?



If possible, explain how to see what comes to the controller inputs in Eclipse. And how would you look for a malfunction?
 
You are definitely reading only the last message.
:ROFLMAO: OK, my fault.
If possible, explain how to see what comes to the controller inputs in Eclipse.
Hm, you can look at the variable values at the point that interests you by setting a breakpoint to the interested line of code. But a breakpoint will pause the execution, so you should not do that while the PWM is on. To debug when the motor is running, you better print out the interested variables to UART.

I would start open loop with constant ud and constant uq, to check if the rotor is turning without bouncing then.
The autodetect worked in this way in an early phase of the project, but I switched to current control some day, as no control of the current may lead into magic smoke....

https://github.com/EBiCS/EBiCS_Firmware/blob/ccc2e2baea7d77fc2e48ba8d8ba01c9515ad6794/Src/FOC.c#L90
 
Last edited:
I would start open loop with constant ud and constant uq, to check if the rotor is turning without bouncing then.
The autodetect worked in this way in an early phase of the project, but I switched to current control some day, as no control of the current may lead into magic smoke....
If possible, a little more detail. I understand the idea. Start the motor with self-determination without current feedback and, accordingly, without a PI controller. Simply by controlling the magnetic field using the voltage on the phases. In static mode and when slowly turning the motor without load, this works. In dynamics, the current in the windings can grow infinitely, destroying everything in its path.

We did something close to this by reducing the p-factor and i-factor in the configurator.

But I still haven’t figured out how to practically start the engine in an open circuit.
 
But I still haven’t figured out how to practically start the engine in an open circuit.
In the new generation branch, you can set the commutation mode to Sensorless_openloop and try to start the motor by the throttle without the autodetect active. If this option is implemented already in the commit that you are using:

Code:
MP.com_mode=Sensorless_openloop;


If not, you have to paste this lines in the FOC.c manually to overwrite the output of the PI control by constant values directly before calling the inverse park in the autodetect routine. You can increase u_d slightly if you see, that the motor is drawing less than 2A with this setting. A battery current between 2A and 5A during the autodetct is OK, normally.

Code:
    if(!MS_FOC->hall_angle_detect_flag){
        MS_FOC->u_d = 200;
        MS_FOC->u_q = 0;
    }
 
Last edited:
PI_flag=1;
// if (MS_FOC->KV_detect_flag) {
// MS_FOC->u_q=MS_FOC->KV_detect_flag;
// MS_FOC->u_d=0;
// }
// else runPIcontrol();

runPIcontrol();

if(!MS_FOC->hall_angle_detect_flag){
MS_FOC->u_d = 300;
MS_FOC->u_q = 0;
}

//inverse Park transformation
arm_inv_park_q31(MS_FOC->u_d, MS_FOC->u_q, &q31_u_alpha, &q31_u_beta, -sinevalue, cosinevalue);

Is that right?

The engine's behavior has changed little.
 

Attachments

  • log.txt
    8.2 KB · Views: 1
  • VID-20250822-WA0000.7z
    3.1 MB · Views: 4
Last edited:
The engine's behavior has changed little.
Hm, strange. The start looks good. No idea, why the rotor jumps back. 🤷‍♂️
How much battery current is drawn during autodetect?
You could print out the angle in each loop run. Will be much slower, but we can see, if there is something wrong with increasing the angle.

Add this line to line 2200:

Code:
printf_("%d \n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8));
 
Last edited:
Code:
HAL_Delay(5);
    for (i = 0; i < 1080; i++) {
        q31_rotorposition_absolute += 11930465; //drive motor in open loop with steps of 1 deg
        HAL_Delay(5);
        //printf_("%d, %d, %d, %d\n", temp3>>16,temp4>>16,temp5,temp6);


//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

printf_("%d \n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8));

//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

        if (ui8_hall_state_old != ui8_hall_state) {
            printf_("angle: %d, hallstate:  %d, hallcase %d \n",
                    (int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),
                    ui8_hall_state, ui8_hall_case);

The current of the BMS shows from 1.5 to 4 amperes.
 

Attachments

  • log.txt
    7.9 KB · Views: 2
printf_("%d \n"
Hm, this didn't work as expected.
Try to increase the delay in the for loop to 20 or 100 and put it behind the print command. There must be 1080 (3x360) lines with the increasing angle in the printout.

Code:
HAL_Delay(5);
    for (i = 0; i < 1080; i++) {
        q31_rotorposition_absolute += 11930465; //drive motor in open loop with steps of 1 deg
 
        //printf_("%d, %d, %d, %d\n", temp3>>16,temp4>>16,temp5,temp6);


//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

printf_("%d \n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8));
       HAL_Delay(20);
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 
Last edited:
It worked. The behavior is incomprehensible.
indeed. Let's print the dutycycle of each phase also, Maybe, you have to increase the delay a little more...

Code:
HAL_Delay(5);
    for (i = 0; i < 1080; i++) {
        q31_rotorposition_absolute += 11930465; //drive motor in open loop with steps of 1 deg
 
        //printf_("%d, %d, %d, %d\n", temp3>>16,temp4>>16,temp5,temp6);


//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

printf_("%d, %d, %d ,%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
       HAL_Delay(50);
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 
Last edited:
make: *** [Src/main.o] Error 1

D:\ELECTRON\VESC\Lishui\EBiCS_Firmware-2261029\Debug>ST-LINK_CLI.exe -c SWD -P LishuiFOC_01.hex -V
STM32 ST-LINK CLI v3.6.0.0
STM32 ST-LINK Command Line Interface

ST-LINK SN: 37FF71064E5734365EB61343
ST-LINK Firmware version: V2J37S7
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Normal
Reset mode: Software reset
Device ID: 0x410
Device flash Size: 64 Kbytes
Device family: STM32F10xx Medium-density

Loading file...
Unable to open file!


D:\ELECTRON\VESC\Lishui\EBiCS_Firmware-2261029\Debug>pause
 
../Src/main.c:2224:2: error: expected ';' before '}' token
}
^
make: *** [Src/main.o] Error 1
 
Building file: ../Src/main.c
Invoking: MCU GCC Compiler

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft '-D__weak=__attribute__((weak))' -DARM_MATH_CM3 '-D__packed=__attribute__((__packed__))' -DUSE_HAL_DRIVER -DSTM32F103x6 -I ../INC -I ../Drivers/STM32F1xx_HAL_Driver/Inc -I ../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -I ../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I ../Drivers/CMSIS/Include -Os -g3 -Wall -fmessage-length=0 -ffunction-sections -c -fmessage-length=0 -MMD -MP -MF"Src/main.d" -MT"Src/main.o" -o "Src/main.o" "../Src/main.c"
../Src/main.c: In function 'autodetect':
../Src/main.c:2163:18: error: 'd' undeclared (first use in this function)
printf_("%d, "%d, "%d ,"%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
^
../Src/main.c:2163:18: note: each undeclared identifier is reported only once for each function it appears in
../Src/main.c:2163:29: error: stray '\' in program
printf_("%d, "%d, "%d ,"%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
^
../Src/main.c:2163:30: error: expected ')' before 'n'
printf_("%d, "%d, "%d ,"%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
^
../Src/main.c:2163:31: warning: missing terminating " character
printf_("%d, "%d, "%d ,"%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
^
../Src/main.c:2163:31: error: missing terminating " character
printf_("%d, "%d, "%d ,"%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../Src/main.c:2224:2: error: expected ';' before '}' token
}
^
make: *** [Src/main.o] Error 1
 
Code:
for (i = 200; i < 1080; i++) { //i = 0
        q31_rotorposition_absolute += 11930465; //drive motor in open loop with steps of 1 deg
        HAL_Delay(5);
        //printf_("%d, %d, %d, %d\n", temp3>>16,temp4>>16,temp5,temp6);


        //

        //printf_("%d \n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8));
        printf_("%d, %d, %d ,%d\n",(int16_t) (((q31_rotorposition_absolute >> 23) * 180) >> 8),TIM1->CCR1,TIM1->CCR2,TIM1->CCR3);
        HAL_Delay(50);
 

Attachments

  • log.txt
    26.3 KB · Views: 4
Last edited:
It seems to me that at some point the real angles of the magnetic field stop corresponding to what we see in the log. And at that moment the motor turns back, which is visible by the switching of the Halls.
 
to what we see in the log
The log looks like something out of the textbook ;) I can't understand why you are starting at 200 with the loop counter, not at zero, but that doesn't matter.
1755872616681.png

but several hall switches are missing (-120°, 0°....) and obviously the voltage pointer is not what it should be in reality.
So I think we have to search the fault on the hardware side...
You could try to set the angle to a fixed value (just comment out the increment operation in the for loop) at different angle steps and look at the dutycycles on each phase with the oszi (or just the voltage with a simple multimeter). You can do that during the autodetect without the motor connected, as we are working with constant ud and uq.

-2^31 --> -180°
0 --> 0°
+2^31 --> +180°

Try the angles -180°, -120°, -60°, 0°, +60°, +120°

signed 32 bit integerdegree
2147483648180
1431655765120
71582788360
00
-715827883-60
-1431655765-120
-2147483648-180
 
Last edited:
I can't understand why you are starting at 200 with the loop counter, not at zero, but that doesn't matter.
I don't start anything. It just works that way. Can I influence it?


So I think we have to search the fault on the hardware side...
I have no doubt about that.

When the motor is switched off, there is nothing at any fixed angle on one of the phases.

But if the motor is connected, there is PWM.

No, it was a bad contact.

Still, there is zero on one phase.
 
Last edited:
I have no doubt about that.

When the motor is switched off, there is nothing at any fixed angle on one of the phases.

But if the motor is connected, there is PWM.

No, it was a bad contact.

Still, there is zero on one phase.
Here it is?
 
As I understand it, we need to look at what happens at the input and output of the driver of this phase.
 
the input and output of the driver of this phase.

I don't know which kind of half bridge driver is on your PCB, you have to look at the imprint and search for the datasheet, to see which pin is the high side and which pin is the low side input....
Example from Fortior:
Screenshot_20250822-210618~2.jpg
 
Last edited:
Back
Top