• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 619 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Lab 12b : Inconsistent Speed Runaway Problem

Niels Smidth
Prodigy 60 points
Other Parts Discussed in Thread: MOTORWARE

Hello,

I have been developing using sensor-less commutation for a while now, and am currently experimenting with using sensored speed control again. I am going back to lab 12b to start simple. I will mention I am controlling a PMSM whose output is connected to a gearbox. I have run this configuration sensorless with few problems, but am seeking the smooth startups of sensored control.

 I have left the speed ref value as the default 0.1krpm and have my BW set at 5. Upon setting the Run_Identify and enableSys flags, after Rs was recalculated, two possible things happen:

1) the motor spins up to 0.1krpm and spins smoothly

2) the motor quickly (definitely faster than the max_accel = 0.2krpmsps) accelerates to either -2.5 or 2.5 krpm and stays there.

The maximum speed of my motor is defined as 2.25krpm in the User.h file. The strangest part of this phenomenon is that I can't seem to find any consistent reason for either of these cases happening, it is seemingly completely random.

I dug a big deeper, to be sure all the control signals going into the Spintac Vel CTL unit were correct.

When the motor is running at the desired 0.1krpm, as expected the st_obj.vel.ctl.velLPF = 0.004 (which is multiplied by the constant 24 to get 0.1).  The .out value is 0.036.

When the motor is running out of control, I noted the st_obj_vel.ctl.VelRef = 0.00417 (multiplied by 24 to give 0.1, which means my velocity reference is the correct, desired value). The .VelLpf = -0.1059 (multiplied by 24 to give ~-2.5, meaning that my runaway speed is getting back to the Vel CTL unit correctly). The .Out value is 0.3636.

In this case, the runaway speed is a large negative value, and the system is trying to apply a large positive torque to correct it, but it continues to spin in the other direction. I would think next that there is a problem with the CTRL object, I don't see any error codes there. I will investigate the settings/input signals to the CTRL object tomorrow.

Any ideas on this problem? It's got me pretty stumped...

  • 0
    Guru 12800 points

    Niels,

    I've seen this problem before when using a sensored motor connected to a load of some kind with labs 12 & 13.  Those labs need the align the motor and encoder together in order to have good control.  This is accomplished when you start the system and it goes into EST_State_Rs.  

    During EST_State_Rs, the system is injecting d-axis current into the motor which is forcing it to a zero degree electrical angle.  Since we know the system is at zero degrees electrical we are able to save the encoder reading and have the motor and encoder be aligned.

    If the motor isn't able to reach an electrical angle of zero during this step, than it will be difficult to control the motor.  In extreme cases, it will cause the motor to spin at maximum rated speed like you found out.

    My advice would be to increase the USER_MOTOR_RES_EST_CURRENT_A in the user.h file.  This will use additional current in order to align the motor and encoder, which should guarantee a higher degree of success in getting your motor and encoder into alignment.

  • 0 in reply to Adam D. Reynolds
    Prodigy 60 points

    Hi Adam,

    Thanks so much for your answer. I implemented your change:

    #define USER_MOTOR_RES_EST_CURRENT (6.0)

    where 6A is my max power supply current.

    I found that out of maybe 25 startups I have done this morning, only 2 of them did runaway. I will blame this partially on the gear box on the output, which has been noted to have certain "locations" that have very high friction. I suppose this could be fixed with a higher current rated power supply (as my motor is rated for ~18A) to guarantee a lock to zero electrical angle.


    For now, this reliability will work fine for me, I can't thank you enough for your answer! I would have never thought to try changing RES_EST_CURRENT, are there any sections in the manual or other documentation that discuss this topic so I can read up on it more?

  • 0 in reply to Niels Smidth
    Guru 12800 points

    Niels,

    I'm glad that helped fix the issue.

    In the InstaSPIN-FOC & -MOTION User's Guide there is a section that talks about sensored systems.  That should have some information.  The other place to look would be the InstaSPIN-FOC & -MOTION Lab Guide (provided with MotorWare).  Between these two this should provide some more information about what is happening "under the hood."

    The trick that we are doing for alignment is really just a development trick.  It could be used in your final application, but it is advisable to use a more reliable homing method for your application.

  • 0 in reply to Adam D. Reynolds
    Prodigy 60 points

    Adam,

    I'll definitely read over those sections again to see what I can find.

    I am curious on the more reliable method for reducing the initial electrical angle to zero. Since I can't move the motor using encoder feedback until I've locked it into zero electrical angle position, would you suggest I move the motor with estimator feedback or something even lower level?

    Thanks,

    Niels

  • 0 in reply to Niels Smidth
    Guru 12800 points

    Niels,

    There are a couple of options.  You could look into different encoder types that have an absolute component.  These are great because you can read the initial absolute position over SPI, but still use quadrature inputs into the microcontroller.  You could apply much more current in order to get 100% sure you are at zero electrical.  Another option is to enter a jog mode until you hit a limit switch or an index line, you could use the sensorless estimator to do this and switch over to the encoder once it has been calibrated.

  • 0 in reply to Adam D. Reynolds
    Prodigy 60 points

    Adam,

    I am actually using a magnetic rotary sensor just like you suggest (quadrature inputs to microcontroller), I'll look into using its absolute position mode for this use.

    Thanks for all your posts, I really respect a company that stands behind their products and answers questions so quickly!

    Niels