Sign in to follow this  
Followers 0
kopitalk

Modbus TCP event driven

7 posts in this topic

Hello, can a Modbus TCP be event driven? I.e. rather than cyclic updating of Modbus data, the Modbus data is updated only when the data is changed.

Share this post


Link to post
Share on other sites
Hello, No. There is no exception reporting in the MODBUS protocol. Other protocols do have exception reporting.

Share this post


Link to post
Share on other sites
As Mark said, no - there is no mechanism in the Modbus protocol to facilitate this. That said, from the server (slave) side, there isn't much you can do since the server requires a request by the client (master) before it will respond with anything. From the client, when writing values to servers, this is possible depending on the client.

Share this post


Link to post
Share on other sites
Thanks for the reply. I'm polling 120 slave devices comprising meters and digital inputs. In commissioning I don't have control to make sure every slave device is alive. As my PLC is continuously polling, those devices which are not powered up would slow down the polling process and eventually causing the PLC to hang. Is there any workaround so that the PLC will just skip those dead devices and continue polling the rest? My error handling is to handle exception from the slave, but how to handle if the slave is not even alive? Currently my refresh time is 100ms and refresh time violation is 500ms. Thank you for any suggestion.

Share this post


Link to post
Share on other sites
Hello, The PLC should not hang. Just take much longer. If 50 or more slaves are not responding it will appear to stop. Do the math 50 X 500 mills. It might cause huge problems if the PLC runs out of sockets. >so that the PLC will just skip those dead devices How would the PLC know it is dead without attempting to communicate with it? It is like calling someone on the phone. Until you dial the number and wait for the response you have no idea if they will answer. You could keep a table of which ones are alive and when it is dead only check it every X minutes. When it comes back clear the entry in the table. Another option is to split the slaves up into smaller chunks. Try to split the slaves up on more than one socket. One slave per socket would be the best but that is not normally an option on a PLC. Those are the only options. It is the nature of the protocol. MODBUS is simple to implement and work with but, it has some limits, as all protocols have limits. I wonder if the "hang" issue is your timeout is shorter than the socket connection timeout. TCP first sets up a connection, then the protocol (MODBUS) can send the request; get a response, so on. For example, if the socket has a timeout of 60 seconds and you time out at 500 mills and try to move on the socket will stay "used" for another 59 1/2 seconds. In a very few seconds you could use all the sockets of the PLC and have major trouble. I have seen PLCs with 2 sockets maximum. Edited by Mark-

Share this post


Link to post
Share on other sites
Mark's suggestion of building a table of dead connections that you can retry every so often is a good one. I would go that route. Just curious, what brand of PLC? Whose meters?

Share this post


Link to post
Share on other sites
Thanks for your input, Mark. Obviously I'm quite new with this stuff. I'm not sure what 'socket' thing you're referring to but the PLC I'm working with right now only comes with one Ethernet port configurable for Modbus TCP. I follow your suggestion to break up the slaves into smaller groups but I'm not sure how to create the table you mentioned so I put error counter instead. After 10 error counts I disable the polling of that device until it reaches 30 counts when the PLC retries polling again and the counter resets. The lag is still there during initial scanning and retries but I think I don't have choice on this, do I? By the way the 'hang' issue turns out due to 'cycle time violation', i.e. the running time of my polling task exceeds the task class cycle time, which I think it's due to time outs from many dead slaves. I'm using B&R PLC, the 70x meters are modbus RTU connected to 7x data concentrator cum modbus TCP gateway, the 50x digital input modules are connected to 4x modbus TCP/RTU gateways as well. So practically my overall speed is capped to RTU, which is set to 9600bps.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0