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.

After an unsuccessful BrowseBranches() (COM Timeout exception comes), the next one (good) needs a big time before succeeding.

More
01 Sep 2014 05:31 #2202 by Emilio
Hello, probably the best way is to try to get the "bad" server, I will ask our FF Team, they might have some installation somewhere, alternatively it might have something to do with some CommDTM Setup, then I can ask another Team for help.

I'm willing to continue some further analysis, I would only postpone it a little bit because we are currently under release (until end of September) therefore I shall keep this issue open and go ahead as soon as we have released our Beta...

If I find an installation of the bad server before then I will send it to you immediately.

Thank you very much for support,
with my best regards,
Emilio

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

More
30 Aug 2014 16:46 #2198 by support
Regarding the second issue, i.e. where the timeout for BrowseNodes was not taken into account and the method could block forever, this is now fixed internally. The fix will be released with a next version that comes out, i.e. QuickOPC 5.32.

Best regards

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

More
29 Aug 2014 12:22 #2197 by support
I attempted to reproduce the first issue reported, but was unsuccessful. I have modified our simulation server to hang for 90 seconds in the initial OPCServer creation. And I have written a following test program:
using System;
using OpcLabs.EasyOpc;
using OpcLabs.EasyOpc.DataAccess;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main()
        {
            var client = new EasyDAClient();
 
            Console.WriteLine(DateTime.Now);
            try
            {
                DANodeElementCollection nodes1 = client.BrowseBranches("", "OPCLabs.KitServer.2");
            }
            catch (OpcException opcException)
            {
                Console.WriteLine(opcException.GetBaseException().Message);
            }
            Console.WriteLine(DateTime.Now);
            DANodeElementCollection nodes2 = client.BrowseBranches("", "Kepware.KEPServerEX.V5");
            Console.WriteLine(DateTime.Now);
 
            Console.ReadLine();
        }
    }
}

The output from the program is:

8/29/2014 2:13:50 PM
Cannot connect Data Access client (timeout).
8/29/2014 2:14:50 PM
8/29/2014 2:14:51 PM


So, it takes one minute to timeout on the "bad" server (which is expected - that's the default value), but the subsequent browsing on the "good" server still completes quickly.

Can you confirm that my test is implemented the way you have wanted it be done?
I will not be able to resolve it without having a repro, or further information.
Would you be able to put the OPC Analyzer there and collect the calls and their timings, or somehow provide me with access to the "bad" server?

Note that this does not affect the second issue (timeout not applied in BrowseNodes, possible infinite block) - as I said I know what is going on, and I plan to resolve it.

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

More
28 Aug 2014 05:17 #2192 by Emilio
Yes, actually this problem, either the original one or the one caused by my test implementation, has no big impact on the reality. We shall not deal with such servers, therefore there is no pressure from our side.

I originally reported it mainly because it might be a side effect of something else, it is always good to investigate unexpected behaviours, they might reveal more important issues.

We do not need a quick fix at this point.

We shall eventually upgrade to newer versions sometimes, if you can just keep us informed about this point, it is completely fine for me.

Thanks for support and best regards,
Emilio

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

More
27 Aug 2014 14:39 #2188 by support
I think that now we are dealing with a different issue.

With the new server you made, it is probably so that the browsing method is blocked. QuickOPC should eventually time out. But I have discovered that, while the time-out do apply with operations, there is a problem in the implementation of the browsing methods, and they do *not* time out. I was planning to fix it in the next version; for this, I do not need further detail to it. But I would like to know how big a problem that may be for you, and how quickly do you expect be fixed.

However, the original problem report you gave seems different. There, the server probably blocked itself earlier, maybe in the class factory (result of CoCreateInstance), or a similar place. For this, our timeouts actually work well, which is indicated by the exception you received, i.e. "Cannot connect Data Access client (timeout).". The only problem there was the delayed browse on the "good" server afterwards, which is something that I did not expect, and wanted to investigate further.

Do you agree?
Best regards

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

More
27 Aug 2014 08:31 #2184 by Emilio
The timeout when trying to BrowseBranches on the bad server is about 1 minute.
Here below the full exception message:
The last lines are concerning my implementation...

{OpcLabs.EasyOpc.OpcException: OPC operation failure. ---> System.Runtime.InteropServices.COMException: Cannot connect Data Access client (timeout).
--- End of inner exception stack trace ---
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.CheckComResult(CHResult* hResult)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.BrowseNodes(ServerDescriptor serverDescriptor, NodeDescriptor parentNodeDescriptor, DANodeFilter nodeFilter)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.BrowseNodes(ServerDescriptor serverDescriptor, DANodeDescriptor parentNodeDescriptor, DANodeFilter nodeFilter)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.BrowseBranches(ServerDescriptor serverDescriptor, DANodeDescriptor parentNodeDescriptor, String elementNameFilter, String vendorFilter)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.BrowseBranches(ServerDescriptor serverDescriptor, DANodeDescriptor parentNodeDescriptor, String elementNameFilter)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.BrowseBranches(ServerDescriptor serverDescriptor, DANodeDescriptor parentNodeDescriptor)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.BrowseBranches(ServerDescriptor serverDescriptor)
at EH.ImsOpcBridge.Service.Implementation.BO.OpcManager.BrowseRecursive(EasyDAClient opc, ServerDescriptor serverDescriptor, DANodeElement nodeElement, OpcItem opcParentItem) in d:\1Data\Views\RTC\DA\ImsOpcBridge\DesignImplementation\EH.ImsOpcBridge.Service.Implementation\BO\OpcManager.cs:line 155
at EH.ImsOpcBridge.Service.Implementation.BO.OpcManager.ReadOpcAddressSpace(String serverName, OpcItem& opcItem, UInt32& error, Exception& exception) in d:\1Data\Views\RTC\DA\ImsOpcBridge\DesignImplementation\EH.ImsOpcBridge.Service.Implementation\BO\OpcManager.cs:line 103}

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

More
27 Aug 2014 07:59 - 27 Aug 2014 07:59 #2183 by support
Thank you.
The symptoms you describe now (infinite block) are different from those before.
For the original symptoms, can you please answer my question in the post from yesterday:

3. It times out after cca 20 seconds (please send me the exception message and details - it is really important)

Thank you
Last edit: 27 Aug 2014 07:59 by support. Reason: typo corr.

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

More
27 Aug 2014 07:37 #2182 by Emilio
Actually we bought the server EXE from a company (Advosol in the US) and we do not have the source code.
The DLL that you also see contains several methods that we have to implement, it is our link between our implementation and the server EXE.
I put the infinite Wait in an initial call that gets the OPC address space.
I don't remember now which OPC call is the corresponding one...

Probably it is still in the first CoCreateInstance, but I can't be sure unfortunately.

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

More
27 Aug 2014 07:20 #2181 by support
Where exactly have you put the infinite waiting in the "bad" server? (which COM or OPC method?)

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

More
27 Aug 2014 07:13 #2180 by Emilio
Hi, I've just coded a bad OPC server, which never returns to the caller.
The behavour is not exactly like with the "real" bad OPC server, because I don't know what exactly happens there, but it is almost the same, anyway it can help you in finding what is happening.

- Unzip the attached file in any folder.
- Run RegServer.exe (as Administrator under Windows 7).

You can use the following sample code to test:

var opc = new EasyDAClient();
var descriptor = new ServerDescriptor("Endress.TestBadServer.1");
DANodeElementCollection nodes;

try
{
nodes = opc.BrowseBranches(descriptor);
}
catch (Exception exception)
{
// Here it hangs until COM timeout.
var t = exception.Message;
}

descriptor = new ServerDescriptor("any-good-opc-server");
nodes = opc.BrowseBranches(descriptor);

// it never reaches this point, or after a HUGE timeout, I didn't wait long enough.
opc.Dispose();
Attachments:

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

Moderators: support
Time to create page: 0.061 seconds