PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E)

kuegerls
2026-07-17
2026-07-21
  • kuegerls - 2026-07-17

    Hello ,

    I am currently evaluating the CODESYS PROFINET Controller SL on a Revolution Pi Connect 5 and have encountered a problem with acyclic PROFINET Record Access (WRREC/RDREC).

    System
    Hardware: Revolution Pi Connect 5
    Runtime: CODESYS Control 4.16.0.0 (SDK 3.5.21.10)
    Development System: CODESYS V3.5 SP21 (64-bit)
    CommFB: 3.5.17.10
    ProfinetCommon: 4.6.0.0
    PROFINET Controller Device: PN-Controller 4.6.0.0
    PROFINET Device: NORD DRIVESYSTEMS SK205E with SK TU4-PNT
    GSDML: GSDML-V2.46-NORDDRIVESYSTEMS-PNT-20251016.xml
    Network

    The PROFINET network is completely separated from the office network.

    RevPi:

    eth0 β†’ Office network
    eth1 β†’ PROFINET
    wlan0 β†’ Visualization

    The PN Controller is configured to use eth1.

    IP configuration:

    RevPi (eth1): 192.168.100.1/24

    NORD Drive: 192.168.100.3

    Connection is established successfully.

    Current Status

    The PN Controller reports:

    Controller Status = Run
    Online = TRUE
    IP Active = TRUE
    Connections = 1

    Cyclic PROFINET IO communication works correctly.

    Problem

    I am trying to access PKW parameters via WRREC (Record Index 100).

    The request buffer contains:

    01 14 00 04 92 00 00 00 00 00 00

    which corresponds to

    Reference = 0x01
    Request = Read
    Axis = 0
    Parameter = 170 + 1000
    Subindex = 0
    Value = 0

    The WRREC call is

    fbWRREC(
    REQ := xWrReq,
    ID := ConnectionID,
    INDEX := 100,
    LEN := 11,
    RECORD := ADR(TxBuffer)
    );

    REQ is pulsed for one PLC cycle only.

    Observed Behaviour

    WRREC enters BUSY state and never finishes.

    Observed values:

    BUSY = TRUE
    DONE = FALSE
    ERROR = FALSE
    STATUS = 16#FFFFFFFF

    indefinitely.

    Packet Capture

    A Wireshark capture was taken on the PROFINET network.

    Observed traffic:

    PROFINET RT
    LLDP
    DCP

    Observed:

    successful cyclic IO

    Not observed:

    DCE/RPC
    Record Write
    Record Read
    RPC Bind

    No RPC packets are transmitted at all.

    Diagnostic Messages

    The controller repeatedly reports

    AR alarm.ind(err)
    AR CMI timeout

    although cyclic IO communication continues to work.

    Already Verified

    The following points have already been checked:

    correct Ethernet interface (eth1)
    correct CREATE_ID result
    correct Device ID
    correct Slot/Subslot
    correct GSDML
    correct REQ pulse
    RECORD buffer is larger than LEN
    cyclic IO communication works
    different Record Indices (100...104) tested
    Question

    Is there any known issue or limitation where WRREC/RDREC requests remain permanently BUSY and no RPC Record Access packets are generated?

    Could this behaviour be related to

    Runtime 4.16.0.0,
    PN Controller 4.6.0.0,
    the missing runtime license (currently running in demo mode),
    or any known issue with the PROFINET Controller SL?

    I am currently evaluating the PROFINET Controller SL and therefore the runtime is operating in demo mode.
    Could you please confirm whether WRREC/RDREC (acyclic Record Data services) are fully supported in demo mode, or whether a valid license is required for these services?

    If required, I can provide:

    complete project archive
    Wireshark capture (.pcap)
    GSDML
    online screenshots
    diagnostic log

    Thank you very much for your help.

    Best regards,

    Stefan

     
  • TimvH

    TimvH - 2026-07-21

    A customer of us had the same issue.
    They updated (at that time) to CODESYS 3.5.21.50 and Control for Linux SL versie 4.19.0.0.
    After that they couldn't reproduce the issue anymore.

    You might give this a try too.

     

Log in to post a comment.