I can not be certain that the tracing had been stopped manually, but I used the "File -> Save Trace" operation within the application which appears to stop the trace automatically when executed (v.1.3.1014).

I have received the download link - thanks.

Thank you for checking. Is it possible to get access to a new version of OPC Analyzer for the duration of this experiment?

Good day,

Thank you for the suggestion - we are using performance counters to monitor GC.

The event in question has occurred again. I was able to log into the customers computer and save the trace, but my version of OPC Analyzer crashes when I attempt to open it. Is there anything we can do to recover the data? Given the (in)frequency of the event I would really like to get access to this data for analysis.

I have attached the trace file.

Thanks,

Shea

1. Our application is a .NET project (.NET 4.5.2 runtime, 64 bit, release configuration).

2. There are timers (one for each distinct tag poll rate, usually 500ms and 1000ms) in the application that take the most recent value and OPC timestamp for each tag and log it to disk. If the timestamp for a tag has not changed since the last timer elasped call, the value is logged to disk again with Datetime.UtcNow as the timestamp (unless an interim OnDataChange callback has been received indicating DAVtq.Quality bad). There is no data logged for any of the ~7000 tags for the 5 second period in question, implying that either the quality went bad for all of them, or our internal timers were not firing. Given that we don't see any quality bad messages in the OPC Analyzer trace, I think it's safe to assume that the internal timers were not firing for > 5s implying a process-wide issue.

If you see a fault in my reasoning please let me know. I have added logging of some performance monitors for the process and will inspect those if it happens again.

Thanks,

Shea

Good day,

I am using QuickOPC 5.31 Build 1331.1 on Windows Server 2012. We are subscribed to ~ 7000 tags with poll rates ranging from 500ms to 1000ms. The OPC Server and client application are running on the same machine.

Note that the information in this paragraph is provided as background information to explain why we were running the experiment described below. Our customer has been reporting intermittent issues whereby the historian to which we are logging all ItemChanged updates was intermittently missing updates from the PLC (e.g., they were sure the PLC was indicating value x at time t but the database did not contain the update, but would get subsequent updates).

I installed OPC Analyzer and instructed 4 of the 7000 tags to subscribe through it rather than directly to Kepware. I also logged instructed the same 4 tags to log directly from the PLC to our historian (using ControlLogix drivers from ingeardrivers.com/). To detect instances where the data received from the OPC Server differed from that which was being logged directly from the PLC, we set up email alerts (so that we could quickly log in and save the OPC Analyzer Trace).

Yesterday I received an email alert and immediately logged in to save the OPC Analyzer Trace. It turns out the alert was generated because a subscription call from the OPC Server to our application took 5437ms to be acknowledged (assuming I am interpreting the highlit line of the trace correctly - please see attached screenshot). Most CallTime's are < 200ms.

What could be responsible for the high CallTime? When QuickOPC receives a subscription update from the OPC Server, does it attempt to immediately send the acknowledgement to the OPC Server? Or does it synchronously pulse all methods subscribed to the to the ItemChanged event before sending acknowledgement to the OPC Server? Is there anything you can think of which we could try to eliminate extremely high CallTime's such as this? Note that during the event no data for any of the other 7000 tags was logged which is a concern.

The machine running the code is not under heavy load (16 cores - usually around 33% utilization, 128 GB ram, and the process calling QuickOPC is typically using 2-3% CPU).

I have attached the trace as well.

Thanks,

Shea