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.
Callback enqueuer overflow.
Longer answer: I'd rather give more elaborate info, in order to prevent any confusion:
1. If you have 9000 items that are internally related in the OPC server, such as they all reside on the same communication link between the server and the device, and the communication fails, the server will update them all with corresponding failure StatusCode, and send the updates to client - individually (well, can be physically in one message, but still there is one notification inside, for each such item).
2. If later on the above communication is restored, the server will send "good" newly collected values, and corresponding good StatusCodes to the client - again, individually, as in the case above.
3. Now to a different case: What if the communication between the OPC UA Client (your app) and the UA server breaks, or the server crashes etc.? In this case, the client has no info from the server, and the problem clearly affects everything that the OPC UA Client is susbcribed to the OPC server. So, in theory, in this situation we could give you just one notification. QuickOPC, however, transforms this situation so that it looks similar to the two above. It will send you notifications (with null AttributeData, but non-null Exception property) for *each* affected (subscribed) item. This behavior is intentional, has to do with some of the basic QuickOPC design principles, and is very unlikely to change.
In the first two cases the behavior comes from OPC UA specifications. In the third case it is our own choice.
Best regards
Please Log in or Create an account to join the conversation.
There is no way to prevent these huge amount of notifications in case the OPC server fails, correct?
Would it help if we can speed up processing of these notifications, because they are worthless for us. If it is possible to detetct the cause of these notifications (Server failed) we can just ignore them.
Kind regards
Peter
Please Log in or Create an account to join the conversation.
- Indication of the communication status between the client and the server: the Exception property.
- If the Exception is null, then the AttributeData property contain a non-null data from the server (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User's...A.UAAttributeData_members.html ). In its StatusCode property, you have the status related to the value, as provided by the server.
So, you can test these two, and you can even compare them with the previous notification. But I do not quite understand why comparing to previous status should be needed.
Regards
Please Log in or Create an account to join the conversation.
The subscription has approx 9000 items.
Can we easiyl detect that the "status" of the data has changed?
Kind regards
Peter
Please Log in or Create an account to join the conversation.
The filtering for the case when the status and value has remained the same and only the timestamps have changed is shown in the following examples.
// This example shows how to subscribe to changes of a monitored item with data change filter.
using System;
using OpcLabs.EasyOpc.UA;
using OpcLabs.EasyOpc.UA.OperationModel;
namespace UADocExamples._EasyUAClient
{
partial class SubscribeDataChange
{
public static void Filter()
{
UAEndpointDescriptor endpointDescriptor =
"opc.tcp://opcua.demo-this.com:51210/UA/SampleServer";
// or "http://opcua.demo-this.com:51211/UA/SampleServer" (not in .NET Standard)
// or "https://opcua.demo-this.com:51212/UA/SampleServer/"
// Instantiate the client object and hook events
var client = new EasyUAClient();
client.DataChangeNotification += client_DataChangeNotification_Filter;
Console.WriteLine("Subscribing...");
// Report a notification if either the StatusCode or the value change.
// The UADataChangeTrigger has an implicit conversion to UADataChangeFilter and can thus be used in its place.
client.SubscribeDataChange(endpointDescriptor, "nsu=http://test.org/UA/Data/;i=10853", 1000,
UADataChangeTrigger.StatusValue);
Console.WriteLine("Processing data change events for 20 seconds...");
System.Threading.Thread.Sleep(20 * 1000);
Console.WriteLine("Unsubscribing...");
client.UnsubscribeAllMonitoredItems();
Console.WriteLine("Waiting for 5 seconds...");
System.Threading.Thread.Sleep(5 * 1000);
}
static void client_DataChangeNotification_Filter(object sender, EasyUADataChangeNotificationEventArgs e)
{
// Display value
if (e.Succeeded)
Console.WriteLine("Value: {0}", e.AttributeData.Value);
else
Console.WriteLine("*** Failure: {0}", e.ErrorMessageBrief);
}
}
}
// This example shows how to subscribe to changes of multiple monitored items and use a data change filter.
using System;
using OpcLabs.EasyOpc.UA;
using OpcLabs.EasyOpc.UA.OperationModel;
namespace UADocExamples._EasyUAClient
{
partial class SubscribeMultipleMonitoredItems
{
public static void Filter()
{
UAEndpointDescriptor endpointDescriptor =
"opc.tcp://opcua.demo-this.com:51210/UA/SampleServer";
// or "http://opcua.demo-this.com:51211/UA/SampleServer" (not in .NET Standard)
// or "https://opcua.demo-this.com:51212/UA/SampleServer/"
// Instantiate the client object and hook events
var client = new EasyUAClient();
client.DataChangeNotification += client_DataChangeNotification_Filter;
Console.WriteLine("Subscribing...");
// Report a notification if either the StatusCode or the value change.
// The UADataChangeTrigger has an implicit conversion to UADataChangeFilter and can thus be used in its place.
client.SubscribeMultipleMonitoredItems(new[]
{
new EasyUAMonitoredItemArguments(null, endpointDescriptor,
"nsu=http://test.org/UA/Data/;i=10845",
new UAMonitoringParameters(1000, UADataChangeTrigger.StatusValue)),
new EasyUAMonitoredItemArguments(null, endpointDescriptor,
"nsu=http://test.org/UA/Data/;i=10853",
new UAMonitoringParameters(1000, UADataChangeTrigger.StatusValue)),
new EasyUAMonitoredItemArguments(null, endpointDescriptor,
"nsu=http://test.org/UA/Data/;i=10855",
new UAMonitoringParameters(1000, UADataChangeTrigger.StatusValue))
});
Console.WriteLine("Processing monitored item changed events for 10 seconds...");
System.Threading.Thread.Sleep(10 * 1000);
Console.WriteLine("Unsubscribing...");
client.UnsubscribeAllMonitoredItems();
Console.WriteLine("Waiting for 5 seconds...");
System.Threading.Thread.Sleep(5 * 1000);
}
static void client_DataChangeNotification_Filter(object sender, EasyUADataChangeNotificationEventArgs e)
{
// Display value
if (e.Succeeded)
Console.WriteLine("{0}: {1}", e.Arguments.NodeDescriptor, e.AttributeData.Value);
else
Console.WriteLine("{0} *** Failure: {1}", e.Arguments.NodeDescriptor, e.ErrorMessageBrief);
}
}
}
Regards
Please Log in or Create an account to join the conversation.
I assume that the timestamps have changed. As far as I know there was a OPC-server failure in this situation, which has caused the "flooding".
Regrads
Peter
Please Log in or Create an account to join the conversation.
Regards
Please Log in or Create an account to join the conversation.
Thank you!
We are connected to a Siemens OPC-Server.
We do not have any DataChangeFilter yet. We are interested in changes for value and server quality only. Changing timestamps can be ignored.
Can you please explain how to filter on these changes only?
Kind regards
Peter
Please Log in or Create an account to join the conversation.
There seems to be two related issues here.
First, you say "We are also getting many calls from item subscriptions, although there were no value changes on the items.". This is, of course, weird. Please provide more details:
1. Which OPC server are you connecting to?
2. The method call and parameters used for subscription. Specifically, are you giving it any explicit DataChangeFilter, etc.?
3. When you receive a notification with "no value change", what are the SourceTimestamp and ServerTimestamp values? Are they also identical as in the previous notification, or is any of the timestamps different? Note: If you are not interested in the same values with newer timestamps, there are ways to do that - I will follow up on that after I receive the answers.
Second, the callback enqueuer overflow. It may be a consequence of the above. If there are huge numbers of events/callback produced, and your code does not cope with consuming them at the rate they are produced, QuickOPC builds a queue, so that no notifications are lost in case this was just a transient issue. But, if the rate of production is higher that the achievable consumption rate for extended periods of time the queue will grow longer and longer, and eventually it hits a limit - and you will get this error.
I suggest we focus on eliminating the notifications you are not interested in. The second problem is then likely to go away as well.
Best regards
Please Log in or Create an account to join the conversation.
During a OPC server failure, we were experiencing lots of LogEntry calls in out client:
Information(1102): The overflow condition of the callback enqueuer is clearing. The overflow count was 2.
Error(1101): Callback enqueuer overflow. The bounded queue capacity is 100000.
What is the reason for this logging?
We are also getting many calls from item subscriptions, although there were no value changes on the items.
Has anyone seen this before? Is it safe to ignore?
Kind regards
Peter
Please Log in or Create an account to join the conversation.