On the V2.2 card the results are:-

STATUS = 8304 (no connection made). I establish connection from the TCP client. Status goes to 8181 (job in progress) for a short period and the 8180 (no data to receive). I then fire off a 12-byte packet from the client. You can see that the STATUS alternates between 8181 (job in progress) and 0 (job complete) on alternate cycles. When the status is 0, the NDR bit is set and the LEN is shown as 2 and data is correctly transferred to the DB. The ERROR output remains at 0 throughout. After 12 cycles, all data is received and the STATUS returns to the 8180 (no more data) value. All this is completely as expected. The reason you get a 2 byte read instead of a one byte read per call is that the DB manager allocates the memory in words, so even though you only have 1 byte, the DB is actually 2 bytes in size. But no bother, it still proves the point that it works fine on V2.2.

On the V3.0 card the results are:-

STATUS = 8304 (no connection made). I establish connection from the TCP client. Status goes to 8181 (job in progress) for a short period and the 8180 (no data to receive). I then fire off the same 12-byte packet from the client. The STATUS alternates between 8181 (job in progress) and 80B1 (destination area invalid) on alternate cycles. When the status is 80B1, the ERROR bit is set. The LEN value remains at 0 throughout and no data is transferred to the DB. This continues forever regardless of however many cycles I leave it for.

I have tried the test in OB1, and OB35 (at 100ms and 2000ms). The result is the same; it works in V2.2 but not V3.0.

It the DB is setup to 12 bytes in size, it works fine. So it looks like it is possible to receive less data than the buffered ammount in V2.2 but not in V3.0. In V3.0 it looks like you have to receive the full buffer in one call. This is stupid as you cannot be sure how much data there is in the buffer ahead of time.

It looks very much to me that someone has made a mistake in the new firmware.

Any ideas anyone?

It seems that it is connected to using port 502. I have changed it to use a different port (port 1000), and now it is working correctly. Now what is special about port 502 I hear you ask? Well port 502 is the default modbus TCP port.

So my guess is that in the new firmware, they have decided to handle the data differently on port 502 (assuming that it is modbus), and maybe doing some protocol parsing or similar, meaning that you have to have the data pointer setup to the correct size for a modbus header (i.e. 6 bytes). This is fine unless you happen (as I have) to have written your own modbus driver and want the raw data off the wire to do your own protocol parsing.

Nowhere in the documentation is there any warning about not using port 502, or that the port is reserved in any way. If I am correct in saying what I have postulated here is indeed the issue, then this is a very, very poor piece of design.

So now we know exactly what the issue is can someone please explain why it is happening?