Developing Custom Channel Driver Blocks in SCL for Third-Party PROFINET Devices in SIMATIC PCS 7

In SIMATIC PCS 7 systems, developing custom channel driver function blocks in SCL for third-party PROFINET or PROFIBUS devices (such as smart control valves) requires dynamically resolving peripheral I/O start addresses and ensuring consistent data access across multi-byte records. To avoid hardcoding memory addresses and make CFC interconnections symbolic, engineers utilize system function SFC 5 (GADR_LGC) to translate geographical module hardware coordinates into logical start addresses (LADDR), alongside SFC 14 (DPRD_DAT) and SFC 15 (DPWR_DAT) to execute consistent multi-word peripheral data exchanges.

Custom Driver Blocks vs Standard PCS 7 Module Driver Generation

In standard SIMATIC PCS 7 engineering, Siemens field devices and standard ET 200 I/O modules are integrated automatically using the Generate Module Drivers compiler wizard. The compiler reads hardware system data blocks (SDBs) and instantiates diagnostic blocks (MOD_CP, OB_DIAG) and channel drivers (FbAnIn, FbDrive).

When integrating non-standard third-party PROFINET devices (such as proprietary smart control valves, multi-variable Coriolis meters, or custom actuators) that lack official PCS 7 library support, engineers must create a custom channel driver in SCL:
- The block must interface between the physical peripheral memory (PIW / PQW) and upper-level APL technological blocks (VlvL, MotSpdCL).
- To maintain standard engineering look-and-feel in CFC, the block should not require hardcoded numerical memory addresses (e.g. 512), but should resolve addresses symbolically or accept hardware configuration parameters.

Dynamic Address Resolution Using SFC 5 (GADR_LGC)

To dynamically resolve the logical base address of a distributed PROFINET module without hardcoding:

System Function SFC 5 (GADR_LGC): Converts geographical module addressing into the logical base address (LADDR):
scl // Example SCL Address Resolution RetVal := GADR_LGC( SUBNETID := Subnet_ID, // In: Subnet ID (PROFINET / PROFIBUS line) RACK := Station_No, // In: Device Number / Station Address SLOT := Slot_No, // In: Slot position of the sub-module SUBSLOT := Subslot_No, // In: Subslot position SUBADDR := W#16#0, // In: Sub-address IOID := Mod_Type, // Out: Input (B#16#54) or Output (B#16#55) LADDR := Base_Address // Out: Logical base I/O address (WORD) );
Symbolic Interconnection in CFC: In CFC, the engineer can interconnect the diagnostic address of the hardware module directly to an input pin of the custom block, allowing SFC 5 to compute the I/O base pointer automatically.

Consistent Multi-Byte Data Transfer via SFC 14 and SFC 15

Fieldbus control valves typically exchange multi-byte records (e.g. 4 bytes for setpoint and status word, plus 4 bytes for readback position and diagnostic bits):
- Data Inconsistency Risk: Standard load/transfer commands (L PEW, T PQW) read/write 2 bytes at a time. If an interrupt OB (such as OB35) preempts execution mid-transfer, half of the valve control word will be updated while the other half contains old data, causing valve position jerking or communication timeouts.
- Consistent Communication:
- Use SFC 14 (DPRD_DAT) to read consistent input data blocks larger than 4 bytes from the peripheral address into an internal STRUCT or ARRAY buffer.
- Use SFC 15 (DPWR_DAT) to write consistent output control records from the controller to the peripheral device.

Implementation Workflow and SCL Architecture Table

The following table details system functions and attributes used in custom SCL channel driver development:

Function / AttributeSiemens System BlockSCL Implementation RoleBenefitGADR_LGCSFC 5Converts Station/Slot to Logical Address (LADDR)Eliminates hardcoded memory addresses in CFCDPRD_DATSFC 14Reads consistent multi-byte data record from devicePrevents data inconsistency across complex telegramsDPWR_DATSFC 15Writes consistent multi-byte data record to deviceEnsures control words and setpoints update atomicallyS7_m_c := 'false'Block AttributeOmitted from driver block headerPrevents generating unnecessary WinCC tagsQuality Code (ST)Internal StructAppends 16#80 (Good) or 16#00 (Bad) to outputProvides native signal status to downstream APL blocks

Note: Custom channel blocks should output structured variables (STRUCT containing Value and ST) to integrate seamlessly with APL technological blocks.

Verification

Verify custom SCL channel driver operation:
1. In HW Config, verify the PROFINET control valve is assigned an I/O memory range (e.g. %IW 512..519 and %QW 512..519).
2. In CFC, insert the custom driver block, parameterize the station/slot or LADDR, and compile.
3. Switch CFC to Test Mode; confirm RetVal of SFC 5 and SFC 14 equals 0 (16#0000 = success).
4. Verify that the decoded readback valve position updates accurately in engineering units with quality code 16#80 (Good).
5. Disconnect the PROFINET network cable; confirm that the driver immediately outputs Quality Code 16#00 (Bad) and flags communication error QPARF = True.

Limitations and Operational Precautions

Essential rules for custom channel driver engineering:
- SFC 14 and SFC 15 can only be used if the module is configured in HW Config with data consistency set to 'Entire Length' (e.g. 3 words or 4 words consistent).
- Custom channel driver blocks are not automatically re-wired if hardware I/O addresses are modified in HW Config; any address change requires manually updating block parameters.
- Ensure the cyclic interrupt OB hosting the driver (e.g. OB35 at 100 ms) provides sufficient execution headroom for SFC 14/15 processing overhead.

Engineer FAQ

Can I use standard APL blocks with my custom driver block?

Yes. Output your process variable as an APL structure (STRUCT containing Value: REAL and ST: BYTE) and wire it directly into the input of standard APL blocks such as VlvL or MonAnL.

Why does SFC 14 return error 8090?

Error 16#8090 indicates an invalid logical base address (LADDR) or that the addressed module was not configured with consistent data length in HW Config.

Can a custom driver block participate in PCS 7 'Generate Module Drivers'?

Participating in automatic driver generation requires creating a formal XML module descriptor file and integrating it into the Step 7 driver generator rules, which is typically reserved for certified Siemens library developers.