Siemens SFC59 RD_REC: Reading Module Data Records in S7-300/400

Overview of SFC59 RD_REC

Siemens SFC 59 "RD_REC" (Read Record) is a standard system function supplied in the SIMATIC S7-300 and S7-400 CPU operating system. It is the canonical mechanism for reading parameter records (data records / DS) out of a distributed I/O module on PROFIBUS-DP or PROFINET IO. The function transfers a request to the addressed module, the module interprets the record number and replies with a byte stream whose layout is defined entirely by the device manufacturer (Siemens or third-party).

The function executes asynchronously on S7-300/400: a single call dispatches the request, and the CPU continues. The programmer must poll the BUSY and RET_VAL outputs to determine completion. This behavior is different from the IEC-standard RDREC instruction on S7-1500, which is also asynchronous but reports status through the ENO / STATUS semantics of TIA Portal instructions.

The defining engineering rule is the one that the original forum question was about: SFC 59 does not allocate or interpret the destination area. The programmer must declare RECORD as a sufficiently large ANY-pointer-compatible area before the call, and the byte layout of that area must match the data record layout specified in the device manual. If the target area is undefined, has the wrong length, or is not in a global DB, the function returns one of the negative acknowledgments documented below.

Prerequisites

• STEP 7 V5.5 or V5.7 with the S7-300/S7-400 system functions library installed. The relevant reference manual is the SIMATIC S7-300/400 Standard Software - System and Standard Functions Reference Manual.
• Hardware configuration (HW Config) loaded into the CPU with the target module configured at a known logical base address.
• The module's GSD file imported, or for Siemens ET 200 stations, the ET 200 device manual defining the available data record numbers (0, 1, 2, ... 240 typically).
• A global DB with a destination area of the correct size and an ANY-compatible declaration. The DB may be of any block type (DB, M, bit memory), but the pointer passed to RECORD must point to a global data area; instance DBs and local stack are not permitted.
• STEP 7 online connection to the CPU for testing; the RD_REC call cannot be verified offline.

Call Interface and Parameters

The function block is called with the following input and output parameters. All multi-byte values are little-endian per Siemens convention. RECNUM and LADDR are WORD-type; the value of LADDR is the same logical address that appears in HW Config for the slot or channel of the target module.

Designing the Destination Area (RECORD)

The original forum thread touched on the most common source of error: calling SFC 59 with an undefined or under-sized destination. SFC 59 does not create a DB on demand and does not validate that the destination layout matches the record. The CPU firmware simply performs a fixed-length byte copy of the response payload into the memory region pointed to by RECORD, then returns. If the target is too small, the surplus bytes are lost; if it is too large, the unused bytes are untouched.

Recommended procedure:

1. Open the device manual of the target module (e.g. ET 200S 1SI module manual) and identify the record numbers you intend to read.
2. For each record number, note the data type, length, and meaning of every byte or word. Most diagnostic records are 4-32 bytes, but parameter records can exceed 200 bytes (e.g. ET 200S parameter record 128 = 128 bytes).
3. In a global DB, declare a structure whose total length is at least the record's maximum possible size. Allow a few bytes of headroom for vendor revisions that extend a record.
4. Pass the structure's symbolic name to RECORD using the STEP 7 "Point to symbol" feature, or build the ANY pointer manually with P#DB100.DBX0.0 BYTE 64 syntax.

Data Record Structure Per Device Family

The byte stream returned by RD_REC is 100% vendor-defined. The following table gives a quick reference for the most common Siemens modules. Always verify against the device manual before commissioning.

Code Examples

STL (Statement List) - S7-300/400

// Assumes DB100 has been pre-declared with a 64-byte array "DiagBuffer"
CALL SFC 59
REQ      := M 10.0          // Edge-triggered start request
IOID     := B#16#54         // 0x54 = input identifier (legacy form)
                          // For mixed modules use B#16#55
LADDR    := W#16#0100       // Module base address 256 decimal
RECNUM   := B#16#01         // Read data record 1
RET_VAL  := MW 12           // Return code, integer
BUSY     := M 10.1          // TRUE while job running
RECORD   := P#DB100.DBX0.0 BYTE 64   // Destination: 64 bytes in DB100

SCL (Structured Control Language) - S7-300/400

IF StartRecord AND NOT BusyFlag THEN
   BusyFlag := TRUE;
   SFC59_REQ := TRUE;
ELSE
   SFC59_REQ := FALSE;
END_IF;

IF BusyFlag THEN
   // SFC 59 returns through a multi-instance call;
   // here we use the symbolic form via FB wrapping
   RetVal := RD_REC(
      REQ    := SFC59_REQ,
      IOID   := 0,            // 0 = input
      LADDR  := 256,          // base address
      RECNUM := 1,
      RECORD := DiagBuffer    // symbol from global DB
   );
   IF RetVal = 0 THEN
      BusyFlag := FALSE;
      // DiagBuffer now contains data record 1
   ELSIF (RetVal < 0) OR (RetVal = 7000) THEN
      BusyFlag := FALSE;
      // Handle error - see RET_VAL codes table below
   END_IF;
END_IF;

LAD (Ladder) - S7-300/400

In LAD/FBD, drag SFC 59 from the standard library onto your network. STEP 7 will auto-generate the EN/ENO calls and an instance DB for the parameter retention. Wire REQ from a positive edge contact, LADDR from a constant of type WORD, and connect the RECORD input by right-clicking and selecting the DB symbol.

S7-1500 / TIA Portal (RDREC)

// RDREC on S7-1500: TIA Portal instruction, NOT SFC 59
#Busy := RDREC(
   REQ      := #startTrigger,
   ID       := 256,                  // HW identifier from device table
   INDEX    := 1,                    // Data record number
   MLEN     := 64,                   // Max length to be read
   VALID    := #recordValid,
   BUSY     := #busy,
   ERROR    := #error,
   STATUS   := #status,
   RECORD   := %DB100.DiagBuffer      // Symbolic DB access
);

The ID parameter is the HW identifier from the device configuration (a DWORD, e.g. 257), not a byte address. MLEN is the maximum bytes to read - this explicit length parameter is a safety improvement over SFC 59.

RET_VAL Error Codes

The RET_VAL (or STATUS on RDREC) return is the single most important field for diagnostics. The following values apply to SFC 59 on S7-300/400; RDREC on S7-1500 uses a superset of these plus the IEC 61131-3 error classes.

Asynchronous Execution and Polling Logic

Because SFC 59 executes across multiple OB1 cycles, the call must be edge-triggered and the BUSY flag must be used to gate the next call. The recommended pattern is:

1. On a positive edge of the user's start trigger, set REQ := TRUE and call SFC 59.
2. Read back BUSY and RET_VAL.
3. If BUSY := TRUE, do nothing - let the next OB1 cycle observe the result. Critically, do NOT re-set REQ while BUSY is TRUE, or you will cancel the in-flight job.
4. When BUSY := FALSE, evaluate RET_VAL. 0000 = success, negative = error (see table above).
5. Reset REQ and arm for the next edge.

Migration to S7-1500 (RDREC)

For new projects on S7-1500, ET 200SP, or any TIA Portal target, the IEC-standard instruction RDREC replaces SFC 59. Key behavioral differences:

• Identifier is ID (DWORD, HW identifier from the device table), not LADDR + IOID.
• MLEN explicitly bounds the read, eliminating the over-write risk of SFC 59.
• Output VALID pulses for one cycle when new data is available - a cleaner edge signal than the BUSY/FALSE pattern of SFC 59.
• Error reporting uses ERROR/STATUS instead of a single RET_VAL with hex codes. STATUS follows IEC 61131-3 error classes (e.g. 16#80B1 for RECORD overflow).
• RDREC is placed in the program directly, not as a system function from a library. It is found under "Extended instructions > Distributed I/O > RDREC".

For migration of legacy SFC 59 code, the wrapper is straightforward: replace the IOID + LADDR pair with a single ID DWORD, add an MLEN literal matching the RECORD size, and adjust the post-call evaluation logic to use ERROR/STATUS. The full conversion table is in the TIA Portal online help under "RDREC - Read data record".

Verification Procedure

1. Build a global DB with a 64-byte byte array named DiagBuffer. This is the RECORD target.
2. In OB1, insert a CALL to SFC 59 with REQ tied to a tag-controlled edge, IOID = 0 (input), LADDR = 256 (your module base address), RECNUM = 1, RECORD = P#DB100.DBX0.0 BYTE 64.
3. Trigger a positive edge on the REQ tag (use a SET / RESET from the STEP 7 debug watch table, or a force in online mode).
4. Open the SFC 59 instance in the online block view and observe BUSY toggle from TRUE to FALSE within a few OB1 cycles.
5. Check RET_VAL; if 0, open the destination DB and verify the byte pattern matches the record layout from the device manual. A diagnostic record from an ET 200S 1SI module, for example, will start with bytes that correspond to baud rate, then parity, framing, etc.
6. Test the error path: change RECNUM to an unsupported value (e.g. 200) and re-trigger. Expect RET_VAL = 16#80A0 (negative ack) and a new error entry in the diagnostic buffer.

Troubleshooting Matrix

Performance and Concurrency Limits

S7-300 CPUs have a limited number of asynchronous job slots. S7-313/314 allow 1-2 concurrent RD_REC calls, S7-315/316 allow 4-8, and S7-400 scales with the CPU type. If you issue more parallel calls than the CPU supports, the call returns RET_VAL = 16#80C3 (resource busy) and the request should be retried after a short back-off. S7-1500 RDREC does not have this hardware-imposed limit but is still subject to the underlying PROFINET/PROFIBUS job scheduler.

For high-frequency polling (e.g. reading diagnostic records every OB1 cycle), prefer the GET_DIAG function (SFC 13) for module-level diagnostics, and use RD_REC only for the less-frequent parameter-record reads. SFC 13 is fully synchronous and cheaper on the job pool.

FAQ