All PRs changed in the controller

    Hello members of the robot forum. Long time reader, first time poster.


    Long story short, so please bear with me. I am an integrator working on Arc Mate M20Ia robot, v8.30. The cell has been developed for some time now and we just ran 50 parts last Friday for 2 different part types. One program uses about 40 PRs to ultrasonic weld and the other has 48 PRs to perform toy tabbing.


    This morning I was asked to run the cell for 1 of the part types and it caused a crash on the first few spots. I went in teach mode to see if my taught points are still where they should be. To my surprise, the EOAT went to the same spot as previously taught, however it was over travelling on my Z axis by 20mm. All the points that previously worked last Friday have now been exhibiting the same issue, including programs that havent been touched for weeks.


    My question is, is there a system variable or a similar way to program shift that could potentially modify all my PRs only on Z motion? Anything at all that could simultaneously affect all the PRs that use different TCPs, but all are based on User Frame 0 - World frame.


    If it has nothing to do with TP programming, would a mechanical problem on the robot could cause such an issue?


    Thank you

    l3ool3oo, this morning I have uploaded the backup from last Wednesday into Roboguide to compare the positional data and Utool values, everything is identical. As far as I can tell, nothing has changed on the PR side as I originally thought.


    However if I reteach the point lets say from the originally taught point in PR10 to PR20 and the EOAT is contacting the part as we want, my X, Y, W, P, R values are the same, however my Z is 20mm different.

    Its as if something is causing the world frame to shift 20mm below the base, but I was certain world frame could never be modified, so I am stumped.

    Hello, I am new to robot programming, started working in the field just couple of months ago, so my solution might be amateur...

    Have you checked the program adjust utility? if you make an offset in that utility by 20mm in Z the PR's will show the same values, but the program will run with the adjustment of 20mm

    Hey Rumblefish, we are using offsets for approach and retract moves that have been setup manually. Such as PR[5] Offset Z+ only ( X - 0.0mm, Y - 0.0mm, Z - 70mm, W - 0.0mm, P - 0.0mm, R - 0.0mm). The offsets work as before, the issue is that the PR that was originally taught to match the point on the part is now travelling farther in Z.

    Hi Amotov, great suggestion. However, if I am not mistaken you have to specify which program you want to apply the adjustment to. In my case, all the programs are affected and I know that I wouldn't have done that to each one.

    Here is some pictures to give you a better idea of the issue that I am currently experiencing. Physical location pic is the actual tooling stand placed in properly on the stand. The PR data picture shows you the original PR12 value that is being used in the program and has the same data value as the back up from Sep18. And on the right side of the picture is the actual position data recorded today when the robot was in that position dropping the tooling off.

    Essentially that is the issue I am having throughout all the programs. All PRs are the same as the backup from before, however when I reteach the points to match the physical location of the EOAT to a part or a stand, the Z value changes. It is almost as if the world frame – user frame 0 which is being used in all the programs is somehow being offset by 20mm or so.

    There is nothing that would change the definition of the WORLD user frame. It's always in the center of J1 and the height of J2.


    If your points are all off in the WORLD Z coordinate only regardless of TCP orientation, it's likely a frame or positioning issue:


    1. Is it possible that you were accidentally using a UFRAME[X] that was close to WORLD (e.g. 0,0,20,0,0,0)

    2. Did the workpiece move?

    3. Did the robot move?


    PR's can be tricky in that the interpreter does not validate the current UFRAME and UTOOL at runtime. In other words, it's possible to record with UFRAME[a] and UTOOL[b] and run with UFRAME[c] and UTOOL[d] with no complaint from the robot.


    If points are off with respect to TOOL Z then maybe the tool itself has moved and/or your TCP is incorrect.


    I know this is not helpful right now, but you may find it easier to debug these sorts of issues in the future if you use a UFRAME that is closer to your workpiece. It's much easier to say "I know the position should have a Z-value of 100 since the point I'm trying to reach is exactly 100mm away from the frame origin" than trying to work with WORLD positions.

    Hey Jay, thanks for your input. Love your site by the way, visited it many times as a refresher.


    To address your questions.


    1. No other UFRAME have been taught. all of them are UNINITIALIZED.

    2. The workpiece or the fixture that workpiece sits in, hasn't been modified or moved in any way.

    3. The robot hasn't been moved and the base is firmly secured as a requested check by Fanuc support.


    I get where you are coming from regarding the UFRAME and UTOOL mixup, but this is not the case. And i agree with you regarding the setup of UFRAME instead of using a base world coordinate, but this was a hand off from another programmer that was half way through development so I just stuck with it.


    Here is an interesting discovery I found this afternoon. So all the tooling are attached through ATI tool changer and those tools haven’t been modified in any way. The length of the tooling is the exact same from the J6 flange to the end of the tool where TCP is taught, nothing has changed that way. However, I went ahead and quickly re-taught a TCP for one of the tools and got these results (see image attached).

    As you can see, X, Y are close to being the same as I did a quick 6 point XZ calibration and W, P, R, are same. However my Z for the new TCP UT-7 is 23mm longer, compared to the old values of UT-6. Keep in mind that UT-6 values were the original TCP values that worked last week without any crashes or issues whatsoever.


    So what could possibly have changed to cause such a discrepancy in Z? Is it possible that J6 UT-0, that is the default tool frame has somehow shifted by 23mm up? Is there a variable or any way at all possible that would explain how the same length tooling is now giving me 2 different TCP values in my Z? And this is essentially affecting all my other TCP's in the same manner.


    Granted, once the TCP was retaught all the PR moves now work perfectly as they did before for that particular UTOOL. Unfortunately that doesn't explain how that problem occurred in the first place and what caused it.


    Thank you all for your time and contributions to this weird problem

    Did this robot have an insulated flange that someone removed? Those are about 20mm thick, and the robot's J6 origin is set at the flange face.


    Edit: After screwing around in Roboguide, I was only able to get the UT0 point to move by 8mm, by switching from normal flange to ISO flange. There isn't an option to change to an insulated flange in controlled start. I was using handling pro though, maybe it is an option in ArcPro.


    I encountered something like this on an install using old robots where someone had removed the insulated flange, but never 'told' the robot about it.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    Edited once, last by Nation ().

    Like 1

    Hey Nation, I am sorry for such a delayed reply. I was away at customer site and had no access to the robot to verify the flange option. I confirmed with mechanical lead on the project that nothing was added or removed to the flange. I also verified through controlled start that the insulated flange wasn't selected as an option, which also wasn't the case.


    Fanuc support hasn't been able to provide any concrete feedback either. I have retaught the TCP for the pin on the ATI tool changer (see pic attached) and the x, y values only differ by 0.2mm which is not significant. However my Z value was the major difference, considering that EOAT hasn't been changed physically or mechanically in any way since the development began.


    At the moment my only solution was to reteach all my Tool Frames which readjusted the PRs to their original positions. No one at our offices has seen anything like this and has no idea what the cause could have been. I just hope it doesn't happen again to cause all this headache.


    Thanks to everyone for their help and feedback.

    Have you moved the robot to zero and verified mastering? If mastering is good, does this affect both linear and joint positions? Is it just the PR's?

    Since it's an M-20iA, check the casting around J3 motor and make sure it's not cracked.

    It could be there is no longer a problem but there was one when it was first programmed.

    My question shoud sound strange, but this happened to me a couple of time: is this robot correctly fixed on the floor/base?


    We were comissioning a bigger robot (M-900 280L) that was crashing ramdonly, but mostly when we increase its speed. After investigate the programming and parametrization, we decided to check robot base screws, and most of them were "loose".

    Hey Skooter, I have moved the robot to zero and all the witness marks line up correctly. Mastering is also correct in comparison with the mastering sheet that comes with the robot from Fanuc.

    Essentially all the PR's were affected, most of them would be linear moves. I will take a look at the J3 casting as you suggest when I am back in the shop next week.


    Hey massula, that was one of the first things that fanuc support recommended checking. We confirmed that the robot base is fully tightened, so that wouldn't be the case.


    Hey Jay, the last TCP frames screenshot, UT8 is the current tool frame that was just retaught few days ago and is currently the correct one. UT5 was the original tool frame that was setup months ago and was correct and worked without problems up until recently, when the issue first occurred. Granted that is just the TCP for the ATI pin. I have several more UTOOLS being used. Same thing with all the other frames, UT1 to UT3 were setup months ago, but have been retaught and exhibit the same pattern. X, Y, P, W, R remained almost identical, but Z increased by roughly 22mm once the TCPs for those tools were re-calibrated.


    You know I've been so focused on the solution on the software side, I haven't thought about measuring the actual length. I will definitely do that when I am back in the shop and post the results as soon as I have the info.


    Once again, I appreciate all the help being provided. Thank you!

    Nation, you are absolutely right, it is not an Arc Mate. I made a mistake in my initial description as the other cell next to this one is using an Arc Mate robot. The actual model is R-1000iA/80F. Does that make a difference or change anything?

Advertising from our partners