Hello everyone, I am currently working on a project that involves integrating the SV (Set Value) of a temperature controller with a SCADA system. The setup involves connecting the SCADA system to a PLC using Modbus TCP, which in turn communicates with the temperature controller via serial/rs485 protocol. For seamless operation, the SCADA system should be able to both read the current value and modify it as needed. One approach I am considering is exposing a single register for both read and write operations on the PLC. This way, the SCADA system can access the register using Modbus TCP. The ladder logic in the PLC will then verify any changes in the value and, if necessary, write the updated value to the temperature controller. While researching this setup, I came across some forums that suggest this may not be the best practice. I would greatly appreciate any insights or recommendations on how to effectively address this scenario. Your opinions and suggestions are highly valued. Thank you.
What type of system is the SCADA (PC, MCU, Arduino, Custom)? What protocols are supported by the SCADA system? Similarly, what type of system is the PLC and what protocols does it support? When selecting a protocol, I prefer to troubleshoot independently from both ends. For example, if the SCADA system operates as a Modbus Master and the PLC as a Modbus Slave, I would initially set up a simulated Modbus Slave on a Windows or Linux PC. This allows the SCADA system to communicate as a Modbus Master, reading and writing holding registers. Next, I would configure a Modbus Master on a PC to communicate with the PLC functioning as a Modbus Slave, ensuring that data can be read and written successfully. Using PC-based Modbus applications provides enhanced diagnostics for problem-solving. Only after successfully running these individual processes would I attempt to connect the SCADA Modbus Master to the PLC Modbus Slave. While some may skip ahead to this step, troubleshooting tools are limited and complex if issues arise.
I am curious to understand the source of the information that suggests it is not a recommended practice, as I believe it is perfectly suitable when utilizing Modbus. Modbus protocol is specifically designed to allow a single register to be both read and written to, known as Holding Registers. Holding Registers are the most commonly utilized type in Modbus communication. When implementing Modbus, it is advisable to expose a single read/write register for each parameter, such as a Set Value. It is not typical, and could potentially cause confusion among Modbus users, to split the Set Value into separate registers dedicated solely for reading and writing. It is important to note that there are other protocols (e.g. PROFINET IO, EtherNet/IP, EtherCAT) that facilitate separate input and output data streams requiring segregation into read-only and write-only blocks. However, this distinction is inherent to the nature of the protocol and should not be mistaken for a universal best practice.
When implementing value comparisons in a PLC system, it is important to ensure error-free communication between the old and new values. By routinely monitoring and verifying data transfer to the controller, potential errors can be quickly identified and remedied. Additionally, it is advisable to set initial values upon system startup to avoid discrepancies. For instance, assigning an unachievable value to the previous value register can signal the PLC to initiate the writing process. These practices help maintain consistency and reliability in the automated system.
Many legacy process controllers have restricted write cycles for certain settings due to limited EEPROM storage capacity. However, it is unlikely that a PID Setpoint would be affected by this limitation. The potential risk of frequent writes to the temperature controller should be considered in such cases.
Your approach seems logical on the surface, but it does pose a risk, especially around error detection and recovery. By sharing a single register for both reading and writing, any issue that occurs might be more difficult to debug since you're not sure whether the problem is with reading or writing operations. Instead, you may want to consider using separate registers for reading and writing operations, even though it might seem more complicated. This clear separation would make problem detection and resolution easier because you know exactly where the problem occurred. In addition, while developing ladder logic, you can plan redundancies and audit trails specifically targeted at error detection and recovery. Also, consider the implications of allowing SCADA to modify the temperature controller values directly. In terms of safety and traceability, having a single point of modification and more control over it usually tends to be more desirable. Good luck!
Hi there, it sounds like you're on the right track with your project. Exposing a single register for both read and write operations on the PLC is a commonly used approach and can work efficiently. However, one of the reasons this might not be considered best practice is due to the potential security risks. If not properly secured, this approach could allow unauthorized access to the temperature controller. As an alternative, you might consider using separate registers for read and write operations, which can be more secure as it allows for better control over who can make changes to the system. Also, ensure that you have a robust error-checking mechanism in place to verify the integrity of all outgoing and incoming messages to avoid faults or discrepancies. Hope this helps!
I've worked on similar projects before. Based on my experience, your approach seems workable; however, having a single register for both read and write operations might potentially lead to sync issues especially if multiple SCADA systems access it concurrently. Alternatively, you could consider segregating the tasks - utilize one register for reading the current temperature and another for writing the updated value from the SCADA. Of course, your ladder logic should be tailored to handle this bifurcation. This method adds a layer of separation and could possibly avoid conflicts. But, regardless of the approach, a crucial factor is managing the sequence and timing of the read/write operations to ensure the system's smooth functioning.
✅ 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: 1. What is the recommended approach for integrating a temperature controller SV with a SCADA system using Modbus communication? - The recommended approach involves connecting the SCADA system to a PLC using Modbus TCP, which then communicates with the temperature controller via serial/rs485 protocol. Exposing a single register for both read and write operations on the PLC can facilitate seamless operation.
Answer: - Exposing a single register for both read and write operations on the PLC allows the SCADA system to access the register using Modbus TCP, enabling it to read the current value and modify it as needed. The ladder logic in the PLC can verify any changes in the value and write the updated value to the temperature controller if necessary.
Answer: - While this approach may seem convenient, some forums suggest that it may not be the best practice. It is important to consider factors such as data integrity, real-time updates, and potential conflicts in simultaneous read and write operations when implementing this setup. Further insights and recommendations from experts in the field may help address these concerns effectively.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.