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.
QUICKOPC.COM and VB6
We are working on further analysis and a fix for this. Please wait for next post.
On your side, with this particular error, it is very important to determine which process is responsible for this. You should set up either task manager or process monitor and observe/log the number of threads consumed by each process.
Sent: Monday, September 10, 2012 11:21 AM
To: Zbynek Zahradnik
Subject: OPCLabs forum - new post, update
By the way,
Our log file has catched the error:
“No more threads can be created in the system” several times, seems like it has been logged after “InvokeWriteItemValue” to the system with no communication.
Does this error come from OPCLabs?
Can you quantify how many calls to this method, and with how many items, can accumulate over time? We can make a test with this method as well.
The queue sizes should rather be set higher, not lower. If a queue is filled to the limit at any moment, it means a serious problem because the system is not coping with the load, and notifications get lost.
I forgot the questions from May, the answer is as following:
- For writing the method InvokeWriteItemValue is used. This is called from timers (time program etc), but normally no writing is performed when no time program changes and no users logged in
- for reading, only subscription is used, no one-time reading
- abandon interval minimum had always been unchecked
Have you found out more about this recent months? The problem is still there. Today the memory consumption of OPCLabs on one of our servers reached 2GB. The reason was com failure in one of the buildings in the system (covering about 2000 out total 40000 opc items in server, this system had no com during weekend).
Have you any suggestions about other settings we can try? What about the queue sizes, should we try to reduce them ? When we started using OPCLabs the system crashed very often, then we increased the queue sizes, and there were no more crashes, but has this something to do with the memory consumption ?
Best regards, LRS
we have set up a long-running test with following parameters:
queue sizes increased according to your picture
client test application subscribing to 12,000 items
each item changing on the server once in 10 minutes (in a phased manner), giving an average rate of change of 20 changes/second
server failure (with OPC_STATUS_FAILED) simulated every 10 minutes (that's quite often...)
We ran this test for approx 2.5 days, and collected the memory consumption (Private Bytes counter) using Windows performance monitor. Unfortunately, no relevant increasing trend in memory consumption could be observed: The "baseline" stayed around 72-73 MB.
We will continue trying to reproduce the problem with different and more "harder" settings. Can you please answer the following as well:
Is your application also using "one-time" reads and writes, or is it just permanently subscribed as our test application is? Can you describe the general "usage pattern" of QuickOPC methods in your application?
I am still not sure about the setting for "Abandon interval minimum:. Are you running with it checked, or unchecked?
"Huk vekk denne" means "Uncheck this" in Norwegain (not meant for you!), as an internal message to our engineers because we have been using the same settings on all servers with OPCLabs.
Error -1073442815 occurs from time to time also on other of our SCADA servers, from different OPC server connections, where we use Matrikon Tunneller and OPCLabs. If you dont' have any better suggestion, we think it indicates that there has been a network fault so that connection between communication server and SCADA server has been lost. (Also get the same message if comm. server is being restarted)
Thanks for looking at our problem, we will inform the customer, and hopefully we will have this problem solved. Please tell if you want us to try different program settings on the server.