Hi guys I am using Ignition V 7.9.13 and I am able to connect to Beckhofff OPC UA V1.5.3, but the problem is that I cannot see the PLC1 Tags.
I have other PLCs with Bechhoff OPC UA V1.4.6 and it works fine.
In Ignition I am connecting to opc.tcp://ST-MTHPN2001:48050
Beckhoff settings:
Any idea why I do not see the PLC1 tags? I am able to see them on the TwinCAT OPC UA Sample Client but only using por 4840 (discovery port) not 48050.
Is the OPC UA connection in Ignition actually connected?
Are you sure you’re connecting to a Beckhoff server and not some intermediate UA gateway that needs to be configured with the tags first or something?
The folder TcOpcUAServer is visible but the PLC1 is not visible.
In the TwinCAT OPC UA Sample client is visible: but only using port 4840.
It may help to connect with a generic 3rd party client like UaExpert and see if you have the same issue.
Kevin
Yes it is connected.
The tags are ready, You can see that If I use the sample client it is visible:
If I use the same port 4840 in Ignition it does not work, it discovers it, but then it says Faulted. In Ignition only works with endpoint 48050 but does not show the PLC1 tags.
What’s the error when you use 4840?
Again, try connecting UaExpert as well, on both ports. We should be able to get some additional information from UaExpert if it works, like what kind of reference it is to the PLC1 object and what type of object it is.
Kevin:
Using UaExpert to connect to tcp.opc://10.83.108.40:48050 it connects but does not show the PLC1.
Then, using tcp.opc://10.83.108.40:4840 I had to use security Basic256Sha256 / Sign.
I got these errors, I trusted the cert and then it connected once I selected Ignore on last pop-up message.
Connected, it shows the PLC1.
Seems you need to get Ignition connected on port 4840 then.
What was the error in the logs or status section? A faulted connection should have an exception or stack trace associated with it.
The hostname or IP address in the server cert does not match the hostname or IP address the client connected to.
I am thinking maybe, I have an error on the hostnames on the cert.
I am pretty sure Ignition only logs a warning when there is a mismatch, it’s not the underlying reason for the connection being faulted.
this is the error on Ignition when using port 4840.
UaException: status=Bad_InvalidArgument, message=One or more arguments are invalid.
at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientAcknowledgeHandler.onError(UascClientAcknowledgeHandler.java:258)
at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientAcknowledgeHandler.decode(UascClientAcknowledgeHandler.java:167)
at io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
at io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:345)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:337)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:345)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:677)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:612)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:529)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:491)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at java.lang.Thread.run(Unknown Source)
7.9.13 (b2019120915)
Oracle Corporation 1.8.0_241
Okay, so this Bad_InvalidArgument is a channel-level error coming from the Beckhoff server.
You may need to go make sure Ignition’s client certificate is trusted in the Beckhoff server somewhere. Or it could be some other issue, maybe something it doesn’t like about the certificate. Unfortunately there’s no more information you can get from the Ignition side of this.
Ok I will create a new certificate with the correct hostname and trust the ignition client cert.
Just a SnootBoop for anyone doing TwinCAT OPC UA – Ignition OPC UA Client
TC’s OPC UA Gatway uses default port 4840 and this is the port the TC Gateway will point to. However, the end-point of that TC UA Server entry is a different port; for me on localhost, it was port 48050.
So if you add your OPC variable attributes in your TC Global Variable List or in a Program above the variables you want to expose, Activate Config and login, you should be able to see the tags you exposed via an OPC client.
For me, Ignition would cycle between “connecting” and “faulted” with port 4840. Creating a new OPC Connection at same URL but Port 48050 allowed me to connect and see tags.
For me the the problem was that I could not connect using security “none” but then we realized that it was disabled.
It was commented on the file, we removed the comments to enable it and it started working on port 4840.
