Click PLC Ethernet problems/best practices

Hello, I'm working with some AD "CLICK" PLCs in a telemetry application.

Each PLC is connected to a cellular (LTE) modem with a static IP address and at least 1Mbit speeds upload and down.

The goal is to send about 16 HEX registers (2 bytes each) to a master PLC at a frequency of about once per minute, as reliably as possible, and also receive 16 HEX registers from the master at the same frequency.

The Master PLC is connected to both a cable internet service and a cellular modem, each with a static IP address. I can send data to the Master by specifying *either* of these addresses in the SEND instruction.

There are two problems I keep encountering:

1. The CLICK PLC "send" instruction doesn't seem to work reliably. I have a timer set to 30 seconds. When it completes, it turns on the SEND rung for one scan, and the timer resets.
However, it seems that the PLC requires the rung to be ON for longer than one scan to cause the Ethernet port to send reliably on slower connections. (This setup worked great in the test lab using a direct Ethernet connection to the Master PLC.)

So I set up the "send" rung to stay ON until either 1) the Send instruction sets either the "success" or "error" bit, or 2) a 5-second timer elapses. (I have the Ethernet port configured to timeout after 3 seconds to ensure it either succeeds or fails before the timer elapses.)

This works, but you can tell the SEND is happening multiple times, because the values on the Master PLC will jitter around for the entire time the SEND is active.

This brings me to the second problem:

2. Bandwidth usage. Something is wasting a lot of bandwidth. With the described setup above, I'm seeing a usage of about 2.5 MB per hour (up + down).
I realize there is a small overhead with TCP connections, but the data itself should constitute (16 SEND registers * 2 bytes = 32 bytes) + (16 RECEIVE registers * 2 bytes = 32 bytes)
Total data bytes per cycle = 64 bytes
Total data bytes per minute: 128 bytes
Total data bytes per hour: 128 * 60 = 7860 bytes per hour

TCP overhead equates to about 40 bytes per packet, so 80 bytes per cycle:

Total bytes per cycle: 64 bytes data, 80 bytes overhead = 144 bytes
Total bytes per minute: 288 bytes
Total bytes per hour: 17,280 bytes

This is a far cry from the 2.5 MB per hour I'm seeing.

So I would appreciate your advice on 1) getting the SEND to work reliably without holding the rung ON for a long time, causing a long burst of SENDs and 2) conserving bandwidth.

Thank you!

I have two Click Ethernet application with messaging. One is using a radio modem to remote radios with I/O and the Modbus protocol, the other is a point to point over a nanostation.

I am using a rising edge transition bit to fire the messages.

I found that the messages would not complete if the Task was called too frequently. I ended up changing my Click scan mode to fixed and setting it to 30ms to cure the problem. It has been running for over six months now.

I think there is some quirk in the timing of how the send/receive bits get handled that doesn't work properly if your PLC is running at a very fast speed. In my testing, it would work great for several minutes to an hour and then hang. I have my messages cascading so that as each one completes (success or error bit), the next one gets triggered by a oneshot. I at first added a "bandaid" so that if it stalled for 60 seconds, I would start over (and increment a counter). What I mean by "hang": It would trigger the message and I would never get a success or error bit to trigger the next one. It was not always the same message that would hang. I played around with keeping the enable active longer (like you have done) and saw the same thing occur with multiple messages getting fired off, which was increasing the bandwidth usage of my radio network.

After much experimentation including calling the Task with a timer which seemed to help, I discovered the ability to set the Click scan time to fixed and set the interval.
I gradually increased the fixed interval starting at 5ms and when I got to about 15ms, the problem cleared up completely, so I doubled that value for a little safety margin.

I don't know if this little tidbit will help you, but I do agree that there are some things under the hood that are not as crisply functioning with the Sending bit as the manual had me believe.

Wow, that is a great answer Okie. Thank you very much! I knew something was "off" with the timing of the Send instruction. My program is very small, so scan rates would be quite fast (i.e. 1ms). Brilliant solution, I will try this ASAP.

Again, thank you!

I have also played with the Ubiquity Nanostation between two Click units.
I'm sending 20 registers starting at DS50 and receiving 20 registers starting at DS10.
The program is monitoring the throughput rate. It is currently around 100 times a second. To trigger the send/receive commands, I used a self resetting shift register.

Attached is the sample program.

Regards,