Announcement

Collapse
No announcement yet.

BRX HSIO use

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


  • BRX HSIO use

    I'm using BRX PLC's high speed I/O in step-and-direction mode to control an "integrated servo motor" from Teknic. I've got everything running quite well (scaling, running to position, homing, etc...) except for one thing.

    I'm using the AXPOSSCRV instruction to run to position, and it's working correctly. I'm holding the E/R input ON with a latch that's canceled with the Axis.AtPosition goes true. My issue is when the operator triggers an E-stop. The E-stop drops power to the motor and brake, and the physical axis stops fast and correctly. The E-stop is also monitored by the PLC, and cancels the latch when it's triggered.

    Problem is, the AXPOSSCRV instruction "decelerates" at its normal predefined rate, even though the physical axis (motor) is no longer moving. This is leading to position errors every time the system is E-stopped.

    I've also tried RST'ing the Axis.MasterEnable bit on E-stop and and SET'ing it once the E-stop is reset. I'm also preforming a AXRSTFAULT when the E-stop is reset.

    This works... sort of. The axis stops immediately when Axis.MasterEnable is RST, so I'm not loosing position, but I can't successfully continue moving in the direction the axis was commanded to move it without moving in the opposite direction first. Attempting it faults the axis. This is apparently a feature, according to the Help file.

    This is a problem. I have (20) of these machines - so (20) axes of motion - that are all triggered to move together; some may be moving one way, some the other, depending on where they started and where they've been commanded to move to. If an E-stop is triggered, I can't very well tell the operator they have to go and manually figure out which direction each axis was moving, and then jog it the other way to recover.

    The AXPOSSCRV instruction really, really, really needs a STOP input that will stop the current move when ON, at the Fault Deceleration value set in AXCONFIG (or preferably a STOP deceleration value within the AXPOSSCRV instruction). This needs to simply stop the current move, not cause any faults or errors, and allow the AXPOSSCRV to be retriggered to continue the move once STOP is turned off.

    If there's another way to do this, I'm all ears. This is potentially a huge issue for these (20) machines I have sitting on the bench right now at the shop.



    Thanks,

    Ryan Poethke


  • #2
    There is no requirement to reverse the axis following a master enable fault, at least not intentionally. The only time a reversal is necessary is following a limit fault, where backing up is part of clearing the fault. If it is requiring a reversal, something is broken. You should just need to reset the fault and start running again. Iíll check it tomorrow.

    Comment



    • #3
      Originally posted by BobO View Post
      There is no requirement to reverse the axis following a master enable fault, at least not intentionally. The only time a reversal is necessary is following a limit fault, where backing up is part of clearing the fault. If it is requiring a reversal, something is broken. You should just need to reset the fault and start running again. Iíll check it tomorrow.
      I'll do some more testing this morning, and report back. It seems like the PLC is also occasionally getting "stuck" after disabling and re-enabling the Axis.MasterEnable bit, and I have to toggle the PLC into Program mode and back to Run mode to get the axis to move again. This may be something I've borked on my end, and I'll look into it more.


      Thanks,

      Ryan Poethke

      Comment



      • #4
        Originally posted by Ryan_Poethke View Post

        I'll do some more testing this morning, and report back. It seems like the PLC is also occasionally getting "stuck" after disabling and re-enabling the Axis.MasterEnable bit, and I have to toggle the PLC into Program mode and back to Run mode to get the axis to move again. This may be something I've borked on my end, and I'll look into it more.


        Thanks,

        Ryan Poethke
        Dropping the master enable while running is a fault, so the fault has to be reset before it will run again, but it sounded like you are doing that. There is an answer and we'll get you going.
        Last edited by BobO; 05-31-2019, 09:11 AM.

        Comment



        • #5
          Backlash having to be wound back up perhaps?
          If you have an urgent issue, please contact AutomationDirect's Technical Support team.

          AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

          Comment



          • #6
            I started a AXPOSSCRV, dropped .MasterEnable, cleared the fault with AXRSTFAULT, and retriggered the AXPOSSCRV. It continued to the target as expected.

            Comment



            • #7
              After investigating the AXRSTFAULT help, it's pretty obvious why you got confused...it's half wrong. The verbiage there is true for overtravel limit faults, and the description line of the instruction indicates that the instruction is for resetting limit faults, which is also true...but its not there just for limit faults, and those direction considerations don't apply to the other fault types. We're fixing that now.

              Comment



              • #8
                Originally posted by Do-more PE View Post
                Backlash having to be wound back up perhaps?
                It's not backlash. I can see the count decelerate to a stop if I turn off the E/R input on the AXPOSSCRV instruction. It has something to do with how I'm trying to recover from an E-stop. If I RST the .MasterEnable bit, it stops immediately with no decel (and faults the axis), but I'm having trouble recovering when I try to SET .MasterEnable and perform an AXRSTFAULT. I'll report back this afternoon, after some more testing.


                Thanks,

                Ryan Poethke

                Comment



                • #9
                  Originally posted by BobO View Post
                  I started a AXPOSSCRV, dropped .MasterEnable, cleared the fault with AXRSTFAULT, and retriggered the AXPOSSCRV. It continued to the target as expected.
                  Should I be SET-ing .MasterEnable on recovery, or will AXPOSSCRV take care of that on its own?


                  Ryan Poethke

                  Comment



                  • #10
                    Turns out I borked it, and I was not canceling the latch that triggers the AXPOSSCRV instruction like I thought I was when the E-stop was struck. The GO never turned off, in order to turn back on and re-trigger the instruction after E-stop recovery. The "having to run in the other direction" thing led me astray slightly. And I answered my own question: I don't have to SET .MasterEnable on E-stop recovery to make the next move; I just have to perform the AXRSTFAULT.

                    It's working perfectly now. Thanks again for all the help BobO! You guys have a really nice product.


                    Sincerely,

                    Ryan Poethke

                    Comment



                    • #11
                      Originally posted by Ryan_Poethke View Post
                      Turns out I borked it, and I was not canceling the latch that triggers the AXPOSSCRV instruction like I thought I was when the E-stop was struck. The GO never turned off, in order to turn back on and re-trigger the instruction after E-stop recovery. The "having to run in the other direction" thing led me astray slightly. And I answered my own question: I don't have to SET .MasterEnable on E-stop recovery to make the next move; I just have to perform the AXRSTFAULT.

                      It's working perfectly now. Thanks again for all the help BobO! You guys have a really nice product.


                      Sincerely,

                      Ryan Poethke
                      Very sorry about the unclear documentation. I'm pretty sure that was one of those things that evolved a bit during development and some of the original stuff didn't get touched as things changed. I know we expanded the possible fault types a couple of times. Too little, too late...but it will be fixed in the next release.

                      Comment



                      • #12
                        Originally posted by BobO View Post

                        Very sorry about the unclear documentation. I'm pretty sure that was one of those things that evolved a bit during development and some of the original stuff didn't get touched as things changed. I know we expanded the possible fault types a couple of times. Too little, too late...but it will be fixed in the next release.
                        No worries on the documentation; it's often the hardest part of a project. Now that I have the programs running for all 28 of the BRX PLC's in this project, I too have to fall down the rabbit hole of writing a user manual. Those pesky end users... always wanting to know how things work and how to use them


                        Thanks,

                        Ryan Poethke

                        Comment

                        Working...
                        X