Hello,
[.....]
The behavior you described is by design. You question is covered in "Data Types" chapter in the Concepts document (I am including a copy below, highlighting the relevant line). Basically, 32-bit unsigned integer may not work in all .NET languages (see e.g.
msdn.microsoft.com/en-us/library/12a7a7h3.aspx ), and that’s why we convert it to 64-bit signed (which can hold all values of 32-bit unsigned). For most usages, this should not cause problems, but if you do need 32-bit unsigned integer, you may convert the value back.
On our “possible future enhancements” list, we have the ability to switch this off, but currently it is not implemented.
Data Types
OPC Data Access specification is based on COM, and uses Windows VARIANT type (from COM Automation) for representing data values.
Note: Some OPC servers even use certain VARIANT types that are not officially supported by Microsoft.
Microsoft .NET Framework has a different concept, and all data is represented using an Object type. Conversions between the two are available, but not always fully possible.
In addition, not everything that can be stored in an Object can later be processed by all .NET tools and languages. Microsoft has created so-called Common Language Specification (CLS), which has certain rules and restrictions that, if followed, guarantee cross-language compatibility. Public QuickOPC.NET components (assemblies) are fully CLS compliant, and that includes the way the data types are converted to and from OPC types.
QuickOPC.NET converts data from COM to .NET according to following table:
COM type (VARIANT)
.NET type (Object)
VT_EMPTY
System.Object (null reference)
VT_NULL
System.DBNull (singleton class)
VT_I2
System.Int16
VT_I4
System.Int32
VT_R4
System.Single
VT_R8
System.Double
VT_CY
System.Decimal
VT_DATE
System.DateTime
VT_BSTR
System.String
VT_DISPATCH
System.Object (not tested)
VT_ERROR
System.Int32
VT_BOOL
System.Boolean
VT_VARIANT
converted type of the target VARIANT
VT_DECIMAL
System.Decimal
VT_I1
System.Int16
VT_UI1
System.Byte
VT_UI2
System.Int32
VT_UI4
System.Int64
VT_I8
System.Int64
VT_UI8
System.Decimal
VT_INT
System.Int32
VT_UINT
System.Int64
VT_ARRAY | vtElement
System.Array of the converted vtElement type
Types that are highlighted do not convert from COM to their “natural” .NET counterparts, because the corresponding .NET type is not CLS compliant. Instead, a “wider” type that is CLS compliant is chosen.
Types not listed in the above table at all are not supported.
Strings are internally represented in Unicode wherever possible.
Best regards,
Zbynek Zahradnik, OPC Labs
Original Message
From: M.
Sent: Thursday, March 01, 2012 8:21 AM
To: Zbynek Zahradnik
Subject: AW: Data Acqusition Problems
Hello!
I have technical question concerning the return-data type using the following call:
OpcLabs.EasyOpc.DataAccess.DAVtq dacResult = dac.ReadItem(ServerDescriptor, new OpcLabs.EasyOpc.DataAccess.DAItemDescriptor(tag));
The returned object (dacResult.Value) is normally of Type of the Data-Object in the PLCs Memory and so returns objects like System.Single, System.Int32 which is so far so good to proceed further.
When reading a Siemens S7 DWORD of 32bit width via Softing OPC-Server (The OPC-Tag so get the Item is: DB258.DBD8:DWORD), the dacResult.Value is of type System.Int64 which is in fact not precise an may cause some trouble in the next steps.
Thanks for your support in advance!
Best Regards
M.
