s7netplus: getting exceptions when reading bytes with single request

This seems to be because of the stricter response integrity checks from 0b6226327b5f62138f4ee2583f690f6c89393e26 . Those are a good thing because otherwise you would not be sure that the communication was successfull.

The underlying cause is probably the RedExact problem which we have been discussing these past days, where a tcp stream can return early with less data than requested.

Just as a note: I do read/write single-bytes in my production code as well (“handshakes” to see if the PLC has new data), and that does work just fine in general.

Your message is quite strange. You get 15 bytes, which is the core response, with 0xff at position 14 which indicated status OK.

Since you request exactly 1 byte, I do think 18+1 = 19 is the correct amount of bytes to expect, since the payload is created in ReadBytesWithSingleRequest by the following line: Array.Copy(s7data, 18, buffer, offset, count);

But since you do net get a TPKT exception (which we would get when the stream returns EOF and the stream gives less bytes than the payload sice specified in its header), the PLC is telling is that this truly what it thinks the payload should be. And it does look okish, it’s just too short.

Thanks for the info guys. Good to hear the issue is solved. It’s quite interesting that you were actually running into this while I don’t seem to encounter this issue with Sally7 which takes the old approach from S7NetPlus of reading once only, and we’re actually using this in production to control machines (so not just reading, but a lot of writing as well) even at some 24/7 facilities. Does mean I should probably apply the same fixes there though.

I’m closing this issue because the actual issue is solved, however I absolutely endorse further discussion. Also, feel free to reopen this issue if required or to open a new issue for seperate problems/discussions.

The exceptions in your log come from the underlying .NET Socket, and they will get the error message from the operating system. So not much we can/want to do here, it just looks like your PLC or network connection for that specific PLC is sometimes down for about 10 to 20s. The first reconnection attempt does not succeed, only the second 20s after the initial read error does. After that it works again.

Interesting that you connect to the plc/plant from outside. At my workplace we usually try to place our data aquisition directly onto a server in the plant. But that is often quite a pain since nobody wants to get IT involved, so having a VM sounds nice. With .NET Core one could even move all of it to some docker container running on linux… Well maybe someday we are able to do that as well 😛

I looked at the data for your first PLC (Konti2) and got:

mean   | 1030,32383076923
var    | 27,2124341841329
stddev | 5,2165538609443
min    | 1021,1355
max    | 1046,2091

which looks quite decent and reliable. I assume that the amount of bytes you transfer for Konti2 is somewhat large and that is the reason the execution time is so much longer than the other ones.

Anyway, thanks for the data. It does look like this works quite reliably for now. And since you do not only read raw bytes but also seem to serialize them, that also hints at not getting any errors in the underlying hardware, otherwise you would probably get wrong values and exceptions on the more complex, non-numeric types.

Can you retest against 0.7.0?

We’re looking into fixing this. I will be on holiday for a week, I’m not sure if I’m picking up any changes or PR’s in that time, but otherwise I intent to fix this soon after. These messages are really useful though because now there’s actually something we can diagnose when people report issues.

Thank you. I just want update the information I have got while testing version 0.5.0 and 0.4.0.

With version 0.5.0 the exception is excatly the same. With version 0.4.0 it is an “index out of range” exception

S7.Net.PlcException: Der Index war außerhalb des Arraybereichs. —> System.IndexOutOfRangeException: Der Index war außerhalb des Arraybereichs. bei S7.Net.Plc.ReadBytesWithSingleRequest(DataType dataType, Int32 db, Int32 startByteAdr, Int32 count) — Ende der internen Ausnahmestapelüberwachung — bei S7.Net.Plc.ReadBytesWithSingleRequest(DataType dataType, Int32 db, Int32 startByteAdr, Int32 count) bei S7.Net.Plc.ReadBytes(DataType dataType, Int32 db, Int32 startByteAdr, Int32 count)