RequestedDataType is what we provide to the server when specifying which item we want to access. Defaults to COM VT_EMPTY, telling the server to send us the value using item's canonical data type, defined by the server. You can set it to specific type and the server should then attempt to convert the values to this type. Normally there should be no need for it.
CanonicalDataType is ignored (as documented:
www.opclabs.com/files/onlinedocs/QuickOpc/Latest/Reference/Q...4b7-d3a0-c3a3-ae03f7aed86b.htm ).
ItemType is used with Write's. We get the value from the mapped member, and convert it to this type before writing to the server. The default is typeof(object) thus no conversion takes place.
When the mapped member is of type System.Int64 while the OPC item is a 32-bit unsigned integer (which is what we recommend to stay CLS-compliant), here is what should - ideally - happen, when you do *not* set any of the above described parameters away from its default:
a) When the value goes in a direction from the OPC server to the mapped member (Read, Subscribe): We convert the 32-bit unsigned integer to System.Int64 on the way, and because System.Int64 is larger, it will always succeed.
b) When the value goes from the mapped member to the OPC server (Write): We obtain System.Int64 from the mapped member, and send it to the OPC server. The server, at least according to the newest OPC specs, is supposed to attempt to convert any incoming value to the type it understands, i.e. to an unsigned 32-bit integer in this case. As long as the value is in the valid range, it should be successfully converted and written.
In a non-ideal case, things can go wrong. For example, the server may not be compliant with the latest specs, and will not write values that are provided with different type. This should be resolvable by specifying
ItemType, in this case as typeof(System.UInt32)).
Best regards
