Hello! We are currently working on an upgrade project that involves replacing an existing GOP panel (Modbus RTU Slave) connected to an AC80 Controller (Modbus RTU Master). The proposed replacement is a Siemens MTP1500 HMI, but we are facing a challenge because the AC80 must be a Modbus RTU Master, while the MTP1500 HMI does not appear to have the option to function as a Modbus RTU Slave. We are considering the possibility of using a S7-1200 PLC to act as a slave to both devices and facilitate communication. We are unsure if this solution is feasible, so any assistance would be greatly appreciated.
If the panel is functioning as a slave, there may be challenges due to Siemens' lack of support for modbus bits and words independently within their modbus blocks. In order to communicate effectively with both the panel and AC80, registers need to be packed into memory words and remain continuous. Consider using a controller from a manufacturer that natively supports modbus, such as Schneider, to avoid compatibility issues.
If your GOP screen is displaying data retrieved from the AC80, then the GOP is functioning as the master while the AC80 acts as the slave. It is crucial to note that this setup is non-negotiable. Switching out the GOP for another HMI screen should not pose any issues, provided that it is compatible with Modbus RTU. In such instances, the hierarchy is clear - the screen takes on the role of the master, while the controller/PLC assumes the position of the slave. In a serial network, it is imperative to understand that only one master can exist. Collisions can occur if two masters attempt to communicate simultaneously. The synchronization process for a serial master involves a strict order of request-response sequences. For multiple masters, transitioning to ethernet communication and utilizing Modbus TCP is recommended for seamless operation with multiple screens connected to a single device.
The AC80's manual (http://download.5117.com/data/file/361.pdf) specifies on page 28 (2-14) that the Ch2 port offers two modes of operation: "Panelbus" mode and "MultiVendor" mode. In "Panelbus" mode, the AC80 acts as the master (as detailed in the CH2TYP setting on page 40 (4-2)). In "MultiVendor" mode, it can be configured as either a master or a slave. Both modes support GOP. It appears that the AC80 may currently be set to "Panelbus" mode, and changing it to "MultiVendor" mode as a slave is likely necessary for compatibility with the new HMI.
After reviewing the software instruction manual for the GOP panel, I discovered that it specifies "AC80 always functions as the master while GOP acts as the slave." I overlooked checking the AC80 documentation, but I will make sure to review it now to understand how it can interact with the new HMI as the master. Thank you for pointing me in the right direction!
In the context of data exchange between a GOP screen and an AC80 controller, it is crucial to understand the dynamics of master-slave relationships. Essentially, when a screen needs to access data from a controller, the screen acts as the master and the controller as the slave. It is important to note that in a serial network, there can only be one master to avoid collisions. Therefore, if multiple screens need to connect to the same device as masters, it is advisable to switch to Ethernet and use Modbus TCP. While it is technically possible for the panel to act as a slave in rare cases, it is more common for the panel to function as the master. Additionally, it is feasible to have multiple serial masters connected to a PLC by incorporating multiple slave ports on the PLC side. Moreover, the use of multiplexers for RS485 can facilitate the connection of several Modbus serial masters to a single slave.
Your solution of using a S7-1200 PLC as the interface between the two systems sounds reasonable. The S7-1200 can indeed work as a Modbus RTU Slave. In this setup, the AC80 can communicate with the PLC via Modbus RTU, and then the PLC can pass on the relevant data to the MTP1500 HMI through Profinet or Profibus. However, do consider potential latency issues that might arise due to this conversion. Additionally to mention, ensure to meticulously script the data mapping and routing in the PLC to avoid data mismatches. Getting a specialist who can debug Modbus RTU and other communication systems onboard could make this transition smoother.
Making the S7-1200 PLC act as a mediator could potentially solve your problem. You would have the AC80 Controller communicating with the S7-1200 over Modbus RTU, and then have the S7-1200 communicate with the MTP1500 using Profinet or Profibus, which the MTP1500 should support. The concern, however, is the additional complexity this introduces into your system. You will need to ensure robust error handling and possibly deal with slower response times due to the need to translate communication between the two devices. I'd recommend thoroughly testing this setup before deciding on it as your final solution.
In my experience, incorporating an S7-1200 PLC as a mediator could be a feasible solution. Siemens S7-1200 PLCs are known for their strong communicative capabilities and certainly support Modbus RTU. While I haven't specifically implemented one to bridge communication between an AC80 and MTP1500 HMI, I'd imagine the principles stay the same. It'll be crucial to thoroughly design your communication architecture to minimize latency and loss of data. Moreover, ensure that the S7-1200 PLC has the necessary processing power and memory to handle this bridging task.
It sounds like you're navigating a complex integration challenge! Using the S7-1200 PLC as a Modbus RTU Slave could indeed be a solid solution. It can act as a bridge between the AC80 and the MTP1500, allowing for seamless communication. Just make sure to configure the S7-1200 correctly to interpret the signals from both devices so that they can share data effectively. Also, double-check the specific Modbus configurations, as the settings for baud rate, parity, and data bits need to align across all devices. Good luck with your upgrade project!
It sounds like you’re on the right track with the S7-1200 as a potential solution! Using it as a Modbus RTU Slave could definitely bridge the gap between the AC80 and the MTP1500, allowing for smooth communication between the two. Plus, the S7-1200 has robust capabilities for handling data exchange, so it should work well for your needs. Just make sure to check the configuration and wiring specifics to avoid any hiccups in setup. Good luck, and I hope it all comes together seamlessly!
It sounds like you're navigating a tricky integration issue! Using the S7-1200 PLC as a Modbus RTU Slave could definitely be a viable solution, as it can bridge the communication between the AC80 and the MTP1500 HMI. Just ensure that the S7-1200 is configured correctly to handle the data exchange and that you map the registers appropriately for both master devices. Also, double-check the response times and overall load on the network to prevent communication bottlenecks. Good luck with the 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: - Yes, it is possible to use a Siemens S7-1200 PLC as a Modbus RTU Slave to connect the AC80 Controller (Modbus RTU Master) and the Siemens MTP1500 HMI. The PLC can bridge the communication gap between the devices by acting as an intermediary.
Answer: - Using a PLC as a communication bridge offers flexibility, scalability, and the ability to handle different communication protocols. It allows for seamless integration between devices that do not directly support the required communication protocol.
Answer: - When configuring the S7-1200 PLC as a Modbus RTU Slave, ensure that the communication settings, such as baud rate, data format, and addressing, are correctly configured to match the requirements of the AC80 Controller and the MTP1500 HMI. Additionally, verify that the PLC programming includes the necessary logic to handle the data exchange between the devices.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.