- Posts: 20
- Thank you received: 0
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.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Reading, Writing, Subscriptions
- Cleaning of the apartment All this is well suited to my kitchen. It will look good in my apartment.
Cleaning of the apartment All this is well suited to my kitchen. It will look good in my apartment.
support wrote: ...
Note that the issue you reported is still a valid issue - the call to SubscribeXXXX should not block in this way, and we will investigate it. ...
Dear Support,
Is there some news about the issue? It seems I'm still experiencing it when my network failing me like in this case:
"[2/10/2016 1:23:11 AM] [OpcNodesBrowser] UAException: An OPC-UA operation failure with error code -1 (0xFFFFFFFF) occurred, originating from ''. The inner exception, of type 'OpcLabs.EasyOpc.UA.Engine.UAClientEngineException', contains details about the problem.
InnerException: Timeout connecting the OPC-UA client session. The total timeout value was 60000 milliseconds, and we have waited for 59968 milliseconds. The actual waiting time is lower than the total timeout (or even zero) if the connection operation has already started earlier."
After this message my service has stalled and I had to kill it.
Serge
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Call to SubscribeXXXX indicates your permanent intent to be subscribed, which only ends if you call UnsubscribeXXXX. In between the Subscribe/Unsubscribe call pair, QuickOPC will *permanently* attempt to be and stay subscribed. The item or the server may be inaccessible at the moment of initial Subscribe, or become inaccessible at any later point - that should make no difference. QuickOPC will signal the problem to you, but after a configurable period, it will attempt to recover, and so on.
Think about it this way: Let's say you want to create a logger, or an HMI screen, with QuickOPC. You simply need to "subscribe" to the items you are interested in, and then process the event notifications. That's it. You will receive good values, or you will receive error indications, and you will log them or display them as they come. No reconnection code whatsoever is needed.
Note that the issue you reported is still a valid issue - the call to SubscribeXXXX should not block in this way, and we will investigate it. But I want, at the same time, steer you to a proper solution with regard to failure handling, which should make your code much shorter - and at the same time, the original issue is likely to go away.
Please Log in or Create an account to join the conversation.
So it is not necessary to re-subscribe when I see in "MonitoredItemChangedEvent" (e.Succeeded == false) or (e.Exception != null) ?
Please Log in or Create an account to join the conversation.
More info: E.g. the "Concepts" document, section "Best Practices", the very first chapter: "Do not write any code for OPC failure recovery", or www.opclabs.com/resources/product-information/articles/1048-best-practices-with-quickopc .
Best regards
Please Log in or Create an account to join the conversation.
Best regards
Please Log in or Create an account to join the conversation.
1. I subscribed to ~400 OPC tags, callback MonitoredItemChangedEvent(..) is working well.
2. I stop Kepserver service (on different PC in the same network).
3. In the callback I fill in List<long> failedSubscriptionHandles:
void MonitoredItemChangedEvent(object self, EasyUAMonitoredItemChangedEventArgs e) {
if ((e.Succeeded && e.Exception == null)) {
// store the VQT
} else {
long handle = (long)e.Arguments.State;
lock (this)
{
if (!failedSubscriptionHandles.Contains(handle))
{
failedSubscriptionHandles.Add(handle); // these items will be unsubscribed
}
}
}
4. In the Timer callback I unsubscribe and re-subscribe:
void RefreshFailedSubscriptionsCallback(object sender, ElapsedEventArgs eargs)
{
lock (this)
{
try
{
this.retryUnsubscribedItems.Enabled = false;
// Stop failed subscriptions
if (failedSubscriptionHandles.Count > 0)
{
StopMonitoringItems(failedSubscriptionHandles.ToList<long>());
}
// Re-subscribe items that are not subscribed yet (because of a subscription failure)
if (IsMonitoring)
{
IList<long> handlesToSubscribe = new List<long>();
foreach (KeyValuePair<long, DataItem.DataItem> dataItem in dataItems)
{
if (!dataItemHandleMappings.ContainsKey(dataItem.Key))
{
handlesToSubscribe.Add(dataItem.Key);
}
}
if (handlesToSubscribe.Count > 0)
{
StartMonitoringItems(handlesToSubscribe); // <<<<<<<<<<<<
}
}
}
catch (Exception e)
{
logger.Log("[OpcDataCollector] Exception: " + e.Message, Log.LogType.Error);
}
this.retryUnsubscribedItems.Enabled = true;
}
}
5. in StartMonitoringItems(handlesToSubscribe) I step to SubscribeMultipleMonitoredItems and it does not return:
// Select data items to start monitoring (all items must be added to the dataItems list)
private void StartMonitoringItems(IEnumerable<long> dataItemHandles)
{
IList<EasyUAMonitoredItemArguments> easyUAMonitoredItemArguments = new List<EasyUAMonitoredItemArguments>();
foreach (long dataItemHandle in dataItemHandles)
{
DataItem.DataItem dataItem = dataItems[dataItemHandle];
dataItem.SubscriptionParametersChangedEvent += DataItemSubscriptionParametersChanged;
UANodeDescriptor nodeDescriptor = new UANodeDescriptor(dataItem.ToNodeID());
easyUAMonitoredItemArguments.Add(
new EasyUAMonitoredItemArguments(MonitoredItemChangedEvent,
dataItemHandle,
endPointDescriptor,
nodeDescriptor,
new UAMonitoringParameters(dataItem.SamplingIntervalMs,
new UADataChangeFilter(dataItem.DeadBandType, dataItem.DeadBandValue, UADataChangeTrigger.StatusValue)
, 100 // queue size
)
));
}
int[] monitoredItemHandles = easyUAClient.SubscribeMultipleMonitoredItems(easyUAMonitoredItemArguments.ToArray()); // <<<<<< problem is here
// ....
}
Serge
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
I have a problem when OPC server temporarily becomes unavailable.
When OPC server becomes unavailable (due to OPC service shutdown during a test or network issue),
following call does not return back if time of disconnect is longer then some value (~1m):
int[] monitoredItemHandles = easyUAClient.SubscribeMultipleMonitoredItems(easyUAMonitoredItemArguments.ToArray());
I mean that the thread waits somewhere inside the SubscribeMultipleMonitoredItems(..) procedure, never comes back even after the OPC server comes back online.
OPC server: KepserverEX v5.15
OpcLabs: v5.34.205.1
How can I debug the issue?
Serge
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Reading, Writing, Subscriptions
- Cleaning of the apartment All this is well suited to my kitchen. It will look good in my apartment.