Problems with STM32 PMSM FOC SDK - Page 1
Forum section: electronics / general

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 15, 2016, 07:00:28 pm
content: 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.htmlI 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.htmlAttached is the configurator file.http://s000.tinyupload.com/index.php?file_id=62181905025753098078I'm freaking out with this ....Thank you!!

author: tatus1969
author_rank: Super Contributor
timestamp: November 15, 2016, 07:53:43 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 15, 2016, 08:38:36 pm
content: Oh, thank God (God Goku, of course).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!

author: tatus1969
author_rank: Super Contributor
timestamp: November 15, 2016, 08:44:44 pm
content: no problem

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 15, 2016, 09:11:41 pm
content: Tomorrow at 10 a.m. (Germany time) I will write something here.Thank you.I owe you a Franziskaner

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 07:13:17 am
content: i can check this evening. just throw over that beer, but make it a KilkennyI don't drink that Bavarian stuffsome 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 scopeEDIT: 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 onehttp://www.st.com/en/evaluation-tools/steval-ihm040v1.htmlis 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 09:24:04 am
content: My knowledge about German beers is very limited.Quote from: tatus1969 on November 16, 2016, 07:13:17 amThe only ST forum I know is this:https://my.st.com/public/STe2ecommunities/motordriver_ics/Lists/Motor%20Control%20Firmware%20and%20Software/AllItems.aspxBut is not dedicated to this SDK.Can you give me the forum link?Quote from: tatus1969 on November 16, 2016, 07:13:17 amYes. I measured these parameters with the Renesas board.Quote from: tatus1969 on November 16, 2016, 07:13:17 amThis 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 ...Quote from: tatus1969 on November 16, 2016, 07:13:17 amI made the changes on this board (so I can use a 24V motor).But this board appears in the configuration tool.Quote from: tatus1969 on November 16, 2016, 07:13:17 amIn the forum I can not add the file ...Try it here:http://www.filehosting.org/file/details/618819/drive_alte.rarOr here:http://www.yourfilelink.com/get.php?fid=1273789Thx

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 10:08:25 am
content: I have been analyzing and actually the board may be making the job difficult ...Will this KIT make the task easier?http://uk.rs-online.com/web/p/power-management-development-kits/9064630/?searchTerm=906-4630&relevancy-data=636F3D3126696E3D4931384E525353746F636B4E756D6265724D504E266C753D656E266D6D3D6D61746368616C6C26706D3D5E283F69292852537C5253207C52532D293F5C647B337D285C73293F5B5C732D2F255C2E2C5D285C73293F5C647B332C347D2426706F3D313426736E3D592673743D52535F53544F434B5F4E554D4245522677633D4E4F4E45267573743D3930362D34363330267374613D3930363436333026

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 10:48:49 am
content: I already bought the KIT.It must arrive tomorrow ...But making FOC with 1 shunt resistor is possible ....

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 11:45:16 am
content: 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_RAMPIn 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 01:00:27 pm
content: Quote from: Dave_PT on November 16, 2016, 09:24:04 amSame for my Portugesian beer knowledgeQuote from: Dave_PT on November 16, 2016, 09:24:04 amThat'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.Quote from: Dave_PT on November 16, 2016, 09:24:04 amI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 02:56:48 pm
content: Quote from: tatus1969 on November 16, 2016, 01:00:27 pmWhen this is over I'll send you the best Portuguese beer.Quote from: tatus1969 on November 16, 2016, 01:00:27 pmI have seen seen in the various posts that the answers are late ...Maybe this may not be the best time ...Quote from: tatus1969 on November 16, 2016, 01:00:27 pmYes. The new KIT I bought already supports the MPA.It is very useful!Quote from: tatus1969 on November 16, 2016, 01:00:27 pmYes, exactly!Quote from: tatus1969 on November 16, 2016, 01:00:27 pmI checked this out ...This is the protection of the driver. These were the "default values" of the configurator for this board.Quote from: tatus1969 on November 16, 2016, 01:00:27 pmA crystal is connected to pins 5 and 6, which I think is 8MHz.The RefDes is Y1.Quote from: tatus1969 on November 16, 2016, 01:00:27 pmThe 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 04:24:45 pm
content: Quote from: Dave_PT on November 16, 2016, 10:48:49 amThen 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 04:44:14 pm
content: Quote from: tatus1969 on November 16, 2016, 04:24:45 pmI'm trying to export the project.I'm more Eclipse user than IAR ...The project has files all over the directory ....

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 04:48:56 pm
content: Quote from: Dave_PT on November 16, 2016, 02:56:48 pmQuote from: Dave_PT on November 16, 2016, 02:56:48 pmThe 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.Quote from: Dave_PT on November 16, 2016, 02:56:48 pmAlright... what a crappy symbol in the drawing (en.DM00073152-1.pdf)Quote from: Dave_PT on November 16, 2016, 02:56:48 pmCan'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 05:09:57 pm
content: Quote from: tatus1969 on November 16, 2016, 04:48:56 pmOK.Done!Quote from: tatus1969 on November 16, 2016, 04:48:56 pmThe first time I looked at him, I did not even realize what it was.I just understood because of RefDes.Quote from: tatus1969 on November 16, 2016, 04:48:56 pmYes, you are right. It's a little strange.Look atTHIS.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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 05:30:05 pm
content: Quote from: Dave_PT on November 16, 2016, 04:44:14 pmIt'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 05:52:49 pm
content: I've been trying to figure out the polarity of BKIN.TIM1 - BDTR -BKPBut the only "TIM1" reference I have in the project has no configuration.Where is the timers setup?: In fact, in all *.c files inside the SDK folder, I can not find any TIM1 settings.

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 07:45:27 pm
content: Quote from: Dave_PT on November 16, 2016, 05:09:57 pmThat 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:(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:/* PWM Driving signals initialization ----------------------------------------*/(FunctionalState)SW_OV_CURRENT_PROT_ENABLING, /*!< It enable/disable the management ofan emergency input instantaneouslystopping PWM generation. It must beeither equal to ENABLE or DISABLE */(uint16_t)(OVERCURR_FEEDBACK_POLARITY),/*!< Emergency Stop (BKIN) input polarity,it must be TIM_BreakPolarity_Low orTIM_BreakPolarity_High */EMERGENCY_STOP_GPIO_PORT, /*!< Emergency Stop (BKIN) GPIO inputport (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 beGPIO_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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 07:51:26 pm
content: Quote from: Dave_PT on November 16, 2016, 05:30:05 pmOnly 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 08:26:12 pm
content: Quote from: tatus1969 on November 16, 2016, 07:51:26 pmI hope I have not deleted too many files ...https://meocloud.pt/link/3eaf8bf7-7baa-4699-af75-c8520d082afd/stm_foc_sdk.rar/

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 09:03:28 pm
content: Quote from: tatus1969 on November 16, 2016, 07:45:27 pmThe only reference I can find is in theMCTasks.cfile (and in theSystemNDriveParams.hfile).Code:oCurrSensor = (CPWMC)R1F0XX_NewObject(&PWMnCurrFdbkParamsM1, &R1_SDParams);This is all a bit tricky ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 09:08:35 pm
content: Quote from: Dave_PT on November 16, 2016, 08:26:12 pmShould be complete. I checked --> #define SW_OV_CURRENT_PROT_ENABLING DISABLEYour 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_DRIVERSTM32F10X_MDARM_MATH_CM3Here 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$\SystemDriveParamsFor 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 16, 2016, 09:24:29 pm
content: Quote from: Dave_PT on November 16, 2016, 09:03:28 pmthat 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 10:28:42 pm
content: Quote from: tatus1969 on November 16, 2016, 09:08:35 pmYou wanted to say IAR, right?Please do not ruin my head.Quote from: tatus1969 on November 16, 2016, 09:08:35 pmThe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 16, 2016, 10:40:00 pm
content: Quote from: tatus1969 on November 16, 2016, 09:08:35 pmNow 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 06:38:32 am
content: Quote from: Dave_PT on November 16, 2016, 10:28:42 pmThat'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

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 06:40:29 am
content: Quote from: Dave_PT on November 16, 2016, 10:40:00 pmThere 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".

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 09:24:31 am
content: 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 10:28:01 am
content: Quote from: Dave_PT on November 17, 2016, 09:24:31 amWouldn'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 10:49:47 am
content: Quote from: tatus1969 on November 17, 2016, 10:28:01 amExactly.I've always used the IAR to send code to the MCU. And I already showed you that I can debug.Quote from: tatus1969 on November 17, 2016, 10:28:01 amThis would be a method of securing this issue ...Is the polarity of BKIN high?Quote from: tatus1969 on November 17, 2016, 10:28:01 amYes of course.I've checked several times, because in the Renesas board I had a problem with the supply voltage of the circuit ...Quote from: tatus1969 on November 17, 2016, 10:28:01 amI'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 11:09:11 am
content: 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 ....

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 12:35:52 pm
content: The new EVB has arrived!I am doing the first setup and the first tests written in the documents.

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 01:20:41 pm
content: Quote from: Dave_PT on November 17, 2016, 10:49:47 amIt 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 01:27:59 pm
content: Quote from: Dave_PT on November 17, 2016, 11:09:11 amYou can also uncheck the "Bus Voltage Sensing" in STMC Workbench "Power Stage" section.The alarm is configured by the following definitions:VBUS_PARTITIONING_FACTOROV_VOLTAGE_THRESHOLD_VUD_VOLTAGE_THRESHOLD_VSomething 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 01:44:03 pm
content: 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. Thathasto trigger rebuilding some of the files. I really cannot find a single error in any of these files...Code:#define OV_VOLTAGE_THRESHOLD_V 32 /*!< Over-voltagethreshold */#define UD_VOLTAGE_THRESHOLD_V 18 /*!< Under-voltagethreshold */#define VBUS_PARTITIONING_FACTOR 0.0833 /*!< It expresses howmuch the Vbus is attenuatedbefore being converted intodigital value */#define MCU_SUPPLY_VOLTAGE 3.30Have you stepped into TSK_SafetyTask_PWMOFF ? Are you sure that it is the voltage monitor that is tripping?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 03:05:16 pm
content: 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 03:59:33 pm
content: Quote from: Dave_PT on November 17, 2016, 03:05:16 pmThe 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...).

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 04:21:13 pm
content: Quote from: tatus1969 on November 17, 2016, 03:59:33 pmIn the version I have already has a template for P-NUCLEO-IHM001.Quote from: tatus1969 on November 17, 2016, 03:59:33 pmIn the MCU.Because in the future the goal is to send speeds via serial port.Quote from: tatus1969 on November 17, 2016, 03:59:33 pmIn 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).

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 06:21:57 pm
content: Quote from: Dave_PT on November 17, 2016, 04:21:13 pmYou 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.Quote from: Dave_PT on November 17, 2016, 04:21:13 pmGreat!Quote from: Dave_PT on November 17, 2016, 04:21:13 pmI 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:static int i=0;i++;FOCVars.Iqdref.qI_Component1 = 0;if( (i%300) < 150 ){FOCVars.Iqdref.qI_Component2 = (int16_t)( 1.0f * (65536.0f * (float)(AMPLIFICATION_GAIN / MCU_SUPPLY_VOLTAGE) ) );}else{FOCVars.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:uint16_t FOC_CurrController(uint8_t bMotor){Curr_Components Iab, Ialphabeta, Iqd;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))Curr_Components IqdHF = {0,0};#endifVolt_Components Valphabeta, Vqd;int16_t hElAngledpp;uint16_t hCodeError;hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC));static int16_t k=0; k+=1; hElAngledpp=k; <<<<<<<<<< inserted, very slow motor rotationPWMC_GetPhaseCurrents(oCurrSensor, &Iab);...Quote from: Dave_PT on November 17, 2016, 04:21:13 pmThere 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).

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 17, 2016, 08:13:26 pm
content: Quote from: tatus1969 on November 17, 2016, 06:21:57 pmSo I have to study the driver better.In fact, I get a bit confused because Renesas used different methods. But I'm enjoying ST.During theMotor Profilertests, the motor is put under more stress and can exceed these currents ...But tomorrow I will analyze better with the scope what is happening.

author: tatus1969
author_rank: Super Contributor
timestamp: November 17, 2016, 08:56:41 pm
content: 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 situationjust 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 18, 2016, 09:45:40 am
content: 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 18, 2016, 10:18:08 am
content: See page 103 and 104.I do not have any of these files after installing version 4.3.http://www.st.com/content/ccc/resource/technical/document/user_manual/5e/5e/d2/cb/07/35/45/a6/CD00298474.pdf/files/CD00298474.pdf/jcr:content/translations/en.CD00298474.pdf

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 18, 2016, 11:18:28 am
content: 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: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_CM4c:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failc:/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 failMotor 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 statusmake: *** [STM32F30x_UserProject.elf] Error 1

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 18, 2016, 06:54:19 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 19, 2016, 06:39:18 pm
content: Quote from: Dave_PT on November 18, 2016, 06:54:19 pmyou 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 19, 2016, 06:58:12 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 20, 2016, 03:59:56 pm
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 08:19:50 am
content: Quote from: Dave_PT on November 19, 2016, 06:58:12 pmI 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).

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 08:26:56 am
content: Quote from: Dave_PT on November 20, 2016, 03:59:56 pmJust 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 09:29:24 am
content: Quote from: tatus1969 on November 21, 2016, 08:19:50 amYes 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.pdfIt also gives absolute rotor angle.Quote from: tatus1969 on November 21, 2016, 08:19:50 amThe 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.Quote from: tatus1969 on November 21, 2016, 08:19:50 amVery 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 10:05:44 am
content: Quote from: tatus1969 on November 21, 2016, 08:26:56 amI do not see anything in scope.I've tried several variables for the DAC, but the output is always static.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 11:37:36 am
content: 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 11:48:05 am
content: Quote from: Dave_PT on November 21, 2016, 10:05:44 amCan 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 12:09:14 pm
content: Quote from: Dave_PT on November 21, 2016, 09:29:24 amAs 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 12:31:24 pm
content: Quote from: tatus1969 on November 21, 2016, 11:48:05 amMy project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVEIn the "UI_TaskInit" file the DAC is enabled.I am using serial communication to use STMCW...Quote from: tatus1969 on November 21, 2016, 12:09:14 pmOK 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 02:10:31 pm
content: Quote from: Dave_PT on November 21, 2016, 12:31:24 pmHmmm, 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".Quote from: Dave_PT on November 21, 2016, 12:31:24 pmIt 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 angleNow 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 02:28:20 pm
content: Quote from: Dave_PT on November 21, 2016, 11:37:36 amIf 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 02:33:49 pm
content: Quote from: tatus1969 on November 21, 2016, 02:10:31 pmIn 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 02:49:39 pm
content: Quote from: tatus1969 on November 21, 2016, 02:28:20 pmI 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 02:49:46 pm
content: 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 rpmThe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 03:37:14 pm
content: There is something very wrong!I unplugged the encoder cables and did "start_motor" and the motor started.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 03:41:07 pm
content: Quote from: Dave_PT on November 21, 2016, 02:49:39 pm(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.Quote from: Dave_PT on November 21, 2016, 02:49:39 pmTorque 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/?allQuote from: Dave_PT on November 21, 2016, 02:49:39 pmProbably a bug, but maybe they forgot the conversion between float 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 03:43:30 pm
content: Quote from: Dave_PT on November 21, 2016, 03:37:14 pmIt 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 03:59:29 pm
content: Quote from: tatus1969 on November 21, 2016, 03:41:07 pmThis should not be a problem. My execution rate is 2 PWM period (15KHz).Quote from: tatus1969 on November 21, 2016, 03:41:07 pmThank you.I'll read the post.Quote from: tatus1969 on November 21, 2016, 03:41:07 pmYes it is a bug.I can only use integers in the "monitor". In the STMCW configurator I can enter current with decimal places.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 04:31:28 pm
content: Quote from: tatus1969 on November 21, 2016, 03:43:30 pmI 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 ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 05:17:40 pm
content: Am I doing something wrong?One question: in the last image I doencoder alignand thenstart motor, but the motor does not rotate. Was not this the right procedure?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 06:41:36 pm
content: 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/

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 07:41:04 pm
content: Quote from: Dave_PT on November 21, 2016, 05:17:40 pmCant'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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 21, 2016, 08:08:29 pm
content: Quote from: Dave_PT on November 21, 2016, 06:41:36 pmChecked 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 21, 2016, 09:01:20 pm
content: Quote from: tatus1969 on November 21, 2016, 07:41:04 pmApparently nothing.I was hoping the current of my power supply would increase. But that does not happen.Quote from: tatus1969 on November 21, 2016, 07:41:04 pmI 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).Quote from: tatus1969 on November 21, 2016, 07:41:04 pmI 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!Quote from: tatus1969 on November 21, 2016, 08:08:29 pmLuckily for me.Quote from: tatus1969 on November 21, 2016, 08:08:29 pmThe 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.Quote from: tatus1969 on November 21, 2016, 08:08:29 pmIt is indeed.All headers are in the correct position for FOC and 3 shunt measurement.Quote from: tatus1969 on November 21, 2016, 08:08:29 pmI'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.Quote from: tatus1969 on November 21, 2016, 08:08:29 pmI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 09:20:01 am
content: Quote from: Dave_PT on November 21, 2016, 09:01:20 pmThe 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 09:57:53 am
content: Quote from: Dave_PT on November 21, 2016, 09:01:20 pmIf 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). 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 10:04:52 am
content: Wait ... on file MCTasks.c, can you explain the logic to this?Code:#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))CSPD oVSS_M1; /* only if M1 is sensorless*/#endifNow it makes some sense.They are not even initializing the encoder. Just like I thought ..."encoder" is never defined.

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 10:15:06 am
content: Quote from: Dave_PT on November 22, 2016, 10:04:52 amThe 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 = (CSPD)ENC_NewObject(&SpeednPosFdbkParamsM1,&ENCParamsM1); /* speed sensor STO, ENC, HALL xNew and xParamsM1*/

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 10:16:55 am
content: Quote from: Dave_PT on November 22, 2016, 10:04:52 amYou can easily check if ENCODER is defined by adding#ifndef ENCODERfucked up!#endifsomewhere in one of the source files

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 10:20:22 am
content: Code:unknown type name 'fucked'You do not know ... but I know it well !!!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 10:31:15 am
content: Could the project not be including the "Drive parameters.h" file?

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 10:32:32 am
content: Quote from: Dave_PT on November 22, 2016, 10:20:22 amyou got a problem with your config/build/project. when i do it here i end up with #define ENCODER in "Drive parameters.h"

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 10:39:30 am
content: Quote from: Dave_PT on November 22, 2016, 10:31:15 amis 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 10:40:01 am
content: 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 10:44:02 am
content: Quote from: Dave_PT on November 22, 2016, 10:40:01 amIt'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"

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 11:31:07 am
content: When I compile the program, it does not see the config files.Now I'm sure.But I do not know how to solve ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 12:24:35 pm
content: 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:#ifdef ENCODER#warning "encoder declared!!!"#endif

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 04:04:26 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 04:39:00 pm
content: Quote from: Dave_PT on November 22, 2016, 04:04:26 pmgreat!what happens now?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 04:58:06 pm
content: Quote from: tatus1969 on November 22, 2016, 04:39:00 pmNow I'm having lots of feedback faults...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 05:09:51 pm
content: Looks like the motor was making an acceleration ramp and then it stopped ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 05:58:19 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 06:18:07 pm
content: Quote from: Dave_PT on November 22, 2016, 04:58:06 pmis 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...)

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 06:35:19 pm
content: Quote from: tatus1969 on November 22, 2016, 06:18:07 pmIt 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 06:39:45 pm
content: Quote from: Dave_PT on November 22, 2016, 05:58:19 pmDo 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 06:40:46 pm
content: Quote from: Dave_PT on November 22, 2016, 06:35:19 pmI thought that you werenotconfiguring a secondary sensor? In this case, the software sticks to the primary.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 06:44:40 pm
content: Quote from: tatus1969 on November 22, 2016, 06:40:46 pmYes, 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 06:49:30 pm
content: Quote from: Dave_PT on November 22, 2016, 06:35:19 pmCould 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 06:52:29 pm
content: Quote from: Dave_PT on November 22, 2016, 06:44:40 pmIf 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 07:25:33 pm
content: Quote from: tatus1969 on November 22, 2016, 06:39:45 pmThese 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.Quote from: tatus1969 on November 22, 2016, 06:39:45 pmI 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.Quote from: tatus1969 on November 22, 2016, 06:49:30 pmNoted!Quote from: tatus1969 on November 22, 2016, 06:52:29 pmThank you.I was wondering what this exchange between sensors would be like ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 22, 2016, 09:27:45 pm
content: Quote from: Dave_PT on November 22, 2016, 07:25:33 pmI 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.Quote from: Dave_PT on November 22, 2016, 07:25:33 pmlooks 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?)

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 22, 2016, 11:22:35 pm
content: Quote from: tatus1969 on November 22, 2016, 09:27:45 pmYou'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.Quote from: tatus1969 on November 22, 2016, 09:27:45 pmYes. I configured the DAC channel to represent the current Iq ...For about 5/10us it draws a pulse, but then begins to oscillate.Quote from: tatus1969 on November 22, 2016, 09:27:45 pmIn 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.Quote from: tatus1969 on November 22, 2016, 09:27:45 pmOh of course!Quote from: tatus1969 on November 22, 2016, 09:27:45 pmOkay. I'll repeat the procedure and analyze the results.The control stabilizes initially, but then oscillates so I'll try adjust the PI values.Quote from: tatus1969 on November 22, 2016, 09:27:45 pmOkay. 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

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 08:34:27 am
content: Quote from: Dave_PT on November 22, 2016, 11:22:35 pmYou can run the motor in control mode "torque", and set Torque ref (iq) to zero.Quote from: Dave_PT on November 22, 2016, 11:22:35 pmNo worries :-)

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 10:37:22 am
content: Quote from: Dave_PT on November 22, 2016, 11:22:35 pmI 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".: The frequency is 30KHz ... the same as the PWM.So if we reject this signal, the current pulse during the alignment lasts only 7uS.Quote from: tatus1969 on November 23, 2016, 08:34:27 amI 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º ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 11:55:39 am
content: 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 12:37:56 pm
content: Quote from: Dave_PT on November 23, 2016, 10:37:22 amThat 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.Quote from: Dave_PT on November 23, 2016, 10:37:22 amReally 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

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 12:41:00 pm
content: Quote from: Dave_PT on November 23, 2016, 11:55:39 amgood 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 03:45:33 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 04:15:47 pm
content: Quote from: Dave_PT on November 23, 2016, 03:45:33 pmWhat 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 05:02:19 pm
content: Quote from: tatus1969 on November 23, 2016, 04:15:47 pmIn 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.68ABut at the beginning the voltage is ~ 2.03V and should be 1.65V, right?:In torque control was the motor supposed to rotate?I blocked the motor shaft, but it does not make any force ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 06:11:15 pm
content: Quote from: Dave_PT on November 23, 2016, 05:02:19 pmThe 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/

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 07:07:25 pm
content: Quote from: Dave_PT on November 23, 2016, 05:02:19 pmLooks 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.Quote from: Dave_PT on November 23, 2016, 05:02:19 pmOf 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,andthe 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 23, 2016, 07:14:52 pm
content: Quote from: Dave_PT on November 23, 2016, 06:11:15 pmIt 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 23, 2016, 11:07:13 pm
content: Quote from: tatus1969 on November 23, 2016, 07:07:25 pmYes. I always do the alignment of the encoder.Quote from: tatus1969 on November 23, 2016, 07:07:25 pmTomorrow I'm going to do this test again.I experimented today and had no torque at the motor shaft.Quote from: tatus1969 on November 23, 2016, 07:14:52 pmExcellent explanation!Very good!Quote from: tatus1969 on November 23, 2016, 07:14:52 pmIn 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 08:17:15 am
content: Quote from: Dave_PT on November 23, 2016, 11:07:13 pmFor 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 goalp.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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 10:26:22 am
content: Quote from: tatus1969 on November 24, 2016, 08:17:15 amYou'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.If I rotate the shaft with my hand, it starts to rotate ...Quote from: tatus1969 on November 24, 2016, 08:17:15 amThanks for your help !!Quote from: tatus1969 on November 24, 2016, 08:17:15 amThe 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.Quote from: tatus1969 on November 24, 2016, 08:17:15 amIn 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!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 11:59:15 am
content: Quote from: Dave_PT on November 24, 2016, 10:26:22 amSolved.I recalculated the current and put the Iq Ref higher.The motor is now starting with the gear box on.

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 12:26:57 pm
content: Quote from: Dave_PT on November 24, 2016, 11:59:15 amwhat do you mean by that?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 12:41:48 pm
content: Quote from: tatus1969 on November 24, 2016, 12:26:57 pmI 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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 12:47:41 pm
content: Quote from: Dave_PT on November 24, 2016, 12:41:48 pmwhen 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 02:37:26 pm
content: For the motor to rotate in the same direction, Id = -Iq. It's normal?Clockwise rotation:Iq = 10026, Id = 0Counterclockwise rotation:Iq = 0, Id = 10026Clockwise rotation:Iq = 0, Id = -10026

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 03:26:30 pm
content: Quote from: Dave_PT on November 24, 2016, 02:37:26 pmId 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 03:40:01 pm
content: 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).

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 04:30:18 pm
content: Quote from: Dave_PT on November 24, 2016, 03:40:01 pmThat 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:#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 1extern FOCVars_t FOCVars;extern CSTC oSTC;extern CPI oPIDSpeed,oPIDIq,oPIDId;extern CPWMC oCurrSensor;extern CSPD oSpeedSensor;extern CSPD oVSS_M1;extern CUI oDAC;CMCI oMCI;CMCT oMCT;#define FIRMWARE_VERS "STM32 FOC SDK\0Ver.4.0.B"const char s_fwVer = 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 priorityNVIC_PriorityGroupConfig(NVIC_PriorityGroup_3);// MCInterface and MCTuning bootMCboot(oMCI,oMCT);// Systick configurationSysTick_Config( (SystemCoreClock) / SYS_TICK_FREQUENCY );NVIC_SetPriority(SysTick_IRQn, SYSTICK_PRIORITY);NVIC_SetPriority(PendSV_IRQn, PENDSV_PRIORITY);// Initialize DAC outputUI_SetDAC(oDAC, DAC_CH0, MC_PROTOCOL_REG_I_Q);// Assign virtual speed sensor (electrical angle = 0)SPD_Clear(oSpeedSensor);SPD_Clear(oVSS_M1);STC_SetSpeedSensor(oSTC,oVSS_M1);// Initialize to zero torque/fluxFOCVars.Iqdref.qI_Component1 = 0; // torque, IqFOCVars.Iqdref.qI_Component2 = 0; // flux, Id// Current sensor calibrationPWMC_CurrentReadingCalibr(oCurrSensor,CRC_START);while( !PWMC_CurrentReadingCalibr(oCurrSensor,CRC_EXEC) );// Enable power stagePWMC_SwitchOnPWM(oCurrSensor);/*// current controller tuningwhile(1){FOCVars.Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );wait( 0.007f );FOCVars.Iqdref.qI_Component1 = 0;wait( 0.04f );}*/// Apply 2A current for 1sec for alignmentFOCVars.Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );wait( 1.0f );FOCVars.Iqdref.qI_Component1 = 0;// Set encoder angleSPD_SetMecAngle( oSpeedSensor, (65536/4) / POLE_PAIR_NUM );// Switch to encoder feedbackSPD_Clear(oSpeedSensor);STC_SetSpeedSensor(oSTC,oSpeedSensor);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 outputUI_DACExec((CUI)oDAC);// Update motor velocity measurementSPD_CalcAvrgMecSpeed01Hz(oSpeedSensor,&wAux);i16CurrentVelocity = SPD_GetAvrgMecSpeed01Hz(oSpeedSensor);// Prevent motor activation while not referencedif( !bReferenced ){return;}// Set commanded velocityi16CommandedVelocity = 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 STMCWBi16MotorCurrentLimit = PHASECURRENT_FTOI( 2.0f );PI_SetUpperOutputLimit( oPIDSpeed, +i16MotorCurrentLimit );PI_SetLowerOutputLimit( oPIDSpeed, -i16MotorCurrentLimit );i16MotorCurrent = PI_Controller( oPIDSpeed, (int32_t)(i16CommandedVelocity - i16CurrentVelocity) );FOCVars.Iqdref.qI_Component1 = i16MotorCurrent;}

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 04:32:11 pm
content: Quote from: Dave_PT on November 24, 2016, 03:40:01 pmThe 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 05:29:44 pm
content: Quote from: tatus1969 on November 24, 2016, 04:32:11 pmFor now I can not put Iq=0 and the motor continues to run.But with this sequence, I can get the motor to rotate ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 24, 2016, 05:41:55 pm
content: Quote from: tatus1969 on November 24, 2016, 04:30:18 pmThank you very much.Now I will study the serial communication using the SDK ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 24, 2016, 06:51:00 pm
content: Quote from: Dave_PT on November 24, 2016, 05:29:44 pmThat means to me that the encoder alignment produces random results...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 25, 2016, 12:15:09 pm
content: I'm terrible working with this.Can I create a newUSART_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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: November 25, 2016, 12:24:35 pm
content: Quote from: Dave_PT on November 25, 2016, 12:15:09 pmi 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 25, 2016, 12:33:02 pm
content: Quote from: tatus1969 on November 25, 2016, 12:24:35 pmOK.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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 25, 2016, 02:17:01 pm
content: Quote from: Dave_PT on November 25, 2016, 12:33:02 pmdo you need to do "hot" switching, or is it ok to decide at boot time?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 25, 2016, 03:40:16 pm
content: Quote from: tatus1969 on November 25, 2016, 02:17:01 pmDuring boot it is ok.It's just to be able to do the test easily without having to program.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 25, 2016, 03:48:18 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: November 25, 2016, 05:14:44 pm
content: Quote from: Dave_PT on November 25, 2016, 03:48:18 pmThats not the way it would work. I haven't tried, but I think this way will work:1. enable serial comms in STMCWB2. 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) andisthe 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: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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 25, 2016, 05:52:12 pm
content: 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!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 30, 2016, 12:21:14 pm
content: 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, theSTEVAL-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 theSTSPIN32F0(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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: December 01, 2016, 07:09:48 am
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 01, 2016, 11:41:42 am
content: Quote from: tatus1969 on December 01, 2016, 07:09:48 amBut 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: December 01, 2016, 05:56:51 pm
content: I think that you'll not get happy with this EVB. Here is a statistic of my code as promised. Total=32512, willjustfit (?).Code:Modulero_codero_datarw_dataso_summain.o63641692466533xprintffull.o4186004186STO_CORDIC_SpeednPosFdbkClass.o277603372776ICS_LM1_PWMnCurrFdbkClass.o22000132200MCTasks.o1420552961972stm32f10x_tim.o1464001464MC_Math.o59251201104PWMnCurrFdbkClass.o782097782stm32f10x_adc.o71000710VirtualSpeedSensor_SpeednPosFdbkClass.o614025614DblDiv.o58200582stm32f10x_gpio.o52000520stm32f10x_rcc.o4442020464startup_stm32f10x_md.o46000460stm32f10x_i2c.o43400434DblMul.o41800418stm32f10x_dma.o41200412DblSub.o38400384PIRegulatorClass.o3640225364stm32f10x_usart.o29400294xdscale.o26800268system_stm32f10x.o25244256FltDiv.o25200252I64DivMod.o23800238FltSub.o23000230PQD_MotorPowerMeasurementClass.o228013228FltMul.o21600216DblAdd.o21200212localeconv.o1088080188RevupCtrlClass.o1840125184xxmemxmalloc.o17608176SpeednTorqCtrlClass.o172033172CircleLimitationClass.o16805168StateMachineClass.o134013134Virtual_TemperatureSensorClass.o13405134FltAdd.o13200132xxmemxfree.o12800128MotorPowerMeasurementClass.o1240281124Virtual_BusVoltageSensorClass.o12205122misc.o12000120ABImemcpy.o11800118SpeednPosFdbkClass.o1140133114MCInterfaceClass.o102065102xencoding_sb.o960096BusVoltageSensorClass.o9402994DblToI32.o880088memchr.o880088MCTuningClass.o78016178FltToDbl.o780078TemperatureSensorClass.o7202972FltToS32.o680068xdnorm.o660066strlen.o540054Gaps522054Timebase.o520452sprintf.o520052I32ToFlt.o500050stm32f10x_MC_it.o480048I32ToDbl.o480048DblCmpGe.o460046DblCmpLe.o460046copy_init3.o460046MCIRQHandlerClass.o4001640xgetmemchunk.o400440data_init3.o400040Linker_created039409639stm32f10x_dbgmcu.o360036FltCmpGe.o360036FltCmpLe.o360036FltToU32.o360036zero_init3.o340034xmbtowc.o320032FltCmpEq.o280028xwctomb.o260026stm32f10x_it.o240024cmain.o220022strchr.o220022setlocale.o20011620exit.o200020div.o140014cstartup_M.o120012xmbcurmax.o100010xsprout.o100010cexit.o100010exit.o4004low_level_init.o4004xtls.o2002I64DivZer.o2002

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 02, 2016, 09:14:40 am
content: Quote from: tatus1969 on December 01, 2016, 05:56:51 pmI 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 ??

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 02, 2016, 09:55:21 am
content: 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 documentRN0085, it says that the STM32F030C6 is supported, but only has 32Kb ...In fact, all the STM32FxxxC6 have 32Kb.

author: tatus1969
author_rank: Super Contributor
timestamp: December 02, 2016, 04:50:26 pm
content: Quote from: Dave_PT on December 02, 2016, 09:14:40 ami am curious about the response from STmy guess: marketing bubble, nobody tested it

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 02, 2016, 04:57:15 pm
content: Quote from: tatus1969 on December 02, 2016, 04:50:26 pmIt 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 ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 02, 2016, 05:57:46 pm
content: Today they provided an SDK for this EVB.http://www.st.com/content/st_com/en/products/evaluation-tools/solution-evaluation-tools/motor-control-solution-eval-boards/steval-spin3201.html

author: tatus1969
author_rank: Super Contributor
timestamp: December 02, 2016, 06:10:08 pm
content: Quote from: Dave_PT on December 02, 2016, 05:57:46 pmnaaaah. that's only "FiledOriented Control (FOC)", never heard of that

author: tatus1969
author_rank: Super Contributor
timestamp: December 03, 2016, 10:18:14 am
content: Quote from: Dave_PT on December 02, 2016, 04:57:15 pmThat'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 05, 2016, 09:38:33 am
content: What a crap ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 06, 2016, 11:55:13 am
content: I am designing a PCB to use the STM32F302R8 and drive my motor in full power.I still await ST official response about STSPINF0 ....

author: tatus1969
author_rank: Super Contributor
timestamp: December 10, 2016, 01:20:52 pm
content: Quote from: Dave_PT on December 06, 2016, 11:55:13 amisn'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: December 12, 2016, 09:27:36 am
content: Quote from: tatus1969 on December 10, 2016, 01:20:52 pmYes it is oversized.But as I'm late so the first board stays like this...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 25, 2017, 06:31:31 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: January 25, 2017, 10:48:33 pm
content: Quote from: Dave_PT on January 25, 2017, 06:31:31 pmit 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 26, 2017, 11:07:13 am
content: 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: January 26, 2017, 07:48:26 pm
content: Quote from: Dave_PT on January 26, 2017, 11:07:13 amdidn'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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 27, 2017, 10:02:48 am
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: January 27, 2017, 12:35:30 pm
content: Quote from: Dave_PT on January 27, 2017, 10:02:48 amThe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 27, 2017, 02:47:56 pm
content: 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- VbusGreen Line- Energy dissipated by resistanceBlue Line- DISSIPATED MOSFET (~ 4W).

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 27, 2017, 03:21:44 pm
content: R(j-a) = 120ºC/W4W = 360ºCThis is going to crackEverything 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!

author: tatus1969
author_rank: Super Contributor
timestamp: January 27, 2017, 07:36:32 pm
content: Quote from: Dave_PT on January 27, 2017, 02:47:56 pmIt 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 14, 2017, 06:32:39 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: February 14, 2017, 07:17:02 pm
content: maybe wrong turning direction? what happens if you swap two motor phases?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 14, 2017, 11:26:42 pm
content: 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 operationThe motor has the numbered phases (1 2 3), which I connected to (U V W).EDIT:Quote from: tatus1969 on February 14, 2017, 07:17:02 pmIn that case, would the sensorless control work?It's that the engine runs on sensorless ... but with the encoder I'm not lucky.

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 06:42:26 am
content: Quote from: Dave_PT on February 14, 2017, 11:26:42 pmswapping 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 10:06:39 am
content: Quote from: tatus1969 on February 15, 2017, 06:42:26 amI changed the alignment to 5 seconds. The current goes up and then the alignment ends.Quote from: tatus1969 on February 15, 2017, 06:42:26 amThis 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 ...Quote from: tatus1969 on February 15, 2017, 06:42:26 amYes, I am using STMCWB, but no error is shown.Quote from: tatus1969 on February 15, 2017, 06:42:26 amThe 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 10:14:30 am
content: Quote from: Dave_PT on February 15, 2017, 10:06:39 amI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 10:24:30 am
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 10:41:32 am
content: Quote from: Dave_PT on February 15, 2017, 10:24:30 amCan 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 11:02:44 am
content: 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/

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 11:32:04 am
content: Wait....Wait...Inspection loupe is talking to me!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 11:51:30 am
content: 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 12:34:04 pm
content: reflow process stability + leadfree solder = &%()§$$"§ ?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 12:47:43 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 01:46:56 pm
content: Quote from: Dave_PT on February 15, 2017, 12:47:43 pmexactly. 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 enough2) 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 02:43:27 pm
content: Quote from: tatus1969 on February 15, 2017, 01:46:56 pmRight 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 03:18:57 pm
content: 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...

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 03:23:53 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 03:32:14 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 15, 2017, 03:35:32 pm
content: Quote from: tatus1969 on February 15, 2017, 03:23:53 pmI will program a MCU to communicate with the encoder.So I can analyze what the registers have.

author: tatus1969
author_rank: Super Contributor
timestamp: February 15, 2017, 03:38:13 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 16, 2017, 10:28:59 am
content: Quote from: tatus1969 on February 15, 2017, 03:38:13 pmI 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...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 16, 2017, 12:21:06 pm
content: 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: February 16, 2017, 03:47:30 pm
content: Quote from: Dave_PT on February 16, 2017, 12:21:06 pmWhat 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 16, 2017, 03:59:08 pm
content: Quote from: tatus1969 on February 16, 2017, 03:47:30 pmIt 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 tracesNext I'll start doing the process that you recommend.Thank you.

author: tatus1969
author_rank: Super Contributor
timestamp: February 16, 2017, 04:14:11 pm
content: Quote from: Dave_PT on February 16, 2017, 03:59:08 pmdoes this happen with sensorless feedback?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 16, 2017, 04:24:14 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: February 16, 2017, 04:33:49 pm
content: Quote from: Dave_PT on February 16, 2017, 04:24:14 pmif 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: February 28, 2017, 02:04:29 pm
content: 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?

author: tatus1969
author_rank: Super Contributor
timestamp: February 28, 2017, 06:34:51 pm
content: Quote from: Dave_PT on February 28, 2017, 02:04:29 pmHow 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 01, 2017, 09:18:05 am
content: Quote from: tatus1969 on February 28, 2017, 06:34:51 pmthis is stupid, because it decreases the calculated mechanical velocity, instead of increasing it. Forget about that idea....

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 01, 2017, 09:54:32 am
content: Quote from: tatus1969 on February 28, 2017, 06:34:51 pmI 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/

author: tatus1969
author_rank: Super Contributor
timestamp: March 01, 2017, 01:18:18 pm
content: 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 tuningwiththat 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 velocityafterthe gear, which you don't). You can consider backlash as a disturber, leading to reduced precision, like a hysteresis.Quote from: Dave_PT on March 01, 2017, 09:54:32 amThis 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 toolow.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 01, 2017, 03:13:58 pm
content: Quote from: tatus1969 on March 01, 2017, 01:18:18 pmI'm always using the incremental encoder.I hope this magnetic encoder is not disturbing ...Quote from: tatus1969 on March 01, 2017, 01:18:18 pmYes.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.Quote from: tatus1969 on March 01, 2017, 01:18:18 pmThe 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.Quote from: tatus1969 on March 01, 2017, 01:18:18 pmYou 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?

author: tatus1969
author_rank: Super Contributor
timestamp: March 01, 2017, 05:37:26 pm
content: Quote from: Dave_PT on March 01, 2017, 03:13:58 pmhappy to hear that, the last that I noticed was that you were having trouble with itQuote from: Dave_PT on March 01, 2017, 03:13:58 pmI 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.cCode:uint16_t FOC_CurrController(uint8_t bMotor){Curr_Components Iab, Ialphabeta, Iqd;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))Curr_Components IqdHF = {0,0};#endifVolt_Components Valphabeta, Vqd;int16_t hElAngledpp;uint16_t hCodeError;hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC));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.Quote from: Dave_PT on March 01, 2017, 03:13:58 pmIt'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.Quote from: Dave_PT on March 01, 2017, 03:13:58 pmThat 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.Quote from: Dave_PT on March 01, 2017, 03:13:58 pmAs 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 10:02:22 am
content: Quote from: tatus1969 on March 01, 2017, 05:37:26 pmThe current step response graph is more complicated to obtain.Here is the speed response step response graph (for 1500RPM).Y - rotor speedHere is the current response step response graph, Iq (for 3Amps). NOTE: I have some oscillation in current control...Y - Iq currentQuote from: tatus1969 on March 01, 2017, 05:37:26 pmRotation setpoint = 100RPMWithout 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 ...

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 11:49:34 am
content: Quote from: Dave_PT on March 02, 2017, 10:02:22 amThat 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 werewayslower. Which brings me back to the start -->Quote from: Dave_PT on March 02, 2017, 10:02:22 amThe 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).

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 12:42:05 pm
content: 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/

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 12:47:29 pm
content: Quote from: Dave_PT on March 02, 2017, 10:02:22 amIf 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.Quote from: Dave_PT on March 02, 2017, 10:02:22 amThis 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 02:19:16 pm
content: Quote from: Dave_PT on March 02, 2017, 12:42:05 pmit 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 virtuallynotorque 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, thismightbe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 02:43:57 pm
content: Quote from: tatus1969 on March 02, 2017, 12:47:29 pmI 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.Quote from: tatus1969 on March 02, 2017, 12:47:29 pmExactly.I did not wait long enough...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 03:18:41 pm
content: Quote from: tatus1969 on March 02, 2017, 11:49:34 amQuote from: tatus1969 on March 02, 2017, 02:19:16 pmYes, I have confirmed and all PWM outputs are correct.Always in high state, except during the dead time on switching.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 03:33:08 pm
content: Quote from: tatus1969 on March 02, 2017, 02:19:16 pmHere 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 atriangle waveform.

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 04:09:24 pm
content: Quote from: Dave_PT on March 02, 2017, 03:33:08 pmsorry, mistaken. The value "Ia" and "Ib" should show sinusodial waveforms, the Iq just shows their amplitude.Quote from: Dave_PT on March 02, 2017, 03:33:08 pmNowthatlooks like a clue. The magnetic encoder having problems with magnets?That picture shows the motor running smoothly at higher rpm, right?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 04:17:38 pm
content: Quote from: tatus1969 on March 02, 2017, 04:09:24 pmIn that case Ia shows a sinusoid.The following picture shows Ia with the engine in charge at 1000RPM.Quote from: tatus1969 on March 02, 2017, 04:09:24 pmNo.This image is in the rotations that I have problems, in this case at 100RPM...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 05:07:44 pm
content: 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).

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 05:16:28 pm
content: Quote from: Dave_PT on March 02, 2017, 03:33:08 pmokay, as this is showing the low-rpm "oscillation" situation, you can be sure that itiscorrelated 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 02, 2017, 06:16:55 pm
content: Quote from: tatus1969 on March 02, 2017, 05:16:28 pmAbove 400/500RPM, with or without load on the motor shaft, the waveform is a perfect sawtooth.Quote from: tatus1969 on March 02, 2017, 05:16:28 pmNow 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.This change is the mystery...2000RPM to 100RPM in 25sec.VIDEO:https://meocloud.pt/link/b35a236c-0675-4494-9829-23860792966d/VID_20170302_180652.3gp/

author: tatus1969
author_rank: Super Contributor
timestamp: March 02, 2017, 08:15:12 pm
content: Quote from: Dave_PT on March 02, 2017, 06:16:55 pmThe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 09:45:01 am
content: Quote from: tatus1969 on March 02, 2017, 08:15:12 pmI'm going to try to use Feed Forward, but the control uses a PID. The derivative gain can be modified via register.Quote from: tatus1969 on March 02, 2017, 08:15:12 pmI 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.Quote from: tatus1969 on March 02, 2017, 08:15:12 pmYes I tested it.It works perfectly.0RPM to 1000RPM to -1000RPM to 0RPM, no problem.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 09:54:39 am
content: Quote from: Dave_PT on March 03, 2017, 09:45:01 amDerivative gain takes no effect....

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 10:10:55 am
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 12:05:29 pm
content: 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.Motor Power has also always zero ... strange.

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 12:18:34 pm
content: Quote from: Dave_PT on March 03, 2017, 09:45:01 amI 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.Quote from: Dave_PT on March 03, 2017, 09:45:01 amOkay, 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).

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 12:27:12 pm
content: Quote from: Dave_PT on March 03, 2017, 10:10:55 amIs 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 12:43:00 pm
content: Quote from: tatus1969 on March 03, 2017, 12:27:12 pmI 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 ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 02:50:03 pm
content: Quote from: tatus1969 on March 03, 2017, 12:27:12 pmFrom what I can see, it seems fine ...

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 05:54:17 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 06:25:14 pm
content: Quote from: Dave_PT on March 03, 2017, 02:50:03 pmThat 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 iskV = frequency * 60 / pole_pairs / amplitude_phase_to_phase * 0.95kV = 141 rpm/VFor a bus voltage of 24V, you can calculate the no-load speed:rpm_no_load = kV * bus_voltrpm_no_load = 3380 rpmI have no idea why the manufacturer advertises the motor for 4000 rpm @ 24V, it is certainly not able to achieve this.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 06:25:46 pm
content: 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 ...Quote from: tatus1969 on March 03, 2017, 05:54:17 pmHow 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 06:39:01 pm
content: Quote from: tatus1969 on March 03, 2017, 06:25:14 pmThis 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...

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 06:58:11 pm
content: Quote from: Dave_PT on March 03, 2017, 06:25:46 pmThe 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 07:33:41 pm
content: Quote from: Dave_PT on March 03, 2017, 06:39:01 pmNo problem, youre welcomeMy ~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?

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 07:35:27 pm
content: just found something interesting. The motor manufacturer website advertises them with "speed,400- 4000 rpm" right on the front page...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 08:22:48 pm
content: Quote from: tatus1969 on March 03, 2017, 07:35:27 pmI 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...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 03, 2017, 08:26:33 pm
content: Quote from: tatus1969 on March 03, 2017, 07:33:41 pmThe gear box yes, it has sealed bearings.The motor I can not confirm, but I think they are of the same type.

author: tatus1969
author_rank: Super Contributor
timestamp: March 03, 2017, 08:43:02 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 09:34:29 am
content: 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!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 10:11:45 am
content: 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.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 ....

author: tatus1969
author_rank: Super Contributor
timestamp: March 06, 2017, 04:39:28 pm
content: Quote from: Dave_PT on March 06, 2017, 10:11:45 amsounds 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 06, 2017, 04:49:00 pm
content: Quote from: Dave_PT on March 06, 2017, 09:34:29 amif 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 / currentAll that would be done in MCTasks.c, function FOC_CurrController(). You don't need the library source code for that mod.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 04:54:21 pm
content: Quote from: tatus1969 on March 06, 2017, 04:39:28 pmMaybe 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 04:58:41 pm
content: Quote from: Dave_PT on March 06, 2017, 04:54:21 pmStupid me.350 (worst case) + ~ 25% (deviation) = 450nS is enough!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 06:07:10 pm
content: Quote from: tatus1969 on March 06, 2017, 04:49:00 pmI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 06, 2017, 06:32:30 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 07:03:52 am
content: Quote from: Dave_PT on March 06, 2017, 06:07:10 pmYou 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 07:06:29 am
content: Quote from: Dave_PT on March 06, 2017, 06:32:30 pmThe 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 07:08:46 am
content: Quote from: Dave_PT on March 06, 2017, 04:58:41 pmEven 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 10:09:13 am
content: Quote from: tatus1969 on March 07, 2017, 07:03:52 amBut this should be done in open loop, right?I should be able to change the PWM and apply a value without controll loop.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 10:18:35 am
content: Quote from: Dave_PT on March 07, 2017, 10:09:13 amagree, 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:...Vqd.qV_Component1 = 1000; Vqd.qV_Component2 = 0; // <<<<<<<Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);hCodeError = PWMC_SetPhaseVoltage(oCurrSensor, Valphabeta);...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 10:52:47 am
content: I made the changes ... but I do not have rotation.I noticed that theFOC_CurrControllerfunction has a condition for "OPEN_LOOP".Can we use this?Code:/*** @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 inlineuint16_t FOC_CurrController(uint8_t bMotor){Curr_Components Iab, Ialphabeta, Iqd;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))Curr_Components IqdHF = {0,0};#endifVolt_Components Valphabeta, Vqd;int16_t hElAngledpp;uint16_t hCodeError;hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC));PWMC_GetPhaseCurrents(oCurrSensor, &Iab);Ialphabeta = MCM_Clarke(Iab);Iqd = MCM_Park(Ialphabeta, hElAngledpp);#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))if (oHFI){IqdHF = Iqd; /* Stores the Iqd not filtered */Iqd = HFI_FP_PreProcessing(oHFI, Iqd);}#endif// Vqd.qV_Component1 = PI_Controller(oPIDIq,// (int32_t)(FOCVars.Iqdref.qI_Component1) - Iqd.qI_Component1);//// Vqd.qV_Component2 = PI_Controller(oPIDId,// (int32_t)(FOCVars.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){Vqd = FF_VqdConditioning(oFF,Vqd);}#endifFOCVars.Vqd = Vqd;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))if (oHFI){Vqd = HFI_FP_VqdConditioning(oHFI, Vqd);}#endif#if defined(OPEN_LOOP) || (defined(DUALDRIVE) && defined(OPEN_LOOP2))if (oOL){Vqd = OL_VqdConditioning(oOL);}#endifVqd = Circle_Limitation(oCLM, Vqd);Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);hCodeError = PWMC_SetPhaseVoltage(oCurrSensor, Valphabeta);FOCVars.Iab = Iab;FOCVars.Ialphabeta = Ialphabeta;FOCVars.Iqd = Iqd;FOCVars.Valphabeta = Valphabeta;FOCVars.hElAngle = hElAngledpp;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))FOCVars.IqdHF = IqdHF;#endif#if defined(FLUX_WEAKENING) || (defined(DUALDRIVE) && defined(FLUX_WEAKENING2))if (oFW){FW_DataProcess(oFW, Vqd);}#endif#if defined(FEED_FORWARD_CURRENT_REGULATION) || (defined(DUALDRIVE) && defined(FEED_FORWARD_CURRENT_REGULATION2))if (oFF){FF_DataProcess(oFF);}#endif#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))if (oHFI){HFI_FP_DataProcess(oHFI, IqdHF);}#endifreturn(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 firmwareSomething like this:Code:Vqd.qV_Component1 = FOCVars.Iqdref.qI_Component1;

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 03:50:59 pm
content: I found the paper of the video.http://www.roboticsproceedings.org/rss10/p42.pdfBut I can not figure out how to start PWM ...I continue to explore the firmware code.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 05:02:23 pm
content: Quote from: Dave_PT on March 07, 2017, 10:52:47 amI have checked, yes, but it is doing exactly the same as our code. This is the function's source code:Code: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: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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 05:06:29 pm
content: Quote from: Dave_PT on March 07, 2017, 03:50:59 pmInteresting. 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

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 05:46:33 pm
content: Quote from: Dave_PT on March 07, 2017, 10:52:47 amThat 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 05:56:41 pm
content: Quote from: tatus1969 on March 07, 2017, 05:46:33 pmWhat 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 ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 06:05:53 pm
content: Quote from: tatus1969 on March 07, 2017, 05:02:23 pmI was gradually rise up to 32000.I have no rotation after doing start motor.But the motor shaft makes some force ...Code:State_t StateM1;StateM1 = STM_GetState(oSTM);if( StateM1 == RUN ){Vqd.qV_Component1 = 3000; Vqd.qV_Component2 = 0;}

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 07, 2017, 06:17:06 pm
content: Code:/*** @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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 06:45:54 pm
content: Quote from: Dave_PT on March 07, 2017, 05:56:41 pmi misunderstood that good idea,sorry

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 07:13:14 pm
content: Quote from: Dave_PT on March 07, 2017, 06:17:06 pmThis function limits the voltage vector amplitude such that the max PWM duty cycle is not exceeded, no worries about that.

author: tatus1969
author_rank: Super Contributor
timestamp: March 07, 2017, 07:16:34 pm
content: Quote from: Dave_PT on March 07, 2017, 06:05:53 pmcan 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 08, 2017, 09:15:58 am
content: Quote from: tatus1969 on March 07, 2017, 07:16:34 pmYes, the motor is already running.What can this mean?

author: tatus1969
author_rank: Super Contributor
timestamp: March 08, 2017, 09:50:18 am
content: Quote from: Dave_PT on March 08, 2017, 09:15:58 amI 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 currentAt 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 08, 2017, 10:02:25 am
content: I do not know if this can give any clue ...I had the motor running withVqd.qV_Component2 = 3000for ~ 15min.I turn off the motor and it is super hot! The whole motor is really hot!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 08, 2017, 12:07:43 pm
content: I did some tests to try to understand what's going on ...Code:encoder align 90ºVqd.qV_Component1 = 0;Vqd.qV_Component2 = 4000;Weak rotation. ClockwiseCode:encoder align 90ºVqd.qV_Component1 = 4000;Vqd.qV_Component2 = 0;No rotation.Code:encoder align 0ºVqd.qV_Component1 = 0;Vqd.qV_Component2 = 4000;No rotation.Code:encoder align 0ºVqd.qV_Component1 = 4000;Vqd.qV_Component2 = 0;Very weak rotation. Clockwise.

author: tatus1969
author_rank: Super Contributor
timestamp: March 08, 2017, 02:55:40 pm
content: Quote from: Dave_PT on March 08, 2017, 10:02:25 amIf 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 isnotan offset that would be added to the electrical orientation after alignment. It just determines atwhich anglethe 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 08, 2017, 03:16:31 pm
content: Quote from: Dave_PT on March 08, 2017, 09:15:58 am300ms 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 08, 2017, 03:20:17 pm
content: Quote from: Dave_PT on March 08, 2017, 12:07:43 pmGoogle is my friendThat 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...

author: tatus1969
author_rank: Super Contributor
timestamp: March 08, 2017, 03:30:08 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 08, 2017, 05:09:42 pm
content: Quote from: tatus1969 on March 08, 2017, 03:20:17 pmMaybe I'm doing something very wrongBut with these modifications I still have no rotation....

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 08, 2017, 05:37:52 pm
content: Quote from: tatus1969 on March 08, 2017, 03:30:08 pmI'll prepare everything to get these tests done.

author: tatus1969
author_rank: Super Contributor
timestamp: March 09, 2017, 09:02:23 am
content: Quote from: Dave_PT on March 08, 2017, 10:02:25 amSomething 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 13, 2017, 04:53:33 pm
content: Quote from: tatus1969 on March 08, 2017, 09:50:18 amI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 14, 2017, 05:02:13 pm
content: If I use 6 step commutation, will I be able to have lower speeds?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 14, 2017, 05:09:23 pm
content: They use FOC with BLDC ....

author: tatus1969
author_rank: Super Contributor
timestamp: March 14, 2017, 11:52:48 pm
content: 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 10:26:45 am
content: Quote from: tatus1969 on March 14, 2017, 11:52:48 pmGood luck!!Quote from: tatus1969 on March 14, 2017, 11:52:48 pmWhat 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/

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 02:38:32 pm
content: I made some adjustments on my board to run this example.I get a slow and smooth movement ...http://www.berryjam.eu/2015/04/driving-bldc-gimbals-at-super-slow-speeds-with-arduino/

author: tatus1969
author_rank: Super Contributor
timestamp: March 15, 2017, 02:59:41 pm
content: Quote from: Dave_PT on March 15, 2017, 02:38:32 pmchecked 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 15, 2017, 03:08:26 pm
content: Quote from: Dave_PT on March 15, 2017, 10:26:45 amthanksQuote from: Dave_PT on March 15, 2017, 10:26:45 amwhen 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 03:39:55 pm
content: 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 becauseI 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 controlis still not clear to me ...

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 05:48:18 pm
content: Maybe a mixed control will work.Low revsStepper motor (SVPWM)High revs6 step commutationI 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 ...

author: nuno
author_rank: Frequent Contributor
timestamp: March 15, 2017, 06:31:13 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 06:39:18 pm
content: HellonunoThanks 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...

author: tatus1969
author_rank: Super Contributor
timestamp: March 15, 2017, 09:15:01 pm
content: I have prepared some videos that show how I validated the relationship between phase voltages, phase currents, and the rotor position feedback. Hope this helpshttps://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

author: tatus1969
author_rank: Super Contributor
timestamp: March 15, 2017, 09:38:54 pm
content: Quote from: Dave_PT on March 15, 2017, 05:48:18 pm(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:uint16_t FOC_CurrController(uint8_t bMotor){Curr_Components Iab, Ialphabeta, Iqd;#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))Curr_Components IqdHF = {0,0};#endifVolt_Components Valphabeta, Vqd;int16_t hElAngledpp;uint16_t hCodeError;hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC));// <<<<<<<<<<<<<<<<<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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 15, 2017, 11:11:44 pm
content: Quote from: tatus1969 on March 15, 2017, 09:38:54 pmThanks 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.

author: nuno
author_rank: Frequent Contributor
timestamp: March 16, 2017, 02:10:00 am
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 07:40:07 am
content: Quote from: Dave_PT on March 15, 2017, 11:11:44 pmI'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...)

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 10:41:40 am
content: Quote from: tatus1969 on March 15, 2017, 09:15:01 pmIn 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/

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 10:59:17 am
content: Quote from: Dave_PT on March 16, 2017, 10:41:40 amJust to be sure: you mean the Hall senror here, right?Quote from: Dave_PT on March 16, 2017, 10:41:40 amwait, 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 11:04:35 am
content: Quote from: tatus1969 on March 16, 2017, 10:59:17 amYes yes... my mistake.

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 11:05:56 am
content: Quote from: Dave_PT on March 16, 2017, 11:04:35 amsorry by being picky, but that's necessary for me to follow closely from my "remote" position

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 11:28:18 am
content: Quote from: tatus1969 on March 16, 2017, 10:59:17 amApparently 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?Quote from: tatus1969 on March 16, 2017, 10:59:17 amThe reduction is 29: 1.Quote from: tatus1969 on March 16, 2017, 10:59:17 amYes. The amplitude got bigger, but the timing was the same.Quote from: tatus1969 on March 16, 2017, 10:59:17 amI 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/Quote from: tatus1969 on March 16, 2017, 10:59:17 amI 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/

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 11:35:14 am
content: Quote from: nuno on March 16, 2017, 02:10:00 amYes, the thread is already going long!Thanks to the precious help oftatus1969.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"

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 11:58:05 am
content: Quote from: tatus1969 on March 15, 2017, 09:38:54 pmThis 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...

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 12:15:40 pm
content: Quote from: Dave_PT on March 16, 2017, 11:28:18 amNow 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.Thisdefinitelymeans 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 12:35:22 pm
content: Quote from: tatus1969 on March 16, 2017, 12:15:40 pmI 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.862HzThe electrical rotations between the hall sensor pulses are 58.

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 01:08:42 pm
content: Quote from: Dave_PT on March 16, 2017, 12:35:22 pmIf it were exactly 58, then you would see synchronicity between hall and encoder. Which you don't. Its probably 58.01, or 57.99.

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 01:14:15 pm
content: Quote from: Dave_PT on March 16, 2017, 12:35:22 pmThat'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 seeexactlythe same voltage at AOUT whenever the hall sensor output is at trigger level.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 03:03:31 pm
content: 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º.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 03:27:01 pm
content: 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/

author: tatus1969
author_rank: Super Contributor
timestamp: March 16, 2017, 05:21:21 pm
content: 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.4msFrom 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 05:43:06 pm
content: I'm not sure there was any printing error, but on the sticker I got the indication that it's a 29: 1 reduction boxQuote from: tatus1969 on March 16, 2017, 05:21:21 pmThat's the best I can domanually.Quote from: tatus1969 on March 16, 2017, 05:21:21 pmI can give you these values.- time for one electrical motor rev = 20.02ms- lag of hall sensor after 58 electrical motor revs = 1.7ms1.7/58/20.02 = 0.00146Quote from: tatus1969 on March 16, 2017, 05:21:21 pmYes. The sawtooth wave is the electrical angle motor.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 16, 2017, 05:46:00 pm
content: It's not easy to solve this.

author: nuno
author_rank: Frequent Contributor
timestamp: March 17, 2017, 12:01:33 am
content: Quote from: Dave_PT on March 16, 2017, 11:35:14 amMaybe they rounded the number for the sticker.

author: mrflibble
author_rank: Super Contributor
timestamp: March 17, 2017, 06:23:13 am
content: I have not read the entire thread, just the last bits, so I might havemissed something... That said, if I understand correctly there is still someuncertainty regarding the gear ratio, correct?It should be 29:1 , but it justmightbe 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.Quote from: Dave_PT on March 16, 2017, 12:35:22 pmMaybe 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 signal2 - 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 / divshould do just that.3 - Turn on persistence4 - Use the right trigger type ....And the "right" trigger type depends a bit on the capabilities of yourscope. If it can do equivalent time sampling, use that. If it doesn'thave ETS then you probably can do a divide-by-N. As in set it to triggeron 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/128.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 youshould get 10 edges in the orange signal. Nice integer multiples. If on theother 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 ratioAnd 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 ratioWhat 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 ratioas per the datasheet that tatus1969 mentioned.Is say things like "pretty sure" and "probably" because I've seen enoughfunky shit with triggering on some scopes. Anyways, you will be ableto judge that since you know your scope. Case in point, on my HP boat anchorI would trust the results and say "sure" and "certain". But doing those samemeasurements 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 of29 instead of 58, then no worries. I did that accidentally on purpose. We canhappily ignore this factor of 2 because both ratios have a 2 in the denominatorof the prime decomposition.So if you insist on a factor of 58 then you still get similar results. The maindifference being that now for every 290(**)blue edges, you would get 5 orangeedges 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 thatCursor 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 ... stddevlarger than 1/3 * period of blue signal ==> probably not an integer multiple, so no 29:1 ratio.

author: tatus1969
author_rank: Super Contributor
timestamp: March 17, 2017, 10:32:05 am
content: Quote from: Dave_PT on March 16, 2017, 05:43:06 pmThe 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.pdfThey have a model with reduction ratio 1:28.93Quote from: Dave_PT on March 16, 2017, 05:43:06 pmI 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.Quote from: Dave_PT on March 16, 2017, 05:43:06 pmIf 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 angleDoes 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 withVqd.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 settingVqd.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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 17, 2017, 10:36:20 am
content: Quote from: nuno on March 17, 2017, 12:01:33 amAlways good to receive other opinions, we're a bit stuck here.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 17, 2017, 11:52:22 pm
content: Thanks for all the answers.I'll read everything carefully.For now I have a question.Quote from: tatus1969 on March 17, 2017, 10:32:05 amMy 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

author: tatus1969
author_rank: Super Contributor
timestamp: March 18, 2017, 08:47:59 am
content: Quote from: Dave_PT on March 17, 2017, 11:52:22 pmExactly.Quote from: Dave_PT on March 17, 2017, 11:52:22 pmNo. 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 startYou 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 clearlyQuote from: Dave_PT on March 17, 2017, 11:52:22 pmThat 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!).Quote from: Dave_PT on March 17, 2017, 11:52:22 pmI 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 11:39:39 am
content: 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 12:20:00 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 12:52:19 pm
content: 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!

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 12:57:19 pm
content: one idea: have you added that if(RUN)... around your open loop code? it is absolutely essential.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 01:00:01 pm
content: Quote from: tatus1969 on March 20, 2017, 12:57:19 pmYes. I think that's right.

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 01:06:13 pm
content: 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?

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 02:22:50 pm
content: Quote from: tatus1969 on March 20, 2017, 01:06:13 pmYes. 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 02:40:41 pm
content: 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!

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 02:54:23 pm
content: Quote from: tatus1969 on March 20, 2017, 02:40:41 pmI 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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 03:22:03 pm
content: Quote from: Dave_PT on March 20, 2017, 02:54:23 pmyes 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.Quote from: Dave_PT on March 20, 2017, 02:54:23 pm

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 05:01:35 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 06:38:05 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 09:49:42 pm
content: 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?

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 10:03:54 pm
content: Quote from: Dave_PT on March 20, 2017, 05:01:35 pmThat 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...Quote from: Dave_PT on March 20, 2017, 05:01:35 pmDid you compare torque in both spinning directions? Only if that is equal then you know that alignment is correct.

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 10:06:56 pm
content: Quote from: Dave_PT on March 20, 2017, 09:49:42 pmNo, 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).

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 10:09:28 pm
content: Quote from: Dave_PT on March 20, 2017, 06:38:05 pmLooks 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?

author: tatus1969
author_rank: Super Contributor
timestamp: March 20, 2017, 10:16:42 pm
content: 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 20, 2017, 10:40:15 pm
content: Quote from: tatus1969 on March 20, 2017, 10:03:54 pmI'm using anAS5047sensor.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.Quote from: tatus1969 on March 20, 2017, 10:03:54 pmI'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.Quote from: tatus1969 on March 20, 2017, 10:06:56 pmSo I did not screw up!Quote from: tatus1969 on March 20, 2017, 10:09:28 pmI 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.Quote from: tatus1969 on March 20, 2017, 10:16:42 pmI'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.

author: tatus1969
author_rank: Super Contributor
timestamp: March 21, 2017, 06:48:05 am
content: Quote from: Dave_PT on March 20, 2017, 10:40:15 pmThat 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.Quote from: Dave_PT on March 20, 2017, 10:40:15 pmWhat 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?Quote from: Dave_PT on March 20, 2017, 10:40:15 pmThat 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: March 21, 2017, 12:45:49 pm
content: Quote from: tatus1969 on March 21, 2017, 06:48:05 amThis almost does the job.I can control speeds around 100RPM ...

author: bayetan
author_rank: Contributor
timestamp: September 28, 2017, 10:00:13 pm
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: September 29, 2017, 10:52:07 am
content: Quote from: bayetan on September 28, 2017, 10:00:13 pmThat 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?

author: bayetan
author_rank: Contributor
timestamp: October 02, 2017, 12:35:09 pm
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: October 02, 2017, 08:10:02 pm
content: Quote from: bayetan on October 02, 2017, 12:35:09 pmThe SysTick ISR is perfect for this purpuse

author: bayetan
author_rank: Contributor
timestamp: October 09, 2017, 05:52:23 pm
content: 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

author: bayetan
author_rank: Contributor
timestamp: October 09, 2017, 06:46:23 pm
content: 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 Connect2) UART Tx/Rx for StartMotor3) UART Tx/Rx for StopMotorSome 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.

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

author: bayetan
author_rank: Contributor
timestamp: October 11, 2017, 08:06:35 am
content: 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 IHM08M1install R76, remove R77, install R80, remove R82, remove R85remove R181 - conflicts with Pot from speed controllerremove R63 - conflicts with BEMF3remove 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 wasspinning at 1200 RPM.

author: tatus1969
author_rank: Super Contributor
timestamp: October 12, 2017, 09:51:14 am
content: Quote from: bayetan on October 09, 2017, 05:52:23 pmThere 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.Quote from: bayetan on October 10, 2017, 01:30:55 amBoth 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.Quote from: bayetan on October 11, 2017, 08:06:35 am

author: bayetan
author_rank: Contributor
timestamp: October 14, 2017, 01:07:34 pm
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: October 14, 2017, 05:18:28 pm
content: Quote from: bayetan on October 14, 2017, 01:07:34 pmStart 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.Quote from: bayetan on October 14, 2017, 01:07:34 pmHaven't done that yet.Quote from: bayetan on October 14, 2017, 01:07:34 pmThey 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.Quote from: bayetan on October 14, 2017, 01:07:34 pmI 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 16, 2017, 02:15:10 pm
content: Hi, guyesI 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.

author: tatus1969
author_rank: Super Contributor
timestamp: October 16, 2017, 02:29:23 pm
content: Quote from: ali_asadzadeh on October 16, 2017, 02:15:10 pmThese are supported. But they are 32MHz only, and I wouldn't use them for high rpm / high pole count outrunners.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 17, 2017, 06:44:29 am
content: Thanks, but they are 48MHzand 0.5$ in quantity

author: bayetan
author_rank: Contributor
timestamp: October 31, 2017, 08:55:40 am
content: Quote from: tatus1969 on October 14, 2017, 05:18:28 pmAfter spending sometime with it, I finally realized that everything was hidden behind right-click context menu. Thanks.

author: bayetan
author_rank: Contributor
timestamp: October 31, 2017, 09:04:57 am
content: Quote from: tatus1969 on October 14, 2017, 05:18:28 pmYou 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.

author: bayetan
author_rank: Contributor
timestamp: October 31, 2017, 09:40:30 am
content: Quote from: tatus1969 on October 14, 2017, 05:18:28 pmI'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?

author: tatus1969
author_rank: Super Contributor
timestamp: November 01, 2017, 12:17:43 pm
content: Quote from: bayetan on October 31, 2017, 09:40:30 amDuring 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.

author: Emmsys
author_rank: Newbie
timestamp: May 15, 2018, 08:46:33 pm
content: 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

author: tatus1969
author_rank: Super Contributor
timestamp: May 16, 2018, 08:37:08 am
content: 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.Quote from: Emmsys on May 15, 2018, 08:46:33 pmNo, 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.Quote from: Emmsys on May 15, 2018, 08:46:33 pmThe 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: May 16, 2018, 08:45:02 am
content: Quote from: Emmsys on May 15, 2018, 08:46:33 pmSame 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.

author: r0d3z1
author_rank: Regular Contributor
timestamp: December 10, 2018, 01:36:54 pm
content: anyone know where the Board IHM08M1 can be found on stock ? or maybe, anyone would like to sell it ?

author: r0d3z1
author_rank: Regular Contributor
timestamp: January 23, 2019, 03:34:27 pm
content: is anyone using the SDK 5 ? it looks like quite buggy (also the documents have a lots of errors)

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 24, 2019, 10:14:26 pm
content: Sorry in advance, was tempting to just ask:"What the FOC?"

author: Dave_PT
author_rank: Frequent Contributor
timestamp: January 25, 2019, 10:02:22 am
content: FOCField Oriented ControlSome simple overview:https://www.roboteq.com/index.php/applications/100-how-to/359-field-oriented-control-foc-made-ultra-simple

author: psyke
author_rank: Contributor
timestamp: November 04, 2019, 05:58:45 pm
content: 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

author: r0d3z1
author_rank: Regular Contributor
timestamp: November 05, 2019, 07:17:07 am
content: 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 ?

author: psyke
author_rank: Contributor
timestamp: November 05, 2019, 02:38:16 pm
content: 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 05, 2019, 02:57:05 pm
content: 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.

author: psyke
author_rank: Contributor
timestamp: November 06, 2019, 12:30:26 am
content: The PPR are correct, they are set to 1024 pulses per rev, which is the default forAS5147P 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_A4wUThis 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

author: tatus1969
author_rank: Super Contributor
timestamp: November 06, 2019, 09:44:42 am
content: 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).

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 06, 2019, 10:05:46 am
content: 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.

author: psyke
author_rank: Contributor
timestamp: November 06, 2019, 02:09:44 pm
content: Thank you for answering guys.Quote from: tatus1969 on November 06, 2019, 09:44:42 amOk, 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?Quote from: Dave_PT on November 06, 2019, 10:05:46 amIn 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 libraryI 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.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 06, 2019, 03:56:02 pm
content: 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 ...

author: psyke
author_rank: Contributor
timestamp: November 06, 2019, 04:18:56 pm
content: I measured number of pole pairs with ST’s method, energizing 2 phases and counting the amount of snaps in a single revolutionI tried changing two phases order with no success, it does the same

author: tatus1969
author_rank: Super Contributor
timestamp: November 06, 2019, 06:19:22 pm
content: Quote from: psyke on November 06, 2019, 02:09:44 pmI'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.Quote from: psyke on November 06, 2019, 02:09:44 pmThe 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.

author: psyke
author_rank: Contributor
timestamp: November 06, 2019, 07:01:13 pm
content: Quote from: tatus1969 on November 06, 2019, 06:19:22 pmOk, 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

author: psyke
author_rank: Contributor
timestamp: November 06, 2019, 07:17:17 pm
content: 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

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 06, 2019, 07:36:39 pm
content: 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.

author: r0d3z1
author_rank: Regular Contributor
timestamp: November 11, 2019, 08:22:57 am
content: 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.

author: psyke
author_rank: Contributor
timestamp: November 12, 2019, 02:15:16 pm
content: 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 workedThank you to all who helped me

author: Dave_PT
author_rank: Frequent Contributor
timestamp: November 12, 2019, 02:28:12 pm
content: Story Summary:Quote from: Dave_PT on November 06, 2019, 03:56:02 pmQuote from: psyke on November 06, 2019, 04:18:56 pmQuote from: psyke on November 12, 2019, 02:15:16 pmGlad to know it already works

author: r0d3z1
author_rank: Regular Contributor
timestamp: November 12, 2019, 05:10:33 pm
content: Quote from: psyke on November 12, 2019, 02:15:16 pmI 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 ?

author: psyke
author_rank: Contributor
timestamp: November 13, 2019, 12:04:08 am
content: Quote from: r0d3z1 on November 12, 2019, 05:10:33 pmThank youI 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.

author: psyke
author_rank: Contributor
timestamp: November 19, 2019, 05:01:47 pm
content: 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 controlThank you

author: r0d3z1
author_rank: Regular Contributor
timestamp: November 20, 2019, 11:31:48 am
content: As far as I know position control is not supported by the library, but you can add it by yourself.

author: r0d3z1
author_rank: Regular Contributor
timestamp: January 13, 2020, 10:51:55 am
content: 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).

author: psyke
author_rank: Contributor
timestamp: January 13, 2020, 03:27:25 pm
content: Hi r0d3z1I 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

author: ozgurazazi
author_rank: Newbie
timestamp: June 25, 2025, 02:17:22 pm
content: hello community. i have a f303re card and an ıhm08m1 card. i need to drive a bldc motor with foc control. but i am encountering some problems.1) although i enter the nominal speed as 1000rpm, it goes up to 2300rpm in the motorpilot interface and i cannot control the speed.2) the power supply i have can provide max 5A current. the motor draws max 24A current. i am getting an overvoltage error.what is the reason for these problems?can you please help?its my final exam ı must finish in 2 weeks.

author: tatus1969
author_rank: Super Contributor
timestamp: June 26, 2025, 11:51:20 am
content: Quote from: ozgurazazi on June 25, 2025, 02:17:22 pmit's possible that the motor commutation is off angle, or the motor spinning direction is wrong. in that case the controller may fully open up, trying to have it spin in the wanted direction where it doesnt.the overvoltage error isnt related to current draw, but a sign of regen operation. this happens when decelerating the motor's inertia. the regenerated energy is pumped into the dc bus capacitance, with no limit to that basically -> voltage climbs to infinity. either increase capacitance, or add brake resistor. quick fix is to put a battery in parallel (-> close to infinite capacitance).