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.
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?
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