• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 82 subscribers
  • Views 1307 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 13a acts as though there is a maximum following error

Steve Ressler
Intellectual 270 points

Other Parts Discussed in Thread: DRV8312, DRV8301

Hello,

I am experimenting with lab 13a with my own motor connected to the DRV8312EVM board, and the lab starts out as expected. The motor holds its starting postion, however if I rotate the rotor manually a bit, say a quarter turn, the motor seems to lose its holding torque and it never turns back on.

Is this the expected behavior? If so, is there a way to change this?

Thanks,
Steve

  • 0
    Guru 12800 points

    Steve,

    The DRV8312 kit is only a 3.5A continuous board.  It is very easy to apply too much torque to the shaft of your motor and it causes the driver chip to have an over current fault because the controller is applying more and more current to return to the goal position.  

    One thing you could do is reduce the USER_MOTOR_MAX_CURRENT_A in the user.h file.  This will prevent the controller from demanding a lot of current and causing the driver chip to have an overcurrent fault.

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Hi Adam,

    I've got that set to 2.3 in my user.h file, so this shouldn't be the cause. Is there something else that could be happening?

    #define USER_MOTOR_MAX_CURRENT (2.3)

    Thanks,

    Steve

  • 0 in reply to Steve Ressler
    Guru 12800 points

    Steve,

    Have you been able to confirm the encoder is functioning correctly using lab 12?  Can you check the version of the compiler that you are using?  I've found that if the version of the compiler is < 6.2.3 it will cause issues.

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Adam,

    The encoder is functioning. I can read the value in the debug window.

    Compiler version is 6.2.5

    -Steve

  • 0 in reply to Steve Ressler
    Guru 12800 points

    Were you able to control the speed of the motor in lab 12?  This will confirm that the encoder and motor are wired correctly.

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Yes, I can control the speed in lab 12

    Incidentally, the same issue exists here as well. If I stop the shaft from spinning with my finger, it doesn't return to the proper speed.

    -steve

  • 0 in reply to Steve Ressler
    Guru 12800 points

    When you start up the system does gMotorVars.CtrlState go through CTRL_State_RsOnLine?  During this state the system will align the motor and the encoder.  If this doesn't happen than the motor will not produce 100% torque.  

    Can you attach your user.h file?

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Adam-

    gMotorVars.CtrlState progresses CTRL_State_Idle -> CTRL_State_OffLine -> CTRL_State_OnLine

    and gMotorVars.EstState progresses through EST_State_Idle -> EST_State_Rs -> EST_State_OnLine

    Attached is user.h

    2705.user.h

    Thanks for your help getting this sorted out,

    Steve

  • 0 in reply to Steve Ressler
    Guru 12800 points

    Steve,

    When you get into the condition where there is no control, is there a value in gMotorVars.SpinTAC.PosCtlErrorID?

    It is possible that you are tripping the short circuit protection in the DRV8312 due to the very low inductance of this motor.  I don't have a motor with that low of inductance to test with.  

    Do you have a DRV8301 board that you can test with?

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Adam-

    >When you get into the condition where there is no control, is there a value in gMotorVars.SpinTAC.PosCtlErrorID?

    It does, I hadn't noticed this. The error code is 2002.

    Also, I noticed that when gMotorVars.SpinTAC.PosCtlBwScale is above a certain value, gMotorVars.SpinTAC.PosCtlErrorID is set to 1013. This appears to be saturating the bandwidth. Is this an issue?

    >It is possible that you are tripping the short circuit protection in the DRV8312 due to the very low inductance of this motor.  I don't have a motor with that low of inductance to test with.  

    FYI the motor is a robodrive 25 and the specs are here: http://www.tq-group.com/fileadmin/web_data/tx_datamintstqproducts/downloads/tq_db_rob_torque-servomotor_en_104_mail.pdf

    >Do you have a DRV8301 board that you can test with?

    I do not, but I can get one if you think it would be worth trying.

    Thanks again,

    Steve

  • 0 in reply to Steve Ressler
    Guru 12800 points

    Steve,

    The 1013 error just means that the bandwidth value has been saturated, that error can be ignored.  

    The reason I asked about the 2002 error is because that error indicates that the position error has exceeded the maximum allowable position error.  This is a safety feature that by default is set to 2 mechanical revolutions in spintac_position.h.  

    You can watch the position error signal in "st_obj.pos.ctl.PosErr_mrev", this is an IQ24 variable.

    If you get the 2002 error you should be able to manually rotate the motor until the position error value reduces below 2.0, this should clear the error and it should be trying to control at that point.

  • 0 in reply to Adam D. Reynolds
    Intellectual 270 points

    Adam,

    I think there were actually two issues going on at the same time. One was the max position error setting in spintac_position.h which I didn't know about. This works just as you described.

    The other issue was a mechanical one specific to my test setup. It appears the motor rotor and optical encoder were slipping relative to one another gradually when the motor was under load. This caused the performance degrade over time.

    Thanks for your help,

    Steve