- Separate into Connect and EstablishConnection step.
- Remove redundant null checks for returned data.
- Only assing PLC stream object once we fully established a connection, and Close otherwise.
- Replace sync implementation with Async call.
This is very fragile with time-dependent cancellation, but I don't know of a better way without messing with the code to be tested.
Seems to only work when the test is run as a single run, not when running the whole test suit.
- Do not allow null string to be passed, raise ArgumentNullException.
- Do not allow string whose ASCII representation is longer than the reserved length, since this currently leads to silent data loss.
- Always write the full binary data length of 2 + reservedLength, since that is what the binary representation of that string is in S7 memory, even if some tail bytes are unused by the current string.
I also suspect that S7WriteMultiple would have chocked on that last bit, but I am not sure. There aren't any tests for writing multiple Dataitems right now.
Adjust tests accordingly. Mostly add some tail bytes where necessary, and assert on exceptions where this is now required.
The limit calculations did not match what the send and parsing code expected.
sending request header seems to be 19 byte in general.
Also adjust XML comments somewhat, since max PDU really differs a lot between PLC types, from 240 to 960 afaik.
- Adds true support for 64bit double / LReal datatype.
- Set old Types.Single and Types.Double to obselete. Both class names use .NET types instead of S7 type names, contrary to all other types.
- Remove already obsoleted conversion from DWord to Real. Why is this even necessary?
For users caring about converting from DWord, they can still convert to single. But unless we get LWord support, there won't be a direct conversion to double/LReal.
- Adjust unit tests by removing rounding, testing directly double read/writes.
There is quite a bit of breaking changes at least in the automated Struct and object functions which automatically translate .NET types to appropriate S7 types.
My consideration was that if we ever want to support 64bit types, there is no way against breaking those existing incorrect conversions from 64bit .NET double to 32 bit S7 Real variables.
The read method on a networkstream blocks only until the first byte is available.
It is not guaranteed to read the desired count into the buffer.
This solution tries to read the remaining bytes in a loop and aborts once the
full count is read or the Stream.Read method returns with 0 or less bytes read.
The synchronous read can block indefinitly if the lenght field is larger than the send package.
These unittests fail intentionally as the issue discussion has not reached
a consesual solution. Any solution should pass the unittests added in this commit.
I don't know what the correct expected connection response size is, so I just added checks for the minimal index access by the current code.
This change will just change NullReferenceExceptions into WrongNumberOfBytesException when the PLC response with not enough data for a connection attempt.
This removes the binary reader, and fixes too things:
1. Properly set the data length (previous implementation requested too much, but that did not matter with BinaryReader)
2. Start reading Data after HeaderLength+1 offset, not always at 3.
The previous problem of not being able to use a larger chunk size than 200 was that the complete header building code for the async implementation was incorrect. Specifically, it wrote the package size only as a byte instead of a int16, thus restricting the package size to something < 256.
With the sharing of the Header building code in the previous commits, this problem was resolved by accident, and thus the chunk size can be increased to the maximum value allowed by the PDUSize.
For me the tests work fine even when adjust the "chunk size" in WriteBytesAsync. So Snap7 seems to be fine, at least the current version.
This should probably be tested with some live PLC's as well.
Both Synchronous and Asynchronous need to build the same binary data package to write a bytes array. Move that package building out into a common function.
Also use IEnumerable to pass in data instead of converting it to array and back multiple times. Not that happy with the whole ByteArray class, we could probably just use a MemoryStream instead.
This requires reference types that can be null to be annotated by a ? operator, similar to value types.
This gives the advantage that the compiler can warn against any null dereference exceptions, of which this commits elimits a few.
To make the underlying protocol implementation not any more complicated and to eliminate existing problems, and not that precise error reporting, I replaced some return null statements with explicit Exceptions. This lead to the assumption that those core protocoll functions always return non-null objects if they do not throw, making the PLC code simpler.
Adjust some NotConnected tests to look for explicit PlcException instead of NullReferenceException.
