Hello everyone, I am currently working on a project that involves utilizing Allen Bradley Micro850 controllers with Ethernet IP functionality. The goal of the project is to establish a connection between multiple controllers across various locations to a centralized server in the cloud using Modbus over TCP/IP as the communication protocol. One challenge I am facing is ensuring that each device does not use the same register location, as Modbus operates on a set register system. Although I do not have a solution yet, I am optimistic about finding one in the future. My main concern, as highlighted by a source on the internet, is the requirement for all devices to be on the same subnet for communication to occur with Modbus TCP. This means that devices with different IP addresses, such as 192.168.10.x/24 and 10.100.45.x/24, may have difficulty communicating. Is there a way to overcome this obstacle? This project marks my first experience with Modbus, presenting a significant challenge for me. I have sought guidance from various resources, including videos like "Allen Bradley Micro850 Modbus TCP Server" and "Turn a Micro800 into a Modbus TCP Server." However, it seems that the examples shown in these videos involve devices on the same network, rather than operating over the internet. As a result, the Modbus data may remain within the local area network (LAN) rather than being transmitted over the internet. Thank you in advance for your assistance and support.
I am currently learning about cloud storage architectures, and it seems possible to achieve data exchange by establishing a network path to reach each controller through a centralized or distributed middleman. Even though I have not personally utilized the Modbus TCP nodes in Node-Red, it should be capable of managing this process effortlessly. Additionally, Node-Red offers various server nodes that may be necessary for this task. It is worth exploring further.
According to thehoneybadger, the objective is to establish a connection between various controllers across different sites and a central server in the cloud by utilizing modbus over TCP/IP as the communication protocol. It is important to note that with TCP/IP, clients connect to a server, and not the other way around. The Micro850 PLCs would act as servers (Modbus slaves) while the client, serving as the Modbus master, would read or write the data. One challenge with this setup is that all Micro850 devices would require a public and static IP address, which can be costly and may pose security risks when unencrypted data is transmitted over the network. A more secure and cost-effective solution would be to have each remote location equipped with a router that supports VPN connectivity, automatically connecting to the central headquarters that requires a public and static IP. This approach offers several benefits, including all devices being on the same virtual private subnet. In addition to facilitating Modbus communication, it also allows for remote access to PLC programming with encrypted traffic for enhanced security measures.
When it comes to TCP/IP communication, it is important to understand that servers typically do not connect to other servers. In the context of the Micro850 PLC acting as servers (Modbus slaves) and clients (Modbus masters) interacting with them, it is crucial to consider the need for public and static IP addresses for each Micro850. This requirement may not always be feasible and could introduce security risks with unencrypted data transmission over the network. To address these challenges, I recommend implementing routers with VPN capabilities at each remote location, automatically connecting them to a central headquarters with the necessary public and static IP address. This setup offers numerous advantages, such as all devices being on the same private subnet, enabling secure communication not only for Modbus but also for remote PLC programming with encrypted traffic. In my current system, I have a single device in the field communicating via a 4G modem antenna to an offsite VPN server. The next phase involves expanding to two devices at separate locations using their own 4G modems to communicate with a shared VPN server. Additionally, I am looking to set up a website with web sockets to remotely manage and configure the PLCs. Each site will have unique login credentials, allowing for separate web pages controlling different PLCs through web sockets associated with Modbus registers. While my communication setup has been secure so far, I am exploring new solutions for remote access, moving from onsite panelview access to offsite control via a custom web page hosted on a cloud server. As I focus on PLC programming, I am seeking assistance from experts familiar with Modbus and web socket integration for this project. If you have experience in this area, please reach out to discuss potential collaboration.
When considering connectivity solutions for remote locations, utilizing an MQTT Server, preferably cloud-based, can be a highly effective choice. By implementing a publish/subscribe model across all remote sites, you can significantly reduce bandwidth usage and streamline communication. Moreover, utilizing a VPN for added security can further enhance data transmission. Compared to Modbus, MQTT offers a more straightforward approach to handling instances of "Lost Communication."
The Old Man recommended using an MQTT Server (potentially cloud-based) for a more streamlined approach. By having all remote locations "publish/subscribe" to the server, you can significantly reduce bandwidth usage and easily manage "Lost Communication" issues compared to using Modbus. Utilizing a VPN for added security is also an option. Thank you, OM, for the advice on utilizing MQTT, I have a feeling this will be our final solution. Have you had experience with this before based on your bio? It seems like you are well-versed in this method.
Hey there! I can understand how challenging this project could be, especially if it's your first time dealing with Modbus. Unfortunately, you're right about the same subnet requirement for Modbus TCP. However, one potential workaround could involve using VPN tunnels to link your different subnets together, essentially making them appear as if they're on the same network from a routing perspective. You'd need to configure the VPN connections so that the devices can see each other across the networks. I hope this helps, and good luck with your project!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - Answer: To prevent conflicts, carefully assign unique register locations to each device as Modbus operates on a set register system.
Answer: - Answer: Yes, devices need to be on the same subnet for seamless communication with Modbus TCP. Devices with different IP addresses may face difficulties, but there are ways to overcome this obstacle such as using VPNs or routing strategies.
Answer: - Answer: To enable Modbus communication over the internet, consider setting up secure connections like VPN tunnels or using routing configurations to allow devices with different IP addresses to communicate effectively.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.