You should at least get a yellow prompt box on the TP which asks the user if they want to resume from that line. This may be a production check setting under Setup - Prog Select.
Regardless, this doesn't really help as it's just another step they can preform. You should be able to prevent access to the program with the password option. Alternatively, you could send a signal to the PLC when the TP is enabled and track it that way.
Interesting. I have this option in Roboguide, but mine only exports SOP I/O and register comments. No robot I/O, digital I/O, etc.
I'm not too sure what would cause that. The only instance where it will not export I/O is if the comment field is blank. However, you can create comments in the .CSV and import them as long as the formatting is correct.
It can be flaky to use. I've noticed it will not import/export if devices are not mapped or set to offline.
Hi, retobar. What is the name of this option. I am currently trying to add it but there is to many of them and there is no description of what they are used for. Thanks.
It is not a robot option. It is an addon to Roboguide. You must select plugins when you install Roboguide, or run the installer again and select the option. You can enable the option in the application from Tools - PlugIns.
Display Morepdl 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
Would upgrading from V8.10 to V8.30 be considered a major revision?
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.
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.
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 believe you need to adjust "UOP auto assignment" under system - config.
Use the group exchange utility once the program has been created.
