Stop command and startup with Hall sensors

[pzt]

[VERSION]: MCSDK 6.1.2 and 6.2.0.

[TOOL]: MC Workbench, MC Pilot, MC Firmware.

[DETAILS]:
I developed a control/power board, a custom Hall sensors board and a motor (which will interface a reduction drive) for AGV application. I was able to integrate very well with both versions of the SDK (6.1.2 and 6.2.0). As a start point, it is perfect if you understand how to use it, as it reduces development time of well-known algorithms. I was able to test boards + motor without any problems, at full load, all protections are working, and I checked that current measurement is clean (after adjust the parameters) - not in no-load situation, but this is not a problem as the motor will never run in this situation and noise is expected given measurement range. Given the complexity and requirements of the SDK, the entire application was developed in the while(1) loop, without interruptions, and it runs every 25ms. The problems I am facing relate to 2 situations, both with or without adding the user application (so this is not interfering):
1. I noticed that the stop command has a longer delay in version 6.2.0 compared to version 6.1.2 (which is almost instantaneous). Is it related to USART treatment or does it concern how the control handles the command? As I was developing the final application, this caught my attention;
2. In both versions I noticed that the control struggles to startup the motor. I understand that an absolute encoder would be better in this case, as it is necessary to know the motor angle, but the Hall works very well for measuring speed as well as reducing costs. Is there a way to adjust startup parameters with just Hall sensors as speed measurement? Or could I add a sensor-less control to enable rev-up (and that would add an "alignment" procedure)?

[EXPECTED BEHAVIOR]:
1. The stop command should be (almost?) instantaneous, for safety purposes;
2. Startup with Hall sensors should be smoother.

[HOW TO REPRODUCE]:
To replicate the project, I have attached the necessary files. Convert them to ".json" (file type is not supported in the community) and add to "C:\Users\USER_NAME\.st_workbench\hardware". Create a project for 1 motor, FOC algorithm, modular hardware. Select "custom_motor", "custom_power" and "custom_control" in the motors, power board and control board windows, respectively. Main information:
1. Custom motor (preliminary, stator and rotor still under test + adjustment):
- Min. torque = 1.2 N.m;
- Pole pairs = 4;
- Nominal current = 25A (current peak of 36A);
- Nominal DC voltage = 24V;
- Rs = 30mR;
- Ls = 60uH;
- I-PMSM magnetic structure;
- Ld/Lq = 0.77;
- BEmf constant = 4.28;
- Inertia / friction = I have already measured but it doesn't seem to change the control, I have even tried other values but nothing... So I kept the default values;
- Maximum rated speed = 3500 RPM;
- Hall sensor displacement = 120°;
- Hall electrical angle placement = 129°;
2. MCU + SDK configuration:
- MCU = STM32F302R8;
- Control type = FOC;
- Primary speed sensor = Hall;
- No auxiliar speed sensor;
- Current sensing topology = 1 shunt with phase shift;
- Shunt resistor = 5mR;
- T-rise = 1500ns;
- T-noise = 500ns;
- Readable current = +- 63,5A;
- Current sampling time = 271ns (19,5 ADC clocks - max. modulation = 100%);
- Over current protection enabled, with 35A threshold;
- Vbus and temperature sensing enabled;
- Over voltage, under voltage and over temperature enabled;
- PWM frequency = 16kHz;
- Software dead-time = 700ns;
- FOC rate = 2 cycles (125us);
- Feed forward and MTPA enabled;
- Kp and Ki from speed regulator auto calculated;
- Flux weakening regulator disabled;
- Motor control protocol enabled over USART with baudrate of 115200, data log enabled;
- MCU load measurement enabled (normally at 25%).

Thanks in advance!

[SRedd.5]

---

@pzt wrote:

[EXPECTED BEHAVIOR]:
1. The stop command should be (almost?) instantaneous, for safety purposes;
2. Startup with Hall sensors should be smoother.

1. It is more related to USART communication according to me, but if the motor is already running at high speed if you provide STOP command it will not immediately stop, if you want to immediately stop the motor provide a negative Iq in torque command.

2. I suspect that your #define HALL_PHASE_SHIFT is not properly set adjust the value and verify any improvement happens.

[pzt]

Thanks for the quick response!

1. I have not tested MC API commands yet because I prefer to adjust the control first, but my concerns are related to the final application as I will implement a CAN bus. I will investigate the MC API in more detail when the time comes.

2. At first I thought this too, but I follewed "MC Workbench" > "User Manual" > "Hall sensor feedback processing" > "Setting up the system when using Hall-effect sensors", and the delay is 7,50433Hz * 48ms * 360° = 129,67° (see attached image). I added an auxiliary sensor (Observer + Cordic) and I was able to confirm that while motor is running the main and auxiliary sensors estimate the same angle. But during the starting time the estimate is really different from each other (probably due to current measurement).

[pzt · Accepted solution]

1. The motor stops in a reasonable time using the MC API stop command; In TSK_MediumFrequencyTaskM1 (called periodically called on systick) in the RUN state it calls TSK_MF_StopProcessing() if DirectCommand is MCI_STOP, which in turn stops the PWM generation. In the worst case, it takes 500us + a few of cycles to get into systick interrupt + a few cycles to get to that.
2. Changing the speed sensor to sensorless (Observer + PLL or Observer + Cordic) as main sensor and Hall as auxiliary enables the start-up profile, which can be easily adjusted.