Codesys control service for RevPi Connect randomly stops working
Posted: 07 Mar 2023, 07:38
Hello,
I have a few RevPi PLC controllers licensed with 'CODESYS Control for Raspberry Pi SL'. CODESYS runtime randomly stops working on the controllers - Modbus server is stops being reachable and I don't see the controllers when I scan network with CODESYS.
Controllers are working properly, and they are on the network. When I check the codesyscontrol.service on the controller, it says it is active (exited). In the codesys log files, I can't see any irregularity. After I restart the controller, everything works properly.
Log file:
The journalctl does not show any relevant informations:
When I restart the codesyscontrol.service it is not enough, I need to restart the whole controller for the Codesys runtime to start working again.
Did anybody else had this problem? Is there anything I can check / fix for this to stop happening?
The PLCs are delivered to the end user and they are put into operation, so this a big problem for us.
I have a few RevPi PLC controllers licensed with 'CODESYS Control for Raspberry Pi SL'. CODESYS runtime randomly stops working on the controllers - Modbus server is stops being reachable and I don't see the controllers when I scan network with CODESYS.
Controllers are working properly, and they are on the network. When I check the codesyscontrol.service on the controller, it says it is active (exited). In the codesys log files, I can't see any irregularity. After I restart the controller, everything works properly.
Log file:
Code: Select all
2023-03-02T23:21:29Z, 0x00008001, 1, 1, 1, *************************************************************************************
2023-03-02T23:21:29Z, 0x000010f0, 2, 0, 4, !!!! Warning: <Network>eth0</Network><Comp>IoDrvEthernet</Comp>
2023-03-02T23:21:29Z, 0x000010f0, 1, 0, 7, <Comp>IoDrvEthernet</Comp>
2023-03-02T23:21:29Z, 0x00000002, 1, 0, 7, Retains matched to bootproject of application [<app>Application</app>]
2023-03-02T23:21:29Z, 0x00000002, 1, 0, 6, Bootproject of application [<app>Application</app>] loaded
2023-03-02T23:21:29Z, 0x00000018, 1, 0, 1, Setting router <instance>0</instance> address to <address>(0001)</address>
2023-03-02T23:21:29Z, 0x00000018, 1, 0, 1, Setting router <instance>1</instance> address to <address>(2ddc:7f00:0001)</address>
2023-03-02T23:21:29Z, 0x00000002, 1, 0, 10, Application [<app>Application</app>] started
2023-03-02T23:21:29Z, 0x00008000, 1, 1, 1, Read Inputs: wConnectorTYPE: 40200, auiPar[0]: 315, dwPIoffset: 315, dwParameterID: 100
2023-03-02T23:21:29Z, 0x00008000, 1, 1, 1, Write Outputs: wConnectorTYPE: 8103, auiPar[0]: 21, dwPIoffset: 0, dwParameterID: 3500
2023-03-02T23:21:29Z, 0x00000001, 1, 0, 34, CODESYS Control ready
2023-03-02T23:21:29Z, 0x00000001, 1, 0, 0, runtime licensed
2023-03-02T23:21:30Z, 0x000010f0, 1, 0, 1, <Network>eth0</Network><IP>192.168.11.168</IP><Sub>255.255.255.0</Sub><Comp>IoDrvEthernet</Comp>
2023-03-02T23:21:34Z, 0x00000018, 1, 0, 5, Network interface <interface>ether local</interface> unregistered
2023-03-02T23:21:34Z, 0x00000007, 1, 0, 6, Network interface: <ipaddress>192.168.11.168</ipaddress>, subnetmask <subnetmask>255.255.255.0</subnetmask>
2023-03-02T23:21:34Z, 0x00000018, 1, 0, 4, Network interface <interface>ether 1</interface> at router <instance>2</instance> registered
2023-03-02T23:21:34Z, 0x00000018, 1, 0, 1, Setting router <instance>2</instance> address to <address>(00a8)</address>
Code: Select all
pi@TBreR2:~ $ sudo journalctl -u codesyscontrol.service
-- Logs begin at Thu 2019-02-14 11:11:59 CET, end at Tue 2023-03-07 07:18:38 CET. --
Mar 03 00:21:22 TBreR2 systemd[1]: Starting LSB: Prepares and starts codesyscontrol...
Mar 03 00:21:24 TBreR2 codesyscontrol[1531]: codesyscontrol started
Mar 03 00:21:24 TBreR2 systemd[1]: Started LSB: Prepares and starts codesyscontrol.
Did anybody else had this problem? Is there anything I can check / fix for this to stop happening?
The PLCs are delivered to the end user and they are put into operation, so this a big problem for us.