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.

How to obtain last error.

More
19 Oct 2012 09:21 #1065 by Jack_Duijf
Hello,
Thank you for the suggestion.
I made the folowing changes, and they seem to work ok now.

aValues := ::oOpc:ReadMultipleItemValues(::cOpcServer,::cOpcClass,{cItem})
If Valtype(aValues) = "A" .and. Len(aValues) >= 1
oIValueResult := aValues[1]
If oIValueResult:Succeeded
uRet := oIValueResult:Value
Endif
Endif

Thanks for the support,
Jack Duijf

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

More
18 Oct 2012 14:03 #1064 by support
If the caller (XBase++) is effectively invalidating the HRESULT-s we are returning, you can use ReadMultipleItems or ReadMultipleItemValues instead of ReadItem/ReadItemValue. The difference is that ReadMultipleItems/ReadMultipleItemValues returns result objects that contain the Exception property, and it in you find the IException object you are mentioning.
ReadMultipleItems/ReadMultipleItemValues does never directly "fail" (return an HRESULT other than S_OK) except for invalid arguments (a programming error) or very rare "catastrophic" conditions.
So, if XBase++ is replacing our HRESULT from ReadItem/ReadItemValue with something of its own, this workaround should prevent it from doing so.
If. on the other hand, XBase++ generates that error on its own, not just when WE return some kind of failure, then you may still be getting the same error with this workaround. Whether in such case the output results objects will contain valid information depends on X++.

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

More
18 Oct 2012 12:02 #1063 by Jack_Duijf
Hello,
After reading the QuickOPC-COM reference, i found IException.
So i suggest a method "GetLastException". This would return a lException, or a list of lExeptions. (after ReadMultipleItems)
Regards,
Jack Duijf

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

More
18 Oct 2012 10:15 #1062 by Jack_Duijf
Hello,
Thanky for the reply.
I seems that the Active-X wrapper as supplied bij Alaska Software generates this error code. So no help there.
Would it be possible to add a method "GetLastError" to the COM interface??
This should return a object with the last error information. (Thread safe)
- Errornumber. (0 = No error)
- Description
- Machinename
- ServerClass
- ItemId
- Timestamp
- etc. (other info that could be usefull)
This object is reset after every succesfull operation.
Regards,
Jack Duijf

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

More
17 Oct 2012 18:27 #1061 by support
I should also add that there is a possibility that XBase++ transforms the error code we generate to this error code; that would mean that the proper error code is "hidden". Do you have a knowledge of how XBase++ handles OLE Automation errors? We can find that out by experiment, but if you knew already it would help.

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

More
17 Oct 2012 18:24 #1060 by support
Hello,
I assume that "-1073446906" mentioned below is the error code you are getting. This code (corresponds to 0xC0048006 hexa) is not directly generated inside our OPC client components. (I have checked the list of codes we use). It can therefore come either from the target OPC server itself, or (less likely) from supporting system calls that we need to make (such as for manipulating VARIANTs etc.).
First thing I would do - ask the server vendor (Siemens) if their OPC server ever generates this error code, and under which conditions.
It the above isn't possible or does not lead to conclusion, we would have to put some more advanced diagnostics in place. This can be either in form of Debug build of our components, or by an OPC Analyzer (a tool from OPC Foundation) that is OPC Client/Server that you can put "in between" your app and the target server, and have it log the OPC calls being made. Both these options mean extra work, so please first let me know whether you can get some info from Siemens.
Best regards
Zbynek Zahradnik

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

More
17 Oct 2012 10:47 #1059 by Jack_Duijf
Hello,
We are using Xbase++ language to access EasyDAClient.
On a reglar base, we can not read data from OPC. We do not know why the read fails.
The same location is read every 15 seconds. This goes ok for many hours.
Suddenly for reasons unknown to me, it fails. After some time it works ok again.
How can i find the reason of the failure?
Regards,
Jack Duijf
::oOpc := CreateObject("OPCLabs.EasyDAClient.5.1")
...
BEGIN SEQUENCE
uRet := ::oOpc:ReadItemValue(::cOpcServer,::cOpcClass,cItem)
// All ok, no error here
RECOVER USING oError
// Some error here
// uRet = nil
// oError:Operation = "ReadItemValue"
// oError:Parameters = ("","OPC.SimaticNET.1","S7:[S7 connection_2]DB200,x0,3")
// oError:oscode = -1073446906
// oError:subsystem = "Automation"
AddToLog("Read", cItem,"Read-error")
END SEQUENCE

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

Moderators: support
Time to create page: 0.063 seconds