General

• I ensured all of our classes have the "Plc" prefix, as I did encounter situations in which very generic type names had collisions and I had to use the fully qualified class name (including the package name). The "Plc" prefix reduces this risk.
• Introduced a PlcFieldRequest / Response classes, allowing PlcRequests and Responses that don't use field information (When calling functions, for example)
• Removed the "RequestItems". Now the data for the plc read responses is contained in the PlcReadResponse/PlcWriteRequest itself.
• Added the concept of a named-field which is in general a Field description combined with a string alias.
• All sub-types of the PlcFieldRequest/Response use these aliases to reference the field they want to access. Resulting in an API that is more similar to JDBCs RecordSet.

...

• As mentioned before, I introduced a new Level PlcFieldRequest/Response which deals with request/responses which target fields (such as read, write, subscribe).
• The requests contain a Map of Named-Fields
• The responses contain a reference to the corresponding request
• The responses contain a response code for every field in the request
• A PlcReadResponse also contains a map of byte data that contains the raw data.
• (The data should be in a general format shared by all drivers, so the drivers requiring special formats need to convert this when constructing the objects)

PlcReadResponse & PlcWriteRequest

• The getObject() is a convenience method to return values of the natural type determined by the field definition itself. This is the smallest possible type fit to contain the PLC type.
• The setObject() is a convenience method. Actually thinking about it a little bit more, we might even have just the setObject version and get rid of the rest.
• A "typeConverter" is passed in by each driver, that handles the encoding/decoding of values for that particular driver.

Example Code

Here comes some example code to demonstrate how a Programm using this API could look like.

...