Posts by Unevenz

    Hey Jay, I measured the distance from faceplate to the ATI pin that was taught and it's 129mm.

    Nation, I think you cracked the case. That is exactly what I was looking for, some actual variable that I could compare against the old back up program from July.

    On the left side of the image is the old backup from july which seems to have the flange setup as per your description. On the right side, is the current setup of the robot with normal flange selected. This at least gives me actual numbers to confirm that there was a change in the robot at some point and that is what i was looking for.

    Thank you all for your help, much appreciated!

    I see what you are saying Nation. Assuming the only way for this to have happened would have been that an insulated flange option was selected at the beginning of the development, during the controlled start.

    Lets say all the TCPs were taught with that option enabled at the beginning. Then lets say the robot was re-setup through controlled start -> maintenance -> manual screen to the normal flange. Hypothetically its a possibility, that someone might have done it inadvertently or maybe they were testing something. The only other robot person that had access to this cell told me he didn't do anything like that.

    My question is then, is there a variable that can be changed to select the different flange options. I am thinking something along the lines of $PARAM_GROUP[group].$MOUNT_ANGLE that is also part of the initial robot setup. I have never seen one, but would assume one exists.

    Again I am just speculating, but maybe they were looking through a variable list looking for something and accidentally changed that specific parameter value that relates to the flange option.

    I would love to dump the old TCP backup into the robot and change it to the insulated flange option, and see if all the moves go back to the way they were before. If time permits, I would be really curious to see the results.

    Thanks again

    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?

    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!

    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.

    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

    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.

    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.

    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.

    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 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