Why Does QuickOPC Miss RSLinx OPC Subscription Updates?

The panel shows a Boolean tag frozen at True while the PLC is False, or frozen at False after the PLC changes to True. A manual read returns the current value, and unsubscribing then resubscribing makes the display correct again. Start here: that pattern points to a stale subscription path, not automatically to stale PLC data.

Stop using the fixes that hide the fault

Several actions clear the symptom without locating the failed boundary:

• Restarting the application: rebuilding the client and its subscriptions discards the stale state. It also destroys the condition you need to capture.
• Unsubscribing and resubscribing: this forces a new initial value, so the tag becomes correct. It does not explain why the earlier notification stopped.
• Reading the item once: a correct read proves that the read path can retrieve a newer value. It does not prove that the server issued the subscription callback or that the client delivered it.
• Changing callback types: listening to ItemChanged instead of MultipleItemsChanged did not remove the missed-update condition in the captured installation.
• Tracing only a few convenient tags: monitoring 10 tags out of approximately 5000 produced no captured failure. Unless a monitored tag is the one that freezes, the trace cannot settle the question.
• Blaming the client because another client works: two valid OPC clients can exercise different communication paths against the same server. A server defect can therefore appear with one client and not another.

Do not restart or resubscribe after the next confirmed mismatch until you have saved the application state, direct-read results, timestamps, quality, exceptions, and communication trace.

Identify the actual failure mode

The decisive symptom is a subscription value and source timestamp that stop advancing while repeated OPC reads return a different value with newer timestamps. One captured sequence held the subscribed value at False with timestamp 2016-02-19T06:52:42.2993453Z. Five direct reads returned True between 2016-02-19T07:57:42.9820322Z and 2016-02-19T07:58:22.9823650Z.

That is more than a display refresh problem. The application did not receive or process a value-change event for over an hour, while the OPC server's read interface exposed the newer value.

Observed symptom	Most useful interpretation	Next check
PLC and subscription disagree, but a read agrees with the PLC	The subscription delivery path is stale somewhere between server notification and application state	Compare callback ingress, queue processing, VTQ, exceptions, and analyzer traffic
Read and subscription both show the same stale value	The problem may be upstream of the client, including server cache or controller communications	Compare the PLC value with server diagnostics and the read's source timestamp
Callback arrives, but the dictionary stays unchanged	The application discarded, reordered, or failed to process the update	Trace callback entry, queue insertion, queue removal, and dictionary assignment
No callback reaches the application, but analyzer traffic contains the change	The client library or its event-dispatch path becomes the primary boundary to investigate	Package the trace, client log, and minimal handler for support
No callback reaches the application or analyzer	The server may not have emitted the notification on that client connection	Correlate the same time window with server and controller diagnostics
Resubscription immediately restores the value	Subscription reconstruction recovers state but hides the origin	Capture before rebuilding the subscription

Inspect value, timestamp, quality, and exception together

A Boolean alone is insufficient. Process the complete VTQ record and the error information supplied with the event. In the QuickOPC handler, check the event argument's .Exception property and inspect the returned VTQ quality before accepting the value.

• Log the item identity, value, source timestamp, quality, callback arrival time, and exception.
• Record whether the event entered the handler, entered the queue, left the queue, and updated the dictionary.
• Keep the last accepted subscription timestamp beside the displayed value.
• Reject or alarm on bad quality and reported exceptions rather than silently treating the value as valid process data.
• Track subscription lifecycle operations so a reconnect or implicit recreation cannot be mistaken for normal callback delivery.

A short callback that only adds an update to a locked queue is a sound design, but it still needs boundary logging. Correct locking does not reveal a rejected event, an event carrying an exception, an overwritten queue entry, or a worker that stopped consuming.

Add an independent stale-value detector

Use periodic reads as a watchdog, not as a replacement for subscriptions. The implemented detector read all tags every 10 seconds through ReadMultipleItems in EasyDAClient or Read in DaServerMgt. It compared each read with the last subscription value and alarmed after five consecutive mismatches while the subscribed value remained unchanged.

1. Store the latest subscription value and timestamp for every monitored tag.
2. Every 10 seconds, read the same tags through the OPC server.
3. Request a maximum age of 5000 ms. With subscriptions configured at 1000 ms or faster in this installation, the server cache was expected to contain a sufficiently recent value.
4. Compare value, timestamp, and quality. Treat a single disagreement as a possible race between asynchronous read and callback paths.
5. Increment the mismatch count only when consecutive reads disagree and the subscription value has not changed.
6. Raise an alarm on the fifth consecutive mismatch. Save the five records plus the unchanged subscription timestamp.
7. Reset the counter when the paths agree or when a valid subscription update arrives.

This rejects most momentary ordering races while detecting a persistent frozen callback path.

A read with MaxAge set to 5000 ms distinguishes the callback path from the server's readable cache; it is not necessarily a new physical read from the PLC. If device-level confirmation matters, use a server-supported device read and identify it separately in the log.

Capture OPC traffic without masking the problem

OPC Analyzer can show whether notification traffic crossed the client/server boundary, but the capture changes timing and load. That observer effect matters when the failure is intermittent. A clean run through the analyzer does not clear either component.

1. Use the analyzer version recommended through the product's official support channel. OPC Analyzer 1.03.1014 was examined during this incident, but treat that number as historical rather than current.
2. Trace tags that the watchdog also checks. A trace of unrelated tags has little diagnostic value.
3. Start with a manageable subset when tracing all approximately 5000 tags would impose too much load. A subset of roughly 500 was considered after a 10-tag capture failed to catch the event.
4. Measure the incoming change rate before committing to a long capture. High update volume makes both trace size and manual analysis difficult.
5. Create an external time marker when the watchdog declares a mismatch. Record the tag and the precise first and fifth mismatch times.
6. Export the relevant window to text when the trace is too large for manual inspection, then filter it by item and time.

The analyzer used in this investigation could not automatically save or split traces. Disk capacity alone does not solve that limitation; you still need controlled rotation and an exact incident time. Any external automation used to save traces must be tested before the production capture so it does not interrupt the analyzer.

Isolate the server, client library, and application

Run the isolation test as a matrix. Keep the tag set, subscription rates, server, and observation interval aligned wherever practical.

1. Prove the PLC state. Record the controller value independently when the panel becomes stale.
2. Prove the OPC read state. Capture the read value, timestamp, quality, and exception.
3. Prove callback entry. Log before queue insertion. If nothing appears there, the dictionary and worker thread are not the first failure boundary.
4. Prove application processing. Correlate callback entry with queue insertion, queue removal, and dictionary update.
5. Prove wire-level delivery. Find the same item and time window in the analyzer trace.
6. Repeat with a second client stack. The installation replaced QuickOPC with Kepware ClientAce on two systems and reported no missed updates during the following week, while another system using the original stack captured a stale subscription.

The client comparison is a valuable workaround test, not final fault attribution. ClientAce may communicate differently with RSLinx, so the result narrows the interaction but does not by itself distinguish a QuickOPC defect from an RSLinx defect triggered by that interaction.

The affected QuickOPC installation used 5.31 Build 1331.1. An upgrade to 5.35, described at that time as the latest release, was recommended even though no specific fix for this symptom was identified. Validate against the currently supported release through official product support rather than treating 5.35 as current. When reads run in parallel with subscriptions, also review the official read/subscription interaction settings; obtain the actual property names and values from the documentation for the installed release.

Verify the repair under real load

Do not declare success because a resubscription corrected one tag. Verify the operating condition that originally exposed the failure:

• Subscribe to the production-scale tag population, approximately 5000 tags in the affected application.
• Retain the configured subscription rates of 1000 ms or faster where they are part of the test baseline.
• Run the independent read detector continuously and keep mismatch alarms visible.
• Confirm every accepted callback has usable quality, no reported exception, and a timestamp that progresses when the process value changes.
• Confirm callback records reach the queue and dictionary exactly once in the intended order.
• Test recovery after server or client reconnection without using routine restarts to conceal the condition.
• Compare analyzer traffic only within a precisely marked mismatch window.

Two ClientAce systems ran for one week without a reported incorrect value, which was operationally encouraging but not proof of the defective component. Set the validation duration from the installation's observed failure frequency; when operators were finding at least one stale value per day, a meaningful test had to cover multiple normal operating days and representative tag-change load.

FAQ