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.

free-wheeling with InstaSPIN Motion

We are implementing a position controller using Lab 13b as the base. Using DRV8301kit, PMSM motor (similar to Teknic model) with encoder feedback.

Some questions that we are unclear about;

1) When using the enconder setup. And gMotorVars.Flag_enableUserParams = true. Is the FAST estimator running at all during normal operation?

2) And the statement
    CTRL_setFlag_enableCtrl(ctrlHandle,false);
Does it relate only to the FAST estimator?
Or does it also disable the blocks inside the FOC block, like the ID and IQ PI controllers, etc.. and ultimately not feed any drive signals to the power switches.


We are trying to find a good way to switch into a free-wheel mode. Possibly during a move (as a safety trip) for example if the motor is drawing more than expected current.

Simply using the statement
    HAL_disablePwm(halHandle);
I'm guessing is not a good idea.

3) Also, is there a quick description as to what the difference is between;

CTRL_runOnLine_User(handle,pAdcData,pPwmData,electricalAngle);
CTRL_runOnLine(handle,pAdcData,pPwmData);
CTRL_runOffLine(handle,halHandle,pAdcData,pPwmData);

But these functions may be internal to the FOC and nothing we need to be worrying about..

Thanks in advance.

  • Bernard,

    Bernard Pottner said:
    1) When using the enconder setup. And gMotorVars.Flag_enableUserParams = true. Is the FAST estimator running at all during normal operation?

    The example labs projects don't completely remove the FAST estimator because it is used for the state machining of the motor and encoder alignment.  Once you have modified the code so that you use your own method of aligning the motor and the encoder you can completly remove the FAST estimator from the code.

    Bernard Pottner said:
    2) And the statement
        CTRL_setFlag_enableCtrl(ctrlHandle,false);
    Does it relate only to the FAST estimator?
    Or does it also disable the blocks inside the FOC block, like the ID and IQ PI controllers, etc.. and ultimately not feed any drive signals to the power switches.

    It does not relate to the FAST estimator.  Setting this function to false will disable the FOC blocks and place the CTRL object into Idle mode.

    You can call HAL_disablePwm(halHandle); and continue to run the FOC.  But if you do this it is important that you update the position control reference with the current motor position otherwise when you call HAL_enablePwm(halHandle) there will be a huge jump in the motor control since it is now immediately trying to run back to a previous position.

    Bernard Pottner said:
    3) Also, is there a quick description as to what the difference is between;

    CTRL_runOnLine_User(handle,pAdcData,pPwmData,electricalAngle); -> this is the main FOC used when running the motor in normal operation (i.e. speed/position control)
    CTRL_runOnLine(handle,pAdcData,pPwmData); -> this is the FOC that gets ran during motor parameter identification
    CTRL_runOffLine(handle,halHandle,pAdcData,pPwmData); -> this is the FOC that gets ran when CTRL is running the offset calibration

    You only really need to worry about these functions if you intend to modify the FOC code.

  • Thank you for the great reply!

    Can you clarify a bit more on the following please.

    ====================================
    CTRL_setFlag_enableCtrl(ctrlHandle,false);
    Setting this function to false will disable the FOC blocks and place the CTRL object into Idle mode.

    You can call HAL_disablePwm(halHandle); and continue to run the FOC. But if you do this it is important that you update the position control reference with the current motor position otherwise when you call HAL_enablePwm(halHandle) there will be a huge jump in the motor control since it is now immediately trying to run back to a previous position.
    ====================================

    Hmmm.. am I right in the following:
    - the position feedback is still passed to STPOSCONV regardless of the state of FOC (it is read by STPOSCONV from the QEP)
    - the 'position control loop' is handled by STPOSCTL
    - and STPOSCTL outputs User_Iqref to the FOC
    - and the FOC is then basically just running open loop tracking User_Iqref
    - the 'Traj Ramp' and 'Speed PI' blocks are not used in the FOC block when we are using SpinTAC motion

    So if we set CTRL_setFlag_enableCtrl(ctrlHandle,false)
    - wouldn't STPOSMOVE & STPOSCTL go a little crazy as it would be seeing huge position errors?
    - And be ramping up User_Iqref to max

    I would think STPOSCTL would be the block that also has to be set idle or disabled.

    So when you say update the position control reference, I am unclear..
  • Another topic - if you could please correct my understanding of the CTRL and EST state machines..


    CTRL_State_Error
    - an internal error, restart / reset state machines to clear
    CTRL_State_Idle
    - motor not energized
    - the controller is disabled
    - triggered by CTRL_setFlag_enableCtrl(ctrlHandle, false);
    CTRL_State_OffLine
    - controller is initializing motor params, hardware offsets recalibration
    CTRL_State_OnLine
    - PWMs are active


    In CTRL_State_Idle, is the PWM output driven to zero, or should our main() code need to invoke HAL_disablePwm(halHandle)?





    EST_State_Error
    - an internal error, restart / reset state machines to clear
    EST_State_Idle
    - the estimator is not initialized, not active, not running
    EST_State_RoverL .. EST_State_MotorIdentified
    - estimator is identifying / initializing
    EST_State_OnLine
    - this state means estimator and motor are ready to move
    - this state is required in order to run the motor


    In EST_State_Idle
    "During the idle state, the estimator state machine does not execute any code. It is simply waiting for the controller state machine to change the state of the estimator."
    - is this handled automatically by CTRL_updateState() and CTRL_setFlag_enableCtrl() ?
    - or are there some functions in main() that I'm not seeing

    Does the state EST_State_OnLine have anything to do with RS Online?

    In spruhh1f it talks about the stator resistance re-calibrations being done in one of 2 ways;
    RS Offline, and RS Online
    Am I right that RS Online is only applicable in velocity mode (not when using POSMOVE)

    The function EST_setFlag_enableRsOnLine(obj->estHandle,TRUE/FALSE) would be used to enable / disable RS Online
    The function EST_setFlag_enableRsRecalc(obj->estHandle,TRUE/FALSE) would be used for RS Offline.
    Is that correct?

    So RS Online can be disabled, and the estimator will still be in state EST_State_OnLine during normal motor moves. Correct?


    Thanks again for the help.
  • Bernard,

    Bernard Pottner said:
    - the position feedback is still passed to STPOSCONV regardless of the state of FOC (it is read by STPOSCONV from the QEP)
    - the 'position control loop' is handled by STPOSCTL
    - and STPOSCTL outputs User_Iqref to the FOC
    - and the FOC is then basically just running open loop tracking User_Iqref
    - the 'Traj Ramp' and 'Speed PI' blocks are not used in the FOC block when we are using SpinTAC motion

    That is exactly correct.  

    Bernard Pottner said:
    So if we set CTRL_setFlag_enableCtrl(ctrlHandle,false)
    - wouldn't STPOSMOVE & STPOSCTL go a little crazy as it would be seeing huge position errors?
    - And be ramping up User_Iqref to max

    Yes, anytime that STPOSCTL is not controlling the system your position error will increase.  But this can be corrected by updating the position start for STPOSMOVE, so that the position reference being provided to STPOSCTL is always equal to the position feedback.  When the FOC is disabled you will want to execute the following code:

    STPOSMOVE_setPositionStart_mrev(stObj->posMoveHandle, STPOSCONV_getPosition_mrev(stObj->posConvHandle));

    This will update the position reference to be equal to the position feedback, which will keep STPOSMOVE & STPOSCTL in good states while freewheeling.

    Bernard Pottner said:
    In CTRL_State_Idle, is the PWM output driven to zero, or should our main() code need to invoke HAL_disablePwm(halHandle)?

    This is done in the background loop when CTRL is in state Idle

    Bernard Pottner said:
    In EST_State_Idle
    "During the idle state, the estimator state machine does not execute any code. It is simply waiting for the controller state machine to change the state of the estimator."
    - is this handled automatically by CTRL_updateState() and CTRL_setFlag_enableCtrl() ?
    - or are there some functions in main() that I'm not seeing

    The EST state is changes by the function CTRL_updateState which is called by the mainISR.

    Bernard Pottner said:
    Does the state EST_State_OnLine have anything to do with RS Online?

    The online rs estimation can only occur when EST is in state OnLine but aside from that it doesn't really have any connection.  OnLine indicates that the estimator is running and estimating the angle and speed.

    Bernard Pottner said:
    Am I right that RS Online is only applicable in velocity mode (not when using POSMOVE)

    I really don't know if the motor needs to be actively spinning in order for RsOnline to work.  One of the TI guys will need to weigh in on that.

    Bernard Pottner said:
    The function EST_setFlag_enableRsOnLine(obj->estHandle,TRUE/FALSE) would be used to enable / disable RS Online
    The function EST_setFlag_enableRsRecalc(obj->estHandle,TRUE/FALSE) would be used for RS Offline.
    Is that correct?

    That is correct.

    Bernard Pottner said:
    So RS Online can be disabled, and the estimator will still be in state EST_State_OnLine during normal motor moves. Correct?

    Exactly.  EST_State_OnLine is used to indicate that the estimator is able to estimate angle and speed.

  • "Am I right that RS Online is only applicable in velocity mode (not when using POSMOVE)"

    the motor has to be running, so velocity or torque mode
  • Great! - thank you for the detailed help Adam & Chris