HSO firmware configuration

[RTirapegui]

Hi, I have been working with the HSO motor control algorithm using Motor Workbench 6.2.0. I was able to successfully configure the firmware for a custom PCB, and it works correctly. The motor, which is a PMSM with 2 pole pairs, starts and runs without any issues up to 30,000 RPM using the HSO's speed mode.

However, as I increase the bearing friction to test the maximum load at which the motor can still start, I notice that no matter how much I increase the application's maximum current, it is not applied right from the beginning by the algorithm in situations where the motor is unable to mechanically move the shaft.

Specifically, I observe that from the start and for about 700ms, the algorithm applies a current equivalent to 70% of the maximum application current, and even though the shaft doesn’t move, the algorithm’s estimated speed increases linearly up to 3,000 RPM.

In this regard, after reviewing the configuration parameters in the firmware, I am wondering how the following are calculated:

SPEED_POLE_RPS doesn’t seem to change as I edit the motor parameters in Motor Workbench. Which parameters is it based on?

Regarding CrossOver_Hz, the comment indicates that it depends on the motor used, but I don’t see it change even when I modify motor settings in Motor Workbench.

The fact that the estimated speed from the HSO increases while the shaft remains stationary could be a sign that the algorithm’s observer is not properly tuned. In that case, how would it be necessary to adjust the other parameters marked in the previous image?

Thanks

[Gael A]

Hello RTirapegui,

Before diving into the details, I would like to know if you are using the MotorPilot, and what start-up method you are using : is it the RsDC or the PolPulse ?
Also, having a look at the currents at start-up would be nice.

[propu]

Hi Gael A:

[VERSION]: Version of MCSDK 6.3.1
[TOOL]: MC workbench , ST MOTOR Pilot

I encountered the same problem mentioned above. After modifying the motor parameters using MC Workbench and generating new code, when I compared the new code with the old one, I found that the parameter configuration for the structure named Hso_params_M1 does not change according to the motor configuration parameters. However, the comments within this structure state that this parameter needs to be adjusted based on the motor. Could you please explain in general how this adjustment should be made?

Another issue I am facing is that I am currently using the STM32G431 with the HSO's ADC sampling configuration to design a custom PCB. However, when running the motor (with a rated speed of 120,000 rpm and very low resistance and inductance values), I always encounter a startup issue. When using ST MOTOR Pilot, the current to the motor can be observed increasing with an oscilloscope. However, the motor rotor does not rotate, and the current does not follow a sine wave motion but is instead locked at a fixed angle. I have spent a lot of time troubleshooting but am unsure how to resolve this issue.

Hso_params_M1 

you

After reading the HSO start-up document, I still don't have any ideas on what changes to make. I hope to get your help. Thank 

[Gael A]

Hello propu,

CrossOver_Hz is a parameter that does not need to be changed by the user. Only the maximum and minimum values are useful to tune, but the default ones are already sufficient for the large majority of use cases. It is true that the code documentation is confusing, thank you for your feedback.

Concerning your start-up problem, I would like to know which start-up method you are using, is it RsDC or PolPulse ?
Also, have you profiled your motor ? Did it go well ? Are the values correct, or at least coherent ?

[propu]

Hi Geal A,

I am using the PolPulse start method. I may not fully understand the configuration of PolPulse, but I know it is used to obtain the initial angle information of the PMSM. I am not sure if there is a way to verify whether my PolPulse function configuration is correct. If every time I use the PolPulse function to start the motor, and the motor does not experience reversal during startup, can this phenomenon prove that the PolPulse configuration is correct? Additionally, I am using an SPMSM motor, and I am not sure whether the PolPulse function works for SPMSM as well.

Let me first introduce the SPMSM motor I am using. It uses a single pole pair, and its speed is quite high, with a maximum speed of 140,000 rpm. This means the electrical frequency is 140,000 / 60 = 2333 Hz. The rated voltage is 270 Vdc, meaning its back EMF is quite low during startup. The line resistance is 0.2 ohms, and the line inductance is 0.23 mH. The motor is a power unit for an air compressor, using a gas floating bearing. At low speeds, there is a significant friction coefficient. When the speed rises to 40,000 rpm, or 666 Hz, the pneumatic bearing will operate normally, and the friction coefficient will become very small.

1. During profiling, I understand that the internal logic is similar to the OpenLoopCurrent mode. It cannot bring the motor to speeds above 100 Hz. Additionally, when the RS and LS learning is complete, the learned resistance values are as follows. In my view, since the values of the motor’s parameters are relatively small, deviations are normal. I would like to know if the frequency during profiling can exceed 100 Hz? How should I modify it?

The following text is from the HSO_STARTUP_GUIDE."

1. Assume that my PolPulse configuration might have issues, leading to inaccurate recognition of the initial position. Is there a configuration similar to the OpenLoopCurrent mode that operates at low speed and switches to the CloseLoopSpeed mode at higher speeds? Or is this something that needs to be configured in the user code? Since the back EMF coefficient of the motor is very small, I'm not sure how the HSO algorithm ensures reliable startup. Therefore, I would like to switch to a traditional startup method.

2. In this project, there is also a requirement for OTF (On-the-Fly) switching. However, when I use the Pilot software to switch modes, I found that it is not possible to directly switch from the observing mode to CloseLoopSpeed mode. Can I write code to handle the switching in the intermediate frequency task within the code? Why can't Pilot software directly switch between these modes? Is there anything specific I should be aware of?

3. In the MC Workbench 6.3.2, the "Regulator execution time" prompt suggests that it should be greater than 100us. I don't quite understand this. I have tested that the high-frequency task time is about 30us, which means the PWM frequency should be able to reach 33kHz, performing one algorithm calculation per PWM cycle. However, if the regulator execution time needs to be greater than 100us, this implies that the algorithm calculation frequency should be less than 10,000Hz. Would this have a significant impact on the bandwidth of the current loop? I would like to ask, what is the maximum frequency at which the HSO algorithm can reliably operate in practice?

   thanks!

[Gael A]

Hello propu,

The speed at which the Profiler makes the motor run is only relevant for Flux estimation, not Rs nor Ls.

The other available start-up method is the RsDC, which performs an alignment of the motor. This means you need a strong enough current to beat initial friction and load. The HSO's convergence time is quick enough for an Open Loop not to be needed and directly start in Closed Loop. The only required info is the angle, which can be attained by two different ways : Alignment (RsDC) or PolPulse. The PolPulse tuning is explained in details in the HSO Startup guide that you already mentioned. If there is something in particular that you didn't understand, please let me know.

OTF is currently not implemented via MotorPilot, this is a current limitation. You can do it quite easily in your application, unless you are using a STDRIVE101.

The WorkBench value is purely indicative, you can try with lower periods and see how it goes. We have no definite known speed at which the HSO is not able to keep up anymore.

Feel free to keep us informed with your work !