Problems with SDK3.2 and MCWB 2.0

[philipphilip9]

Posted on September 14, 2012 at 02:21

I have an IPMM with absolute position resolver mounted on it. Unfortunately i can not use it even with decoder - absolute position to 12-16 bit paralel interface. Thats why i try to run in sensorless modes with 2 insulated current sensors.

I tried with 3.0 and MCWB 1.2 but wasnt able to run the interrupts and the serial communication. After that i tried with 3.2 and workbench 2.0 and the FW compiled correctly. When try to connect MCWB 2.0 to FW 3.2 there is an error that says some version incompatibilities. I connect FW 3.2 (with parameters generated from MCWB2.0) with serial communication to MCWB 1.2. Then i have the motor spinning just for few turns. It behaves like that: First it runs DC for few miliseconds and after that it generates 9 sine waves with frequency 20 Hz and maximum voltage (PWM 0-100%). After that the motor stops and displays Speed Feedback Error. In one of 10 or 20 runs the FW halts on the moment with the DC on the motor and looses commmunication with the PC. I have to reset the board so i can have it working again. Please tell me what i do wrong so i can not run the motor in sensorless mode? Is it very critical about motor parameters? Also what is wrong so FW 3.2 can not communicate to MCWB 2.0 ?

[Gigi]

Posted on September 18, 2012 at 17:35

Ciao Philip

It seems very strange. The table of checked compatibilities between FW lib and Workbench is this: FW Lib v3.0 - MC Work Bench 1.0.2 -> (No real time communication implemented) FW Lib v3.0.1 - MC Work Bench 1.2 -> (Real time communication implemented) FW Lib v3.2 - MC Work Bench 2.0 -> (Real time communication implemented) I can say that ''out of the box'' this combination shuould work so the best suggestion I can give to you is to come to the original FW disinstalling and reinstalling the MC lib. and it shall work. If not I suggest to spend some time to read the STM32 PMSM MC Library v3.2 User manual.pdf or the Quick Start for STM32 PMSM MC Library v3.0.pdf (present in the v3.0 installation folder). Then swithcing back to the problems you have I think that in the first case:

the motor spinning just for few turns.

It behaves like that: First it runs DC for few miliseconds and after that it generates 9 sine waves with frequency 20 Hz and maximum voltage (PWM 0-100%). After that the motor stops and displays Speed Feedback Error. It is a ''normal'' behaviour. The sensorless algortithm start to work just when the motor has been already bringed to a sufficient speed and so the BEMF have a good amplitude. To do that a start up procedure has been implemented. The DC you see shall be the allignment phase and after that there is the acceleration phase (the 20Hz and current that you see is the one that you have set in the MC Workbench -> Drive Mamagement -> Startup block). If you read the Speed Feedback Error (and not the RevUp Fails) this means that the sensorless algorithm has been converged for some times (the time required to pass in RUN state) and then it looses the reliability of the measurement. First of all it is important to understand if the motor has been proper bringed to run. If the motor just vibrate witout really turning it is the case to adjust the startup parameters lowering the accelleration or increasing the current supplied. If the motor runs really then is importatn to take a look at the waveform of the BEMF observed and at the waveform of the Electrical angle Observed. And this can be easily done using the DAC capabilities of the FW. If the BEMF is noisy the best thing is to divide by 2,4,8 the G2 parameter of the observer. While if the BEMF are pretty good sinusoidal shape but the Electrical angle is not a good triangle then you can divide by 2 the KI of the PLL. Other important point to check is the Variance threshold of the sensorless algorithm or the number of check befor to rise the speed fault (all parameter that you can set in the MC workbench) and also the minimum speed to validate the startup. So you have a lot of parameter to play with. Just use the wise techinque to make just one change for each try. Finally regarding the last issue I think that it can be caused by an HardFault (maybe some stack overflow or similar). It is not a normal behaviour and it shall not occurs if you don't modify the code (but bug is always possible). So, if you want, post your configuration (.stmc file) and I will try to reproduce the issue. Ciao Gigi

[Laurent Ca...]

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

Best regards