TCP Driver - Sleeping?

General Discussion
1

Aloha!

I'm getting a consistently odd behavior from (I think) my TCP Driver and/or device. I don't know how to resolve.
We have a Fairbanks FB2560 Truck Scale that prints INBOUND data to a ticket and (about 10 min later) OUTBOUND data to same ticket.
I've configured the scale to transmit the ticket data via its COM4 (Ethernet) port. The scale's COM4 port outputs around same time ticket prints.
This device is connected over Ethernet to Ignition via standard TCP Driver.

An OPC string tag is mapped to the Fairbanks scale. The tag receives INBOUND data (130+ chars), then (about 10 min later) OUTBOUND data (110+ chars).
This works.

However, after 27 trucks without missing data, it begins to miss data.
Once started, it does this on every 5th truck, until I reset the Device Connection.
The missing data is only on the INBOUND string. Only about 2-5 characters (from the end of the of the 130+ character string) show up in the tag.
If I simply do a "Save" on the Device Connection in Ignition, the problem doesn't occur...for 27 trucks. On the 27th truck, it returns.

There is never a problem with the printed tickets. All the data is always present on the tickets.

I've examined the frequency of occurrence, time of day, radio interference, amount of data, values in the data, everything I can think of.
I have no indication that there is anything wrong on the Fairbanks side as the scale never shuts off and every ticket prints correctly.

Suggestions/thoughts?

2

What's the message delimiter configured as on the Ignition side?

Leaving a Wireshark capture running from device reset until the problem occurs may help.

3

Thanks Kevin!
Delimeter Type = Packet Based
Delimeter = blank, I never entered anything here.
Wireshark - good idea!

4

Ok, Wireshark is still probably a good idea, but Packet Based as the message delimiter when using the TCP driver is operating on hopes and prayers.

TCP is a stream-oriented protocol. The application layer see and consumes a stream of bytes, not packets. So what the driver is really doing in this mode is dumping whatever happens to be in the socket's buffers at the time read() was called on it, which in the end will depend on your operating system's TCP stack...

To reliably receive data on TCP it must be framed in a meaningful way. It's interesting that it seems to happen reliably on the 27th message for you, but there's probably some quirk or implementation detail deep in some other layer responsible for that.

5

So, then Character Based with some sort of SOF/EOF?
Is there an expected standard for Start/End?

6

Yes, ideally you can set it up to be character-based.

There's no standard, but ideally you can configure your scale to terminate with a new line or something (\n).

Or, packet-based works great over UDP, if that's an option.

7

I remember seeing delimiter characters in the Fairbanks configuration. I'll try the Character Based and add in a /r or /n.

Thanks Kevin!!