Forcing Variables on Siemens S5-95F with STEP 5 FORCE VAR

S5-95F Failsafe Architecture: Why Forcing Is Different

The SIMATIC S5-95F (6ES5 095-8MFxx series) is the failsafe variant of the S5-95U compact programmable controller. Where the 95U is a single-channel compact PLC aimed at general machine control, the 95F was engineered for hazardous processes—burner management, press safeguards, emergency-stop loops, and similar SIL-rated applications. To satisfy those requirements the 95F integrates two processor channels and a redundant I/O periphery inside a single compact housing, so that a single CPU fault, a welded relay contact, or a shorted output cable cannot drive the machine into an unsafe state on its own.

For a commissioning or maintenance engineer, this dual-channel architecture has a direct, practical consequence: variable forcing—the act of overwriting an input, output, flag, or timer value from the programming device to simulate a field condition—behaves differently on the 95F than on the 95U. The S5-95F Programming Manual (Siemens order number 6ES5 998-1MF23) dedicates Chapter 14 to test and service functions, with Section 14.1.3 covering the FORCE VAR function and the mode-dependent write permissions that govern it, and Section 14.1.4 covering the search function used to locate symbols and absolute operands in the live controller.

The manual documents three operating modes, each of which has a different effect on the force capability of the programmer. The remainder of this reference reconstructs that procedure, explains the mode transitions required to enable forcing, and documents the safety interlocks a field engineer must respect when a 95F leaves safe mode for any reason.

Operating Modes: Safe, Quasi-Failsafe, and Test

The 95F recognizes three run-time operating modes that govern the integrity checks it performs every cycle. The same three modes also govern whether a programmer can write to the process image, the flag word, or the timer/counter word area. The mapping is fixed by firmware and is documented in Section 14.1.3 of the S5-95F manual.

The mode is held in a non-volatile mode byte on the 95F CPU and is signalled back to STEP 5 in the status header of every PLC status request. Any attempt to write a forced value from the programmer while the mode byte indicates SAFE or QUASI-FAILSAFE results in a NAK on the programmer port—the value is not written and a 0x0E status code is returned to the PG.

Why Forcing Requires Test Mode (Safety Architecture)

In SAFE mode, the 95F runs a two-channel comparison on every safety-relevant operand—input word, output word, flag word, and timer word—every scan. If channel A and channel B disagree, the offending safety output is forced OFF within a single cycle and an entry is written to the diagnostic buffer (see Section 14.2 of the manual). The forced-OFF state is latched until the next cold restart.

If a programmer were allowed to overwrite a safety input or output while the 95F was in SAFE mode, the firmware would have no way to tell the difference between "engineer overrode the signal" and "a real cross-check disagreement". Either way, channel A and channel B would produce different bit patterns, and the 95F would interpret that as a hardware fault and trip the safety outputs. The controller would be in a guaranteed-shutdown state within milliseconds, with no recovery path short of a mode switch.

For this reason, FORCE VAR is implemented as a write that is only legal in TEST mode, where the cross-check itself is disabled. The trade-off is explicit: in TEST mode the 95F performs no cross-check whatsoever, and the operator is solely responsible for not commanding an unsafe actuator state. Test mode is a documented degraded state, not a normal operating mode.

Prerequisites Before Forcing

Before launching the FORCE VAR dialog in STEP 5, verify the following:

1. Programmer connection. Connect the PG (e.g., PG 685, PG 710, PG 720, PG 740, or a modern PC with a CP 5210 / CP 5410 / TI505-compatible serial converter) to the 95F's PG port using a 15-pin or 25-pin Siemens programming cable. The line must be configured for the 95F's baud rate (default 9600 bit/s, 8 data bits, even parity, 1 stop bit for the 95F series).
2. STEP 5 project on disk. Load the current S5 project file (\*.S5D) that matches the program resident in the 95F. The symbol table and block list of the online project must be byte-for-byte consistent with the offline project, or the FORCE VAR dialog will not display the same names you expect.
3. PLC type and firmware match. Confirm the CPU type setting in STEP 5's PLC > PLC Type dialog. For the 95F, select S5-95F (not S5-95U). The 95U profile will not display the SAFE/QUASI-FAILSAFE/TEST mode fields and will silently allow writes that the 95F firmware rejects.
4. Operator authorization. The 95F password system supports a hierarchy: level 1 (read status), level 2 (read/write data blocks), level 3 (write program blocks), level 4 (mode switch). Be logged in at the level required to alter the mode byte—typically level 4.
5. Mechanical safety state. As covered in the preceding section, verify the driven process is in a safe, de-energized, or guarded state before any mode change.

STEP 5 FORCE VAR Procedure

The FORCE VAR function is invoked from the STEP 5 menu path Test > Force Var (in older STEP 5 versions, PLC > Force). The procedure is identical regardless of whether the target operand is an input (I), output (Q), flag (F), timer (T), or counter (C).

1. Switch the 95F to TEST mode. From STEP 5, choose PLC > Mode, select TEST, and click OK. The mode change is acknowledged by the 95F; the status line in STEP 5 will display RUN-T or STOP-T depending on whether the 95F was already executing OB 1 at the time of the switch.
2. Open the FORCE VAR dialog. Choose Test > Force Var. The dialog presents a four-column table: Operand, Symbol, Display, and Force Value. The current live value of each operand is shown in the Display column.
3. Enter the operand. Type the absolute address (e.g., IB 12 for input byte 12, QW 4 for output word 4, FW 100 for flag word 100, T 5 for timer 5) into the Operand column, or double-click the row and pick from the symbol table.
4. Enter the forced value. For bit operands, type 1 or 0. For byte/word/double-word operands, type the value in hex (16#F0A3) or decimal (61595) according to the dialog's current display base. The dialog also accepts the syntax 2#1010_1100 for binary forcing.
5. Apply the force. Press the Force key (F4 in the default STEP 5 keymap) or click the Force button. The 95F returns an ACK (0x06) on success or a NAK with an error code on failure.
6. Confirm the force visually. The Display column updates to show the forced value; the row is also marked with a small "F" indicator in the leftmost column of the FORCE VAR dialog.

Forces are cumulative. If you force IB 12 = 16#FF and then later force I 12.0 = 0, the 95F applies both overrides simultaneously. The single-bit force does not cancel the byte force on the same operand; both take effect and the most restrictive (in 95F firmware convention, the explicit single-bit zero) wins on the affected bit position.

Operating Mode Switch Procedure (Field Sequence)

The mode switch is the most safety-sensitive part of any 95F forcing session. Use the following field sequence, which mirrors the procedure in Section 14.1.2 of the S5-95F manual.

1. Place the driven machine in a safe state via hardwired interlocks (E-stop, guard doors, energy isolation).
2. Open STEP 5 and establish online connection to the 95F (PLC > Connect Online).
3. Read the current mode from the status bar. If the mode is already SAFE, record the current diagnostic buffer state for later comparison.
4. Choose PLC > Mode > Test. STEP 5 prompts for the level-4 password; enter it.
5. The 95F performs a controlled stop, drops the safety outputs, and re-enters the run-time loop with cross-checking disabled. The status line changes to RUN-T.
6. Begin the FORCE VAR procedure described in the previous section.

To leave test mode, the 95F must be commanded back to SAFE explicitly; it will not auto-revert. The reverse sequence (TEST → SAFE) requires a fresh operator authentication and clears all outstanding forces in the process image.

Forcing Standard I/O (Non-Safe Signals)

For non-safety inputs and outputs (the 95F's standard I/O is mapped to byte addresses outside the dedicated safety image), forcing follows the standard STEP 5 procedure described above. The most common use cases on a 95F are:

• Simulating a permissive input (e.g., "burner ignition proven") to verify a downstream sequence.
• Driving an actuator output to confirm field wiring and rotation direction without a live process input.
• Pre-loading a counter or timer to skip long integration cycles during a fast commissioning checkout.

For these standard I/O forces, the 95F imposes no additional restrictions beyond the TEST-mode requirement. The forced value is held in the process image until the force is explicitly cleared or the controller is taken out of TEST mode.

Forcing Safety-Related I/O: Hard Restrictions

The 95F's safety inputs and outputs are mapped to a fixed pair of byte ranges on the I/O bus (see the hardware section of the 6ES5 998-1MF23 manual for the exact address range, which varies by I/O module order number). On these addresses, additional restrictions apply even in TEST mode:

• Safety outputs cannot be latched forced high. A forced 1 on a safety output is held for one scan only. The firmware applies a watchdog that drops the output to 0 at the end of every cycle, regardless of the force. This is intentional: it prevents a programmer-induced override from keeping a safety output energized indefinitely.
• Safety inputs require dual-channel agreement on the next SAFE restart. A forced safety input is not propagated into the dual-channel comparison table. When the 95F re-enters SAFE mode, the comparison will run on the actual field state, not on the force, and the controller will trip if the two channels do not agree on the unforced value.
• Forces on safety addresses are not retained across a cold restart. Cold restart (power cycle) clears the force table for the entire process image, including the safety range.

These restrictions are documented in the 6ES5 998-1MF23 manual at the start of Chapter 14 and are the reason Siemens requires the 95F to be returned to SAFE mode for any production-relevant validation.

Verification: Reading Forced Values Back

After applying a force, verify it has taken effect by reading the same operand back through a different tool. The following three checks are standard field practice:

1. STATUS request. From STEP 5, use PLC > Status (or Test > Status Variable) on the same operand. The displayed value must match the force you entered. If it does not, the force was rejected and you will see the live field value instead.
2. Process image monitor. Open the Monitor window (Test > Monitor) and confirm the operand in the running OB 1 displays the forced value. The monitor reflects what the application code actually sees, which is the value the cross-check would have used had the controller been in SAFE mode.
3. Field measurement. For output forces, measure the voltage or current at the field terminal with a calibrated meter. For input forces, disconnect the field device and confirm the controller continues to read the forced value. The field measurement is the only check that proves the force survived the path from process image to physical terminal.

Restoring Safe Operation

When commissioning or diagnosis is complete, return the 95F to SAFE mode as follows:

1. Open the FORCE VAR dialog and click Delete All (Shift+F4). The 95F clears all outstanding forces and returns the process image to the field-driven value.
2. Verify each previously forced operand has returned to its expected live value via Status or Monitor.
3. Choose PLC > Mode > Safe and authenticate with the level-4 password.
4. The 95F performs a self-test, re-establishes the cross-check between channels A and B, and resumes dual-channel operation. The status line displays RUN-SAFE.
5. Capture a fresh diagnostic buffer snapshot (PLC > Diagnostics > Read Buffer) and compare it to the pre-test snapshot to confirm no faults were logged during the test session.
6. Remove the mechanical safe-state barriers and re-energize the process under the normal production sequence.

Troubleshooting Matrix

Field-Commissioning Caveats and Best Practices

Several field-proven caveats apply when forcing a 95F in production environments:

• Document every force. Maintain a paper or electronic log of the operator, the time, the operand, the forced value, and the justification. The 95F does not write a "force applied" entry to the diagnostic buffer, so the log is the only durable record.
• Cap the test session. The 95F allows TEST mode to be held indefinitely, but the longer TEST mode is held, the more opportunities for an unsafe command. Use a one-hour cap as a default and require supervisor re-authorization for extensions.
• Force flags, not inputs, where possible. On a 95F, forcing an input changes the field state in the process image but the dual-channel input module itself is unaffected. Forcing a flag that the application code consults downstream of the input has the same effect on the logic and is easier to clear at the end of the test.
• Re-enter SAFE before any program change. A block download (FB, PB, OB, DB, SB) is only permitted in STOP, not in TEST. Plan the session so all forcing is completed, all forces are cleared, and the 95F is back in SAFE mode before any block download is initiated.
• Use STEP 5's search function for unknown operands. The S5-95F manual's Section 14.1.4 documents the search function inside the FORCE VAR dialog, which lets you locate a symbol or absolute operand across the loaded blocks. This is the fastest way to confirm whether a given tag is referenced by the active program before forcing it.
• Confirm the firmware version. The 95F shipped with several firmware revisions. Earlier revisions reject single-bit forces on flag words; later revisions accept them. Use PLC > Information > Module Information to read the firmware version, and refer to the firmware release notes for that revision before relying on a specific force syntax.

FAQ