Sign in to follow this  
Followers 0
cadomanis

QJ71MT91 Question

3 posts in this topic

I have recently deployed several system that use the QJ71MT91 Modbus TCP master to communicate with some Beckhoff BC9100 Modbus bus controllers. when everything is working well, the system has an increduble response time and everything is great. The problems come in when we have something go wrong. Let's say one of the BC9100 slaves gets umplugged. The PLC seems sometimes able to get the unit bck online, and other times not. I did some wireshark capures and see that firs the MT91 resends the modbus request, and then after several tries it sends a RST to the coupler. Finally, after getting no ACK back from the coupler, it starts send out SYN on 10 second intervals. I can make some sense of this from the timeout settings explained in the MT91 manual, but it doesn;t ever talk about the SYN messages. I can find references to RST and FIN messages only. If anyone else has experience with the MT91 modules, I would love some advice. I am sure I need to adjust all of the timeouts from the defualts to make our system more robust in a failure mode, but not sure where these SYN messages are coming from. Thanks, Chuck

Share this post


Link to post
Share on other sites
Hi. If you plug in your slave and wait "long enough", will the MT91 card to start to communicate with the specified slave again? SYN, RST, FIN have nothing to do with ModbusTCP. They are control flags and are part of the basic TCP/IP stack. They are used for establishing, maintaing, teardown connections. In other words, first the MT91 will establish a TCP/IP connection (SYN is the first message in this sequence). If the MT91 card receives a correct TCP/IP response (with an SYN+ACK flag), the MT91 will respond with ACK and a TCP/IP connection is established. Then the ModbusTCP communication will begin. Therefore, the SYN messages are normal and they should not affect the Modbus communication itself. If you plug in the slave, and wait "long enough" the Modbus communication should operate as normal again.

Share this post


Link to post
Share on other sites
Thanks. This is helpful. Kind of what I figured on the TCP side. Was surprised with all the details in the manual that the don;t mention this. Thanks. C

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