Removing Unused Motion Groups Compromises Path Accuracy?

Hey there,

I work as an integrator at an OEM automotive manufacturing facility. This OEM has developed a programming guideline that is continuously updated until the next version of the programming guideline is released. At the beginning of each new project, the lead robot technician of the facility provides an updated facility-specific document for the current version of the programming guideline. This facility-specific document takes precedence over the OEM programming guideline. In the facility-specific document for the project I am working on at this facility, it says:

Quote

By default, when a program is created, the default group setting is all 5 groups are active. No programs should have all 5 groups active. The program structure must be set individually for each program based on the necessary motion groups needed. If a technology is not configured to use motion groups 2, 3, 4, or 5, it must be masked.

For example:

• A robot that only performs handling operations would have DEFAULT_GROUP equal-to 1,*,*,*,*;
• A robot that only performs welding operations with a robot-mounted servo gun would have a DEFAULT_GROUP equal-to 1,1,*,*,*;
• A robot that performs handling and welding operations with a robot-mounted servo gun would...
  • Have a DEFAULT_GROUP equal-to 1,*,*,*,*; during programs with only handling operations
  • Have a DEFAULT_GROUP equal-to 1,1,*,*,*; during programs with only clinching/welding operations
  • Have a DEFAULT_GROUP equal-to 1,1,*,*,*; during programs with handling and clinching/welding operations
  • The "main" program would have a DEFAULT_GROUP equal-to 1,1,*,*,*; while sub-programs would only contain groups necessary for the application(s) performed in each sub-program
    • NOTE: Sub-programs cannot call other sub-programs!

Now, the offline programs delivered by the design company include all 5 groups active in all "main" programs and sub-programs. Unfortunately, we are unable to reject the OLP as-is and wait for new offline programs that comply with the facility-specific document. Instead, my colleagues and I must remove the unnecessary groups ourselves.

My colleagues and I have written macros/scripts (offline) and used the Group Mask Exchange built into the Teach Pendant (onsite) to remove the unnecessary groups from backups without any issues.

Using backups from Monday, 2024-05-13, my colleagues and I removed the unnecessary groups offline and loaded the new programs/sub-programs on Saturday, 2024-05-18. Then, we began testing the new programs/sub-programs in manual-mode. While checking a docking sub-program of a particular robot (docking, handling, gluing with a stationary gun), a colleague noticed the gripper was going to crash with a nearby station.

Next we:

1. Verified the station had not been modified or relocated since the backup used was taken on Monday, 2024-05-13
2. Verified the docking stand had not been modified or related since the backup used was taken on Monday, 2024-05-13
3. Verified the gripper had not been modified since the backup used was taken on Monday, 2024-05-13
4. Verified the robot's mastering data
5. Took a backup of the robot with the new programs and compared it to the backup from Monday, 2024-05-13:
   1. Verified the DEFAULT_GROUP of the docking sub-program was 1,1,1,1,1; before being changed to 1,*,*,*,*;
   2. Verified the /POS data included GP1, GP2, GP3, GP4, and GP5 before being changed to only include GP1
   3. Verified the /POS data of GP1 was the same in the new docking sub-program
   4. Verified there was no change to the point parameters (ACC, CNT, TB)
   5. Verified there was no change to the PAYLOAD data
   6. Verified there was no change to the UFRAME data
   7. Verified there was no change to the UTOOL data

Unable to determine the cause of the deviation in the path, we loaded the docking sub-program from the backup from Monday, 2024-05-13 and the robot did not crash with the nearby station.

Next, we wondered if the macro/script used to remove the unnecessary groups offline might have altered the docking sub-program in some way that could explain the path deviation. So, we used the Group Mask Exchange built into the Teach Pendant (MENU → UTILITIES → F1 [ TYPE ] → Group Exchg → ENTER) to remove the unnecessary groups and began to check the docking sub-program in manual-mode, but the gripper was still going to crash with the same nearby station as before.

Out of concern this issue could present itself in robots elsewhere on the line and due to the limited amount of time we had to complete our weekend work, we resorted to rolling back all the robots to the backup from Monday, 2024-05-13.

Why would this happen? How is this possible?

Quote from Erik Olsen

Providing the TP programs (if allowed) or even snippets of the logic and /POS data would be helpful. Additionally, a list of software options installed on the robot that could potentially cause some strange behavior (Coord Motion Package, Multi-Group Motion, Interference Check, etc) might give some clues. Lastly, are you running any custom Karel scripts on the robots?

Hey there,

I am willing to share what information I can. Below you will find two files: prog081wogp.ls is the previously mentioned docking sub-program without Motion Groups 2-5 and prog081wgp.ls is the same docking sub-program with Motion Groups 2-5. Also, I have removed much of the logic contained within the P-SPS with "pseudocode". NOTE: All MAKRO programs have a DEFAULT_GROUP of *,*,*,*,*. Also, I have attached some relevant information from the summary.dg file for which software options are installed.

Thank you for your help!