Modbus Comms issues

[eman5oh]

I am having an issue with Modbus comms dropping out for up a minute or so at a time on a BRX running firmware2.10.3 that did not an issue on firmware 2.10.1. I am not sure if the firmware change caused the issue or other minor code changes that were made. See the attached screen shot of system status to see the warnings and errors I am getting. Any advise on how to track down the issue would be appreciated. I noticed that if go to the failing MRX instruction while we are having a dropout both the success and fail bits stay in the off state despite the instruction being set to run every 100ms. the odd thing is this plc is talking to 2 other plc and they do not drop out at the same time, it can be talking to one while the other drops out. The other plc's are also having any issue talking to this one as well, both of the others are BRX's too. I created separate Modbus tcp clients in the device configuration for each of the separate plc's to keep the comms separate.

[Greg]

If ST145 ($QueuesFlushed) is coming on, this means the Ethernet queues were completely full and had to be forcibly cleared to recover. Most of the time this is because a Device isn't being serviced. Are other things talking to this BRX using TCP? Or UDP?

To troubleshoot for starters:

• Monitor DST72 ($FreePackets). This value should hover around 375. If it trends down, turn ON ST300. This dumps info about the network packet frames in use: DST98-399 will contain data of what is using up all the sessions. So if DST72 trends down, this info can be very useful.
• Show status of DST30-37
• Show status of DST40-44,49

[eman5oh]

Thanks for the info on this! The other thinks talking to this plc are BRX PLCs using DoMore protocol, C-More HMI's using the DoMore and protocol, and a software archiver that is using Modbus. We are seeing the issue crop up else were in our network on other PLC's, Terminators and BRX's talking to stride and Protos-x modules as well.  Would setting up a oneshot trigger that if DST72< 300 , store the values of DST30-73 and DST40-44,49 be a good starting point on debugging this?

[Greg]

...Would setting up a oneshot trigger that if DST72< 300 , store the values of DST30-73 and DST40-44,49 be a good starting point on debugging this?

If DST72 is trending downward, which it should never do, then turn ON bit ST300. This will cause the PLC to fill up DST98-399 with data of what is using up all the sessions.

But just show us the status of DST30-37, 40-44, 49. These have data in them regardless.