[FB15034] OPC-UA - Bad_ContinuationPointInvalid

Ignition Early Access
1

I’m trying to connect Ignition 8.0.4RC1 to the TANI OPC-UA server and get an exception. The server runs on the same machine as the Ignition 8 gateway.

A remote 7.9 gateway is connected to the same server and works without problems.

Any ideas what might be causing this?

UaException: status=Bad_ContinuationPointInvalid, message=The continuation point provide is longer valid.
	at com.inductiveautomation.ignition.gateway.opcua.client.connection.DataTypeTree$Companion.browse(DataTypeTree.kt:266)
	at com.inductiveautomation.ignition.gateway.opcua.client.connection.DataTypeTree$Companion$browse$1.invokeSuspend(DataTypeTree.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:740)
2

Can you get a Wireshark capture?

If I had to guess I’d say maybe they are returning an empty continuation point (rather than null) and we’re calling BrowseNext with that anyway.

3

Hello Kevin,

here is the Wireshark capture. The connection to this server worked in 7.9 and 8.0.3. The problem emerged with version 8.0.4rc, the capture is from 8.0.4.
opcua.zip (52.6 KB)

4

This looks like a bug in the server to me. It’s returning Bad_ContinuationPointInvalid in the BrowseResult of a response to a regular BrowseRequest, which doesn’t even make any sense.

I’ll have to look into what might have changed between 8.0.3 and 8.0.4-rc though.

5

Ok, thank you.
Let me try to restart the server tomorrow. Maybe there is a bug that only shows on new connections and don’t affect existing ones.

6

A restart had no effect. The problem is reproduceable on two seperate systems.

I added another capture from a working Ignition 7.9 connection. When you look a the BrowseResponse with Request Id 173, the servers answer is the same. It looks like the client ignored this exception in versions prior 8.0.3rc.
opcua_ok_7_9.zip (23.9 KB)

7

Yes, it looks like as part of a change related to browsing datatypes the StatusCode of the BrowseResult started being checked, where previously it was ignored. I can probably revert to the more lenient behavior in an upcoming 8.0.5 nightly.

Can you report this to the server vendor as well? This is definitely a bug in the server.

1 Like
8

Yes, i already sent them the capture.

9

This issue was fixed in the 8.0.5 nightly build that was uploaded today (9/24).

10

This has meanwhile been fixed by the server vendor. It looks like browsing datatypes is not a commonly used feature.

11

Ignition 7.9.12+ and 8.0.0+ will browse all the DataTypes to construct a tree, which it then uses to support aliased datatypes.

It’s become common in the servers embedded on PLCs to use alias datatypes, i.e. instead of using an OPC UA Int16 they make an alias type to INT or whatever the native equivalent is. Without building this tree it’s not possible for the Ignition client to resolve these aliases into their actual underlying type.

Older versions of Ignition could read tags with aliased datatypes but not write to them. They would also not get the correct tag type set when you dragged them into Ignition.