CQM1 Subroutine Programming: Scan Time Optimization Guide

Overview

The Omron CQM1 programmable controller family (CQM1, CQM1H) is a compact PLC platform widely deployed in machine and process applications. One of the most common engineering questions when commissioning a CQM1 ladder program is: how should subroutines be structured to keep scan time under control? Subroutines are not free — they require stack management, call/return overhead, and indexed dispatch. Used correctly, however, they can dramatically shorten average scan time by allowing large blocks of code to be skipped when not needed. Used incorrectly, they add overhead and lengthen every cycle.

This reference consolidates field-tested techniques for structuring CQM1 programs around SBS (Subroutine Call), SBN (Subroutine Begin), and RET (Return) instructions, with concrete guidance on:

• Conditional call patterns that gate execution on state
• First-scan initialization via subroutines
• DIFU / DIFD one-shot call gating
• Self-clearing call bits
• Comparison of subroutine calls vs. JMP/JME jumps
• Stack and nesting limits on the CQM1 CPU

CQM1 Subroutine Instruction Set

The CQM1 ladder instruction set provides three core subroutine instructions:

Up to 256 subroutines may be defined per program (numbers 0–255). The CQM1 supports a call stack depth of 8 nested subroutine levels; exceeding this raises the Subroutine Stack Overflow flag in the AR (Auxiliary Relay) area and the program halts with an error. Always size nested call trees to stay well below this limit.

Subroutine Numbering Conventions

There is no required numbering order, but the following convention speeds up debugging in CX-Programmer:

• 0–9: Initialization (powered-up, first-scan, mode-change)
• 10–49: I/O handling and field-device processing
• 50–99: Sequencing and mode logic
• 100–199: HMI/communications marshalling
• 200–255: Alarms, diagnostics, and fault recovery

Why Subroutines Affect Scan Time

A CQM1 scan consists of four phases: common processing, program execution, I/O refresh, and peripheral servicing. The program-execution phase walks the ladder from top to bottom, and any code in that walk consumes time. Three execution-cost rules govern subroutine design on the CQM1:

1. Skipped code is free. If a rung is not reached, it does not execute. Therefore any code that can be placed behind a conditional SBS — and not called — does not contribute to scan time.
2. Every SBS has a fixed overhead. Pushing the return address, validating the subroutine number, and dispatching the jump cost a few microseconds per call. The RET also costs stack-pop time. Routine on the CQM1 measures this at approximately 10–25 µs per SBS+RET pair, depending on the CPU variant (CQM1-CPU11/21 vs. CQM1H-CPU51).
3. Calls inside the main loop always execute. An unconditional SBS in the main scan that runs every cycle adds its overhead every cycle. If the called code runs every cycle anyway, inlining it removes the dispatch cost.

The net optimization rule is therefore: use subroutines when a block of code is sometimes needed and sometimes not, and skip the call entirely when it is not needed. Use inlined rungs when the code runs every cycle.

Pattern 1 — First-Scan Initialization Subroutine

The most common CQM1 subroutine pattern is the initialization subroutine, called only on the first scan after entering RUN mode. The CQM1 First Cycle flag is SR 25315; it is ON for exactly one scan after the CPU transitions to RUN or MONITOR.

 |  SR 25315           SBS  0
 |--------|/|----------| |
 |                                  (call init subroutine once)

 Subroutine 0: SBN 0
 |  First pass setup rungs here
 |  Initialize counters, clear working bits,
 |  set up comms registers, etc.
 |  RET

This pattern is superior to placing initialization in the main scan because the main scan only pays the cost of the call once. The bulk of the program can be organized as a series of conditional SBS calls, with initialization isolated to a single subroutine that runs for one scan and is then dormant for the life of the program.

Pattern 2 — Conditional Calls on State

A well-structured CQM1 main scan is typically short, with each rung calling a state-specific subroutine:

 |  W0.00 (Auto)     SBS 10
 |--------| |---------| |
 |  W0.01 (Manual)   SBS 11
 |--------| |---------| |
 |  W0.02 (Fault)    SBS 12
 |--------| |---------| |
 |  W0.03 (HMI Upd)  SBS 20
 |--------| |---------| |

In this example, only the routines needed for the active mode are dispatched. The fault routine, manual routine, and HMI routine are entirely skipped when not relevant. In an 8-mode machine this can reduce a 15 ms main scan to 2–3 ms by leaving the heavy subroutines dormant.

Pattern 3 — DIFU/DIFD One-Shot Gating

To invoke a subroutine for exactly one scan — for example, to trigger a serial-port message, to copy a value, or to debounce an event — combine a DIFU (Differentiation Up, instruction 13) or DIFD (Differentiation Down, instruction 14) with an SBS:

 |  Trigger            DIFU  W0.10
 |--------| |----------|---|
 |  W0.10              SBS  30
 |--------| |----------| |

DIFU turns its output ON for the single scan in which its input transitions from OFF to ON. The subroutine executes once and is then idle. This is the CQM1 equivalent of the Allen-Bradley OSR (One-Shot Rising) and the Siemens FP/Edge-detection.

Pattern 4 — Self-Clearing Call Bits

An alternative to DIFU is the self-clearing call bit: the subroutine itself resets the bit that called it. This avoids the need for a separate one-shot rung and guarantees a single execution:

 Main scan:
 |  W0.20 (Send Msg)  SBS 40
 |--------| |----------| |

 Subroutine 40:
 |  SBN 40
 |  ... send message logic ...
 |  RSET  W0.20   (clears the call bit before RET)
 |  RET

Place the reset (or RSET) as the last rung before RET to ensure the bit is cleared before the return. This pattern is robust against the bit being re-asserted by external logic partway through the subroutine's execution.

Pattern 5 — JMP/JME vs. SBS/SBN

The CQM1 also supports JMP(04) N and JME(05) N jumps. The differences are summarized below:

Use JMP/JME when a single block of code at a single program location needs to be conditionally skipped. Use SBS/SBN when a routine must be invoked from multiple points or when you want a callable, named, organized module.

Scan Time Estimation Worksheet

Use the following table as a starting point to estimate program-execution time on a CQM1H-CPU51 (typical values; verify against your CPU's Operation Manual):

To estimate full scan: sum all instruction times, add I/O refresh and peripheral servicing, and you have the typical scan. A scan-time optimization goal is to keep the program-execution phase below 50% of the controller's allowed scan budget, leaving headroom for the other phases.

Step-by-Step Refactor Procedure

Use this procedure to convert an unstructured CQM1 program into a subroutine-organized program that scans faster:

1. Inventory the program. In CX-Programmer, export the ladder to a printout. Tag each block with a one-line purpose: init, mode-select, valve-control, alarm, comms, etc.
2. Identify always-on blocks. Any block that runs every scan and contains no conditional logic should stay in-line. Do not move it into a subroutine — that adds overhead with no benefit.
3. Identify rarely-on blocks. Mark each block with the condition that enables it (mode bit, state register, fault flag). These are candidates for conditional SBS calls.
4. Extract the initialization block. Find the rungs that should only run once. Move them to SBN 0 and add an SBS 0 gated by SR 25315 in the main scan.
5. Define the main scan. Reduce the main scan to a short sequence of conditional SBS calls plus the always-on glue logic (I/O marshalling, mode arbitration).
6. Add DIFU gates where single-scan calls are needed. Replace any set-then-clear-after patterns with a DIFU-gated SBS or a self-clearing call bit.
7. Verify nesting. Walk the call graph and confirm no chain exceeds 8 nested levels. CQM1 stack overflow halts the CPU.
8. Measure. Use the CQM1's built-in scan-time monitor or CX-Programmer's online scan display to compare before/after.

Verification

After the refactor, perform the following checks before returning the program to production:

1. Scan-time check. Place the controller in MONITOR mode and read the scan time in the CX-Programmer status bar. Compare to the pre-refactor baseline. A well-organized CQM1 program with conditional subroutines typically shows 30–70% reduction.
2. Watchdog margin. Confirm the cycle time is well below the CQM1's watchdog setting (default 100 ms, adjustable). Scan time should be less than 50% of the watchdog for a stable system.
3. First-scan test. Power-cycle the CPU and confirm the initialization routine runs once and the bits it sets are stable on subsequent scans.
4. Mode transitions. Force each mode bit ON individually and confirm the corresponding subroutine executes and its outputs behave correctly. Confirm outputs are held when the mode is OFF, not cleared — CQM1 subroutines do not automatically reset outputs that are not in their scope.
5. Fault recovery. Trigger a fault and confirm the fault subroutine is entered via its conditional SBS and that recovery logic properly re-enters the normal mode.
6. Stack integrity. Use a long-running stress test (1,000+ mode transitions) to confirm no stack overflow occurs. AR flags and CX-Programmer error log should remain clean.

Common Pitfalls

• Calling the same subroutine unconditionally from multiple sites. This multiplies overhead and risks of unintended re-entry. Use a single conditional call.
• Placing long math or table-comparison rungs in a one-shot subroutine. The first-scan call still costs the full execution time, just once. Consider initializing in stages.
• Forgetting that outputs in a skipped subroutine are held. If a valve was opened by Subroutine 10 and you switch to a mode that does not call Subroutine 10, the valve will not automatically close. Provide explicit shutdown logic.
• Exceeding the 8-level call stack. Nested subroutines that call subroutines that call subroutines will overflow on the CQM1. Flatten the call graph.
• Using DIFU for stylistic reasons. Each DIFU costs both execution time and IR memory. Use only when you need the edge.

FAQ