Advanced FANUC TP techniques for event-driven programming. Learn CONDITION/ENDCONDITION blocks, MONITOR/MONITOR END activation, Background Logic setup, and SKIP CONDITION — with real production patterns for conveyor jam detection, vision timeouts, and safety monitoring.
Most FANUC TP programs handle events the same way: a WAIT instruction that blocks until a signal arrives. This works — but it has real costs. A blocked WAIT cannot react to multiple inputs simultaneously, cannot cancel on timeout without extra logic, and cannot monitor safety conditions while motion is running. CONDITION blocks, MONITOR, Background Logic, and SKIP CONDITION solve all of these. If you have not used them yet, this guide will change how you write every production program.
The Problem with Polling Loops
The typical polling approach looks like this — and has three serious problems:
! --- POLLING APPROACH (problematic) ---
1: WAIT DI[5:PART_PRESENT]=ON ; ! Blocks — cannot watch anything else
2: WAIT DI[6:CONVEYOR_JAM]=OFF ; ! Runs AFTER part check — not simultaneous
3: L P[2:PICK] 200mm/sec FINE ; ! If jam happens during move, no reactionWhat polling cannot do:
- Watch multiple conditions simultaneously — each WAIT blocks all others
- React during motion — a WAIT before a move cannot cancel the move if something changes mid-trajectory
- Monitor safety conditions persistently — polling stops when the program reaches a different section
CONDITION / ENDCONDITION — Defining Event Rules
A CONDITION block defines a named rule: "when this happens, do that." The block itself does nothing when defined — it only becomes active when you call MONITOR to start it. This separation of definition from activation is the key to clean event-driven TP.
! --- CONDITION block syntax (one action per WHEN) ---
CONDITION[1]:
WHEN DI[10:CONVEYOR_JAM]=ON DO CALL JAM_HANDLER ;
ENDCONDITION
! --- Multiple WHEN clauses in one block ---
CONDITION[2]:
WHEN DI[20:E_STOP_EXT]=ON DO CALL EMERGENCY_STOP ;
WHEN R[10:CYCLE_COUNT]>1000 DO DO[6:MAINT_LIGHT]=ON ;
ENDCONDITIONCONDITION syntax rules:
- CONDITION[n] — n is 1–32 (varies by controller model). Each number is a named slot.
- WHEN clause supports: DI, DO, RI, RO, UI, UO (I/O), R[] (numeric registers), and timer comparisons
- DO clause supports: SET output, CALL program, JMP LBL — one action per WHEN clause
- Multiple WHEN clauses in one block are all monitored simultaneously once MONITOR is active
- CONDITION blocks persist in controller memory — redefine them at program start to ensure correct state
MONITOR / MONITOR END — Activating Conditions
MONITOR starts watching a CONDITION block. MONITOR END stops it. Everything between those two instructions runs with the condition actively monitoring in the background — including motion instructions. This is the fundamental difference from WAIT.
! --- MONITOR activation pattern ---
1: MONITOR[1] ; ! Start watching CONDITION[1]
2: MONITOR[2] ; ! Can monitor multiple simultaneously
3: J P[1:APPROACH] 80% CNT50 ; ! Condition[1] + [2] active during this move
4: L P[2:PICK] 200mm/sec FINE ; ! Still active — jam triggers during move
5: DO[1:GRIPPER]=ON ; ! Still active
6: WAIT .5(sec) ; ! Still active
7: MONITOR END[1] ; ! Stop condition 1
8: MONITOR END[2] ; ! Stop condition 2
9: J P[3:HOME] 100% FINE ; ! No monitoring — normal program flowAlways call MONITOR END before the program ends or loops back to start. A CONDITION left active from a previous run can trigger unexpectedly in the next cycle. Best practice: MONITOR END all conditions at program start as a reset, then reactivate the ones you need.
! --- Clean program start pattern ---
1: MONITOR END[1] ; ! Reset — kill any leftover from last run
2: MONITOR END[2] ;
3: MONITOR END[3] ;
! Redefine conditions fresh (CONDITION block is not a numbered line)
CONDITION[1]:
WHEN DI[10:JAM]=ON DO CALL JAM_HANDLER ;
ENDCONDITION
4: MONITOR[1] ; ! Activate cleanBackground Logic (BG Logic) — Always-On Monitoring
Background Logic is fundamentally different from CONDITION/MONITOR. It is a persistent task that runs on the controller at all times — whether a program is running, paused, or stopped. You configure it through the teach pendant menu, not in TP code. Use it for cell-level safety and persistent I/O management that must survive program boundaries.
! --- Navigate to BG Logic setup ---
! MENU > 6 SETUP > F1 [NEXT] > 6 BG Logic
!
! Each line is: CONDITION = ACTION
! Example entries in BG Logic editor:
!
! DI[30:DOOR_OPEN]=ON -> DO[8:SPEED_LIMIT]=ON
! DI[30:DOOR_OPEN]=OFF -> DO[8:SPEED_LIMIT]=OFF
! DI[31:E_STOP]=ON -> CALL ALARM_LOG
!
! BG Logic runs every scan cycle (~8ms) regardless of program state
! It cannot be stopped by MONITOR END — only by editing the BG Logic tableBG Logic vs CONDITION — when to use each:
- BG Logic: cell-level safety (door interlocks, speed limits, alarm logging) — must be active even when no program runs
- BG Logic: permanent I/O management that should never be switched off during production
- CONDITION/MONITOR: process-level events (conveyor jam during pick cycle, vision timeout) — active only for specific program phases
- CONDITION/MONITOR: events that should only trigger during certain operations — use MONITOR/MONITOR END to bracket those operations
- Both: do not call Karel programs or long routines from BG Logic — keep actions fast (output sets and short TP calls only)
SKIP CONDITION — Event Traps During Motion
SKIP CONDITION attaches an event trap to a single motion instruction. If the condition becomes true during the move, the robot stops and execution jumps to a label. This enables force-controlled assembly (stop when contact is detected) and mid-move part detection (stop early if sensor fires).
! --- SKIP CONDITION syntax ---
1: SKIP CONDITION DI[15:CONTACT_SENSOR]=ON ; ! Must be line before move
2: L P[10:SEARCH_POS] 50mm/sec FINE Skip,LBL[20] ;
! If sensor fires during move: robot stops and jumps to LBL[20]
! If move completes without trigger: continues to line 3
LBL[20:CONTACT_FOUND] :
3: PR[5]=LPOS ; ! Capture exact Cartesian position at skip point
4: R[20]=PR[5,3] ; ! Store Z element of that position
5: L P[11:RETRACT] 100mm/sec FINE ;SKIP CONDITION details:
- Must be the line immediately before the motion instruction — no other instructions between SKIP and the move
- Skip,LBL[n] on the move line specifies where to jump if condition triggers
- If condition does NOT trigger, execution continues normally after the move (LBL is skipped)
- LPOS captures the exact Cartesian position where the skip triggered — use this for adaptive programs
- Works with L (linear) and C (circular) motion — not with J (joint) moves
- One SKIP CONDITION per move — you cannot stack multiple skip conditions on one instruction
Production Patterns
The following are complete, production-tested patterns combining the techniques above.
! === PATTERN 1: CONVEYOR JAM DETECTION ===
! CONV_JAM_ROUTINE sets alarm light and pauses
CONDITION[1]:
WHEN DI[20:CONV_JAM]=ON DO CALL CONV_JAM_ROUTINE ;
ENDCONDITION
1: MONITOR[1] ;
2: J P[1:APPROACH] 80% CNT50 ;
3: L P[2:PICK] 200mm/sec FINE ;
4: DO[1:GRIPPER]=ON ;
5: WAIT .3(sec) ;
6: L P[1:APPROACH] 200mm/sec CNT50 ;
7: MONITOR END[1] ;! === PATTERN 2: VISION TIMEOUT HANDLING ===
! Camera must respond within 3 seconds — one action per WHEN
CONDITION[2]:
WHEN TIMER[1]>=3000 DO JMP LBL[99] ;
ENDCONDITION
1: TIMER[1]=0 ; ! Reset timer before trigger
2: DO[10:CAM_TRIG]=ON ;
3: WAIT .02(sec) ; ! Hold trigger pulse
4: DO[10:CAM_TRIG]=OFF ;
5: MONITOR[2] ; ! Start 3-second timeout watchdog
6: WAIT DI[11:VIS_RDY]=ON ;
7: MONITOR END[2] ; ! Camera responded — cancel watchdog
8: CALL VIS_READ ;
9: JMP LBL[100] ;
LBL[99:VISION_TIMEOUT] :
10: MONITOR END[2] ;
11: DO[14:VIS_ALARM]=ON ;
12: PAUSE ;
LBL[100:END] :! === PATTERN 3: FORCE-CONTROLLED INSERTION (SKIP CONDITION) ===
! Robot searches downward until contact, records Z height
1: PR[10]=P[5:SEARCH_START] ; ! Load base search position
2: SKIP CONDITION DI[25:FORCE_THRESH]=ON ; ! Arm trap — must be line before move
3: L PR[10] 10mm/sec FINE Skip,LBL[50] ; ! Skip to LBL[50] on contact
4: JMP LBL[90] ; ! Reached target without contact — error
LBL[50:CONTACT] :
5: PR[11]=LPOS ; ! Capture Cartesian position at skip point
6: R[30]=PR[11,3] ; ! Extract Z element of captured position
7: IF R[30]<R[31:Z_MIN],JMP LBL[90] ; ! Validate depth is in range
8: L PR[11] 5mm/sec FINE ; ! Press to final insertion depth
9: CALL INSERT_SEQUENCE ;
10: JMP LBL[99] ;
LBL[90:DEPTH_ERROR] :
11: DO[14:ALARM]=ON ;
12: PAUSE ;
LBL[99:END] :These patterns are production-proven but must be adapted to your specific I/O mapping, safety requirements, and controller firmware. Always test CONDITION and MONITOR patterns in T1 mode (reduced speed) before running in AUTO. Xpert Robotics provides FANUC advanced programming consultancy and commissioning across Israel.
