We configure our EB1’s with a non-routable ip address common to the controller’s ENET 2 port. By doing so it keeps all the i/o traffic local and isolated…straight out of the SNAP PAC User’s Guide.
With this configuration we alienate ourselves from inspecting the EB1 and installing firmware to the EB1 unless we are physically at the device. Not practicable for all of our remote locations.
Building out a separate network is not an option.
Is it possible to implement a procedure similar to the “Install Firmware via Ethernet Passthrough Connection” for SB1 brains?
Generally you wouldn’t want to upgrade firmware unless you could physically access the device, in case something goes wrong and you have to reset it manually.
Also, normally you wouldn’t want to upgrade firmware at all unless you’re adding a module that wasn’t supported in the old firmware, need a bug fix, or want some new feature.
What’s you’re motivation for upgrading the firmware?
We have a new project with many installations at remote locations…forward looking, I do not want to have to fly to every location to touch every brain.
Your latest 9.5 firmware is a good example of why you would want to upgrade firmware…to get the restful api functionality. Bug fixes are always a possibility. I would expect eventually you will release a new version of PAC Project that will need a firmware upgrade to take advantage of new features.
…and it’s not just firmware installs. You lose all the functionally PAC Manager gives you with “inspect” and “maintenance”.
Yes! 9.5 is wonderful, but that’s mostly for controllers–you’re talking about brains here. Given your desire to inspect, etc., my next question is: why not just put the EBs on the same network as the controller?
Okay. That makes sense. So how about, when you’re ready to update the EBs, you connect to a hub/switch where the controller is and connect to those EBs from there. Hopefully this will also have you physically closer to the EBs if/when you do a firmware upgrade, in case something goes wrong during the upgrade.
Note from above, “We have a new project with many installations at remote locations…forward looking, I do not want to have to fly to every location to touch every brain.”
It also doesn’t solve, "You lose all the functionally PAC Manager gives you with “inspect” and “maintenance”.
You could install a VPN router at each location to bridge between your rout-able network and your private network. Another option, if there is a PC on site, is to install two network cards and have the PC system on both networks. Then you can RDP/VNC to the PC for firmware updates and PAC manager duties.
Aside from my concerns about “could” vs. “should”; getting back to the original question of “is it possible to implement…”
The “inspect” part of PAC Manager reads values from the memory map, which is something that can be done in a chart, ditto for the sending of files via ftp required to do a firmware update. So in theory, yes, one could implement those PAC Manager functions in a custom chart triggered by various user tags. But it wouldn’t be easy.
However, I’m thinking Robertson might have been suggesting adding such a pass-through feature in the controller – but that would essentially poke a hole through (defeat the main purpose of) the very network setup that started this discussion.
I like where philip is heading with his VPN-ing, etc. Keep those good ideas coming!
It wouldn’t be too difficult to setup a chart that proxied/echoed the TCP port for OptoMMP from the rout-able network to a device on the private network using a couple comm handles. No user tags necessary other than the comm handles and perhaps a string for the target network address. FTP would be slightly more challenging with the way it operates on multiple ports.
I don’t understand this, if the Opto devices are on a separate network, then you already have the infrastructure to keep i/o traffic separate even if the devices are on the same network other than some minor network broadcasts. We are way past the days of network hubs where all traffic gets broadcast everywhere.
Again, good points, Philip. FYI - if you did write such a chart, better to use a udp comm handle. (PAC Manager can be configured to communicate via udp vs. tcp which is handy if you’re using a lot of sockets on that controller.)
The controller’s ENET port 1 is on the company general network. The EB1 is connected to the controller’s ENET port 2 which is configured on a separate network with only i/o traffic.
I was hoping to inspire someone at Opto to see that is usefulness of being able to communicate to brains configured on the second ENET port, using PAC Manager, through the controller they were attached to, without having to do a workaround.
Just dug up this chart I’d written a while back (it’s in 9.4 basic so you can import the chart into any strategy that’s 9.4 Basic or better). The chart does what philip describes above for mem map read/writes via PAC manager. It’ll do either tcp or udp. Here’s how I tested it for this use-case:
Configured my “other network” brain to have IP = 10.10.10.1
Configured this chart to communicate to it via udp (so my comm handle gets set to: “udp:10.10.10.1:2001” via the string sRemoteDeviceHandle)
Configured this chart to listen on port 2002 (so that comm handle gets set to: “tcp:2002” via sListenerHandle). Note: you could use udp for that too, but PAC Manager uses tcp by default.
Hit the controller running this chart on port 2001 and got the controller’s info. Hit the same controller on port 2002 and got the remote/other network brain’s info, thanks to the re-routing done by this chart.
Of course, if you had several brains you wanted to reach you’d need to do something a little fancier. Perhaps use 2003 for the 2nd brain, 2004 for the third, etc. then have the chart map those ports to the appropriate IP addresses down the line.
Another idea would be to write the remote IP (the 10.10.10.1) to a string variable and build the comm handle from that (or change the value of sRemoteDeviceHandle directly).
