Professional OPC
Development Tools

logos

Online Forums

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.

Error after 100,001 tags are added to Data Client

More
07 Feb 2015 15:35 #2734 by admin
Great.

TopicLruSize should be greater than or equal to maximum number of OPC items needed by the application at any single time.

RequestQueueSize is the number of pending requests (to add/remove/modify the item, or to read/write/other operations) at any single time. Given that this application appears to be subscribing to all items with a single call, RequestQueueSize should be at least as big as TopicLruSize, but (because other operations may be requested after the SubscribeXXXX method returns but request are still pending) it would be safer to have it even higher.

I have doubts that whether the counting is still done right on the customer's side. For 100,100 items, it should be enough to have TopicLruSize simply 100,100. I have tested analogical scenarios and they succeeded.

It should be said, however, that both these numbers are just limits that are there to prevent unlimited growth in case of application error or other problems. The settings do *not* cause pre-allocation of memory or other resources for the given size upfront. Therefore, if they like, they can set the limits to very large values (1 million), and no harm will be done.

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

More
06 Feb 2015 14:50 #2733 by Ahock
I believe we have success!!!

He was able to subscribe to all items by changing the two parameters to 300,000.

EasyDAClient.SharedParameters.Client.RequestQueueSize = 300000;
EasyDAClient.SharedParameters.Engine.TopicLruSize = 300000;

He did have a question if there is an optimal number for these two parameters. There are 100,100 items in his subscription. 200,000 did not work for him.

He sends a big thank you for all of your hard work and assistance as do I!!

~A.

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

More
06 Feb 2015 06:26 #2727 by support
This is precisely the error that should (now) appear when the number of requested items is over the limit. Wit the testing I have done, I am fairly confident that the problem is now within the customer's code. Either he is not setting the limits properly, or he is setting it too late, when some operations have already been made.

Yes, please, get the code...

Best regards

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

More
05 Feb 2015 22:12 #2725 by Ahock
Hi!

My customer installed the newest version that you sent me this morning. He tested his application and received a different error:

[System.InvalidOperationException] = {"Failure on API for OPC-DA. Refer to inner exception for details."}

Inner exception:
[System.Runtime.InteropServices.COMException] = {"Cannot add topic object. "}
Source = "OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient"

Stack trace:
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.CheckApiResult(CHResult* hResult, IErrorInfo* pErrorInfo)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.CheckApiResult(CHResult* hResult)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.SubscribeItem(EasyDAItemSubscriptionArguments arguments)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.InternalSubscribeMultipleItems(EasyDAItemSubscriptionArguments[] argumentsArray)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] argumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.CompositeEasyDAClient.<SubscribeMultipleItems>b__1d(IEasyDAClient client, IEnumerable`1 enumerable)
at OpcLabs.BaseLib.FullyParallel.<>c__DisplayClass10`3.<>c__DisplayClass12.<GroupSelect>b__e()
at OpcLabs.BaseLib.FullyParallel.Perform(IEnumerable`1 actions)
at OpcLabs.BaseLib.FullyParallel.GroupSelect[TSource,TKey,TResult](IEnumerable`1 source, Func`2 keySelector, Func`3 groupResultSelector, IEqualityComparer`1 comparer)
at OpcLabs.BaseLib.FullyParallel.GroupSelect[TSource,TKey,TResult](IEnumerable`1 source, Func`2 keySelector, Func`3 groupResultSelector)
at OpcLabs.EasyOpc.DataAccess.CompositeEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.SubscribeMultipleItems(IEasyDAClient easyDAClient, DAItemGroupArguments[] itemGroupArgumentsArray, EventHandler`1 callback)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.SubscribeMultipleItems(IEasyDAClient easyDAClient, DAItemGroupArguments[] itemGroupArgumentsArray)
at eLynxServer.OPCSnapshot.OPCSnapshot.OPCSnapshotThread._SubscribeMultipleItems(IList`1 pSubscriptions, Int32 updateRate) in c:\eLynx\Services\eLynxServer\Plug-Ins\OPCSnapshot\OPCSnapshot.cs:line 836

I have requested an updated (complete) code and will email this as soon as I receive it.

If there is anything else you need please let me know.

Thank you!

A.

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

More
04 Feb 2015 08:46 #2691 by support
Thank you for the additional info.

1. Originally, you mentioned that the .OPF file will be attached. It is not - instead, what appears as an XML config to the app itself. I hoped to try to reproduce the issue with the same server config. But not a big issue currently, I have created my own test using our simulation server instead.

2. The code piece sent does not contain the lines (configuration parameters) I have suggested to add - which is what I wanted to check - to verify whether they are present and that they are at the right place.

3. I have, however, found a mistake in the lines I have originally sent. I apologize - please correct it on your/customer side as well. Both numbers should be higher than the numbers of items needed - i.e. they should 200000 (two hundred thousands)- but I made the first number just 20000. Here is how it should be correctly:
    EasyDAClient.SharedParameters.Client.RequestQueueSize = 200000;
    EasyDAClient.SharedParameters.Engine.TopicLruSize = 200000;

If they have just copied in my (incorrect) lines, this could explain why the issue persisted.

4. This is just a comment not related to the issue at hand, but it is not clear to me from the code how (in the notification handler - which has not been posted) the incoming notifications are correlated with the items that were subscribed. The 'State' argument, which is usually the best to be used, is passed in as 'null', i.e. not really used. I just hope that they do not use the handles (they are just for unsubscribing/making subscription changes - I can explain more if needed). They can use the Item IDs etc., but that can be slow given the high number of items. But I do not know enough about the app, it may be all well (e.g. if they are just logging what comes in).

5. I have now made more tests, and discovered and fixed some issues that appeared with subscribing to such high number of items, or when going over the limits. The fixes will be in QuickOPC 5.32 build 1063.1 (and higher); if things go well, this build should be available later today. Please have the customer use the new build, plus correct the configuration lines (#3) below.

Thank you, and best regards

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

More
03 Feb 2015 15:35 #2679 by support
Files attached for record.
Attachments:

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

More
02 Feb 2015 21:56 #2672 by Ahock
I have sent an email to you with his .opf file as well as a text file of his code. The latest stack trace is below.

Here is the stack trace

at AfxThrowInvalidArgException()
at CEDAAbstractItem.InternalConnect(CEDAAbstractItem* )
at CEDAAbstractItem.InternalAttachAndConnect(CEDAAbstractItem* )
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.SubscribeItem(EasyDAItemSubscriptionArguments arguments)
at OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] argumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.CompositeEasyDAClient.<SubscribeMultipleItems>b__1d(IEasyDAClient client, IEnumerable`1 enumerable)
at OpcLabs.BaseLib.FullyParallel.<>c__DisplayClass10`3.<>c__DisplayClass12.<GroupSelect>b__e()
at OpcLabs.BaseLib.FullyParallel.Perform(IEnumerable`1 actions)
at OpcLabs.BaseLib.FullyParallel.GroupSelect[TSource,TKey,TResult](IEnumerable`1 source, Func`2 keySelector, Func`3 groupResultSelector, IEqualityComparer`1 comparer)
at OpcLabs.BaseLib.FullyParallel.GroupSelect[TSource,TKey,TResult](IEnumerable`1 source, Func`2 keySelector, Func`3 groupResultSelector)
at OpcLabs.EasyOpc.DataAccess.CompositeEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.DelegatingEasyDAClient.SubscribeMultipleItems(EasyDAItemSubscriptionArguments[] itemSubscriptionArgumentsArray)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.SubscribeMultipleItems(IEasyDAClient easyDAClient, DAItemGroupArguments[] itemGroupArgumentsArray, EventHandler`1 callback)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.SubscribeMultipleItems(IEasyDAClient easyDAClient, DAItemGroupArguments[] itemGroupArgumentsArray)
at eLynxServer.OPCSnapshot.OPCSnapshot.OPCSnapshotThread._SubscribeMultipleItems(IList`1 pSubscriptions, Int32 updateRate) in c:\eLynx\Services

Thank you!

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

More
02 Feb 2015 20:14 #2670 by admin
- Can you please post here or send me the code.

- Can you please verify that the error is truly the same, *including the same call stack* ? (can the customer grab the call stack again, now?)

- I will also test it here.

Best regards

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

More
02 Feb 2015 19:17 #2669 by Ahock
I had my customer add the two lines of code you suggested along with placing the subscribeMultiple calls outside of his loop. He informed me that he's still seeing the same error when that 100,001 tag is present.

Are there any other suggestions or changes we can try?

Thank you!

~A

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

More
02 Feb 2015 08:06 - 02 Feb 2015 08:16 #2668 by support
These are very high item counts, and certainly a feasibility of the project should be verified before committing to implementing it either way.

Yes, there are some limits, and the likely reason for this problem is bumping to this limits. Please try to add the following lines, somewhere the beginning of the program, before instantiating the first EasyDAClient object:
    EasyDAClient.SharedParameters.Client.RequestQueueSize = 20000;
    EasyDAClient.SharedParameters.Engine.TopicLruSize = 200000;

This said, the actual behavior in case of going over these limits should be different, and not the exception reported. I will have a look at it and let you know.

One more thing: The app code apparently uses a call to EasyDAClient.SubscribeItem in a loop. For efficiency, that should not be done, and especially not with such high item counts. The code should instead prepare the arguments upfront in an array, and then use one of the EasyDAClient.SubscribeMultipleArguments overloads.

Best regards
Last edit: 02 Feb 2015 08:16 by support.

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

Moderators: support
Time to create page: 0.071 seconds