Siemens S7 M4.4 Coil Turns ON Without Command STEP 7

Problem Overview

A classic symptom reported on Siemens S7-300/S7-400 PLCs programmed with STEP 7 (Classic, V5.x) is that a memory bit (merker / flag) such as M4.4 appears as energized (ON / TRUE) in the online monitor even when the rung preceding its coil evaluates to FALSE. The reported case shows M4.4 with a single visible coil in Network 17, no apparent driving logic, and the rung input evaluating to FALSE in the ladder view, yet the bit is shown as ON in the LAD/FBD/STL monitor.

This article consolidates the diagnostic path that resolves the four most common root causes:

1. Overlapping memory access between bit, byte, word, and double-word symbols mapped onto MB4 / MW4 / MD4.
2. Indirect STL addressing in another block writing the bit through pointer arithmetic.
3. Process Mode (vs. Test Mode) on the CPU limiting the monitoring view.
4. Cross-block writes from FB / FC / OB routines that are not visible in the local network monitor.

The bit number 4 in byte 4 means it is the fifth bit (counting from 0) of memory byte 4. Any symbolic or absolute access to MB4, MW4, MD4, or even a misaligned access through a different merker area can overwrite it.

S7 Memory Bit Architecture and the M Area

The merker (M) area in S7-300/S7-400 CPUs is a volatile, byte-addressable region of internal flags held in work memory. The default size is 256 bytes (MB0–MB255), configurable per CPU model:

The key architectural property relevant to this fault is that all sizes in the M area share the same physical byte. Accessing M4.4, MB4, MW4, or MD4 reads or writes the same bit. This is by design — STEP 7 allows multi-width access for efficiency — but it produces surprising results when one developer writes a byte while another reads individual bits.

Writing 1 to MB4 sets all eight bits of byte 4 (M4.0 through M4.7) to 1, regardless of any rung that should be controlling M4.4 individually. The same applies to any write to MW4 or MD4 — the lower byte of those operands is MB4.

Root Cause 1: Overlapping Memory Access

The first check is to verify that no other part of the program — in any block, any network, any language (LAD, FBD, STL, SCL, GRAPH) — writes the parent byte of M4.4. In STEP 7 this is done through the menu path:

Edit > Overlapping access to memory areas

Or by opening the cross-reference and inspecting every occurrence of MB4, MW4, and MD4. The check is not limited to the current block; it must cover all blocks in the S7 program (OB1, OB35, OB100, all FBs, all FCs, all DBs with symbolic references).

Typical overlapping patterns that trigger the symptom:

// STL fragment in FC12 writing MB4
L 0
T MB4          // Clears M4.0 through M4.7

// STL fragment in OB100 (warm restart) presetting M4.4
SET            // RLO = 1
S M 4.4        // Set bit M4.4 unconditionally

// LAD network in FB20 setting MW4
[ MW4 := W#16#0010 ]   // Bit 4 of MW4 = M4.4 forced to 1

Any of these — even in OB100, OB101, OB102, an alarm OB (OB40), or a cyclic interrupt OB (OB35) — will set the bit for at least one cycle, and depending on retentivity may keep it set permanently. Refer to the Siemens STEP 7 V5.x Online Help – Overlapping Access to Memory Areas for the scanner's exact scope.

Verification Steps

1. Open SIMATIC Manager.
2. Right-click the S7 program node.
3. Choose Overlapping access to memory areas.
4. Review the result list. Each entry shows the block, network, and access type.
5. Resolve every entry pointing at MB4, MW4, or MD4 unless the overlap is intentional and documented.

Root Cause 2: Indirect STL Addressing in Another Block

If overlapping access returns no results, the next candidate is indirect addressing. In STL (Statement List), a programmer can compute an address at runtime through a pointer in a memory word or double word. This makes the write invisible to a static cross-reference scan unless pointer tracking is explicitly performed.

Common indirect patterns:

// Loop fragment writing through a pointer
OPN DB [AR1,P#0.0]      // Open DB from pointer
L  B [AR2,P#4.0]        // Indirect byte read
T  MB [MW100]           // Indirect byte write — destination computed at runtime

// Area-crossing pointer manipulation
LAR1  P#M 4.0            // Load pointer pointing to M4.0
U   M [AR1,P#0.4]        // Read M4.4 indirectly
S   M [AR1,P#0.4]        // Set M4.4 indirectly

// FC parameter of type POINTER
L   P##Input_Ptr
LAR1
U   M [AR1,P#0.0]        // M4.4 accessed via pointer passed from caller
=   M [AR1,P#0.0]

Because the operand is computed at runtime, the cross-reference list does not show M4.4 as an access point. The only way to find it is to manually audit any code path that uses AR1, AR2, or a DBW/DMW as a pointer, then mentally trace the pointer value to confirm whether it can equal P#M 4.0 with a bit offset of 4. The Siemens S7-300/400 STL Programming Reference documents the addressing modes and their pointer semantics.

Audit Checklist for Indirect Addressing

If the project was developed partially in STL and partially in SCL, SCL compiled code also uses AR1/AR2 internally for #Temp variable access. Forcing a breakpoint and watching AR1/AR2 in the data view of the STL block is the fastest way to confirm whether the running pointer equals P#M 4.0 at the moment of interest.

Root Cause 3: Process Mode vs. Test Mode

STEP 7 supports two online modes for the CPU that govern monitoring behavior:

In Process Mode, the status display in the active block can lag behind the actual scan. The "command not ON" observation in Network 17 may simply reflect a snapshot of the RLO captured at the start of OB1, while the bit was set elsewhere between the snapshot and the visual refresh. More importantly, Process Mode on S7-400 CPUs may show only the block currently being executed — for example, if FC50 writes M4.4 in network 8 and OB1 then calls FC100 which executes network 17 of FC100 (the user's reported network), the user is monitoring FC100 but the set came from FC50.

To switch modes:

1. Open the online view of the S7 program.
2. From the menu bar, choose PLC > Operating Mode (or right-click the CPU in SIMATIC Manager and choose Operating Mode).
3. Select Test Mode.
4. Confirm the prompt about losing online connections to other stations.

After switching to Test Mode, the status displays refresh on every scan, and breakpoints can be set. This often resolves the symptom because it forces a cleaner view of the RLO state. Refer to the Siemens S7-300 CPU 31xC – Operating Modes Technical Data for the firmware-specific behavior of your CPU.

CPU-Specific Note

The behavior of Process Mode versus Test Mode varies slightly across the S7-300 and S7-400 families. S7-300 CPUs always run in a single mode selected by the configuration; S7-400 supports runtime switching between Process and Test mode without restart. The current mode is displayed in the SIMATIC Manager online view and is identified in the diagnostic buffer of the CPU.

Root Cause 4: Cross-Block Writes (OB, FB, FC, DB)

Even with overlapping access excluded and indirect addressing ruled out, the bit may be written in:

• OB1 (the cyclic main) in a network not visible in the monitored block.
• OB35 or another cyclic interrupt OB running at a fixed interval independent of OB1.
• OB40–OB47 (hardware interrupt OBs) triggered by an I/O event.
• OB100 (warm restart), OB101 (hot restart), OB102 (cold restart).
• Time-of-day OBs (OB10–OB17).
• FB instance data blocks (if the bit is mistakenly aliased to a merker through the FB's STAT or TEMP section).

The cross-reference tool resolves these quickly:

In LAD/FBD/STL editor:
Menu > Options > Cross-References   (Ctrl+Alt+F7)

Or via SIMATIC Manager:

Right-click block > Cross-References

Filter the result for the symbol M4.4 or the absolute address M 4.4. Every occurrence is listed with block name, network, and access type (R = read, W = write, RW = read/write, ? = unresolved). Anything other than the single coil observed in Network 17 indicates the bit is driven elsewhere.

Diagnostic Procedure: Step-by-Step

Follow this sequence in order. Each step rules out one root cause before proceeding to the next.

Step 1 — Open the Overlapping Access Check

1. Start SIMATIC Manager.
2. Open the S7 program node (e.g., "S7 Program(1)").
3. Menu: Edit > Overlapping access to memory areas.
4. Wait for the scan to complete.
5. Filter results for MB4, MW4, MD4.
6. Document every entry: block, network, statement, and access type.
7. For each entry, decide whether the access is intentional and benign, or whether it must be corrected.

Step 2 — Build the Cross-Reference

1. Right-click the M4.4 coil in Network 17.
2. Choose Go to > Cross-Reference or press Ctrl+Alt+F7.
3. The cross-reference window lists every block, network, and access type where the operand appears.
4. If only the single coil in Network 17 is shown, no other block uses the bit by absolute address.
5. If multiple entries exist, jump to each one and evaluate whether it is intended.

Step 3 — Scan for Indirect Addressing

1. Search the entire project for STL blocks (file extension .AWL).
2. Open each STL block and search for patterns containing: AR1, AR2 with M operand prefix, MW or MD used as index registers, P##, LAR1, LAR2, +AR1, +AR2, -AR1.
3. For each match, mentally trace the pointer value at the moment of the access.
4. If the computed pointer equals P#M 4.0 with bit offset 4, the indirect write is the cause.

Step 4 — Switch to Test Mode and Re-monitor

1. Connect online to the CPU.
2. Menu: PLC > Operating Mode > Test Mode.
3. Re-open the block containing Network 17.
4. Watch the status of M4.4 across multiple OB1 scans.
5. If the bit now behaves as expected (stays OFF), the previous observation was a Process Mode artifact.

Step 5 — Use a Variable Table (VAT) for Authoritative View

The variable table bypasses the block-level monitor entirely:

1. In SIMATIC Manager, open S7 Program(1) > Blocks.
2. Insert a new Variable Table (VAT).
3. Add the operand M 4.4 with display format BOOL.
4. Add MB 4, MW 4, MD 4 for context.
5. Click the Monitor button (glasses icon) to start continuous monitoring.
6. The values shown in the VAT are read directly from the CPU's process image and are not subject to the block monitor's refresh rules.

If the VAT shows M4.4 as TRUE while MB4 / MW4 / MD4 are non-zero in the same cycle, the write is genuine. If only M4.4 shows TRUE and the parent byte is zero, a single-bit write has occurred somewhere (confirm via cross-reference).

Step 6 — Use a Trigger and Force Table

If a non-invasive breakpoint is needed:

1. Open an existing VAT or create a new one with M4.4.
2. Right-click the operand row and choose Trigger.
3. Configure trigger conditions: address, condition (==TRUE / ==FALSE), trigger event (single scan, cyclic).
4. The trigger freezes the CPU in a controlled stop after the condition fires, allowing post-mortem inspection of STL pointers and merker contents.

Avoid the Force function unless absolutely necessary. Forcing M4.4 forces the bit on the CPU regardless of program logic. Forcing should be used only when the diagnostic cannot be completed in any other way, and it must be cleared before returning the system to production. Forced values persist across CPU restarts on S7-400 and require explicit removal.

Diagnostic Decision Matrix

Using Cross-References Effectively

The cross-reference tool is the single most powerful diagnostic for this class of fault. In STEP 7 V5.x, the tool can be invoked from:

• LAD/FBD/STL editor: Options > Cross-References (Ctrl+Alt+F7)
• SIMATIC Manager: Right-click the program node, then Cross-References
• Symbol table: Right-click a symbol, then Cross-References

The result window has four columns:

Filter the result for any access type other than the single coil in Network 17. Sort by access type — all W and RW entries are writes that must be investigated.

Indirect Addressing Caveat

The cross-reference scanner resolves static addressing only. As discussed in Root Cause 2, indirect addressing through AR1/AR2 or via OPN DB [MWx] is flagged as ? (unresolved). Double-click the ? row to jump to the code and inspect manually. For a deeper explanation, see the Siemens S7-300/400 STL Programming Reference.

Using Variable Tables (VAT) for Debugging

The variable table is the most authoritative online diagnostic tool because it reads directly from the CPU's internal state without going through the block monitor's buffering. Key features:

• Monitor: Continuous update of all listed operands each scan.
• Modify: Write a single value to a single operand once.
• Force: Force one or more operands to fixed values, overriding program logic.

For this fault, use Monitor (not Force) to observe M4.4, MB4, MW4, and MD4 simultaneously. Adding the parent byte/word/dword makes it immediately obvious whether the bit is set alone (direct bit write) or as part of a wider access.

To enable address register monitoring, the CPU must be in Test Mode, and the VAT must include the special operand names AR1 and AR2.

Verification

After applying the fix, perform the following to confirm the bit behaves correctly:

1. Cold restart simulation: Power-cycle the CPU (or use PLC > Clear/Reset) and bring the system to a known state. Verify M4.4 stays FALSE through startup.
2. Cross-reference re-scan: Run the cross-reference tool. The single coil in Network 17 should be the only entry for M4.4, or all other entries must be intentional and documented.
3. Overlapping access re-scan: Run Edit > Overlapping access to memory areas. Confirm no unaddressed overlap remains.
4. VAT monitor: Monitor M4.4 in a variable table for at least one full process cycle. The bit must remain FALSE.
5. Process Mode verification: Switch the CPU back to Process Mode. Re-monitor. The bit must remain FALSE.
6. Indirect addressing audit: For any STL block that previously used indirect addressing, add a comment documenting the maximum pointer range to prevent future regressions.

Notes on Safe Handling of Forces

Summary

A merker bit appearing ON without an apparent driving rung is one of the most common STEP 7 mysteries, and it has a structured diagnostic path:

1. Run the overlapping-access check to find any byte/word/dword write that covers M4.4.
2. Build a cross-reference and verify that Network 17 is the only write point.
3. Audit STL blocks for indirect addressing through AR1/AR2 or memory-word pointers.
4. Confirm the CPU is in Test Mode for accurate monitoring.
5. Use a VAT as the authoritative read source.
6. Apply the fix, then re-run the verification cycle.

When the symptom is fully resolved, document the cause in the block header comment so the next engineer does not repeat the investigation. For the broader context of merker use in modern S7-1500 / TIA Portal projects where M-area overlap is more strictly checked at compile time, see the Siemens Programming and Operating Manual for guidance on migrating or refactoring legacy M-area logic.