Author Topic: Problems with STM32 PMSM FOC SDK  (Read 116158 times)

0 Members and 1 Guest are viewing this topic.

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Problems with STM32 PMSM FOC SDK
« on: November 15, 2016, 07:00:28 pm »
I do not know if this is the right place. Be gentle with me.

I'm having a lot of problems using this SDK:
http://www.st.com/en/embedded-software/stsw-stm32100.html

I already configured all the parameters and generated the configuration header files.
All done according to the documentation.

The problem starts when I try to use the IAR (or KEIL) to get the application up and running.
The examples are not clear enough for me.

I have no compilation errors nor problems in programming the MCU.

So my difficulty lies in building basic instructions with the SDK.

I do not understand how I can not get any assistance from ST  :( :(.

Has anyone here worked with this SDK, who can help me?

I'm using this board, slightly modified, for my application.
http://www.st.com/en/evaluation-tools/steval-ihm040v1.html


Attached is the configurator file.
http://s000.tinyupload.com/index.php?file_id=62181905025753098078


I'm freaking out with this ....


Thank you!!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #1 on: November 15, 2016, 07:53:43 pm »
I am using it with success, but I remember getting off was quite painful. Maybe you can upload your complete IAR project, then I can have a look.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #2 on: November 15, 2016, 08:38:36 pm »
Oh, thank God (God Goku, of course  ;D).

I'm trying to run the "ramp" example.

But after doing "start motor", I have no PWM signals.

At this point, I came home and I have nothing installed on my PC.

Could you help me out tomorrow?


You can not imagine how relieved I am just for communicating with someone who is actually using the SDK !!!   :-+


My project takes some delay because I've been using Renesas for motor control, but now I have to add an encoder.

Because the project is changing, I decided to start using ST for the quality of its configuration tools.


So I'll buy you a beer for your help!  ;)
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #3 on: November 15, 2016, 08:44:44 pm »
no problem :)
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT, richard_t

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #4 on: November 15, 2016, 09:11:41 pm »
Tomorrow at 10 a.m. (Germany time) I will write something here.

Thank you.


I owe you a Franziskaner :)
« Last Edit: November 15, 2016, 09:23:29 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #5 on: November 16, 2016, 07:13:17 am »
i can check this evening. just throw over that beer, but make it a Kilkenny 8) I don't drink that Bavarian stuff :o some ideas:
- ST maintains a forum dedicated to this SDK, have you been there? that was of great help for me
- have you measured your motor parameters, most important L, R, backemf constant. the sensorless rotor angle estimators really need good values
- have you played with the RS232 based remote control that is built into the configuration tool? it allows inspecting live values. it also allows routing them to the DACs of the micro, so you can make them visible on a scope

EDIT: just checked the reference design that you linked. Unless ST has added some features that I am not aware of, then the ST FOC library cannot run on that board. One of the essential features is phase current measurement, and that one http://www.st.com/en/evaluation-tools/steval-ihm040v1.html is missing that. Have you added phase current measurement in your design?

EDIT2: cannot download your configuration file, maybe just add as attachment to your post.
« Last Edit: November 16, 2016, 08:47:37 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #6 on: November 16, 2016, 09:24:04 am »
My knowledge about German beers is very limited  :-DD.

- ST maintains a forum dedicated to this SDK, have you been there? that was of great help for me
The only ST forum I know is this: https://my.st.com/public/STe2ecommunities/motordriver_ics/Lists/Motor%20Control%20Firmware%20and%20Software/AllItems.aspx
But is not dedicated to this SDK.
Can you give me the forum link?


- have you measured your motor parameters, most important L, R, backemf constant. the sensorless rotor angle estimators really need good values
Yes. I measured these parameters with the Renesas board.


- have you played with the RS232 based remote control that is built into the configuration tool? it allows inspecting live values. it also allows routing them to the DACs of the micro, so you can make them visible on a scope
This EVB was poorly chosen.
I have access to the DAC output but I have not yet turned on the scope there. I'll do it next ...


EDIT: just checked the reference design that you linked. Unless ST has added some features that I am not aware of, then the ST FOC library cannot run on that board. One of the essential features is phase current measurement, and that one http://www.st.com/en/evaluation-tools/steval-ihm040v1.html is missing that. Have you added phase current measurement in your design?
I made the changes on this board (so I can use a 24V motor).
But this board appears in the configuration tool.



EDIT2: cannot download your configuration file, maybe just add as attachment to your post.
In the forum I can not add the file ...
Try it here: http://www.filehosting.org/file/details/618819/drive_alte.rar
Or here: http://www.yourfilelink.com/get.php?fid=1273789

Thx
« Last Edit: November 16, 2016, 09:27:43 am by Dave_PT »
 


Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #8 on: November 16, 2016, 10:48:49 am »
I already bought the KIT.

It must arrive tomorrow ...

But making FOC with 1 shunt resistor is possible ....
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #9 on: November 16, 2016, 11:45:16 am »
I have already changed the DAC settings for several variables, but I have the feeling that something is not activating the functions ...

Changes on main template (after generating all config files to SystemDriveParams folder, open "STM32F10x_Workspace.eww"):
* line78 - #define EXAMPLE_RAMP




In debug mode I can make the MCI StartMotor with success... but nothing happens (no PWM, no rotation, no variation on DAC channels, ...)




I'm pretty sure that I'm forgetting to initialize something.
« Last Edit: November 16, 2016, 11:47:40 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #10 on: November 16, 2016, 01:00:27 pm »
My knowledge about German beers is very limited  :-DD.
Same for my Portugesian beer knowledge  ;)

- ST maintains a forum dedicated to this SDK, have you been there? that was of great help for me
The only ST forum I know is this: https://my.st.com/public/STe2ecommunities/motordriver_ics/Lists/Motor%20Control%20Firmware%20and%20Software/AllItems.aspx
But is not dedicated to this SDK.
Can you give me the forum link?
That's the one I meant. The FOC library is one of the main topics there. Gigi from ST is usually very helpful and responsive and he had helped me a lot in the past.

EDIT: just checked the reference design that you linked. Unless ST has added some features that I am not aware of, then the ST FOC library cannot run on that board. One of the essential features is phase current measurement, and that one http://www.st.com/en/evaluation-tools/steval-ihm040v1.html is missing that. Have you added phase current measurement in your design?
I made the changes on this board (so I can use a 24V motor).
But this board appears in the configuration tool.

I see, they do support single-resistor current sensing. Maybe I just missed that because I am using hall based current sensing anyway (currents up to 40A). I am happy to see that they now also have a motor profiler application. You could double check your motor params with that.

Some more ideas:
- have you changed R10=R12=47k?
- your overcurrent settings do not seem to match the circuit. Rsense = 0.25 Ohms, comparator trip point = 0.25V, according to 1.0A. Your settings differ (should not prevent startup though)
- the board seems to use the microcontroller's internal RC oscillator for clocking, but that is not available from the configuration. My latest project is doing it the same way, but I have modified the startup code. Don't know if there's an automatic fallback if there is no crystal.
- there's some timer magic with the BKIN signal (PB12 on your board), don't remember the exact details. That can block timer operation if I am correct.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #11 on: November 16, 2016, 02:56:48 pm »
Same for my Portugesian beer knowledge  ;)
When this is over I'll send you the best Portuguese beer ;).


That's the one I meant. The FOC library is one of the main topics there. Gigi from ST is usually very helpful and responsive and he had helped me a lot in the past.
I have seen seen in the various posts that the answers are late ...
Maybe this may not be the best time ...


I see, they do support single-resistor current sensing. Maybe I just missed that because I am using hall based current sensing anyway (currents up to 40A). I am happy to see that they now also have a motor profiler application. You could double check your motor params with that.
Yes. The new KIT I bought already supports the MPA.
It is very useful!


- have you changed R10=R12=47k?
Yes, exactly!


- your overcurrent settings do not seem to match the circuit. Rsense = 0.25 Ohms, comparator trip point = 0.25V, according to 1.0A. Your settings differ (should not prevent startup though)
I checked this out ...
This is the protection of the driver. These were the "default values" of the configurator for this board.


- the board seems to use the microcontroller's internal RC oscillator for clocking, but that is not available from the configuration. My latest project is doing it the same way, but I have modified the startup code. Don't know if there's an automatic fallback if there is no crystal.
A crystal is connected to pins 5 and 6, which I think is 8MHz.
The RefDes is Y1.


- there's some timer magic with the BKIN signal (PB12 on your board), don't remember the exact details. That can block timer operation if I am correct.
The PB12 pin is connected to the driver's SD pin.
In the datasheet the SD pin is described as being an input pin.
In the SD pin the voltage is always 10.5V, so the control logic is active.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #12 on: November 16, 2016, 04:24:45 pm »
I already bought the KIT.

It must arrive tomorrow ...

But making FOC with 1 shunt resistor is possible ....
Then I suggest to compile and flash the project with default options (no ramp, etc) and use the STMC Workbench to control everything via RS232/UART. You'll most probably see directly why the PWM stays in disabled state, probably one of the protection mechanisms (for example over/undervoltage, but I don't think its that) is in error state.

Please also upload your complete project somewhere, there are many IAR project settings that can mess up things so I could check those.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #13 on: November 16, 2016, 04:44:14 pm »
Please also upload your complete project somewhere, there are many IAR project settings that can mess up things so I could check those.

I'm trying to export the project.

I'm more Eclipse user than IAR ...

The project has files all over the directory ....
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #14 on: November 16, 2016, 04:48:56 pm »
When this is over I'll send you the best Portuguese beer ;).
:popcorn:

- your overcurrent settings do not seem to match the circuit. Rsense = 0.25 Ohms, comparator trip point = 0.25V, according to 1.0A. Your settings differ (should not prevent startup though)
I checked this out ...
This is the protection of the driver. These were the "default values" of the configurator for this board.
The values for STMC Workbench "Power Stage -> Overcurrent Protection" are certainly used somehow in the library code, although I have no idea how. I can check this evening in the source code. I suggest to completely disable this feature for now.

A crystal is connected to pins 5 and 6, which I think is 8MHz.
The RefDes is Y1.
Alright... what a crappy symbol in the drawing (en.DM00073152-1.pdf)


- there's some timer magic with the BKIN signal (PB12 on your board), don't remember the exact details. That can block timer operation if I am correct.
The PB12 pin is connected to the driver's SD pin.
In the datasheet the SD pin is described as being an input pin.
In the SD pin the voltage is always 10.5V, so the control logic is active.
Can't see that in the document (STEVAL-IHM040V1), PB12 seems to be pulled to GND but not connected to anything else. BKIN (PB12) is an input to the PWM generating timer, and if I remember it correctly, a HIGH on that pin will inhibit PWM output. I found this document: from ST, AN4277. But maybe not important anymore, lets see how the new board performs.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #15 on: November 16, 2016, 05:09:57 pm »
The values for STMC Workbench "Power Stage -> Overcurrent Protection" are certainly used somehow in the library code, although I have no idea how. I can check this evening in the source code. I suggest to completely disable this feature for now.
OK.
Done!



Alright... what a crappy symbol in the drawing (en.DM00073152-1.pdf)
The first time I looked at him, I did not even realize what it was  :o.
I just understood because of RefDes.


Can't see that in the document (STEVAL-IHM040V1), PB12 seems to be pulled to GND but not connected to anything else. BKIN (PB12) is an input to the PWM generating timer, and if I remember it correctly, a HIGH on that pin will inhibit PWM output. I found this document: from ST, AN4277. But maybe not important anymore, lets see how the new board performs.
Yes, you are right. It's a little strange.
Look at THIS.
The PB12 pin connects, via R8, to pin 2 of the driver.
If the PB12 pin and the SD pin are inputs, then:
V(PB12) = 2.85V (logic 1)   -> Turn off PWM? (I believe the polarity is inverted, otherwise it would not have logic)
V(SDpin) = 11.2V (logic 1) -> Control logic active.

« Last Edit: November 16, 2016, 05:14:19 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #16 on: November 16, 2016, 05:30:05 pm »
Please also upload your complete project somewhere, there are many IAR project settings that can mess up things so I could check those.

I'm trying to export the project.

I'm more Eclipse user than IAR ...

The project has files all over the directory ....

It's ridiculous ... but I can not export the project with the IAR.

To send you the project I would have to send you the folder with the whole SDK (~ 400MB).

But the only files with some kind of change made by me are the files I've already sent you.

I'll take the project home. Any file you need I can search and send to you.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #17 on: November 16, 2016, 05:52:49 pm »
I've been trying to figure out the polarity of BKIN.

TIM1 - BDTR - BKP

But the only "TIM1" reference I have in the project has no configuration.
Where is the timers setup?




[EDIT]: In fact, in all *.c files inside the SDK folder, I can not find any TIM1 settings.
« Last Edit: November 16, 2016, 06:02:26 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #18 on: November 16, 2016, 07:45:27 pm »
Can't see that in the document (STEVAL-IHM040V1), PB12 seems to be pulled to GND but not connected to anything else. BKIN (PB12) is an input to the PWM generating timer, and if I remember it correctly, a HIGH on that pin will inhibit PWM output. I found this document: from ST, AN4277. But maybe not important anymore, lets see how the new board performs.
Yes, you are right. It's a little strange.
Look at THIS.
The PB12 pin connects, via R8, to pin 2 of the driver.
If the PB12 pin and the SD pin are inputs, then:
V(PB12) = 2.85V (logic 1)   -> Turn off PWM? (I believe the polarity is inverted, otherwise it would not have logic)
V(SDpin) = 11.2V (logic 1) -> Control logic active.


That circuit actually makes sense, it is described on page 12 of the UM1595 manual that you gave me a link to. Interestingly, the product brief schematic is actually wrong...

I checked the FOC library source code (rev4.0 - you won't find it, it is not publicly available).

The relevant code passages are these:

Code: [Select]
(R1_LM1_PWMnCurrFdbkClass.c)

  if ((pDParams_str->EmergencyStop)!= DISABLE) 
  {
    /****** Configure TIMx BKIN input, if enabled ******/   
    GPIO_StructInit(&GPIO_InitStructure);
    GPIO_InitStructure.GPIO_Pin = pDParams_str->hBKINPin; 
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
    GPIO_Init(pDParams_str->hBKINPort, &GPIO_InitStructure);
    GPIO_PinLockConfig(pDParams_str->hBKINPort, pDParams_str->hBKINPin);
  }

  /* Dead Time */
  TIM_BDTRStructInit(&TIMx_BDTRInitStructure);
  TIMx_BDTRInitStructure.TIM_OSSRState = TIM_OSSRState_Enable;
  TIMx_BDTRInitStructure.TIM_OSSIState = TIM_OSSIState_Enable;
  TIMx_BDTRInitStructure.TIM_LOCKLevel = TIM_LOCKLevel_1;
  TIMx_BDTRInitStructure.TIM_DeadTime = (pDParams_str->hDeadTime)/2u;
  /* BKIN, if enabled */
  if ((pDParams_str->EmergencyStop)!= DISABLE) 
  {
    TIMx_BDTRInitStructure.TIM_Break = TIM_Break_Enable;
    TIMx_BDTRInitStructure.TIM_BreakPolarity = pDParams_str->hBKINPolarity;
    TIMx_BDTRInitStructure.TIM_AutomaticOutput = TIM_AutomaticOutput_Disable;
    TIM_ClearITPendingBit(TIMx, TIM_IT_Break);
    TIM_ITConfig(TIMx, TIM_IT_Break, ENABLE);
  } 
  TIM_BDTRConfig(TIMx, &TIMx_BDTRInitStructure);

What I found:
- the SD pin of the motor driver can act as an output and pull the line low in an overcurrent situation (2 amps).
- BKIN (PB12) is an input that can be configured for immediate shutdown of all six PWM outputs. Polarity can be active low, or active high. That feature can be enabled or disabled. That input is also configurable as an interrupt source, I haven't checked how the FOC libary configures that though. Most probably enabled. Interrupt "TIM_IT_Break" is enabled and assigned.

You'll find the settings in file "SystemNDriveParams.h" (output from STMC Workbench) in struct "R1_SDParams_t". There, you find these lines:

Code: [Select]
/* PWM Driving signals initialization ----------------------------------------*/ 
 (FunctionalState)SW_OV_CURRENT_PROT_ENABLING, /*!< It enable/disable the management of
                                            an emergency input instantaneously
                                            stopping PWM generation. It must be
                                            either equal to ENABLE or DISABLE */ 
  (uint16_t)(OVERCURR_FEEDBACK_POLARITY),/*!< Emergency Stop (BKIN) input polarity,
                                           it must be TIM_BreakPolarity_Low or
                                           TIM_BreakPolarity_High */
  EMERGENCY_STOP_GPIO_PORT,             /*!< Emergency Stop (BKIN) GPIO input
                                           port (if used, after re-mapping).
                                           It must be GPIOx x= A, B, ...*/
  EMERGENCY_STOP_GPIO_PIN,              /*!< Emergency Stop (BKIN) GPIO input pin
                                         (if used, after re-mapping). It must be
                                          GPIO_Pin_x x= 0, 1, ...*/     

In order to eliminate this mechanism from preventing your motor to spin, I suggest you make sure that SW_OV_CURRENT_PROT_ENABLING == DISABLE.

« Last Edit: November 17, 2016, 06:40:28 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #19 on: November 16, 2016, 07:51:26 pm »
Please also upload your complete project somewhere, there are many IAR project settings that can mess up things so I could check those.

I'm trying to export the project.

I'm more Eclipse user than IAR ...

The project has files all over the directory ....

It's ridiculous ... but I can not export the project with the IAR.

To send you the project I would have to send you the folder with the whole SDK (~ 400MB).

But the only files with some kind of change made by me are the files I've already sent you.

I'll take the project home. Any file you need I can search and send to you.
Only the "Project" and "SystemDriveParams" folders are interesting. If you leave out the SDK binaries (search for .a .o .pbi .cout etc, should be in subfolders like "MC Library Compiled"), it should not be that large.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #20 on: November 16, 2016, 08:26:12 pm »
Only the "Project" and "SystemDriveParams" folders are interesting. If you leave out the SDK binaries (search for .a .o .pbi .cout etc, should be in subfolders like "MC Library Compiled"), it should not be that large.

I hope I have not deleted too many files ...

https://meocloud.pt/link/3eaf8bf7-7baa-4699-af75-c8520d082afd/stm_foc_sdk.rar/

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #21 on: November 16, 2016, 09:03:28 pm »
You'll find the settings in file "SystemNDriveParams.h" (output from STMC Workbench) in struct "R1_SDParams_t". There, you find these lines:

/* PWM Driving signals initialization ----------------------------------------*/ 
 (FunctionalState)SW_OV_CURRENT_PROT_ENABLING, /*!< It enable/disable the management of
                                            an emergency input instantaneously
                                            stopping PWM generation. It must be
                                            either equal to ENABLE or DISABLE */ 
  (uint16_t)(OVERCURR_FEEDBACK_POLARITY),/*!< Emergency Stop (BKIN) input polarity,
                                           it must be TIM_BreakPolarity_Low or
                                           TIM_BreakPolarity_High */
  EMERGENCY_STOP_GPIO_PORT,             /*!< Emergency Stop (BKIN) GPIO input
                                           port (if used, after re-mapping).
                                           It must be GPIOx x= A, B, ...*/
  EMERGENCY_STOP_GPIO_PIN,              /*!< Emergency Stop (BKIN) GPIO input pin
                                         (if used, after re-mapping). It must be
                                          GPIO_Pin_x x= 0, 1, ...*/     


In order to eliminate this mechanism from preventing your motor to spin, I suggest you make sure that SW_OV_CURRENT_PROT_ENABLING == DISABLE.

The only reference I can find is in the MCTasks.c file (and in the SystemNDriveParams.h file).
Code: [Select]
oCurrSensor[M1] = (CPWMC)R1F0XX_NewObject(&PWMnCurrFdbkParamsM1, &R1_SDParams);
This is all a bit tricky ...
« Last Edit: November 16, 2016, 09:05:16 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #22 on: November 16, 2016, 09:08:35 pm »
Only the "Project" and "SystemDriveParams" folders are interesting. If you leave out the SDK binaries (search for .a .o .pbi .cout etc, should be in subfolders like "MC Library Compiled"), it should not be that large.

I hope I have not deleted too many files ...

https://meocloud.pt/link/3eaf8bf7-7baa-4699-af75-c8520d082afd/stm_foc_sdk.rar/
Should be complete. I checked --> #define SW_OV_CURRENT_PROT_ENABLING      DISABLE

Your Eclipse project file is not included there, that would be essential. The library extensively uses #define rubbish.

I checked my IAR project. It defines the following globals:
USE_STDPERIPH_DRIVER
STM32F10X_MD
ARM_MATH_CM3

Here is the search path for .c/h files:
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\STM32F10x_StdPeriph_Driver\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface\common
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\interface
$PROJ_DIR$\
$PROJ_DIR$\SystemDriveParams

For some of the files you only have the compiled libary binaries.

Have you been more successful with the new kit? Does the RS232 link work?
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #23 on: November 16, 2016, 09:24:29 pm »
You'll find the settings in file "SystemNDriveParams.h" (output from STMC Workbench) in struct "R1_SDParams_t". There, you find these lines:

/* PWM Driving signals initialization ----------------------------------------*/ 
 (FunctionalState)SW_OV_CURRENT_PROT_ENABLING, /*!< It enable/disable the management of
                                            an emergency input instantaneously
                                            stopping PWM generation. It must be
                                            either equal to ENABLE or DISABLE */ 
  (uint16_t)(OVERCURR_FEEDBACK_POLARITY),/*!< Emergency Stop (BKIN) input polarity,
                                           it must be TIM_BreakPolarity_Low or
                                           TIM_BreakPolarity_High */
  EMERGENCY_STOP_GPIO_PORT,             /*!< Emergency Stop (BKIN) GPIO input
                                           port (if used, after re-mapping).
                                           It must be GPIOx x= A, B, ...*/
  EMERGENCY_STOP_GPIO_PIN,              /*!< Emergency Stop (BKIN) GPIO input pin
                                         (if used, after re-mapping). It must be
                                          GPIO_Pin_x x= 0, 1, ...*/     


In order to eliminate this mechanism from preventing your motor to spin, I suggest you make sure that SW_OV_CURRENT_PROT_ENABLING == DISABLE.

The only reference I can find is in the MCTasks.c file (and in the SystemNDriveParams.h file).
Code: [Select]
oCurrSensor[M1] = (CPWMC)R1F0XX_NewObject(&PWMnCurrFdbkParamsM1, &R1_SDParams);
This is all a bit tricky ...
that is how the library is organized. mctasks.c instanciates all objects and feeds them with parameters. the library is using a poormans object oriented approach, still being pure c code.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #24 on: November 16, 2016, 10:28:42 pm »
Your Eclipse project file is not included there, that would be essential. The library extensively uses #define rubbish.
You wanted to say IAR, right?
Please do not ruin my head  ;D.


Have you been more successful with the new kit? Does the RS232 link work?
The new KIT should arrive tomorrow (if the carrier is not late) ...
Tomorrow as soon as the KIT arrives I test this all and keep the topic updated.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #25 on: November 16, 2016, 10:40:00 pm »
I checked my IAR project. It defines the following globals:
USE_STDPERIPH_DRIVER
STM32F10X_MD
ARM_MATH_CM3

Here is the search path for .c/h files:
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\STM32F10x_StdPeriph_Driver\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface\common
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\interface
$PROJ_DIR$\
$PROJ_DIR$\SystemDriveParams
Now that I see, this is described in Chapter 10.3 of the manual, but I'm using the IAR for the first time ...
Where do I declare global variables and define the path of includes?

Here?
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #26 on: November 17, 2016, 06:38:32 am »
Your Eclipse project file is not included there, that would be essential. The library extensively uses #define rubbish.
You wanted to say IAR, right?
Please do not ruin my head  ;D.
That's human communication. After you wrote that you cannot export the project to IAR, I thought that we should stick with getting Eclipse/GNU to work. But didn't write it  :o
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #27 on: November 17, 2016, 06:40:29 am »
I checked my IAR project. It defines the following globals:
USE_STDPERIPH_DRIVER
STM32F10X_MD
ARM_MATH_CM3

Here is the search path for .c/h files:
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\Libraries\STM32F10x_StdPeriph_Driver\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCLibrary\interface\common
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\MCApplication\interface
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\inc
$PROJ_DIR$\..\..\STM32 PMSM FOC LIBv4.0\ProtectedSources\UILibrary\interface
$PROJ_DIR$\
$PROJ_DIR$\SystemDriveParams
Now that I see, this is described in Chapter 10.3 of the manual, but I'm using the IAR for the first time ...
Where do I declare global variables and define the path of includes?

Here?

There are readily pre-packaged projects, have a look in Project/EWWARM. You should only need to configure the debugger, and maybe select the correct MCU type after selecting the correct project. The project name suggests that you already had done these steps? The #define config pane that you are looking for here is under "C/C++ Compiler", tab "Preprocessor".
« Last Edit: November 17, 2016, 06:43:15 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #28 on: November 17, 2016, 09:24:31 am »
Yes, I had already changed the processor to be the same as I am using.



The preprocessor settings are correct. Just like you said.




On this board ... no clues for it to work, right?
It seems that everything is right, but something prevents it from working ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #29 on: November 17, 2016, 10:28:01 am »
Yes, I had already changed the processor to be the same as I am using.



The preprocessor settings are correct. Just like you said.




On this board ... no clues for it to work, right?
It seems that everything is right, but something prevents it from working ...
Wouldn't say that. I'm chasing three possibilities:
1) toolchain problem, project setup -> I think as you managed to migrate to IAR using the default projects (I assume you could flash and run the code with it, and get the same result - no PWM, right?) we can cross this out.
2) board compatibility -> I see only the BKIN issue as possible reason why you don't get PWM signals. I remember from all the documentation that there was a side note that, on some STM32F derivates, this feature cannot be disabled in the timer block. Don't remember where that was though. I decided back then to sacrifice one GPIO for that, and tie it to GND. So it is possible that, even though you disabled that feature in the configuration tool, it is still ruining your day. Maybe do a test and desolder that R8 resistor, this way the driver chip could see a HIGH, and PB12 could see a low. Then enable the BKIN feature again, check it is assigned to PB12 and configured HIGH-active.
3) the FOC library has a number of protection mechanisms that cause it to shut down. For example, over/undervoltage. You could easily see via RS232 and the STMC Workbench's remote control, if one of them is alarmed. I didn't ask that yet: I assume that you supply the board with 24V, right?

You could also start debugging the code, and see if one of the protection mechanisms is shutting down the PWM. But as most of the FOC libary is only available as a binary blob, that can be very difficulty. A good starting point could be MCTasks.c --> TSK_SafetyTask(). This function is regularly called from an interrupt service, and checks for problems.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #30 on: November 17, 2016, 10:49:47 am »
1) toolchain problem, project setup -> I think as you managed to migrate to IAR using the default projects (I assume you could flash and run the code with it, and get the same result - no PWM, right?) we can cross this out.
Exactly.
I've always used the IAR to send code to the MCU. And I already showed you that I can debug.


2) board compatibility -> I see only the BKIN issue as possible reason why you don't get PWM signals. I remember from all the documentation that there was a side note that, on some STM32F derivates, this feature cannot be disabled in the timer block. Don't remember where that was though. I decided back then to sacrifice one GPIO for that, and tie it to GND. So it is possible that, even though you disabled that feature in the configuration tool, it is still ruining your day. Maybe do a test and desolder that R8 resistor, this way the driver chip could see a HIGH, and PB12 could see a low. Then enable the BKIN feature again, check it is assigned to PB12 and configured HIGH-active.
This would be a method of securing this issue ...
Is the polarity of BKIN high?


3) the FOC library has a number of protection mechanisms that cause it to shut down. For example, over/undervoltage. You could easily see via RS232 and the STMC Workbench's remote control, if one of them is alarmed. I didn't ask that yet: I assume that you supply the board with 24V, right?
Yes of course.
I've checked several times, because in the Renesas board I had a problem with the supply voltage of the circuit ...


You could also start debugging the code, and see if one of the protection mechanisms is shutting down the PWM. But as most of the FOC libary is only available as a binary blob, that can be very difficulty. A good starting point could be MCTasks.c --> TSK_SafetyTask(). This function is regularly called from an interrupt service, and checks for problems.
I'll debug and analyze this function better.
In the meantime, it may be that the new EVB arrives and can do more tests.

Thank you.  :-+
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #31 on: November 17, 2016, 11:09:11 am »
You were right.
But it's strange because I measured the voltage and it's correct.

I measured 1.95V at resistor R14 (Vbus ~ 24.3V).

I lowered the voltage to 15V and still have that error.
I've commented this line and I already have PWM in the outputs ....


 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #32 on: November 17, 2016, 12:35:52 pm »
The new EVB has arrived!

I am doing the first setup and the first tests written in the documents.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #33 on: November 17, 2016, 01:20:41 pm »
This would be a method of securing this issue ...
Is the polarity of BKIN high?
It can be configured in the TIM1 peripheral, and "OVERCURR_FEEDBACK_POLARITY" controls it. In the STMC Workbench, Power Stage -> Overcurrent Protection -> Overcurrent feedback signal polarity.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #34 on: November 17, 2016, 01:27:59 pm »
You were right.
But it's strange because I measured the voltage and it's correct.

I measured 1.95V at resistor R14 (Vbus ~ 24.3V).

I lowered the voltage to 15V and still have that error.
I've commented this line and I already have PWM in the outputs ....



You can also uncheck the "Bus Voltage Sensing" in STMC Workbench "Power Stage" section.
The alarm is configured by the following definitions:
VBUS_PARTITIONING_FACTOR
OV_VOLTAGE_THRESHOLD_V
UD_VOLTAGE_THRESHOLD_V

Something must be wrong with one of these. I cannot find a mistake in your "drive_alte.stmcx", maybe a bug in the STMC Workbench?

You can look up all the relations in the STMC Workbench -> Help -> Content menu, then Supported Classes Parameters -> Single Motor.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #35 on: November 17, 2016, 01:44:03 pm »
another quick question: are you sure that you compile in the same SystemDriveParams\* files that were generated by the STMC Workbench? Simple test is to have the Workbench repeat generating these files, and pressing Make in the toolchain. That has to trigger rebuilding some of the files. I really cannot find a single error in any of these files...

Code: [Select]
#define OV_VOLTAGE_THRESHOLD_V          32 /*!< Over-voltage
                                                         threshold */
#define UD_VOLTAGE_THRESHOLD_V          18 /*!< Under-voltage
                                                          threshold */
#define VBUS_PARTITIONING_FACTOR      0.0833 /*!< It expresses how
                                                       much the Vbus is attenuated 
                                                       before being converted into
                                                       digital value */
#define MCU_SUPPLY_VOLTAGE    3.30
Have you stepped into TSK_SafetyTask_PWMOFF ? Are you sure that it is the voltage monitor that is tripping?
« Last Edit: November 17, 2016, 06:39:28 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #36 on: November 17, 2016, 03:05:16 pm »
The files generated by the configurator are those compiled. I see this when I change values and the files in the compiler change as well.

I'll forget for now the EVB STEVAL-IHM040V1.

It is best to start over, but using EVB P-NUCLEO-IHM001 (as it should have done from the beginning, my fault).

While I'm doing some calibration ... I leave some questions.

How can I configure another serial port?
Do I have to do all the setup in the registers?
Or can I use the serial port using the SDK?

I know it may sound silly questions ... but for now it's causing me some confusion ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #37 on: November 17, 2016, 03:59:33 pm »
The files generated by the configurator are those compiled. I see this when I change values and the files in the compiler change as well.

I'll forget for now the EVB STEVAL-IHM040V1.

It is best to start over, but using EVB P-NUCLEO-IHM001 (as it should have done from the beginning, my fault).

While I'm doing some calibration ... I leave some questions.

How can I configure another serial port?
Do I have to do all the setup in the registers?
Or can I use the serial port using the SDK?

I know it may sound silly questions ... but for now it's causing me some confusion ...
The problem with over/undervoltage monitor will probably not disappear, because 2V @ ADC matches well with 24V bus voltage. Better keep that feature disabled and leave it for later.

The STMWB has templates for NUCLEO-IHM07 and -08, you can check if these have identical microcontroller pinout. Then you'd only have to copy the motor parameters. There is a top row button that gives you an overview of the pin assignments, it looks like a chip.

Re the serial port: Do you mean on the Windows machine, or do you mean the microcontroller pin assignment? The latter is in STMCWB under Control Stage -> User Interface  (enable it there), and Control Stage -> Digital I/O. For the Windows machine, click on the symbol that looks like an analog gauge.

p.s. overvoltage protection can be very important, if your system can go into regenerative operation, and your bus voltage has the ability to charge up. For example, if the controller abruptly decelerates the motor and the mass that is attached to its shaft, then you'll have a considerable amount of energy being fed back into the DC bus, charging the bus capacitor. If nothing is keeping the voltage down, you can easily run into overvoltage, and boom. If your system supply will be a simple DC/DC converter, that can easily happen. If your supply is a battery that is directly connected to the bus, then that will suck in the excessive energy. Unless you have a fuse that can blow (which is what happened to me...).
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #38 on: November 17, 2016, 04:21:13 pm »
The STMWB has templates for NUCLEO-IHM07 and -08, you can check if these have identical microcontroller pinout. Then you'd only have to copy the motor parameters. There is a top row button that gives you an overview of the pin assignments, it looks like a chip.
In the version I have already has a template for P-NUCLEO-IHM001.


Re the serial port: Do you mean on the Windows machine, or do you mean the microcontroller pin assignment? The latter is in STMCWB under Control Stage -> User Interface  (enable it there), and Control Stage -> Digital I/O. For the Windows machine, click on the symbol that looks like an analog gauge.
In the MCU.
Because in the future the goal is to send speeds via serial port.


p.s. overvoltage protection can be very important, if your system can go into regenerative operation, and your bus voltage has the ability to charge up. For example, if the controller abruptly decelerates the motor and the mass that is attached to its shaft, then you'll have a considerable amount of energy being fed back into the DC bus, charging the bus capacitor. If nothing is keeping the voltage down, you can easily run into overvoltage, and boom. If your system supply will be a simple DC/DC converter, that can easily happen. If your supply is a battery that is directly connected to the bus, then that will suck in the excessive energy. Unless you have a fuse that can blow (which is what happened to me...).
In my situation the power comes from a battery. Over voltage should not be a big problem. But I must be aware of this problem.


So far everything is going well  :).
I already switched to my motor and it works fine. I will now try to enable the encoder control.

PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #39 on: November 17, 2016, 06:21:57 pm »
Because in the future the goal is to send speeds via serial port.
You can either tell STMCWB to configure one of the serial ports for STMCWB remote control, or disable that feature which frees it for you to.

So far everything is going well  :).
I already switched to my motor and it works fine. I will now try to enable the encoder control.
Great!

PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).
I strongly recommend to check current control loop stability first, to do that route Id and Iq to the two DAC outputs, and attach a scope. What I do then is to pulse the Iq setpoint (that part which is not contributing to torque), and watch the result on the scope. If your overcurrent circuit triggers, it can be an indication of current loop instability. I use this code to generate the setpoint pulse:


Code: [Select]
static int i=0;
i++;
FOCVars[M1].Iqdref.qI_Component1 = 0;
if( (i%300) < 150 )
{
FOCVars[M1].Iqdref.qI_Component2 = (int16_t)( 1.0f * (65536.0f * (float)(AMPLIFICATION_GAIN / MCU_SUPPLY_VOLTAGE) ) );
}
else
{
FOCVars[M1].Iqdref.qI_Component2 = 0;
}
I run this in a cyclic interrupt, in my case at 2kHz. And I make sure that no velocity control is in place, that would interfere with it.

Another useful hack is disabling the angle measurement, this way you can apply motor current without having it spin up. Easier than blocking the motor mechanically for some tests. This is part of MCTasks.c:

Code: [Select]
uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
  static int16_t k=0; k+=1; hElAngledpp=k;  <<<<<<<<<< inserted, very slow motor rotation
 
  PWMC_GetPhaseCurrents(oCurrSensor[bMotor], &Iab);
 ...
PS: before that I have to solve another problem. Sometimes I have overcurrent errors. I have to see how I can change the threshold (I've already changed "Over Current Protection" but it's still the same effect).
There is only one mechanism reporting overcurrent, and that is the BKIN feature. An overcurrent can only be reported by the hardware comparator(s). There is no need for a software based overcurrent monitor, because the FOC algorithm *controls* the current (unless there is loop instability).
« Last Edit: November 17, 2016, 06:39:00 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #40 on: November 17, 2016, 08:13:26 pm »
There is only one mechanism reporting overcurrent, and that is the BKIN feature. An overcurrent can only be reported by the hardware comparator(s). There is no need for a software based overcurrent monitor, because the FOC algorithm *controls* the current (unless there is loop instability).

So I have to study the driver better.

In fact, I get a bit confused because Renesas used different methods. But I'm enjoying ST.



[EDIT]
During the Motor Profiler tests, the motor is put under more stress and can exceed these currents ...

But tomorrow I will analyze better with the scope what is happening.

« Last Edit: November 17, 2016, 08:23:15 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #41 on: November 17, 2016, 08:56:41 pm »
looks good. but if the current control loop (a PI type controller) is set up well, then it will not exceed the motor's rated current in any situation
 just make sure to set a value smaller than the overcurrent threshold, like maybe 1.8A in your case, in the motor parameters in STMCWB. the PI control gains are calculated ftom the motor specs L, R, but i did not have the impression that the calculations were right so i did my own tuning. the standard procedure here is I=0, slowly step up P until stability starts degrading, then step up I until critical. then i like to set 50% of these values so i have a safety margin. do all this at max bus voltage. maybe the motor profiler does this job as well? will play with it when i have time.
« Last Edit: November 17, 2016, 09:03:21 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #42 on: November 18, 2016, 09:45:40 am »
For some reason only yesterday I concluded that I had version 4.2 installed. The latest version (4.3) already has worspaces for AC6.
I was able to import the project correctly, but I can not compile.
This is the message that appears.
Do not you know what might cause this?
I can not find the lib "MC_Library_STM32F302x8_single_drive" anywhere ....


Quote
09:39:34 **** Incremental Build of configuration P-NUCLEO-IHM001_SINGLEDRIVE for project STM32F30x_UserProject ****
make all
'Building target: STM32F30x_UserProject.elf'
'Invoking: MCU GCC Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled" -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\MCO_SD"  --specs=rdimon.specs -T"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\STM32F30x_UserProject\STM32F302R8Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm -o "STM32F30x_UserProject.elf" @"objects.list"  -lMC_Library_STM32F302x8_single_drive -lMC_Lib_PS_CM4
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lMC_Library_STM32F302x8_single_drive
collect2.exe: error: ld returned 1 exit status
make: *** [STM32F30x_UserProject.elf] Error 1
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #44 on: November 18, 2016, 11:18:28 am »
I installed version 4.2 on another computer and copied the * .a files.

I pasted the files into the "AC6 \ MC Library Compiled" folder, but the compiler still can not find the files.

Then I changed the file name to "libMC_Library_STM32F302x8_single_drive.a", but I have a lot of fails and some undefined references.

It seems to me that libraries are not compatible (has logic), version 4.2 for version 4.3.

Code: [Select]
make all
'Building target: STM32F30x_UserProject.elf'
'Invoking: MCU GCC Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled" -L"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\MCO_SD"  --specs=rdimon.specs -T"C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\STM32F30x_UserProject\STM32F302R8Tx_FLASH.ld" -Wl,-Map=output.map -Wl,--gc-sections -lm -o "STM32F30x_UserProject.elf" @"objects.list"  -lMC_Library_STM32F302x8_single_drive -lMC_Lib_PS_CM4
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(BusVoltageSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(CircleLimitationClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(DigitalOutputClass_F30X.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(FeedForwardCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(FluxWeakeningCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MC_Math.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MCIRQHandlerClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(MotorPowerMeasurementClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(NTC_F30X_TemperatureSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PID_PIRegulatorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PIRegulatorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PQD_MotorPowerMeasurementClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(PWMnCurrFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(R3_1_F30X_PWMnCurrFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(RampExtMngrClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(Rdivider_F30X_BusVoltageSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(RevupCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(SpeednTorqCtrlClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(StateMachineClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(STO_CORDIC_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(STO_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(TemperatureSensorClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829/tools/compiler/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Program Files (x86)\STMicroelectronics\FOC SDK\v4.3.0\STM32 PMSM FOC LIB\Web\Project\AC6\MC Library Compiled\libMC_Library_STM32F302x8_single_drive.a(VirtualSpeedSensor_SpeednPosFdbkClass.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
Motor control/MC Application/src/MCInterfaceClass.o: In function `MCI_StopSpeedRamp':
C:/Program Files (x86)/STMicroelectronics/FOC SDK/v4.3.0/STM32 PMSM FOC LIB/Web/MCApplication/src/MCInterfaceClass.c:491: undefined reference to `STC_StopSpeedRamp'
Motor control/MC Application/src/MCTasks.o: In function `TSK_MediumFrequencyTaskM1':
C:/Program Files (x86)/STMicroelectronics/FOC SDK/v4.3.0/STM32 PMSM FOC LIB/Web/MCApplication/src/MCTasks.c:1339: undefined reference to `STC_ForceSpeedReferenceToCurrentSpeed'
collect2.exe: error: ld returned 1 exit status
make: *** [STM32F30x_UserProject.elf] Error 1
« Last Edit: November 18, 2016, 11:20:54 am by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #45 on: November 18, 2016, 06:54:19 pm »
All solved so far.

Now the problem is the encoder.

The motor gives a small start, but then stops.

The motor gets "stuck" (current is flowing).

The encoder is already configured but I can not start up with the control.




 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #46 on: November 19, 2016, 06:39:18 pm »
All solved so far.

Now the problem is the encoder.

The motor gives a small start, but then stops.

The motor gets "stuck" (current is flowing).

The encoder is already configured but I can not start up with the control.





you cannot use an encoder as primary rotor angle sensor. until the reference mark is passed the first time, how should the software know the absolute rotor angle? you need an absolute angle sensor, like three hall sensors, or use sensorless startup to have the rotor start spinning. (does your encoder have a reference channel?) another option, but only if there is no load at the shaft: apply current with a given fixed vector, wait some time until the rotor has arrived and stabilized there, the yinitialize for encoder use. i have code for that at home, can send you tomorrow.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #47 on: November 19, 2016, 06:58:12 pm »
My problem is the low revs.
At low speeds the sensorless control does not work because there is no sufficient current through the shunts.
My encoder is a magnetic IC that generates 1024 pulses per mechanical rotation.
This IC also has outputs corresponding to the sensor hall, but I do not think the magnet is calibrated with the rotor.

Monday I will test with sensorless as a primary control and with auxiliary control using encoder.
I'm going to accelerate to 2000 RPM and then I'm slowly going down to 100 RPM. Below the 350RPM the sensorless control can not rotate the motor.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #49 on: November 21, 2016, 08:19:50 am »
My problem is the low revs.
At low speeds the sensorless control does not work because there is no sufficient current through the shunts.
My encoder is a magnetic IC that generates 1024 pulses per mechanical rotation.
This IC also has outputs corresponding to the sensor hall, but I do not think the magnet is calibrated with the rotor.

Monday I will test with sensorless as a primary control and with auxiliary control using encoder.
I'm going to accelerate to 2000 RPM and then I'm slowly going down to 100 RPM. Below the 350RPM the sensorless control can not rotate the motor.
I need some more information to understand your application here:
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?
- do you need to be able to rev up the motor under load?
- after rev up, do you need to be able to provide torque at standstill?

It sounds like your encoder is a resolver (https://en.wikipedia.org/wiki/Resolver_%28electrical%29). The natural output of these is two analog signals, but many modern ones can also emulate incremental encoders, and hall sensors.

If you have something like this, then it can determine the absolute rotor angle immediately after powerup. If it then provides Hall outputs, then you should go for those instead.

The FOC algorithm interpolates the Hall sensors while the motor is turning, so there will be no degradation. But you have a 10-20% torque loss at very slow velocity (probably far slower than the numbers that you mentioned) and standstill. If that is not a problem in your application, then you'd be fine. And your possible encoder software/microcontroller limitation from your last post would become unimportant (I vaguely remember that I needed to sacrifice a GPIO for that, can check this evening).
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #50 on: November 21, 2016, 08:26:56 am »
Should I worry about this?

Page 8, 3.2.1 - http://www.st.com/content/ccc/resource/technical/document/release_note/b1/3f/4e/1b/cc/7f/45/c1/DM00068242.pdf/files/DM00068242.pdf/jcr:content/translations/en.DM00068242.pdf


Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not  ;)
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #51 on: November 21, 2016, 09:29:24 am »
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?
Yes it has an incremental output (I channel).
The encoder is this (PDF downloads automatically): https://ams.com/kor/content/download/725051/1853902/file/AS5047P_DS000324_2-00.pdf
It also gives absolute rotor angle.


- do you need to be able to rev up the motor under load?
- after rev up, do you need to be able to provide torque at standstill?
The motor will always be in effort. This may have several applications, but the most immediate will be a larger-sized robot.
I need the engine to start rotating with the engine weight to overcome the inertia moment.


The FOC algorithm interpolates the Hall sensors while the motor is turning, so there will be no degradation. But you have a 10-20% torque loss at very slow velocity (probably far slower than the numbers that you mentioned) and standstill. If that is not a problem in your application, then you'd be fine. And your possible encoder software/microcontroller limitation from your last post would become unimportant (I vaguely remember that I needed to sacrifice a GPIO for that, can check this evening).
Very low speed maybe is very slow even for me  :).
A minimum speed of 100RPM in the motor goes through the gearbox, and I get output rotation of approx 1.5RPM.


PS: I just tested with sensorless on primary control and with encoder on auxiliary control, but the motor does not rotate properly. The motor runs for a while (1/2sec) and then stops and it is consuming current.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #52 on: November 21, 2016, 10:05:44 am »
Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not  ;)

I do not see anything in scope.
I've tried several variables for the DAC, but the output is always static.



 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #53 on: November 21, 2016, 11:37:36 am »
After some adjustments the encoder is operating on the main controller.
The controller energize the motor to align the encoder and starts running from there. If I understood correctly ...
After some tuning it works.

But I still can not control the speed at low speed. The motor runs out of torque ...

How can I fine tune the torque?
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #54 on: November 21, 2016, 11:48:05 am »
Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not  ;)

I do not see anything in scope.
I've tried several variables for the DAC, but the output is always static.


Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.
« Last Edit: November 21, 2016, 11:59:01 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #55 on: November 21, 2016, 12:09:14 pm »
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?
Yes it has an incremental output (I channel).
The encoder is this (PDF downloads automatically): https://ams.com/kor/content/download/725051/1853902/file/AS5047P_DS000324_2-00.pdf
It also gives absolute rotor angle.
As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #56 on: November 21, 2016, 12:31:24 pm »
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE


In the "UI_TaskInit" file the DAC is enabled.


I am using serial communication to use STMCW...


As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.
OK friend.

I'm going to do just one more test and switch to hall sensor emulation. But the sensor and magnet in the rotor not need to be aligned?


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #57 on: November 21, 2016, 02:10:31 pm »
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE

In the "UI_TaskInit" file the DAC is enabled.

I am using serial communication to use STMCW...
Hmmm, hard to say without having the hardware on my table. The AOUT feature worked without hassles right from the beginning for me and was of great help, but I remember having removed all the eval board stuff in the very beginning, because I was using my custom board right from the start. The NUCLEO board is supposed to deliver the analog signal at X2 / pin 3 ("A2"). I hope you didn't probe at pin 5 "A4".

As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.
OK friend.

I'm going to do just one more test and switch to hall sensor emulation. But the sensor and magnet in the rotor not need to be aligned?
It needs to. You can configure the offset in degrees in STMCWB -> hall motor feedback parameters "placement electrical angle". The "sensors displacement" must be 120°.

The simplest way to find out the correct offset is the following (alternatively you can grab a scope and probe phases and halls, but there can be a lot of pitfalls in interpreting them correctly):
- start with offset 0
- start the motor with maximum torque and velocity settings
- the motor will likely spin in one or the other direction
- now repeat the process, but increment the offset by, lets say, 30 degrees per try, until you find the precise offset in which the motor does *not* turn anymore. you may also turn the shaft by hand and feel if the counter torque is equal in both directions. decrease your offset step width until you have found that precise offset angle

Now set this value, plus 90 degrees, as your final offset value.

If the motor spins in opposite direction as you want, add another 180 degrees.

If your magnet orientation is not repeatable in later mass production (I hope it is), you can also implement this strategy in software.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #58 on: November 21, 2016, 02:28:20 pm »
After some adjustments the encoder is operating on the main controller.
The controller energize the motor to align the encoder and starts running from there. If I understood correctly ...
After some tuning it works.

But I still can not control the speed at low speed. The motor runs out of torque ...

How can I fine tune the torque?
If the motor runs out of torque, then there still is a problem with configuration. FOC basically works as two nested PI control loops:
- the outer loop controls velocity and calculates a torque value: set_torque = PI ( set_velocity, current_velocity )
- the inner loop controls torque and calculates motor set_voltage: voltage = PI ( set_torque, current_torque )

For a PMSM, motor torque is proportional to phase current (magnitude of 3-phase current vector), so you can replace torque by current in the above.

The set_torque resp. set_current value is limited by the rated motor current that you provide.

You can see that you'll get full torque in all situations, also in standstill. This makes FOC ideal for servo applications like yours. I have made a 25kW servo using this, and I have it made playing music by controlling velocity setpoint for fun. I had to make sure it is tightly bolted to the table, or it would jump off just from rotor inertia. It was amazing, you couldn't even *hear* it accelerating or decelerating.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #59 on: November 21, 2016, 02:33:49 pm »
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE

In the "UI_TaskInit" file the DAC is enabled.

I am using serial communication to use STMCW...
Hmmm, hard to say without having the hardware on my table. The AOUT feature worked without hassles right from the beginning for me and was of great help, but I remember having removed all the eval board stuff in the very beginning, because I was using my custom board right from the start. The NUCLEO board is supposed to deliver the analog signal at X2 / pin 3 ("A2"). I hope you didn't probe at pin 5 "A4".
In fact I'm doing probe of the A4 pin. This pin is marked on the schematic as the DAC pin.


EDIT:



Once again you're right.
The resistor R76 is not assembled and so in J7 there is no DAC.
But on pin C7_32 I already have the triangular shape of the encoder.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #60 on: November 21, 2016, 02:49:39 pm »
If the motor runs out of torque, then there still is a problem with configuration. FOC basically works as two nested PI control loops:
- the outer loop controls velocity and calculates a torque value: set_torque = PI ( set_velocity, current_velocity )
- the inner loop controls torque and calculates motor set_voltage: voltage = PI ( set_torque, current_torque )

For a PMSM, motor torque is proportional to phase current (magnitude of 3-phase current vector), so you can replace torque by current in the above.

The set_torque resp. set_current value is limited by the rated motor current that you provide.

You can see that you'll get full torque in all situations, also in standstill. This makes FOC ideal for servo applications like yours. I have made a 25kW servo using this, and I have it made playing music by controlling velocity setpoint for fun. I had to make sure it is tightly bolted to the table, or it would jump off just from rotor inertia. It was amazing, you couldn't even *hear* it accelerating or decelerating.

I have to work on it.
I do not have to calibrate the values of Iq and Id PID's?

Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...
For some reason, I can only use integers.


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #61 on: November 21, 2016, 02:49:46 pm »
one more idea: to test if everything is working as it should, you can
- use speed control mode
- have the motor rev up and find its encoder alignment
- set zero rpm

The motor has to abruptly stop. When you try to turn the shaft by hand, you should feel the same holding torque in both directions. If that is asymmetrical instead, it is a direct indication of an incorrect encoder alignment.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #62 on: November 21, 2016, 03:37:14 pm »
There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  :o.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #63 on: November 21, 2016, 03:41:07 pm »
I do not have to calibrate the values of Iq and Id PID's?
(Although they name it PID control, it is actually PI control (no differential term)...) STMCWB automatically calculates a set of Kp / Ki based on the motor parameters that you typed in, and that should be good to start with. But as I mentioned in an earlier post I did my own tuning and don't trust their calculations a lot anymore. The difficulty with own tuning, as mentioned, is that you need a step input for the torque/current setpoint, and you don't want the motor to be able to move, even a little, in order to be able to obtain a nice clear step response reading on your scope (set AOUT = Iq).

Another thing that may important. You can adjust the current controller's update rate in multiples of PWM cycles. Don't make it too slow, or the controller may become instable. If your motor inductance is low, then you need a fast current controller. I suggest to set  (Drive Management -> Drive Settings -> Torque&flux regulators -> Execution rate) to get an update rate of > 5kHz to stay on the safe side.

Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...
Torque ref / Iq is the current setpoint value for the current PI controller that I am talking about. That is the current that you want to flow through the phases. The other value, Flux ref / Id, is always zero in a servo application. I made some explanations on this in another thread: https://www.eevblog.com/forum/chat/regulating-speedtorque-of-induction-motor-methods/?all

For some reason, I can only use integers.
Probably a bug, but maybe they forgot the conversion between float[amps] and their internal fixpoint integer values. What happens when you set 1? If the motor spins, then it is Amperes. If not, try larger numbers up to +-32767.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #64 on: November 21, 2016, 03:43:30 pm »
There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  :o.
It starts sensorless, and tries to switch over to encoder, but only if it is present. The library always monitors the validity of its connected speed sensors. If you disconnect the cable, it will stay in sensorless mode.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #65 on: November 21, 2016, 03:59:29 pm »
Another thing that may important. You can adjust the current controller's update rate in multiples of PWM cycles. Don't make it too slow, or the controller may become instable. If your motor inductance is low, then you need a fast current controller. I suggest to set  (Drive Management -> Drive Settings -> Torque&flux regulators -> Execution rate) to get an update rate of > 5kHz to stay on the safe side.
This should not be a problem. My execution rate is 2 PWM period (15KHz).


Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...
Torque ref / Iq is the current setpoint value for the current PI controller that I am talking about. That is the current that you want to flow through the phases. The other value, Flux ref / Id, is always zero in a servo application. I made some explanations on this in another thread: https://www.eevblog.com/forum/chat/regulating-speedtorque-of-induction-motor-methods/?all
Thank you.
I'll read the post.


For some reason, I can only use integers.
Probably a bug, but maybe they forgot the conversion between float[amps] and their internal fixpoint integer values. What happens when you set 1? If the motor spins, then it is Amperes. If not, try larger numbers up to +-32767.
Yes it is a bug.
I can only use integers in the "monitor". In the STMCW configurator I can enter current with decimal places.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #66 on: November 21, 2016, 04:31:28 pm »
There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  :o.
It starts sensorless, and tries to switch over to encoder, but only if it is present. The library always monitors the validity of its connected speed sensors. If you disconnect the cable, it will stay in sensorless mode.
I think the controller is not using the encoder channels even after I select the encoder on the main sensor.
Already after the motor is running I turn off one of the channels of the encoder and still it continues to run properly.
In this situation I'm pretty sure it would give a fault.

It's a strange situation ...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #67 on: November 21, 2016, 05:17:40 pm »
Am I doing something wrong?

One question: in the last image I do encoder align and then start motor, but the motor does not rotate. Was not this the right procedure?

























 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #68 on: November 21, 2016, 06:41:36 pm »
I'm starting to walk in circles ...
I'm not making progress.

In this link is the SDK configuration file.

https://meocloud.pt/link/ba2e6d66-9d51-4cac-80eb-46542dcb6d27/ro_mot.rar/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #69 on: November 21, 2016, 07:41:04 pm »
Am I doing something wrong?

One question: in the last image I do encoder align and then start motor, but the motor does not rotate. Was not this the right procedure?
Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position. Also very make sure that
- the encoder angular resolution matches the reality, in your case 512 (I see that the encoder chip is programmable)
- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #70 on: November 21, 2016, 08:08:29 pm »
I'm starting to walk in circles ...
I'm not making progress.

In this link is the SDK configuration file.

https://meocloud.pt/link/ba2e6d66-9d51-4cac-80eb-46542dcb6d27/ro_mot.rar/
Checked the file and have a few questions.
- you have enabled motor temperature sensing, are you sure that this is not triggering? Maybe temporarily disable it, maybe also disable bus voltage monitoring and over-current protection to be on the safe side
- I saw the nucleo power board can be configured to one-shunt and 3-shunt, is that set to 3-shunt?
- you can try to reverse the encoder's counting direction in STMCWB (in Drive Management -> Speed Pos... -> Main sensor), if these mismatch the motor can also never run
- 15kHz current loop update rate is quite high, don't know if the CPU can handle that. Maybe try :4 ratio from PWM instead of :2
- you have enabled current feed forward ("Additional Features and PFC settings"). Possible instability if motor parameters are not perfect, suggest to disable that temporarily

We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #71 on: November 21, 2016, 09:01:20 pm »
Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.
Apparently nothing.
I was hoping the current of my power supply would increase. But that does not happen.

- the encoder angular resolution matches the reality, in your case 512 (I see that the encoder chip is programmable)
I already received the motor with the encoder mounted. Initially I thought it was 1024 pulses per mec/rev (this is the default value).
However, I activated the oscilloscope pulse count and it counts ~ 512 pulses per 1 mec/rev (without the reduction box, of corse).

- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.
I think the motor has 3 pairs of poles, but the seller says it has 4 poles, 2 pairs.
Tomorrow I will do this test to verify. Thank you!

Checked the file and have a few questions.
Luckily for me :).

- you have enabled motor temperature sensing, are you sure that this is not triggering? Maybe temporarily disable it, maybe also disable bus voltage monitoring and over-current protection to be on the safe side
The temperature is measured next to the motor driver.
It rarely rises above 40 ° C (my tests are very short).
But I can deactivate all these safety features momentarily.

- I saw the nucleo power board can be configured to one-shunt and 3-shunt, is that set to 3-shunt?
It is indeed.
All headers are in the correct position for FOC and 3 shunt measurement.

- 15kHz current loop update rate is quite high, don't know if the CPU can handle that. Maybe try :4 ratio from PWM instead of :2
I'll try this and also lower the PWM frequency to 25KHz.
With a ratio of :4, the loop current control is done at 6.25KHz.

- you have enabled current feed forward ("Additional Features and PFC settings"). Possible instability if motor parameters are not perfect, suggest to disable that temporarily
I enabled this feature for testing.
Since I was having poor results, I activated this function to see if the system would react differently.

I do not understand, if everything is set up to work with the encoder (and this sensor is the only feedback), why can I remove the wires and it will continue to work fine.
The encoder reading is certainly not being activated.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #72 on: November 22, 2016, 09:20:01 am »
- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.
I think the motor has 3 pairs of poles, but the seller says it has 4 poles, 2 pairs.
Tomorrow I will do this test to verify. Thank you!
The motor indeed has 2 pairs of poles. There is 2 "snaps" per rev.

I've done some more tests and the result is still the same ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #73 on: November 22, 2016, 09:57:53 am »
Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.
Apparently nothing.
I was hoping the current of my power supply would increase. But that does not happen.

I do not understand, if everything is set up to work with the encoder (and this sensor is the only feedback), why can I remove the wires and it will continue to work fine.
The encoder reading is certainly not being activated.
If you select encoder, then the motor should never be able to spin without it, and the motor referencing must apply current to the motor for that one second that you configured, you must see the motor snapping into a certain position (I think they are slowly ramping up the current though, so it would not be a snap but a 'tightening'). And you must see current consumption increasing. But attention: don't expect the system draw 1 amp when it should generate 1 amp of motor current. The motor doesn't generate shaft power (shaft power = 2*PI * M * n, and n is zero), so an ideal system would not consume input power. It only does because of resistive / switching losses.

Something must be going horribly wrong. I can only see the build system and project setup as a possible root cause here (unless ST has messed up evrything in ver 4.3).

I suggest to debug the code and see if the right code is being executed. First step into MCTasks.c / MCboot, and see which lines contain code and which not. See if the encoder object is being initialized (oSpeedSensor[M1]). If that is okay, run the remote control and set a breakpoint in the large case switch, in case "ALIGNMENT". Trigger the alignment procedure, and you should arrive at the breakpoint. If that is the case, then you can check the values that are written into the IqdRef struct, the qI_Component2 element must contain increasingly large values.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #74 on: November 22, 2016, 10:04:52 am »
Wait ... on file MCTasks.c, can you explain the logic to this?  :o

Code: [Select]
#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.
« Last Edit: November 22, 2016, 10:09:26 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #75 on: November 22, 2016, 10:15:06 am »
Wait ... on file MCTasks.c, can you explain the logic to this?  :o

Code: [Select]
#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.
The oVSS_M1 object is used during alignment. This is a "virtual" rotor feedback sensor, which they use to "inject" a certain measured rotor angle. If they, for example, set this to 90°, and apply motor current, then this will cause the motor to snap into that angle.

The important code that needs to be executed is for example

(line 550)
  oSpeedSensor[M1] = (CSPD)ENC_NewObject(&SpeednPosFdbkParamsM1,&ENCParamsM1); /* speed sensor STO, ENC, HALL xNew and xParamsM1*/
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #76 on: November 22, 2016, 10:16:55 am »
Wait ... on file MCTasks.c, can you explain the logic to this?  :o

Code: [Select]
#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.
You can easily check if ENCODER is defined by adding

#ifndef ENCODER
fucked up!
#endif

somewhere in one of the source files ::)
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #77 on: November 22, 2016, 10:20:22 am »
Code: [Select]
unknown type name 'fucked'
You do not know ... but I know it well !!!

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #78 on: November 22, 2016, 10:31:15 am »
Could the project not be including the "Drive parameters.h" file?

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #79 on: November 22, 2016, 10:32:32 am »
Code: [Select]
unknown type name 'fucked'
You do not know ... but I know it well !!!


:-DD
you got a problem with your config/build/project. when i do it here i end up with #define ENCODER in "Drive parameters.h" :o
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #80 on: November 22, 2016, 10:39:30 am »
Could the project not be including the "Drive parameters.h" file?


is there a predefined constant "STM32F30X" in your project settings? There's only one #ifdef that can prevent that ENCODER inclusion, it is in "Parameters conversion.h". Sure you're compiling and flashing the same project as you think? In Germany we say, the devil is a squirrel.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #81 on: November 22, 2016, 10:40:01 am »
But the folder is there!

PS: I do not have in the whole project #include for "Drive parameters.h".
Should not I have #includes for the header files where the #defines are?

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #82 on: November 22, 2016, 10:44:02 am »
But the folder is there!

PS: I do not have in the whole project #include for "Drive parameters.h".
Should not I have #includes for the header files where the #defines are?


It's a bit ugly.
"MCTasks.c" includes "SystemNDriveParams.h"
"SystemNDriveParams.h" includes "Parameters conversion.h"
"Parameters conversion.h" includes "Parameters conversion_F30x.h" (if that "STM32F30X" definition is in your project)
"Parameters conversion_F30x.h" includes "Drive parameters.h"
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #83 on: November 22, 2016, 11:31:07 am »
When I compile the program, it does not see the config files.

Now I'm sure.
But I do not know how to solve ...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #84 on: November 22, 2016, 12:24:35 pm »
The eclipse is not working well ... but the encoder is declared.

I put this at the end of the file "MCTasks.c".
The message appears on the console.

Code: [Select]
#ifdef ENCODER
#warning "encoder declared!!!"
#endif

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #85 on: November 22, 2016, 04:04:26 pm »
I think I've already solved the problem.
Now I'm having trouble getting the motor in rotation ...
The calibration values are not right, because I've changed Fpwm and everything else.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #86 on: November 22, 2016, 04:39:00 pm »
I think I've already solved the problem.
Now I'm having trouble getting the motor in rotation ...
The calibration values are not right, because I've changed Fpwm and everything else.
great!
what happens now?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #87 on: November 22, 2016, 04:58:06 pm »
great!
what happens now?

Now I'm having lots of feedback faults...

« Last Edit: November 22, 2016, 05:59:11 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #88 on: November 22, 2016, 05:09:51 pm »
Looks like the motor was making an acceleration ramp and then it stopped ...  :-//
« Last Edit: November 22, 2016, 05:59:49 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #89 on: November 22, 2016, 05:58:19 pm »
Now I am actually using the encoder!

But I still have problems.

When I do "encoder align" the current rises to 100mA and the rotor moves a bit.
Then I start the motor and the rotor starts to spin. The rotor rotates about 2/3 times and stops. The current rises to 530mA.
If I do not do "encoder align" the rotor never rotates and the current immediately rises to 530mA.


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #90 on: November 22, 2016, 06:18:07 pm »
great!
what happens now?

Now I'm having lots of feedback faults...


is this issue solved? I see that the motor stopped with a speed sensor error. This means that the library code that runs the encoder has detected a problem. I have checked the code, the only situation in this is signaled is a timer overflow. This happens at veeery slow speed, sub rpm, and permanent standstill. (In a robotic application, standstill is a normal situation, so this should not cause an error. Maybe an issue to solve later...)
« Last Edit: November 22, 2016, 06:32:14 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #91 on: November 22, 2016, 06:35:19 pm »
is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.

But I'm not getting the rotor to rotate more than 2/3 times ...


Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?
« Last Edit: November 22, 2016, 06:38:56 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #92 on: November 22, 2016, 06:39:45 pm »
Now I am actually using the encoder!

But I still have problems.

When I do "encoder align" the current rises to 100mA and the rotor moves a bit.
Then I start the motor and the rotor starts to spin. The rotor rotates about 2/3 times and stops. The current rises to 530mA.
If I do not do "encoder align" the rotor never rotates and the current immediately rises to 530mA.


Do you mean motor phase current or supply current? Please check the current Iq during encoder alignment. Does it rise to 1.5A (or the value you set in the startup parameters)?

Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #93 on: November 22, 2016, 06:40:46 pm »
is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.

But I'm not getting the rotor to rotate more than 2/3 times ...


Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?
I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #94 on: November 22, 2016, 06:44:40 pm »
Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?
I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.

Yes, I am not configuring the secondary sensor.

It was just a question.
Basically the controller will always use the main sensor?
Is there a time when the controller makes the switch?
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #95 on: November 22, 2016, 06:49:30 pm »
is this issue solved?

It happens less.
Once in a while it goes fault again.
But okay, there is not much problem.
We can solve it after configuring everything to use the encoder.
Could be a problem with the encoder signals, maybe they pick up noise from the motor phases. You can try a shielded cable, or add more filter capacitance to GND on the nucleo power board.
For a series design I recommend to use differential signaling.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #96 on: November 22, 2016, 06:52:29 pm »
Some doubts:
When is the primary and secondary sensor used?
When does the controller stop using the primary sensor and start using the secondary sensor? And vice versa?
I thought that you were not configuring a secondary sensor? In this case, the software sticks to the primary.

Yes, I am not configuring the secondary sensor.

It was just a question.
Basically the controller will always use the main sensor?
Is there a time when the controller makes the switch?
If primary=encoder and secondary=null, the controller will use the encoder after alignment. I do not know how it should behave, if alignment has not been executed. Probably it depends on your luck. If the physical rotor angle is null when the software starts up, then you could run the motor without alignment.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #97 on: November 22, 2016, 07:25:33 pm »
Do you mean motor phase current or supply current? Please check the current Iq during encoder alignment. Does it rise to 1.5A (or the value you set in the startup parameters)?
These values are shown by power supply.

The alignment lasts approx 700mS. I do not know what is the Iq to Vout ratio of the DAC. But I measured a peak of 0.5V (2.15V - 1.65V).
I have configured it for 1A.




Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.
I took a picture of the oscilloscope.
I had to put the controller at zero speed to be able to rotate the rotor manually.
The DAC outputs (in this version) only come into operation after make "start motor.




Could be a problem with the encoder signals, maybe they pick up noise from the motor phases. You can try a shielded cable, or add more filter capacitance to GND on the nucleo power board.
For a series design I recommend to use differential signaling.
Noted!


If primary=encoder and secondary=null, the controller will use the encoder after alignment. I do not know how it should behave, if alignment has not been executed. Probably it depends on your luck. If the physical rotor angle is null when the software starts up, then you could run the motor without alignment.
Thank you.
I was wondering what this exchange between sensors would be like ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #98 on: November 22, 2016, 09:27:45 pm »
The alignment lasts approx 700mS. I do not know what is the Iq to Vout ratio of the DAC. But I measured a peak of 0.5V (2.15V - 1.65V).
I have configured it for 1A.

I have two issues with this picture: (For the next photos, it would be nice to include the timebase and all vertical settings. Guessing 100ms timebase here, right?)
- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)
- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.
Iq voltage conversion should be 0V <--> -max measurable current, 3.3V <--> +max measurable current. STMCWB calculates max readable current of +-3.268A (power stage, current sensing). So +1A would be 1.65V + 1.65V*(1.0A / 3.268A) = 2.15V. It seems like the current controller is reaching that level for a short time, when looking closely at the beginning (~ div 1).

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.

Also put the rotor angle on the screen (measured electrical angle). Turn the motor manually a few turns, is the display consistent (the displayed angle value must be the same every time the shaft repeats a certain orientation)? I suspect that there is still a mismatch between encoder angle measurement and actual angle.
I took a picture of the oscilloscope.
I had to put the controller at zero speed to be able to rotate the rotor manually.
The DAC outputs (in this version) only come into operation after make "start motor.

looks okay. But the objective here is: does the encoder count correctly? If you paint a reference mark on the shaft, and turn it a random number of complete revolutions (fast or slow), and then carefully align to the painted reference mark again, then the shown voltage (or value, if you do it directly in STMCWB) for "measured electrical angle" *must* be identical all the time. Have you checked that? *And* you must see exactly *one* triangle sweep per mechanical revolution. It is not allowed to "lose" one single tick count now and then, because that will put everything out of sync over time.

From the first scope picture, I am concerned that the encoder output may be corrupted. (Magnetic interference? wrong field strength of permanent magnet?)
« Last Edit: November 22, 2016, 09:36:00 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #99 on: November 22, 2016, 11:22:35 pm »
I have two issues with this picture: (For the next photos, it would be nice to include the timebase and all vertical settings. Guessing 100ms timebase here, right?)
You're right. My mistake.
The blue trace represents the current (Iq), the other traces are the encoder outputs.
The vertical scale of the blue trace is visible, the horizontal scale has a timebase of 100mS.

- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)
Yes. I configured the DAC channel to represent the current Iq ...
For about 5/10us it draws a pulse, but then begins to oscillate.

- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.
In fact, after 700mS I should not have any more pulses on the encoder ...
At this point I have no explanation for that. Tomorrow I will test more closely to see if I can find an explanation.

Iq voltage conversion should be 0V <--> -max measurable current, 3.3V <--> +max measurable current. STMCWB calculates max readable current of +-3.268A (power stage, current sensing). So +1A would be 1.65V + 1.65V*(1.0A / 3.268A) = 2.15V. It seems like the current controller is reaching that level for a short time, when looking closely at the beginning (~ div 1).
Oh of course!  :palm:

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.
Okay. I'll repeat the procedure and analyze the results.
The control stabilizes initially, but then oscillates so I'll try adjust the PI values. ;)

looks okay. But the objective here is: does the encoder count correctly? If you paint a reference mark on the shaft, and turn it a random number of complete revolutions (fast or slow), and then carefully align to the painted reference mark again, then the shown voltage (or value, if you do it directly in STMCWB) for "measured electrical angle" *must* be identical all the time. Have you checked that? *And* you must see exactly *one* triangle sweep per mechanical revolution. It is not allowed to "lose" one single tick count now and then, because that will put everything out of sync over time.

From the first scope picture, I am concerned that the encoder output may be corrupted. (Magnetic interference? wrong field strength of permanent magnet?)
Okay. I understand.
I'll check this.
My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.


Thanks for all the help  :-+ :-+
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #100 on: November 23, 2016, 08:34:27 am »
My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.
You can run the motor in control mode "torque", and set Torque ref (iq) to zero.

Thanks for all the help  :-+ :-+
No worries :-)
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #101 on: November 23, 2016, 10:37:22 am »
- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)
Yes. I configured the DAC channel to represent the current Iq ...
For about 5/10us it draws a pulse, but then begins to oscillate.

- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.
In fact, after 700mS I should not have any more pulses on the encoder ...
At this point I have no explanation for that. Tomorrow I will test more closely to see if I can find an explanation.

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.
Okay. I'll repeat the procedure and analyze the results.
The control stabilizes initially, but then oscillates so I'll try adjust the PI values. ;)
I was doing the alignment of the encoder.
The encoder pulses result from a "snap" given by the motor.
In this link you can see a small video that shows the moment of alignment.

https://meocloud.pt/link/ad0461a1-e651-44db-90a3-fefeb67b8227/VID_20161123_094942.3gp/

I've already tried adjusting the PI values of the current control, but I can not see any big differences ...



Detail of the oscillation type during encoder alignment.
This oscillation is caused by the DAC (update values?) because I have the same waveform when it represents the angle. Some kind of "noise".

[EDIT]: The frequency is 30KHz ... the same as the PWM.
So if we reject this signal, the current pulse during the alignment lasts only 7uS :o.




My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.
You can run the motor in control mode "torque", and set Torque ref (iq) to zero.
I really have to check what happens to the encoder!
I followed the procedure that you indicated to you and after 4 mec / rev the encoder was advanced about 45º ...
« Last Edit: November 23, 2016, 10:42:19 am by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #102 on: November 23, 2016, 11:55:39 am »
Wait...

I think I got the motor run with the encoder ...
When I remove the cables, it stops and shows overcurrent failure...

Against all that is written, the encoder is configured with 500ppr.

Well ... let's move forward.

How can I start doing the first calibration of PI gains?
« Last Edit: November 23, 2016, 12:27:47 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #103 on: November 23, 2016, 12:37:56 pm »
The frequency is 30KHz ... the same as the PWM.
So if we reject this signal, the current pulse during the alignment lasts only 7uS :o.
That is the crosstalk that I mentioned earlier, maybe you can also check the encoder signals for "purity". But in your video it seems that the motor has two cables, one for power and one for encoder. These seem to be shielded. Do you have a good connection of both shields to GND?
For the AOUT, I use to add a capacitance in parallel with the probe in such a situation.

I seems like the too short current pulse is a bug in the library, which is not controlling AOUT correctly during the alignment. But the video clearly shows that the alignment works, and it seems to ramp up the current nicely. I have another simple idea how the current loop can easily be verified. You need to tightly fix the motor shaft. Then, in torque mode, start the motor. As soon as you change the Iq value and click on "set references", the current must jump to the new value. You can then tune the gains like I described in an earlier post. Do this at maximum bus voltage, as this voltage is a gain term in the control loop.

I really have to check what happens to the encoder!
I followed the procedure that you indicated to you and after 4 mec / rev the encoder was advanced about 45º ...
Really strange. The encoder part works very well in my designs. But I am using F0 and F4 microcontroller series. For the F3, you found a limitation note in the documentation. I hope that it's not that. Can your scope count pulses? Can you verify that the encoder is configured correctly and produces 512 p/rev as specified? Did you check the cleanness of the input signals? Does adding filter capacitance lower the error? Some questions from my head  :)
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #104 on: November 23, 2016, 12:41:00 pm »
Wait...

I think I got the motor run with the encoder ...
When I remove the cables, it stops and shows overcurrent failure...

Against all that is written, the encoder is configured with 500ppr.

Well ... let's move forward.

How can I start doing the first calibration of PI gains?
good success! Overcurrent failure is still an indication that the current loop is not stable. I didn't see this post while writing my previous one when answering the PI gain adjustment procedure 8)
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #105 on: November 23, 2016, 03:45:33 pm »
I followed your directions.
I calibrated the PI gains. But I still have little current, and so little torque.

For example:
Motor at 1000RPM with the gear box bolted.
Suddenly I lock the shaft with a brake and the current never rises above 300mA.
So my torque is too low. I can easily block the shaft with my hand  :box:.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #106 on: November 23, 2016, 04:15:47 pm »
I followed your directions.
I calibrated the PI gains. But I still have little current, and so little torque.

For example:
Motor at 1000RPM with the gear box bolted.
Suddenly I lock the shaft with a brake and the current never rises above 300mA.
So my torque is too low. I can easily block the shaft with my hand  :box:.
What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #107 on: November 23, 2016, 05:02:19 pm »
What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?

In this image you can see the controller gains.


Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?


[EDIT]:
In torque control was the motor supposed to rotate?

I blocked the motor shaft, but it does not make any force ...
« Last Edit: November 23, 2016, 05:24:41 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #108 on: November 23, 2016, 06:11:15 pm »
Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

The controller is limiting the current to the motor nominal. But it does not match with the values measured by the ammeter ...


Watch this video.
I used a metal piece to lock the motor shaft.

https://meocloud.pt/link/bdcb0756-33a1-4614-ba09-7a00812e2c94/VID_20161123_181502.3gp/
« Last Edit: November 23, 2016, 06:19:33 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #109 on: November 23, 2016, 07:07:25 pm »
What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?

In this image you can see the controller gains.


Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

Looks good! I think that the rubbish before the slope to 1.68A is again some undefined behavior of the library. You are right, 0A should correspond to 1.65V. But what is important in the picture is that there is only very little overshoot after the transition. This shows that you have found good controller gains. We can assume that this part is working now.

[EDIT]:
In torque control was the motor supposed to rotate?

I blocked the motor shaft, but it does not make any force ...
Of course the motor should run. It is torque that makes it accelerate. If the set point is high enough, then it will always rev up into full speed no-load rpm. That 1.68A should definitely be enough.

If the motor does not run, and the encoder feedback is working now, this is what I can think of:
- Had you executed encoder alignment before the test? This is essential after every power-up.
- the actual current is not what the library thinks it is (some conversion error). Don't think that this is the case, if all the other possibilities are ruled out then lets think how that can be checked.
- something is wrong with the encoder alignment. Try putting a value into the Id (flux) field instead (leave Iq at zero). Does the motor produce torque?
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #110 on: November 23, 2016, 07:14:52 pm »
Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

The controller is limiting the current to the motor nominal. But it does not match with the values measured by the ammeter ...


Watch this video.
I used a metal piece to lock the motor shaft.

https://meocloud.pt/link/bdcb0756-33a1-4614-ba09-7a00812e2c94/VID_20161123_181502.3gp/
It is important to understand that you cannot measure the phase current (Iq is the amplitude of that) at the supply input. I had tried to explain that in an earlier post. You can compare the power stage and motor inductance with a switchmode buck regulator. You can have a very high output current, but if you short the output and force it to be zero volts, then the regulator does not produce any output power: P = V * I = 0V * {a lot of current}). And if it has a good efficiency, then it consequently does not draw any power from its input. An ideal buck converter with an ideal inductor could provide thousands of amperes without drawing a milliamp from its input. It is the same for the motor. When it does not rotate, then it does not produce mechanical output power. Then the supply current is small, even if you have 1.68A flowing through the motor inductance(s).

So the supply current that you observe when blocking the motor is perfectly reasonable. The problem is that the motor current does not seem to contribute to torque.
« Last Edit: November 23, 2016, 07:19:11 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #111 on: November 23, 2016, 11:07:13 pm »
- Had you executed encoder alignment before the test? This is essential after every power-up.
Yes. I always do the alignment of the encoder.

- something is wrong with the encoder alignment. Try putting a value into the Id (flux) field instead (leave Iq at zero). Does the motor produce torque?
Tomorrow I'm going to do this test again.
I experimented today and had no torque at the motor shaft.

It is important to understand that you cannot measure the phase current (Iq is the amplitude of that) at the supply input. I had tried to explain that in an earlier post. You can compare the power stage and motor inductance with a switchmode buck regulator. You can have a very high output current, but if you short the output and force it to be zero volts, then the regulator does not produce any output power: P = V * I = 0V * {a lot of current}). And if it has a good efficiency, then it consequently does not draw any power from its input. An ideal buck converter with an ideal inductor could provide thousands of amperes without drawing a milliamp from its input. It is the same for the motor. When it does not rotate, then it does not produce mechanical output power. Then the supply current is small, even if you have 1.68A flowing through the motor inductance(s).
Excellent explanation!
Very good!

So the supply current that you observe when blocking the motor is perfectly reasonable. The problem is that the motor current does not seem to contribute to torque.
In torque mode the motor does not rotate, but in speed mode the motor shaft exerts some force...
Compared to the torque I got on the Renesas board with the same current, it remains low.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #112 on: November 24, 2016, 08:17:15 am »
In torque mode the motor does not rotate, but in speed mode the motor shaft exerts some force...
Compared to the torque I got on the Renesas board with the same current, it remains low.
For me, all this points to encoder alignment problems. In speed mode, the speed controller generates a command for the torque controller. In torque mode, you do this yourself. Why should that make a difference to the generated torque... I guess that the encoder alignment is wrong, and randomly you get little torque, or none. As if it is 90 degrees out of phase.

p.s. I'm sure that you are very close to reaching the goal ;)

p.p.s. if you manage today to bring full torque to the shaft, and continue working with a lab supply, I strongly suggest that you add overvoltage protection to the DC bus, like a beefy 28V zener diode. Otherwise, you'll likely blow the circuit, and possibly your lab supply, when first attempting a deceleration from full rpm to zero with full torque. The regenerated electrical energy will pump up your DC bus capacitors.

p.p.p.s: another question. How do you plan to control the motor in your system? Do you want to keep the entire ST software as it is and send commands via RS232 like STMCWB is doing, or do you plan to implement your own control software? If the second, then I can compile you an extract of how I do it, and the library primitives and structures you need for that.
« Last Edit: November 24, 2016, 09:05:55 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #113 on: November 24, 2016, 10:26:22 am »
For me, all this points to encoder alignment problems. In speed mode, the speed controller generates a command for the torque controller. In torque mode, you do this yourself. Why should that make a difference to the generated torque... I guess that the encoder alignment is wrong, and randomly you get little torque, or none. As if it is 90 degrees out of phase.
You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

p.s. I'm sure that you are very close to reaching the goal ;)
Thanks for your help !!

p.p.s. if you manage today to bring full torque to the shaft, and continue working with a lab supply, I strongly suggest that you add overvoltage protection to the DC bus, like a beefy 28V zener diode. Otherwise, you'll likely blow the circuit, and possibly your lab supply, when first attempting a deceleration from full rpm to zero with full torque. The regenerated electrical energy will pump up your DC bus capacitors.
The EVB I am using now does not support more than 2.8A. But in the future, when I move to a circuit that has more power, I'll take that into account. Thank you.

p.p.p.s: another question. How do you plan to control the motor in your system? Do you want to keep the entire ST software as it is and send commands via RS232 like STMCWB is doing, or do you plan to implement your own control software? If the second, then I can compile you an extract of how I do it, and the library primitives and structures you need for that.
In a future design I want to create my communication protocol and leave the original as well.
I am going to use a selection jumper. If the jumper is on, then the firmware will use all the ST functions to communicate with the STMCWB. If the jumper is off, the firmware will use my protocol, with simpler frames: set speed, set direction, currents, checksum and little else.
If you could show me how you did it would be great!

You deserve 2 of the best Portuguese beers!  :popcorn:  ;D
« Last Edit: November 24, 2016, 10:37:11 am by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #114 on: November 24, 2016, 11:59:15 am »
You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...
Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on.  :)
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #115 on: November 24, 2016, 12:26:57 pm »
You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...
Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on.  :)
what do you mean by that?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #116 on: November 24, 2016, 12:41:48 pm »
You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...
Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on.  :)
what do you mean by that?
I was trying to use 0.5A (Iq = 5013).
Now I changed the value to 1A (Iq = 10026) and the motor runs ease ..

New question:
All the settings I made are 4000RPM max.
But the STMCWB does not let rise above 2500RPM. Will there any parameters that I am not changing?
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #117 on: November 24, 2016, 12:47:41 pm »
You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...
Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on.  :)
what do you mean by that?
I was trying to use 0.5A (Iq = 5013).
Now I changed the value to 1A (Iq = 10026) and the motor runs ease ..

New question:
All the settings I made are 4000RPM max.
But the STMCWB does not let rise above 2500RPM. Will there any parameters that I am not changing?
when you stick to torque mode for now, there is no speed limit. have you tried setting Id instead of Iq? if that produces more torque that would be a clear indication of encoder alignment problems. btw: do the alignment procedure at max possible current, this will let the motor lock more accurately.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #118 on: November 24, 2016, 02:37:26 pm »
For the motor to rotate in the same direction, Id = -Iq. It's normal?

Clockwise rotation:
Iq = 10026, Id = 0

Counterclockwise rotation:
Iq = 0, Id = 10026

Clockwise rotation:
Iq = 0, Id = -10026
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #119 on: November 24, 2016, 03:26:30 pm »
For the motor to rotate in the same direction, Id = -Iq. It's normal?

Clockwise rotation:
Iq = 10026, Id = 0

Counterclockwise rotation:
Iq = 0, Id = 10026

Clockwise rotation:
Iq = 0, Id = -10026
Id would not contribute to torque at all if encoder alignment was good. how much torque do you have in these situations? that is most interesting for me.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #120 on: November 24, 2016, 03:40:01 pm »
I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #121 on: November 24, 2016, 04:30:18 pm »
I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).
That behavior doesn't really make sense to me. I really would like to know which combination produces good torque, and which one produces less or none.

I have assembled something for you based on my working solution, I hope it does not contain too many errors.

It also contains a working encoder alignment procedure, maybe you want to try this out.

Code: [Select]
#include "PWMnCurrFdbkClass.h"
#include "SpeednTorqCtrlClass.h"
#include "SpeednPosFdbkPrivate.h"
#include "MCTuningClass.h"
#include "MCInterfaceClass.h"
#include "MCTasks.h"
#include "Parameters conversion.h"
#include "Timebase.h"
#include "UITask.h"
#include "MCLibraryISRPriorityConf.h"

#define NBR_OF_MOTORS 1
extern FOCVars_t FOCVars[NBR_OF_MOTORS];
extern CSTC oSTC[NBR_OF_MOTORS];
extern CPI oPIDSpeed[NBR_OF_MOTORS],oPIDIq[NBR_OF_MOTORS],oPIDId[NBR_OF_MOTORS];
extern CPWMC oCurrSensor[NBR_OF_MOTORS];
extern CSPD oSpeedSensor[NBR_OF_MOTORS];
extern CSPD oVSS_M1;
extern CUI oDAC;
CMCI oMCI[MC_NUM];
CMCT oMCT[MC_NUM];

#define FIRMWARE_VERS "STM32 FOC SDK\0Ver.4.0.B"
const char s_fwVer[32] = FIRMWARE_VERS;

#define PHASECURRENT_FTOI( current ) ((int16_t)( current * (65536.0f * (float)(AMPLIFICATION_GAIN / MCU_SUPPLY_VOLTAGE) ) ))
#define VELOCITY_FTOI( velocity ) ((int16_t)( velocity / (0.1f * 60.0f) ))

volatile uint32_t time = 0;
bool bReferenced=FALSE;

void wait( float delay )
{
  uint32_t then;
 
  then = time + (uint32_t)(delay * (float)SYS_TICK_FREQUENCY);

  while( (int32_t)(then - time) > 0 );
}

int main(void)
{
  // Enable interrupt preemption via priority
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_3);
 
  // MCInterface and MCTuning boot
  MCboot(oMCI,oMCT);

  // Systick configuration
  SysTick_Config( (SystemCoreClock) / SYS_TICK_FREQUENCY );
  NVIC_SetPriority(SysTick_IRQn, SYSTICK_PRIORITY);
  NVIC_SetPriority(PendSV_IRQn, PENDSV_PRIORITY);
 
  // Initialize DAC output
  UI_SetDAC(oDAC, DAC_CH0, MC_PROTOCOL_REG_I_Q);
 
  // Assign virtual speed sensor (electrical angle = 0)
  SPD_Clear(oSpeedSensor[M1]);
  SPD_Clear(oVSS_M1);
  STC_SetSpeedSensor(oSTC[M1],oVSS_M1);

  // Initialize to zero torque/flux
  FOCVars[M1].Iqdref.qI_Component1 = 0; // torque, Iq
  FOCVars[M1].Iqdref.qI_Component2 = 0; // flux, Id

  // Current sensor calibration
  PWMC_CurrentReadingCalibr(oCurrSensor[M1],CRC_START);
  while( !PWMC_CurrentReadingCalibr(oCurrSensor[M1],CRC_EXEC) );

  // Enable power stage
  PWMC_SwitchOnPWM(oCurrSensor[M1]);

/*
  // current controller tuning
  while(1)
  {
    FOCVars[M1].Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );
    wait( 0.007f );
    FOCVars[M1].Iqdref.qI_Component1 = 0;
    wait( 0.04f );
  }
*/

  // Apply 2A current for 1sec for alignment
  FOCVars[M1].Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );
  wait( 1.0f );
  FOCVars[M1].Iqdref.qI_Component1 = 0;

  // Set encoder angle
  SPD_SetMecAngle( oSpeedSensor[M1], (65536/4) / POLE_PAIR_NUM );

  // Switch to encoder feedback
  SPD_Clear(oSpeedSensor[M1]);
  STC_SetSpeedSensor(oSTC[M1],oSpeedSensor[M1]);
  bReferenced = TRUE;

  keep_doing_something();
}

// This function must be called at SYS_TICK_FREQUENCY rate via interrupt - add it to
// function TB_Scheduler() in file Timebase.c.
void Main_Scheduler(void)
{
  int16_t wAux;
  int16_t i16CurrentVelocity;
  int16_t i16CommandedVelocity;
  int16_t i16MotorCurrentLimit;
  int16_t i16MotorCurrent;

  // Update DAC output
  UI_DACExec((CUI)oDAC);

  // Update motor velocity measurement
  SPD_CalcAvrgMecSpeed01Hz(oSpeedSensor[M1],&wAux);
  i16CurrentVelocity = SPD_GetAvrgMecSpeed01Hz(oSpeedSensor[M1]);

  // Prevent motor activation while not referenced
  if( !bReferenced )
  {
    return;
  }
 
  // Set commanded velocity
  i16CommandedVelocity = VELOCITY_FTOI( 1000.0f );

/*
  // velocity controller tuning
  {
    static int k;
    k++;
    if(k%1000 < 500)
    {
      i16CommandedVelocity = PHASECURRENT_FTOI( 3500.0f );
    }
    else
    {
      i16CommandedVelocity = PHASECURRENT_FTOI( 2500.0f );
    }
  }
*/

  // Velocity control with torque limitation,
  // the PI controller uses the speed PI parameters from STMCWB
  i16MotorCurrentLimit = PHASECURRENT_FTOI( 2.0f );
  PI_SetUpperOutputLimit( oPIDSpeed[M1], +i16MotorCurrentLimit );
  PI_SetLowerOutputLimit( oPIDSpeed[M1], -i16MotorCurrentLimit );
  i16MotorCurrent = PI_Controller( oPIDSpeed[M1], (int32_t)(i16CommandedVelocity - i16CurrentVelocity) );
  FOCVars[M1].Iqdref.qI_Component1 = i16MotorCurrent;
}
« Last Edit: November 24, 2016, 04:46:10 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #122 on: November 24, 2016, 04:32:11 pm »
I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).
The motor should not run at all with Id > 0. Something's wrong with the encoder alignment! How much torque do you have with Iq=10000 Id=0, how much do you have with Iq=0 Id=10000?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #123 on: November 24, 2016, 05:29:44 pm »
The motor should not run at all with Id > 0. Something's wrong with the encoder alignment! How much torque do you have with Iq=10000 Id=0, how much do you have with Iq=0 Id=10000?
For now I can not put Iq=0 and the motor continues to run.
But with this sequence, I can get the motor to rotate ...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #124 on: November 24, 2016, 05:41:55 pm »
That behavior doesn't really make sense to me. I really would like to know which combination produces good torque, and which one produces less or none.

I have assembled something for you based on my working solution, I hope it does not contain too many errors.

It also contains a working encoder alignment procedure, maybe you want to try this out.

Thank you very much.  :-+ :-+
Now I will study the serial communication using the SDK ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #125 on: November 24, 2016, 06:51:00 pm »
The motor should not run at all with Id > 0. Something's wrong with the encoder alignment! How much torque do you have with Iq=10000 Id=0, how much do you have with Iq=0 Id=10000?
For now I can not put Iq=0 and the motor continues to run.
But with this sequence, I can get the motor to rotate ...

That means to me that the encoder alignment produces random results...
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #126 on: November 25, 2016, 12:15:09 pm »
I'm terrible working with this.

Can I create a new USART_NewObject (pUSARTParams_t pUSARTParams) to implement my protocol?
They have repeated interrupt routines etc ... it's a bit confusing for me. But I've done very little with object-oriented programming ...
Is different from base C ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #127 on: November 25, 2016, 12:24:35 pm »
I'm terrible working with this.

Can I create a new USART_NewObject (pUSARTParams_t pUSARTParams) to implement my protocol?
They have repeated interrupt routines etc ... it's a bit confusing for me. But I've done very little with object-oriented programming ...
Is different from base C ...
i can on the road, can send you a uart example when at home.check out the ST HAL examples. you need to switch off the serial comms in STMCWB, dont use the FOC library for your UART stuff.
« Last Edit: November 25, 2016, 12:26:19 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #128 on: November 25, 2016, 12:33:02 pm »
i can on the road, can send you a uart example when at home.check out the ST HAL examples. you need to switch off the serial comms in STMCWB, dont use the FOC library for your UART stuff.

OK.

I usually use the HAL libs. That's how I usually use ST MCUs.
But in this case it's tricky because I wanted to keep the original code and just change the protocol with a jumper.
When the jumper is ON the protocol used is the STMCWB, when the jumper is OFF the protocol used is mine.

But they have the functions of USART very scattered .. I do not like. To make changes of these I have to invent a lot.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #129 on: November 25, 2016, 02:17:01 pm »
i can on the road, can send you a uart example when at home.check out the ST HAL examples. you need to switch off the serial comms in STMCWB, dont use the FOC library for your UART stuff.

OK.

I usually use the HAL libs. That's how I usually use ST MCUs.
But in this case it's tricky because I wanted to keep the original code and just change the protocol with a jumper.
When the jumper is ON the protocol used is the STMCWB, when the jumper is OFF the protocol used is mine.

But they have the functions of USART very scattered .. I do not like. To make changes of these I have to invent a lot.
do you need to do "hot" switching, or is it ok to decide at boot time?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #130 on: November 25, 2016, 03:40:16 pm »
do you need to do "hot" switching, or is it ok to decide at boot time?
During boot it is ok.
It's just to be able to do the test easily without having to program.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #131 on: November 25, 2016, 03:48:18 pm »
In my head, I just have to change the IRQ number to use an IRQ function created by me.
With this function I should be able to do what I want ...

But I do not understand what is the IRQ number (in this case is the number 0) and how do I create mine.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #132 on: November 25, 2016, 05:14:44 pm »
In my head, I just have to change the IRQ number to use an IRQ function created by me.
With this function I should be able to do what I want ...

But I do not understand what is the IRQ number (in this case is the number 0) and how do I create mine.


Thats not the way it would work. I haven't tried, but I think this way will work:

1. enable serial comms in STMCWB
2. a switch in stm32f10x_MC_it.c, USART_IRQHandler(), rerouting all interrupts to your specific function. The function USART_IRQHandler() is an alias (per #define) and is the interrupt handler for the UART that is selected with STMCWB, one of USART1_IRQHandler(), USART2_IRQHandler(), USART3_IRQHandler().
3. a switch in main(), calling UI_TaskInit in a different way when you want to claim the UART:   UI_TaskInit(UI_INIT_CFG & ~OPT_COM,wConfig,MC_NUM,oMCI,oMCT,s_fwVer);
4. do your own serial GPIO and UART initialization in case, like this (careful, this is code for STM32F103xB):

Code: [Select]
  GPIO_InitTypeDef GPIO_InitStructure;
  USART_InitTypeDef USART_InitStructure;
  // Init USART1 at pins PB6 (TX) and PB7 (RX)
  RCC_APB2PeriphClockCmd( RCC_APB2Periph_USART1, (FunctionalState)ENABLE );
  USART_InitStructure.USART_BaudRate   = 115200;
  USART_InitStructure.USART_WordLength = USART_WordLength_8b;
  USART_InitStructure.USART_StopBits   = USART_StopBits_1;
  USART_InitStructure.USART_Parity     = USART_Parity_No;
  USART_InitStructure.USART_Mode       = USART_Mode_Tx | USART_Mode_Rx;
  USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
  USART_Init( USART1, &USART_InitStructure );
  GPIO_InitStructure.GPIO_Pin   = GPIO_TXD | GPIO_RXD;
  GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_AF_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_Init( GPIOB, &GPIO_InitStructure );
  GPIO_PinRemapConfig(GPIO_Remap_USART1, (FunctionalState)ENABLE);
  USART_Cmd( USART1, (FunctionalState)ENABLE );
  USART_ITConfig( USART1, USART_IT_RXNE ..., (FunctionalState)ENABLE);

I would also use DMA to further reduce UART interrupt traffic.
« Last Edit: November 25, 2016, 05:18:25 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #133 on: November 25, 2016, 05:52:12 pm »
I was already debugging and realizing how their communication works.
They have many layers where they format the frame before sending.
I was do the same scheme (procedure) that you suggest.
Then I'm more sure of what to do.

Thank you!  :-+ :-+
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #134 on: November 30, 2016, 12:21:14 pm »
I have already been able to create my own communication protocol and my functions. Thank you tatus1969 for all the suport.

But meanwhile came a new EVB to test my motor in full power, the STEVAL-SPIN3201.

I changed workspace (to STM32F0xx), compiled the MC Lib, put everything original (main file, etc..) but the compiler is generating too large binary files for me to program the STSPIN32F0 (32Kb).

I already reported it to ST (using the forum and online suport), but I continue without an explanation ...



Let's start a new battle ...  |O |O
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #135 on: December 01, 2016, 07:09:48 am »
the FOC lib is quite large, it would surprise me if it would fit in 32k including your application code. i would say, wrong EVB. i can check how much code space i use.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #136 on: December 01, 2016, 11:41:42 am »
the FOC lib is quite large, it would surprise me if it would fit in 32k including your application code. i would say, wrong EVB. i can check how much code space i use.
But they say it should work. In STMCWB this board appears in example ...
The code I was generating for the P-NUCLEO-IHM001 was about 38Kb, larger than the space on the STSPIN32F0.
They must have created some limitations, so that the code is reduced ...

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #137 on: December 01, 2016, 05:56:51 pm »
I think that you'll not get happy with this EVB. Here is a statistic of my code as promised. Total=32512, will just fit (?).

Code: [Select]
Module ro_code ro_data rw_data so_sum
main.o 6364 169 246 6533
xprintffull.o 4186 0 0 4186
STO_CORDIC_SpeednPosFdbkClass.o 2776 0 337 2776
ICS_LM1_PWMnCurrFdbkClass.o 2200 0 13 2200
MCTasks.o 1420 552 96 1972
stm32f10x_tim.o 1464 0 0 1464
MC_Math.o 592 512 0 1104
PWMnCurrFdbkClass.o 782 0 97 782
stm32f10x_adc.o 710 0 0 710
VirtualSpeedSensor_SpeednPosFdbkClass.o 614 0 25 614
DblDiv.o 582 0 0 582
stm32f10x_gpio.o 520 0 0 520
stm32f10x_rcc.o 444 20 20 464
startup_stm32f10x_md.o 460 0 0 460
stm32f10x_i2c.o 434 0 0 434
DblMul.o 418 0 0 418
stm32f10x_dma.o 412 0 0 412
DblSub.o 384 0 0 384
PIRegulatorClass.o 364 0 225 364
stm32f10x_usart.o 294 0 0 294
xdscale.o 268 0 0 268
system_stm32f10x.o 252 4 4 256
FltDiv.o 252 0 0 252
I64DivMod.o 238 0 0 238
FltSub.o 230 0 0 230
PQD_MotorPowerMeasurementClass.o 228 0 13 228
FltMul.o 216 0 0 216
DblAdd.o 212 0 0 212
localeconv.o 108 80 80 188
RevupCtrlClass.o 184 0 125 184
xxmemxmalloc.o 176 0 8 176
SpeednTorqCtrlClass.o 172 0 33 172
CircleLimitationClass.o 168 0 5 168
StateMachineClass.o 134 0 13 134
Virtual_TemperatureSensorClass.o 134 0 5 134
FltAdd.o 132 0 0 132
xxmemxfree.o 128 0 0 128
MotorPowerMeasurementClass.o 124 0 281 124
Virtual_BusVoltageSensorClass.o 122 0 5 122
misc.o 120 0 0 120
ABImemcpy.o 118 0 0 118
SpeednPosFdbkClass.o 114 0 133 114
MCInterfaceClass.o 102 0 65 102
xencoding_sb.o 96 0 0 96
BusVoltageSensorClass.o 94 0 29 94
DblToI32.o 88 0 0 88
memchr.o 88 0 0 88
MCTuningClass.o 78 0 161 78
FltToDbl.o 78 0 0 78
TemperatureSensorClass.o 72 0 29 72
FltToS32.o 68 0 0 68
xdnorm.o 66 0 0 66
strlen.o 54 0 0 54
Gaps 52 2 0 54
Timebase.o 52 0 4 52
sprintf.o 52 0 0 52
I32ToFlt.o 50 0 0 50
stm32f10x_MC_it.o 48 0 0 48
I32ToDbl.o 48 0 0 48
DblCmpGe.o 46 0 0 46
DblCmpLe.o 46 0 0 46
copy_init3.o 46 0 0 46
MCIRQHandlerClass.o 40 0 16 40
xgetmemchunk.o 40 0 4 40
data_init3.o 40 0 0 40
Linker_created 0 39 4096 39
stm32f10x_dbgmcu.o 36 0 0 36
FltCmpGe.o 36 0 0 36
FltCmpLe.o 36 0 0 36
FltToU32.o 36 0 0 36
zero_init3.o 34 0 0 34
xmbtowc.o 32 0 0 32
FltCmpEq.o 28 0 0 28
xwctomb.o 26 0 0 26
stm32f10x_it.o 24 0 0 24
cmain.o 22 0 0 22
strchr.o 22 0 0 22
setlocale.o 20 0 116 20
exit.o 20 0 0 20
div.o 14 0 0 14
cstartup_M.o 12 0 0 12
xmbcurmax.o 10 0 0 10
xsprout.o 10 0 0 10
cexit.o 10 0 0 10
exit.o 4 0 0 4
low_level_init.o 4 0 0 4
xtls.o 2 0 0 2
I64DivZer.o 2 0 0 2
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #138 on: December 02, 2016, 09:14:40 am »
I think that you'll not get happy with this EVB. Here is a statistic of my code as promised. Total=32512, will just fit (?).
I don't believe.

But it is normal for the manufacturer to say that this SoC is fully compatible with the SDK, but then everything indicates that it will not work ??
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #139 on: December 02, 2016, 09:55:21 am »
I've been compiling for the STM32F030 and it ran 42056. But this MCU family, the STM32F030, has a flash of up to 128Kb, which is no problem.

The STM32F031, inside the STSPIN32F0, only have flash memory up to 32Kb.

[EDIT 1]
In document RN0085, it says that the STM32F030C6 is supported, but only has 32Kb ...
In fact, all the STM32FxxxC6 have 32Kb.



« Last Edit: December 02, 2016, 10:13:29 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #140 on: December 02, 2016, 04:50:26 pm »
I think that you'll not get happy with this EVB. Here is a statistic of my code as promised. Total=32512, will just fit (?).
I don't believe.

But it is normal for the manufacturer to say that this SoC is fully compatible with the SDK, but then everything indicates that it will not work ??
i am curious about the response from ST 8) my guess: marketing bubble, nobody tested it
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #141 on: December 02, 2016, 04:57:15 pm »
I think that you'll not get happy with this EVB. Here is a statistic of my code as promised. Total=32512, will just fit (?).
I don't believe.

But it is normal for the manufacturer to say that this SoC is fully compatible with the SDK, but then everything indicates that it will not work ??
i am curious about the response from ST 8) my guess: marketing bubble, nobody tested it

It is curious, because in fact they have created "projects" to use with this SoC ... but apparently they did not test.
This Soc was ideal for my application because I have some space limitations.

The ST forum is under maintenance until December 5th.
Through online support, I can not get any answers so far.
So it's a bit complicated to move forward ...  :-//
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #143 on: December 02, 2016, 06:10:08 pm »
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #144 on: December 03, 2016, 10:18:14 am »
This Soc was ideal for my application because I have some space limitations.
That's a good idea of ST to include the gate drivers. But it seems to be brand new, so you'll probably be one of the "external" beta testers. I usually try to avoid this. How about packing two motor controllers in a larger STM32F4, and add six gate drivers in 4x4 WSON each? Could be similar in size.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #145 on: December 05, 2016, 09:38:33 am »
What a crap ...  :palm:
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #146 on: December 06, 2016, 11:55:13 am »
I am designing a PCB to use the STM32F302R8 and drive my motor in full power.

I still await ST official response about STSPINF0 ....
« Last Edit: December 06, 2016, 11:58:40 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #147 on: December 10, 2016, 01:20:52 pm »
I am designing a PCB to use the STM32F302R8 and drive my motor in full power.

I still await ST official response about STSPINF0 ....
isn't that one a bit oversized? AFAIK the FOC library neither uses the DSP nor the FPU (it's all based on fixpoint integer arithmetic). I started with a STM32F405, but then went down to a STM32F103CBU6 in my current design, small, cheap and more than enough for the task.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #148 on: December 12, 2016, 09:27:36 am »
isn't that one a bit oversized? AFAIK the FOC library neither uses the DSP nor the FPU (it's all based on fixpoint integer arithmetic). I started with a STM32F405, but then went down to a STM32F103CBU6 in my current design, small, cheap and more than enough for the task.

Yes it is oversized.
But as I'm late so the first board stays like this...  :phew: :phew:
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #149 on: January 25, 2017, 06:31:31 pm »
Overvoltage starts to be a problem.

I came back to see your recommendation to use a zener diode.
When the motor decelerate, the VBus rises to 35V.

One zener diode of 27V, 5W should be enough to control, right?

As a precaution I will use a 24V TVS as well.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #150 on: January 25, 2017, 10:48:33 pm »
Overvoltage starts to be a problem.

I came back to see your recommendation to use a zener diode.
When the motor decelerate, the VBus rises to 35V.

One zener diode of 27V, 5W should be enough to control, right?

As a precaution I will use a 24V TVS as well.
it depends on the mass that you are decelerating. calculate the stored energy of the rotating mass at full speed, that gives you an estimate of how beefy your zener or tvs needs to be. larger bus capacitance also helps.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #151 on: January 26, 2017, 11:07:13 am »
I've been thinking better and I'm going to use a zener to close a MOSFET and dissipate everything in a power resistor ...

I will have to draw the PCB again to support this ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #152 on: January 26, 2017, 07:48:26 pm »
I've been thinking better and I'm going to use a zener to close a MOSFET and dissipate everything in a power resistor ...

I will have to draw the PCB again to support this ...
didn't you say that your system was battery powered? should only be a problem when you power it from a psu. maybe simulate your circuit, as you describe it sounds like you will be operating the transistor in its linear and dissipative region.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #153 on: January 27, 2017, 10:02:48 am »
Yes, you are right.
But apparently this is going to take many bench tests using the bench power supply ...
So by prevention, and since I have free space on the PCB, I'm going to set up this circuit.

When Vbus rises above 29V (Vzener + Vth) the MOSFET closes and dissipates the energy in excess in a resistor of 56R (35W D2PAK).
These events should be sporadic so the heat should not be a big problem.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #154 on: January 27, 2017, 12:35:30 pm »
Yes, you are right.
But apparently this is going to take many bench tests using the bench power supply ...
So by prevention, and since I have free space on the PCB, I'm going to set up this circuit.

When Vbus rises above 29V (Vzener + Vth) the MOSFET closes and dissipates the energy in excess in a resistor of 56R (35W D2PAK).
These events should be sporadic so the heat should not be a big problem.


The circuit will not work as intended, because you'll operate the transistor in its linear region, it will not saturate. The transistor will dissipate the energy, not the resistor. I suggest to remove/short the resistor, and use a larger D(2)PAK MOSFET instead, and let that handle the heat.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #155 on: January 27, 2017, 02:47:56 pm »
In my simulation practically the whole power is dissipated in the resistance ...
I'm assuming that the voltage increase is fast (~10mS).

In the chart:
Red Line - Vbus
Green Line - Energy dissipated by resistance
Blue Line - DISSIPATED MOSFET (~ 4W).


 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #156 on: January 27, 2017, 03:21:44 pm »
R(j-a) = 120ºC/W

4W = 360ºC

This is going to crack  :palm:

Everything will depend on how long the MOSFET will be ON... if the generated energy dissipates fast, then it will work, but if too much power is generated, it will warm up!

« Last Edit: January 27, 2017, 03:51:33 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #157 on: January 27, 2017, 07:36:32 pm »
In my simulation practically the whole power is dissipated in the resistance ...
I'm assuming that the voltage increase is fast (~10mS).

In the chart:
Red Line - Vbus
Green Line - Energy dissipated by resistance
Blue Line - DISSIPATED MOSFET (~ 4W).



It seems that your simulator doesn't handle the rising edge properly. There's MOSFET dissipation there as well (attached pic). Your solution will also work as it only has to dissipate the inertial rotor energy, and that is limited. But how about using a GPIO pin to control the MOSFET, and use the bus voltage ADC and some interrupt driven code to form a comparator that enables the MOSFET when Vbus > Vthreshold?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #158 on: February 14, 2017, 06:32:39 pm »
I do not know what's happening now...

Now I have the following problem: everything ready to work with the encoder, align the motor (it moves!), but when I click start it does not run. Tremble 1 second and then do nothing else.

What could be the problem this time?
The encoder is correctly set to 500 ppr...

In sensorless the motor rotates ... so the electronics is fine.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #159 on: February 14, 2017, 07:17:02 pm »
maybe wrong turning direction? what happens if you swap two motor phases?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #160 on: February 14, 2017, 11:26:42 pm »
I have not done this yet, but in the encoder setup I already tested with "reverse". The result is the same ...

Reverse direction in the encoder setup (in the configurator) should not work?

The encoder signal is perfect ... but it looks like the control will not start. On the other hand I do not get any error message ...

Stupidly, I just changed the PCB ... the entire circuit is the same as I've tested and put it into proper operation  :-// :-//

The motor has the numbered phases (1 2 3), which I connected to (U V W).


EDIT:
maybe wrong turning direction? what happens if you swap two motor phases?

In that case, would the sensorless control work?
It's that the engine runs on sensorless ... but with the encoder I'm not lucky.
« Last Edit: February 14, 2017, 11:32:04 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #161 on: February 15, 2017, 06:42:26 am »
I have not done this yet, but in the encoder setup I already tested with "reverse". The result is the same ...

Reverse direction in the encoder setup (in the configurator) should not work?

The encoder signal is perfect ... but it looks like the control will not start. On the other hand I do not get any error message ...

Stupidly, I just changed the PCB ... the entire circuit is the same as I've tested and put it into proper operation  :-// :-//

The motor has the numbered phases (1 2 3), which I connected to (U V W).


EDIT:
maybe wrong turning direction? what happens if you swap two motor phases?

In that case, would the sensorless control work?
It's that the engine runs on sensorless ... but with the encoder I'm not lucky.
swapping two phases is the same as reversing encoder direction by configuration, both work equally. The sensorless algorithm works same after swapping phases, the motor will just run in opposite direction.

I would double check the encoder operation here:
- during alignment, is the motor shaft stiff after the current has ramped up? (you can extend the alignment duration to a few seconds to test this)
- can you check the rotor angle output via the analog output test signal? It should vary also when turning the motor by hand
- do you control the motor via STMCWB? No error signaled there?
- sure that the number of poles, and the number of encoder counts per mech revolution is absolutely correct? A mistake there would have exactly that effect.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #162 on: February 15, 2017, 10:06:39 am »
- during alignment, is the motor shaft stiff after the current has ramped up? (you can extend the alignment duration to a few seconds to test this)
I changed the alignment to 5 seconds. The current goes up and then the alignment ends.

- can you check the rotor angle output via the analog output test signal? It should vary also when turning the motor by hand
This is a problem.

I tried yesterday do this ... but at the output of the DAC I do not have variations.
It seems to me that it is not reading the encoder, but the encoder is correctly connected, to the right pins of the MCU and generate a perfect wave ...

- do you control the motor via STMCWB? No error signaled there?
Yes, I am using STMCWB, but no error is shown.

- sure that the number of poles, and the number of encoder counts per mech revolution is absolutely correct? A mistake there would have exactly that effect.
The motor configuration is right. The encoder configuration, could have some problem, but I already switched by the encoder I had to work on the other PCB.
I will continue to check this situation and see if there may be a problem here ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #163 on: February 15, 2017, 10:14:30 am »
I tried yesterday do this ... but at the output of the DAC I do not have variations.
I know for sure that you should have DAC output after successful alignment when manually turning, motor enabled, Id=Iq=0. I do not know if the library generates a rotor angle signal *before* alignment, nor what happens when then motor is not in "started" condition.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #164 on: February 15, 2017, 10:24:30 am »
The DAC works only in "run mode".
When I click "start" motor, the rotor got stuck and I could not turn by hand.
I disconnected the motor connections and then turn the shaft by hand.

I do not have any RPMs measured either in STMCWB or in DAC  |O

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #165 on: February 15, 2017, 10:41:32 am »
The DAC works only in "run mode".
When I click "start" motor, the rotor got stuck and I could not turn by hand.
I disconnected the motor connections and then turn the shaft by hand.

I do not have any RPMs measured either in STMCWB or in DAC  |O
Can you give me the STM32 pinout and port assignment? Also what's reported by STMCWB when you hit the "pin assignment" button? Maybe there is a hidden conflict, or a compatibility problem with the micro. Also make sure that you always use the *primary* rotor feedback in the configuration, the secondary has no use in this setup.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #166 on: February 15, 2017, 11:02:44 am »
I checked the pins and got the right connections ...

I have to find a way to make sure the MCU can receive the signals from the encoder.

https://meocloud.pt/link/e8c879ee-96e5-4a4b-9171-f9cf74030922/FOC%20SDK.rar/
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #167 on: February 15, 2017, 11:32:04 am »
Wait....

Wait...

Inspection loupe is talking to me!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #168 on: February 15, 2017, 11:51:30 am »
I'm a f**ing idiot, with a f**ing blindness!

I measured all the signals on the MCU pins (because I had already learned from past mistakes). But by pressing the MCU pin with the oscilloscope probe, the pin made contact with the pad.
When I took the probe away, the pin was raised.

With the inspection magnifying glass I could see that something was not right ...
 |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O |O
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #169 on: February 15, 2017, 12:34:04 pm »
 :o reflow process stability  +  leadfree solder = &%()§$$"§ ?  8)
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #170 on: February 15, 2017, 12:47:43 pm »
The values I'm changing on the monitor are divided by the constants in Drive Settings, right?




Now I'm having trouble keeping up the rotation.
The motor starts to spin and after a few seconds it loses rotation and stops.


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #171 on: February 15, 2017, 01:46:56 pm »
The values I'm changing on the monitor are divided by the constants in Drive Settings, right?

exactly. But I don't think that it is the velocity controller causing these problems. If the gains are too low, then it will react slowly but still reach steady state. If they are too high, then it will oscillate.

Your observation is somewhat different. The motor starts, it should instantly reach target speed. I assume no shaft load, so that should normally be not more than a few ten to 100 milliseconds depending on the motor. In your case it does never reach target speed, so you have two possible problems:
1) the motor current amplitude is not high enough
2) the motor current does not have the right phase (orientation with respect to rotor)

Does the motor run properly in sensorless configuration? Can you load the shaft then, does it maintain target speed then? You could measure one of the phase currents to see if it reaches the nominal value of 4A that you configured for the motor. If all this is correct, then this rules out option 1. To sense the motor current, I recommend this one here. I bought it a few weeks ago, incredible price/performance ratio and does its job well: http://www.hantek.com/en/ProductDetail_15_77.html
« Last Edit: February 15, 2017, 01:54:29 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #172 on: February 15, 2017, 02:43:27 pm »
Does the motor run properly in sensorless configuration? Can you load the shaft then, does it maintain target speed then?[/url]
Right now I've been testing with sensorless and it works.


When I returned to control with encoder feedback, the motor starts to spin, but after a few seconds it stops ...
* Yellow: encoder alignment
* Green: motor start
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #173 on: February 15, 2017, 03:18:57 pm »
I was able to keep the motor running for more than a few seconds ... but when I changed the speed reference to see the control running, it did the opposite action.
Weird...

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #174 on: February 15, 2017, 03:23:53 pm »
there is only one reason for this that i can think of: the encoder does not do 500 counts per mech rev. even 501 or 499 would lead to exactly this result.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #175 on: February 15, 2017, 03:32:14 pm »
you can check the phase current, ia ib, if they are constantly rising in that situarion, it would be another hint of a count mismatch.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #176 on: February 15, 2017, 03:35:32 pm »
there is only one reason for this that i can think of: the encoder does not do 500 counts per mech rev. even 501 or 499 would lead to exactly this result.

I will program a MCU to communicate with the encoder.
So I can analyze what the registers have.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #177 on: February 15, 2017, 03:38:13 pm »
another remaing thing from a previous post that came into my mind again: did you check that the shaft becomes stiff during (slow 5 seconds) encoder alignmen?t it should not be possible to easily turn it by hand after current has ramped up. i would check that without gearbox.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #178 on: February 16, 2017, 10:28:59 am »
another remaing thing from a previous post that came into my mind again: did you check that the shaft becomes stiff during (slow 5 seconds) encoder alignmen?t it should not be possible to easily turn it by hand after current has ramped up. i would check that without gearbox.

I already tested it and I can not turn the shaft by hand.

So far, the encoder registers are fine to work ...

I do not know what I can do...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #179 on: February 16, 2017, 12:21:06 pm »
The problem is somehow related with PI gains ...

I made some adjustments here and the motor can keep up the speed ... but after a few minutes it starts to oscillate brutally ...

Could it be related to the encoder?

The motor was running smoothly for about 95 seconds and then began to oscillate ...

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #180 on: February 16, 2017, 03:47:30 pm »
The problem is somehow related with PI gains ...

I made some adjustments here and the motor can keep up the speed ... but after a few minutes it starts to oscillate brutally ...

Could it be related to the encoder?

The motor was running smoothly for about 95 seconds and then began to oscillate ...


What happens when you run it sensorless? Does it run stable over time, does it produce torque over time? If all is yes, then I am sure that it must be related to the encoder feedback.

Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

Generally, when I set up the controller gains for FOC, then I do it like this:
- operate in torque mode, and program a rectanguar torque(current) command, maybe 10 to 50Hz in frequency. Adjust system input voltage to max rated.
- configure virtual rotor position feedback to make sure the motor cannot spin.
- measure current of phase U, preferably with current clamp and oscilloscope.
- set integral term to 0, raise proportional term in steps, until the scope starts showing overshoot of the current signal.
- step back a bit with proportional term (I prefer using 50% of final value)
- start raising integral term, until it starts overshooting again
- step back a bit with integral term (again 50% of final value)

Now you can be sure that the current control loop is stable.

Then, the same for velocity control loop:
- use your real rotor phase feedback now
- add all inertia to the rotor shaft that will be present in the system later on
- make sure that regerative operation does not cause overvoltage, as the following test will do that
- program a rectangular velocity command profile, maybe 0.2 Hz, having the velocity switch between two different values. They can be close to each other, maybe 1000 rpm and 1500 rpm.
- monitor velocity value via STM32 DAC feature
- now tune proportional and integral terms of velocity controller the same way as explained above.

This should result in a rock stable system with highest possible dynamic response.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #181 on: February 16, 2017, 03:59:08 pm »
Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

It is a random situation.
For example, the motor was running for more than 15min without any problem ...

I will add the capacitors in the feedback traces  :-+

Next I'll start doing the process that you recommend.

Thank you.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #182 on: February 16, 2017, 04:14:11 pm »
Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

It is a random situation.
For example, the motor was running for more than 15min without any problem ...

I will add the capacitors in the feedback traces  :-+

Next I'll start doing the process that you recommend.

Thank you.
does this happen with sensorless feedback?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #183 on: February 16, 2017, 04:24:14 pm »
Nope.

This erratic behavior only happens with the magnetic encoder.

In sensorless had no problem.

I've already put the capacitors and I'll let the motor run until I'm gone, to see if there's any problem.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #184 on: February 16, 2017, 04:33:49 pm »
Nope.

This erratic behavior only happens with the magnetic encoder.

In sensorless had no problem.

I've already put the capacitors and I'll let the motor run until I'm gone, to see if there's any problem.
if the problem remains, it would be interesting to see "Ia" via DAC, that should be a stable sine and only increase with load. if it ramps up even at idle it would be a strong hint to encoder problems.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #185 on: February 28, 2017, 02:04:29 pm »
Everything is already tuned and I am already meeting the minimum operating conditions.

However at low RPM I get some instability (<400RPM) ...
Is it because the motor has only 2 pairs of poles?
If the motor had more pairs of poles, would I be able to control better at low speeds?


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #186 on: February 28, 2017, 06:34:51 pm »
Everything is already tuned and I am already meeting the minimum operating conditions.

However at low RPM I get some instability (<400RPM) ...
Is it because the motor has only 2 pairs of poles?
If the motor had more pairs of poles, would I be able to control better at low speeds?
How does the instability show? Can you measure rpm fluctuations? Or is it just audible? How does the motor react to instantaneous velocity setpoint changes, is it free from overshoot?

Generally it depends on how you run the motor:
- sensorless: there is a certain minimum speed for the rotor angle estimator to run properly.
- sensored: no theoretical minimum speed. But in reality it depends on the sensor's angular resolution. Yours @400/rev should be fine even at very low rpm.

In either case, the way in which the FOC library represents mechanical velocity has some limitations. As you know, they implemented everything with fixpoint integers. For these values, they did not choose the format very wisely, the numerical representation is in 1/10th of Hertz, or 1/10th of mechanical revs per second. For extreme low speed situations, this can lead to noticeable quantization errors, which is maybe what you notice.

I think that there is a way to work around this (have not tried yet though). As this is mechanical revs, you can "push" the resolution by telling the library that you have a motor with 20 pole pairs instead of 2, and also tell it that the encoder has 4000 steps per rev, instead of 400.
« Last Edit: March 01, 2017, 09:17:38 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #187 on: March 01, 2017, 09:18:05 am »
I think that there is a way to work around this (have not tried yet though). As this is mechanical revs, you can "push" the resolution by telling the library that you have a motor with 20 pole pairs instead of 2, and also tell it that the encoder has 4000 steps per rev, instead of 400.
this is stupid, because it decreases the calculated mechanical velocity, instead of increasing it. Forget about that idea....
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #188 on: March 01, 2017, 09:54:32 am »
How does the instability show? Can you measure rpm fluctuations? Or is it just audible? How does the motor react to instantaneous velocity setpoint changes, is it free from overshoot?

I have fluctuations in RPM...
But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).

This is the speed chart at 200RPM.


Here you can see a video of the behavior of the motor. Initially the motor is running at 1000RPM and then ramps in 10s to 100RPM.
Can it be the backlash that contributes to this?
Does it happen because there is no load on the motor shaft?

https://meocloud.pt/link/07993c73-7c99-4012-bb97-8ee4c9c1b897/VID_20170301_093623.3gp/
« Last Edit: March 01, 2017, 09:58:38 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #189 on: March 01, 2017, 01:18:18 pm »
is it running sensorless or with incremental encoder? That would be very important to know now. For sensorless operation, that would not be surprising. IF you are running with incremental encoder, I would suspect that this is pure velocity control loop instability.

You say that there is no load at the motor. Actually, this is not pointing in the right direction when we are talking about control loop stability. It is not the load that affects stability. That only shifts the setpoints to different values, but it does not change the dynamic behavior. It is the inertial momentum that you need to look at. And you added a lot of that with that large and heavy wheel. My question is: did you do the velocity control loop tuning with that wheel? you definitely need to.

Backlash... your setup looks like it is using a precision planetary gear, is that right? If so, I would expect that the backlash introduced by the reduction gear should be negligible. And, if the velocity control loop is stable with maximum inertial momentum at the shaft, then it cannot become unstable again by adding backlash (unless you would measure velocity after the gear, which you don't). You can consider backlash as a disturber, leading to reduced precision, like a hysteresis.

But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).
This sounds like that you have a certain range of PI gains that are stable. You should only observe instability when gains are too high, it should not be possible to cause instability when gains are too low.
« Last Edit: March 01, 2017, 01:53:04 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #190 on: March 01, 2017, 03:13:58 pm »
is it running sensorless or with incremental encoder? That would be very important to know now. For sensorless operation, that would not be surprising. IF you are running with incremental encoder, I would suspect that this is pure velocity control loop instability.
I'm always using the incremental encoder.
I hope this magnetic encoder is not disturbing ...

You say that there is no load at the motor. Actually, this is not pointing in the right direction when we are talking about control loop stability. It is not the load that affects stability. That only shifts the setpoints to different values, but it does not change the dynamic behavior. It is the inertial momentum that you need to look at. And you added a lot of that with that large and heavy wheel. My question is: did you do the velocity control loop tuning with that wheel? you definitely need to.
Yes.
All calibrations were made with the wheel.
The wheel is very light, all made of plastic and rubber, and has a diameter of 20cm.
The motor has 110W ... a wheel of this size and weight should not be a problem.

Backlash... your setup looks like it is using a precision planetary gear, is that right? If so, I would expect that the backlash introduced by the reduction gear should be negligible. And, if the velocity control loop is stable with maximum inertial momentum at the shaft, then it cannot become unstable again by adding backlash (unless you would measure velocity after the gear, which you don't). You can consider backlash as a disturber, leading to reduced precision, like a hysteresis.
The gear box is planetary, but the connection of the wheel to the shaft has a small gap. However I will solve this to be able to test better.

But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).
This sounds like that you have a certain range of PI gains that are stable. You should only observe instability when gains are too high, it should not be possible to cause instability when gains are too low.
You are right.
But at low rotations I need to increase the gains so that the rotation is more stable. Approximately I have to triple the PI gains to have stability below 400 / 300RPM.

Can current PI gains have any influence?

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #191 on: March 01, 2017, 05:37:26 pm »
I'm always using the incremental encoder.
happy to hear that, the last that I noticed was that you were having trouble with it 8)

I hope this magnetic encoder is not disturbing ...
I doubt that, but you could check it by operating the motor in "stepper motor" style, and watch the output from the encoder via DAC. To test that, this is the hack I normally do:

file MCTasks.c
Code: [Select]
uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
  static int16_t k=0; k+=10; hElAngledpp=k; // <<<<<<<<<<<<<<<<<

 ...


Then, start the motor in torque control mode, and apply some current (the more the better, as you want to check for EMI probems ;)). The motor should turn slowly and smooth. The DAC should show a clear sawtooth.

All calibrations were made with the wheel.
The wheel is very light, all made of plastic and rubber, and has a diameter of 20cm.
The motor has 110W ... a wheel of this size and weight should not be a problem.
It's not a matter of power, control loop stability depends on the characteristics of the controlled system. There you look for gains and time constants. The gains are bus voltage and motor ESR (torque system), and motor kV (velocity system). The time constants are motor inductance (torque system), and rotating mass inertia (velocity system). I hope I haven't forgot anything... As this is a cascade of two control loops, the inner one will also cause additional delays, but normally the current control loop is at least one order of magnitude faster than the velocity control loop, so I try to treat them as independent to keep things simple.

But as you said you have tuned the loops with the wheel. Do you have oscilloscope diagrams of the step response of both loops? Maybe that could give me a clue of what's happening.

at low rotations I need to increase the gains so that the rotation is more stable. Approximately I have to triple the PI gains to have stability below 400 / 300RPM.
That is really strange. Can you once try a controller without integral term? Does the instability disappear? How far can you increase the proportional term until you start noticing instability? My suspicion here is that the I term is too high to be able to handle the wheel's inertia. Another thing worthwile trying: remove the wheel and check if that leads to better stability.

Can current PI gains have any influence?
As mentioned above, theoretically yes but I would expect the current control loop to be much faster than the velocity control loop. That could be easily checked if you could post some pictures from current and velocity step responses from your calibration.
« Last Edit: March 02, 2017, 06:32:39 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #192 on: March 02, 2017, 10:02:22 am »
But as you said you have tuned the loops with the wheel. Do you have oscilloscope diagrams of the step response of both loops? Maybe that could give me a clue of what's happening.
The current step response graph is more complicated to obtain.
Here is the speed response step response graph (for 1500RPM).
Y - rotor speed


Here is the current response step response graph, Iq (for 3Amps). NOTE: I have some oscillation in current control...
Y - Iq current



Can you once try a controller without integral term? Does the instability disappear? How far can you increase the proportional term until you start noticing instability? My suspicion here is that the I term is too high to be able to handle the wheel's inertia. Another thing worthwile trying: remove the wheel and check if that leads to better stability.
Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.
With Ki = 10/4096 the motor does not run, but with Ki = 100/4096 the motor starts to rotate but in an unstable way ...

However, more and more I am sure that the "shakes" in the rotation are caused mechanically.

I'm going to run some more tests to try better understand what's going on ...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #193 on: March 02, 2017, 11:49:34 am »
Here is the speed response step response graph (for 1500RPM).
Y - rotor speed

That looks very reasonable, the time constant is roughly 30ms. Which is quite fast considering that large wheel. But this also makes me think that it is unlikely that your low-rpm oscillations would be caused by instability of the velocity controller. That oscillations were way slower. Which brings me back to the start -->  :o :wtf:

Y - Iq current

The step response shows very large overshoot here (50 % or so?), I suggest to reduce gains until you are completely free from that. It is not possible to judge the time constant from that picture, maybe 2 ~ 5ms. I would say that is fast enough to assume that there will be no interaction with the velocity controller.

But what really concerns me is the very slow decay at 60ms. What command has been given there? Did you just set the current setpoint to zero? If that is the case (I assume for now), I would have expected a step response that is as fast as the one before (@20ms). Something is wrong there. The oscillation also should not be there. It looks as if the power stage is not controlled correctly. Are the low-side transistors working as expected? When the power stage is on, each leg must always be active, so either H or L side transistor conducting. You should never see both transistors of any leg in OFF stage (except of course deadtime during switching).
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #194 on: March 02, 2017, 12:42:05 pm »
I'll take a look at everything again and do what you recommend.

It seems to me that the problem is the motor and gearbox.

Watch this video. Reduction of 2000RPM (motor)/~ 69RPM (after gear box - wheel) to 100RPM (motor)/3.45RPM (after gear box - wheel) in 25sec.

It appears that the control powers the motor to overcome the inertia of a pole and when it rotates. The next magnet attracts and the control has to reduce power quickly ... and so on.
I think it's something related to this ...

Now my speed control loop is 3mS and the current control is 4 times the pwm period.

VIDEO: https://meocloud.pt/link/89ac0711-c8c1-4a29-956a-016925fd7074/VID_20170302_122155.3gp/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #195 on: March 02, 2017, 12:47:29 pm »
Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.
If the motor does not start with only proportional term, then give it a higher speed setpoint, e.g. 1000 or 2000 rpm. Then the motor should start and you can find the correct Kp value. Only then start increasing Ki.

With Ki = 10/4096 the motor does not run
This should never be possible. The integral term of the controller will always deliver maximum torque after some time (it takes longer, the smaller Ki is). You must always be able to start the motor with Ki > 0, even when Kp=0. (It will not be stable though). Again, also here I suggest using a larger speed setpoint.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #196 on: March 02, 2017, 02:19:16 pm »
It appears that the control powers the motor to overcome the inertia of a pole and when it rotates. The next magnet attracts and the control has to reduce power quickly ... and so on.
I think it's something related to this ...
it seems that the "oscillation" correlates with the electrical rotor angle. But I think that the root cause must be somewhere else. Maybe the magnetic encoder. Did you check that all three driver legs are working properly? Are all current sensors giving correct readings?

Basically, the FOC library produces a clean and perfect sinusodial rotating field. If the motor is constructed as a PMSM, then you'll have virtually no torque ripple. The other possibility is that you have a BLDC type motor. These are optimized for six-step "block" commutation and do not produce sinusodial current / back emf waveforms. You'll have some torque ripple when using them together with FOC. As the motor has only 2 pole pairs, this might be contributing to the "oscillation", but the level is surprising to me, and the velocity controller should be able to compensate this to a certain degree.

If the datasheet does not tell, you can check if you have a BLDC or PMSM by running the motor under load, and watching the motor current waveform (Iq, via DAC). If the waveform is sinusodial, then it is a PMSM.

As you are developing a servo application requiring ripple-free torque, a PMSM would be more suitable.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #197 on: March 02, 2017, 02:43:57 pm »
Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.
I was trying to observe the behavior at lower rotations.
At higher revs, I can do a correct tunning and the behavior is expected in all situations.

With Ki = 10/4096 the motor does not run
This should never be possible. The integral term of the controller will always deliver maximum torque after some time (it takes longer, the smaller Ki is). You must always be able to start the motor with Ki > 0, even when Kp=0. (It will not be stable though). Again, also here I suggest using a larger speed setpoint.
Exactly.
I did not wait long enough...
« Last Edit: March 02, 2017, 03:07:56 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #198 on: March 02, 2017, 03:18:41 pm »
When the power stage is on, each leg must always be active, so either H or L side transistor conducting. You should never see both transistors of any leg in OFF stage (except of course deadtime during switching).
it seems that the "oscillation" correlates with the electrical rotor angle. But I think that the root cause must be somewhere else. Maybe the magnetic encoder. Did you check that all three driver legs are working properly? Are all current sensors giving correct readings?
Yes, I have confirmed and all PWM outputs are correct.
Always in high state, except during the dead time on switching.

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #199 on: March 02, 2017, 03:33:08 pm »
Basically, the FOC library produces a clean and perfect sinusodial rotating field. If the motor is constructed as a PMSM, then you'll have virtually no torque ripple. The other possibility is that you have a BLDC type motor. These are optimized for six-step "block" commutation and do not produce sinusodial current / back emf waveforms. You'll have some torque ripple when using them together with FOC. As the motor has only 2 pole pairs, this might be contributing to the "oscillation", but the level is surprising to me, and the velocity controller should be able to compensate this to a certain degree.

If the datasheet does not tell, you can check if you have a BLDC or PMSM by running the motor under load, and watching the motor current waveform (Iq, via DAC). If the waveform is sinusodial, then it is a PMSM.

As you are developing a servo application requiring ripple-free torque, a PMSM would be more suitable.

Here is a lot of information.
In the supplier page, everything indicates that it is a BLDC motor.
Under load, the current Iq is just line ... does not form any sine wave ...
Another interesting thing is when I see the Measured Electric Angle on the oscilloscope, I see strange waveforms. I stop observing a triangle waveform.


« Last Edit: March 02, 2017, 03:47:21 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #200 on: March 02, 2017, 04:09:24 pm »
Under load, the current Iq is just line ... does not form any sine wave ...
sorry, mistaken. The value "Ia" and "Ib" should show sinusodial waveforms, the Iq just shows their amplitude.

Another interesting thing is when I see the Measured Electric Angle on the oscilloscope, I see strange waveforms. I stop observing a triangle waveform.
Now that looks like a clue. The magnetic encoder having problems with magnets?  :o That picture shows the motor running smoothly at higher rpm, right?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #201 on: March 02, 2017, 04:17:38 pm »
Under load, the current Iq is just line ... does not form any sine wave ...
sorry, mistaken. The value "Ia" and "Ib" should show sinusodial waveforms, the Iq just shows their amplitude.
In that case Ia shows a sinusoid.
The following picture shows Ia with the engine in charge at 1000RPM.


Another interesting thing is when I see the Measured Electric Angle on the oscilloscope, I see strange waveforms. I stop observing a triangle waveform.
Now that looks like a clue. The magnetic encoder having problems with magnets?  :o That picture shows the motor running smoothly at higher rpm, right?
No.
This image is in the rotations that I have problems, in this case at 100RPM...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #202 on: March 02, 2017, 05:07:44 pm »
I feel that something here is not right  ???.

I'm going to take it all apart and test it only with the motor, with nothing attached to shaft (no wheel, no gear box).
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #203 on: March 02, 2017, 05:16:28 pm »

okay, as this is showing the low-rpm "oscillation" situation, you can be sure that it is correlated to the electrical motor angle - simply because the shape of distortion from a sawtooth is similar in each cycle.

But I still don't really trust the encoder yet. At higher rpm under load, do you get a nice sawtooth? That would rule out possible problems there.

Current waveform Ia is good. If you look close at it, then you can see that it is not perfectly sinusodial. There are small flat sections around zero crossing. I have seen much worse, like this for example (googled) :

PWM also looks good, so I would say (unless the encoder has some problems) both electronics and firmware are in good shape.

I am slowly coming to the point that the BLDC's torque ripple together with the wheel's inertia leads to a situation that cannot be solved by a PI controller at low rpm. Put simple: the wheel inertia limits the Kp / Ki gains that you can allow to maintain stability. (You can try tuning the speed controller without the wheel, you should be able to use much higher gains!) The lower gains limit the controller's ability to compensate for the torque ripple.

If that turns out correct, I don't see simple options...
- use motor with higher pole count (mitigate problem by shifting it to even lower rpm)
- use motor with PMSM construction (eliminate torque ripple)
- use higher rpm motor and higher gear reduction ratio (this reduces the inertia that the motor "sees")
- I think that the speed controller has a feedforward option, that can help to improve stability, but don't expect too much from that
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #204 on: March 02, 2017, 06:16:55 pm »
But I still don't really trust the encoder yet. At higher rpm under load, do you get a nice sawtooth? That would rule out possible problems there.
Above 400/500RPM, with or without load on the motor shaft, the waveform is a perfect sawtooth.


I am slowly coming to the point that the BLDC's torque ripple together with the wheel's inertia leads to a situation that cannot be solved by a PI controller at low rpm. Put simple: the wheel inertia limits the Kp / Ki gains that you can allow to maintain stability. (You can try tuning the speed controller without the wheel, you should be able to use much higher gains!) The lower gains limit the controller's ability to compensate for the torque ripple.

If that turns out correct, I don't see simple options...
- use motor with higher pole count (mitigate problem by shifting it to even lower rpm)
- use motor with PMSM construction (eliminate torque ripple)
- use higher rpm motor and higher gear reduction ratio (this reduces the inertia that the motor "sees")
- I think that the speed controller has a feedforward option, that can help to improve stability, but don't expect too much from that

Now I have only the motor and the oscillation persists below 400RPM.

It is very obvious that below ~400RPM the waveform changes like the behavior of the motor and the control as well.
Pay attention to the oscilloscope in the video. I'm measuring the electric angle via DAC.
Notice that at some moment the waveform changes completely  :o :o.
This change is the mystery...

2000RPM to 100RPM in 25sec.
VIDEO: https://meocloud.pt/link/b35a236c-0675-4494-9829-23860792966d/VID_20170302_180652.3gp/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #205 on: March 02, 2017, 08:15:12 pm »
Now I have only the motor and the oscillation persists below 400RPM.

It is very obvious that below ~400RPM the waveform changes like the behavior of the motor and the control as well.
Pay attention to the oscilloscope in the video. I'm measuring the electric angle via DAC.
Notice that at some moment the waveform changes completely  :o :o.
This change is the mystery...

2000RPM to 100RPM in 25sec.
VIDEO: https://meocloud.pt/link/b35a236c-0675-4494-9829-23860792966d/VID_20170302_180652.3gp/
The waveform is changing because the motor speed becomes unstable. From what I can see, there is no problem with the encoder. I think we can rule that out.

I suggest to tune the speed controller Kp/Ki again without gearbox (you should be able to set significantly higher values). If that results in a stable system down to zero rpm (which I would almost bet by now), then that would strengthen the theory in my last post: the control problem is not solvable by a PI controller, and you'd need to change components (maybe feedforward does help).

p.s. I still have in a previous post, regarding the current controller: what is happening at the falling slope in your current step response screenshot? What command do you give there?

p.p.s. another idea: did you test that the speed controller handles transitions from high to low rpm correctly? The motor should not "roll out", you should see the same quick reaction as you see when accelerating.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #206 on: March 03, 2017, 09:45:01 am »
I suggest to tune the speed controller Kp/Ki again without gearbox (you should be able to set significantly higher values). If that results in a stable system down to zero rpm (which I would almost bet by now), then that would strengthen the theory in my last post: the control problem is not solvable by a PI controller, and you'd need to change components (maybe feedforward does help).
I'm going to try to use Feed Forward, but the control uses a PID. The derivative gain can be modified via register.


p.s. I still have in a previous post, regarding the current controller: what is happening at the falling slope in your current step response screenshot? What command do you give there?
I introduced a Iq ref of 1.5A and clicked start motor.
The signal measured on the oscilloscope represents Iq in step response.
The motor jumped to full speed.

p.p.s. another idea: did you test that the speed controller handles transitions from high to low rpm correctly? The motor should not "roll out", you should see the same quick reaction as you see when accelerating.
Yes I tested it.
It works perfectly.
0RPM to 1000RPM to -1000RPM to 0RPM, no problem.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #207 on: March 03, 2017, 09:54:39 am »
I suggest to tune the speed controller Kp/Ki again without gearbox (you should be able to set significantly higher values). If that results in a stable system down to zero rpm (which I would almost bet by now), then that would strengthen the theory in my last post: the control problem is not solvable by a PI controller, and you'd need to change components (maybe feedforward does help).
I'm going to try to use Feed Forward, but the control uses a PID. The derivative gain can be modified via register.


Derivative gain takes no effect....
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #208 on: March 03, 2017, 10:10:55 am »
Using Feed Forward, I had no difference in motor behavior.

By tuning the gains without the gearbox, the values of the gains can be higher.

But below the ~ 400RPM, the problem remains the same ... the jump between electric rotation is very remarkable.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #209 on: March 03, 2017, 12:05:29 pm »
NOTE:
I've been reading the manufacturer's information and this motor has a nominal speed of 3100RPM.
So far I've always tested around the 2000RPM, because it was the maximum rotation I want in my application.
But there is a problem. When I try to accelerate the motor to maximum (which should reach 4000RPM according to the manufacturer), the motor does not exceed 2900RPM. It's a big question ... because the limitation I had so far was 4000RPM (in motor configuration) and I do not understand why the rotation is being limited...

I had already noticed this, but I thought it was some mistake. For my application has no difference ... but with all these problems I remembered again this situation that can give some clue of what can happen at low revs.

[EDIT]
Motor Power has also always zero ... strange  ???.

« Last Edit: March 03, 2017, 12:29:43 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #210 on: March 03, 2017, 12:18:34 pm »
I'm going to try to use Feed Forward, but the control uses a PID. The derivative gain can be modified via register.
I am using an older version of the library (4.0), and I looked again. That version definitely uses only PI. Maybe that's some future extension residue.

I introduced a Iq ref of 1.5A and clicked start motor.
The signal measured on the oscilloscope represents Iq in step response.
The motor jumped to full speed.
Okay, understood. The slow falling ramp is then caused by the motor reaching steady state rpm, and as expected. That "oscillation" which follows is normal, and is due to imperfections of motor construction (phase windings, magnetization, etc).
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #211 on: March 03, 2017, 12:27:12 pm »
Using Feed Forward, I had no difference in motor behavior.

By tuning the gains without the gearbox, the values of the gains can be higher.

But below the ~ 400RPM, the problem remains the same ... the jump between electric rotation is very remarkable.
Is it possible that the motor is damaged somehow? Can you make a measurement that would also help identifying the motor characteristics futher? Take three 1k resistors and connect one of them to each phase. Join the other ends of the three. Then use three channels of your scope and measure all three phase voltages simultaneously while turning the motor by hand. The ground clips of all channels go to the common connection of the three resistors.

I really cannot find anything suspicious in your setup, it all leads me to think that the motor is not suitable.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #212 on: March 03, 2017, 12:43:00 pm »
Is it possible that the motor is damaged somehow?

I have 2 identical motors and 2 similar electronics.
I have now tested the other setup, with the same firmware. Everything runs in a similar way. Maximum rotation of 2900RPM, vibration at low rotations, etc ...
« Last Edit: March 03, 2017, 03:15:55 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #213 on: March 03, 2017, 02:50:03 pm »
Take three 1k resistors and connect one of them to each phase. Join the other ends of the three. Then use three channels of your scope and measure all three phase voltages simultaneously while turning the motor by hand. The ground clips of all channels go to the common connection of the three resistors.

From what I can see, it seems fine ...




 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #214 on: March 03, 2017, 05:54:17 pm »
Now we know that both phase voltages and phase currents look almost sinusodial, I would expect little torque ripple and the motor should be able to run smooth with FOC also at low rpm.

I made a quick test to see if we are expecting something from the FOC library. This is a video of my diy electric kart running STM32 FOC. The motor is a servo motor (PMSM), 3 pole pairs, Rs=0.13, Ls=250uH, BemfConstant = 4.2 Vrms/krpm. That should not be too far away from yours, except that it is much stronger, and that it is a motor that is constructed to have sinusodial behavior. The planetary reduction gear is 1:10. I run a sawtooth velocity ramp down to zero. There is heavy inertial load at the output shaft, the kart rear axle weighs several kilograms, you see that when the motor spins up at the end.

https://www.kicksurfer.de/index.php/2017/03/03/kart-motor-velocity-control/

It is running very smoothly down to almost zero. When you look closely then you can notice some irregularity when it almost stops spinning.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #215 on: March 03, 2017, 06:25:14 pm »

That picture allows us to calculate the motor kV. Frequency is ~ 43Hz. Amplitude of one phase in relation to star point is ~ 5V. This means that the Amplitude phase-to-phase is ~ 5V * sqrt(3) = 8.7V.

The classical kV value of a BLDC cannot be easily calculated from that, because it assumes that you are running the motor with a six-step-commutating controller.

In the past I have done some experiments with one of my FOC controllers (max PWM duty cycle is set to 95%) to find out how to derive a "compatible" kV from the above measurement. My formula is

kV = frequency * 60 / pole_pairs / amplitude_phase_to_phase * 0.95
kV = 141 rpm/V

For a bus voltage of 24V, you can calculate the no-load speed:

rpm_no_load = kV * bus_volt
rpm_no_load = 3380 rpm

I have no idea why the manufacturer advertises the motor for 4000 rpm @ 24V, it is certainly not able to achieve this.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #216 on: March 03, 2017, 06:25:46 pm »
Yes you're right ... the motor runs smoothly almost to 0RPM.
I want to be able to do this ... but with this motor I'm not very lucky ...

Rs=0.13, Ls=250uH, BemfConstant = 4.2 Vrms/krpm.
How did you get those values?
Did you use an EVB with the "Motor Profiler"?

My EVB (P-NUCLEO-IHM001) only supports a maximum of 2.8Apk...
The values obtained may be slightly wrong. Will this make a lot of difference in the final application?

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #217 on: March 03, 2017, 06:39:01 pm »
That picture allows us to calculate the motor kV. Frequency is ~ 43Hz. Amplitude of one phase in relation to star point is ~ 5V. This means that the Amplitude phase-to-phase is ~ 5V * sqrt(3) = 8.7V.

The classical kV value of a BLDC cannot be easily calculated from that, because it assumes that you are running the motor with a six-step-commutating controller.

In the past I have done some experiments with one of my FOC controllers (max PWM duty cycle is set to 95%) to find out how to derive a "compatible" kV from the above measurement. My formula is

kV = frequency * 60 / pole_pairs / amplitude_phase_to_phase * 0.95
kV = 141 rpm/V

For a bus voltage of 24V, you can calculate the no-load speed:

rpm_no_load = kV * bus_volt
rpm_no_load = 3380 rpm

I have no idea why the manufacturer advertises the motor for 4000 rpm @ 24V, it is certainly not able to achieve this.
This morning I contacted the manufacturer to ask for some explanation/data/infos. I'm still waiting for an answer ...
The manufacturer should have more technical details than those on the site.

I'm learning a lot from you. Thank you!  :-+ :-+
This is my first contact with brushless motors and if it were not for you, I would be completely lost!

Theoretically the maximum rotation will be ~3300RPM and I am measuring a maximum rotation of ~ 2900RPM.
I'm getting -12%. Not a big difference in fact, which can be affected by motor efficiency...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #218 on: March 03, 2017, 06:58:11 pm »
Yes you're right ... the motor runs smoothly almost to 0RPM.
I want to be able to do this ... but with this motor I'm not very lucky ...

Rs=0.13, Ls=250uH, BemfConstant = 4.2 Vrms/krpm.
How did you get those values?
Did you use an EVB with the "Motor Profiler"?

My EVB (P-NUCLEO-IHM001) only supports a maximum of 2.8Apk...
The values obtained may be slightly wrong. Will this make a lot of difference in the final application?

The motor profiler is quite new, haven't used it yet.

Rs and Ls were measured with an LCR meter. That BemfConstant was calculated from the phase voltage measurement. I had some support from ST to understand the relationships correctly. I checked the forum there, but the posts do not seem to be there anymore.

From what I remember:
Rs, Ls: measure between two phases, divide by 2.
BemfConstant = amplitude_phase_to_phase / sqrt(2) / (frequency*60/1000)
BemfConstant = 2.4 (in your case)

Anyhow, the motor parameters are used by STMCWB to calculate parameters for sensorless operation, and they also derive the current controller Kp/Ki from that. The BemfConstant will probably also go into the velocity controller Kp/Ki and the feedforward parameters, I'm not sure about that.

As you tune all PI's manually and use sensored feedback, I am pretty sure that these three parameters do not matter at all. What needs to be correct is pole pairs, max rated speed, nominal current. For nominal DC voltage I'm not sure either.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #219 on: March 03, 2017, 07:33:41 pm »
I'm learning a lot from you. Thank you!  :-+ :-+
This is my first contact with brushless motors and if it were not for you, I would be completely lost!

Theoretically the maximum rotation will be ~3300RPM and I am measuring a maximum rotation of ~ 2900RPM.
I'm getting -12%. Not a big difference in fact, which can be affected by motor efficiency...
No problem, youre welcome :)

My ~3300 is only a very rough estimate from looking at the screenshot, you could make more precise measurements. And yes, you would only reach that speed if the motor had no bearing losses. Does it use sealed bearings?
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #220 on: March 03, 2017, 07:35:27 pm »
just found something interesting. The motor manufacturer website advertises them with "speed, 400 - 4000 rpm" right on the front page...
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #221 on: March 03, 2017, 08:22:48 pm »
just found something interesting. The motor manufacturer website advertises them with "speed, 400 - 4000 rpm" right on the front page...
I had already noticed that, but I thought that this minimum rotation was limited by sensorless.
Below the 400RPM the feedback current is very small.

However they also indicate "4000RPM" and apparently this is also not true...  :-//
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #222 on: March 03, 2017, 08:26:33 pm »
My ~3300 is only a very rough estimate from looking at the screenshot, you could make more precise measurements. And yes, you would only reach that speed if the motor had no bearing losses. Does it use sealed bearings?
The gear box yes, it has sealed bearings.
The motor I can not confirm, but I think they are of the same type.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #223 on: March 03, 2017, 08:43:02 pm »
just found this video. They describe a method to reduce cogging. That would be possible in your application but would also involve digging deep into the firmware.


We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #224 on: March 06, 2017, 09:34:29 am »
I've been busy in the weekend ... sorry for the delay.

Excellent video! I understood what they are doing.
But if all the control firmware was designed by me, it would be easier to implement that.
In this case the SDK is very advanced and its algorithm forms a "web" that would be very difficult to modify.
I would have to find another solution (a simple one) ... otherwise I have a lot to "dig" into the firmware!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #225 on: March 06, 2017, 10:11:45 am »
I am inventing using the SDK.

I reduced the PWM frequency from 20KHz to 15KHz.
So, with my power circuit, the maximum modulation raise from 89% to 96%.

In this configuration the maximum rotation reaches 3100RPM.



[EDIT]
With a maximum modulation of 100% (fPWM=12KHz) the motor reaches a maximum rotation of ~3300RPM.
The same difference of -12% from your theoretical calculation for the measured rotation (100% modulation).

So, I think this is the true maximum speed I can achieve with this hardware ....
« Last Edit: March 06, 2017, 04:44:58 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #226 on: March 06, 2017, 04:39:28 pm »
I am inventing using the SDK.

I reduced the PWM frequency from 20KHz to 15KHz.
So, with my power circuit, the maximum modulation raise the  from 89% to 96%.

In this configuration the maximum rotation reaches 3100RPM.

[EDIT]
With a maximum modulation of 100% (fPWM=12KHz) the motor reaches a maximum rotation of ~3300RPM.
The same difference of -12% from your theoretical calculation for the measured rotation (100% modulation).

So, I think this is the true maximum speed I can achieve with this hardware ....
sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot. If you can reduce this, it will also improve efficiency and reduce losses in the driver. During the deadtime, the motor current flows through the lossy MOSFETs body diodes.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #227 on: March 06, 2017, 04:49:00 pm »
I've been busy in the weekend ... sorry for the delay.

Excellent video! I understood what they are doing.
But if all the control firmware was designed by me, it would be easier to implement that.
In this case the SDK is very advanced and its algorithm forms a "web" that would be very difficult to modify.
I would have to find another solution (a simple one) ... otherwise I have a lot to "dig" into the firmware!
8) if you want to do that, you might want to get a copy of the library's source code, you can get this for free from your chip distributor. (ST will want you to sign an NDA.)

But maybe that will not be necessary. I was thinking about how to implement the anti-cogging feedforward. It is possible that it is enough to do this
- get current electrical rotor phase
- look up correction factor from a table (rotor phase is the index to the table, do linear interpolation to reduce table size)
- multiply the torque current setpoint value (Iq) with that factor
- apply range limitation to make sure the motor does not receive too much instantaneous current
- use the corrected value as input to PI controller for torque / current

All that would be done in MCTasks.c, function FOC_CurrController(). You don't need the library source code for that mod.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #228 on: March 06, 2017, 04:54:21 pm »
sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.
Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS

 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #229 on: March 06, 2017, 04:58:41 pm »
sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.
Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS


Stupid me.

350 (worst case) + ~ 25% (deviation) = 450nS is enough!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #230 on: March 06, 2017, 06:07:10 pm »
- get current electrical rotor phase

I just have one DAC output.
I have to find a way to measure Iq and also measure the electric angle.

If I find a minimum operating Iq and get the graph of the electric angle variation?
I'll be able to have the rotation variation for the same torque ....

No ... probably I could not do anything with that information.
« Last Edit: March 06, 2017, 06:11:11 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #231 on: March 06, 2017, 06:32:30 pm »
Using torque control, I can lower the current Iq to a minimum of 0.35A with rotation rotation.

I can observe the variation of the electric angle ... but it is not enough information to move forward.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #232 on: March 07, 2017, 07:03:52 am »
- get current electrical rotor phase

I just have one DAC output.
I have to find a way to measure Iq and also measure the electric angle.

If I find a minimum operating Iq and get the graph of the electric angle variation?
I'll be able to have the rotation variation for the same torque ....

No ... probably I could not do anything with that information.
You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #233 on: March 07, 2017, 07:06:29 am »
Using torque control, I can lower the current Iq to a minimum of 0.35A with rotation rotation.

I can observe the variation of the electric angle ... but it is not enough information to move forward.


The speed variation seems quite sinusodial and hints to a torque variation of similar shape, maybe this is already enough to set up a correction function/table. You would just need to find gain and phase of that by try and error.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #234 on: March 07, 2017, 07:08:46 am »
sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.
Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS


Stupid me.

350 (worst case) + ~ 25% (deviation) = 450nS is enough!
Even better. You only have to wait for the fall time to complete, until the other transistor can be switched on. So the minimum dead time could be 302ns.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #235 on: March 07, 2017, 10:09:13 am »
You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.

But this should be done in open loop, right?
I should be able to change the PWM and apply a value without controll loop.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #236 on: March 07, 2017, 10:18:35 am »
You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.

But this should be done in open loop, right?
I should be able to change the PWM and apply a value without controll loop.
agree, that would the necessary. You can do that again in the FOC_CurrController() function. There should be a section like this, I added a line here:

Code: [Select]
  ...
  Vqd.qV_Component1 = 1000; Vqd.qV_Component2 = 0; // <<<<<<<
  Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);
 
  hCodeError = PWMC_SetPhaseVoltage(oCurrSensor[bMotor], Valphabeta);
  ...
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #237 on: March 07, 2017, 10:52:47 am »
I made the changes ... but I do not have rotation.
I noticed that the FOC_CurrController function has a condition for "OPEN_LOOP".
Can we use this?

Code: [Select]
/**
  * @brief It executes the core of FOC drive that is the controllers for Iqd
  *        currents regulation. Reference frame transformations are carried out
  *        accordingly to the active speed sensor. It must be called periodically
  *        when new motor currents have been converted
  * @param this related object of class CFOC.
  * @retval int16_t It returns MC_NO_FAULTS if the FOC has been ended before
  *         next PWM Update event, MC_FOC_DURATION otherwise
  */
#pragma inline
uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
 
  PWMC_GetPhaseCurrents(oCurrSensor[bMotor], &Iab);
 
  Ialphabeta = MCM_Clarke(Iab);
 
  Iqd = MCM_Park(Ialphabeta, hElAngledpp);
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    IqdHF = Iqd; /* Stores the Iqd not filtered */
    Iqd = HFI_FP_PreProcessing(oHFI[bMotor], Iqd);
  }
#endif
 
//  Vqd.qV_Component1 = PI_Controller(oPIDIq[bMotor],
//            (int32_t)(FOCVars[bMotor].Iqdref.qI_Component1) - Iqd.qI_Component1);
//
//  Vqd.qV_Component2 = PI_Controller(oPIDId[bMotor],
//            (int32_t)(FOCVars[bMotor].Iqdref.qI_Component2) - Iqd.qI_Component2);
 
/****************************************/
  Vqd.qV_Component1 = 1000;
  Vqd.qV_Component2 = 0;
/****************************************/
 
#if defined(FEED_FORWARD_CURRENT_REGULATION) || (defined(DUALDRIVE) && defined(FEED_FORWARD_CURRENT_REGULATION2))
  if (oFF[bMotor])
  {
    Vqd = FF_VqdConditioning(oFF[bMotor],Vqd);
  }
#endif
 
  FOCVars[bMotor].Vqd = Vqd;
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    Vqd = HFI_FP_VqdConditioning(oHFI[bMotor], Vqd);
  }
#endif
 
#if defined(OPEN_LOOP) || (defined(DUALDRIVE) && defined(OPEN_LOOP2))
  if (oOL[bMotor])
  {
    Vqd = OL_VqdConditioning(oOL[bMotor]);
  }
#endif
 
  Vqd = Circle_Limitation(oCLM[bMotor], Vqd);
 
  Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);
 
  hCodeError = PWMC_SetPhaseVoltage(oCurrSensor[bMotor], Valphabeta);
 
  FOCVars[bMotor].Iab = Iab;
  FOCVars[bMotor].Ialphabeta = Ialphabeta; 
  FOCVars[bMotor].Iqd = Iqd;   
  FOCVars[bMotor].Valphabeta = Valphabeta;
  FOCVars[bMotor].hElAngle = hElAngledpp;

#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  FOCVars[bMotor].IqdHF = IqdHF;
#endif
 
#if defined(FLUX_WEAKENING) || (defined(DUALDRIVE) && defined(FLUX_WEAKENING2))
  if (oFW[bMotor])
  {
    FW_DataProcess(oFW[bMotor], Vqd);
  }
#endif
 
#if defined(FEED_FORWARD_CURRENT_REGULATION) || (defined(DUALDRIVE) && defined(FEED_FORWARD_CURRENT_REGULATION2))
  if (oFF[bMotor])
  {
    FF_DataProcess(oFF[bMotor]);
  }
#endif
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    HFI_FP_DataProcess(oHFI[bMotor], IqdHF);
  }
#endif
 
  return(hCodeError);
}

Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.
The problem is that I do not know nothing in this firmware :-DD

Something like this:
Code: [Select]
Vqd.qV_Component1 = FOCVars[bMotor].Iqdref.qI_Component1;
« Last Edit: March 07, 2017, 11:35:04 am by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #238 on: March 07, 2017, 03:50:59 pm »
I found the paper of the video.
http://www.roboticsproceedings.org/rss10/p42.pdf

But I can not figure out how to start PWM ...
I continue to explore the firmware code.
 
The following users thanked this post: tatus1969

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #239 on: March 07, 2017, 05:02:23 pm »
I made the changes ... but I do not have rotation.
I noticed that the FOC_CurrController function has a condition for "OPEN_LOOP".
Can we use this?
I have checked, yes, but it is doing exactly the same as our code. This is the function's source code:
Code: [Select]
Volt_Components OL_VqdConditioning(COL this)
{
  pVars_t pVars = CLASS_VARS;
  Volt_Components Vqd;
 
  Vqd.qV_Component1 = pVars->hVoltage;
  Vqd.qV_Component2 = 0;
 
 return(Vqd);
}

Our code should also work, but I noticed that it has a problem: it is always active. We don't want it active during encoder alignment. Please try this modification:

Code: [Select]
if( StateM1 == RUN )
{
    Vqd.qV_Component1 = 1000; Vqd.qV_Component2 = 0;
}

Did you check with higher values as 1000? I think 32767 equals 100% voltage.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #240 on: March 07, 2017, 05:06:29 pm »
I found the paper of the video.
http://www.roboticsproceedings.org/rss10/p42.pdf

But I can not figure out how to start PWM ...
I continue to explore the firmware code.
Interesting. They propose to compensate for cogging by adding a correction value instead of multiplying in a factor. I was already wondering which one would be the best approach :)
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #241 on: March 07, 2017, 05:46:33 pm »
Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.
That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #242 on: March 07, 2017, 05:56:41 pm »
Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.
That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.

What I want to say was pick up the Iq value that is sent to the MCU (via STMCWB ) and pass it directly to the PWM.
So it ranged from 0 to 32767 using STMCWB and immediately updated the PWM value.
It would be faster than modifying the value and compile all again...

But I'm talking without the knowledge of the tasks that occur at low level ...
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #243 on: March 07, 2017, 06:05:53 pm »
Did you check with higher values as 1000? I think 32767 equals 100% voltage.

I was gradually rise up to 32000.
I have no rotation after doing start motor.
But the motor shaft makes some force ...

Code: [Select]
State_t StateM1;
StateM1 = STM_GetState(oSTM[M1]);
if( StateM1 == RUN )
{
Vqd.qV_Component1 = 3000; Vqd.qV_Component2 = 0;
}
« Last Edit: March 07, 2017, 06:08:29 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #244 on: March 07, 2017, 06:17:06 pm »


Code: [Select]
/**
  * @brief Check whether Vqd.qV_Component1^2 + Vqd.qV_Component2^2 <= 32767^2
  *        and if not it applies a limitation keeping constant ratio
  *        Vqd.qV_Component1 / Vqd.qV_Component2
  * @param  this related object of class CCLM
  * @param  Vqd Voltage in qd reference frame 
  * @retval Volt_Components Limited Vqd vector
  */
Volt_Components Circle_Limitation(CCLM this, Volt_Components Vqd);

This makes some limitations ...
But in fact the applicable maximum is 32767.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #245 on: March 07, 2017, 06:45:54 pm »
Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.
That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.

What I want to say was pick up the Iq value that is sent to the MCU (via STMCWB ) and pass it directly to the PWM.
So it ranged from 0 to 32767 using STMCWB and immediately updated the PWM value.
It would be faster than modifying the value and compile all again...

But I'm talking without the knowledge of the tasks that occur at low level ...
i misunderstood that good idea,sorry :o
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #246 on: March 07, 2017, 07:13:14 pm »


Code: [Select]
/**
  * @brief Check whether Vqd.qV_Component1^2 + Vqd.qV_Component2^2 <= 32767^2
  *        and if not it applies a limitation keeping constant ratio
  *        Vqd.qV_Component1 / Vqd.qV_Component2
  * @param  this related object of class CCLM
  * @param  Vqd Voltage in qd reference frame 
  * @retval Volt_Components Limited Vqd vector
  */
Volt_Components Circle_Limitation(CCLM this, Volt_Components Vqd);

This makes some limitations ...
But in fact the applicable maximum is 32767.
This function limits the voltage vector amplitude such that the max PWM duty cycle is not exceeded, no worries about that.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #247 on: March 07, 2017, 07:16:34 pm »
Did you check with higher values as 1000? I think 32767 equals 100% voltage.

I was gradually rise up to 32000.
I have no rotation after doing start motor.
But the motor shaft makes some force ...

Code: [Select]
State_t StateM1;
StateM1 = STM_GetState(oSTM[M1]);
if( StateM1 == RUN )
{
Vqd.qV_Component1 = 3000; Vqd.qV_Component2 = 0;
}
can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #248 on: March 08, 2017, 09:15:58 am »
can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.

Yes, the motor is already running.

What can this mean?

« Last Edit: March 08, 2017, 09:26:02 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #249 on: March 08, 2017, 09:50:18 am »
can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.

Yes, the motor is already running.

What can this mean?


I think that the encoder alignment does not work as expected. There seems to be an (electrical) phase shift of around 90 degrees between what it does and what it should do.

If it would be working correctly, then the FOC algorithm would make sure that the magnetic field created by the stator windings is (electrically, magnetically) always exactly 90 degrees away from the magnetic field vector of the rotor's permanent magnets. This makes sure that the attraction/rejection forces within the motor are radial, which maximizes motor torque.

In your case, there seems to be a 90° error in phase. If that is the case, then the forces are axial instead, and the stator poles just axially "pull out" the permanent magnets, resulting in no movement.

I just validated the sensorless algorithm a few weeks ago because I wasn't sure how well that is working. You can do the same with the encoder algorihm, allowing you to debug it:

- place small permanent magnet onto motor shaft/gear
- place Hall sensor in some orientation, such that it triggers once per mechanical rev, connect to scope channel, use it as trigger
- connect oscilloscope between two motor phases
- turn motor by hand and determine voltage zero crossing on scope --> this is your zero phase reference; you can now move the hall sensor such that its trigger point is right at the zero crossing; alternatively you can determine the phase between the two
- now attach the driver, setup a certain motor speed, and load the motor
- measure Ia value via DAC via scope and determine phase between hall sensor triggering (zero crossing) and current

At this point you are able to measure the phase between motor current and the motor's rotor orientation. I am a bit lost here to suggest the correct phase (I did it differently by measuring real phase current with a probe instead), but there is an easy way for you to determine that: make the measurement once with sensorless feedback, I am confident that you can trust it. Then you know the phase that you should see when switching to encoder feedback.
« Last Edit: March 08, 2017, 09:53:36 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #250 on: March 08, 2017, 10:02:25 am »
I do not know if this can give any clue ...

I had the motor running with Vqd.qV_Component2 = 3000 for ~ 15min.
I turn off the motor and it is super hot! The whole motor is really hot!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #251 on: March 08, 2017, 12:07:43 pm »
I did some tests to try to understand what's going on ...

Code: [Select]
encoder align 90º
Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;
Weak rotation. Clockwise

Code: [Select]
encoder align 90º
Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;
No rotation.

Code: [Select]
encoder align 0º
Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;
No rotation.

Code: [Select]
encoder align 0º
Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;
Very weak rotation. Clockwise.
« Last Edit: March 20, 2017, 10:15:01 am by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #252 on: March 08, 2017, 02:55:40 pm »
I do not know if this can give any clue ...

I had the motor running with Vqd.qV_Component2 = 3000 for ~ 15min.
I turn off the motor and it is super hot! The whole motor is really hot!
If the motor gets hot and does not produce torque, it means that the magnetic forces are not pointing in the right direction. The flowing current is then mostly generating heat.

Keep in mind that the angle that you enter in this mask is not an offset that would be added to the electrical orientation after alignment. It just determines at which angle the measurement takes place. For a "sinusodial" motor this does not make a difference, but for a BLDC as in your case this will result in slightly different alignment results depending on which angle you choose.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #253 on: March 08, 2017, 03:16:31 pm »

300ms is quite a short time for the rotor to mechanically move into the correctly aligned position, and to keep it. Maybe increase that. I also suggest to do the ramp with as much current as possible. This helps it keep that position even when there is some torque at the output shaft.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #254 on: March 08, 2017, 03:20:17 pm »
Eu fiz alguns testes para tentar entender o que se passa...

Code: [Select]
encoder align 90º
Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;
Weak rotation. Clockwise

Code: [Select]
encoder align 90º
Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;
No rotation.

Code: [Select]
encoder align 0º
Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;
No rotation.

Code: [Select]
encoder align 0º
Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;
Very weak rotation. Clockwise.

Google is my friend  8) That is very confusing. You should have torque at least in one of the two situations:

Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;

Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;

Maybe try this one as well:

Vqd.qV_Component1 = 3000;
Vqd.qV_Component2 = 3000;

That gives a 45°.

I start thinking if there is something wrong with the motor windings. Very confusing...  :o
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #255 on: March 08, 2017, 03:30:08 pm »
I think it will can very difficulty if impossible to have more progress by playing with forms and numbers. Do you have the possibility to make a setup with Hall sensors like I pictured? I think you really need to shed more light on things like electrical and mechanical rotor orientation, encoder output, phase voltages and currents. There is something very weird going on, and remember that was already the case when you tested the ST eval board.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #256 on: March 08, 2017, 05:09:42 pm »
Google is my friend  8) That is very confusing. You should have torque at least in one of the two situations:

Vqd.qV_Component1 = 0;
Vqd.qV_Component2 = 4000;

Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;

Maybe try this one as well:

Vqd.qV_Component1 = 3000;
Vqd.qV_Component2 = 3000;

That gives a 45°.

I start thinking if there is something wrong with the motor windings. Very confusing...  :o

Maybe I'm doing something very wrong  |O |O |O
But with these modifications I still have no rotation....


 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #257 on: March 08, 2017, 05:37:52 pm »
I think it will can very difficulty if impossible to have more progress by playing with forms and numbers. Do you have the possibility to make a setup with Hall sensors like I pictured? I think you really need to shed more light on things like electrical and mechanical rotor orientation, encoder output, phase voltages and currents. There is something very weird going on, and remember that was already the case when you tested the ST eval board.

I'll prepare everything to get these tests done.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #258 on: March 09, 2017, 09:02:23 am »
I had the motor running with Vqd.qV_Component2 = 3000 for ~ 15min.
I turn off the motor and it is super hot! The whole motor is really hot!
Something that I forgot to mention. Please be careful with higher values here. The driver is directly converting these into voltage. 3000 means roughly 10% bus voltage, so the power stage feeds 2.4V(peak) to the motor. If that cannot spin (or does only spin slowly), then it creates no (or little) back-emf voltage. And in this case there is nothing that limits current, except internal resistance of driver power stage, cabling and motor windings. That can easily trip your overcurrent protection (if it hasn't already). And 2.4V can then cause a lot of current flow.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #259 on: March 13, 2017, 04:53:33 pm »
- place small permanent magnet onto motor shaft/gear
- place Hall sensor in some orientation, such that it triggers once per mechanical rev, connect to scope channel, use it as trigger
- connect oscilloscope between two motor phases
- turn motor by hand and determine voltage zero crossing on scope --> this is your zero phase reference; you can now move the hall sensor such that its trigger point is right at the zero crossing; alternatively you can determine the phase between the two

I can not do this ...
The motor magnets are very strong and I can not turn with precision by hand ...
With the motor cables off, the rotor gives 6 strong bumps when rotating by hand.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #260 on: March 14, 2017, 05:02:13 pm »
If I use 6 step commutation, will I be able to have lower speeds?
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #261 on: March 14, 2017, 05:09:23 pm »
They use FOC with BLDC ....

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #262 on: March 14, 2017, 11:52:48 pm »
I'm on the road seeking for new employment, couldn't check emails...

To BLDC: these motors are sort of optimized for 6step commutation, but in my experience that does not improve closed-loop behaviour with velocity control at low speed. It makes things even worse when adding position control and can cause oscillation at standstill, because the motor can only move by 60 degree steps.

If your motor has that huge cogging that it cannot be turned by hand easily then this means to me that it is not optimized for robotics use at all. You want cogging free behaviour for that. I have used Maxxon BLDC for this purpose, they are coreless and turn 100% smooth.With anti-cogging you should be able to improve behaviour with your motors, but don't expect too much. You are limited  by their poor construction.

But anyway, there's something wrong with torque generation. When back home tomorrow I will come back with ideas to verify current phase without having to turn the motor manually

« Last Edit: March 14, 2017, 11:57:34 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #263 on: March 15, 2017, 10:26:45 am »
I'm on the road seeking for new employment, couldn't check emails...
Good luck!!

To BLDC: these motors are sort of optimized for 6step commutation, but in my experience that does not improve closed-loop behaviour with velocity control at low speed. It makes things even worse when adding position control and can cause oscillation at standstill, because the motor can only move by 60 degree steps.

If your motor has that huge cogging that it cannot be turned by hand easily then this means to me that it is not optimized for robotics use at all. You want cogging free behaviour for that. I have used Maxxon BLDC for this purpose, they are coreless and turn 100% smooth.With anti-cogging you should be able to improve behaviour with your motors, but don't expect too much. You are limited  by their poor construction.

But anyway, there's something wrong with torque generation. When back home tomorrow I will come back with ideas to verify current phase without having to turn the motor manually
What bothers me is that the seller says that he has a controller that regulates the motor speed practically from 0RPM.
I'm pretty sure they use 6-step commutation, but it's hard for me to believe they can do that kind of regulation!

PS: Watch this video of me turning the motor shaft by hand.
https://meocloud.pt/link/40b64946-03ec-450a-8910-c3945be29637/VID_20170315_100905.3gp/
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #264 on: March 15, 2017, 02:38:32 pm »
I made some adjustments on my board to run this example.

I get a slow and smooth movement ... :o

http://www.berryjam.eu/2015/04/driving-bldc-gimbals-at-super-slow-speeds-with-arduino/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #265 on: March 15, 2017, 02:59:41 pm »
I made some adjustments on my board to run this example.

I get a slow and smooth movement ... :o

http://www.berryjam.eu/2015/04/driving-bldc-gimbals-at-super-slow-speeds-with-arduino/

checked that website, he is driving the motor in a stepper-like fashion by generating three phase shifted sine waves with certain amplitude. This is similar to a test that I suggested earlier. Remember how I described to manually control the electrical angle with a small hack? If you combine that with open-loop mode, then the result *must* be exactly the same.

Currently preparing a video that describes how to check phases with a Hall sensor... Probably this evening.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #266 on: March 15, 2017, 03:08:26 pm »
Good luck!!
thanks  :)

What bothers me is that the seller says that he has a controller that regulates the motor speed practically from 0RPM.
I'm pretty sure they use 6-step commutation, but it's hard for me to believe they can do that kind of regulation!
when looking at your video, and looking at the phase current and voltage measurements that you did in the past, I would expect that your FOC solution should perform better that it currently does. But as you also experience too little torque and heated up motors, I think the most important part is to get that problem solved. I expect that, once that encoder alignment and motor phase voltages and currents are working as they should, your low-rpm results will drastically improve as well.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #267 on: March 15, 2017, 03:39:55 pm »
I'm having trouble for quite some time ...

I'm wondering if it's not better build my own firmware that does a mix of SVPWM and 6-step commutation.
I have not start yet because I can not understand how I can control current. In other words, in brushless motors the speed is related to the frequency and the torque is related to the duty cycle of the PWM.
If the motor starts to slow down, my control should increase the duty cycle, but also reduce the step frequency, so that the rotor does not lose the magnetic field.
But the control
is still not clear to me ...  |O
« Last Edit: March 15, 2017, 04:08:32 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #268 on: March 15, 2017, 05:48:18 pm »
Maybe a mixed control will work.

Low revs
Stepper motor (SVPWM)

High revs
6 step commutation

I understand the control in 6 step commutation, but in low revs I can not figure it out (using SVPWM).
In a stepper motor the switching frequency is related to the speed of rotation, but I can not understand how to make the PWM duty cycle adjustment ...
 

Offline nuno

  • Frequent Contributor
  • **
  • Posts: 606
  • Country: pt
Re: Problems with STM32 PMSM FOC SDK
« Reply #269 on: March 15, 2017, 06:31:13 pm »
At low speeds there's hardly any back EMF. Some FOC systems still have halls, I think mainly for starting in the right direction without "attempts" but probably for low speeds too.
You can try a "Lebowski controller" too, put it on google.
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #270 on: March 15, 2017, 06:39:18 pm »
Hello nuno

Thanks for comment.

I am using an incremental encoder of 500ppr.

This is my feedback to the controller.

There should be no problem, but at low speed the motor does not run smooth...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #271 on: March 15, 2017, 09:15:01 pm »
I have prepared some videos that show how I validated the relationship between phase voltages, phase currents, and the rotor position feedback. Hope this helps

https://www.kicksurfer.de/index.php/2017/03/15/bldc-motor-and-foc-controller-phase-current-validation/

I did an extra video for you that shows how it should look like when you use open-loop control. You can see that the phase current signal looks just as good, and is in perfect phase with the Hall sensor / back-emf.

https://www.kicksurfer.de/index.php/2017/03/15/video2


We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #272 on: March 15, 2017, 09:38:54 pm »
Maybe a mixed control will work.

Low revs
Stepper motor (SVPWM)

High revs
6 step commutation

I understand the control in 6 step commutation, but in low revs I can not figure it out (using SVPWM).
In a stepper motor the switching frequency is related to the speed of rotation, but I can not understand how to make the PWM duty cycle adjustment ...

(please don't confuse terms - SVPWM is just describing a way to create three 120°-spaced sinusodial phase voltages. That's what FOC is using, and that's what is used in the video. FOC calculates the amplitude and orientation/frequency to turn the motor into a motor, and the guy from the video gives fixed amplitude (100%) and programmable frequency.)

At high revs, there is no advantage of 6-step commutation over FOC.

The problem with a stepper motor is that you always have to run it at maximum current, as it does not have a mechanism to detect its shaft load. If current is too low for the given load, it will "jump". If current is always max, it will quickly heat up. I don't think that this is a good strategy.

You can try this out by turning the ST FOC into a stepper controller:

a) forced rotor angle (here you can set the speed by changing the increment step) as already explained:

Code: [Select]
uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));

  // <<<<<<<<<<<<<<<<<
  if( StateM1 == RUN )
  {
    static int16_t k=0; k+=10; hElAngledpp=k;
  }
  // <<<<<<<<<<<<<<<<<

 ...



b) set controller to torque mode in STMCWB, and apply current.

This way the FOC algorithm will just create three sinusodial phase currents, rotating at a given frequency, no matter what the motor is doing. The encoder feedback is not used here.

Then, try to stop the output shaft and see how the motor "jumps".

I still think that the problem is neither the motor nor the control scheme, but a remaining problem with the voltage/current/mech_position relationships. I'm sure that you can find it.

One hint: when you try to turn the motor to do the Hall sensor measurements I proposed, can you extend the shaft with locking pliers or similar? I did that with the Maxxon motor, it had a similar output gear as your motor. You can attach the permanent magnet for the Hall sensor to its arm then.
« Last Edit: March 15, 2017, 10:55:41 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #273 on: March 15, 2017, 11:11:44 pm »
One hint: when you try to turn the motor to do the Hall sensor measurements I proposed, can you extend the shaft with locking pliers or similar? I did that with the Maxxon motor, it had a similar output gear as your motor. You can attach the permanent magnet for the Hall sensor to its arm then.

Thanks for all the information.

Tomorrow I will insist on all this and see if I start to get results.

I will make a plastic part to be able to fit into the motor shaft gear.

PS: I've been watching the STM forum and there are some complaints of problems at low speeds. However, the general problems are because they all use sensorless ... which is not my case.
« Last Edit: March 15, 2017, 11:14:20 pm by Dave_PT »
 

Offline nuno

  • Frequent Contributor
  • **
  • Posts: 606
  • Country: pt
Re: Problems with STM32 PMSM FOC SDK
« Reply #274 on: March 16, 2017, 02:10:00 am »
I didn't read the whole thread, just picked on the slow motion problems, yeah, sorry. Are you sure your encoder is behaving well at low speed? Or maybe the code isn't prepared to or doing enough "debouncing" on the encoder's signal (don't know which encoder you're using). Throwing out some possible causes at you :P
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #275 on: March 16, 2017, 07:40:07 am »
PS: I've been watching the STM forum and there are some complaints of problems at low speeds. However, the general problems are because they all use sensorless ... which is not my case.
I've also experienced that. I think that their mathematical models that translate motor parameters into parameters for their sensorless observer implementation aren't very good. I ended up with doing things in reverse, changing the STMCWB motor parameters and watching how that affected stability and accuracy. And I learned that probably only the Cordic algorithm is usable, I never managed to get the PLL mode stable under all speed/load conditions. But doing so, I came to satisfactory results. The motor is controllable down to 15 rpm (mechanically) / 4 Hz (electrically). (I hear you asking: no, no cogging at all... 8))
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #276 on: March 16, 2017, 10:41:40 am »
I have prepared some videos that show how I validated the relationship between phase voltages, phase currents, and the rotor position feedback. Hope this helps

https://www.kicksurfer.de/index.php/2017/03/15/bldc-motor-and-foc-controller-phase-current-validation/

In the 2nd video I can not get a perfect wave if I turn without the gearbox.
In the picture, the blue line is the phase-star voltage.



Only with the gearbox I can have a perfect sinosoid.
I was able to align the encoder with the phase voltage.



I'm watching current Ia via DAC.
I'm triggering whith the sensor hall. But current Ia does not "stay in the same place"... does not stay synchronous.

https://meocloud.pt/link/24b6ff74-3164-4a8c-9493-e7d551fe78e8/VID_20170316_103615.3gp/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #277 on: March 16, 2017, 10:59:17 am »
I was able to align the encoder with the phase voltage.
Just to be sure: you mean the Hall senror here, right?

I'm triggering whith the sensor hall. But current Ia does not "stay in the same place"... does not stay synchronous.
wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?

Some other questions/ideas:
- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.
- did you load the motor during phase current measurement?
- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.
- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?
« Last Edit: March 16, 2017, 11:04:38 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #278 on: March 16, 2017, 11:04:35 am »
I was able to align the encoder with the phase voltage.
Just to be sure: you mean the Hall senror here, right?

Yes yes... my mistake.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #279 on: March 16, 2017, 11:05:56 am »
I was able to align the encoder with the phase voltage.
Just to be sure: you mean the Hall senror here, right?

Yes yes... my mistake.
sorry by being picky, but that's necessary for me to follow closely from my "remote" position  ;)
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #280 on: March 16, 2017, 11:28:18 am »
wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?
Apparently yes.
I do not have any current probe, so I'm watching it by the DAC of the micro. Can there be some delay here? But it should be constant, right?
Is the current Ia to be observed?

- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.
The reduction is 29: 1.

- did you load the motor during phase current measurement?
Yes. The amplitude got bigger, but the timing was the same.

- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.
I was using the DAC to see Ia, but now I made probe at the ampop output. The result is the same.
https://meocloud.pt/link/1709d055-2f11-4f86-9a4f-60022009ac78/VID_20170316_111607.3gp/

- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?
I do not know if I understood correctly ... but would have to disconnect the motor again, put it like the first video and measure Vphase?


Another video.
Hall sensor with electrical angle.
https://meocloud.pt/link/9e546b85-a8cb-41aa-a6dd-bacc134cc18c/VID_20170316_112436.3gp/
« Last Edit: March 16, 2017, 11:31:09 am by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #281 on: March 16, 2017, 11:35:14 am »
I didn't read the whole thread, just picked on the slow motion problems, yeah, sorry. Are you sure your encoder is behaving well at low speed? Or maybe the code isn't prepared to or doing enough "debouncing" on the encoder's signal (don't know which encoder you're using). Throwing out some possible causes at you :P

Yes, the thread is already going long!
Thanks to the precious help of tatus1969.

I've already manually turned the motor shaft and saw the encoder outputs (A + B) and that's fine.

But I'm beginning to believe that there might be some limitation in the firmware that prevents low revs. However I start to have problems below 300 / 400RPM ... it's not really "low revs"  :-//
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #282 on: March 16, 2017, 11:58:05 am »
...

a) forced rotor angle (here you can set the speed by changing the increment step) as already explained:
...

b) set controller to torque mode in STMCWB, and apply current.

This way the FOC algorithm will just create three sinusodial phase currents, rotating at a given frequency, no matter what the motor is doing. The encoder feedback is not used here.

...

This is it.

It runs in a similar way to what I did yesterday.

If I increase Iqref I feel the engine making more force before jumping.

I write 6 step commutation for being a simpler control method and I can do the whole firmware.
But in stepper the torque control gets very complicated...
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #283 on: March 16, 2017, 12:15:40 pm »
wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?
Apparently yes.
I do not have any current probe, so I'm watching it by the DAC of the micro. Can there be some delay here? But it should be constant, right?
Is the current Ia to be observed?

- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.
The reduction is 29: 1.

- did you load the motor during phase current measurement?
Yes. The amplitude got bigger, but the timing was the same.

- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.
I was using the DAC to see Ia, but now I made probe at the ampop output. The result is the same.
https://meocloud.pt/link/1709d055-2f11-4f86-9a4f-60022009ac78/VID_20170316_111607.3gp/

- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?
I do not know if I understood correctly ... but would have to disconnect the motor again, put it like the first video and measure Vphase?


Another video.
Hall sensor with electrical angle.
https://meocloud.pt/link/9e546b85-a8cb-41aa-a6dd-bacc134cc18c/VID_20170316_112436.3gp/
Now that is certainly the breakthrough.

Summarizing: the gear reduction ratio is integer, proven by the fact that motor phase voltage stays synchronous with hall sensor. The encoder output (and thus also the current waveform, as it is generated from it) is *not* synchronous to the hall sensor.

This definitely means that the encoder's count per (mechanical) revolution is wrong. This also explains the huge cogging and low generated torque. It also explains the results from your experiments with open-loop control. I suggest that you concentrate now on getting the hall sensor / electrical to stay synchronized. As you have 2 pole pairs and a gear reduction rate of 29:1, you should expect to see exactly 58 full sawtooths per hall sensor pulse, and all that in synchronosity. As long as you don't see that, you can be sure that you have a mismatch between the generated encoder ppr and the expected number by the FOC library.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #284 on: March 16, 2017, 12:35:22 pm »
This definitely means that the encoder's count per (mechanical) revolution is wrong. This also explains the huge cogging and low generated torque. It also explains the results from your experiments with open-loop control. I suggest that you concentrate now on getting the hall sensor / electrical to stay synchronized. As you have 2 pole pairs and a gear reduction rate of 29:1, you should expect to see exactly 58 full sawtooths per hall sensor pulse, and all that in synchronosity. As long as you don't see that, you can be sure that you have a mismatch between the generated encoder ppr and the expected number by the FOC library.

I already tested it yesterday and I was able to verify that the encoder pulses are correct.

I'll redo the tests again.

In speed control for 1500RPM.

(1500RPM / ratio 29) / 60 = 0.862Hz

The electrical rotations between the  hall sensor pulses are 58.


« Last Edit: March 16, 2017, 02:36:29 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #285 on: March 16, 2017, 01:08:42 pm »
The electrical rotations between the  hall sensor pulses are 58.
If it were exactly 58, then you would see synchronicity between hall and encoder. Which you don't. Its probably 58.01, or 57.99.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #286 on: March 16, 2017, 01:14:15 pm »

That's not a proof that the encoder is counting correctly. It it would count 501ppr instead of 500, then you would not be able to notice it from the measurement that you show here... What do you see if you zoom in at both cursor positions? You should see exactly the same voltage at AOUT whenever the hall sensor output is at trigger level.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #287 on: March 16, 2017, 03:03:31 pm »
Can such a small difference be caused by the gear box and the error wheel - hall sensor?

The encoder is set to 500ppr so you should only produce these pulses for each mec. Rev. ...

In fact there is a slight difference at the end of a rotation ...

First pulse:


Last pulse:


After doing the math, there are about 57.94 pulses.
Therefore the encoder counts 500.52 pulses per rotation.
I have an error of approx 0.36º.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #288 on: March 16, 2017, 03:27:01 pm »
If I change the encoder pulses per revolution to 501 or to 499, the effect is this.
The motor does some rotation and then stops.

https://meocloud.pt/link/c76a2aa2-0a29-4f02-9a8d-a242b5ef009c/VID_20170316_152233.3gp/
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #289 on: March 16, 2017, 05:21:21 pm »
These are planetary gear boxes, unless there is a mechanical problem like a loose motor gear, they cannot slip.

I checked the motor datasheet where they list the available gear reduction ratios, that lists a 2-stage planetary gear box with a reduction ratio of 28.9. Nothing with 1:29.


Are you absolutely sure that the phase voltage was always in sync with the hall sensor?

Your test with ppr=499 and 501 also suggests that the encoder ppr=500 is correct, and that the out-of-sync between hall and encoder/current comes from a fractional gearbox reduction ratio.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms

From that I calculate a lag of 2.4 / 58 / 19 = 0.218%.

If the gearbox is 1:28.9 instead of 1:29.0, then this would cause a lag of 0.1/29.0 = 0.345%.

Just one more question: the sawtooth in the screenshots is motor electrical angle, and not "raw" encoder angle, right? Otherwise I would have expected ~29 cycles only per wheel rev.
« Last Edit: March 16, 2017, 05:23:31 pm by tatus1969 »
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: nuno

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #290 on: March 16, 2017, 05:43:06 pm »
I'm not sure there was any printing error, but on the sticker I got the indication that it's a 29: 1 reduction box


Are you absolutely sure that the phase voltage was always in sync with the hall sensor?
That's the best I can do manually.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms
I can give you these values.

- time for one electrical motor rev = 20.02ms
- lag of hall sensor after 58 electrical motor revs = 1.7ms

1.7/58/20.02 = 0.00146

Just one more question: the sawtooth in the screenshots is motor electrical angle, and not "raw" encoder angle, right? Otherwise I would have expected ~29 cycles only per wheel rev.
Yes. The sawtooth wave is the electrical angle motor.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #291 on: March 16, 2017, 05:46:00 pm »
 |O |O |O |O |O |O |O

It's not easy to solve this.

 |O |O |O |O |O |O |O
 

Offline nuno

  • Frequent Contributor
  • **
  • Posts: 606
  • Country: pt
Re: Problems with STM32 PMSM FOC SDK
« Reply #292 on: March 17, 2017, 12:01:33 am »
Thanks to the precious help of tatus1969.
:-+


Maybe they rounded the number for the sticker.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Problems with STM32 PMSM FOC SDK
« Reply #293 on: March 17, 2017, 06:23:13 am »
I have not read the entire thread, just the last bits, so I might have
missed something... That said, if I understand correctly there is still some
uncertainty regarding the gear ratio, correct?

It should be 29:1 , but it just might be 28.9:1.

In the measurement in this image it's indeed rather difficult to guess if it's 29:1 or 28.9:1.



Maybe you've already done what I'm about to suggest, in which case disregard. :)
But if not, one possibility is this:

1 - Trigger on the positive edge of the blue signal
2 - change timebase such that you get about 2.5 full waveforms in view.
    If you use 1500 RPM ==> 25 revs/sec, then a timebase of 10 ms / div
    should do just that.
3 - Turn on persistence
4 - Use the right trigger type ....

And the "right" trigger type depends a bit on the capabilities of your
scope. If it can do equivalent time sampling, use that. If it doesn't
have ETS then you probably can do a divide-by-N. As in set it to trigger
on every Nth positive going edge of the blue signal. So what N to choose?

The two candidate ratios and their prime decompositions are:
29:1   --> 290/10 = 290/(2*5) =      29/1
28.9:1 --> 289/10 = 289/(2*5) = (17*17)/(2*5)
                         ^^^--------------------------- See (*) comment below about 2's in the denominator.


Triggering is always on the blue signal.

Now if you trigger on every 290th edge, with persistence on then:
If you have a 29:1 gear then for those 290 edges in the blue signal you
should get 10 edges in the orange signal. Nice integer multiples. If on the
other hand you happen to have a 28.9:1 gear then no nice integer multiples.

Possible results:
A1 - Nice clean edges for the orange signal   ==> absence of bad news, probably good news (29:1 as you expect)
A2 - Orange signal smeared all over the place ==> Nope, that's no 29:1 gear ratio

And as a sanity check do it the other way around. Trigger on every 289th edge, again with persistence on.

Now the possible results are:
B1 - Nice clean edges for the orange signal   ==> absence of good news, probably bad news (28.9:1, nooooo)
B2 - Orange signal smeared all over the place ==> highly unlikely it's a 28.9:1 gear ratio

What you want is results A1 and B2. Then it's pretty sure that it is a 29:1 gear, and not a 29.9:1 gear.

What you definitely do not want is results A2 and B1, because then in all likelyhood it's a 28.9:1 ratio
as per the datasheet that tatus1969 mentioned.

Is say things like "pretty sure" and "probably" because I've seen enough
funky shit with triggering on some scopes. Anyways, you will be able
to judge that since you know your scope. Case in point, on my HP boat anchor
I would trust the results and say "sure" and "certain". But doing those same
measurements on my rigol I would have to stick with "pretty sure" and "probably".  ;)

(*) If you worry about a factor of 2 because I "accidentally" used a factor of
29 instead of 58, then no worries. I did that accidentally on purpose. We can
happily ignore this factor of 2 because both ratios have a 2 in the denominator
of the prime decomposition.

So if you insist on a factor of 58 then you still get similar results. The main
difference being that now for every 290 (**) blue edges, you would get 5 orange
edges instead of 10.

(**) Well, either 290 or 289, depending on it being a 29:1 or a 28.9:1 gear.

Anyways, hope this helps in finding out what's going on. :)

PS: Assuming that 1500 RPM really is 1500 RPM, then based purely on the delta T for Cursor 1 the ratio is closer to 28.9:1 than 29:1.
Depends a bit on the standard deviation. Oh yeah, almost forgot to mention that. If you turn on the statistics for that
Cursor 1 then you might be able to do an educated guess too. If the stddev on that 1.154 s is high, then chances are good that it is not 29:1.
If the stddev is low, then it probably is 29:1. And this "high" and "low" being relative to the period of the blue signal. Quick guess ... stddev
larger than 1/3 * period of blue signal ==> probably not an integer multiple, so no 29:1 ratio.
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #294 on: March 17, 2017, 10:32:05 am »
I'm not sure there was any printing error, but on the sticker I got the indication that it's a 29: 1 reduction box

The manufacturers ofen round the numbers. From the label plate, the gearbox could be this one here:

https://www.imsgear.com/en/imsbaseline?file=tl_files/assets/downloads/engl/products/PLG/IMS.baseline_PM52_EN.pdf

They have a model with reduction ratio 1:28.93

Are you absolutely sure that the phase voltage was always in sync with the hall sensor?
That's the best I can do manually.
I guess that you were moving the wheel forth and back around the hall sensor trigger point when aligning the motor phase, and that you didn't make do full revs of the wheel at this time. So probably if you would repeat that setup and do that, you would also see the phase walking around.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms
I can give you these values.

- time for one electrical motor rev = 20.02ms
- lag of hall sensor after 58 electrical motor revs = 1.7ms

1.7/58/20.02 = 0.00146
If my guess for that gearbox is right, then it does a slip of (29 - 28.93) / 29 = 0.0024. Not very close, but maybe close enough to come to this conclusion.

To me this means
- the encoder ppr is properly setup. It measures exactly 1 mech / 2 electrical cycles per real mech rev. The test with 499 / 501 ppr proves this best. When the motor can run continuously on 500ppr, you also know that the signal integrity is good.
- the gear box does not have an integer ratio, so you cannot use a magnet on the wheel for these measurements
- your encoder alignment does not work yet, so we have to come up with a different approach to find a working alignment angle

Does your encoder have an index channel? If yes, and because I think that we can trust the encoder signal, then you could use that instead of an external hall sensor for scope triggering.

Then, can you use the output gear of your second motor to drive the one under test, to obtain nice back-emf voltage waveforms?

If that is all not feasible, then I have a different approach. The goal of all this is to find the correct rotor angle. If you have that, then the motor will operate with maximum torque in both spinning directions. If you are off by 90°, then the motor will produce zero torque. If you are off by a small amount, then the motor will spin better in one direction than in the other.

We can use this to find the best angle. What you can do is, to repeat the open-loop setup with

Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;

You also need to load the output shaft in a controlled way. You could connect the two motors back-to-back, and use the second one as a generator. Use 6 diodes to create a three-phase full wave rectifier, and connect a power resistor to the output. You could even use the power stage of your FOC controller, and connect the resistor directly across the DC bus. The MOSFET's body diodes will act as the recifier then.

Then, adjust the encoder alignment angle in small steps, from -90° to +90°, lets say in 5° steps.

Each time, run the alignment (I suggest to use maximum target current here, and 1s alignment time), and let the motor drive the load. Watch the resulting rpm under load.

After you have found the alignment angle that results in the most rpm under load, then repeat the test with this setting

Vqd.qV_Component1 = -4000;
Vqd.qV_Component2 = 0;

This reverses spinning direction. Watch if you get the same rpm. If not, then continue searching for the right alignment angle, until you find one that produces the same rpm under load in both spinning directions.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #295 on: March 17, 2017, 10:36:20 am »
Thanks to the precious help of tatus1969.
:-+
Always good to receive other opinions, we're a bit stuck here.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #296 on: March 17, 2017, 11:52:22 pm »
Thanks for all the answers.
I'll read everything carefully.

For now I have a question.

Does your encoder have an index channel? If yes, and because I think that we can trust the encoder signal, then you could use that instead of an external hall sensor for scope triggering.

Then, can you use the output gear of your second motor to drive the one under test, to obtain nice back-emf voltage waveforms?
My encoder has an index channel.
I can use it to trigger the oscilloscope.
In theory the index signal will always appear on the same point of the Bemf wave, right? - in this case, the index will appear every 2 revolutions.

What are we looking here?
Any lags?

Another thing that is creating doubts ...
If I were to use a hall encoder, I understand that it would be important to align the magnet with the rotor and get the UVW switches at the right time.
If I am using an incremental encoder, should the encoder alignment angle not always be zero?
I think that when encoder alignment is done, the algorithm simply clears the timer 2 register and all calculations are done based on that.
This was the great advantage of being able to do self alignment. The magnet is glued to the motor shaft at any position and the auto alignment compensates for the deviation.

Modifying encoder alignment angle is the same as rotating the magnet.

Am I realizing this well?



PS:
I'm thinking that the problem might be the SDK or FOC algorithm in this motor...
I've been seeing alternatives and these may be the best if we do not get any progress from here.
What do you think?

https://my.st.com/content/ccc/resource/technical/document/user_manual/group0/90/b6/9f/0c/50/c1/47/1d/DM00334922/files/DM00334922.pdf/jcr:content/translations/en.DM00334922.pdf
« Last Edit: March 17, 2017, 11:56:52 pm by Dave_PT »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #297 on: March 18, 2017, 08:47:59 am »
My encoder has an index channel.
I can use it to trigger the oscilloscope.
In theory the index signal will always appear on the same point of the Bemf wave, right? - in this case, the index will appear every 2 revolutions.
Exactly.

What are we looking here?
Any lags?
No. As you explain further below in your reply, that is fully compensated for during encoder alignment. Let me explain what I am trying to achieve with the methods that I proposed in my last posts.

First, to the encoder alignment procedure. In details, it works this way:
- force electrical angle to the angle that you provided as the "offset" in STMCWB, and keep it like that during the entire procedure (they do this by temporarily switching to a "virtual" speed feedback module that does not listen to any sensor, it just holds the angle that you give it)
- linearly ramp up current with Iq=0 and Id=current
- when the ramp has reached its final level, then also set the electrical angle of the encoder feedback module to the offset value that you provided
- set current to zero again, switch to encoder position feedback, motor can start

You have to look closely to what happens here, they did some clever things that are not easy to notice. At first, they do "Iq=0 and Id=current". During normal operation, you know that you will do "Iq=current and Id=0" instead. The trick here is: when they ramp up the current at a given (and constant) electrical angle, then the motor will lock into that angle which yields minimum magnetic force. This angle is exactly 90° away from the one with maximum force that we are seeking for. The vectors "Iq=0 and Id=current" and "Iq=current and Id=0" are just those 90° apart from each other.

The other trick is regarding the offset. As I mentioned earlier, it is not just added somewhere. The idea here is to give you the choice at which absolute electrical angle you want the alignment procedure to happen. If you set that to 0°, then the procedure will create a 3-phase current with (x + 90°) angle (the 90° comes from using Iq instead of Iq), meaning U=cos(x+90°)*current, V=cos(x+210°)*current, W=cos(x+330°)*current. If you would increase that offset angle stepwise and repeatedly execute the alignment, then you would actually see the motor rotating slowly. It is basically the same as doing that stepper motor scheme.

The last part of the trick is quite simple: when the alignment is done with a 3-phase current at angle (x + 90°), then it can be expected that the motor has been mechanically locked to angle (x + 90°), and we know that angle x will be the one that will yield maximum torque. So they set the encoder angle to x.

There is one very important thing to understand here. During alignment, the motor jumps to an angle with zero torque. But what we want to find is the angle that would do maximum torque. So we have to assume that they are exactly 90° away from each other.

Here lies the problem: this assumption implies that the motor behaves sinusodial. Your motor is far away from that. So if the alignment procedure creates a current vector of 0°, then the motor may lock into a physical angle of e.g. 30°. And we also cannot assume that the angle of maximum torque is 90° away from that.

But what we know is that the alignment error that we have is something that moves around the correct value once we start varying the offset angle. There will be settings where we measure a too high angle, there will be some where we measure a too low value, but there also will be offsets that happen to result in correct alignment.

Therefore I proposed to stepwise vary the alignment offset. But how can you measure how good the alignment was (how close it is to producing max torque)? Therefore I proposed two methods:
1) comparing back-emf voltage with generated phase current, they are exactly in phase on success. All you need to do here is repeat the procedure, but use the index channel to trigger.
2) apply torque and run the motor in both directions. If torque is equally high, then success.

Phew... hope I explained clearly :o

Another thing that is creating doubts ...
If I were to use a hall encoder, I understand that it would be important to align the magnet with the rotor and get the UVW switches at the right time.
That is only true for 6-step algorithms. FOC works differently here, because it has to interpolate between the 6 states that it receives, in order to maintain an electrical angle value with fine resolution. Otherwise it could not produce sinusodial waveforms. You can better see the hall encoder as a low-update-rate speed and position sensor here. You can imagine that it is very easy for them to allow an angular offset to all this. You can set this in the hall sensor config page. So, the actual orientation here is not important (in contrast to 6-step commutation!).

PS:
I'm thinking that the problem might be the SDK or FOC algorithm in this motor...
I've been seeing alternatives and these may be the best if we do not get any progress from here.
What do you think?

https://my.st.com/content/ccc/resource/technical/document/user_manual/group0/90/b6/9f/0c/50/c1/47/1d/DM00334922/files/DM00334922.pdf/jcr:content/translations/en.DM00334922.pdf
I think that, after you have debugged the alignment process, you will end up with a setup with correct angle relationships creating maximum torque. And the jumpiness at low revs will also be drastically reduced.

EDIT: As your goal is softness at low revs, you will not come closer to it by switching to  6-step commutation, because that can only jump into 6 different states / angles per electrical rev.
« Last Edit: March 18, 2017, 09:00:43 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #298 on: March 20, 2017, 11:39:39 am »
is it possible that there is a problem in the power stage, or the current sensing? to check that, you can run the motor again as stepper, and probe the three phase voltages (add a RC lowpass before the scope probe) as well as Ia and Ib via DAC. the currents must be perfect sinusodial, and the voltages must be SVPWM style. scratching my head of what is happening there at your desk.

can you notice that the motor locks at changing angles when you change the alignment offset? does it start when you help it manually? if not, does it feel the same in both directions?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #299 on: March 20, 2017, 12:20:00 pm »
I've been varying the angles to see when the motor runs.
I have had values in which the motor does not spin and others in which it spin.

But when I connected the motor to the gear box, the motor does not have enough torque to turn the gears at any angle.

I will continue to vary values and observe what happens.
« Last Edit: March 20, 2017, 12:21:43 pm by Dave_PT »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #300 on: March 20, 2017, 12:52:19 pm »
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!  :palm:
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #301 on: March 20, 2017, 12:57:19 pm »
one idea: have you added that if(RUN)... around your open loop code? it is absolutely essential.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #302 on: March 20, 2017, 01:00:01 pm »
one idea: have you added that if(RUN)... around your open loop code? it is absolutely essential.

Yes. I think that's right.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #303 on: March 20, 2017, 01:06:13 pm »
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?
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #304 on: March 20, 2017, 02:22:50 pm »
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.

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #305 on: March 20, 2017, 02:40:41 pm »
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!
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #306 on: March 20, 2017, 02:54:23 pm »
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.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #307 on: March 20, 2017, 03:22:03 pm »
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!
:-+ :-+
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #308 on: March 20, 2017, 05:01:35 pm »
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.
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #309 on: March 20, 2017, 06:38:05 pm »
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.



 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #310 on: March 20, 2017, 09:49:42 pm »
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?


 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #311 on: March 20, 2017, 10:03:54 pm »
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.
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #312 on: March 20, 2017, 10:06:56 pm »
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).
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #313 on: March 20, 2017, 10:09:28 pm »
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?
We Are The Watt - Resistance Is Futile!
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #314 on: March 20, 2017, 10:16:42 pm »
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.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #315 on: March 20, 2017, 10:40:15 pm »
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  :phew:!

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.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #316 on: March 21, 2017, 06:48:05 am »
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.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #317 on: March 21, 2017, 12:45:49 pm »
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 ...
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #318 on: September 28, 2017, 10:00:13 pm »
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
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #319 on: September 29, 2017, 10:52:07 am »
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?
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: bayetan

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #320 on: October 02, 2017, 12:35:09 pm »
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

 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #321 on: October 02, 2017, 08:10:02 pm »
Is there a better ISR handle that I can toggle the pin on
The SysTick ISR is perfect for this purpuse :-+
We Are The Watt - Resistance Is Futile!
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #322 on: October 09, 2017, 05:52:23 pm »
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
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #323 on: October 09, 2017, 06:46:23 pm »
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.
« Last Edit: October 09, 2017, 06:53:41 pm by bayetan »
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #324 on: October 10, 2017, 01:30:55 am »
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! :clap: 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.
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #325 on: October 11, 2017, 08:06:35 am »
Here is the final configuration I had for the Nucelo F303RE and IHM08M1 to get FOC to work with Debug output.

1) Do everything specified by Motor Profiler (http://localhost:5331/mp/bundle?ctrl=NUCLEO-F303RE&pwr=X-NUCLEO-IHM08M1%203Sh)
2) Remove SB21 on F303RE (LD2 interferes with signal on PA5)
3) On IHM08M1
  • install R76, remove R77, install R80, remove R82, remove R85
  • remove R181 - conflicts with Pot from speed controller
  • remove R63 - conflicts with BEMF3
  • remove R21 - This is also used CURRENT REF which is input to OpAmp through a low pass filter so in the case of Observer Electric angle, the saw-tooth will appear chopped at the end.
I think I finally got this FOC working.  Now time to start with the real design work.  Below is the screen capture of both Debug displaying Observer Electric Angel when the Motor was spinning at 1200 RPM.
« Last Edit: October 11, 2017, 08:09:45 am by bayetan »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #326 on: October 12, 2017, 09:51:14 am »
Would you happen to know how I can setup the Peripherals register view on IAR?
There is a "Registers" entry in the debugging menu. But that "HSEStatus" is not a controller register, but just a variable. To be able to debug this realiably, you should disable compiler optimizations.

Actually, it was't the optimization that effected the code size but the options enabled in the Motor Control/Drive parameters.
Both of them affect the code size, but you'll always be close to the 32k. You can also reduce the code size by choosing a more restricted standard library, if you can live with things like printf being restricted to integers. Go to the project options -> General options -> Library Options (and Library Configuration). There, choose smaller options.

finally got this FOC working.

 :-+

We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: bayetan

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #327 on: October 14, 2017, 01:07:34 pm »
I forgot that Debug and Optimization just don't go together on IAR.  But the debug feature (peripheral memory) that exists on Eclipse through Pack (CMSIS) is shown below.  I think its really useful but I can find or get the equivalent thing to work on IAR.  They have something CMSIS-Pack Installer but I just don't see anything change once I've installed it.

Thanks for the information about the restricted standard library.  I was able to compile with all the options I need without going over the 32k limit.  Do you know if moving to a Dual system will increase the size much?

And have you had any luck working with STM32F4 series.  I would at some point need move to F4 but I'm still unable to communicate with uC using Motor Controller Workbench.  Given that my SysTick configured at 1mS is still at ~3.125 mS on the scope, I'm sure that has something to do with it but haven't had much luck getting that resolved.

And I'll like to get some advice on motor selection and my current Motor parameters is below.  Voltage should be 24 V and current should be more than 10 A with lots of inertia and friction in my applications.  I would like to use a 12 power supply and so would like to change the motor to 12 V version which has quarter the resistance and inductance but I decided against because the ST Motor Porfiler was not "optimum"  for inductance below 0.1 mH, I think.  Do you think I can get FOC to work with a motor that has quarter the inductance and quarter the resistance of my current one.

Thank,
Ben
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #328 on: October 14, 2017, 05:18:28 pm »
I can find or get the equivalent thing to work on IAR.
Start a debugging session, then in the menu: View -> Register. There you can select the peripheral that you want to see. You can open this window multiple times.

Do you know if moving to a Dual system will increase the size much?
Haven't done that yet.

And have you had any luck working with STM32F4 series.  I would at some point need move to F4 but I'm still unable to communicate with uC using Motor Controller Workbench.  Given that my SysTick configured at 1mS is still at ~3.125 mS on the scope, I'm sure that has something to do with it but haven't had much luck getting that resolved.
They are well supported. Have you checked in STMCWB to select the right processor, and to match the used crystal frequency? Also, make sure to load the right project.

And I'll like to get some advice on motor selection and my current Motor parameters is below.  Voltage should be 24 V and current should be more than 10 A with lots of inertia and friction in my applications.  I would like to use a 12 power supply and so would like to change the motor to 12 V version which has quarter the resistance and inductance but I decided against because the ST Motor Porfiler was not "optimum"  for inductance below 0.1 mH, I think.  Do you think I can get FOC to work with a motor that has quarter the inductance and quarter the resistance of my current one.
I am using the library with motors having inductances as low as 50uH, still running well. It also depends: are you going to use a sensorless motor? If your motor is sensored, then some of these values are irrelevant. I am not using the motor profiler but measure the values directly on the motor.
We Are The Watt - Resistance Is Futile!
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: Problems with STM32 PMSM FOC SDK
« Reply #329 on: October 16, 2017, 02:15:10 pm »
Hi, guyes
I was just wondering if it's possible to use this SDK with STM32F030K6T6, since it's one of the cheapest parts and I want to design an ESC for my Quadcopter  motors.
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #330 on: October 16, 2017, 02:29:23 pm »
Hi, guyes
I was just wondering if it's possible to use this SDK with STM32F030K6T6, since it's one of the cheapest parts and I want to design an ESC for my Quadcopter  motors.
These are supported. But they are 32MHz only, and I wouldn't use them for high rpm / high pole count outrunners.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: ali_asadzadeh

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: Problems with STM32 PMSM FOC SDK
« Reply #331 on: October 17, 2017, 06:44:29 am »
Thanks, but they are 48MHz ;)  and 0.5$ in quantity
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #332 on: October 31, 2017, 08:55:40 am »
I can find or get the equivalent thing to work on IAR.
Start a debugging session, then in the menu: View -> Register. There you can select the peripheral that you want to see. You can open this window multiple times.
After spending sometime with it, I finally realized that everything was hidden behind right-click context menu.  Thanks.
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #333 on: October 31, 2017, 09:04:57 am »

And have you had any luck working with STM32F4 series.  I would at some point need move to F4 but I'm still unable to communicate with uC using Motor Controller Workbench.  Given that my SysTick configured at 1mS is still at ~3.125 mS on the scope, I'm sure that has something to do with it but haven't had much luck getting that resolved.
They are well supported. Have you checked in STMCWB to select the right processor, and to match the used crystal frequency? Also, make sure to load the right project.

You were right about the frequency.  I ignored the "external crystal frequency" in the STMCWB because I assumed I was using the internal one and figured it didn't apply.  Apparently it did and the option selected was 25 MHz when I had 8 MHz, whose ratio is exactly 3.125.  Thanks.
 

Offline bayetan

  • Contributor
  • Posts: 10
  • Country: us
Re: Problems with STM32 PMSM FOC SDK
« Reply #334 on: October 31, 2017, 09:40:30 am »

And I'll like to get some advice on motor selection and my current Motor parameters is below.  Voltage should be 24 V and current should be more than 10 A with lots of inertia and friction in my applications.  I would like to use a 12 power supply and so would like to change the motor to 12 V version which has quarter the resistance and inductance but I decided against because the ST Motor Porfiler was not "optimum"  for inductance below 0.1 mH, I think.  Do you think I can get FOC to work with a motor that has quarter the inductance and quarter the resistance of my current one.
I am using the library with motors having inductances as low as 50uH, still running well. It also depends: are you going to use a sensorless motor? If your motor is sensored, then some of these values are irrelevant. I am not using the motor profiler but measure the values directly on the motor.

I'm going sensorless but having trouble getting reliable start-up and reliable speed control.  Below is the data I got from the ST Motor Profiler.  They match up pretty well with vendor's numbers and measurements I made using a scope and function generator.  And the gain parameters determined by ST FOC SDK are also included.  Not clear on how they arrived at these number... are they setup properly?  Wc (bandwidth of the closed loop system) was recommended to be 1500 rad/s for a good balance but not clear on what KpDIV and KiDIV should be.  And Ls/Rs=Kp/Ki is required for pole-zero cancellation so should my system respond well as long as I keep that ratio the same, that is once I figure out what that ratio should be.
 And is T (sec?) the reciprocal of PWM frequency multiplied by the Torque/Flux regulator execution rate [PWM periods]?  And would you recommend a more accurate way to measure Ls, Rs and Kv?
« Last Edit: October 31, 2017, 05:42:36 pm by bayetan »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #335 on: November 01, 2017, 12:17:43 pm »
I'm going sensorless but having trouble getting reliable start-up and reliable speed control.  Below is the data I got from the ST Motor Profiler.  They match up pretty well with vendor's numbers and measurements I made using a scope and function generator.  And the gain parameters determined by ST FOC SDK are also included.  Not clear on how they arrived at these number... are they setup properly?  Wc (bandwidth of the closed loop system) was recommended to be 1500 rad/s for a good balance but not clear on what KpDIV and KiDIV should be.  And Ls/Rs=Kp/Ki is required for pole-zero cancellation so should my system respond well as long as I keep that ratio the same, that is once I figure out what that ratio should be.
 And is T (sec?) the reciprocal of PWM frequency multiplied by the Torque/Flux regulator execution rate [PWM periods]?  And would you recommend a more accurate way to measure Ls, Rs and Kv?
During my process, I got the feeling that there may be something wrong with the derived values that STMCWB creates from entered motor and drive parameters. My current process is to enter the measured motor parameters as you did, and let it calculate what it thinks. Then I start tuning things as follows:
- first the current controller (that has nothing to do with sensorless or speed). You can stall the motor, and program a rectangular current command of a few ten hertz. I have described some methods in previous posts of this thread. (I suggest to read it completely.) I have an oscilloscope current clamp for this. Then tune Id/Iq PI gains. Use maximum bus voltage. Don't go too close to the limits here, I use to divide my results by 2 to get final values.
- then sensorless startup, but only externally driven. The observer must be able to follow the rotation with zero torque command, use the analog output feature to validate this. I also use a magnet on the rotor and a hall sensor connected to the scope. Play with parameters like observer type (cordic/pll), and BEMF quality factor. Play with the motor kV value last.
- then speed loop. That mainly depends on your motor inertia, and I always do this manually. Program a velocity command step, and tune until you get a good step response. Divide your results by 2 again. Also use max bus voltage here.
We Are The Watt - Resistance Is Futile!
 

Offline Emmsys

  • Newbie
  • Posts: 1
  • Country: 00
Re: Problems with STM32 PMSM FOC SDK
« Reply #336 on: May 15, 2018, 08:46:33 pm »
Hi,

Apologies for resurrecting an old thread but I am also using the FOC SDK for a project and experienced some of the issues mentioned in this thread. I am going completely sensorless on a motor that works up to 36V. I haven't decided whether I will use 24V or 36 in the end but right now I am getting the motor to spin from a stop, and also using the On-the-Fly startup. I am using an F3 with the IHM08M1 demo board. The motor runs but I am seeing 2 issues.

1) When using the on-the-fly startup only, I would manually spin the motor, then (after setting a torque ramp), make a call to "Start motor" and the motor would stop temporarily then start spinning. This only happens when the motor starts from the "stop" state (although the motor itself is being turned manually to engage OTF). If torque ramps are used once the motor is spinning, the transitions are buttery smooth so it is really when the FOC SDK is told to start the motor. Could this be a torque controller PI value issue, or is it related to the on-the-fly "brake" period? I tried changing this latter parameter but with no luck.

2) The second issue might not be an issue but here it is. If I ask for maximum torque, let's say 15 amps (by setting a torque ramp), the motor will not pull 15 amps, unless the RPMs increase drastically. So there is basically very little torque at lower RPMs. It's almost like the motor needs to catch up in speed (albeit always in torque control mode), before it gives the torque I want. If there is no load, I understand that the motor can reach maximum speed with little torque/amps, but when there is a load, the torque/amp (read from a power meter) might not reach the current/torque I request unless the motor is spinning a higher speeds. Is this just normal BLDC functionality where torque and speed are related? This issue is with on-the-fly startups in torque control mode. I feel like speed-control allows pulling more amps/torque than just straight torque control mode which is strange since the speed controller basically manipulates the torque controller. Or am I getting low torque at lower speeds because I am trying to go sensorless?

BTW I al using FOC SDK 4.3.0. The new 5.0 is giving me lots of issues.

Any tips are greatly appreciated!

e

« Last Edit: May 15, 2018, 08:49:06 pm by Emmsys »
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #337 on: May 16, 2018, 08:37:08 am »
I haven't used the on-the-fly startup feature in SDK4.3.0, because that was not available in 4.0 which I had been using a lot. Meanwhile I have moved to my own code, so I am afraid but I can't help you there.

If there is no load, I understand that the motor can reach maximum speed with little torque/amps, but when there is a load, the torque/amp (read from a power meter) might not reach the current/torque I request unless the motor is spinning a higher speeds. Is this just normal BLDC functionality where torque and speed are related?
No, BLDCs don't behave like this. Their output torque is proportional to the phase current, and you can expect it to be like this from near zero rpm (down to the point where the sensorless observer loses tracking) up to the point where the motor back emf "prevents" more current flow at high rpm.

It is most critical for the sensorless rotor observer that the motor parameters (L and R) are entered correctly, you may check these and play around with changing them to see if that has an effect. Also try both PLL and CORDIC options, they behave quite differently.

This issue is with on-the-fly startups in torque control mode. I feel like speed-control allows pulling more amps/torque than just straight torque control mode which is strange since the speed controller basically manipulates the torque controller. Or am I getting low torque at lower speeds because I am trying to go sensorless?
The sensorless observers that they have implemented can typically keep track down to very low rpm like a few Hertz (electrically), if properly tuned. I'd look into this first, this may also sort out your on-the-fly startup problems.
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #338 on: May 16, 2018, 08:45:02 am »
The new 5.0 is giving me lots of issues.

Same here.

I'm using the P-NUCLEO-IHM001 and the project compile successfully... but the motor Monitor does not work. I can't connect through the UART... the software does not pairing with the board.
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #339 on: December 10, 2018, 01:36:54 pm »
anyone know where the Board IHM08M1 can be found on stock ? or maybe, anyone would like to sell it ?
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #340 on: January 23, 2019, 03:34:27 pm »
is anyone using the SDK 5 ? it looks like quite buggy (also the documents have a lots of errors)
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14306
  • Country: fr
Re: Problems with STM32 PMSM FOC SDK
« Reply #341 on: January 24, 2019, 10:14:26 pm »
Sorry in advance, was tempting to just ask:

"What the FOC?"

 ::)
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #342 on: January 25, 2019, 10:02:22 am »
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #343 on: November 04, 2019, 05:58:45 pm »
Hi, I'm developing a motor control system with ST's SDK 5.4.1.

I developed a new PCB based in STM32F302R8, and I already verified that the hardware works OK because with sensorless algorithm I can spin motors correctly. The problems come when I want to use the magnetic encoder I have in the circuit. It's an AS5147P, almost the same as Dave_PT's AS5047.
I checked that the encoder works well, I spin manually the motor and I see the measured speed varying in the STMCWB.

If I select only encoder as primary sensor, and no secondary sensor, the shaft just locks in place, energized. Also if i put observer as auxiliary sensor, I don't see any difference from not having secondary sensor. I also found out that ST says that you can use an encoder with index output, but it never ever uses it...

When I use observer as primary, and encoder as secondary, It works randomly but works. Also if I remove the encoder IC from the shaft of the motor, it still works... which I dont like too much, because it seems like it isn't using it.

So... how can I reliably measure speed with the encoder and effectively use it without getting speed feedback errors because of observer being activated?

Thank you in advance
« Last Edit: November 05, 2019, 02:58:54 am by psyke »
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #344 on: November 05, 2019, 07:17:07 am »
As first step I suggest you to use only encoder as feedback, if it doesn't run you have to fix some problem on encoder configuration in your setup. Have you set the pulse number correctly ? have you connected the encoder correctly ? have  you check with scope if the A,B signal are correct ?
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #345 on: November 05, 2019, 02:38:16 pm »
Hi. I already checked the encoder and it works correctly. If I spin the motor manually, I see the measured speed in ST Motor Control Workbench Monitor, and also checked, before making it work, that the signals in A and B are correct.

If you check post #46, tatus says that you cannot use only encoder as primary sensor. I don't like that, because why in the world couldn't I use an encoder as primary sensor, if other FOC implementations let you use just encoder as a sensor?
With encoder as primary sensor, the motor gets energized and stuck in place, but it doesn't spin. Also I can't configure startup ramps.
If I put observer as primary, and encoder as secondary sensor, it works, not as smooth as it would be with encoder, but works. But the weird thing comes when I unplug, while the motor is spinning, the encoder feedback: the motor keeps spinning, the measured speed is the same, and I don't notice any change.

So, is there a way to use the encoder as the primary sensor? I want a realiable speed measurement, and not an estimation.

Thank you
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #346 on: November 05, 2019, 02:57:05 pm »
Please check if the ppr of your encoder are correct.

At the end, my problem is related with a misunderstood of the encoder datasheet.

Count with an oscilloscope, or a logic analyser (more easier) if the ppr number are correct.
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #347 on: November 06, 2019, 12:30:26 am »
The PPR are correct, they are set to 1024 pulses per rev, which is the default for AS5147P in SETTINGS2 register.

Here is a video in which I show the encoder measurement by spinning the motor manually.
https://www.youtube.com/embed/Z8Xcem_A4wU

This is another video in which I start the motor and show how it aligns, and after that, it remains in position, energized, but doesn't spin even if I change speed reference.
https://youtu.be/pWIWRgWoC1M
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #348 on: November 06, 2019, 09:44:42 am »
I'd first verify both ppr and counting direction of the encoder. You can also use one of the DAC outputs to monitor the electrical angle along with one of the phase voltages, while spinning the motor manually. If these stay in sync after a few revolutions then you can tick that off. Regarding the encoder I channel: in earlier versions that's something that you have to code by yourself - set up an interrupt for that signal in your MCU and let the ISR manually set the correct offset (to be measured once).
We Are The Watt - Resistance Is Futile!
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #349 on: November 06, 2019, 10:05:46 am »
Thing that you need to do the "encoder align" first and only then you mus click on "start motor".
Have you tried this?

If you never align the encoder, the control stage will know where the rotor is and will probably get stuck.

PS: In these new versions I don't know if the "start motor" already makes the encoder alignment, but it makes no sense to me.
« Last Edit: November 06, 2019, 10:16:56 am by Dave_PT »
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #350 on: November 06, 2019, 02:09:44 pm »
Thank you for answering guys.

I'd first verify both ppr and counting direction of the encoder. You can also use one of the DAC outputs to monitor the electrical angle along with one of the phase voltages, while spinning the motor manually. If these stay in sync after a few revolutions then you can tick that off. Regarding the encoder I channel: in earlier versions that's something that you have to code by yourself - set up an interrupt for that signal in your MCU and let the ISR manually set the correct offset (to be measured once).

Ok, going to try the DAC output when I get close to an oscilloscope. Regarding to the encoder I channel, the motor should work anyways even if I dont implement the interrupt for that channel?

Thing that you need to do the "encoder align" first and only then you mus click on "start motor".
Have you tried this?

If you never align the encoder, the control stage will know where the rotor is and will probably get stuck.

PS: In these new versions I don't know if the "start motor" already makes the encoder alignment, but it makes no sense to me.

In new versions, if you click "Start motor" for the first time, it does an encoder alignment, and after that, it starts the motor. Successive "Start motor" commands just start the motor without alignment, as it is already aligned.

I already tried hitting encoder alignment before starting, I think I tried everything available in the library  |O

I also got inside the code of the library, trying to know why it doesn't spin the motor... but got no success finding the problem.
« Last Edit: November 06, 2019, 02:13:02 pm by psyke »
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #351 on: November 06, 2019, 03:56:02 pm »
Stupid question: the phases order, number of pole pairs, etc are correct, right?

You can run the motor in sensorless mode, so all parameters must be correct, but you never know ...  :-//
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #352 on: November 06, 2019, 04:18:56 pm »
I measured number of pole pairs with ST’s method, energizing 2 phases and counting the amount of snaps in a single revolution

I tried changing two phases order with no success, it does the same
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: Problems with STM32 PMSM FOC SDK
« Reply #353 on: November 06, 2019, 06:19:22 pm »
Ok, going to try the DAC output when I get close to an oscilloscope.
I'd say that having one is a must when developing a motor controller. When having a problem, I first hook that up. I only start debugging the code when it doesn't look like an electrical problem.

Regarding to the encoder I channel, the motor should work anyways even if I dont implement the interrupt for that channel?
The I channel based alignment is a substitute for the software alignment that the library does. If your application is fine with the motor being 'hard' turned each time the system powers up, and you can guarantee that there is no shaft torque during this time, then you don't need that.
We Are The Watt - Resistance Is Futile!
 
The following users thanked this post: Dave_PT

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #354 on: November 06, 2019, 07:01:13 pm »
Ok, going to try the DAC output when I get close to an oscilloscope.
I'd say that having one is a must when developing a motor controller. When having a problem, I first hook that up. I only start debugging the code when it doesn't look like an electrical problem.

Regarding to the encoder I channel, the motor should work anyways even if I dont implement the interrupt for that channel?
The I channel based alignment is a substitute for the software alignment that the library does. If your application is fine with the motor being 'hard' turned each time the system powers up, and you can guarantee that there is no shaft torque during this time, then you don't need that.

Ok, so the I channel isn't going to be used for now. First I need to make the motor spin with encoder.

Regarding to the oscilloscope, we have some for students use in the university. I know its very important to have one, but I don't.
Maybe tomorrow I can go use one of those. I will post updates after that
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #355 on: November 06, 2019, 07:17:17 pm »
I just did some tests with another motor, this one has 6 pole pairs (the original one that I need to use has 8 pole pairs), but I have the same results... I feel there is a problem with the library. Hope we can find out the problem soon
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #356 on: November 06, 2019, 07:36:39 pm »
Therefore, you cannot guarantee under what conditions the AB signal reaches the MCU ...

When possible check the AB signals with the oscilloscope. Just to make sure the feedback is working correctly.
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #357 on: November 11, 2019, 08:22:57 am »
what library version are you using ? I am currently using the 5.4 with only encoder as feedback and it works. For sure your motor phase order have to be correct.
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #358 on: November 12, 2019, 02:15:16 pm »
Well... yesterday I recorded some videos showing the oscilloscope and the motor control workbench, and I came here to post them, but when I read r0d3z1 comment, I thought: I'm going to try a last thing, so I interchanged the connection of two phases.... and it worked  |O  :palm:  :scared:

Thank you to all who helped me
 

Offline Dave_PTTopic starter

  • Frequent Contributor
  • **
  • Posts: 315
  • Country: pt
    • DavidMartinsEngineering
Re: Problems with STM32 PMSM FOC SDK
« Reply #359 on: November 12, 2019, 02:28:12 pm »
Story Summary:

Stupid question: the phases order, number of pole pairs, etc are correct, right?

I tried changing two phases order with no success, it does the same

I'm going to try a last thing, so I interchanged the connection of two phases.... and it worked  |O  :palm:  :scared:

Glad to know it already works ;)
 
The following users thanked this post: psyke

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #360 on: November 12, 2019, 05:10:33 pm »
Well... yesterday I recorded some videos showing the oscilloscope and the motor control workbench, and I came here to post them, but when I read r0d3z1 comment, I thought: I'm going to try a last thing, so I interchanged the connection of two phases.... and it worked  |O  :palm:  :scared:

Thank you to all who helped me

I am pleased that it worked.
I would like to ask you if you are using the library with the ihm08m1 board ? i am currently using it and the current reading are very noisy due to the switching noise induced by the buck converter. Anyone notice this ?
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #361 on: November 13, 2019, 12:04:08 am »
I am pleased that it worked.
Thank you  :)

I started with a P-NUCLEO-IHM001 (NUCLEO board with STM32F302R8 and an IHM07M1). After testing the library with that board, I designed my own PCB based in IHM08M1 schematics. I literally copied the current sensing part, and it's working nice on my board.

How much current does your motor consume?

If you get noisy current reading, I would start increasing T-noise and/or Trise in "Current Sensing" block in ST Motor Control Workbench, and recompile.
« Last Edit: November 13, 2019, 03:40:49 am by psyke »
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #362 on: November 19, 2019, 05:01:47 pm »
Hi, I'm back again, but this time I don't have any problem, just a question.

Does anyone know if you can do position control with this library? Because I can't find a way to do that, only speed control

Thank you
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #363 on: November 20, 2019, 11:31:48 am »
As far as I know position control is not supported by the library, but you can add it by yourself.
 

Offline r0d3z1

  • Regular Contributor
  • *
  • Posts: 116
  • Country: it
Re: Problems with STM32 PMSM FOC SDK
« Reply #364 on: January 13, 2020, 10:51:55 am »
Anyone using this library with encoder is having oscillation problem on speed loop ?
I have seen that there is no LPF of speed feedback and the sampling is very slow (1ms).
 

Offline psyke

  • Contributor
  • Posts: 11
  • Country: ar
Re: Problems with STM32 PMSM FOC SDK
« Reply #365 on: January 13, 2020, 03:27:25 pm »
Hi r0d3z1

I have a little oscilation in speed feedback but it isn't significant.
Does it get unstable due to the oscilation in speed feedback?
If you are using encoder you can increase the input filter in the workbench.
Maybe you could also post a short video showing the behavior.
Also check if changing motor parameters you get better results
« Last Edit: January 13, 2020, 04:34:33 pm by psyke »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf