• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 731 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.

DRV8353RS-EVM: DRV8353RS-EVM

Premkumar T
Intellectual 445 points
Part Number: DRV8353RS-EVM

Hello team,

I am working with the Universal motor code for the controller (F2800157) with proper hardware setup. I am able to run the motor and modify other parameters through debug in Fast mode and also with HALL feedback.
Now I have enabled the macro CMD_POT_EN in Predefined symbols to run the motor with Throttle input(Connected to a Potentiometer). I am able to see the changes through expression window for POT( potadc ), but motor is not running and also motorVars_M1.flagEnableRunAndIdentify and motorVars_M1.speedRef_Hz is not getting enabled.
Could you please help me out to Run the Motor with Throttle input in Universal motor code.

 

Thanks,
Premkumar.T

  • 0
    TI__Genius 12231 points

    Hi Premkumar, 

    Thanks for your question. 

    Please allow some time for our team to look into this matter and follow-up with further questions/suggestions next week at latest.  Please look forward to response. 

    Best Regards,

    -Joshua

  • 0 in reply to Joshua Maize
    Intellectual 445 points

    Hi Joshua,

    Sure, Thank you for your updated.

    Best Regards,

    Premkumar.T

  • +1 in reply to Premkumar T
    TI__Genius 11076 points

    Premkumar,

    By default, motorVars_M1.flagEnableRunAndIdentify is manually controlled via the CCS debug menu and is not automatically enabled- if you wish to enable that kind of functionality, it would require custom implementation.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Hi Jason,

    Now I'm running the motor using throttle, for that I have enabled CMD_POT_EN from predefined symbols. I'm able to run the motor using throttle, but facing initial delay in throttle response. I've tried decreasing USER_M1_WAIT_TIME_SET in setExtCmdPotParams() function and also I have removed the wait timer based condition in updateExtCmdPotFreq() function. I've attached Screenshot for your reference. So now the flagEnableRunAndIdentify is responding immediately. 

    But, still we are facing delay. Initially the motor (using 48V PMSM motor with Hall feedback) rotates 1-2 times opposite direction and then it rotates in forward direction.  So can you please suggest some steps to avoid the initial delay when throttle is applied and what parameters should be taken care of to make the motor run in proper direction initially without any reverse rotations.

  • 0 in reply to Premkumar T
    TI__Genius 11076 points

    Hello,

    Can you show me what the state of the motor and the HALL object during the backwards rotation? I'm uncertain what may be causing this without further information.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Hello Jason,

    While rotating backwards the motorState is MOTOR_ALIGNMENT. I'm attaching screenshot for your reference. Also, I'm trying to vary startupTimeDelay and alignTimeDelay to reduce the TPS response time in motor1_drive.c. Can you please suggest if there's any other method to reduce the TPS response time.

    Regards,

    Premkumar. T

  • 0 in reply to Premkumar T
    TI__Genius 11076 points

    Hello,

    Because you're entirely disabling the motor every time using flagEnableRunAndIdentify, I think you will need to disable alignment.

    • flagEnableAlignment needs to be set to 'false'
    • flagEnableFlyingStart may need to be set to 'false' if the flying start functionality is not desired.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Hi Jason,

    Thanks for your support, after setting flagEnableAlignment as 'false', I'm able to observe no backward rotations and TPS response time is also reduce to some extent. However, by setting flagEnableFlyingStart as 'false', the flagRunIdentAndOnLine is taking time to set as one when flagEnableRunAndIdentify is set as one, which is causing delay in motor run. I'm checking further to reduce the TPS response time.

    Regards,

    Premkumar T.

  • 0 in reply to Premkumar T
    Intellectual 445 points

    Hi Jason,

     Thankyou for your support,

    As we discussed earlier, still there is some delay in throttle response. I'm able to observe some delay initially when we are giving throttle input. I tried increasing accelerationStart_hzps as it may affect the throttle response, but still the issue is not sorted. Can you please suggest which parameters we need to consider for quick throttle response?

     

    Regards,

    Premkumar T.

  • 0 in reply to Premkumar T
    TI__Genius 11076 points

    Premkumar,

    Please post a screenshot containing the value of all of the following variables in the expressions window:

    • alignTimeDelay
    • forceRunTimeDelay
    • startupTimeDelay
    • flyingStartTimeDelay
    • fwcTimeDelay

    All listed variables are part of the motorVars_M1 struct.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Jason,

    I'm attaching the screenshot containing the values of all the variables listed by you for your reference.

    Regards,

    Premkumar T.

  • 0 in reply to Premkumar T
    TI__Genius 11076 points

    Premkumar,

    As a debug step, set all of these values except for startupTimeDelay to 0. These control the startup state transitions.

    Additionally, set:

    • motorVars_M1.speedFlyingStart_Hz to a very low value, between 1 and 5.
    • motorVars_M1.stopWaitTimeSet to 0
    • motorVars_M1.startupTimeDelay to 2
      • Alternatively, set this value to 0. If you set this value to 0, altering the runMotor1Control() function would be required. Altering the following line:

        if(obj->stateRunTimeCnt == obj->startupTimeDelay)

        to

        if(obj->stateRunTimeCnt >= obj->startupTimeDelay)
      • This should alter the state machine and allow you to reach the closed loop running state. Ensure testing is done on your end to confirm functionality.

    Note: These debug steps are all solely to minimize the startup time of your system. I highly recommend ensuring on your end that all behavior related to safety or essential system functionality continues to work consistently after these changes.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Hi Jason,

    Thanks for your reply. As per your suggestion I've made changes in the code, there is slight reduction in delay, say 0.5 sec, but not much.

    I could observe delay when the motor state is 'MOTOR_CL_RUNNING'. When the state changes to 'MOTOR_CTRL_RUN' the response is quick. Also, if I'm increasing the accelerationStart_Hzps and accelerationMax_Hzps, it has no effect in 'MOTOR_CL_RUNNING' state, only when the state is changed to 'MOTOR_CTRL_RUN' the motor is running with the set accelerationMax_Hzps value. Can you please suggest how this delay can be reduced? 

    Regards,

    Premkumar T.

  • +1 in reply to Premkumar T
    TI__Genius 11076 points

    Premkumar,

    Ah, that's unfortunate. The reason that the change for startupTimeDelay is more complicated than the others is because I was trying to avoid that exact issue with the motor state.

    Try this- it should work:

    • Find the following lines in the ISR:
    • Change it to this:

    This forces motorState to progress from MOTOR_CL_RUNNING (closed-loop running startup state) to MOTOR_CTRL_RUN (final runtime state). Prior note about testing still applies.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 445 points

    Hi Jason,

    Thanks a lot for your response. After doing the changes suggested by you, there is significant reduction in throttle response time.

    Regards,

    Premkumar T.