# OPC-UA Server Connections and Tag Issues

**URL:** <https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206>\
**Category:** Ignition\
**Tags:** ignition79\
**Created:** [January 29, 2019, 11:10pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206 "2019-01-29T23:10:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 29, 2019, 11:10pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/1 "2019-01-29T23:10:39Z")

</div>

I have a client attempting to use Ignition in a lab environment for R&D purposes.  
They have multiple test control system racks, each having upwards of 20 standalone distributed devices.

They’ve been experiencing a severe issue where OPC-UA tags stop updating completely in both Ignition designers and clients.

In some cases, the quality will go bad and read “config error” under diagnostics. Other times the quality stays good but the tags simply don’t update. The scan class claims to have executed but the values are not updated.

If I use the OPC quick client or another OPC client to check the values, they do report correctly, so I know it’s not a connection issue.

Additional Details:

- No OPC-UA tags are updating, all values are held at ‘null’
- This is true even for new tags whose OPC-UA connection in the Gateway is reading ‘good’
- The scanclasses are executing, as expression tags update fine
- The Gateway is not under heavy load. Peaks at about 20% CPU and 25% memory usage before GC (21 GB total)
- They have configured 262 OPC-UA connections, of which only 16 are active, the rest are faulted (test devices currently disconnected)
- They default realtime tag provider has 4913 Tags registered

The obvious solution would be to manage these connections in a third party OPC-UA server, and have Ignition only connect to that one server. Any advice?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2019, 11:16pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/2 "2019-01-29T23:16:38Z")

</div>

What version of Ignition is this?

Am I right in understanding that these are all OPC UA connections directly to the devices and that Ignition’s built-in OPC UA server is not really involved here?

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 29, 2019, 11:20pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/3 "2019-01-29T23:20:57Z")

</div>

7.9.7. Will be pushing them to update soon.

That’s correct, they’re all configured as their own OPC UA servers, no usage of the Ignition server.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2019, 11:22pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/4 "2019-01-29T23:22:39Z")

</div>

Ok, well definitely start with upgrading to 7.9.10.

From there, you can go to the logging area in the gateway and configure the logging level for the logger you find searching “UaSubscriptionChangeListener” to TRACE. And “OpcUaConnection” to DEBUG. Leave these on and get a log export next time there’s an issue.

You might also get Wireshark installed in case we need to use that for troubleshooting as well.

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 29, 2019, 11:28pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/5 "2019-01-29T23:28:15Z")

</div>

Changing UaSubscriptionChangeListener to TRACE released a deluge of “Unable to get client to synchronize, rescheduling…” messages.

Also interesting sequences of:

- synchronizing subscriptions
- creating/deleting items on subscription …
- nodesToAdd.size() = N
- nodesToRemove.size() = 0
- Creating N items on scanclass
- Failed to create item '… details … ’ x N

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2019, 11:29pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/6 "2019-01-29T23:29:23Z")

</div>

Yeah, those are important. The “Failed to create item” messages are likely why you’re seeing Bad\_ConfigError quality on your tags. What’s the StatusCode returned by the server?

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 29, 2019, 11:41pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/7 "2019-01-29T23:41:55Z")

</div>

The tag quality is no longer bad since I’ve deleted over 60 faulted (unused) UA servers and increased the scanclass rate from 1 to 5 seconds.

Seems like the scanclasses just get overloaded with too many inactive UA connections?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2019, 11:44pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/8 "2019-01-29T23:44:09Z")

</div>

No, unless a scan class is in Read Mode it’s almost entirely irrelevant when dealing with OPC tags. Only the scan class rate is used to determine the sampling interval of monitored items belonging to the corresponding subscription.

Whatever the StatusCode is for those items items that were failing to be created is probably important and your issue will probably come back again…

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 29, 2019, 11:50pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/9 "2019-01-29T23:50:54Z")

</div>

Ah I see…

StatusCode for the ‘failToCreate’ messages is:  
{name=Bad\_NodeIdUnknown, value=0x80340000, quality=bad}

Sidenote: altering the scanclass triggers the tag issue again, causing all qualities to go bad indefinitely.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2019, 11:51pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/10 "2019-01-29T23:51:36Z")

</div>

Assuming those NodeIds are/were valid, this looks more like an issue with the Servers rather than the Client.

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 30, 2019, 12:00am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/11 "2019-01-30T00:00:05Z")

</div>

The servers connections that I removed were physically connected in the past.

Though I think [you're right](https://i.kym-cdn.com/entries/icons/original/000/027/475/Screen_Shot_2018-10-25_at_11.02.15_AM.png), the issue could be caused by some of the still-connected devices.

There are additional warnings of the form:

> "Failed to set publishingInterval=5000 on subscription ... scanclass details ...  
> UaServiceFaultException: status=BAD\_ServiceUnsupported, message=The server does not support the requested service."

That only happened after attempting to change the scanclass again.

Though it doesn't report which UA servers are causing the issue.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 30, 2019, 12:10am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/12 "2019-01-30T00:10:55Z")

</div>

Oh boy. Bad\_ServiceUnsupported in response to setting the publishing interval means the server isn’t implementing the Modify Subscription service, which is _not_ optional if you support subscriptions.

What are these and who makes them?

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 30, 2019, 12:16am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/13 "2019-01-30T00:16:59Z")

</div>

There is a variety, so it’s hard to nail down.

DYNSIM 3 jumps out in the list as the server type is legacy: OPC\_COM\_ServerType

Some devices are also running [open62541](https://open62541.org/), though I wouldn’t suspect that.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 30, 2019, 12:20am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/14 "2019-01-30T00:20:04Z")

</div>

None of this logging or troubleshooting applies to COM connections.

open62541 is generally solid but it’s just an SDK so you can still screw things up with it.

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [January 30, 2019, 12:24am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/15 "2019-01-30T00:24:47Z")

</div>

Great points.

Thanks for your help @Kevin.Herron, I’ll relay your wisdom to their development team and update this post with what we find. Cheers!

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 30, 2019, 12:26am UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/16 "2019-01-30T00:26:12Z")

</div>

Good luck! Let me know what you find.

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [February 25, 2019, 3:29pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/17 "2019-02-25T15:29:31Z")

</div>

Unfortunately I was never able to pinpoint the specific fault in the custom server software. The team responsible for the the server implementations were already in the process of switching from open62541 to a commercial MatrikonOPC stack when I inquired about implemented services. With the new server software in place, we haven’t experienced any further connectivity issues with those devices. Safe to say your evaluation was correct.

However, I’ve now identified a separate OPC issue with tags exposed in NXT Control (now Schneider Electric) soft controllers via their proprietary OPC UA server… The logs are relaying similar errors as before, with UaSubscriptionChangeListener reporting “The server does not support the requested service” I’m not seeing an error code this time, so unsure what that unsupported service is. In this instance the scanclass is still functioning as expected. Only tags from the offending server are faulting out. Tag Diagnostics reports quality “Unknown”. Using a third party OPC-UA client (Unified Automation’s UaExpert) the tags are still reading correcting. Any advice?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 25, 2019, 3:40pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/18 "2019-02-25T15:40:00Z")

</div>

On the log level config page in the gateway find the logger for “UaSubscriptionChangeListener” and turn it to TRACE, then edit/save the OPC UA connection to the NXT server and collect the logs.

---

<div class="post-metadata">

**Author:** ![bfuson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bfuson/32/4597_2.png) [@bfuson](https://forum.inductiveautomation.com/u/bfuson)\
**Post date:** [February 25, 2019, 4:08pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/19 "2019-02-25T16:08:26Z")

</div>

Disabling the OPC UA server connection does stop the warnings  
Strangely when re-enabling the connection all the tag values report correctly, but the Bad\_ServiceUnsupported messages resume and the values/timestamps no longer update after the initial read.

The sequence of UaSubscriptionChangeListener logs:

- [D] Synchronizing subscriptions…
- [D] Creating/deleting items on subscription ‘Scanclass ‘Default[default]’’
- [D] nodesToAdd.size()=0
- [D] nodesToRemove.size()=0
- [D] Setting MonitoringMode to Reporting for 16 of 16 items on subscription ‘Scanclass ‘Default[default]’’
- [W] Failed to set MonitoringMode.Reporting on 16 items on subscription ‘Scanclass ‘Default[default]’’: UaServiceFaultException: status=Bad\_ServiceUnsupported, message=The server does not support the requested service.

No code reported in the warning stack trace.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 25, 2019, 4:09pm UTC](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206/20 "2019-02-25T16:09:47Z")

</div>

That’s everything I needed.

Again, the server you’re connected to is not implementing a mandatory service (SetMonitoringMode this time).

[Next page](https://forum.inductiveautomation.com/t/opc-ua-server-connections-and-tag-issues/22206.md?page=2)
