Hello again!
Now we need some more help from you! It is all about the same customer and server, still our biggest, and now even bigger. During recent year, the system has grown further, and the OPCLabs client is now handling about 95000 items through 5 different OPC servers from about 50 locations (buildings). The system was also quite stable, until the latest expansions a few months ago, but recent months we have experienced some problems. It seems like there is some kind of memory leak. One month ago we decided to upgrade to 5.12, and implemented the new client in our application, we also changed api interface from using _itemchanged and _operationcompleted to the new _multipleitemschanged and _multipleoperationscompleted event. That part works well, but we still have the same memory leak problems with the new client. easyopccl.exe is consuming about 300 MB RAM after server has been restarted. But after some days this has increased, not linear, some days there is no change, other days more, and then, maybe after one week or two the system is running very slow because there is no available memory, easyopccl.exe is consuming 1 GB, and we have to restart the server. (also remember that our webserver application consists of a number of 32bit ActiveX controls, and the operating system limits 32bit memory consumption to about 3,5 GB in total 32bit program space, even on 64bit servers). This has been the situation for about 3-4 months. Its seems like the same problem exists on all our servers using OPCLabs client, but most of those systems are much smaller than this, handling maybe 10-20000 items, and on those servers, the memory consumption is not a problem, because it is still much lower than 1GB even after one month, and most of the servers are restarted monthly. Monthly restart would also have been acceptable in this case.
All OPC servers except one are located on separate Windows servers in the network and OPCLabs communicates with them through Matrikon Tunneller, and we get the server failed-error 1073442815 from time to time from different systems. We suspect that this might has something to do with networks and opcservers disconnecting/reconnecting(?) That easyopccl in some cases are doing a new internal Add on all items after reconnect, or something like that and grabbing more memory ?
Because of the problems with program crashes described earlier in this thread, we have also changed some of the default OPCLabs settings. (attached). So far we have also been using same settings with 5.12, and have not tried to change settings back to default, or other settings.

Just wanted to say that our server is still running fine, after 10 days! Thanks for good advice, we will consider changing also these parameters, but update rate now seems satisfactory for all items.
One more question: Do you have any opinion about using Remote DCOM instead of Matrikon Tunneller. So far, we have been using Tunneller, because of reconnect-option. We had to use it anyway, even on local servers, because there was no reconnect in out old OPC-client. With EasyOPC, this has changed, and I have now been testing connection to a remote server simply using DCOM, and it works fine. Communication is even reestablished after server restart. So we consider using this solution for new projects, and save heavy license costs.
Have a nice weekend!
Best regards, LRS

Hello,
Yes, we are using the out-of-process type of the component. The server has a 16-core (8 phys.) CPU, and running Windows Server 2003. Lots of memory available. None of the processes comsuming lots of CPU.
Must also inform you that last restart of this server was 3 days ago, because our customer did a major upgrade of their network's firewall security policy. Before the restart, we had also been "cleaning" our project configuration to remove some references to non-existing variables that caused error messages each time the system was restarted. (One of these variables was also part of a time program, and therefore the opc client did a new subscription, following a removal, of this item every minute.) Since then the system has been stable. Everything working fine. There has been no errors, except a few messages about "Server Failed" (ItemChanged Error -1073442815), for different systems (corresponding warnings in event log), but each time the client has been able to reconnect to these OPC servers, within a few minutes. (Think these are caused by temporary network problems). If the server also survives Monday (lot of user activity then), then we get very optimistic.
Anyway, Yes maybe we are stretching both VB6 and EasyOPC to the limit, and we are of course aware that we cannot expect unlimited capacity of any software, at least not at these prices. But as I said, regarding to the many settings available for EasyOPC, it would have been nice to know a little bit more about how they work, than the information you get in the help available runtime. Now when you know a little about our system, do you have any recommendations? (except rewriting - we will, but not yet!).
Best regards, LRS

Hello, and thanks for quick reply!
With reference to your answer on the other support: "3. After some period, the component will re-try with the same ItemID again. This is to allow for OPC servers that change their configuration over time. If this succeeds, you will start receiving ItemChanged callbacks for that item with the data obtained from the server."
The removal of invalid items is done by intention in our application, to avoid these exceptions returning. I.e if we start time program or logger on non-existing items. If OPC configuation is updated we have other reinit-functions in our solution that can be used to attempt to re-add these items. We just want to make sure that our client is only dealing with existing data.
Regards, LRS