m340 modbus

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.

Thanks for the insight Lare. I will try this alternative also.
The case is that the that from each slave I have to read consequtive registers from different memory areas at the slave.

So for each slave, I will use the required READ_VAR blocks, all configured with the same GEST variable.

I ll work it around and see the results.
 
Your screen shot is pretty small, but noticed that you don't use R_trig and activity bit before read/write blocks.
Because of this there is several messages sended when blocks is called, it can be main reason for problem.

read_var.jpg
 
Your screen shot is pretty small, but noticed that you don't use R_trig and activity bit before read/write blocks.
Because of this there is several messages sended when blocks is called, it can be main reason for problem.

Hello again Lare. In my application, I use the falling edge of the activity bit of each slave's GEST in order to increment a counter and poll the 8 slaves. In order to give you an idea about the structure I have attached the following image displaying my logic of polling the slaves.

M340 MODBUS PROBLEM.jpg
 
I think that it isn't work as you think. Activity bit is "1" several plc cycles before it falls back to "0", this means that you read_var is sending queries to slave several times before is gets reply to first sended query. If your disable your inc block, you see that your read var is sending Modbus querys all time, it should only send one query, if counter isn't updated.

Add R_trig block between you comprare block and read_var, even better if you also add activity bit as on jpg attacment before. That way you can be sure that only one modbus query is sended to slave when counter changes values.
You can check it from TX/RX led of card. It should only flash one time for send and soon after again for receiving.
If you slow down your communication, it is easier to see if there is several modbus querys for one sequence number. Also if you unwire you slave there should be only two blinks for one slave, first original modbus query and after timeout the retriet query. Pretty sure that you see more than two blinks for one slave now.

If you look help files of read and write_var blocks, you notice that ST example code is same than jpg attachment
 
Last edited:
Thanks Lare. For sure, by observing the SER COM led, it blinks/flashes really fast.
I will try the example above on your jpeg. Just to sort something out, the activity bit on
your jpeg example, is the activity bit of the current slave to be polled, correct? (for
example for slave#1 it is the activity bit of GEST_SLAVE1?)

I will try the following attached logic:

M340 MODBUS PROBLEM2.jpg
 
All activity bits should be zero, before calling. You need to add them all before block. (That way communication sequence number can mofied also with animation table).

I would also change little bit your counter inc code. Inc with fall edges works, but if some activity bit gets stuck, then your communication stops.

For activity bits I have maded force resets with TON timer and Reset block. If activity bit stays over 10s then I reset activity bit.

With these mods it should communicate years without problems.

p.s You are moving timeout value 2s to GEST parameters alsewhere on program?

counter.jpg
 
Last edited:
All activity bits should be zero, before calling. You need to add them all before block. (That way communication sequence number can mofied also with animation table).

I would also change little bit your counter inc code. Inc with fall edges works, but if some activity bit gets stuck, then your communication stops.

For activity bits I have maded force resets with TON timer and Reset block. If activity bit stays over 10s then I reset activity bit.

With these mods it should communicate years without problems.

p.s You are moving timeout value 2s to GEST parameters alsewhere on program?

Thank you very much Lare for the insight. I will implement your suggestion
first, and later as an additional measure I will replace the caples with
twisted shielded pair.


As for the 2 sec timeout to 3rd GEST parameter I set it to 20 (2sec) elsewhere in the program, at a general initialization section.
 
Last edited:
M340 Modbus problem

Following the previous posts, I provide an update here as I visited the site
today to implement the changes. Here are some initial findings:

1. Before performing any fix or alteration I rechecked everything regarding
the comms. During my visit, I had the chance to observe the problem of
communication loss appear again live. This time I rebooted the system (power
off and on again), but before doing so, I integrated in the code, monitoring
of index overflow. More specific, when detecting %S20, I set a %M bit, in order
to verify if I indeed have index overflow. And after an hour or so of operation,
kaboom 🔨 again, the comms of all the 8 RTUs were gone simultaneously.

And I noticed that the %M bit was set, meaning that there was indeed an
index overflow (although the CPU did not halted as %S78 didn't turn to 1.

Anyway, I went on to implement the changes at the cabling I mentioned. Now all the RTUs connections have shielded twisted pair cables.

I went on implementing the changes mentioned by Lare also. Till the time I
left the site there was no error in comms observed. Anyway I ll wait and
see what it turns out. 🤾

I ll post any further findings here guys.
 
M340 Modbus

As promised, I am back with the latest results and solutions for the problem.
After implementing the method proposed by Lare (thanks again), and
downloaded the new program, the Modbus communication executed
correctly, but unfortunately after some hours the communication crashed
again.

So this situation led me to the decision to add a new NOM card to the PLC
rack, and separate the Modbus RTU devices from different manufacturers
(Ducati & Siemens) to separate groups. So the first group consists of 4 x
Ducati energy analyzers + Schneider M221 PLC, and the second group
consists of the 3 x Siemens Simatic drives (1 x V20 & 2 x G120).

The 1st group is connected to the Modbus port of the ME40 P342020 CPU and
the 2nd group is connected to the 1st port of the NOM card. After performing
this alteration, the communication crash problem did not reappear again
(both with my original implementation and the implementation proposed by
Lare). The system is now up and running for more than one week, and no
communication problem has appeared at all during this time.

Even if this solved the communication problem, I am still puzzled about the
root cause of the problem:book:. Nevertheless it is a solution after all
(y).
 
o_O Thinking still hardwire timeout of 100ms. Can you change it to 1s and see if it is root cause?

Maybe there is some querys sended to new slave before previous is sended back from slave. Oldest installations with communication like this are way over 5 years without any problems.

What is PLC scan time?
 
o_O Thinking still hardwire timeout of 100ms. Can you change it to 1s and see if it is root cause?

Maybe there is some querys sended to new slave before previous is sended back from slave. Oldest installations with communication like this are way over 5 years without any problems.

What is PLC scan time?
Lare, I had changed the hardware timeout to 1sec. When I did so,
the communication crashed almost about every 10 to 30 minutes
in both 2 read_var software implementations (the problem
was more intense at the 3 Simatic drives -many comm errors
etc.).

I know its odd, but when I returned it to 100ms everything returned
to normal, and the problem was eliminated with the addition of the
new NOM card.

Regarding the PLC scan time you mention, I don't recall it right now,
but I ll sure check during my next visit to the site.
 
That sounds odd. Maybe NOM card is defective.
Is it possible that you send your communication sections. (No need to whole PLC program). (PM-message)
 
Hi Lare, how you doing?

I'm with a similar problem and I think you can help me. We can talk on my post? I think it will be better.

http://www.plctalk.net/qanda/showthread.php?t=114114

I've tried to reset the activation bit, it resets but my communication don't return.

Thanks, Nilo Ramirez.

Hi!

I reset all management parameters everytime before plc program calls read_var or write_Var block. I have used separate management
parameters to every read/write_var block, but using same management parameters to all read_var block is ok, if you don't call
multiple read_var blocks same time. (I think that you can call up to 8 read or write_var blocks same time, but I call only one
block at time. How many blocks you can call same time depends of hardwire)

Timeout value is also defined on hardware properties like you said, but you can set timeout value to smaller via plc
program/managemet parameters. If you leave timeout value to zero (Most significant byte of third management parameter) => PLC
program uses timeout value from hardware properties (same place, where you can change baudrate, parity etc.)

Activity bit is first bit of first management parameter. (least signifant bit of first parameter). You are right, activity bit
should automatically reseted back to "0" after timeout by read_Var block , but sometimes activity bit remais it's "1" state also
after timeout and communications magically stops, if activity bits are condition to call communication blocks. So I have programmed
separate reset for activity bit. (Force reset)
ex. hardware timeout is 1s, but if activity bit is true for 10s of some reason, which it shouldn't be possible => PLC program
resets activity bit and communication starts again.

Take a look to help files of Unity, if you look read_var help file from communications library, you can see example which is writed
on ST format, you can also use find command: "Example including execution check" and you should find example of using read_var
block... Anyway using read and write block on unity is little bit tricky, I have learned most of this by doing

If you search management parameters from help files, you should find documention, which tells meaning of every management
parameter.

P.s If second management parameter have value 16#0004 it means incorrect destination addrees error
(managemt parameters are mux of two different bytes, least and most signifant byte have different meaning, so you should divide
management parameters to seperate bytes before you look them. Second management is mux of communication report (least
significant byte) and Operation report (most significant byte).
 

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
269
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
382
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,638
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,574
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