akbeer (Customer) asked a question.
Setup:
Click Plus PLC (Click A) w/physical Ethernet port and serial Port.
One EA3 HMI connected via serial.
One CM5 HMI connected via physical Ethernet
One UNIX (pymodbus) client/master initiates full time connection to the Click A (server/slave).
Click A (client/master) also periodically initiates a connection to a UNIX client but I don't think this is relevant here.
A second Click (also a client/master) (Click B) that initiates periodic connections to the first Click A, but quite often, like every 500ms via a time driven counter. There are four of these Modbus output blocks, so each is called every 2 seconds. The second Click B is Wi-Fi only.
Most of the time this all works perfectly. Every couple few weeks though the two Clicks cease talking reliably to each other. The next day (after both being powered down overnight) it works fine again. Power cycling the second Click B (Wi-Fi) doesn't address the problem. The one time I've been around to investigate, connecting to Click B with the software it looked like the Click B was almost constantly trying to send on one of the Modbus send blocks to Click A (seemed far longer than 3 seconds (2 x retries, second between) though given retries and every two seconds...perhaps.
I initially suspected Wi-Fi issues, though this doesn't manifest elsewhere w/other hosts and I have no problem connecting to Click B with the software. But, perhaps there are issues with my code/logic being that if the Wi-Fi Click B has to retry, and it is allowed to do so twice after a second each attempt, would it get behind so to say and never be able to catch up? But then, a power cycle should fix that. I'm pretty confident I've left the Wi Fi Click B off for over 60 seconds (the Client Inactivity Timeout on the first Click A), but perhaps I haven't been so patient.
Which all this, leads me to ask, are there too many devices trying to establish/maintain concurrent connections with the first Click A? It looks like the Click supports three concurrent server/slave connections. I count four devices. But, I don't know what sort of Modbus connections the HMI panels utilize (do they open, communicate and close each sync or do they maintain a full time connection). Thus my questions:
How do the HMI panels communicate with the Click?
Is the three concurrent slaver/server connection limitation per physical port or is it three per device/Click (serial and Ethernet in aggregate)?
Does a Click to Click communication failure and subsequent retry basically get canceled/ the next time the same Modbus send/receive command is come upon in a later scan? With some recoding, I could reduce this to two instead of four, or, with more recoding as alluded to below, just one send...
I could and perhaps should rewrite the way that the two Clicks communicate but that leads to another question. One of the reasons it was written this way (the second Click B always being the client/master for all four send/receive commands to the first Click A) was that I didn't want to slow the first Click's ability to initiate a Modbus send command to a different host. The documentation states that there could be a delay if there are multiple sends being initiated concurrently. For instance, if Click A acting in its capacity as the master initiates a Modbus send command to Click B, but that communication attempt gets retried multiple times, does that mean that a second Modbus send command from Click A to the UNIX Modbus server would get held/queued the entire time (so up to perhaps 3 seconds)? Or just for the few ms it takes to initiate the first send?
Please see helpfile CL234 that describes the connection limits. “Unless otherwise noted, connections are independent and can be simultaneous.”
Answers to your other questions:
Q1) Is the connection from “ClickB” to the “ClickA” Port1 Wired, or WLAN?
Q2) “Click B” when the issue occurs, is it still Pingable? Software able to connect?
Q3) What is the status of WLAN system bits and registers? (SC80-SC88 and SD200-SD218)
Q4) Does power cycling “Click A” immediately resolve the problem?
Okay, it looks like the serial connected EA3 to Click A is of no factor here, so just three connections to Click A's Modbus server via Ethernet Port 1 (the CM5, the Linux host, and Click B).
When you say: "After each communication instruction Success or Error the same packet will not be retried again. There is no buffer. If the instruction remains active, a new request will begin." So under Modbus TCP Setup, Configuration as Client (Master), the retries setting does not actually do anything?
Okay, I am understanding that multiple Modbus client/master connections (Modbus connections initiated by a Click to another device) shouldn't really be blocking, at least not for more than a few ms. Correct?
Q1: The connection between ClickB and ClickA is ClickB WLAN to Click A Wired/Port1.
Q2: Yes, pingable and software can connect fine.
Q3: I will have to investigate the next time. Also check the SC92 register.
Q4: This is easier said than done though of course I understand why the question. Will do some more investigation next time it happens.
Thank you!
Yes, the SC92 register was asserted, which would make sense I think given the three separate client/masters attempting to communicate to the Click A server/slave.
I ended up completely rewriting the way these two Clicks communicate. First, I pack copied the coil block to registers which reduced the communication threads from two sends and two receives to one each (I needed to share both coils and registers). Second, I changed the communications from cycling through the four once every half second each to more of a demand/change based approach with a periodic heartbeat send. Third, rather than Click B facilitating all of the communications, it now only sends and Click A also demand/heartbeat sends. Fourth, if I’ve deemed a connection to have failed, I just won’t try again for 75 seconds under the assumption that the opposing Click should close its session by then (after 60 seconds). I’ve run this for ten days w/o hiccup until today. And I only noticed today because there was a small bug that manifested elsewhere when an edge contact for my comm state coil register fell. As it happened four times over a couple of hours I know there were comm issues. But the two Clicks otherwise were happy and worked through the less than reliable communication environment fine and and nobody would have otherwise been the wiser. =)
I suspect that Click A was just getting hammered way too hard and problems manifested in the event of less than perfect Wi-Fi every now and then. This was less noticeable before adding the CM5 (the third Modbus client-master) but became much more so after.
Cheers!