Add support for custom addressing by supplying a TsapPair to the PLC.
CPU, Rack and Slot properties are still present to preserve backwards
compatibility and to support alternate functionality based on the PLC
type.
- 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.
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.
* Add StringEx.ToByteArray(...)
* Add Serialization.SerializeDataItem(DataItem)
Supports StringEx VarType or offloads to SerializeValue method.
* Use SerializeDataItem in S7WriteMultiple
* Assume string length without header in StringEx.ToByteArray
VarTypeToByteLength already assumed that StringEx declared count for
the number of characters without the header, this now matches that
behavior.
* Add unit tests for StringEx conversions
* Fix incorrect value passed to Encoding.GetBytes
The length must actually be within string limits.
- Remove duplicate parameter code / length (already in initial array)
- Remove separate branch for S7-400 (same as S7-300/1200)
- Change all values to 2-character hex