Seeking help regarding process alarms for the ECS700 central control system
Thread Content
Many of the company’s auxiliary equipment are connected to the system via 485 communication, such as RTO devices. This presents a problem: sometimes these RTO devices fail to start for a short period of time, becoming offline, and as a result, hundreds of devices connected via communication will generate ERR alarms. This significantly affects the monthly performance metrics, as the number of alarms increases, which in turn has an impact on salaries. Are there any technical solutions to this issue? Does Zhejiang Zhongkong’s ECS700 system offer any good solutions?
For Zhejiang Zhongkong’s ECS700 system, in the case of numerous communication alarms caused by devices being offline, the following solutions can be considered: 1. **Improve communication stability**: Check and enhance the stability of the Modbus communication link, including examining the physical connections, 485 communication parameters, and the communication settings of the devices, to ensure that the communication link remains as stable as possible. 2. **Set communication delay alarm**: In the ECS700 system, this can be achieved by adjusting the tolerance time for device communication failures. For example, it can be set to trigger an alarm only after the device has failed to communicate continuously for a certain period of time (such as 15 minutes). This can effectively prevent a large number of alerts caused by brief communication failures. 3. **Hierarchical alarm management**: Treat communication errors differently from process control errors; for example, the alarm levels can be adjusted so that communication failure alarms do not interfere with critical process control alarms. In this way, although communication failures are recorded, they do not have a significant impact on monthly performance. 4. **Regular Maintenance and Inspection**: Conduct regular maintenance and inspections of systems and equipment, especially communication devices and related connections, to prevent frequent disconnections caused by equipment aging or failures. 5. **Software upgrades and optimizations**: Consult Zhejiang Zhongkong’s technical support team to find out whether any software upgrades or patches can help resolve such issues, or whether customized software functions can be provided to address this situation specifically. 6. **User Training and Standardized Operations**: Ensure that operators know how to handle temporary disruptions in device communication, and are able to quickly identify and resolve issues, thereby reducing the occurrence of false alarms. Through these comprehensive measures, the number of alerts caused by equipment communication issues can be effectively reduced, thereby helping to improve monthly performance metrics and the associated wage impacts. .
It’s not about paying money; instead, the company uses the number of alarms as a criterion for evaluating salary, similar to the uptime rate. For example, if the equipment’s uptime rate is above 98% in a month, the coefficient for this salary evaluation is 1.0. If it’s lower than that, the coefficient might be 0.8 or 0.7, which means the salary will be lower
Use as many RS485 serial ports as possible to spread these devices out, thereby preventing a failure in any single device from affecting the overall polling time or even causing a system failure. Alternatively, use a gateway to read the data first (which also allows checking the quality of communication with the serial device), and then transfer it to the DCS.
It’s fully shielded; as long as there’s no alarm, that’s fine
If the RTO ignition PLC doesn’t shut down, how can an ERR error be triggered? You’re referring to parameter alarms, right? It is recommended to adjust the alarm thresholds, and such adjustments should only be made for critical process parameters.
This post was last edited by mutianly on 2024-7-31 08:13. The issue you’re facing is mainly due to unstable communication; check the RTO’s communication devices, the communication cables, as well as the power supply and transmission distance of the communication cards. Also, verify whether the communication lines are dedicated for this purpose. I’ve also encountered situations where using ordinary twisted-pair cables in place of 485 communication cables can lead to communication disruptions, or even damage to the communication cards. There are generally no major issues with the central control interface. Do communication devices have a resume transmission function? In general, communication allows the values to be retained after an interruption, and such value retention usually does not trigger any alarms. Check it step by step; the main issue to address is the communication interruption.
Keep the data. If the auxiliary equipment is a CPU, it doesn’t matter if the communication is lost; but if it’s an S7-200SMART with programs programmed inside it, automatic control can be achieved. However, you won’t be able to issue new commands, nor will you be able to see its current status. Monitor the communication status; it can alert you if communication fails, and trigger an alarm after a certain period of time has passed. For the communication cables, it’s better to choose Siemens’ purple PROFIBUS cables, as they have excellent interference resistance. Of course, it could also be a problem with the PLC of the auxiliary equipment. Also, have you set the scanning cycle to be too short? You can completely change the cycle to 5 seconds.
Changing the fault alarm level to log mode will prevent errors from being reported