+/- 1 RPM Resolution using B-G431B-ESC1 Discovery Kit

[GHave.1]

I have this kit, am using the MCSDK under STM32CubeIDE, and everything seems to be functioning fairly well.

I'm still getting the occasional fail to start issue, but what I'm really trying to do is to be able to specify motor speed +/- 1 RPM, and be able to hold that speed to +/- 0.5 RPM.

As far as speed accuracy, I'm getting better results with a pretty hefty flywheel, and I have the Observer+PLL Variance threshold parameter set to 5% in the Workbench app, but I still have more variance in speed than I'd like. What are the best parameters to tweak / signals / variables to monitor to hold speed better? Would using Hall Effect sensors as an auxilliary sensor help with speed accuracy?

As far as being able to specify the desired speed, I'm defining SPEED_UNIT to be _001HZ, and with the hFinalSpeed parameter to MCI_ExecSpeedRamp being a 16 bit integer, I just don't seem to be able to get 1 RPM granularity at RPM < 1000. Also, the docs / comments do not seem clear that using _001HZ will help with speed granularity, and the math doesn't seem to make a difference in the end, I'm still going to end up with kind of a step function with a granularity > 1 with regards to RPM.

What would really be cool is some sort of "fine adjust", but i don't see anything like that in the API, and there doesn't seem to be any stated capabilities or limitations that would help answer my questions. I was also wondering if there wasn't some base PLL that I could twiddle to tweak things where I need them.

I've watched a bunch of the videos ST has posted on Youtube, but none of them seem to answer my questions, or if they did, I didn't pick up on it.

Does anyone have any pointers on how / if the HW/SDK is capable of such things?

[cedric H]

Hello @GHave.1​ ,

> What are the best parameters to tweak / signals / variables to monitor to hold speed better? 

I would say that tuning you PID speed could help, but it really depends on your application. If there is no external event the system has to cope with, perhaps lowering the proportional value and increasing a bit the integrator value could help, but it will not do the job if you want to stick sharply to a moving target.

+-0.5 RPM is a very strong requirement. Perhaps it could be worth to increase also the frequency of the regulation loop. But a more pragmatic approach will be to spin faster and use a mechanical gear box.

>Would using Hall Effect sensors as an auxiliary sensor help with speed accuracy?

No. Auxiliary speed sensor output are today not used by he firmware. We plan to add an API to switch from main sensor to auxiliary sensor soon to allow the application to use the best of both world depending on the use case. But for the moment auxiliary speed sensor is mainly used to tune the HALL sensor placement angle.

Setting SPEED_UNIT to 001 Hz is not very suitable with our 16 bits architecture. A not so bad tradeoff would be to try to set it to U_RPM. You have to be careful with your maximum electrical speed to be sure to not overflow our 16 bits architecture.

Regards

Cedric

[BTrem.1]

I have a similar requirement where I'm running a small BLDC polygon mirror at ~1800RPM, but the actual frequency is dependent on a MEMS scanner frequency so the variation will be very slow but different polygon to polygon. At 1800RPM the rotations is 30.00Hz or in SPEED_UNIT 001Hz this is 3000. I don't see the limitation of 16 bits. I wish there was a 00025Hz SPEED_UNIT ;)

I'm under the impression 001Hz (0.01Hz) is the smallest resolution available in the code.

Since there is not much disturbance in my system I do choose low Kp to minimize the response due to Observer noise, also I maximized my inertia the most I could allow.

Bottom line I wish there was about a 4x improvement in speed resolution.