m340 modbus

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.

M340_read_var_in_program.jpg M340_serial_port_configuration.jpg
 
Thank you for your reply tragically1969. The M340 CPU is a new model, ordered just a month ago, so it must have the latest firmware. Anyway I will check and verify the firmware version the next time I ll visit the site.
 
Thank you for your reply tragically1969. The M340 CPU is a new model, ordered just a month ago, so it must have the latest firmware. Anyway I will check and verify the firmware version the next time I ll visit the site.

I wouldn't be so sure, we get several different versions delivered at the same time in some shipments.

You should really be using twisted pair for Modbus, also make sure you have a terminating resistor on the end, its shouldn't matter in a small network but you don't mention what the slaves are, so can be trickier than others, for instance are you requesting data too often from them ?
 
I wouldn't be so sure, we get several different versions delivered at the same time in some shipments.

You should really be using twisted pair for Modbus, also make sure you have a terminating resistor on the end, its shouldn't matter in a small network but you don't mention what the slaves are, so can be trickier than others, for instance are you requesting data too often from them ?

Thanks again for the insights. I will surely check the firmware version of the CPU next time I visit the site. Replacing the cables with shielded twisdted pair is the next step I consider, as it is not too tricky (longer cable run in panel is not more than 3 meters).

The slaves I am reading data from are:

5 x Ducati LCD96 Power Meters
1 x Siemens Sinamics V20 Drive
2 x Siemens G120 Drives

The data are requested from the slaves at a cyclic fashion. With the current settings, each devices is polled at an interval of about 1.5 to 2 seconds.

Thing is, that the problem in its nature is intermittent. So far it can vary from about 10 min after power up to 3 days in continuous system operation.
 
Hardwire timeout 10ms*10 (100ms) sound too little.
Also so called programmed timeout (3rd Gest parameter) should be more than configured hardwire timeout.

Change Hardwire timeout something like 1s (100msx10ms). Because you have retries selected to 1, then your hardwire timeout is 2s (Querys)*timeout parameter = 2s

Change also 3rd Gest parameter someting like 30. Gest parameter have multiple 100ms so 30 is 3s, which is more than cards hardwire timeout parameter
 
Hardwire timeout 10ms*10 (100ms) sound too little.
Also so called programmed timeout (3rd Gest parameter) should be more than configured hardwire timeout.

Change Hardwire timeout something like 1s (100msx10ms). Because you have retries selected to 1, then your hardwire timeout is 2s (Querys)*timeout parameter = 2s

Change also 3rd Gest parameter someting like 30. Gest parameter have multiple 100ms so 30 is 3s, which is more than cards hardwire timeout parameter

Hello Lare.

The 3rd GEST parameter is set to 20 in the program, for all GEST variables (so I have 2s timeout).

Moreover, by monitoring all the GEST variables in an animation table, the timeout value is set succesfully to 20, and the operation of the activity bit as well as the operation report and comm report react as they should when the proroblem is not present. When the problem is present, the communication report (LSB of second parameter) of the management table returns 0x01, indicating "Exchange stop on timeout".
 
Do all the communication blocks have separte Gest variables or are you using same gest parameter for all blocks?

Schneider's recomend is to use same Gest paramter for all blocks on same communication port.
 
Do all the communication blocks have separte Gest variables or are you using same gest parameter for all blocks?

Schneider's recomend is to use same Gest paramter for all blocks on same communication port.

Lare thanks for the insight. For each READ_VAR block I use a separate GEST variable.

If it is possible that you have available the reference of Schneider's recommendation to use only the same GEST variable for all the READ_VAR blocks on the same serial port?

Anyway, I will add your recommendation on my upcoming actions to rectify the problem.
 
Not exatcly, but noticed on Hot standby system years ago, that switchover didn't work if serial blocks had several Gest parameters. It didn't worked after PLC switching.


From help files, READ_VAR , Communication Library, assistend screen.


"Report

The report is an array of 4 integers.
NOTE: be careful not to use several identical memory areas for report tables, otherwise the variable read function may not work"


Same for Write, communication library, assistend screen

Report

The report is an array of 4 integers.
NOTE: be careful not to use several identical memory areas for report tables, otherwise the variable read function may not work.
 
Have used only one GEST parameter since that for serial communications. On serial only one block can be active one time so that makes also program easier.

Of course if you wan't check communications by looking GEST variable values, then you need to take account which block have called on sequence.

For ethernet I use several GESTs and call several communications on same time. Works 100%
 
Have used since that only one GEST parameter for serial communication, on serial only one block can be active one time so that makes also program easier.

Of course if you wan't check communications then you need to take account which block have called on sequence, if there is only one gast parameter used for communication/port.

For ethernet I use several GESTs and call several communications on same time. Works 100%

For the TCP connection, as I mentioned there is no problem so far, neither had any problems before.

In my case, the use of different GEST variables is done also to detect communication faiure of independent slaves. If I only used one GEST variable for all the slaves and READ_VAR blocks, I wouldn't be able to detect communication failure of a single slave unit.

Of course, to all the GEST variables I use, different %MW are assigned, and there are no overlappings in memory.
 
It is still possible to check communications failure of single slave.

You need to compare Communication report and operation report values, when block have called and activity bit falls from "1" to "0" (move values to different addrees range from Gest group)
Change sequence to different block only after little pause when activity bit goes to "0".
That way you have only one communication block active one time and you have time to check operation report and communication report before them are updated of another block call.
 

Similar Topics

I have 9 field devices, three METSEPM5110 power meters and six ACE949-2 rs285 interface modules. I want to read this Modbus rtu data through rs485...
Replies
8
Views
270
I'm using M340 (Schneider Electric) as modbus master. It works fine but if there is a disconnection with the slave, it stops working even after...
Replies
2
Views
383
Hello all. I am trying to read out the values from a Carlo Gavazzi EM340 energy analyzer via Modbus communication. The S7-1200 PLC has the CB1241...
Replies
29
Views
3,640
Hello, this is a message for specialists in Schneider, I am trying to establish communication in modbus tcp between a schneider M340 (P3420302)...
Replies
2
Views
1,576
Hi, I hope everyone's week is going great. I have ADAM-6217 Analogue module which supports Modbus TCP and I am trying to get the AI values of the...
Replies
2
Views
1,610
Back
Top Bottom