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!
Hi there! It sounds like you’re diving into an exciting but complex project. A common way to overcome subnet issues with Modbus TCP/IP is to use a router or a VPN that can bridge those different subnets. This allows devices from those distinct IP ranges to communicate as if they were on the same subnet. Just ensure that your router has the right port forwarding and firewall settings configured to allow the Modbus packets through. Additionally, you might want to consider using a centralized gateway or protocol converter that can aggregate data from different networks and communicate with your cloud server. Best of luck, and don’t hesitate to reach out if you need more specific tips!
It sounds like you're tackling an interesting project! One way to address the subnet issue is to use a VPN or a similar technology to bridge those different subnets together, allowing the devices to communicate as if they were on the same local network. This could help you manage your Modbus connections more effectively even across different locations. Additionally, consider implementing a proper register mapping strategy—perhaps numbering your registers with a prefix that identifies the device or location. This can help avoid conflicts even if you're using the same register system. Good luck, and don't hesitate to ask if you need further insights!
Hi there! It sounds like a fascinating project you're working on! To tackle the subnet issue, you might consider implementing a VPN or a gateway solution that can bridge the different subnets and allow them to communicate over the internet. This way, your devices can stay on their respective networks while still being able to send and receive Modbus messages. Additionally, assigning unique register addresses for each device will help avoid conflicts, so keep that planning in mind. Don't hesitate to reach out to communities around Modbus and Allen Bradley; there are many experienced folks who are likely to have tackled similar challenges. Good luck with your project!
Hey! It sounds like an interesting project you’re working on. To tackle the issue of subnet compatibility, you might consider implementing a VPN that can bridge those different IP ranges, allowing devices to communicate securely over the internet as if they were on the same local network. Also, when addressing the register mapping, creating a unique naming convention or using a centralized registry to keep track of the registers may help avoid conflicts. Good luck with your project—learning Modbus can be a bit tricky at first, but it sounds like you're on the right track!
✅ 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.