Problems with STM32 PMSM FOC SDK

[Dave_PT]

With the gear box mounted on the motor shaft. The shaft was always locked (I tried to force it by hand), but at these angles it is easier to force the rotation: 15º, 40º, 65º and 85º.

I'll test now from 270º to 359º.

PS: The motor does not spin ... but it gets hot! I just made a heater! 

[tatus1969]

one idea: have you added that if(RUN)... around your open loop code? it is absolutely essential.

[Dave_PT]

one idea: have you added that if(RUN)... around your open loop code? it is absolutely essential.

Yes. I think that's right.

[tatus1969]

ok. do you see the motor locking at different angles during alignment? you can make an ink mark at the output gear.

when you turn by hand at gearbox, does the motor try to rotate back into its previous position, or is it just hard to turn?

[Dave_PT]

ok. do you see the motor locking at different angles during alignment? you can make an ink mark at the output gear.

when you turn by hand at gearbox, does the motor try to rotate back into its previous position, or is it just hard to turn?

Yes. The motor shaft locks at different angles.
It is difficult to turn the shaft by hand, but at some angles it is more easier. The angles are the ones I wrote in the previous post.

[tatus1969]

just saw something that I must have overlooked a thousand times by now. You have commented out the original code (the PI controllers). Please put that in again, this code is vital during alignment!

[Dave_PT]

just saw something that I must have overlooked a thousand times by now. You have commented out the original code (the PI controllers). Please put that in again, this code is vital during alignment!

I always looked at this and thought the idea was to suppress the whole process.

I have uncomment this part of the code and already have movement, finally!

I'll do the process again!


Thank you.

[tatus1969]

I always looked at this and thought the idea was to suppress the whole process.

yes and no. Yes, during open-loop operation - but your code overrides it anyway. No, during alignment, that is the FOC current controller and it is needed there.

I have uncomment this part of the code and already have movement, finally!

[Dave_PT]

I can not use the index of my encoder because it is independent of the controller. The zero is done whenever the IC has power.
So I've been seeing if I notice torque changes while change the angles, but I do not notice any difference.

[Dave_PT]

In my last attempt I used a dynamometer to measure the force that the motor did in the various alignment angles.

All readings gave about 5Kg. So I could not find any angle where the motor would push harder.

[Dave_PT]

I already put everything in doubt.

I'm doing the tests using speed control. But did not make more sense do these tests in torque control?

[tatus1969]

I can not use the index of my encoder because it is independent of the controller. The zero is done whenever the IC has power.

That sounds bad... I am surprised because you said that it is a magnetic encoder. These ones know about the absoulte angular relationship... And how can they realize hall sensor emulation then...

So I've been seeing if I notice torque changes while change the angles, but I do not notice any difference.

Did you compare torque in both spinning directions? Only if that is equal then you know that alignment is correct.

[tatus1969]

I already put everything in doubt.

I'm doing the tests using speed control. But did not make more sense do these tests in torque control?

No, that's okay. As you stall the motor, the speed controller tells the torque controller "go for it" and directs full torque (nominal motor current from motor parameters).

[tatus1969]

In my last attempt I used a dynamometer to measure the force that the motor did in the various alignment angles.

All readings gave about 5Kg. So I could not find any angle where the motor would push harder.

Looks not too bad, is that a level that you expect? Is it the same in both spinning directions? Is it constant when allowing the motor to spin (giving rope slowly)? Or you you have that cogging effect again here?

[tatus1969]

If torque is the same in both spinning directions, it means that the alignment is working well, and can be considered validated. What I would do last here is measure (low pass filtered) phase voltages and currents in stepper mode. This would validate the entire power stage.

If all tests are positive, and same torque in both directions, this means that both motor feedback, controller and firmware are working well. If there is still massive cogging at low revs, then that is all caused by the motor construction. Unless you implement an anti-cogging strategy, there is nothing else to do that I can think of.

[Dave_PT]

I can not use the index of my encoder because it is independent of the controller. The zero is done whenever the IC has power.

That sounds bad... I am surprised because you said that it is a magnetic encoder. These ones know about the absoulte angular relationship... And how can they realize hall sensor emulation then...

I'm using an AS5047sensor.
The only way I would be to rotate the magnet until the index changes state ... but this is very difficult. The magnet is glued to the motor shaft.

So I've been seeing if I notice torque changes while change the angles, but I do not notice any difference.

Did you compare torque in both spinning directions? Only if that is equal then you know that alignment is correct.

I'll do it again tomorrow.
But I did as you said. Vary the angle from 270º (-90º) to + 90º in both directions in 5º steps.
After I fixed my error in the code, the motor started to run fine. But I did not notice any difference in torque, so I went to get a dynamometer to check.
With the dynamometer I just tested for one of the directions ... tomorrow I'm going to test all this again.

I already put everything in doubt.

I'm doing the tests using speed control. But did not make more sense do these tests in torque control?

No, that's okay. As you stall the motor, the speed controller tells the torque controller "go for it" and directs full torque (nominal motor current from motor parameters).

So I did not screw up  !

Looks not too bad, is that a level that you expect? Is it the same in both spinning directions? Is it constant when allowing the motor to spin (giving rope slowly)? Or you you have that cogging effect again here?

I expected more force... but as it is in open-loop it seems normal.
I'll test again tomorrow in the opposite direction.
In open-loop I do not have significant congging. I had the rope tied and so the motor runs until it's locked. I did not try to release the rope slowly.

If torque is the same in both spinning directions, it means that the alignment is working well, and can be considered validated. What I would do last here is measure (low pass filtered) phase voltages and currents in stepper mode. This would validate the entire power stage.

If all tests are positive, and same torque in both directions, this means that both motor feedback, controller and firmware are working well. If there is still massive cogging at low revs, then that is all caused by the motor construction. Unless you implement an anti-cogging strategy, there is nothing else to do that I can think of.

I'm going try to prove all this part tomorrow.

What seems to me so far is that the alignment angle does not make any difference. I varied a few angles and re-tested the full code in low revs and had the same cogging as before.
Everything points to the construction of these motors.
If this does not work, it seems the only solution is to run in "stepper mode" at low revs. In this case I have to create a compromise between maximum torque and heating. For example, in low revs the motor runs but with reduced torque to avoid heating.

[tatus1969]

I'm using an AS5047sensor.
The only way I would be to rotate the magnet until the index changes state ... but this is very difficult. The magnet is glued to the motor shaft.

That sensor should be able to deliver an index signal that is tied to an absolute orientation. They write something about beavior after reset, but I read this as "temporary state" while the chip is booting. And they write the same for hall sensor emulation outputs. These *must* be absolutely oriented anyway.

Of course you don't know the magnet to shaft alignment after FOC power-on, and it even may differ from motor to motor (but I don't think so, motor manufacturers know about the need for fixed sensor orientation). The standard procedure is to measure that offset once during production, and to store it somewhere (e.g. the micro's flash). What the startup procedure then needs to do once per startup, is to forcedly turn the motor (stepper mode) and wait until the index mark passes by. I have code for this, but this assumes that the index channel is connected to an interrupt capable pin. The offset is hardcoded in my example.

I see that the sensor has more options. You could also use the PWM feature, this is only one signal and it is absolute. I would personally go for that one.

I expected more force... but as it is in open-loop it seems normal.

What is the wheel radius? I assume 0.2m here. Then your gearbox output torque is 50N * 0.2m = 10Nm. Assuming an 80% gearbox efficiency, the motor shaft torque is then 10Nm / 29 / 0.8 = 0.43Nm. The motor seems to be rated at 3000 rpm. Output power at this speed would then be 3000/60*2*PI*0.43Nm = 135W. Does this match the rated output power?

In open-loop I do not have significant congging.

That is interesting. Maybe your strategy should be always using open-loop mode? There is one disadvantage to this: you lose your ability to control torque, your only protection then is the hardware current limiter. And you lose the main feature of FOC that it maintains perfect magnetic alignment in the motor. You will experience torque degradation at higher revs.

To do this, you would need to take the output of the speed controller (variable Iqdref) and directly use it as output voltage, like this:

Vqd = Iqdref;

Your Kp / Ki values need to be tuned again as well.

[Dave_PT]

In open-loop I do not have significant congging.

That is interesting. Maybe your strategy should be always using open-loop mode? There is one disadvantage to this: you lose your ability to control torque, your only protection then is the hardware current limiter. And you lose the main feature of FOC that it maintains perfect magnetic alignment in the motor. You will experience torque degradation at higher revs.

To do this, you would need to take the output of the speed controller (variable Iqdref) and directly use it as output voltage, like this:

Vqd = Iqdref;

Your Kp / Ki values need to be tuned again as well.

This almost does the job.

I can control speeds around 100RPM ...

[bayetan]

Hello tatus1969,

I was hoping you could point me in the right direction... I'm using STM32F446 and IHM08M1 w/ FOC to control a brush-less motor.  I used the provided SDK 4.3 and IAR 8.11 to generate the code but is unable to communicate with the controller using the ST Motor Control Workbench.  I used a bus pirate to inspect the UART and got the following command transmitted from the PC (0600 0602 0166 6902 0170 7306 0006 0201 8285) the following response from the controller (F020 3433 3053 544D 3332 2046 4F43 2053 444B 0000 0000 0000 0000 0000 0000 0000 0000 FEF0 0101 F2F0 045F C9FC 314C F020 3433 3053 544D 3332 2046 4F43 2053 444B 0000 0000 0000 0000 0000 0000 0000 0000 FEF0 0100 F1) all in HEX.

The ST WB is unable to connect and I can't seem to make sense of the HEX command and response.  They don't really match the UM1052 Serial communication class overview provided by ST.  If you could help me decipher this command/response sequence, i would really appreciate it.  Specifically, does the 0x06 command (Get board Info) require any parameter.  How long is the commands and how is the CRC determined, i.e., CRC-8?

Thanks,
bayetan

[tatus1969]

The ST WB is unable to connect and I can't seem to make sense of the HEX command and response.

That should work out of the box. I have never investigated the protocol that they use. These are the things that I would investigate:
- check the microcontroller system clock frequency with an oscilloscope. For example, toggle a pin in an interrupt service routine and check against your expectation.
- check for correct baud rate setup in the microcontroller. Repeatedly send some known characters, and check with scope.

I haven't used the Nucleo boards so far, do you use an external USB/UART interface to talk with the controller, or is that on board? If the first, does the Nucelo have RS232 level shifters or does it expect 3.3V TTL signals for serial comms?

[bayetan]

Sorry for the late reply.  Family, work and life leave little time to spend on my little project.

But you're right about the system clock frequency.  I set PC10 to toggle on SysTick, which set to trigger at 500 uS interval so I should expect 1 mS period but ended up getting ~3.125 mS.  Is there a better ISR handle that I can toggle the pin on.  I tried several other ISR handler, i.e., TIMx_UP_M1_IRQHandler but that was not active.  Does that become only active after the motor is commanded on?

Let me work on getting uC to send known message to PC over UART.  Pseudo object C in very new to me.

Thanks,
Ben

[tatus1969]

Is there a better ISR handle that I can toggle the pin on

The SysTick ISR is perfect for this purpuse

[bayetan]

I was trying to figure out why my 1 mS Systick was being generated every ~3.125mS so I started looking into SetSysClock.  As I was following the execution, I noticed that HSEStatus was set to 0x00 after a check to see that HSE was ready.  However, in the next statement, (if (HSEStatus == (uint32_t) 0x01) was evaluated to be true and the code proceed to configure HSE.  This is all very confusing because I don't have a HSE on the Nucelo-F446RE board.  I tried following the Disassembly as well but ended up being a big headache.

Would you happen to know how I can setup the Peripherals register view on IAR?  Eclipse had a nice one with CMSIS Pack but when I CMSIS-Pack Installer by double-clicked on "5.1.1 CMSIS", it went through a lengthy download but I still don't see any additional peripherals register views.

Thanks,
Ben

[bayetan]

I originally started out with a Nucelo-F303RE board but switch to Nucleo-F446RE after my complied code  exceed the 32k limit on IAR free version.  I must have done something wrong in the settings, but when I went back to it (F303), with Options:C/C++ Compiler/Optimization set to High/Size, it compiled within the 32k limit.  Using this, I was able to capture some UART data at baud rate 115,000.

1) UART Tx/Rx for Connect
2) UART Tx/Rx for StartMotor
3) UART Tx/Rx for StopMotor


Some of the pixel got chopped off in the picture so they look like "FC0CFC" but it is "F000F0".  ST Motor Control Workbench connects fine now so I'm very happy but still confused that CRC byte does not seem to match with any standard ones as far as  I can tell.  I guess I can took at the code to see how uC calculated it.

[bayetan]

Actually, it was't the optimization that effected the code size but the options enabled in the Motor Control/Drive parameters.  By disabling all the ones that weren't absolutely necessary, I was able to get the code size below 32k and get Debug DAC to work, kinda.  While spinning the motor at 600 RPM, I was able to capture on the scope of the "observed electric angle PLL".  Obviously, its corrupted with some PWM signal but the 10.4 Hz check out real nice. Woo-hoo! Next spend some time with the schematic and all the solder-bridges to figure out what I need to do to get a clean signal.  The second DAC signal, also configured to output "observed electric angle PLL" was flat-lined so need to look into that some more too.