How to Diagnose a Third-Party PROFINET IO Device in PCS 7
For a directly connected PROFINET IO device, the PCS 7 Basis Library V8.0 documents RACK_PN for monitoring a PN IO rack and reporting its associated error events. OB_DIAG1_PN has a narrower documented purpose: monitoring DP or PA slaves connected through an IE/PB link. If the project needs a custom device-specific status, an S7-300/400 program can read the relevant system status list with RDSYSST (SFC 51), but that asynchronous call and its returned record must be handled according to the CPU and PCS 7 versions in use.
Table of Contents
- Choose the diagnostic path that matches the topology
- Use the PCS 7 RACK_PN monitor for a direct PN IO device
- Understand the scope of OB_DIAG1_PN
- Read module status with RDSYSST when custom logic is needed
- Build a PCS 7 custom monitor without relying on private driver data
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Choose the diagnostic path that matches the topology
First identify whether the “foreign slave” is a PROFINET IO device directly assigned to a PN IO system, or a DP/PA device downstream of an IE/PB link. The blocks are not interchangeable:
RACK_PNOB_DIAG1_PNRDSYSST / SFC 51 with SZL W#16#0C96The V8.0 Basis Library manual is specific to that library release. Check the installed Basis Library, CPU type/firmware, and project documentation before applying its block names or interfaces to another PCS 7 release.
Use the PCS 7 RACK_PN monitor for a direct PN IO device
The V8.0 Basis Library Function Manual describes RACK_PN (FB 90) as a rack-status monitor that reports associated error events. Its documented inputs include DADDR (diagnostics address of the PN IO device), DELAY (interrupt delay in seconds), PNIO_ADR (diagnostics address of the PN IO interface), and RACK_NO. The block also provides a RAC_DIAG structure and message/status outputs.
For a direct PN IO device, use the applicable release's RACK_PN documentation and the addresses from the project's hardware configuration. Check the block's actual interface in the installed library; do not assume its V8.0 pins or generated run sequence are identical in other releases. This is the documented PCS 7 route to consider before creating a parallel hand-coded diagnosis path.
Understand the scope of OB_DIAG1_PN
The PCS 7 Basis Library V8.0 manual identifies OB_DIAG1_PN (FB 202) as monitoring failure and recovery of DP or PA slaves connected to an IE/PB link. Its interface includes diagnostic/link parameters and a QRACKF failure output. This does not establish that its internal diagnostic structure is a supported general-purpose connection point for an arbitrary direct PN IO station.
If a device is downstream of an IE/PB link and the installed library documentation matches the project, use the documented block interface and the PCS 7-generated connections for that topology. For a direct PN IO device, use the direct-device diagnostic path instead of wiring undocumented internal data from an unrelated block.
Read module status with RDSYSST when custom logic is needed
On S7-300/400 systems, Siemens documents RDSYSST (system function SFC 51) for reading a partial system status list. SZL W#16#0C96 returns status information for a module or submodule selected by logical start address. The INDEX uses bits 0–14 for the module address and bit 15 to identify input versus output. The record includes the logical address, PROFINET system identifier, station/slot/subslot and an I/O-status word.
For the I/O-status word, Siemens documents bit 0 as a module fault detected by a diagnostic interrupt, bit 1 as module exists, bit 2 as module does not exist, bit 3 as module disabled, and bit 4 as station error for the representative slot. Select the address and representative slot that match the hardware configuration; a module-status bit is not a generic proof that every function of the third-party device is healthy.
The SFC 51 call is asynchronous. Siemens specifies that REQ starts the read, BUSY indicates an unfinished read, and RET_VAL carries an error code if execution fails. Use a nonblocking state machine or equivalent version-supported pattern that retains the request and checks completion on later calls. Do not copy the ticket's tight REPEAT loop into a cyclic OB; it can hold execution while a read is pending. Size and interpret the destination from SZL_HEADER.LENTHDR and N_DR, and evaluate only complete records.
Build a PCS 7 custom monitor without relying on private driver data
If the standard rack monitor does not provide the exact signal needed by the application, encapsulate the SFC 51 call and status decoding in a project-specific block only after confirming CPU support and the correct SZL/address mapping. Keep the status result, read-in-progress state, and return status explicit at the block interface. Define what the application treats as unavailable or faulty, including how a missing module, disabled device, station-level error, and failed status-list request differ.
Read the desired device or representative module address rather than scanning all devices without need. Schedule requests so that only the required status is read at an appropriate interval or in response to an applicable diagnostic event. The source discussion's estimate that a certain number of devices is automatically safe for cyclic polling is not supported by the cited Siemens documentation and is omitted.
Verification
In an approved test environment, verify the selected status path with the device operating normally and with a planned, controlled loss/recovery test when site procedures allow. Confirm that the diagnostic block or custom signal changes to the expected state, that recovery clears it, and that the PCS 7 message identifies the intended PN IO system and station. Check RET_VAL and BUSY during SFC 51 reads so that a failed or unfinished read is not mistaken for a healthy device.
A network ping or a single successful I/O update is not a substitute for checking the PCS 7 device/module status that the application relies on. The source ticket provides no test results, so this article describes a documented design path and verification criteria, not a lab-tested configuration.
Limitations and Operational Precautions
The source does not state the PCS 7 release, CPU model, firmware, library version, PN IO topology, or device addresses. The PCS 7 block details cited here are from Basis Library V8.0; the SFC 51 status-list reference covers classic S7-300/400 systems. Confirm the applicable manuals for the actual project before implementation.
A custom diagnostic block and its resulting interlock can affect process availability. Do not add SFC 51 polling loops to OB 1 or copy internal structures from generated driver charts into application logic without checking timing, interface support, and version-specific documentation. Validate changes offline or during an approved commissioning window, back up the project, and follow site rollback and download procedures. A communications status is not itself a safety-rated interlock.
Engineer FAQ
Can I use OB_DIAG1_PN for every PROFINET IO device? No. The cited PCS 7 Basis Library V8.0 manual describes it for DP or PA slaves connected through an IE/PB link. It documents RACK_PN as the rack-status monitor for PN IO devices.
Can RDSYSST target one module instead of reading all status information? SZL W#16#0C96 selects module/submodule status using the module's logical start address and input/output direction in INDEX.
What does bit 2 of the 0C96 I/O-status word mean? Siemens defines it as “module does not exist.” Bit 4 denotes a station error only for the representative slot; use the complete record and configured topology when interpreting station state.
Why should the SFC 51 request not spin in a loop in OB 1? The documented interface can remain busy after a request. A tight loop can keep the calling cycle occupied instead of allowing the asynchronous read to complete over subsequent calls.
Does the ticket's code establish a safe performance limit for polling? No. The quoted device-count estimates are forum experience, not a documented CPU or PCS 7 limit. Determine request rate and CPU impact from the actual CPU and application and validate them.
Technical References
- Siemens, PCS 7 Basis Library V8.0 Function Manual, § 3.45.3 “RACK_PN: Rack monitoring” and § 3.45.10 “OB_DIAG1_PN: OB diagnostics for avoiding stoppages in DPV1 master systems”: https://cache.industry.siemens.com/dl/files/833/57265833/att_279/v1/s7jbl80b_en-US.pdf
- Siemens, STEP 7 V21 Extended Instructions (S7-300, S7-400), “SZL-ID W#16#xy96 — PROFINET IO and PROFIBUS DP module status information”: https://docs.tia.siemens.cloud/r/en-us/v21/extended-instructions-s7-300-s7-400/diagnostics-s7-300-s7-400/system-status-list-s7-300-s7-400/szl-id-w-16-xy96-profinet-io-and-profibus-dp-module-status-information-s7-300-s7-400?contentId=EzmMXC8GvK39XCCZI4sWrw
- Siemens, STEP 7 V20 Extended Instructions (S7-300, S7-400), “RDSYSST: Read system status list”: https://docs.tia.siemens.cloud/r/en-us/v20/extended-instructions-s7-300-s7-400/diagnostics-s7-300-s7-400/rdsysst-read-system-status-list-s7-300-s7-400