Managing I/O Faults on S7-1200 with GETIO/SETIO and OB86

Overview: I/O Fault Management on the S7-1200

When migrating a Profibus drive-control application from an S7-300 to an S7-1200, the I/O fault-handling strategy must be reworked. The S7-300's familiar DPRD_DAT and DPWR_DAT instructions that move entire consistent Profibus telegrams from a drive (for example, an ABB ACS / DCS-series Profibus adapter on an ET200S station) are not directly user-callable on the S7-1200 in the same way. The replacement approach is:

1. Install a Profibus master communications module (CM 1243-5, 6GK7243-5DX30-0XE0) on the S7-1200 to keep existing ET200S stations or Profibus drives wired in.
2. Disable the automatic peripheral-to-process-image update on the affected input and output ranges so the user program can decide what to do with the data.
3. Read the consistent telegram in a cyclic OB using the GETIO instruction (which internally calls DPRD_DAT) and write to the drive using SETIO (which internally calls DPWR_DAT).
4. Check the STATUS output of every GETIO/SETIO call and treat any non-zero value as bad data; this avoids the data-consistency window that an OB86 race can introduce.
5. Add an OB86 fault routine as a safety net to clear diagnostic events, prevent CPU STOP on rack/slave failure, and force peripheral-data bad flags.

The advantage of this approach: it decouples the data-consistency check from the interrupt-driven OB86 model. OB86 runs at priority class 26 and can interrupt OB1 mid-cycle. If your control logic only reads a "data is good" flag set by OB86, you can read stale good-flag state with bad data (or vice-versa) for at least one OB1 scan. The GETIO/SETIO model removes that race entirely.

Prerequisites

Hardware and Profibus Topology

The S7-1200 has no integrated Profibus interface, so the CM 1243-5 is mandatory for any Profibus DP master application. The module plugs into the left side of the CPU alongside signal modules and is addressed as a Profibus master at the configured node address (default 2, configurable in TIA Portal under the CM's properties > Profibus interface > Address). The CM occupies one slot in the S7-1200's signal board / module expansion area and counts against the CPU's maximum module count.

Wiring follows the standard Profibus DP conventions: shielded twisted-pair Profibus cable (typically violet) with bus terminators enabled at both ends of the segment. Maximum segment length depends on baud rate (1200 m at 9.6 kbps, 100 m at 12 Mbps). For multi-segment networks, repeaters are required.

In TIA Portal, after adding the CM, configure the Profibus network, set the master address, and drag the ABB drive's GSD device into the topology. The Profibus slave address of the drive determines the start address of its I/O area in the CPU. Typical configuration: ABB drive at Profibus address 4 occupies input bytes 100..111 (%IB100..%IB111) and output bytes 100..111 (%QB100..%QB111) when mapped via the CM 1243-5. The I/O area can be 4, 12, 20, or 24 bytes depending on the PPO type selected in the drive's configuration (covered in the worked example below).

Disabling Automatic Process Image Updates

For consistent data transfer (a whole Profibus telegram moved atomically), the standard automatic copy from the peripheral area to the process image must be disabled on the affected address range. The S7-1200 system manual describes this as removing the address from the "automatic process-image update" list, which the manual treats as a prerequisite for DPRD_DAT/DPWR_DAT usage.

In TIA Portal:

1. Open the device view of the S7-1200 CPU.
2. Select the CM 1243-5 or the slave's I/O area in the device configuration.
3. In Properties > I/O addresses, uncheck "Automatic update of process image" (or "Process image: automatic", depending on TIA version) for the input range that the drive occupies.
4. Repeat for the output range.

After this change, the CPU will not refresh the process image for that range automatically. The peripheral area (%I100:P) holds the most recent peripheral read and is updated by the next GETIO call. The standard process image (%I100) is updated only by your explicit program logic.

GETIO and SETIO Instructions

GETIO and SETIO are the S7-1200 / S7-1500 wrappers around DPRD_DAT and DPWR_DAT. They are the recommended way to access consistent data on distributed I/O without disabling the entire process image for unrelated inputs. The S7-1200 system manual lists them in the "Distributed I/O" instruction group and notes that the underlying DPRD_DAT/DPWR_DAT are still compiled into the program, so the on-wire behaviour is identical.

Block Interface (LAD / FBD)

GETIO / SETIO Return Codes

Any non-zero STATUS must be treated as "data is bad" by the application. The recommended pattern is to set a bad-data flag and skip processing of that range for the cycle.

Ladder Sample

      +--------+
--[EN]-+ GETIO  +---ENO--
      |        |
      | LADDR  |---W#16#64   // decimal 100
      | SLOT   |---B#16#0
      | RECORD |---P#DB100.DBX0.0 BYTE 11
      | STATUS |---%MW200
      +--------+

ST/SCL Sample (Cyclic OB1 Read and Write)

// Cyclic read of the ABB drive input telegram
IF "sim_mode" = FALSE THEN
    "drive_getio_status" := GETIO(LADDR  := 16#0064,    // 100 decimal
                                  SLOT   := 16#00,
                                  RECORD := "drive_in_buffer",
                                  STATUS => "drive_status");
    IF "drive_getio_status" = 0 THEN
        "drive_data_ok" := TRUE;
    ELSE
        "drive_data_ok" := FALSE;
        "drive_fault_id" := "drive_status";
    END_IF;
ELSE
    // PLCSIM mode: copy simulated input from the plant simulator DB
    "drive_in_buffer" := "sim_drive_in";
    "drive_data_ok"   := "sim_drive_data_ok";
END_IF;

SETIO is invoked the same way, but RECORD is the source buffer (your output telegram) and the data is written atomically to the peripheral. Use it for control words, setpoints, and reference values:

// Cyclic write of the ABB drive output telegram
IF "sim_mode" = FALSE THEN
    "drive_setio_status" := SETIO(LADDR  := 16#0064,
                                  SLOT   := 16#00,
                                  RECORD := "drive_out_buffer",
                                  STATUS => "drive_status_out");
    "drive_write_ok" := ("drive_setio_status" = 0);
ELSE
    "sim_drive_out" := "drive_out_buffer";
    "drive_write_ok" := TRUE;
END_IF;

OB86: Rack and Station Failure

OB86 is the S7-1200 / S7-1500 organisation block for rack failure, distributed I/O failure, and PROFINET IO station failure events. It is required if you want the CPU to remain in RUN when a Profibus slave drops off the network. Without OB86, a slave failure causes a diagnostic interrupt that the CPU cannot service and the CPU goes to STOP.

OB86 Temporary (Local) Variables

OB86_FLT_ID Values (subset relevant to S7-1200)

For the ABB drive scenario, expect FLT_ID = 02 (slave failure) when the drive drops off, and FLT_ID = 07 (slave return) when it comes back. The OB86_MDL_ADDR field will hold the logical base address of the failed station — in the typical mapping above, this is 100 (W#16#64) for the ABB drive at Profibus address 4.

OB86 Sample Code (SCL)

// OB86: Rack / Slave / Profibus station failure and return
// Purpose: mark drive data bad on slave failure, clear flag on return
// Note: this is a SAFETY NET. Primary data validity is checked
//       from GETIO.STATUS in OB1.

IF #OB86_EV_CLASS = B#16#38 THEN
    // Incoming event - a new fault has been detected
    CASE #OB86_FLT_ID OF
        B#16#02:  // Distributed I/O slave (Profibus DP) failure
            IF #OB86_MDL_ADDR = W#16#64 THEN
                "drive_comm_fault" := TRUE;
                "drive_data_ok"    := FALSE;
                "drive_fault_id"   := 16#0002;
            END_IF;
        B#16#10:  // CM 1243-5 interface failure
            "cm1243_5_fault" := TRUE;
            "drive_data_ok"  := FALSE;
        B#16#01:  // Central rack failure (less common on S7-1200)
            "rack_fault" := TRUE;
        ELSE
            "last_ob86_fault" := #OB86_FLT_ID;
    END_CASE;
ELSIF #OB86_EV_CLASS = B#16#39 THEN
    // Outgoing event - the fault has cleared
    CASE #OB86_FLT_ID OF
        B#16#07:  // Distributed I/O slave return
            IF #OB86_MDL_ADDR = W#16#64 THEN
                "drive_comm_fault" := FALSE;
                // Do NOT set "drive_data_ok" = TRUE here.
                // Let the next OB1 GETIO confirm data is good.
            END_IF;
        B#16#11:  // CM 1243-5 interface return
            "cm1243_5_fault" := FALSE;
        B#16#06:  // Rack return
            "rack_fault" := FALSE;
        ELSE
            ;
    END_CASE;
END_IF;

OB86 Interrupt Behaviour

OB86 is an interrupt OB at priority class 26. It can interrupt OB1 (priority class 1). The risk is that if your only data-validity mechanism is "set a bit in OB86, read it in OB1", you may read the bit one cycle too early or too late. The S7-1200 system manual recommends DPRD_DAT/DPWR_DAT (and by extension GETIO/SETIO) for applications that need a single consistent read with validity status returned synchronously.

The recommended pattern is therefore:

• OB1 uses GETIO/SETIO and checks STATUS for every cycle. This is the primary data-validity check.
• OB86 exists only to keep the CPU in RUN, log the event, and update a "last comm fault" diagnostic word. Do not make the safety logic depend on OB86 flag toggles.

Data Consistency Considerations

When OB86 fires for a slave failure, the CPU does not propagate the failure to your control logic until your next read. If your OB1 reads the process image (%I100 rather than %I100:P) and the image still contains the last good read, you can act on stale data. The window is short (one OB1 scan), but in motion or safety-related code it is significant.

GETIO reads the peripheral area directly and atomically. If the read fails, STATUS is non-zero and the data in RECORD is marked invalid. The instruction either returns a good read or a non-zero status — never a half-update. This is the property that DPRD_DAT had on the S7-300 and the property the S7-1200's GETIO preserves.

The key configuration that makes this work: the address range must be removed from the automatic process-image update, so the standard OB1 cycle does not silently overwrite your last GETIO result with stale peripheral data.

A second consideration: the use of MOVE_BLK_VARIANT to copy the consistent data from %I100:P to %I100 does not preserve consistency on its own. The MOVE_BLK_VARIANT instruction copies one element at a time and can be interrupted by OB86 mid-copy, leaving the process image in a partially-updated state. DPRD_DAT/GETIO are the only instructions on the S7-300/1200 that guarantee an atomic copy of the entire consistent data range.

PLCSim Integration Strategy

S7-1200 PLCSIM (in TIA Portal V16+) does not allow the user to write to the process input area (%I); writes from the simulation are immediately overwritten by the cyclic peripheral-to-process-image update. This makes it difficult to integrate an external plant simulator that needs to inject sensor values into the simulated PLC's inputs.

The workaround is:

1. Disable the automatic process image update on the simulated input ranges (same as the real PLC).
2. In the plant simulator (e.g., a C# application using S7ProSimLib or a TCP-based NetToPLCSIM connection), write directly to a DB that the PLC code is reading conditionally.
3. In the PLC code, use a runtime flag (set by the simulator) to switch between GETIO/SETIO (real PLC) and direct DB read/write (PLCSIM mode).

The decision flag can be a single bit in a known DB:

• In real PLC: sim_mode := FALSE. Code uses GETIO/SETIO.
• In PLCSIM: sim_mode := TRUE. Code reads drive input from a simulated DB written by the plant simulator, writes drive output to the same DB; the plant simulator consumes the output and updates the input DB on the next cycle.

This pattern lets a single TIA project run on both PLCSIM and the real PLC without conditional code paths for the I/O calls themselves, only for the source/destination of the data.

NetToPLCSIM acts as a TCP-to-PLCSIM gateway and runs as a small Windows service. It exposes PLCSIM on a TCP port so the plant simulator can connect over standard Ethernet without needing the S7ProSimLib's in-process API. For a simple architecture: PLCSIM runs on the engineering PC, NetToPLCSIM exposes it on TCP port 102, the plant simulator (also on the engineering PC or on a separate machine) connects via S7 client calls to read the simulated outputs and write the simulated inputs. The PLC code, in PLCSIM mode, sees the DB updates from the simulator and never calls GETIO/SETIO.

ABB Drive PPO Configuration and Worked Example

Most ABB drives (ACS800, ACS550, ACS355 with RPBA-01, ACS880 with NPBA-12) use a Profibus profile called PPO (Parameter/Process Data Object). PPO types are:

For a 1-word control word + 1-word setpoint and 1-word status word + 1-word actual value, PPO 3 is the minimum. For full diagnostics with 6 PZD words each direction, PPO 4 is common. PPO 5 and 6 are used for ABB drives with extended status/control word sets and fieldbus adapter parameter access.

Configure the PPO type on the drive (drive parameter group 51 / 52 typically, depending on the drive family) to match the GSD selection in TIA Portal. The PPO type drives both the telegram length on the wire and the mapping of the I/O words in the PLC's address space.

Worked example: PPO 4, 12 bytes I/O, ABB drive at Profibus address 4 mapped to %IB100..%IB111 and %QB100..%QB111.

// Data block "drive_data"
// Drive input (from drive to PLC)
"drive_in_buffer".status_word      AT %IB100 : WORD;  // ABB status word
"drive_in_buffer".actual_speed     AT %IB102 : WORD;  // Actual speed (scaled)
"drive_in_buffer".output_freq      AT %IB104 : WORD;  // Output frequency
"drive_in_buffer".motor_current    AT %IB106 : WORD;  // Motor current
"drive_in_buffer".dc_bus_voltage   AT %IB108 : WORD;  // DC bus voltage
"drive_in_buffer".fault_word_1     AT %IB110 : WORD;  // Fault / alarm word

// Drive output (from PLC to drive)
"drive_out_buffer".control_word    AT %QB100 : WORD;  // ABB control word
"drive_out_buffer".speed_ref       AT %QB102 : WORD;  // Speed reference
"drive_out_buffer".reserved_1      AT %QB104 : WORD;  // Reserved
"drive_out_buffer".reserved_2      AT %QB106 : WORD;  // Reserved
"drive_out_buffer".reserved_3      AT %QB108 : WORD;  // Reserved
"drive_out_buffer".reserved_4      AT %QB110 : WORD;  // Reserved

In OB1, the read and write sequence is:

// OB1: cyclic drive I/O
IF "sim_mode" = FALSE THEN
    // Read 12 bytes from drive peripheral
    "drive_getio_status" := GETIO(LADDR  := 16#0064,
                                  SLOT   := 16#00,
                                  RECORD := "drive_in_buffer",
                                  STATUS => "drive_status");
    "drive_data_ok" := ("drive_getio_status" = 0);
    
    // Process control logic
    IF "drive_data_ok" THEN
        "drive_out_buffer".control_word := "control_word_calc";
        "drive_out_buffer".speed_ref    := "speed_ref_calc";
    ELSE
        // Fault path: command drive to safe state
        "drive_out_buffer".control_word := 16#0000;  // OFF1 stop
        "drive_out_buffer".speed_ref    := 0;
    END_IF;
    
    // Write 12 bytes to drive peripheral
    "drive_setio_status" := SETIO(LADDR  := 16#0064,
                                  SLOT   := 16#00,
                                  RECORD := "drive_out_buffer",
                                  STATUS => "drive_status_out");
END_IF;

The control_word_calc is the result of the drive state-machine logic, which uses status_word to determine the current drive state. Common ABB control word transitions: 16#0006 = OFF1 stop, 16#0007 = OFF2 stop (coast), 16#000F = run enable, 16#047F = run with ramp, 16#04FF = fault reset (rising edge). Common status word values: 16#0000 = not ready, 16#0347 = ready, 16#0237 = running, 16#0F37 = fault active.

Verification, Commissioning, and Troubleshooting

Use this checklist when validating the migration:

1. Hardware: CM 1243-5 is detected in TIA Portal, online diagnostics show it as OK (green). The CM's BF (bus fault) LED must be off and the RUN LED must be green.
2. Profibus: All slaves (IM151, ABB drive) appear with green status in the online diagnostics. Use "Online > Online and diagnostics" on the CM, then the "Profibus diagnostics" buffer, to verify bus health.
3. GSD: ABB drive GSD is imported; PPO type matches the drive configuration; I/O length matches (e.g., 12 bytes for PPO 4).
4. Process image: Automatic update is disabled for the affected input and output ranges.
5. GETIO / SETIO instructions return STATUS = 0 under steady-state conditions. Verify with a watch table on drive_status and drive_status_out.
6. OB86 is present in the project and the project downloads without the "OB86 missing" warning.
7. Force a slave failure: pull the Profibus connector from the IM151. CPU remains in RUN. OB86 fires with FLT_ID = 02, EV_CLASS = 38, MDL_ADDR = 100. STATUS of the next GETIO call is non-zero (e.g., 80B0 or 80F1). drive_data_ok flag is FALSE in both OB86 and OB1.
8. Reconnect the slave. OB86 fires with FLT_ID = 07, EV_CLASS = 39. The next GETIO returns STATUS = 0. drive_data_ok returns to TRUE.
9. PLCSIM: project runs offline. Plant simulator can drive the simulated drive state machine. sim_mode flag is set. GETIO/SETIO are not called in simulation mode (or are called and the simulator intercepts the result).
10. HMI: KTP700 shows the "drive comm fault" diagnostic and the last-known good status when the Profibus is broken. The bad-data flag must be visible to the HMI for operator diagnostics.

Troubleshooting Matrix

Fault Handling State Diagram

Frequently Asked Questions