Posts by retobor

    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.

    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.

    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.

    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.


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

    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?