Usage of the motor lib v 3.0 -- some questions

christianrichter9 · ‎2012-05-29

Posted on May 29, 2012 at 16:58

Hello together,

we are currently building up a prototype with the STM3210B-Eval board in combination with the STEVAL-IHM031V1 board. The correspondig motor is the QBL4208-61-04-13:

http://www.trinamic.com/tmc/media/Downloads/QMot_motors/QBL4208/QBL4208_ShortSpec.pdf

There are two versions of the ST motor control library: One, which is for free and downloadable (STM32 PMSM FOC Firmware Library v3.0 web distribution). The other one contains all source files of the motor library, and we got it from ST by subscribing a NDA: STM32 PMSM FOC Firmware Library v3.0.1 By using the non-NDA version of the motor control library, the LCD display on the STM3210B-Eval board wasn't working, despite it was enabled in the SW. But on the other hand, it was working with the NDA SW version of the motor control library. We found out, that the LCD code and entry address differs in both versions. In the file /Project/UITask.c (non-NDA motor library version): #define VECT_TABLE_BASE 0x08013800 and has to be changed to (motor library NDA version): #define VECT_TABLE_BASE 0x08010000 Are you aware about this? The used SW toolchain is: IAR Workbench 6.30.4.3295, ST Motor Control Workbench Debugger: ST Link The other thing is, that the motor isn't rotating. If overcurrent protection is enabled, it ''moves'' for about 1/10 s, and then stops with a overcurrent error. By disabling the overcurrent protection, it rotates longer, sometimes several seconds, and then stops with a revup fail error. Can you give us a hint, how to debug this error condition? We have already spent a lot of time for finding the root cause of this error condition. Thank you in advance and best regards, Chris

Gigi · ‎2012-05-29

Posted on May 29, 2012 at 17:18

You are right the VECT_TABLE_BASE of the LCD project for the STM32F103B project of 3.0 differs from the one for the 3.0.1.

For this reason is mandatory to use the proper LCD project.

LCD project 3.0 with STM32 FOC lib 3.0

LCD project 3.0.1 with STM32 FOC lib 3.0.1

Otherwise LCD doesn't works even if you enable it in the firmware.

Regarding the second point it is difficult to say which can be the root cause.

Of course disabling the over current protection you can't solve the problem. Is like you where informed that someting is goning wrong and you go ahead with a pillow on your hears.

The first think I will do in this condition is reduce the nominal current set in the workbech trying to start up the motor even with lower available torque. Of course enabling the overcurrent protection. And then when the motor runs I will try to increase the nominal current monitoring the emergency input of the microcontroller and the motor phase current to see if the over current is real and is not a noise on the brake input for instance. If it is real I will check the current level value that triggers the protection to see if the threshold is the one expected and so on...

christianrichter9 · ‎2012-06-06

Posted on June 06, 2012 at 10:38

Hello Gigi,

thank you for your reply. I'm definitively sure that I didn't mix

LCD project version X with STM32 FOC lib version Y.

Regarding the hints you gave me to the second point: Will try it, and give you feedback.

Thanks again,

Chris

christianrichter9 · ‎2012-06-11

Posted on June 11, 2012 at 15:25

Hi,

so, the result is:

The emergency input is definitively set. Also an overcurrent can be measured.

>If it is real I will check the current level value that triggers the protection to see if the threshold >is the one expected and so on...

In the header files, I didn't find a treshold value for the current. Which parameter do you mean? Or did I misunderstand something?

I attached the header files, and I have the hope, that you maybe see an error in a headerfile on a glance (

The correspondig motor is the QBL4208-61-04-13:

http://www.trinamic.com/tmc/media/Downloads/QMot_motors/QBL4208/QBL4208_ShortSpec.pdf

)

It seems, that the motor prints the state ''Fault ack'' a short delay before signaling ''Overcurrent'', but I don't know if this is important.

Thank you and best regards,

Chris

christianrichter9 · ‎2012-06-12

Posted on June 12, 2012 at 14:36

Hi,

also, I have these additional information:

After starting the motor, the current rises up to 2... A.

I'm sure that these parameters are correct, I measured them:

#define HALL_SENSORS_PLACEMENT DEGREES_120

#define HALL_PHASE_SHIFT 270 // equal to -90

I have the impression, that the motor drives a bit backward (for 1/10sec) before

driving forward. So I think, that the interplay of the electro-magnets isn't ok regarding the time.

I try to describe it in simple words, hope it is understandable:

Maybe two electro-magnets trying to drive one permanent magnet in different directions.

So one electro-magnet has to work against the force of the other. To keep the expected speed,

the overall-current has to be increased.

Do you have an assumption why this happens?

Thank you and best regards,

Chris

Gigi · ‎2012-06-13

Posted on June 13, 2012 at 09:09

Hi Chris

I didn't find a treshold value for the current. Which parameter do you mean?

In the motor control WB there is this value under Power Stage->Over Current Protection block. This i computed starting from the comparator threshold and over current network gain. The assumption is that the curent is converted into a voltage by shunt resistor and eventually OP amps and then is compared with a fixed voltage threshold before to signaling it to the microcontroller. This depend on the overcurrent protection hardware of the board. My suggestion is to understand how it works and verify that it works properly before to run the motor. Usually the ST eval board with this functionality is already tested but s**t can happen.

Then you nedd to set the nominal current of the motor (Motor -> Electrical parameters) below the over current threshold. I suggest to stay at least 10% below the overcurrent threshold. More over as I suggest before you can start with a very low level of the nominal current (of course if the motor is not loaded) just to avoid the overcurrent and to see if all remainig part is working (For instance the current regulation).

I'm sure that these parameters are correct, I measured them:

#define HALL_SENSORS_PLACEMENT DEGREES_120

#define HALL_PHASE_SHIFT 270 // equal to -90

...

By disabling the overcurrent protection, it rotates longer, sometimes several seconds, and then stops with a revup fail error.

Your informations is not clear. The revup phase (and so the revup fail error) usaully is present just in sensorless control so the above two sentence seems to be in contradition.

I have take a look at your attachment.

First I see that in the drive management in Speed/Position Feedabck Management is selected the Sensorless control. So in this case the parameter of the sensor (even if it is present is not take in account for the control).

In the motor electrical parmaeter I see that you have set 3.5A (first of all I suggest to try to set the same calue also for the demagnetizing current). Moreove I see that the startup current is set to 0.6->0.7 so it seem strange that you measure 2A... You have check that the

STEVAL-IHM031V1

is configured for the single shunt like you have set in the Power Board -> Current sensing.

Gigi

christianrichter9 · ‎2012-06-21

Posted on June 21, 2012 at 09:06

Hi Gigi,

first of all, thank you again for your information.

>First I see that in the drive management in Speed/Position Feedabck Management >is selected the Sensorless control. So in this case the parameter of the sensor

>(even if it is present is not take in account for the control).

You are right, and I don’t know why I ignored such an important thing.

But after changing it from Sensorless->Hall, the motor goes immediately, after pressing “Start�?, into the state “Fault ack�? and “Speed Feedback�?.

The curious thing is that I can see (in my opinion) valid voltage curves for the 3 phases on the oscilloscope; the 3 curves are identical, e.g. the peaks are at the same time and so on.

But the motor isn’t moving at all.

Then I used a low level implementation, which sets the 6 PWMs (Ulow – Whigh) in the needed way without regarding the hall signals, and the motor is moving, so it is not defect.

The hall sensor signal is a rectangle signal, but I would suppose that is always high or low, because the rotor position isn’t changed.

Best regards,

Chris

christianrichter9 · ‎2012-06-28

Posted on June 28, 2012 at 11:06

Solved this issue.

The solution was to swap two phases.

But now, I have a new question:

As I found out, it is not possible to change the rotor speed.

It is always about 3500 rpm, also, if I start ST_ExecSpeedRamp with a speed parameter

of 100 rpm.

Do you have an idea why this happens?

Best regards,

Chris

Laurent Ca... · ‎2021-06-28

The question has been moved from the "Motor Control Hardware" section to the "STM32 Motor Control" section (the question is about the STM32 MC SDK).

Best regards