Modbus TCP Client Hang

[belias]

I had an issue this morning where a TCP Client instruction in a stage program hung without properly executing the JMP on Success or JMP on Error.

It seems similar to the TCP Server hang reported here:  https://forum.hosteng.com/index.php?topic=3324.0

I read through the posts before troubleshooting, and I tried the suggestions posted.  Here's the sequence I followed:

1.  Found program hung on S3; did not jump to S5 or S90 (see attached)

2.  Checked the following:

ST145 Off
ST146 Off
DST411 9346708
DST51 0

3.  Try restarting main stage program --> no difference

4.  Try re-initialize PLC I/O --> no difference

5.  Create new Modbus TCP Client Device, and write change to PLC (no program changes to use the new device yet, only the addition of the new device) --> no difference

6.  Change MRX instructions to use the new TCP Client Device, write to PLC --> MRX instructions now work!  **However, now I'm getting PL-Link errors to the other 2 PLCs on the network (showing PL.Rate around 0 to 1); this was not happening before.

7.  Re-initialize PLC I/O again --> all better.  Both the MRX instruction and the PL.Rates are normal.



I haven't restarted the PLC, so as far as I know the first (troublesome) Modbus TCP device is still in some kind of error state.  I'm not sure if that's helpful for troubleshooting.   If so, please let me know.


Thanks,


Brian

[BobO]

2.9 firmware should fix this. It's due out soon.

[belias]

Great - thank you!!

[Bolt]

Maybe this will push BobO to release the new firmware! 

[RBPLC]

BobO, what is/was the root cause of the Modbus/EIP issues? You said previously you thought it might be associated with changes to accommodate the ECOMEX modules. Is/was this the case?

[BobO]

BobO, what is/was the root cause of the Modbus/EIP issues? You said previously you thought it might be associated with changes to accommodate the ECOMEX modules. Is/was this the case?

We added something new, don't remember what, that benefited from reusing the TCP connect/disconnect code. While refactoring for reuse, a hole was introduced that would allow a permanent state machine hang. Since everything that created outbound TCP connections used the same base code, they could all be affected. It only showed up when the connection failed, but once failed, it takes a reboot to fix. And since it was only during failure, occasionally, normal regression test didn't reveal it. Fix was simple once identified.

[RBPLC]

2.9 firmware should fix this. It's due out soon.

Not to give you a hard time, but when do you think this will be? I've got a long term project starting next month and if the comms issue has been for sure resolved, I'd like to get my controllers updated before the project starts so I don't have to potentially deal with this. 

[BobO]

2.9 firmware should fix this. It's due out soon.

Not to give you a hard time, but when do you think this will be? I've got a long term project starting next month and if the comms issue has been for sure resolved, I'd like to get my controllers updated before the project starts so I don't have to potentially deal with this.

We're in beta now. Just trying to clean up a few more things. And FWIW, I won't ever say "for sure". Been at this too long and been surprised too many times. I'm certain we duped two issues, and I'm certain we greatly improved both. Time will tell whether it's perfect.