2020-10-09 03:49 PM
I am working with a custom SM-PMSM, and built a motor drive to power it.
The motor does not start, and the START-UP FAILURE always occurs.
There is a pulse of current delivered to the motor, which I assume is used to orient the rotor.
Using the monitor in motor control workbench, it shows speed ramping from 0 - 100, and then the failure is indicated. Note that despite the speed measurement, the motor is not moving. The only motion I observe is the rotor wobbles briefly with the current pulse I mentioned.
Here are the motor parameters I know for certain:
Ld and Lq are not known, but were estimated to be 6.5 mH each using a benchtop VFD to test. I plan to do a DC standstill test to try to get a better estimate of Ld and Lq.
I set the motor control parameters as follows in MC workbench
On the motor control board, I have scoped all 6 MOSFETS and verified all are switching.
This board uses 2 isolated current sensors, and measurements show the current sensors are following the acual current which was measured with a Hall effect probe.
Another thing I noticed using the monitor in MC workbench is the the currents Id and Iq seem to be ramping up prior to the fault.
Any suggestions as to settings etc. I can try to get this motor turning?
2020-10-16 01:13 AM
Dear @DTard.1
Welcome to the STM32 Community
Could you give more details to the STM32 Community about the material you use (HW and SW, CPU(s), tools and versions, board(s), motor(s) and so on)?
And more especially did you use MC tools (such as MC_suite, MC-Motor Profile, MC-SDK, MC-workbench, and so on)?
Best regards
Laurent Ca...
2020-10-16 08:58 AM
For motor control HW, I am using a NUCLEO-F446RE, mounted to the custom motor driver board I mentioned in my first post.
This board board consist of 6 MOSFETs in a standard 3 phase inverter arrangement, with gate drives, power supplies and 2 isolated current sensors.
I can provide more specific details of this if required.
MC workbench 5.4.4 and MC-SDK were used to develop the SW for motor control. MC Profile was not used since I don't have the particular hardware to run motor profile.
I am also using STM32CubeMX version 5.6.1 and STM32CubeIDE version 1.3.0
At this time, the only user addition I made was to add a 'heartbeat' LED by toggling LD2 on the NUCLEO 1 time per second.
I have attempted to spin the motor in 2 ways: using the monitor feature in MC-workbench, and also be inserting commands in the main while loop.
The commands used are MC_ProgramSpeedRampMotor1(100, 3000) and MC_StartMotor1().
If I am using the MC-workbench monitor to try to run the motor, I comment out these 2 commands.
Let me know if you need any more specific information.
Thank you
Dale
2020-10-16 12:09 PM
Here is some more information I can add to describe this problem.
case START:
{
/* Mechanical speed as imposed by the Virtual Speed Sensor during the Rev Up phase. */
int16_t hForcedMecSpeedUnit;
qd_t IqdRef;
bool ObserverConverged = false;
/* Execute the Rev Up procedure */
if( ! RUC_Exec( &RevUpControlM1 ) )
{
/* The time allowed for the startup sequence has expired */
STM_FaultProcessing( &STM[M1], MC_START_UP, 0 );
}
else
2020-10-20 11:32 AM
Hello
First of all I noticed an issue in your startup parameters. Indeed your minimum start-up output speed is equal to your final speed ramp value (100 rpm), with this settings you can get a STARTUP_FAILURE error .Indeed one of the conditions to close the loop is that your observer measures a speed greater than your "minimum start-up output speed" (i.e. 100RPM). So when you will reach 100rpm the revup controller will detect that it is the end of the startup phase and as the observer has not measured a speed greater than 100rpm it will raise a fault. Then I suggest to decrease your "minimum start-up output speed" to maybe 80 or 90 RPM.
The other issue is that the motor does not spin during startup phase which is necessary to make the observer converge. So if your motor only wobbles that's not good. Could you please try to decrease the current of your startup phase. You can do it by opening "configuration" panel in the monitor and maybe divide by 2 the "final torque" value. Here the current is expressed in S16A unit which is equal to (current_in_ampere*65536*shunt*Amplification_gain)/uC_VDD.
In this panel you have access to the five stages of the startup phase so can try tune them and check that you are able to make the motor spin.
If it still not work then please activate the two DAC channels in debug mode (if not already done) in the panel DAC functionality and select Ia on one channel and Ib on the other. generate the project and copy\paste elsewhere the IOC file that has been generated by the MC workbench. Edit it with a text editor and look for OPEN_LOOP_FOC. Set this value to true and open this IOC file with cubeMX in order to generate the code. Compile and flash the firmware, display in your debugger the handle OpenLoop_ParamsM1. At this point you will be in open loop mode and the firmware will force the PWM duty cycles to inject voltage sinusoids without checking the currents.
Launch the firmware, open the monitor and start the motor. the motor should spin, if not or if it wobbles then try to increase/decrease the voltage by modifying in your debugger the value of the field "OpenLoop_ParamsM1.hVoltage". Take care of the current and temperature (apply a limitation on your DC supply). Observe Ia and Ib on the DAC channels and check that the current signals are clean and aligned with what is measured by your current probes.
Note: the speed that is displayed during startup phase is the speed of the rotating magnetic field imposed by the stator and not the rotor itself. The rotor usually follows it but when it does not follow it the startup phase needs to be tuned. When the loop is closed then it is the rotor's speed.
Best regards
2020-10-26 11:23 AM
Hello
I followed through on the steps to reduce the start up current, and edit the final torque values.
Although the motor did not spin, I noticed 2 improvements in operation.
First, the output current is now sinusoidal.
Second, the motor attempts to spin 1 or 2 rotations, before stopping.
The fault in this case is SPEED SENSOR FAULT.
I started making the changes to attempt to drive open loop.
I was distracted by another project, so only now am able to refocus on this and attempt to drive open loop.
I will follow up with a report on the result of this testing.
Also, I ordered an X-NUCLEO-IHM08M1 hopefully to use Motor profiler to determine the Rs and Ls parameters for the motor.
Thank you
Dale
2020-10-28 11:01 AM
Hello
I followed the instructions to attempt to drive open loop, but I still get a SPEED_FDBK fault.
When probing the circuit, I have observed that current Ia is the expected sinusoidal current.
Phase V (Current Ib) appears to output no current.
AN open circuit was found and corrected.
I can now spin the motor, but not consistently.
Sometimes it takes several attempts before the motor will spin.
I would like to investigate the current feedback and determine if the values seen by the MCU match what is measured.
In the earlier step you referred to monitoring OpenLoop_ParamsM1.hVoltage, but the debugger does not seem to recognize this.
I think it would be wise to validate the current feedback before progressing to tuning.
Any advice to proceed with this?
2020-10-28 11:58 AM
Hello,
SPEED_FDBK fault should not occur in OPEN_LOOP_FOC mode and OpenLoop_ParamsM1 is available only if the OPEN_LOOP_FOC is set to true in your IOC file. Please close cubeMX, edit your IOC file, set OPEN_LOOP_FOC to true and save it. At this point you can reopen your IOC file with cubeMX and click on "generate code". I advise you to generate your open loop foc code in another directory. You should see in mc_tasks.c OpenLoop_ParamsM1 in MC_boot routine. Then please compile your project, flash the board and start your motor. Your motor should spin and you can check that Ia and Ib displayed thanks to the DAC (these are what the firmware reads from ADC) are OK. You can also store FOCVars[M1].Iab.a and FOCVars[M1].Iab.b in an array each time the routine FOC_CurrControllerM1 is called and dump this array, then convert the values in Ampere thanks to the formula I gave and compare them to what you probed.
Best regards
2020-10-28 04:00 PM
Hello
For some reason, I can't get the open loop to work.
It seems to ramp up the frequency quite high, and then stops.
However, I have used the DAC channels to observe the current signals during operation.
there appears to be good agreement between the signal at the DAC pin as well the analog signal from the current sensor.
I am also comparing this with what I see using a hall effect current probe.
I can work with this to validate the current feedback.
Any thoughts on open loop? Could this be related to the setting of OpenLoop_ParamsM1.hVoltage?
2020-10-29 12:29 AM
Hello,
Yes it could be, you can try to increase or decrease it. You can also modify the speed by default it is set to 100 RPM. This can be done directly with the monitor.
Best regards