Dear Mr. Zahradnik,

thank you for your support. I really would like to provide some callstacks, but as I use the COM version from my Delphi program, the stacks are not very readable, except for my own code.

Most other threads belong to the ntdll and clr.dll, when I take a look into it in the "process explorer". In my Delphi IDE, I can only identify your threads, because the stack refers to .NET framework:



And as I assumed before, some WaitForMultipleObjects statement is waiting for something to happen which does not. There is one more thread which refers to the .NET framework which has a WaitForSingleObject on top of the callstack. I don't know if that could help you any further?

I could maybe provide a test program if that helps. Then you could use it with some modified version of your lib which creates log files or something?

Best regards,
Ralf Herrmann

And again, I have to correct my assumption, that is has something to do with the Siemens OPC server. I could reproduce it on both sometimes, but the Siemens server session hangs more often. This is probably a coincidence.

Some short explanation on my program:

My program creates several instances of OPC clients, one for each server. I set the Isolated-Flag = true to get independent instances. My program creates one thread for each client, where the read/write operations are executed (ReadMultiple, WriteMultipleValues). Before each operation, I ping the server and only perform the following read/write operation on success. That already helped a lot. But I guess it's still a problem, when the connection is lost in the wrong moment. The good thing is, only one instance blocks and only one thread is locked when it happens. All the other ones are still running.

I tried the following workaround: After the detection of a thread hanging, I kill it (not recommended though, sometimes the application shuts down directly), free the OPC client and create a new client and thread. But even then, I can't reconnect. That might be like this due to the internal structure which I don't know. Does this information help you in any way to get the reason for my issues?

Can I collect some diagnostic information for you to get on track? I also tried on a different computer with different OS, but the problem occurred as well.

If there is no other possibility to get it fixed, I will probably have to go for one process for every OPC connection which I can probably kill and recreate with less damage. But that's not a nice structure in my opinion and more difficult to handle due to interprocess communication that would be needed.

I also did some more testing, using another OPC server device of a different manufacturer. With that, I couldn't reproduce the error as well.

It seems, that it is an issue of the integrated OPC server in the Siemens Touchpanel. I posted another thread here, where I described problems with using the secured endpoints on the Siemens Touchpanel. You told me, that the server does not meet the OPC standards very good. Maybe this issue happens due to some differences from standard.

Would it be helpful for you, when we send you a device for temporary testing? Then you could make your library more tolerant against this connectivity issue. Siemens panels are widespread and maybe it might be relevant for other users, too.

Maybe it made less problems because of less read calls from my application. I also tried to add some error handling in my code to prevent read calls if the server cannot be pinged. Although it is not recommended in your manual to add some own error handling. But maybe it helped in this case.

I use QuickOPC 5.40.315.1 (version of the dlls in the program folder).
The server uses opc.tcp: protocol.

I just tested the readmultiple function, and there is no freeze problem there. If I disconnect my network cable and reconnect it again, it takes 5-10 seconds and the communication is running again. Maybe this helps you finding a possible bug with the single read function.

Edit: I also get it freezing with the multiple read function. It seems to be a timing issue, when exactly it is getting disconnected...