Setting Up a Password System on Fanuc Robots (R-30iB V8.

30P)
Password Option
Before anything else, you will need to have the paid option J541 (Password Protection). This can be
done either upon initial purchase from Fanuc (recommended) or after purchase using a PAC (Product
Activation Code).

Define Password Levels

The Fanuc Password System allows for up to 9 password levels, although the highest level (called Install)
cannot be modified, and may only have one user. The levels range from 0 to 8, with 0 being the general
operator, with no username and no password, and 8 being the Install user level. By default, only levels 0,
1, 2, and 8 are used, configured for Operator, Setup, Program, and Install levels, respectively. To
configure the password levels to your own specifications, you will need to create a special XML file.

The password.xml file can specify as much or as little as you want, restricting all users from accessing the
Digital Input screen, or restricting a single user level from pressing a single button on a single screen. The
limit of the granularity of control only comes in at the individual program level. You can specify
permissions for specific actions down to the edit screen, but not to a specific program open on the edit
screen. In order to restrict access to certain programs and not to others, you will need to use the
password system in combination with the Write Protection attribute of programs.

All of your configuration information, detailed shortly, need to be contained in a single XML file,
between the <PASSWORD> and </PASSWORD> tags. The empty XML file should look like this.

The first thing you will want to define are the names of your different levels, which will indicate what
access the users at that level will have. An example is below.
The next helpful thing to define is what type of menus each level has access to by default. In many cases,
you will want to restrict lower levels to Quick Menus, while allowing upper levels access to Full Menus.
An example is below.

Before going further, it is important to understand how screens, items, buttons, actions, functions, and
options are defined in the password system. Every screen and subscreen has a screen id and a soft part
id, abbreviated as scrn_id and sp_id in the XML file. A list will be included as Appendix A containing the
ID’s for all of the screens I have been able to identify.

Using these ID’s, the next step will be to define the default screen each user level will be taken to when
they log in to the controller. I have mine defined so that everyone is taken to the Alarm Screen, but this
can be modified to any screen that the level has access to.

Next is defining what levels have what access to what features of the controller. Access is defined in two
stages, the ability to view and the ability to edit. It is important to note, regardless of the access set for
edit, if the user level cannot view the feature, they also cannot edit the feature. The XML file uses the
key word “access” for view access, and “rw_access” for edit access.

Not every screen needs to be defined. Some screens do not allow for any malicious interference with
the operation of the robot, and so can be left alone. The most important screens to define are those
that allow editing of data or logic, and should be carefully reserved to only allow needed access to each
level. An example is below.
In this example, I have restricted the Operator, Gap Leader, and Supervisor levels from having any
access to the System Variable screen. I have allowed Maintenance and Technician levels to view, but not
edit System Variables, and I have allowed Engineers and up to edit System Variables.

Once screen access has been defined as is desired, you may want to further restrict certain functions
within a single screen differently for different levels. One instance may be with the Edit screen. It may
be desirable to allow the operator the ability to move the robot forward and backward through a
program, but not allow them any editing power, then further to allow the Technician to Touch Up
points, but not to change any logic. An example is below.

There is also a small collection of options which can be controlled by the XML file, two I will address are
Jog Access and Production Speed. Others will be found in Appendix B. These options are identified with
a constant tag “const” and the two I mentioned are 20 and 21. Example below.

The first, if access is set to 0, will allow the user to jog the robot in Cartesian directions, but not to rotate
the TCP about its axes. The second, if access is set to 0, will not allow the user to change the robot
operation speed below 80%.

Creating Install User

Before you can being configuring the actual robot, you will need to choose an Install user. This should
generally be the most senior Process Engineer, Robotics Engineer, or the Engineering Manager. This
individual will be responsible for any changes to the Password system.

When you first access the Password Setup Menu, you will see a message saying “Passwords are inactive.
Press LOGIN to activate.” When you press LOGIN, you will be able to enter a username for the Install
level, and then you will be prompted to enter a password for this user, and then to verify that password
by entering it a second time.

Once you are logged in, you will have a few immediate options. One is the Default user timeout. If this is
set to a number greater than 0, then the user will be logged out after that many minutes of inactivity. If
it is set to 0, then the user will not be automatically logged out due to inactivity. The value may be set to
any number between 0 and 10080 minutes (seven days).

The second immediate option you will be faced with is to enable or disable Log Events. When Log Events
are enabled, then an additional menu option will be added under Alarm, detailing password controlled
actions. The most recent 100 items will be logged.

The last immediate option you will have is to change the number of available users. By default, this is set
to 10, but this is frequently insufficient for all of the users who may need access to a given robot. This
number can be changed, but requires a power cycle to take effect.

Pressing Next will give you two more options. CONFIG and DISABLE. Pressing DISABLE while logged in as
the Install user will deactivate the entire password system, and delete the Install user.

Configuring Password Levels

The next step is to load the XML configuration file created to define your custom password levels. Load
the xml file onto a flash drive or compact flash card, and insert it into the robot. Next, go to the File
menu and set the default device to the device you just inserted. Finally, return to the Password menu
and press CONFIG.

You will now have the option to VERIFY, IMPORT, or EXPORT. First, it is a good idea to verify that your
XML file contains no critical errors. This does NOT overwrite the current configuration, only parses the
XML file you provide and ensures that it is valid.

Once the file has been verified, Import it into the controller. This will now be the configuration which all
users will be defined by. Save the XML file to use on other robots. We will come back to this later.

Setting Up Users
Now that the user levels have been defined, it is time to create the users. Depending on how you intend
to use the system, there are two difference recommendations. The first is if each user will be
responsible for their own username and password, and the second is if the system will be based on
security keys.

In the first scenario, each username should be very clear and recognizable for the user, and the
password should be something easy for them to remember, which will not take them too much effort to
enter into the Teach Pendant via Function Keys. Simple number-only passwords are ideal for this, as
they are easier to input, and allow plenty of combinations.

For the second scenario, which the rest of this document will focus on, it is expected that no user
(besides the Install user) will ever know their own password. In this instance, the password should be
complicated and difficult to remember. Once the users are set up, they will only ever log in using their
personal key, not by entering their password.

Set up each user as desired, being sure to set their level each time (they will always default to level 1,
whatever it is configured as). It is suggested to add in a couple of Contractor users, which can be generic,
but serialized, so that temporary access can be granted to internal or external support. The Install User
should be responsible for signing in and out these keys.

Creating User Keys – Step 1: Hardware

Each User Key consists of a single USB Flash Drive, and if desired, an identifying tag. Shown below are
the components we use for our User Keys.

We stock blue Verbatim Flash Drives for regular storage uses, and now stock special red Verbatim Flash
Drives for the creation of User Keys. The plastic name tags are color coded based on the password level
of the attached key as shown below.

Each key has the first and last name of the user written on the tag. Once the key is created and handed
off to the user, the user is then responsible for every action taken with that key.
It is important to note that a large capacity is not desirable for creating user keys. Larger capacity is not
only more expensive, but it also slows down the access speeds and can cause issues with the use of
keys. We use 4GB flash drives, which is the largest recommended size. 1 or 2 GB is preferred.

Creating User Keys – Step 2: Formatting

Once you have the desired components for the keys, you need to format each key to FAT rather than
FAT32 for optimal performance. Each of our devices has the username of the user set as the name of
the device upon formatting. Formatting can be performed by opening Windows Explorer (My Computer,
My Documents, or any file folder) and right clicking on the flash drive in the side bar directory and
selecting format.

Once you have launched the format window, select FAT, set the name under Volume Label, and format
the device by pressing Start.

Creating User Keys – Step 3: Enabling USB Keys

You must log in under the Install User, and navigate to System Variables.

MENU -> SYSTEM -> VARIABLES

Set $PASSWORD.$ENB_PCMPWD = TRUE

Creating User Keys – Step 4: Final Setup

First, log in as the Install User once again, then navigate to the File menu and set the device to UD1 (the
USB port on the face of the controller cabinet). All keys must be created with this port.
Now, return to the password setup menu with the list of users. It is suggested to set each user’s timeout
to 0. This will make it so that when a user removes their key, it immediately logs them out. This is added
security that only the person holding the key can make changes under a user’s name.

Navigate to the line of the user you wish to create a key for, and press the USB Function Key (remember
to scroll to the next set of options with NEXT). You will then be prompted to insert the key. Insert the
key into UD1, then return to the Teach Pendant and continue on. Once the key is created, remove it and
move to the next user. Repeat for every user.

Roll Out
The last step is to transfer the users to other robots. This can be done by taking an All of the Above
backup of the setup robot, isolating the syspass.sv file, and loading this file onto the desired machine.

NOTE: This will require you to re-enter the DCS password and cycle power.

Once the syspass.sv file is loaded, then manually create the Install User and all of the other users will
appear. Lastly, load in the XML config file to make all levels match. Verify that keys work on the new
robot.