Not following path correctly

Relatively new to Fanuc. But we have an identical Fanuc robot machine that we built four years ago. However, when we run the exact same robot programs that we did on the original machine (same backup - LR mate 200i), the robot tool does not follow the same path (and it would crash into the machine if we let it). We have re-calibrated the user frames and adjusted the end positions (very slight adjustments needed). It seems like the CNT100 (or even CNT20) is behaving way differently than it did on our previous robot. It is cutting the corners way more than it used to (close to 40 mm lower). If I move the intermediate point up by 50mm, it does not seem to affect the path at all. If we use step mode or use CNT0 (have to use CNT10 or lower to get a path that doesn't crash), it works okay, but we need the same or better cycle time that we had on the first robot and we don't want to have to change all of the programs (~50 programs). I believe the LR mate 200i firmware may have changed. We are looking for ideas on what we may need to do to get the same performance without changing all of our programs.

Here is an example of one of the programs. The main issue is when moving from line 37 to 40 (joint move to linear move). When we run from the pendant, it looks like the program is jumping ahead by 2-3 moves. Stepping works fine.

37:J PR[40:FlrBasePt] R[30:JntMoveSpd]% CNT100 Offset,PR[41:FlrAppr1Offs] ;

38: DO[10:InFlrStation]=ON ;

39: CALL M_PLCSYNC_OL(503) ;

40:L PR[40:FlrBasePt] R[31:LinMoveHiSpd]mm/sec CNT100 Offset,PR[42:FlrPreInsOffs] ;

41:L PR[40:FlrBasePt] R[32:LinMoveLoSpd]mm/sec CNT100 Offset,PR[47:FlrHalfInsOffs] AP_LDR[1] ;

42:L PR[40:FlrBasePt] R[20:LinFlrInsSpd2]mm/sec CNT0 Offset,PR[43:FlrInsOffs] ;

Quote from Shellmer

Have you checked correct robot calibration by jogging each axis at 0º?

If you have loaded SYSVARS.sv files, restore the original image of the robot, check calibration (or restore it by loading sysmast) and load all files again without loading sysvars and sysmast files.

I've seen very weird behavviours on robots when people load the sysvars file, even from the same controller, mechanical unit and firmware versions.

All of the position registers appear to be correct (robot is where it should be when at the PR), or at least within a couple mm of the PRs on the original robot controller. So, we assumed the robot position calibration was okay. So, the positions are good, but the path through the positions is not good.

I don't believe anyone loaded SYSVARS.sv, but I will confirm with our engineers.

Quote from Shellmer

First thing when comissioning a robot is to ensure it's calibrated correctly, if it's not calibrated, joint movements will usually work ok after a touchup, but linear ones will not work correctly.... even manual jogging on catersian mode will behave incorrectly.

You should ensure this:

- With every new controller is included a document that include the quality tests, the accuracy tests and the calibration values that are set from factory, you should ensure this calibration values are exactly the same on the robot variables as on that documents (if not, encoder batteries had probably run out, or someone just recalibrated the robot...)

- After checking this, you should jog all robot axis to 0º, you can do it manually or write a little program to do a J move with all joints at 0º. There are marks or stickers that should match on every axis, that indicates their zero position is correct.

If robot is old, some controllers make the robot path to round corners very agressivelly, newer robots do not do that anymore, as you state it's moving incorrectly and it's relativelly new I assume it's a new robot with at least an R30iA/iB controller, if it uses an RJ3 controller it will trim the path a lot on certain mechanical units.

If you restore a full backup, all files are restored, including the sysvars and sysmast, you should never restore a backup from one controller into another one, if you need to transfer the program, you must load all files except sysvars.sv and sysmast manually or later you will have big issues.

Fanuc has told us that sysvars should never be loaded into another controller unless we can ensure there is the exact mechanical unit, the same exact controller and the same exact firmware version, and even so, it overwrites the serial number of the controller and you should restore it.

Experience has teached me that even if all this points are true, it can cause problems, the latest 2 robots someone has loaded the damn file were experiencing collisions mid-air as the collision detect parammeters were not correct, fix was loading their original image and restoring all files except this one, as on the moment I loaded the sysvars file back, this issue appeared again.

Display More

We verified the $MASTER_COUN variable matches the Factory Inspection Sheet. We also ensured the witness marks are aligned for all axis for when at the zero position.

We actually have two different robots on this machine and they are both exhibiting the same behavior (i.e. not following the same spline path as the previous robots).

It sounds like you are saying that the Fanuc controller may have changed in the way it rounds corners? That would be bad. If that is really the case, then I guess we'll have to start modifying programs and hope the drastically reduced CNTxx doesn't actually slow the moves down like it seems that it will.

Additional info:

Current robots have an R-30ib controller version 9.30P/16 (we had to downgrade from 9.40 post delivery due to incompatibilities with the optional Profinet hardware).

Original robots have an R-30ib controller version 9.10p/16

Quote from FanucUser14

Can you ensure your configured payloads are the same? Menu, 0, System, Motion. This could change your tool path.

You are correct. Our active payload was set to 0 for some reason (both robots). We set it to 1 (which had the correct payload value) and it appears to have fixed the path issue as it is now clearing the obstacles as before. Thank you for your help.