Modbus RTU communication dies on M340
Although this is an old post, I am posting here, as I faced the same problem mentioned by user dimitrisd. The problem in my case is intermittent, and can appear at any interval between 10min to 2 days after power on of the M340 unit. At the M340 P342020 CPU (Ethernet & Modbus), there are 8 x Modbus RTU units connected to the Modbus serial port of the PLC and 1 x Modbus TCP device at the Ethernet port. The problem only happens in the RTU devices. When the problem occurs, the Serial Port freezes (the Ser Com Led is off). The Modbus TCP communication is not affected by this problem and keeps working perfectly.
For all the Modbus devices, the READ_VAR block is utilized. Different GEST variables are used for each READ_VAR block. The Modbus RTU devices are polled sequentially, one by one. Sequential reading for the devices is performed by an INC counter. The condition for the counter to increment and the polling to move to the next device to be polled is done by the detection of the falling edge of the activity bit of the GEST of the first READ_VAR block of the actual polled device. This counter function works fine also (and during the problem of communication loss). During each read of Modbus RTU device, 3 x READ_VAR blocks are used, and each READ_VAR block reads 40 sequential registers from the device.
The timeout for each GEST is set by the program to a timeout value greater than the one set to the port settings in CPU (e.g. in CPU the Serial port timeout / answer delay is set to 10, and the timeout at each GEST is set to 20).
When the problem is present, I have noticed that the activity bits for each READ_VAR are not stuck (they keep going 0 to 1 and back to 0) at the set timeout intervals. The communication report error is 1, meaning “Exchange Stop at Timeout”, which is normal, as the serial port is dead (No LED light).
I have also noted, when the problem is present, that the %S20 = 0, meaning that there is no Index overflow present. Same applies for %SW125, as it does not return a DEF3 code for index overflow.
I am really stuck, as I cannot figure out the source of this problem. The only thing that crosses my mind, is that all the cables for the Modbus RTU communication are simple cables, for internal panel wiring and not twisted pair shielded ones. The longest cable run for the Modbus cables is 3m (all the Modbus RTU devices are located inside the control panel). As a last resort I will try to change the cables with twisted shielded pair 2x0.75mm2 cable.
Also, I will try to log the %S20, and %SW125 also, for further monitoring and troubleshooting.
In the meanwhile, any ideas and recommendations are welcome.
For your convenience, I have attached some screenshots of the serial port configuration, and of the program.
Although this is an old post, I am posting here, as I faced the same problem mentioned by user dimitrisd. The problem in my case is intermittent, and can appear at any interval between 10min to 2 days after power on of the M340 unit. At the M340 P342020 CPU (Ethernet & Modbus), there are 8 x Modbus RTU units connected to the Modbus serial port of the PLC and 1 x Modbus TCP device at the Ethernet port. The problem only happens in the RTU devices. When the problem occurs, the Serial Port freezes (the Ser Com Led is off). The Modbus TCP communication is not affected by this problem and keeps working perfectly.
For all the Modbus devices, the READ_VAR block is utilized. Different GEST variables are used for each READ_VAR block. The Modbus RTU devices are polled sequentially, one by one. Sequential reading for the devices is performed by an INC counter. The condition for the counter to increment and the polling to move to the next device to be polled is done by the detection of the falling edge of the activity bit of the GEST of the first READ_VAR block of the actual polled device. This counter function works fine also (and during the problem of communication loss). During each read of Modbus RTU device, 3 x READ_VAR blocks are used, and each READ_VAR block reads 40 sequential registers from the device.
The timeout for each GEST is set by the program to a timeout value greater than the one set to the port settings in CPU (e.g. in CPU the Serial port timeout / answer delay is set to 10, and the timeout at each GEST is set to 20).
When the problem is present, I have noticed that the activity bits for each READ_VAR are not stuck (they keep going 0 to 1 and back to 0) at the set timeout intervals. The communication report error is 1, meaning “Exchange Stop at Timeout”, which is normal, as the serial port is dead (No LED light).
I have also noted, when the problem is present, that the %S20 = 0, meaning that there is no Index overflow present. Same applies for %SW125, as it does not return a DEF3 code for index overflow.
I am really stuck, as I cannot figure out the source of this problem. The only thing that crosses my mind, is that all the cables for the Modbus RTU communication are simple cables, for internal panel wiring and not twisted pair shielded ones. The longest cable run for the Modbus cables is 3m (all the Modbus RTU devices are located inside the control panel). As a last resort I will try to change the cables with twisted shielded pair 2x0.75mm2 cable.
Also, I will try to log the %S20, and %SW125 also, for further monitoring and troubleshooting.
In the meanwhile, any ideas and recommendations are welcome.
For your convenience, I have attached some screenshots of the serial port configuration, and of the program.