Flexy 205 issue reaching devices

Ewon Support Ewon Flexy
, ,
#1

Hello,

I hit send on my last post before I could finish it, and it said that it needed pre-approval to post, so I’m just going to complete it here. Delete my last post from an the prior hour. Thanks.

I’m pretty sure this is a firewall/protocol blocking issue, as I can connect to many of our other systems of nearly identical design without any issue.

I am able to connect to the ewon via talk2m, but some odd things are happening that are preventing me to fully connect to the allen bradley 5380 and the siemens TP1500 in our system.

I can ping the allen bradley 5380 PLC when it’s the only device plugged into the machine ports (beside the top-right WAN port), but I can’t reach the web landing page or see it in rslinx. when only the Siemens TP1500 HMI is plugged in, I can see it on the profinet explorer, but I cant ping it or reach the web landing page, or see it in the TIA portal software.

We typically set up our systems so that they operate if the ewon needs to be pulled, so we network the PLC directly to the HMI, and then the HMI to the ewon’s machine port. This works due to how the HMI’s ports act as a switch at the HMI’s X1 interface. But, oddly, I can’t ping the PLC. The activity LED’s shared by the ewon and the device used just don’t seem very active, but they are blinking occasionally, so the ports and cabled are unlikely to be faulty.

I did try to ping from the ewon’s IDE program, but couldn’t get it to reach anything.

Again, I suspect an advanced firewall or protocol blocking of sorts.

Backup + support files.
MOVED TO STAFF NOTE (179.5 KB)

#3

The other thing that I suspect is another set of devices sharing the 10.0.0.X IP range exists on their network. They do have someone in their IT department looking into their network/firewall, but this will not likely be fully looked into until Monday.

PLC 10.0.0.10
HMI 10.0.0.11
ewon 10.0.0.53

I should also mention that when I ran pings with the -t option on my command prompt on my PC to the PLC when it was the only device connected, the pings stopped at the same moment that it was unplugged.

Strange stuff. Thanks in advance.

#4

There is a firewall on the LAN side of the Ewon?

It does sound like a routing issue though, which unfortunately we wouldn’t be able to help you with much as it’s due to third party equipment and not the Ewon.

Have you tried using a different switch?

#5

Hey Kyle,

There is no firewall on the lan side (ports 1-3) of the ewon, only the top-right wan/internet port. I’m just puzzled why the devices are semi-accessible. It’s also puzzling how I can easily reach the default ewon address of 10.0.0.53 via ecatcher, but not the devices.

I will probably try to have them plug both the PLC and hmi devices direct into the machine ports rather than in through the hmi’s dual Ethernet port.

the IT department will probably be looking at their network/firewall this morning.

I may try to reprogram the devices to a different IP range to see if that helps, but it’s probably gonna be similar. I think their firewall is doing some deep packet inspection and making things halfway operational. I’ll also have them run the connection checker.

Let me know if you want to try remoting in through our ecatcher account to check it out.

Thanks!

#6

Make sure that the LAN devices (PLC, HMI, etc.) have the default gateway set to be the Ewon’s LAN address (10.0.0.53). Maybe plug and route is not working…

Make sure to go through and check all the items in this article: Unable to Connect to LAN Device

#7

It’s working. I’m not sure exactly how it was resolved, maybe its a bug in the Plug 'n Route.

We rewired the ethernet for each device to go into the machine ports of the ewon. That didn’t appear to fix anything though.

  1. I set it to NAT & TF Disabled.
  2. Power cycled
  3. Enabled Plug 'n Route
  4. Power cycled
  5. now it works. Still can’t see the allen bradley web based landing page. Not necessary though, since I can program it via the software and rslinx can see it.

There is a possibility that they changed firewall settings at the same moment though.

Thanks for your time and support!

#8

Interesting. The NATitf setting does require a reboot to take effect so maybe that’s what fixed it.

Let us know if you have any other questions!