Posts by retobor

Quote from Doctor_C

pdl is correct.

You can auto update the 8.10 to the latest revision though, which is P/32.

May help with some stuff fixed along the way

Display More

Would upgrading from V8.10 to V8.30 be considered a major revision?

Quote from cobenson

After you perform an all of the above backup, depending on the robot controller, you can also do an ascii backup from the same screen.

Alternatively, set your backup folder location, then set MD, F4 SAVE AS will backup AOA and LS in one shot.

There are a few things you can try. Some may be subject to the options loaded on your controller. Some will be easier to implement then others.

1. Program Shift Utility - similar to program adjust, however changes are permanent. You may run into the same issue.

2. Adjust your TCP frame - Although I don't really recommend this, it can be an easy solution if your tool doesn't reorientate during process.

3. Frame Shift Utility - Convert the points in your program from frame 0 to frame x. Then you can adjust your user frame as needed. As mentioned above.

4. Tool offset / offset instruction - this would require more work as you would need to add this to each position, but you can dynamically change the position on the fly with a position register.

Yes. There are a few options; in the parent tool of your vision process, you can select do not log, log failed images, or log all images.

AR is the argument connected to the program call.

1. CALL WR_UPDATE(X,X)

(AR[1], AR[2]) etc.

That is a very high error especially for a 400mm working distance. I would consider adjusting some of your physical limitations; larger cal grid, adjusting exposure, etc. Ensure your setup values are correct as well; focal distance (check what the system thinks with a measure tape), grid spacing value, etc.

As a last resort, delete the high error calibration points as they will effect the overall average error.

Quote from AlanT96

it is happening after tip dress. But only the tip dress that happens immediately after changing caps

If this is the case, it sounds like the reference isn't being reset after new caps. What is AR[2] for the program you've shown above? It looks like the wear is reset with the program call on line 52 if this register does not equal 1.

What are your calibration results? Your mean and max error values should help you determine if camera calibration is off. Would a larger target help with calibration?

In relation to focus of the camera, I believe the standard Kowa cameras optimal working distance is 400mm. I'm sure you can focus the camera to 500mm but something to consider.

The reference position would be the easiest method. However, anytime I've had to monitor an additional axis, it interacted with an operator. In that case, I would use a DCS JPC monitor and connect it to an NSI.

I find it varies between integrators/customers, but typically a tracking sheet is used to record changes. It also heavily depends on the applications and size of the project. DCSVRFY is fairly descriptive regarding POS/IO changes.

It is pretty common that the DCS safety sigs are recorded (hex or dec) and these are latched by the PLC. Usually requires an acknowledgment on the PLC end to prevent rogue editing of the safety system.

Has this always been a problem? Which direction is being used as gun open? Was TW_SETG1 mastered properly with new caps?

Yes, I worked on a similar EASOM cell with the same issue. I believe it is a result of error when teaching the coordinate frame.

Passing coord from UF to PR

I think this is the thread you want.

If you have never run it before, it is probably best to wait for the weekend. It isn't difficult, but there is a procedure to follow. You must verify gun parameters and perform a gun zero master with fresh caps.

Quote from AlanT96

I'm having tip increase faults after every tip change.

After rereading your original post, I am now confused. Is the tip increase fault after a cap change, or a tip dress? or both? I was assuming this was occuring after a tip dress because the wear update program is called after a dress, I believe.

This is a common issue on new custom guns during their break-in period. There could be several problems here, the help diagnostics on the pendant is descriptive for this fault. If it is constantly happening every cycle, your caps look ok, and TW_SETG1 was run properly, it may be time for an autotune.

If autotune does not fix the issue, I know changing these system variables can resolve the issue: $SGSYSCFG.$MINIMUM_TRQ from 1 (default) to 100, and $SGGUNx.$SGTWD.$DIV_STROKE to 100 (x being your gun number). I have not been told what these variables do exactly.

I believe you need to adjust "UOP auto assignment" under system - config.

Use the group exchange utility once the program has been created.

I don't really think anyone actually knows the potential problems that could occur from a minor revision upgrade, because nobody really does it (including some Fanuc techs). I've transferred files (with the exception of sysvars and some other .sv files) between major revisions without issues. I've also upgraded a multiarm ArcTool cell from 8.0 to 8.3 because of issues with coordinated motion. I never had any issues, but nobody wants to take on that liability either. This is just my opinion.

HandlingTool manual explains that you can go between minor revisions 8.10 to 8.20 for example. I would take an image first (auto update does preform an image prior but I have heard that this has crashed on people before), then preform the auto update. Never heard of .TP's not transferring. They can be translated between any major revision or xxTool software as far as I am aware.

Quote from I3ooI3oo

I am currently building a system right now with a dial table and LR Mate 200i. We are using a Powerflex 550 from AB.

First thing I did was have a relay wired into the enable bit of the table controller. When that relay is not active the table can't rotate. The Poll for the relay comes from the Robot. I created a reference position for the table. The bit that is set when the robot is in that reference position is then inverted in the I/O. This now means that bit is active when the robot is not in the reference position. So if the table is rotating and the robot moves into that reference area the table will stop immediately.

To prevent the robot from moving into the table area while rotating thus, causing the table to stop, We wire the table's "in position" bit into the robots inputs. In my pick program, which is the only program that moves near the table. There is a wait "DI[109]=ON" for table in position bit, This prevents the pick program from moving into the table area.

Using this setup the table and the robot haven't ever crashed. If the robot is off the table can't rotate. If the table in position sensor goes bad the robot can't move into the table area.

Display More

I've tried to invert a bit for ref pos in the past. I recall this function not behaving as I expected; the controller ignored the bit inversion when assigned to ref pos. Can you confirm that it works?

You define user frame and user tool when you setup your limits for space function.