This issue will be handled by e-mail.

We suspect that these crashes are often related to OPCLabs not handling network / OPC Tunneller problems properly. On one of our servers e.g., we have had daily problems recently. OPCLabs is connected to 3 different systems on this server, one local system handling 46000 opc items, and tho other systems via Matrikon Tunneller handling about 500 and 100 opc items. According to attached event log dump, there are several warnings from one of the smaller systems before easyopc crashes. The night before there were problems with the other system and the same thing happened. When OPCLabs is only connected to local servers it is much more stable, even if crashes also happen then, sometimes.
Of course, some network problems can be hard to handle. We have also seen that event Matrikon Explorer sometimes is not able to connect to the remote systems then, and sometimes even "hanging" (need to restart servers), but such problems should be solved in a more "smooth" way, so that potential problems should be isolated to only the system not responding, and not lead to program crash. "In the perfect world" there should be no network problems either, but I am afraid we have to live with that.
(At crash time, the whole 32x program memory consumption was about 2 GB, so there should be plenty left. Today we upgraded this server from OPCLabs 5.21 to 5.22, maybe something has been solved?)

Best regards
LRS


(not able to add file to forum, so sending you a screen dump on mail, separately)

You are not doing it wrong. We do not have statistics from our customers as to how many items they handle, but you are significantly over what we use in our internal tests or what the customers mentioned.

The "Client LRU Size" and "Topic LRU size" setting should be larger than the number of servers/items you need.

There have been no changes in version 5.22 compared to 5.21 that were directly addresing this, but there are always some fixes, so you are always welcome to try the newest version. Assuming that you are licensed for 5.21, you are also licensed for 5.22.

If the memory consumption on the system or of the EASYOPCL process itself is near the limit and there may no more memory to allocate, I can imagine that these situations may not be always well handled, leading to crash. Not sure if this is truly the situation, though.

Have you tried using the In-process component? That would lead to each client process having its "smaller" copy of EasyOPC (assuming they are connecting to different items mainly).

I am out of office this week, will be able to better work on this since next Tuesday.

Best regards

Hello again!

(our solution with opc clients built-into VB6 ActiveX controls has earlier been described in thread "EasyOPC and VB6", or something like that, think that one disappeared with your server migration, but anyway)

We now have about 50 customers running this solution, and mostly it works fine, but from time to time we have had some EasyOPC crashes. This has happened on different of our customers servers.

Attached error message that appeared today, on one of our biggest servers.

On this server, there are 11 (VB6) ActiveX controls using EasyOPC 5.21 to connect to 7 different systems.
We have split the biggest of these systems into 5 clients, each with 8000-12000 opc items, connected via EasyOPC to a local OPC server (EXOopc from Regin AB)

The other ActiveX controls are hosting one opc client/system, each with 200-2000 items, via EasyOPC and Matrikon Tunneller (The OPC servers reside on separate communication servers)

In total EasyOPC on the main server is handling about 70000 items.

The OPC clients are using the event _MultipleItemsChanged to read from and _InvokeWriteItemValue to write to EasyOPC.

Some EasyOPC options are set different from default because of some "queue size errors" in earlier versions with default settings).
(the forum won't accept my attachment, so here they are:
Default event queue size: 200000
Topic request queue size: 200000
Topic response queue size: 200000
Link callback queue size: 100000)
Also unchecked "Abandoned interval minimum")

- Are we doing something wrong, or is there something buggy in EasyOPC ?
- Are there other settings that might help ?
- Have there been made any improvements on these issues in 5.22 ?
or
- We are aware that our application in total is consuming near the memory limit of a x32 application, and we can't take the advantage of x64 because it is still a VB6 ActiveX solution.
Are we simply stretching the limits (too far) both for VB6 and EasyOPC ?


Best regards,
LRS