Hello,
We ae using a fairly new Mitsubishi module that adds an OPC UA Server to an FX5 CPU.
(FX5-OPC - Mitsubishi Electric Factory Automation)
This module is configured and programmed with 3 tags for testing purposes.
Unfortunately we are unable to connect to that OPC UA Server from our Ignition while a Kepware Server is able to connect to it and read the tags correctly.
Below the error we get.
We get the same when connecting to “opc.tcp://10.12.8.87:4840/Mitsubishi/FX5-OPC” or by connecting to “opc.tcp://10.12.8.87:4840”
We are using V8.1.10 and are able to ping the module from the server.
Does anyone has some experience with this Mitsubishi OPC UA module?
Thanks and kind regards,
Tony
Error message:
UaException: status=Bad_Timeout, message=io.netty.channel.ConnectTimeoutException: connection timed out: /10.12.8.87:4840
at org.eclipse.milo.opcua.stack.client.transport.uasc.ClientChannelFsm$ClientChannelActions.lambda$connect$0(ClientChannelFsm.java:126)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:578)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:571)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:550)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:491)
at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:616)
at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:609)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:117)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe$1.run(AbstractNioChannel.java:262)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: io.netty.channel.ConnectTimeoutException: connection timed out: /10.12.8.87:4840
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe$1.run(AbstractNioChannel.java:261)
… 8 more
8.1.10 (b2021090812)
Azul Systems, Inc. 11.0.11
This is just a plain networking error. Is there a firewall blocking outbound connections or something?
Do you have Kepware making an OPC UA client connection or are you connecting it using their Mitsubishi driver? Where is Kepware running relative to Ignition on the network?
IT department did confirm they are not yet blocking or filtering traffic from that ignition server.
I made a OPC UA connection in Kepware, not using the mitsubishi driver.
Kepware and Ignition are running both on different virtual servers but have acces to the same Vlan’s were using for our PLC’s in the production area.
Sorry, not sure what else you can do on the Ignition side. Maybe the module only allows 1 or 2 connections and they’re both somehow used?
You’ll probably have to work with IT to troubleshoot this.
Heard that one before, definetly was being blocked. If IT cant give you better help what does ping and wireshark tell you?
Hi,
I can ping the module from the Ignition server, no problem with that.
I installed wireshark. Below some messages from the moment Ignitions tries to connect but fails.
As I’m not that familiar with Wireshark yet, can you maybe spot a problem?
Ignition server: 10.10.1.24
Opc Module: 10.12.8.87
As I can not yet upload any files
WeTransfer Link to capture file
I don’t see any new problem, the capture just confirms that a TCP connection cannot be opened to this IP/port, because it immediately sends RST.
Hi Kevin,
Mitsubishi eventually came back to us with following answer:
Does this help in further investigating the problem?
Not really. It’s a cop-out answer from someone who probably doesn’t understand what they’re talking about.
These flags are being set by the TCP stack in your operating system (or an intermediate router, depending where the capture was made), not by Ignition, and if their TCP stack doesn’t support them they can just ignore them.
Tony_Quartier, did you find solution?
I am struggling second week having the same issue…
Sorry, did not find a solution.
Seems I’m a little stuck between Ignition saying it’s a Mitsubishi problem and Mitsubishi saying it’s not their problem…
Are you using the same FX5 OPC module?
In the mean time we also upgrade Ignition from 8.1.10 to 8.1.17
It is definitely Mitsubishi’s problem. Their statement that they send RST on unsupported flags is an admission that their protocol stack is misdesigned. They aren’t handling TCP/IP negotiation flags correctly (continuing while ignoring unknown flags is correct), flags the Ignition gateway’s OS is offering, not Ignition itself.
Sending RST for unsupported content in the channel would be reasonable. Not for TCP options.
I managed to connect FX5U to KEPSERVER EX (installed on laptop, time limited version), Mitsubishi Ethernet Driver. I had to add SLMP TCP connection in the PLC configuration. Settings in Kepserver EX: TCP, Port 5001. But I have to say I still have issues. I have a router for NAT between company’s VLAN IP addresses and machine Ethernet network. I have used this model router and configuration on at least 10 machines with various brands PLC. With the laptop, as I said, I can read tags from FX5U. I cannot do that using the licensed Kepserver, connected to Ignition, on company VLAN. Wireshark did not help me. There is something wrong with Mitsubishi Ethernet driver indeed for FX5U. FX3U did not have such problems.
This problem will keep getting worse as you install more modern routers and switches and use more modern operating systems. They all are going to attempt to invoke Explicit Congestion Notification (ECN) at a low level (not Ignition or Kepware’s doing). Mitsubushi’s statement suggests their engineers have their heads up their collective [plural expletive].
Mitsu doesn’t need to implement ECN–they can carry on without it. They just have to follow the TCP rules for the parts they do support.
Will get back once again to Mitsubishi…
All our Siemens and Beckhoff PLC work just fine using Ignition OPC UA and the same network infrastructure components.
@d.vasilev
I was able to connect from our KepServer to the OPC module by using OPC UA, not the Mitsubishi driver. But it seemed to be unstable to rely on.
Also I did not asked to include the OPC module to end up using Kepware and their Mitsubishi driver.
I want to use a direct OPC UA from Ignition to the FX5.
It seems like additional module need to be installed:
FX5-OPC UA
I am seriously thinking to do that, since I am running out with options.
@d.vasilev
I’m thinking you are trying to talk OPC UA directly to the FX5 CPU without additional module? Correct?
For the FX5 there is also a OPC UA module.
this is the one I have problems with…
FX5-OPC
Tony_Quartier
Well noted, good to know…
What I was doing so far, was to establish communication Kepserver EX - FX5U CPU.
As I said, it works normally laptop - router (NAT) - FX5U CPU.
If I connect the router Ethernet 1 port to company’s VLAN, it does not work.
BTW I just found out some issues with the cabling/switches…I can ping the router from my PC, but not from VM, where Kepserver is installed, so let me do some more investigations…
Issue solved. In my case, I had to disable ECN from the command prompt:
netsh int tcp set global ecncapability=disabled
Now I have it working normally.
3 Likes
I’m glad you got it working.
I’m also blown away that was actually the issue. It’s bonkers that Mitsubishi is using TCP stack so fundamentally broken…
4 Likes
