Questions About the Path Recorder

  • RW6.12, IRC5

    My company is rewriting our standard Rapid templates for ABB robots, and one of the biggest things I want to improve is recovery and auto-homing. Right now, we use MoveJSync/MoveLSync to count steps as the robot moves through each position. The step number and current program are stored in persistent variables because with IFWC homing always requires a start @ main command and we need some way to remember where the robot was. This is a huge pain because if a corner path failure occurs, the sync instructions can be missed. The old template even used MoveXSync with fine points, which was another issue. If the step is not correct, the robot will not recover correctly.

    I would like to use the path recorder to make recovery easy. I've already set up some tests with it and have had success, but I have some questions I haven't been able to find answers to or test:

    1.) Since recovery means the program pointer gets reset, does this also destroy any recorded paths? If so, this whole idea is mute unless I can do something in the UNDO handler.

    2.) Can PathRecMoveBwd be used even if the robot deviates from the programmed path, say for example with a SearchL \Stop instruction? I think that as long as a PathRecStop \Clear hasn't been executed then it should work and the recorded path will be a little different than the programmed path, but the wording in the documentation is causing some doubts.

    3.) Can multiple PathRecMoveBwd's be executed in a row? The idea is that if the robot does deviate from the programmed path, I would first like to move backwards to the closest point along the path, then move backwards all the way back. I have multiple path recorder ID's set up, and IFWC comes with a handy little CheckLocation function, so the process would be to check which location I am closest to, see if a valid backwards path exists to that ID, execute a PathRecMoveBwd to that ID, see if a valid backwards path exists to the first ID, then execute another PathRecMoveBwd to that ID at the start of the path. Nothing in the manual says that this isn't possible, but there also aren't any examples where they do this.

    Here's an example of what I'm trying to do:

  • Place your Ad here!
  • Sorry, but I have bad news for you. I experimented years ago when IFWC was newer. I had the same endeavor, pretty much, as you do. So, the bad news is that the PPtoMain erases completely the recorded paths. It would work great if they had instead chose to use an input to initiate recovery, but Nooo, they use PPtoMain system input. You would think that, of all the programmers out there, that ABB would be doing things the best. I threw out that opinion years ago. Tell me please, if you would do a simple test for me, can you still block the output for IOBlockedinAuto? That would help to demonstrate my point.

  • That was my biggest fear. The more I work with IFWC, the more I begrudgingly understand what its purpose is though. Ford didn't want every single integrator to have their own recovery strategy, PLC handshakes, etc.. I was really hoping the path recorder would be a foolproof way to recover, but I'll keep brainstorming.

    Unfortunately I don't have access to an RC right now, I created a quick and dirty VC but I don't see anything about IOBlockedinAuto.

  • The program standard used MoveLSync well before I was hired, I couldn't tell you why they were being used over TriggL. Really MoveLSync is just a condensed version of using TriggInt and TriggL though so ultimately using MoveLSync accomplishes the same thing, which is pretty much just incrementing a persistent variable.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners