Professional OPC
Development Tools

logos

Random Disconnect from OPC server

More
13 Nov 2012 13:35 #1095 by algorithmica
Hi,To add some information to this I recently added the error detection code to my writing procedure as well. Please see here my code:The vector "values" is set like so values->SetAt(1, CComVariant(3.14));Until now I just didCComSafeArray saResults;saResults.Attach((*dac)->WriteMultipleItemValues(machine.c_str(), server.c_str(), CComVariant(*ItemOutArray), CComVariant(*values)).parray);after that but now I added the control code for(i = saResults.GetLowerBound(0); i <= saResults.GetUpperBound(0); ++i) { IDAVtqResultPtr DAVtqResultPtr(saResults); if(DAVtqResultPtr->Exception == NULL) // only if this is NULL, is the result valid. { IDAVtqPtr DAVtqPtr(DAVtqResultPtr->Vtq); // contains value, timestamp, quality. value = DAVtqPtr->Value.dblVal; // retrieves the value. It *must* be a double as the variant will contain an R8 value! entry->data = (float) value; // now save values to the passed entry. } else // we have an exception. { // Handle failure here: you can use properties such as COMExceptionPtr->HResult, COMExceptionPtr->Message. ICOMExceptionPtr COMExceptionPtr = DAVtqResultPtr->Exception; printf("WRITE %s at ", conv.convert_time(now).c_str()); _tprintf(_T("%d: failure: %s. "), i, COLE2T(COMExceptionPtr->Message)); _tprintf(_T("source: %s. "), COLE2T(COMExceptionPtr->Source)); _tprintf(_T("result: %d\n"), COMExceptionPtr->HResult); LPCTSTR str_message = COLE2T(COMExceptionPtr->Message); LPCTSTR str_source = COLE2T(COMExceptionPtr->Source); #ifdef UNICODE wstring w_message = str_message; wstring w_source = str_source; message = string(w_message.begin(), w_message.end()); source = string(w_source.begin(), w_source.end()); #else message = str_message; source = str_source; #endif *log << conv.convert_time(now).c_str() << "(WRITE) at " << i << ": failure: " << message.c_str() << ". source: " << source.c_str() << ". result: " <HResult << endl; entry->data = info->special_value; } }for which I received a crash. Please see the screenshots in the attachment. Perhaps this has something to do with the problem?Thank you!

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

More
13 Nov 2012 08:33 #1094 by support
Hello,
thank you for the detailed information. You have made great work and collected everything possible. It does not yet give me precisely the information needed to directly figure out what the problem is, but that's not your fault. It still helps. I will now study that calls stacks and other information and let you know the outcome.
Best regards

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

More
12 Nov 2012 09:04 #1093 by algorithmica
Hi there,The debug version of my program and of your new version are running and produced the first system stop. I've opened the debugger and made six screenshots of what happened.The first two screenshots are the ones saying that the program has stopped. Then I go into the debugger and you can see the whole call stack in image 3. So ReadMultipleItems raises an error. I drilled into this in image 4 and show my function that calls it in image 5. Image 6 is the same as 4 except that I held the cursor over _hr to display its result. The German text means "Exception error by server."I should note that timeout errors were also produced by the program but these did not lead to a system stop, so this stop may be our problem. Is this enough information to diagnose something? Can I do more? Thank you!Best, Patrick

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

More
08 Nov 2012 08:39 #1090 by support
Hello,
we have released the version 5.20. It can be downloaded from the Downloads page of our Web site now.
You can download the Debug build of the Out-of-process EasyOPC-COM component (just the .EXE) from www.opclabs.com/onlinedocs/201 ... . Please re-register it (using /RegServer on the command line) after replacing.
For a license file for version 5.20, please send an email request to This email address is being protected from spambots. You need JavaScript enabled to view it., stating either the old serial number, the purchase date, invoice number, or whatever we can use to find the original purchase.
Best regards

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

More
05 Nov 2012 08:45 #1085 by algorithmica
Thank you for those options!Getting the new version would be great. If you can give me both a debug and release build of this new version, I will also try the ASSERT route.I will try to run my application in debug mode and catch the error when it happens in addition to the above.That way we can do three out of your four suggestions in parallel. Unfortunately, I cannot give you access in any way to the application as what it works with is restricted access, e.g. a virtual machine. Reproduction is also my goal and I have tried but so far, I do not know the circumstances under which this happens yet.Best, Patrick

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

More
04 Nov 2012 17:59 #1084 by support
Hello,
thank you for detailed information. This may be difficult to diagnose. I am currently consider following options; I do not know what is and what is not possible at your side, so I am presenting them all, and you can tell me what is the acceptable way to go.

We should be releasing a new version (5.20) this coming week. There was no fix to this particualr problem, but there are certain differences in internal processing of OPC requests, so the behavior may be different. Due to the issue you have, you can have this upgrade free of charge, even if you haven't purchased the maintenance. So you mught want to test it, but there is no guarantee it'll work.
If you have a way to reproduce it somehow so that it can be passed to us, that would of course be the best solution. Such as a virtual machine image that has the problem.
I can give you a Debug build to deploy. The idea is that if there is a hidden internal error, it may manifest by an ASSERTion instead. But it has less performance, and the assert may not appear...
If you can debug the application when it is frozen, you could tell us at least what's the nature of the "freeze". It looks like that there may be a deadlock inside the component, but attaching a debugger would at least tell us which method it is blocking in. Or maybe you already know it - isn't it in the ReadMultipleItems? Because, you say that the error message is printed out, but "then" it stops: There has to be some moment when it stops - so is it when you re-enter the ReadMultipleItems methods maybe?

Regards,

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

More
01 Nov 2012 20:33 #1070 by support
Hello,
will answer - please bear with me.

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

More
31 Oct 2012 16:27 #1067 by algorithmica
Hello !The problem has occured several times now and the symptoms are always the same. Every time there is an exception, I print out the Source, Message and HResult of the ICOMExceptionPtr object.Over time, I have been able to record the following exceptions where all of them have the source equal to "OPCLabs.EasyDAClient.5.1." -1073430525 (Topic not updated for the first time (timeout).) -1073430526 (Cannot connect topic (timeout).) -1073430527 (Cannot connect Data Access client (timeout).) -2147024891 (Access Denied.) -1073430509 (No message here.) -2147023174 (The RPC Server is not available.) -2147023170 (Remote procedure failed.)These are all non-fatal and the program recovers on its own. So far, well done!However, the exception -1073430509 with the message "failure: Read not completed. This error indicates that it could not be verified that the requested read operation was completed during the timeout period. ..." leads to a freeze of the program. At the point that this message is output by the program, nothing happens anymore. Neither does my program continue to work, nor does the OPC interface perform any reads or writes and no more errors are output either. A manual re-start of the program has to be done. When the program is manually re-started, everything works just fine again.Unfortunately, I have not been able to determine any kind of causation for this. Sometimes it takes only days for the fault to occur again and sometimes it takes many weeks.The OPC Server that I'm reading from is by Simon Process Engineering GmbH, version 2.2 dated August 2012.Any help would be much appreciated.Thank you! Best, Patrick

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

More
09 May 2012 18:54 #855 by algorithmica
Thank you! I have implemented that on the machine. Now we have to wait until the error appears again. This may be a number of days. I will post when I have the result.

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

More
09 May 2012 15:19 #854 by support
You have a statement in your code:
_tprintf(_T("%d: failure: %s\n"), i, COLE2T(COMExceptionPtr->Message));

This is printing out the Message property of the COMExceptionPtr.
I just want you to print out COMExceptionPtr->Source (a string) and COMExceptionPtr->HResult (a long integer) as well.
Best regards,

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

Moderators: support
Time to create page: 0.222 seconds

      

 Recommend this on Google