Professional OPC
Development Tools

logos

QUICKOPC.COM and VB6

More
04 May 2012 12:39 #842 by support
Replied by support on topic QUICKOPC.COM and VB6
Hello,
we will investigate this. You might be right that the problem could be related to reconnections, but of course the expected behavior is that these should not caause a memory leak.
Here is the plan:

We will set up a system similar to yours (probably with lower number of items, and some other differences, but with regular simulation of server failures etc.). We will monitor its memory consumption. If we reproduce the problem, we will fix it.
If the above does not give a repro, we will prepare some tools to help investigate on your side. This would not be easy, though.

Please understand that the above will take some considerable time - both to set it up, and then to monitor. Several weeks at least.
Also thanks for the settings screen picture. I need to check whether the "infinite" in "Abandon interval minimum" could not be related to the issue. What does "Huk vekk denne" mean, please?
Note: Error -1073442815 (I think you forgot the minus sign) is 0xC0049001 hexa, which corresponds to following message text:

Server failed. This error originates in the OPC Data Access server. A vendor specific fatal error has occurred within the server. The server is no longer functioning. The recovery procedure from this situation is vendor specific. The application will try to reconnect to the server after a configurable period.

Technical information: The call to IOPCServer::GetStatus on the OPCServer object has returned OPC_STATUS_FAILED in the OPCSERVERSTATUS structure.


It would be useful to know from the vendor why this is being reported.
Regards,

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

More
03 May 2012 12:33 #839 by lrs
Replied by lrs on topic QUICKOPC.COM and VB6
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.

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

More
12 Feb 2011 11:29 #276 by support
Replied by support on topic QUICKOPC.COM and VB6
I am glad it works well.
My reply with regard to DCOM vs. OPC tunnelling is here: www.opclabs.com/Support/Online ....
Zbynek Zahradnik

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

More
11 Feb 2011 15:43 #273 by lrs
Replied by lrs on topic QUICKOPC.COM and VB6
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

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

More
06 Feb 2011 09:36 #265 by support
Replied by support on topic QUICKOPC.COM and VB6
This appears like a "server-type" kind of application, where maximum throughput (number of operations per time unit, also considering the system load) is more relevant than the responsiveness (how long it takes for a single operation to complete), specifically if there are multiple threads/processes making the calls.
For this type of application, in general any setting that is expressed in units of time, or number of objects, can be increased, and one can expect an improvement. Those that can specifically help are:

Garbage collection period, Auto adjustment period: Making them higher will reduce the need to go through large lists and figure out what can be removed or adjusted.
Topic processing interval timeout, Topic processing total timeout: Increasing them will cause the operations be done in larger "chunks", possibly slowing down the individual responses but increasing the throughput.

One final note: As you go into larger applications, and unless there is some special need, ALWAYS make sure that

Client LRU size is at least equal to the number of OPC servers you need to connect to at the same time, and
Topic LRU size is at least equal to the number of OPC items you need to connect to at the same time.

Otherwise, a drastic drop in performance may occur.
Regards, ZZ

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

More
04 Feb 2011 16:23 #262 by support
Replied by support on topic QUICKOPC.COM and VB6
Hello.
A note, before separate reply to the remainder of your text: Error <span style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">-1073442815 (0xC0049001), internally OCK_E_SERVER_FAILED, is "out of our scope", because it is reported by the target OPC server; and yes, we react by immediate disconnecting, and then reconnecting, after some time. The error means that we have called IOPCServer::GetStatus (this is done periodically to check the health of the server), and in the OPCSERVERSTATUS structure returned by the OPC Server, there was dwServerState == OPC_STATUS_FAILED.
The reason for this happening is server-specific, and should be discussed with the vendor of the server.

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

More
04 Feb 2011 16:13 #261 by lrs
Replied by lrs on topic QUICKOPC.COM and VB6
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

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

More
04 Feb 2011 10:20 #258 by support
Replied by support on topic QUICKOPC.COM and VB6
Hello,
obviously there is lot of things to be discussed.
First, let me explain the "expected behavior":

There should be no crash (such as memory access violation), even under heavy load and/or with queues overflowing.
All relevant method calls have an internal timeout, and as such should not block "forever" (or considerably longer than the timeout value is).

So, if you are observing a problem that any the above does not hold, I will try to reproduce it here or figure out the reason in some other way.
I think it is obvious to both you and me that you might be stretching the system to the limit. And, one should be aware every physical system has some limits. Now, if the internal queues get filled, it is in general a normal situation - it may be a sign of temporary high load (in which case increasing the queue sizes will resolve it), or a permanent disproportion between the ability of the producing side and consuming side: if the consuming cannot cope, in long term, with the inlfux generated by the producing side, the queues will keep growing and will always overflow, no matter how big you set the limit.
If you have increased the queue sizes and are no longer seeing queue overflows, it appears that you are "OK" on this side of things. If you, however, cannot find a size that is "big enough", then either we have reached the system limits, or there may be some bug that would cause the work of the consuming side be "blocked" - but if you are still receiving new data, then probably there is no such "block".
Do you have any hints how we can reproduce the problem(s) here? Is there a way to take over your code and make it work e.g. with simulation OPC server, or should we start by simply setting up an application or multiple apps that subscribe to huge number of items and also issue some InvokeWriteValue-s?
Also, I assume you are using the out-of-process (Local Server) type of he component (running in separate process), and not in-process? - please confirm, this is quite important.

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

More
01 Feb 2011 14:40 #244 by lrs
Replied by lrs on topic QUICKOPC.COM and VB6
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

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

More
01 Feb 2011 13:56 #243 by admin
Replied by admin on topic QUICKOPC.COM and VB6
Hello, I just want to confirm that we have received this, and will be looking into it.
I have noticed in your event handler that you specifically check for "invalid" items, and unsubscribe them. This is not normally needed. I just want to be sure that you understand how the components works with these, and incidentally, I have just replied to a support request just abou that: www.opclabs.com/Support/Online ... . This probably has nothing to do with the issues you are reporting, and you may even have a legitimate reason to unsubscribe when the item is not "right", but I want to be sure that you understand what is happening "inside the component" in this situation.
I will reply to the remainder of your request separately.
Best regards,
Zbynek Zahradnik, OPC Labs

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

Moderators: support
Time to create page: 0.225 seconds

      

 Recommend this on Google