Ignition Tag Browser Timeout/Issues

Ignition
1

Hello,

I am using the Ignition maker edition to connect to an OPC DA server tunnelled through Matrikon OPC Tunneller. The connection is established just fine, and things generally work aside from two small issues:

If I add tags through the tag browser, by expanding the tree until I get to to where I want and then dragging it to the right side, the tag is added fine and will read with no issues.
If I then duplicate it, and change a single character in the OPC path (EG, CT001 to CT002) every single tag value I have will go to bad. I know the paths are correct, it's literally the same as I would get when I add it manually through the browser (as opposed to just duplicating and changing the OPC item path property). The only way to get the system to normalize after this is to delete all added tags through the tag browser, then restart both the tunneller service and Ignition service.

If I import tags via json or xml, the same thing happens. Seems like the only way to add tags into the project is to browse through them one by one. I have about 140 to configure, and possibly more in the future - this will take forever.

Another issue is that when browsing certain folders, I get the following error: "com.inductiveautomation.ignition.client.gateway_interface.GatewayException: Read timed out"

So there are tags that I cannot browse to because of a timeout, or add manually through their path because that destroys all the tags in the project.

I'm really hoping someone has faced this before and has some sort of insight, as I am lost in what else to try. I've played with the timeouts, the Matrikon tunneller logs reveal nothing. Here is an example of what I would see in the Ignition Gateway logs for the failed browse and when the tags all go bust:

Datatypetree error:

Browsing failed: BrowseDescription(nodeId=NodeId{ns=0, id=24}, browseDirection=Forward, referenceTypeId=NodeId{ns=0, id=45}, includeSubtypes=false, nodeClassMask=64, resultMask=63)

org.eclipse.milo.opcua.stack.core.UaException: requestId=256 timed out after 60000ms
at org.eclipse.milo.opcua.stack.client.transport.AbstractTransport.lambda$scheduleRequestTimeout$7(AbstractTransport.java:137)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.run(HashedWheelTimer.java:713)
at io.netty.util.concurrent.ImmediateExecutor.execute(ImmediateExecutor.java:34)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:701)
at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:788)
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:501)
at java.base/java.lang.Thread.run(Unknown Source)

For when the OPC totally breaks:

java.lang.Exception: session inactive: id=NodeId{ns=4, id=481771174} name=ignition[Ignition-CUBILLOS-HIS]_Experion PKS SA RDM_1731323338680

	at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaConnection$MiloSessionActivityListener.onSessionInactive(OpcUaConnection.kt:499)

	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$null$39(SessionFsmFactory.java:611)

	at java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(Unknown Source)

	at org.eclipse.milo.opcua.sdk.client.session.SessionFsmFactory.lambda$configureActiveState$40(SessionFsmFactory.java:611)

	at com.digitalpetri.strictmachine.dsl.ActionBuilder$PredicatedTransitionAction.execute(ActionBuilder.java:119)

	at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.lambda$run$0(StrictMachine.java:242)

	at java.base/java.util.ArrayList.forEach(Unknown Source)

	at com.digitalpetri.strictmachine.StrictMachine$PollAndEvaluate.run(StrictMachine.java:227)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

	at java.base/java.lang.Thread.run(Unknown Source)
2

Sounds like a broken OPC DA server. Not that unusual, which is why modern systems don't use them. Consider placing an instance of Ignition directly on that target system so you don't need the tunneler. (Edge, perhaps.)

3

The OPC DA server is fine throughout the whole ordeal if accessed in parallel by something like OPC explorer. This is either a problem in the tunneller or Ignition, I'd say.

What I'm wondering is why does adding tags manually by browsing them work, but copy pasting and changing the item path property to something I know is 100% correct cause all the tags to break?

4

Broken tunneler software doesn’t think something exists until it has been browsed.

Friends don’t let friends use Matrikon.

5

The target machine only has OPC DA servers available, which the Maker edition cannot support without the paid module so I suppose the solution would be to use different tunneller software or the OPCcom Tunneller installed on both the ignite server and the target machine, right?

What would you recommend as far as free/open source solutions go? This is for an educational project.

6

:rofl:

(I know I shouldn't laugh when other are suffering, but that's just perfect.)

7

Hmm, the tunneler I always recommend is UaGateway: UaGateway - Unified Automation

Not sure about free or open source options though.

8

I did it with RapidScada in 15 minutes - I can't believe Matrikon charges money for that shit tunneller software. Thanks for opening my eyes.