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.

Large position setpoint changes

Other Parts Discussed in Thread: MOTORWARE

Hi,

I'm noticing that when using ST_runPosCtl and updating the position setpoint by a large amount, which may exceed ST_POS_ERROR_MAXIMUM_MREV the controller goes into a state in which the motor rotor begins rotating continuously, rather than disabling the output. Is there a chance that updating the position setpoint by a value which exceeds ST_POS_ERROR_MAXIMUM_MREV could cause the system to fail with the rotor spinning?

Thanks,

Steve

  • Steve,

    When you set the new position setpoint are you bypassing the position profile generator?

  • Hi Adam,

    That's right, I'm calling STPOSCTL_setPositionReference_mrev() directly.

    -Steve

  • Steve,

    If the position error exceeds the position error maximum this is not a latching fault.  So if the position error ever reduces below the error max the controller will turn back on.  It is possible that something like this is happening in your system.  When you are manually setting the position setpoint are you accounting for the position rollover from +10 to -10?

  • Hi,

    I'm not explicitly handling the rollover, I will add that now. I'm looking at: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/902/7356.SpinTAC_5F00_Position_5F00_Move_5F00_Rollover.pdf

    Is "position" in this document referring to "STPOSCTL_setPositionReference_mrev" ? I think I'm unclear on how this is handled. If the current value in "STPOSCTL_setPositionReference_mrev" is 9.5, and then it is updated to -10, will the motor move 0.5 mrevs or -19.5 mrevs?

    Thanks,

    Steve

  • Steve,

    In that document position is referring to STPOSCTL_setPositionReference_mrev. I think it will move 0.5 mrevs. I am away from the office right now and on mobile so I cannot double check to confirm. I'm also out the rest of this week I'll try to get you a firm answer sometime next week. But this should be pretty easy for you to experiment and try with your motor uncoupled from your system.  

  • Adam,

    Is there a definitive answer to this issue?  I can't test every case, is this behavior specified somewhere?


    Thanks,
    Steve

  • Sorry about the long delay Steve.  I was away on a two week business trip followed by a week of vacation.  I've just now been able to make it back into the office.

    I tested the case you specified as well as the reverse case, setting -9.5 followed by 10.  Our algorithm will always choose the closest point.  So it will rotate forward 0.5 rotations.  The reason we choose the closest point is because there is a maximum allowable position error.  If the position error is larger than 2 revolutions (this is the default in the MotorWare projects but the value can be modified), the SpinTAC Position Control will produce a 2002 error.  

    Hope this helps answer the question.

  • That makes sense.

    Is there a mechanism for keeping track of how many times the position has wrapped and in which direction?

    I have a higher level system interfacing with instaspin which is commanding positions according to encoder counts. This system is expecting to receive back the current position in encoder counts since power on. Converting from encoder counts to the appropriate mrev number that instaspin requires is straightforward. Going the other direction seems more difficult. Do I need to keep track of the rollovers myself in order to convert back to encoder values? Or is this done somewhere within the instaspin system?

    Thanks,

    Steve

  • Just to be sure I understand, commanding -9.5 and then 9.5 should cause a 1mrev motion, correct?

  • Steve,

    In SpinTAC Position Convert there is a rollover counter.  This increments each time the position feedback rolls over from positive to negative and decrements each time the position feedback rolls over from negative to positive.  This way you know how many times the position has rolled over and will keep track of the relative position since power on.  

    Combining the roll over counts with the current position should be straightforward to convert into encoder counts since power on.

  • Yes, if you are starting at -9.5, then command 9.5 it will cause a 1 mechanical revolution rotation in the positive direction.

  • Outstanding. Thank you.

    -Steve