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.