While I await IT’s plan for some type of converged ethernet architecture in our plant or approval to buy good networking hardware at the machine level. I bought this router. To try and get one of the 30 machines, with more or less the same config, I have online.
50 bucks and claims to do what I need. Has a pretty cool web app that gives access to the os to make all the rules and whatnot.
These machines, par for the course, all have their own network. In the default range.
Something like…
192.168.0.1 – PLC
192.168.0.2 – HMI
192.168.0.11 – Keyence GT2
192.168.0.10 – SMC air manifold
With everything going back to a cheap unmanaged switch.
So the idea was to try and set up 1:1 NAT translation (192.168.0.1 → 150.150.80.200) As cheap as possible so I can get ahead of the game and have something to develop against. Even if it’s somewhat unreliable. Or better yet it proves to be reliable and we save a but load of money. Not holding my breath tho.
So got the router set-up, I should preface this, and say I don’t really know what I am doing. Up until I found ignition I mainly did web dev as a hobby and robotics programming. And we have useless 3rd party IT support.
Then tried I to make a connection to the PLC. (CompactLogix L16ER Rev 20.19) . Watching the router it seems like it may try to connect. It will TX some. I can see the activity on the router. So I took a capture to see what is going on… But, its a bit cryptic to me. Looks like its getting rejected? As always any guidance, words of wisdom, encouragement is appreciated.
I am not a guru in this subject, but have had some experience with NAT routers, we are using Moxa EDR810, in our setup the moxa has a WAN side and a LAN side, hence 2 IPs, the devices in the LAN side need to use the LAN IP of the moxa as gateway. If we dont configure the gateway, the requests get to the PLC but responses dont make it all the way back to Ignition.
I would assume something similar needs to happen in this router.
I’m not a networking guru, so I can’t talk to the ‘hows’, but we’ve used these on projects a few times, they are great little devices for the money. I know you CAN do what you are looking for though since we did it, I just don’t have the configuration
Have you set the default gateway on the CompactLogix to the LAN IP of the Ubiquiti router? And how is your development PC connecting to the Ubiquiti router? If it’s going through any other routers on the same subnet as the WAN side of the Ubiquiti router, you’d need to setup routing in them so they send requests for addresses on the Ubiquiti LAN IP range to the Ubiquiti’s WAN IP (otherwise they’d get sent out the default gateway on the other router(s), rather than to the Ubiquiti router).
And we’re moving to all Ubiquiti for our corporate wireless networks; I don’t think you’ll need to get a different router (unless you need a wider temperature range or something; most of the time you’ll be fine on the cold end as long as things stay powered up to make their own heat, but the hot end can be a different matter).
Thanks! I will swap out the gateway address for the address of the switch in PLC. That makes sense.
As far as the other stuff down the line I don’t have access or the skill set honestly to fiddle with it. I would have to make a request to our IT supplier. And they are quite difficult to work with. For some reason they have the gateway pointed at the HMI address. But, surely the plc address is referenced in the project. I don’t know as the OEM has source protection on their HMI projects and they haven’t given them up yet.
It depends how everything is connected and configured. It can't hurt to try changing the default gateway in the PLC to the LAN IP of the router. If the HMI still works (and I expect it will); all's good. If not, change it back
Considering all devices are in the same vlan “192.168.0.x” gateway should not be needed for local traffic @ the machine (PLC, HMI, GT2 and SMC) , gateway address is used when “talking” to other vlans.
Appreciate all the help guys. I think the problem is on down the line. On network equipment. I can see when Ignition tries to make its hook. But, its getting killed from somewhere else. And if that is the case I think I would have the same problem from the $900 AB NATR switches. But, who knows?
Not knowing the topology between your development PC and the PLC (other than the Ubiquiti router), it's hard to say. Are you using the PLCs LAN IP in Ignition and the PLC development software? Or the routers WAN IP?
You can eliminate other network devices and test with a laptop connected directly to the router's WAN port (didn't look up, but assuming it does auto-crossover--otherwise you need a cross-over cable) and a static IP address set on the laptop compatible with the router's WAN IP. If that works and you can't reach things on the other side of the Ubiquiti router (I'll use Ubiquiti router to ID your equipment LANs--obviously could be another brand router) from elsewhere, most likely you've got a router in between that will need to be setup to route requests to the IPs inside your Ubiquiti LANs to the WAN ports of your Ubiquiti routers. This brings up another issue; the LAN IPs on your Ubiquiti LANs would need to be unique for this to work (not the same for each Ubiquiti LAN). If you want them different so your PLC development software (and Ignition) can access the PLCs via Ubituiti WAN IPs, you'll need to play with port forwarding in the Ubiquiti router so requests sent to it for the PLC are forwarded to the PLC. In other words, there are two ways to do this:
Use unique LAN subnets for each equipment LAN (LAN side of Ubiquiti router) and have any other routers between Ignition and it setup to route requests for those subnets to the appropriate Ubiquiti router WAN IP. With this setup, Ignition would use the IP address of the PLC (not the WAN IP of the router).
Use the same LAN subnets for each equipment LAN and setup port forwarding on the Ubiquiti routers to send requests on the ports needed for PLC connection to the PLC. With this setup, Ignition would use the WAN IP address of the router to access the PLC.
I'm not an expert on the networking stuff, but have had to sort it out at remote fly-in mine sites with no local knowledgeable IT multiple times, and so far have managed to be successful. The basic idea is that the Ubiquiti router either needs to know what requests addressed to it's WAN IP must be forwarded to a particular device on it's LAN (port forwarding setup in it), or other routers must know to send requests addressed to the Ubiquiti router's LAN IP to it's WAN IP (routing setup in whatever other routers lie between) and the device on the Ubiquiti LAN must have the Ubiquiti router's LAN IP set as it's default gateway so replies from it can get back out to the WAN side of the Ubiquiti router.
I was thinking of #1 in my earlier posts, but am guessing you want to do #2. Hope this helps!
We had issues with those, just make sure it work for you, they were blocking some traffic when we tested them. We opened several tickets to AB and they said they can only warranty their devices to work with AB PLCs. We ended up going for the Moxa EDR810 for about the same price.. The RedLion also gave us some issues, sometimes after a few hours we had to reboot them.
These worked great! For 50$ they never missed a lick. Zero issues. Can set one up in like 5 mins. I went with a big switch/router instead of these tho… A MikroTik CRS354-48G-4S+2Q+RM. Which was also great. These bought me some time tho for sure. They have a good OS and GUI as well.
They don’t have any din rail kits. Which is a bummer. Or phoenix type connections for power. Just barrel plugs. They just aren’t industrial enough for production. I think this silly of them.
They would be great for labs or dev and I have a bigger Umbiqiti L3 switch at home for an automated garden, shop door and lights, and security system. It works great as well.
