Discussion on the details of communication loss between the PLC and the host computer
Thread Content
Generally, the scanning time of PLCs is very short, usually in the range of milliseconds (typically 10–100 ms), whereas the time required by the host computer to collect data is generally in the seconds range (usually 0.5 s or 1 s). So, if a switch remains on for 20ms, will that prevent the host computer from detecting that signal? But has the PLC already executed the corresponding logic?
This post was last edited by budaoweng123 on 2015-9-30 at 14:22. Hehe, what’s the point of collecting them if that’s the case? Logic works, and that’s that.
This statement is incorrect. Since it’s a communication link, the issue doesn’t solely relate to the DCS; for example, by using 485 communication, the MODBUS protocol, and proper settings for the baud rate, as long as both the PLC and the DCS are of good quality and perform well, there should be little risk of data loss. The PLC data acquisition, as mentioned by the poster, occurs on a millisecond scale, and this isn’t necessarily related to communication. Moreover, when a switch signal remains on for 20 milliseconds, the DCS tends to consider it as an incorrect switch operation; otherwise, why would the DCS need to introduce a delay?
I’m talking about PLC+HMI, not DCS. I previously conducted an experiment in which I quickly turned a switch on and off, and the HMI was unable to record all of these on/off actions.
It seems that in this situation, the actual actions take place on-site, but the upper-level controller does not trigger any alarm; however, after 1 second or a few seconds, the upper-level controller shows that everything is functioning normally~~
I don’t know if it will work properly. Anyway, when I was conducting the experiment, the number of times I made quick movements did not match the number of times an alarm was triggered in the end. Moreover, this issue was also reflected in a real parking scenario. Once, a machine stopped operating without any apparent reason; it was later found that the emergency stop button was loose, but the touchscreen did not display any alert regarding this issue.
So, this can also be considered a drawback of PLCs: their alarms are detected and triggered at the HMI level； Meanwhile, DCS is detected and triggered at the CPU level.
Systems with low safety requirements use ordinary host computer software, while those with higher requirements employ host computer software from foreign manufacturers; more advanced compression units are equipped with complete sets of PLCs and host computers. This also depends on the programming skill level; if the software cannot provide MS-level alarm logging, a delay output can be added to the PLC. . .
Shouldn’t alarm signals like this have RS hold and reset functions? With RS retention, the HMI will definitely reflect it
I have encountered this situation before: when an external digital switch acts suddenly, it is possible to see the PLC’s logical response (in the engineering files offline), but no corresponding alarm appears on the operation alarm screen.
All flag bits that trigger interlocks must be hold signals :)