Hi!
Is there a way to change the password for the Userlevels?
Everybody know the Password for Userlevel 3, so i can't protect my Standard Programms.
Thanks!
Hi!
Is there a way to change the password for the Userlevels?
Everybody know the Password for Userlevel 3, so i can't protect my Standard Programms.
Thanks!
Welcome to the forum.........
I'm not aware of any possibility.
So sad, but thank you for your help.
Then I will not get around to train the people on the robot until they can handle it.
But in the meantime there is the possibility to use the "operator" command not only as a keyboard command but also as a program command in F-Controllers (and E-Controllers from a certain software version).
So you can use the following commands in the program:
If operator 3 is active:
operator 2
If operator 2 is active:
operator 1
If operator 1 active:
operator 2
But what does not work
the change from operator 2 to operator 3
I presume you are referring to the Taught Program Protection Option.
You haven't mentioned that you are using it though so I'm speculating.
What are you trying to protect and with what regard to?
Have you set it up according to the manual?
Nothing in Kawasaki is 100% protected by the way, even if options suggest this.
I would use the "Taught Programm Protection Options" if i could change the "Operator 3" password.
(everyone already knows this password)
My goal is to protect Standard Pick&Place Programms, wich you can copy to generate a new Programm.
But it seems to be impossible
Protect in what regard, you mention protect........but in regard to what?
QuoteProtect in what regard, you mention protect........but in regard to what?
I want to protect the programs from modification, because they are standard programs that should not be modified.
They are only there, to make a copy.
I was in the same situation, wanted that nobody would save or modify the programs without password, but i did not find any solution for this.
Although, you can have a background program which remain at the same IF page if you dont set a certain/variable password to unblock the IF page.
I really don't know why protective features are required.
Through proper training, there is no requirement IMHO especially if you set the application to operate without a teach pendant (which is under the control of maintenance) and drive it all from an HMI and PLC.
I was in the same situation, wanted that nobody would save or modify the programs without password, but i did not find any solution for this.
Although, you can have a background program which remain at the same IF page if you dont set a certain/variable password to unblock the IF page.
I already know this trick, but it disturbs more than it is worth.
QuoteI really don't know why protective features are required.
Through proper training, there is no requirement IMHO especially if you set the application to operate without a teach pendant (which is under the control of maintenance) and drive it all from an HMI and PLC.
We have almost 100 Kawasaki robots, we also need an enormous amount of personnel for that. This also means that a lot of training is needed.
A PLC or HMI is too expensive. But what is possible, we have covered via the IF panel.
Yes, I completely understand and it's just my own personal opinion really.
Placing a passcode or even create an evolving passcode algorithm around a timestamp for instance within a PC task which locks to the IFP so that only IFP pages can be displayed is usually more than adequate protection.
If used in conjunction with Aux 0896 and Aux 0897 options set to level 3 in order to grey out options for level 1 and level 2 operator levels can pretty much lock everything down.
Does not matter that in operator level 1 or level 2 you can still access Aux 0899 to change to operator level 3, the passcode on the IFP will prevent access to anything further then.
In addition if a passcode is used within a PC Task, you can also lockdown the PC Tasks too so they cannot be aborted (well they could, but you would instantly restart them in the code).
However, even with PC Tasks, they can be stopped outside of any protection they are controlling just by implementing 'alias' commands or a well known command and then reboot to disable them which can be entered via a terminal editor online.
Depends on just how far you want to go, but you cannot prevent people with 'exploratory fingers' or 'accidental button pushes' from crashing things, including manually driving the robot into fixtures without Cubic S protection for example.