one issue I have is employees that don't program robots deciding to attempt to without authorization. I know you can restrict what people can do without a proper login, however our robots use outputs to control injection molding presses, for example when the clamp can close or when ejectors can move forward or retract. Our mold changers need to be able to control permissions such as clamp open and close and if i have it locked out they would need to find me to open it. My goal is to find a way to restrict the programs from them but allow them to change i/os. I would also like to avoid wasting their time to come hunt me down every time they need a permission changed. Any advice or help would be appreciated.
locking out users on fanuc
-
Crig -
July 20, 2018 at 4:45 PM -
Thread is marked as Resolved.
-
-
The password system would be the ideal way. Next best thing would be read/write protect the programs, but this is pretty easy for a dedicated person to get around.
-
How would I go about read/write protecting the programs or creating an xml file and loading it onto the robot?
-
Write protecting a program is pretty simple. On the Select Screen, highlight the program you want to protect, then use the function key to enter its configuration settings (i can not remember exactly what the button says, but there are only a few options). Then at the write protect line, change it to true.
The XML file can be created in any text editor, i personally use Notepad ++, which is free and has language support to make everything stand out cleaner.
-
Once a program is protected what all is restricted from someone? For example can it still be loaded and started or will it need a password to be changed?
-
IIRC, once a program is write-protected, it cannot be edited. To change the program, you'll need to follow the procedure - but turn off the write-protect.
-
That is correct. It should also be noted that if a program is write protected and you try to load that same program from a backup to overwrite the current version, it will fail. You have to de-protect the program before you can overwrite it.
-
thanks all, the write protect will work for what I'm doing. I appreciate the help.
-
one issue I have is employees that don't program robots deciding to attempt to without authorization. I know you can restrict what people can do without a proper login, however our robots use outputs to control injection molding presses, for example when the clamp can close or when ejectors can move forward or retract. Our mold changers need to be able to control permissions such as clamp open and close and if i have it locked out they would need to find me to open it. My goal is to find a way to restrict the programs from them but allow them to change i/os. I would also like to avoid wasting their time to come hunt me down every time they need a permission changed. Any advice or help would be appreciated.Is the issue limited to unauthorized people messing strictly with I/O's during runtime? There should be an option in system->config that disallows any manual I/O changing while in auto mode
-
No, the issue is that unauthorized people alter programs that they think is necessary, for example they'll touchup a point that they think needs to be changed. Recently they changed a point after a part wasnt being cut but the issue was the nippers. They did not touch up the point they meant to and the robot ended up crashing and damaging the EOAT. I looked into the password system but if I put a password on it then they are then locked out of the i/o and they need to access it for mold changes.
-
Typically I would write a series of programs that the operator can access that does the simple tasks that are needed. On a recent system there were programs like. To_service.TP and From_service.TP which would bring the EOAT over to the door of the system so they could open the door and inspect/clean the EOAT.
You could write a series of programs and add a menu setup that allows them to choose which of the programs they can choose. Each program could be as simple as turn on these I/O bits, with another program that turns them back off.
-
You can create custom password levels in an xml file that disallows program editing, but allows full access to DI/DO.