remote access general strategy?

Hey all,

I'm teaching myself PLC programming, and don't have a lot of resources at my disposal, so probably a very basic question, but I recently was able to do some minimal work with someone more experienced/get a peek at his code, but now am curious: is there some sort of general strategy for remote connections (mostly for the purpose of debugging if necessary/deploying an update to the code)?

My colleague (who wasn't in the same physical location) seemed to be able to access the HMI over the ethernet connection to our router, but didn't seem to be able to access the PLC in any way, because he would remote into my laptop & use the EcoStruxure from there, though could update the HMI remotely. This seems to match my experience, which is that I can access my HMI via ethernet, but can't access my PLC remotely (though in my case, I don't know if this is just because I don't know how). For reference, he's using a Schneider electric PLC, and I've been working with IDEC.

But this also brings up the question, of when you're working with a PLC & HMI combo, are you typically doing your calculations on the PLC or the HMI? How do you typically split up your code between the two? I've been doing most of my calculations and such on the PLC, but in principal, I could be doing them on either the HMI or PLC; is there a more typical/preferred way to do this, or a strong argument to do it one way or the other?

Cheers

I'll leave the remote access to others. I know that there are a number of ways to do it and they're all outside my experience of setting up. I've used different tools provided by our IT folks (VPN, remote desktop) but I've never set it up.


As for how to blend HMIs and PLCs, I lean strongly towards having as much as possible handled in the PLC and as little as possible in the HMI. The reason is that I've had to replace HMIs with a new platform a LOT more often than PLCs. The fancier you get in the HMI, the more likely you'll have trouble replacing it with something else.

I agree that calculations related to the control of the machine belong in the PLC. Any technician troubleshooting after you've gone, will expect to look in the PLC.
Calculations related to how the information is displayed on the HMI can be made in the HMI. Quite often, they are part of the configuration of the on-screen object anyway.
If you ever find it necessary to do operational calculations outside of the PLC, be sure to document that fact in the PLC program. Maybe a rung comment that says, "The value in the tag 'XYZ_TAG' is calculated in the HMI". Some people include the text, "From_HMI" in their tagnames, but that may only imply that the data is an operator entry.

To your 1st question, the PLC must be reachable via the VPN connection. Usually on the PLC it means its Ethernet port must be setup with the router that is the final routing device on the PLC site.
The VPN connection from the office to the remote PLC site is done can be done in multiple ways. Sometimes the remote location has an IT department which will provide a VPN solution. Sometimes you can use a device which provides the VPN in a single unit.

To your 2nd question. No calculations that are related to the active process is done in the HMI. The HMI is 'merely' an in-out device. The HMI can possibly perform some statistics for reports or similar, but that is about it.

To your 2nd question. No calculations that are related to the active process is done in the HMI. The HMI is 'merely' an in-out device. The HMI can possibly perform some statistics for reports or similar, but that is about it.

Click to expand...

I don't agree with this, I do calculations in the place where they are best done. Particularly if the HMI has access to data from multiple sources. My aim is generally to keep the PLC/HMI communications to a minimum, so if that is achieved by doing calculations in the PLC, I do them there, otherwise I will work with the HMI. However it can make finding a fault harder, PLCs generally have a way for you to go online and see the code running, HMIs less so.

Thanks all, helpful information to have

Hi,
I can help with the remote connection. Schneider supports remote connection of monitoring code and download software (I am constantly remotely connected and works well). As someone wrote you need to have a VPN connection to the PLC or doing it via a remote computer that forwards the ports needed. I'm not sure what Schneider PLC you are using but here are some ports used by Schneider.
M241,LMCxxx use port 1105.
M262 port 11740.
M340 port 502.
If you are using a remote PC then you can use smart port forwarding (its a free windows software to forward traffic). if not you need to open the correct port on your router and get a VPN connection direct to PLC

BryanG said:

I don't agree with this, I do calculations in the place where they are best done. Particularly if the HMI has access to data from multiple sources. My aim is generally to keep the PLC/HMI communications to a minimum, so if that is achieved by doing calculations in the PLC, I do them there, otherwise I will work with the HMI. However it can make finding a fault harder, PLCs generally have a way for you to go online and see the code running, HMIs less so.

Click to expand...

I guess it's all about priorities.

Your priority as you stated is "to keep the PLC/HMI communications to a minimum." I'm not positive why this is your priority, but I suspect that it's to keep screen data update rates as fast as possible and that your strategy is tailored to (or heavily influenced by) whatever PLC/HMI platform you're most accustomed to as well as the kind of system topologies you typically work with.

My priority is to keep code manageable, readable, troubleshootable, and not have processes dependent on mystery values calculated behind the closed doors of a HMI. Also I've had undue trouble every time a HMI went obsolete and I had to convert the project to a different HMI; less so with upgrading to a new PLC. I optimize HMI communications in other ways such as using arrays to send big chunks of data in a single call instead of many individual calls to different widespread memory areas, and limiting the amount of data displayed on any one page.

One alternative is if the HMI PC is available via the Internet, install Chrome Remote Access and then run the PLC dev tools from this.

Alternatively look at a TOSI box or other M2M solution.

You may be able to do this with a Raspberry PI built as a WireGuard Server

I regularly use TeamViewer or Chrome Remote Desktop to access a PC that has the software tools and utilities that I need, and is physically plugged into the client's automation LAN. That generally requires that all the software be installed and licensed on that computer. Some of our customers set up a PC specifically for a machine system, often just designated the "maintenance laptop" and it's straightforward for them to connect it to the Internet via their own enterprise network, and then to the automation LAN.

Where TeamViewer and CRD bring their value is that they are "cloud brokered" services, so nobody has to set up a VPN or other access method so that I can connect to that computer remotely over the Internet. With proper credentials and authentication, that computer can also be left unattended, giving me access to work without someone having to let me connect to the system every time.


I have also been learning to use ZeroTier effectively, to bridge between computers and devices, especially with manual static routing at the far end.

I have a tiny $30 travel router sitting in my shop, connected to a small network of controllers and devices via its hardwired LAN port, and connected to our guest WiFi system over the wireless port.

Using ZeroTier, my virtual machine and the travel router get a 10.172.44.xx address, and I can SSH or HTTP into the configuration of the router at that address from my VM.

But also I've set up static routing using the ZeroTier website, and when my VM wants to access 192.168.1.10 (for example), it routes that traffic to the LAN port of the travel router, and then to the PLC.

It's a little tricky to get working, and to keep straight which network I'm connected to. It's actually slower when I'm on a network that's connected to my campus network (because the Guest WiFi is walled off on purpose and the traffic has to be relayed through ZeroTier's servers). But it's inexpensive and stable and secure.