ONE Robotics Company

Last updated: July 2026

You’ve finished programming your FANUC robot, tested it in T1, and now you want to run it faster. If you’re like me, you sometimes forget the details on Remote vs. Local, UOP signals and the different startup types available (RSR, PNS, Style, Other). For your (and my own) reference, here’s a quick guide on how to get things running.

NOTE: If you like this post and are interested in the programming side of things, be sure to check out my book on programming FANUC robots.

The Teach Pendant Enable/Disable Switch

For safety, only one device can control robot motion. If the teach pendant switch is enabled (ON), the teach pendant is in charge. The robot will not move unless you’re jogging it.

Of course that means that the teach pendant must be disabled (OFF) to run in AUTO.

The Mode Select (T1/T2/AUTO) Switch

This also controls who’s in charge to some extent, but you can’t take it with you into the cell.

This switch has to be in T1 or T2 for the teach pendant to move the robot. When switched into AUTO, the teach pendant cannot run programs or jog even when enabled. In fact, it is a fault condition when the teach pendant is enabled while in AUTO. Some other device (covered later) will issue signals to start and stop the robot.

T1 and T2 are for teaching and testing the robot. T1 limits the tool center point (TCP) speed to a nice and safe 250mm/sec.

If your robot has T2, you probably have an older robot or you’re outside the US. This mode became non-standard in the US over a decade ago, but it allows you to test-run programs with the teach pendant at full speed. Be careful out there.

Fence Circuit

The fence circuit is ignored in T1 and T2, but it must be closed when in AUTO mode.

Remote vs Local

Now that your robot is in AUTO, you can choose to start it remotely or locally. This configuration option is on the System Config screen (Menu > System > Config).

Local Mode

When in local mode, the robot will be started from the Standard Operator Panel (SOP) green button on the front of the controller.

Be careful: when the robot is in local mode, it will always run whatever program you have selected on the SELECT menu. The robot will ignore any setup you have done on the Program Select method screen. (Ask me how I know!)

I generally switch things over to AUTO/Local after some thorough testing in T1. Start out slow with your finger on the HOLD button, gradually bumping up the override until your confidence grows.

Remote Mode

When the robot is in Remote mode, it will follow the Program Select method and Production Start method you defined in the system config screen. You’ll probably always use UOP as the Production Start method.

Program Select Methods

There are four Program Select methods: RSR, PNS, STYLE and OTHER, but I think OTHER is the best option.

OTHER

Ah, OTHER: the simplest, most barebones and easy-to-use startup method. The robot simply runs an explicitly stated program when it receives a start signal.

Set your Program Select Mode to OTHER on the system config screen and then specify a program to run by hitting DETAIL. You can also set the program name via the $shell_wrk.$cust_name system variable.

NOTE: You’ll have to cycle power after changing the Program Select method.

I find that keeping it simple, having the robot start some main task and handling any job requests, etc. from there is generally best, but I’ll briefly summarize the other methods as well.

Robot Service Request (RSR)

If you don’t want to write a job request handler, FANUC has one built-in. You just have to follow their naming convention: RSRxxxx. You have the option to add an acknowledge bit, but it’s not really a full handshake.

The setup screen has you associate a number with each of your 8 RSR bits (e.g. 10, 20, 30, etc.). You can also specify a base that these numbers will get added to (e.g. 100). With these example values, if the RSR1 input is given the robot will execute RSR0110 (base of 100 + RSR1 bit value of 10). RSR2 would execute RSR0120, RSR0130 for RSR3, and so on.

You have to follow this naming convention (RSRxxxx) exactly, but you can modify the RSR prefix via $shell_cfg.$job_root.

I’m not a fan of these non-descriptive names (what the heck does RSR0150 do again?), so I wouldn’t recommend using this method.

Program Number Select (PNS)

PNS is kinda like RSR, but it interprets the 8-bits as a binary number. You don’t have to explicitly set numbers for each signal, but you can define a base number $shell_cfg.$pns_base. The naming convention is similar (PNSxxxx) unless you change the prefix with $shell_cfg.$pns_program.

Style Select

Style is basically PNS without a naming convention. You explicitly setup a table that associates a given TP program with the input job number.

Additionally, you can enable/disable entries via the setup table.

The bottom line with Program Select methods

It seems to me that the RSR, PNS and STYLE Program Select methods are all remnants of an earlier time. Who wants to name their programs RSR0001 or PNS1000 when you could write something more descriptive like UNLOAD_LATHE_A?

If you can’t be bothered to setup your own logic for job requests, STYLE is probably your best bet.

A simple job request handshake

Here’s how I might write a simple routine to get a job request:

! get_job.ls
R[1:job]=0 ;
LBL[1] ;
WAIT (DI[1:job request]) TIMEOUT,LBL[500] ;
R[1:job]=GI[1] ;
! GO[1:job] echos R[1] in BG logic ;
DO[1:job ack]=ON ;
LBL[2] ;
WAIT (!DI[1:job request]) TIMEOUT,LBL[501] ;
DO[1:job ack]=OFF ;
END ;
 ;
LBL[500] ;
! timed out waiting for job ;
! TODO: alarm? ;
JMP LBL[1] ;
 ;
LBL[501] ;
! timed out waiting for job request to go low ;
! TODO: alarm? ;
JMP LBL[2] ;

The PLC would be responsible for validating GO[1] after DO[1:job ack] comes on.

Then your main routine might look something like this:

! main.ls
LBL[1] ;
CALL GET_JOB ;
SELECT R[1:job]=1,CALL SOME_JOB ;
               =2,CALL SOME_OTHER_JOB ;
			   ELSE,CALL INVALID_JOB ;
JMP LBL[1] ;

UOP Signals

Most of the time you’re going to have a PLC controlling your robot with UOP signals. We’re probably talking over Ethernet/IP. (I briefly cover mapping the UOP signals at the end of this post.)

UOP Input Signals

On the input side (from the robot’s perspective), you get up to 18 signals, but you’ll probably only need the first 8.

NOTE: You have to enable UI signals from the MENU > System > Config screen. Set “Enable UI Signals” to TRUE.

UI[1:*IMSTP] Leave this on all the time. When it drops, the robot will stop immediately, but this should not be used for safety purposes (use hardware e-stop contacts or DCS Safe I/O instead)

UI[2:*Hold] Leave this on unless you want to pause the robot. If this signal ever dips, the robot will slow to a controlled stop and pause its program. It’ll need a UI[6:Start] signal to resume.

UI[3:*SFSPD] This annoying little signal is normally on. When it drops, it will pause the robot and clamp the override to $scr.$sfrunovlim. If you’re in teach, it’ll clamp the override to $scr.$sfjogovlim.

UI[4:Cycle stop] This signal can be used as a cycle stop or immediate abort signal depending on the value of $shell_cfg.$use_abort. If set to true, it will act as an abort signal. If set to false, you’ll have to check UI[4] in your program and ABORT by hand.

NOTE: There is a System Config item for this: CSTOPI for ABORT.

UI[5:Fault reset] Normally off, this signal will attempt to reset any errors on your robot. Note: your robot cannot start or resume if any faults are present.

UI[6:Start] This one depends on $shell_cfg.$cont_only. If set to true, UI[6] will only resume a paused program, and you’ll have to use UI[18:Prod start] to start from scratch. If set to false, it will resume or start an aborted program from the cursor position.

UI[7:Home] I’ve never used this signal. I guess you can setup a home macro to run when this signal is received.

UI[8:Enable] When this signal is high, the robot can move.

So basically, to start the robot:

1. Turn on UI[1:*IMSTP]
2. Turn on UI[2:*Hold]
3. Turn on UI[3:*SFSPD]
4. Turn on UI[8:Enable]
5. Pulse UI[5:Fault reset] to clear any faults
6. If there are no faults, pulse UI[6:Start]

If the robot is paused (from dropping the hold signal, a fault or e-stop):

1. Keep UI[1:*IMSTP], UI[2:*Hold], UI[3:*SFSPD] and UI[8:Enable] high
2. Pulse UI[5:Fault reset] if necessary to clear faults
3. Pulse UI[6:Start]

UOP Output Signals

You’ll get some signals back from the robot if you want. Feel free to use any or all of them to make your PLC more intelligent.

UO[1:Cmd enabled] This is ON when the robot is in Remote mode and not faulted. You can only start/resume the robot when this is ON.

UO[2:System ready] Servo motors are on

UO[3:Prg running] A program is running

UO[4:Prg paused] A program is paused

UO[5:Motion held] On when the robot is actively being held (e.g. UI[2:*Hold] is low)

UO[6:Fault] On when there is a fault that needs to be cleared/reset

UO[7:At perch] When the robot is at reference position #1

UO[8:TP Enabled] When the teach pendant is on

UO[9:Batt alarm] When the CMOS RAM battery voltage is less than 2.6V or robot battery voltage is low

NOTE: Watch out for this one! If your batteries die completely you may end up dealing with a BZAL alarm and remastering.

UO[10:Busy] When the robot is thinking

I’m not a PLC guy, but I would:

1. Make sure UO[1:Cmd enabled] is on before issuing any start signals
2. Don’t bother issuing any start signals if UO[3:Prg running], UO[5:Motion held] or UO[6:Fault] is on
3. Know that you’ll have to give a reset if UO[6:Fault] is on
4. Maybe prohibit a start from the top unless UO[7:At perch] is on
5. Tell the operator to turn off the TP if you want to run and UO[8:TP enabled] is on
6. Tell someone to change the batteries if UO[9:Batt alarm] is on

Mapping UOP signals

Let’s assume you’ve setup your Ethernet/IP connection and everyone’s happy.

IO > F1 [ TYPE ] > UOP > F2 CONFIG

If you’ve never mapped IO before, this might look strange to you, but you’ll see a range of inputs/outputs, then columns for rack, slot, start and status.

If there are existing mappings here, you can delete them.

We are basically telling the robot where the logical UI/UO signals (used for starting/stopping the robot) are addressed in memory.

Ethernet/IP is rack 89. The slot corresponds to the Ethernet/IP connection number (probably 1 in most cases). Start will depend on where your PLC tags are, but most people seem to start at 1 and reserve the first 2 words for UOP signals.

Your mapping will probably end up looking like this. Remember to cycle power after changing any I/O mapping.

NOTE/RANT: It drives me crazy, but lots of people will map UO[1-20] and DO[1-20] to the same place (e.g. rack 89, slot 1, start 1) along with UI[1-18] and DI[1-18]. You don’t have to map those DIs and DOs – they are already mapped and used by the UI/UO signals! The UOP signals are digital I/O under the hood, so pointing DI/DO at the same rack/slot/start just double-maps the same points. If you reserved 2 words, just start at 33 or start your DIs at 19 and DOs at 21 if you’re packing bits.

---

That about does it. At this point you should know how to start your robot both locally and remotely while in AUTO via whichever program select method serves you best. We also covered the UOP Startup Method which you’ll probably use 99% of the time. (The other option is OTHER, which looks at a system variable $shell_wrk.$cust_start, usually used when the robot is controlled by a PC.) As a bonus, we quickly talked about how to map these signals to the PLC.

Let me know if you have any questions or know something about RSR/PNS/STYLE that I’m missing!

---

If you enjoyed this post and want to learn more about FANUC robot programming, please check out the book I wrote, Robot Whispering: The Unofficial Guide to Programming FANUC Robots.