Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Trapping / recovering from errors in the SDK

More
21 Apr 2016 11:43 #4007 by support
We have made the fix. Please try a recent build of QuickOPC 5.35 from www.opclabs.com/products/quickopc/downloads (it should identify itself as 5.35.1173.1 or higher).

Note that we have not actually tested the behavior in question - lacking a server that would send us such data. But the fix was not complex and should hopefully work. You should now get DateTime.MaxValue for "offending" values.

Best regards

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 12:28 #4005 by support
Thank you - then you should have no problem with the fix, as it would be just a new build of the same version. You will just reinstall QuickOPC and rebuild with the new assemblies.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 08:32 #4004 by Rich
the Full Product Version is 5.35.442.1

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 08:27 #4003 by Rich
Cheers, Sorry about missing the build number, we are using 5.35 Build 442

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 06:27 #4002 by support
There are several issues in here. None of them is your fault.

The underlying problem is that .NET-s DateTime range cannot fully represent all valid FILETIME values; and the FILETIME structure is what OPC "Classic" uses to represent various timestamps. The FILETIME is essentially a 64-bit (unsigned) integer.

But, the DateTime is wide enough to cover all "reasonable" dates. The OPC server has apparently chosen to use some extreme FILETIME values to represent some special states. There is nothing in Windows or OPC specs that forbids doing this, although I would argue that it can be inferred from the OPC specs that it is not a good idea. Zero FILETIME is not a problem - it convert to a valid DateTime (January 1, 1601) already. The problem is therefore in big values (or, when FILETIME is treated as a signed integer, in values like -1), because they go over the DateTime.MaxValue (which is 23:59:59.9999999 UTC, December 31, 9999).

And, on our side, we have not covered this case correctly. It should not throw in the way it does. It should do something better. You currently have no way of trapping it; neither you actually should be required to do it.

The question is what to do in such case. It would be ideal to have some way to indicate that the problem has occurred, but I am not sure how, but it would require a change in the API which we cannot do at the moment. I am making a note for future consideration. For now, we will make a fix that will convert all FILETIME-s that are too high to DateTime.MaxValue (which you can then detect if so required). And, no exception will be thrown.

I will post here when the fix is available - should be hopefully by end of the week.

BTW, just for record, the exception message (which comes from Microsoft conversion function) is not really appropriate either - it says "Not a valid Win32 FileTime", but there really aren't any invalid values (msdn.microsoft.com/en-us/library/system.runtime.interopservi...mtypes.filetime(v=vs.110).aspx ) - just values that cannot be converted to DateTime.


Regarding the QuickOPC version: Thank you - but I actually needed one more digit to the right. The reason I have asked is that we can only provide a fix to the current version, which is 5.35 (and of course it will be present in all subsequent versions). You can determine the full version e.g. by looking at the first page of the install Wizard (or from the filename of the setup package), or from the properties of any assembly, or from the accompanying documentation files, or by clicking "About" in one of the Demo applications.

Best regards

Please Log in or Create an account to join the conversation.

More
19 Apr 2016 17:53 - 19 Apr 2016 17:54 #4001 by Rich
QuickOPC 5.3 and .Net 4.5
Last edit: 19 Apr 2016 17:54 by Rich.

Please Log in or Create an account to join the conversation.

More
19 Apr 2016 17:28 #3999 by support
Which QuickOPC version are you using please? I will answer then.

Please Log in or Create an account to join the conversation.

More
19 Apr 2016 15:40 - 19 Apr 2016 17:28 #3997 by Rich
We have a program that works fine with various OPC AE simulators, However, when we run against a "real" server we, very rarely, get the following error, which takes out out program.

Is there anyway of extracting some more information about what caused it so we can do some further investigation with the vendor.

Is there a "good" way of trapping these and recovering (discarding that message if needed)
Unhandled Exception: System.ArgumentOutOfRangeException: Not a valid Win32 FileTime.
Parameter name: fileTime
   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at OpcLabs.EasyOpcRaw.AlarmsAndEvents.RawEasyAEClient.MakeNotificationEventArgs(CEasyEvent* Event, EasyAENotificationEventArgs& notificationEventArgs)
   at OpcLabs.EasyOpcRaw.AlarmsAndEvents.RawEasyAEClient.MakeEventArgs(CEasyEvent* Event, EventArgs& eventArgs)
   at OpcLabs.EasyOpcRaw.AlarmsAndEvents.CAEInnerPump.PreprocessEvent(CAEInnerPump* , CEasyEvent* Event)
   at CEasyAbstractPump.PreprocessEventList(CEasyAbstractPump* , CList<CEasyEvent\,CEasyEvent const \&>* EventList)
   at CEasyAbstractPump.ExecuteEvents(CEasyAbstractPump* )
   at OpcLabs.EasyOpcRaw.AlarmsAndEvents.CAEInnerPump.process(CAEInnerPump* )
   at OpcLabs.EasyOpcRaw.AlarmsAndEvents.RawEasyAEClient.EventsProcess()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()
Last edit: 19 Apr 2016 17:28 by support. Reason: formatting

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.067 seconds