FANUC Mixed Logic, BG Logic, and Macros: Picking the Right Tool for Parallel Behaviour

The customer asks for a “simple” change: turn on a vacuum output when the robot crosses a position, and only while the conveyor is running. You add a Mixed Logic line. It works on the bench. It breaks the moment the cell scales up to real production speed because Mixed Logic can only handle simple comparisons during motion. The fix is not more Mixed Logic, it is moving the behaviour into Background Logic or a Condition Monitor. At Probot Systems we see this misalignment between tool and use case on most cells where multiple integrators have touched the code over the years.

This post is written for technicians programming R-30iB, R-30iB Plus, and CRX-10i controllers who need parallel behaviour and are not sure which control structure to reach for. We will cover Mixed Logic, Background Logic, Macros, and Condition Monitor in the order you should evaluate them.

What this error actually means

There is no single FANUC alarm called “Mixed Logic misuse”. The symptoms appear downstream as INTP-254 Parameter not found, PRIO-620 PNIO(C) station deactivated when a BG Logic task references an IO that vanished, or simply behaviour that does not match the program as written.

Per the FANUC error code manual on INTP-254: “Parameter not found. Cause: The specified parameter name cannot be found. Remedy: Check the parameter name.” It fires when a Mixed Logic line, a BG Logic task, or a Macro references a system variable or parameter that does not exist on the running firmware. The fix is reading the manual for that firmware, not patching the symptom.

Per the manual on PRIO-620: “The device whose Show error when deactivated setting is ON is deactivated. Remedy: Check the station specified the station number, and activate it.” This one bites when a BG Logic program is polling a fieldbus IO that loses comms, and the polling logic is not gated by the comms-OK signal.

The shop floor reality: each of Mixed Logic, BG Logic, Macros, and Condition Monitor has a job it is good at. Use the wrong one and you either get a downstream alarm or behaviour that drifts in production.

Most common causes, in order of probability

1. Mixed Logic line too complex for in-motion execution. Mixed Logic is for single simple comparisons that need to evaluate during motion (e.g., IF DI[3], DO[5]=ON). Stack three conditions and you get unpredictable timing. The Mixed Logic option manual is explicit about the constraint.
2. Background Logic disabled or not configured. The customer assumes BG Logic is running because someone wrote a BG-style program, but MENU > SETUP > BG Logic shows the slot is empty. A DIY Robotics community thread on “Program Timer not running” documents exactly this misconception (reference).
3. Macro called from a hot motion path. Macros are designed for HMI buttons (a few lines, fast, returns immediately). A macro that launches a long motion sequence behaves erratically because it is on the UI thread. The robot-forum thread “FANUC with SK7 starting Macro” gives a clean example of using a macro the right way (group mask, digital output, no motion) (reference).
4. Condition Monitor not used where it would be correct. Condition Monitor fires a programmed action when an IO changes state during motion, without modifying the running motion line. Most cases people try to solve with Mixed Logic actually want a Condition Monitor.
5. BG Logic doing work it cannot do. A robot-forum thread bluntly notes that some TP instructions are not legal in BG Logic, and the alarm message is not always helpful (reference). Motion instructions, full path coordination, and a handful of register operations are restricted.

How to diagnose in under 10 minutes

Step 1. Identify what is supposed to run in parallel with motion. Is it a single IO comparison? Mixed Logic candidate. A continuous status update (alarm flag, conveyor running)? BG Logic candidate. A response to an IO change during motion? Condition Monitor candidate. An HMI button shortcut? Macro candidate.

Step 2. Open MENU > SETUP > BG Logic. Read the running task list. If it is empty, no BG Logic is executing. Bench tests of BG Logic that work in T1 but not in AUTO often fail because the BG task is not assigned to AUTO start.

Step 3. Read the alarm log if behaviour is wrong. INTP-254 means a parameter name in your code does not exist. INTP-258 means a weld port access error and is unrelated to logic structure (mentioned in the manual). PRIO-620 means an IO reference is offline.

Step 4. For Macros, check MENU > SETUP > Macro. Each macro is bound to a button or UI signal. Confirm the binding is what you expect.

Step 5. For Condition Monitor, open the relevant motion program and look for WHEN conditions inline with motion lines. Condition Monitor is part of the motion program, not a separate task.

How to fix it

For Mixed Logic that is too complex:

Move the complex part to BG Logic. Leave only a single comparison in the Mixed Logic line, or remove Mixed Logic entirely and let BG Logic drive the IO. A DIY Robotics community thread on “Starting a Robot by an output button” shows the right pattern: BG Logic maps UI signals to flags, and the main program reads flags (reference).

For BG Logic that is not running:

MENU > SETUP > BG Logic. Add the task. Set “AUTO start” so it runs on power-up, not just when manually launched. Save and cycle power. The task list should show your program as running.

For BG Logic that is doing too much:

Split it. BG Logic prefers small focused tasks. A monolithic 200-line BG program is harder to debug and more likely to trip on a restricted instruction. Multiple 20-line BG tasks are cleaner.

For a Macro driving a long motion:

Restructure. The macro should do nothing but CALL my_motion_program and return. The motion program runs in its own group with its own ownership. This avoids macro-thread timing problems and lets the motion program use the full TP feature set.

For a Condition Monitor not used:

Replace the Mixed Logic + motion combination with a Condition Monitor instruction. The syntax (CMR[n] and the WHEN keyword) is documented in the FANUC TP Programming manual. The benefit is that the IO response is independent of the motion line execution.

For digital output on alarm or UO state:

Use BG Logic. A clean pattern is documented in the DIY Robotics community: “You can make a BG logic program with DO XX = UO 6 Fault” (reference). One line of BG Logic and the panel light always reflects the alarm state.

When to call a specialist

Two situations are worth a service call:

You have inherited a cell where someone used Mixed Logic, BG Logic, and Macros interchangeably and the behaviour is hard to predict. Untangling that is a programming audit. We do this routinely and the deliverable is a documented map of who runs what and when.

You need to add a safety-critical IO response during motion (light curtain mute, force-sensor pause, vision-driven re-plan). That is Condition Monitor territory at minimum, often with a DCS Safe IO mapping behind it. Wiring it up without the safety design is how cells end up with intermittent behaviour the auditor will not certify.

contact us for a programming review, or schedule a maintenance preventive visit so the BG Logic and Macro inventory is documented alongside the mechanical maintenance.

Related errors to check

• INTP-254 Parameter not found: parameter referenced in code does not exist on this firmware. Most common in Mixed Logic and BG Logic.
• PRIO-620 PNIO(C) station deactivated: BG Logic is polling an offline fieldbus device. Gate the BG read with the comms-OK signal.
• PROG-040 Already locked by other task: BG Logic tried to drive motion, or a macro launched a motion program while another was running.
• INTP-105 Run request failed: a macro tried to start a TP program that has no motion ownership available. Read the cause code.

Probot Systems is a FANUC integrator based in Lévis, Quebec serving Canada and the US. We design Mixed Logic, BG Logic, Macro, and Condition Monitor structures for every cell we deliver, and rework them on customer cells where the original integrator picked the wrong tool. If your parallel behaviour is unpredictable, that is a contact us conversation.