Announcement

Collapse
No announcement yet.

Integrated Stepper Motor with encoder - Problem maintaining target position

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts


  • Integrated Stepper Motor with encoder - Problem maintaining target position

    Hello,

    I am using a do-more BRX (BX-DM1E-18ED13) PLC to drive an integrated stepper motor (STP-MTRD-17038E) with encoder output. I am using a signal conditioner module (FC-ISO-C) to make sure that the encoder outputs are compatible with the High-speed inputs of the PLC.

    So far everything works well in "single-move" mode. But there are problems when I try to implement "Multi-Move" mode. The axis is configured as a rotary axis with encoder feedback. The scale factor is set up correctly. See attached picture for axis configuration. The stepper motor is configured to have 25000 steps/rev. The rotary range becomes 0 to 24999 pulses or steps.

    I have followed the "Multi-Move" example in the help documentation. It appears that the stepper motor has trouble reaching the target position. The current position value of the axis always runs beyond the target position and goes into a never-ending circular loop. This causes the motor to always run in a loop continuously.

    I can't seem to figure out what is causing the $Axis1.CurrentPosition to always rollover TargetPosition and end up in continuous rotational loop. I have attached the pictures of the ladder code showing Multi-Move is set up.

    Any suggestions/thoughts on why this is occuring?

    I have tried to increase "deadband" in axis configuration from 1 (default value) upto 50. The problem still exits.
    Attached Files
    Last edited by RockB; 02-04-2019, 11:18 AM.


  • #2
    The Ladder_Code images are broken. I don't know the answer, but maybe trying Relative Rotary Target and calculate the needed relative move from an absolute you keep track of. I'm just wondering if the Absolute Clockwise prevents the reversal?

    Another possibility is if you are changing the target position and triggering an update before the move is actually completed it may be heading to the next point. I don't think you are saying this though.

    (The Target Position image in the AXPOSTRAP instruction is somewhat confusing to me.)

    Comment



    • #3
      I feel like we've fixed something here. Maybe a bug with rotary axis, encoder feedback, using the encoder for position, with scale factors other than one. That sounds super familiar to me. I'll check Monday when I'm back in the office.

      If that is true, then I have have good news/bad news. The good news is that it is already fixed, but the bad news is that it isn't released. It should be soon, but if soon isn't soon enough, we can look for other solutions.

      Comment



      • #4
        Originally posted by Mike Nash View Post
        The Ladder_Code images are broken.
        (The Target Position image in the AXPOSTRAP instruction is somewhat confusing to me.)
        Mike Nash I have re-uploaded the images of the ladder code. Take a look.

        I don't think the target position is changing before the motor reaches its current target position.

        The Multi-Move AXPOSTRAP instructions only support Absolute position referencing. The target position is stored in EX0 register. After the flag (in my case C202) is updated, the motor moves to new position read from EX0. What is confusing in the AXPOSTRAP?

        Comment



        • #5
          Originally posted by BobO View Post
          I feel like we've fixed something here. Maybe a bug with rotary axis, encoder feedback, using the encoder for position, with scale factors other than one. That sounds super familiar to me. I'll check Monday when I'm back in the office.

          If that is true, then I have have good news/bad news. The good news is that it is already fixed, but the bad news is that it isn't released. It should be soon, but if soon isn't soon enough, we can look for other solutions.
          Bob O I have re-uploaded images of my ladder code. Please take a look at it to make sure its not a simple mistake in ladder code or if it is actually the bug you are talking about.

          Is this bug only with rotary axis? I can change to a linear axis and still achieve the same functionality for my project. I have observed that the encoder feedback has trouble keeping up with the target position. It tries to close up the difference, rolls past the target value and tries to run back to the target value. This seems to be happening in a continuous loop.

          If this is infact a bug, When is the update going to be released? What other solutions are we talking about?

          Comment



          • #6
            Originally posted by RockB View Post

            Bob O I have re-uploaded images of my ladder code. Please take a look at it to make sure its not a simple mistake in ladder code or if it is actually the bug you are talking about.

            Is this bug only with rotary axis? I can change to a linear axis and still achieve the same functionality for my project. I have observed that the encoder feedback has trouble keeping up with the target position. It tries to close up the difference, rolls past the target value and tries to run back to the target value. This seems to be happening in a continuous loop.

            If this is infact a bug, When is the update going to be released? What other solutions are we talking about?
            If it is the one I'm thinking, I'm pretty sure it was related to rotary mode with encoder feedback and ratios greater than 1. I won't swear that it isn't bugged in linear, but I thought it was specific to rotary. And yes, the case I'm referring to was a bug.

            We are close to a new release that has the fix (weeks), but we could always look at getting you a beta.

            Comment



            • #7
              Mike Nash Bob O I have shared a small screen capture videos of Do-More designer showing how the encoder count is not able to keep up with target position.

              When Axis is configured as Rotary: [Click Here]

              When Axis is configured as Linear: [Click Here]

              ​​​​​​​In case of Linear axis, the motor comes to stop but still has trouble reaching target position.

              Comment



              • #8
                One thing I think I am seeing is the resolution of the encoder is not going to allow you to hit your 8091 target, hence it bounces back and forth between values it CAN hit (8075 and 8100) in linear. Also, your "not equal" in rung 3 will never be false for this reason.

                For the rotary, I'll let BobO get back to you on that, I'm just a(n) (ab)user.

                Since you are trying to resolve only to an encoder value, can you set the stepper to 1000 steps per rev to see if that does help your situation?

                And you can do relative on the rotary multi-step, you just have to select Target Type as Relative and this changes your Linear vs Rotary choices.

                Comment



                • #9
                  Originally posted by RockB View Post
                  ​​​​​​​In case of Linear axis, the motor comes to stop but still has trouble reaching target position.
                  It may be within the deadband, but still not at the target. That's normal.

                  Comment



                  • #10
                    Originally posted by Mike Nash View Post
                    One thing I think I am seeing is the resolution of the encoder is not going to allow you to hit your 8091 target, hence it bounces back and forth between values it CAN hit (8075 and 8100) in linear. Also, your "not equal" in rung 3 will never be false for this reason.

                    For the rotary, I'll let BobO get back to you on that, I'm just a(n) (ab)user.

                    Since you are trying to resolve only to an encoder value, can you set the stepper to 1000 steps per rev to see if that does help your situation?

                    And you can do relative on the rotary multi-step, you just have to select Target Type as Relative and this changes your Linear vs Rotary choices.

                    Mike Nash I tried setting the steps per revolution of the motor to 1000, which is same as the encoder (1000 PPR). The scale factor in the AXCONFIG was changed from 25 to 1. I am observing a very weird thing. Since the ratio is 1:1, my guess is that encoder should match any target position. However, I am observing the continuous rollover behavior like the rotary axis setup. See video [here]

                    Not sure what is causing this. There is NO option to do "relative" Multi-step. Do More designer allows only "Absolute" multi-step.

                    Maybe I can try increasing the deadband to a higher value and see if this stops.
                    Attached Files

                    Comment



                    • #11
                      Originally posted by BobO View Post

                      It may be within the deadband, but still not at the target. That's normal.
                      I am using the $Axis.AtPosition flag to perform successive moves. In the linear axis configuration, the AtPosition Flag sometimes comes ON but it never stays ON, looks like it is unstable.

                      Comment



                      • #12
                        Originally posted by RockB View Post

                        Not sure what is causing this. There is NO option to do "relative" Multi-step. Do More designer allows only "Absolute" multi-step.
                        Ah, I didn't tell it to accept when I tried it. It doesn't gripe until then.

                        What about your encoder input setup...is it set to rotary also?

                        I haven't actually used the BRX on a stepper, only servos with step/direction or quadrature input. I did have the encoders coming back into the BRX also, but I wasn't using the encoder feedback mode for control, and I was using linear. Then again, servos.

                        Even on a rotary application I have just used linear and let the +/- 2,147,483,648 counts be my friend - I was going to reset the cycle before I got anywhere near that high a value.

                        Comment



                        • #13
                          Originally posted by RockB View Post

                          I am using the $Axis.AtPosition flag to perform successive moves. In the linear axis configuration, the AtPosition Flag sometimes comes ON but it never stays ON, looks like it is unstable.
                          Possibly mechanical lash resulting in the .AtPosition turning back on?

                          I personally wouldn't use the multi-move. It was mostly added to answer the dynamic move modes in CTRIO/2. There really isn't as strong of a reason to do so in BRX. Once we release the AXSCRIPT instruction here very soon, there will be even less reason.

                          Comment



                          • #14
                            Originally posted by Mike Nash View Post
                            One thing I think I am seeing is the resolution of the encoder is not going to allow you to hit your 8091 target, hence it bounces back and forth between values it CAN hit (8075 and 8100) in linear. Also, your "not equal" in rung 3 will never be false for this reason.
                            Was thinking about your comment. I can think of two ways to solve this problem: 1. Set deadband value to be 25. This makes sure there is extra margin of 25 counts above and below target value (8091) in our case. This should theoretically stop the motor as soon as encoder counts upto 8075 (closest multiple of 25). I am not sure if 25 is a large value for deadband and what implications it will have when small errors add up with multi move
                            2. To reduce deadband value, I can reduce motor resolution from 25000 ppr to 10000 ppr. This should still give me a smooth rotation. But since the scale factor is 10 instead of 25, I can set deadband value equal to scale factor.

                            Do you think setting deadband value equal to scale factor might help reduce oscillations or continuous looping of motor?

                            Comment



                            • #15
                              Originally posted by BobO View Post

                              Possibly mechanical lash resulting in the .AtPosition turning back on?

                              I personally wouldn't use the multi-move. It was mostly added to answer the dynamic move modes in CTRIO/2. There really isn't as strong of a reason to do so in BRX. Once we release the AXSCRIPT instruction here very soon, there will be even less reason.
                              I did a simple experiment to test this out. I set the motor resolution to 25000 ppr and changed multi move to a simple relative single move. It looks like motor has problem staying stable at a target position of 2000 counts. It oscillates slowly around target value. However, when to motor is connected to a small load, it reaches target position and comes to complete stop. Do you think this is common behaviour in steppers with encoders or a cade of mechanical lash?

                              Do you have any alternative methods to implement multi move? Your next release sounds very promising. I would be happy to test out your beta release.

                              Comment

                              Working...
                              X