Resolving S7-300 GET Function Error 27: FB14 vs SFB14 Block Selection

Problem Details

When programming S7 communication between Siemens SIMATIC S7-300 controllers, engineers frequently encounter a confusing failure mode. The GET function block returns no entry in the diagnostic buffer, no OB121 programming-error call, and no CPU STOP. Instead, a STATUS value of 27 (decimal) is reported on the function block's status output. Data is not transferred, but the CPU continues running because the project contains an error-OB that traps the underlying fault and prevents the CPU from going to STOP.

The root cause is almost always confusion between FB14 (a CPU-specific communication block that lives in the user program and must be downloaded) and SFB14 (a system function block that is embedded in the S7-400 firmware image). On the S7-300 platform, the correct block to use for S7 communication is FB14 "GET" from the "Standard Library > Communication Blocks" palette, targeted specifically at the CPU_300 family. Calling SFB14 on an S7-300 CPU triggers STATUS = 27 (W#16#1B / hex 1B), which the online help translates as: "There is no function code in the CPU for this block." The runtime cannot find a system function code, so the call exits with this status and no work is performed.

According to the Siemens S7 Communication with PUT/GET documentation, GET status is output at the "status" output of the function block, and on error the output parameters are set to their initial values. Because the function is not a true runtime error at the OB level (the CPU simply cannot find a system function code), the error does not propagate to OB121 or the diagnostic buffer when an error-OB swallows it.

Symptom Matrix

The error message text in the STEP 7 / TIA Portal online help translates to: "No system function code available for this block. The block cannot be executed on this CPU." This is a hard hint that the CPU's firmware does not have the SFB14 function code, which is correct because SFB14 belongs to the S7-400 system software, not the S7-300.

Affected Hardware and Firmware

• CPU family: SIMATIC S7-300 (including the CPU 317-2 used in the field case)
• Other affected platforms: S7-300F, ET 200S IM151-8 CPU, WinAC RTX (firmware-compatible with the S7-300 system block set)
• Block delivery method: FB14 / FB15 supplied via the "Standard Library > Communication Blocks" in STEP 7 V5.x and via the "Standard libraries > Communication Blocks" folder in TIA Portal V13 and later
• STEP 7 versions known to exhibit the issue: STEP 7 V5.4, V5.5, V5.6, TIA Portal V13, V14, V15, V15.1, V16, V17, V18 (and later)
• S7-400 / S7-1500 note: These platforms use SFB14 / SFB15 (S7-400) or the PUT / GET instructions (S7-1500) natively; the S7-300 is the only family that requires the FB-library approach

Root Cause Analysis

Why the CPU Reports W#16#1B

The S7-300 CPU family is shipped without the SFB14 / SFB15 system function codes. SFB system function numbers are reserved for the S7-400 firmware image; on the S7-300, the equivalent functionality is delivered as FB14 "GET" and FB15 "PUT" inside the "Standard Library" that ships with STEP 7. If a project is copied between projects, restored from a backup originally written for an S7-400, or pasted from a vendor example, the call can inadvertently reference SFB14. When the cyclic OB hits that call, the CPU cannot resolve the system function code and returns W#16#001B (decimal 27) in the STATUS output.

The reason there is no diagnostic buffer entry is that the CPU first invokes any installed error-OB, the OB's local TEMP variable receives the status, and the OB exits cleanly. Combined with a user-written error-OB that suppresses the fault, the entire event becomes silent in the buffer.

Why the Original Code "Did Nothing"

If a project uses SFB14 on an S7-300 without an error-OB, the CPU transitions to STOP. The original programmer installed an OB to trap the fault and keep the CPU in RUN, so the symptom degraded from "PLC in STOP" to "GET silently does nothing" - the trap OB never wrote the error out, and the block did not execute the S7 communication job. The combination of an error-OB plus a wrong block type is the most common root cause of this exact symptom pattern.

Why Pulling the Block from the Library Did Not Work

A common troubleshooting step is to right-click the call in STEP 7 and select "Update Block" or to drag a fresh FB14 from the Standard Library onto the network. This works only if the block is dropped as a new block instance in the program. If the original call is left as SFB14, no amount of "update" will change the call type, because SFBs and FBs are not interchangeable at the call site. The SFB14 call must be deleted and replaced with a fresh FB14 instance.

Solution: Use the Correct Block from the Standard Library

Step 1 - Verify CPU Family

In TIA Portal or STEP 7 V5.x, open the project and inspect the device configuration. Confirm that the CPU is a 6ES7 3xx-xxxxx-xxxx (S7-300 family) rather than 6ES7 4xx-xxxxx-xxxx (S7-400). The S7-1500 uses 6ES7 5xx-xxxxx-xxxx, which has its own PUT/GET system instructions.

Step 2 - Open the Standard Library

STEP 7 V5.x:

1. From the menu, select File > Open > Library
2. Navigate to Standard Library
3. Open Communication Blocks
4. Locate FB14 "GET" with the comment "CPU_300" or "for S7-300"

TIA Portal (V15 and later):

1. Open the project tree
2. Right-click Program blocks
3. Select Libraries > Standard libraries > Communication Blocks
4. Drag FB14 into the program blocks folder of the S7-300 CPU

Step 3 - Delete the Old SFB14 Instance and Replace With FB14

1. In the program editor, locate the network that calls SFB14 GET
2. Right-click the SFB14 instance DB and select Delete
3. Drag FB14 from the library into the same network
4. STEP 7 / TIA Portal will prompt to create a new instance DB; accept the default DB number or assign a free number
5. Reconnect the input pins (REQ, ID, ADDR_1, ADDR_2, ... ADDR_8, RD_1, RD_2, ... RD_8) to the existing variables
6. Reconnect the output pins (NDR, ERROR, STATUS)

Step 4 - Download the Block to the CPU

The correct download order is critical to avoid a CPU fault during the change:

1. Stop the CPU (or place it in STOP via the online menu)
2. Download FB14 first
3. Download the instance DB for FB14
4. Download the calling block (OB1 or wherever the call resides)
5. Switch the CPU back to RUN

If you download the calling block before FB14 is on the CPU, the CPU will fault when it tries to call a non-existent block. If an error-OB swallows this fault, the symptom will persist. Stopping the CPU first ensures a clean transition.

Step 5 - Configure the S7 Connection

In NetPro (STEP 7 V5.x) or Devices & Networks (TIA Portal):

1. Establish an S7 connection between the local CPU and the partner CPU
2. Right-click the connection partner and select Object Properties
3. Confirm the connection ID matches the ID input on FB14
4. Verify that the partner's slot and rack are correctly entered
5. For PROFINET, confirm the partner's IP address and TSAP are correct
6. For PROFIBUS, confirm the partner's PROFIBUS address is correct

Verification

Online Status Check

After completing the steps above:

1. Open the calling block online
2. Monitor the FB14 inputs and outputs
3. REQ should pulse TRUE on the call that triggers a read
4. After one or more scan cycles, ERROR should be FALSE
5. STATUS should be 0 (W#16#0000) on success
6. The RD_1, RD_2, ... RD_8 outputs should contain the data read from the partner

Expected STATUS Codes for FB14 GET

Diagnostic Buffer Inspection

Open the CPU's online diagnostic buffer and confirm there are no remaining OB121, OB85, or OB122 entries that point to SFB14. The "Event" column should show "STOP cause" cleared. If an error-OB is in the project, the buffer may show only the OB invocation but not the underlying cause. Temporarily removing the error-OB (after saving a backup) and forcing the call will surface the cause in the buffer.

Cross-Platform PUT/GET Compatibility

S7-300 to S7-300

Both sides use FB14 / FB15 from the "Standard Library > Communication Blocks". No additional configuration is required beyond creating the S7 connection in NetPro. The connection ID is assigned by STEP 7 and can be inspected under the connection's object properties.

S7-300 to S7-400

The S7-300 side uses FB14 / FB15. The S7-400 side uses SFB14 / SFB15. Both blocks are functionally identical at the interface level. Ensure that the S7-400 has SFB14 / SFB15 enabled (this is the default). The S7-400 may require that the S7 connection be configured with the same TSAP at both ends (typically TSAP 01.01 for the local slot/rack).

S7-300 to S7-1500

The S7-300 side continues to use FB14 / FB15. The S7-1500 side uses the "PUT" / "GET" instructions from the "Communication" palette. The S7-1500 must have "Permit access with PUT/GET communication from remote partner" enabled in its properties. The CP module (for example, CP 1543-1) is the typical S7-1500 interface for S7 communication.

S7-1500 to S7-1500

Both sides use the TIA Portal "PUT" and "GET" instructions. No library block download is required because the instructions are part of the S7-1500 firmware image. Status handling is identical to the S7-300 FB14 interface.

Common Pitfalls and Edge Cases

Pitfall 1 - Copy-Paste from a Mixed Project

If a project was started on an S7-400 and the hardware was later changed to an S7-300, STEP 7 may retain the SFB14 calls because the calling block was never recompiled against the new hardware. The fix is to delete and re-drag FB14 from the Standard Library. After hardware replacement, always perform a project-wide "Compile (rebuild all)" to surface any block-type mismatches.

Pitfall 2 - Hidden Error-OB

The presence of OB121, OB80, OB85, or OB122 in the project suppresses CPU STOP. If the PLC was commissioned in a state where these OBs are present but the S7 communication is not yet working, the fault is hidden. Remove the OBs temporarily (or add code to write the OB's local variables to a DB) to surface the underlying fault.

Pitfall 3 - S7-1500 Security Default

The S7-1500 disables PUT/GET access by default. Without enabling it, the S7-300 GET call will return STATUS = 16 (W#16#0010) or similar, indicating the partner rejected the request. Check the S7-1500 protection settings. This setting was added in firmware V2.0 of the S7-1500 CPUs.

Pitfall 4 - Wrong Connection ID

The ID input on FB14 / GET must match the local S7 connection ID assigned in NetPro or "Devices & Networks". If the IDs do not match, the STATUS output returns 16 / 17 / 26 indicating "connection not established" or "no such connection". To find the connection ID, open the connection in NetPro and read the "Local ID" field in the properties dialog.

Pitfall 5 - Partner Not in the Same Project

If the partner CPU is in a different project (for example, the partner is a third-party PLC or a separate SIMATIC project), the S7 connection must still be defined locally with the partner's IP address / PROFIBUS address. The connection ID can be different from the partner's local ID.

Pitfall 6 - CP Card vs Onboard Interface

If the S7 connection is established via a CP card (for example, CP 343-1) rather than the CPU's onboard PROFINET / PROFIBUS interface, the FB14 call should reference the CP's connection ID, not the CPU's. Using a CPU connection ID with a CP interface causes STATUS to indicate "connection not found." Each interface maintains its own connection table.

Pitfall 7 - Cycle Time and OB Priority

FB14 / FB15 internally use SFCs (SFC 24, SFC 25 for testing the connection) that have an execution time of several milliseconds. Calling them in OB1 with a high repetition rate can inflate the OB1 cycle time. For a 1-second cycle, call the GET in OB35 (100 ms cyclic interrupt) instead of OB1, and use a handshake DB to move the data into the main cycle.

Pitfall 8 - ADDR Parameter Width

The ADDR_1 ... ADDR_8 parameters are pointers (ANY) that point to the data area on the partner. The RD_1 ... RD_8 parameters are pointers to the local receive area. Both pointers must be of the same width (e.g., both P#DB100.DBX0.0 BYTE 20). Mismatched widths cause STATUS = 33 (object access not allowed) on the partner side.

Error Handling with GET_ERROR and GET_ERROR_ID

The TIA Portal "GET_ERROR" and "GET_ERROR_ID" instructions provide local error information for a block call. According to the GET_ERROR and GET_ERROR_ID documentation, these instructions are used to send error information from the currently executing block (called block) to a calling block. They are not the same as the FB14 STATUS output, but they can be used together.

Place GET_ERROR immediately after the FB14 / GET call to capture any local errors that the block call itself encountered. If FB14 returns STATUS = 27, GET_ERROR will report that the system function code is not available, and GET_ERROR_ID will return a code that maps to the same root cause. A typical pattern:

IF "GET_DB14".ERROR THEN
    "Last_ERROR_Text" := GET_ERROR();
    "Last_ERROR_ID" := GET_ERROR_ID();
END_IF;

Programming Template

A robust FB14 call in OB1 (or a cyclic OB) should:

1. Use a rising-edge detection on REQ so that each call initiates one read
2. Latch ERROR and STATUS to a separate DB so that transient errors can be reviewed
3. Reset the latch after the operator has acknowledged the error
4. Log the first error (via GET_ERROR_ID) to a separate error DB
5. Set a heartbeat / watchdog so that the operator can see if the block is being called

A typical pattern in SCL (Structured Control Language):

IF "Start_Trigger" THEN
    "GET_DB14"(REQ := TRUE,
                ID := 1,
                ADDR_1 := "Partner_DB".ADDR_1,
                RD_1 := "Receive_Area".RD_1);
ELSE
    "GET_DB14"(REQ := FALSE,
                ID := 1,
                ADDR_1 := "Partner_DB".ADDR_1,
                RD_1 := "Receive_Area".RD_1);
END_IF;

IF "GET_DB14".ERROR THEN
    "Last_ERROR" := "GET_DB14".STATUS;
END_IF;

"Watchdog" := "Watchdog" + 1;

Diagnostic Workflow Summary

Field Commissioning Checklist

• CPU family confirmed as S7-300
• FB14 / FB15 source confirmed as Standard Library > Communication Blocks
• No SFB14 / SFB15 calls anywhere in the project
• FB14 / FB15 blocks present in the CPU load memory
• Instance DBs for FB14 / FB15 present in the CPU load memory
• S7 connection defined in NetPro / Devices & Networks
• Local connection ID matches the ID input on FB14 / FB15
• Partner IP address / PROFIBUS address correct
• Partner TSAP correct (default 01.01 for the local CPU slot/rack)
• S7-1500 PUT/GET access enabled (if partner is S7-1500)
• No error-OB in the project during commissioning (or error-OB code that logs the underlying cause)
• Status codes monitored for 0 (success) and any of 16, 33, 49, 50 (connection or address issues)
• Watchdog counter increments, proving the call is being executed each cycle

Frequently Asked Questions