Diskussion zu den Details des Kommunikationsverlusts zwischen PLC und Oberrechner
Thread Content
Die Scannzeit eines herkömmlichen PLCs ist in der Regel sehr kurz und liegt im Bereich von Millisekunden (in der Regel 10–100 ms). Die Zeit, die das Obersteuergerät benötigt, um Daten zu erfassen, liegt hingegen im Bereich von Sekunden (in der Regel 0,5 s oder 1 s). Wenn also ein Schalter für 20 ms eingeschaltet ist, könnte das dazu führen, dass der Oberrechner das Signal nicht erfassen kann. Aber hat der PLC bereits die entsprechende Logik ausgeführt?
Dieser Beitrag wurde zuletzt von budaoweng123 am 30.9.2015 um 14:22 geändert. Ha ha, was bringt es schon, wenn man etwas sammelt? Wenn die Logik funktioniert, klappt es.
Das ist nicht richtig. Da es sich um eine Kommunikation handelt, betrifft das DCS nicht nur dieses Problem. Wenn beispielsweise die 485-Kommunikation sowie das MODBUS-Protokoll verwendet werden und die Baudrate richtig eingestellt ist, dann gibt es, solange sowohl der PLC als auch das DCS von guter Qualität und Leistung sind, kaum Probleme mit dem Verlust von Daten. Was der Threadersteller mit der PLC-Datenübertragung in Millisekunden meint, hat keinen notwendigen Zusammenhang mit der Kommunikation. Außerdem interpretiert das DCS ein Schaltersignal, das 20 Millisekunden lang aktiv ist, in der Regel als Fehlfunktion des Schalters. Warum sollte das DCS sonst in der Regel eine Verzögerung einbauen?
Ich meine PLC+HMI, nicht DCS. Ich habe zuvor ein Experiment durchgeführt, bei dem ein Punkt schnell eingeschaltet und ausgeschaltet wurde – die HMI kann jedoch nicht alle Schaltvorgänge aufzeichnen.
Es scheint, dass in solchen Fällen tatsächlich Aktionen vor Ort stattfinden, doch der Überwachungsrechner gibt keinen Alarm aus. Erst nach 1 Sekunde oder einigen Sekunden zeigt der Überwachungsrechner an, dass alles wieder in Ordnung ist~~
Ob es normal funktioniert, weiß ich nicht. Jedenfalls stimmten bei meinen Experimenten die Anzahl der schnellen Bewegungen nicht mit der Anzahl der ausgelösten Alarmsignale überein. Außerdem zeigte sich dieses Problem auch bei einer tatsächlichen Parkung. Einmal stellte sich heraus, dass eine Maschine ohne ersichtlichen Grund zum Stillstand kam. Es wurde festgestellt, dass der Notstopp-Knopf locker war – doch auf dem Touchscreen wurde keine Meldung dazu angezeigt.
Das ist also auch ein Nachteil des PLC: Die Alarme werden auf der Ebene der HMI erkannt und ausgelöst； DCS hingegen wird auf CPU-Ebene ausgelöst.
Für Systeme mit geringen Sicherheitsanforderungen werden herkömmliche Steuerungssoftware verwendet, für solche mit hohen Anforderungen Software von großen ausländischen Herstellern. Für fortgeschrittene Kompressoranlagen werden komplette PLC-Systeme in Kombination mit Steuerungssoftware eingesetzt. Auch das hängt vom Programmierniveau ab; wenn die Software keine MS-Niveau-Alarmprotokolle erzeugen kann, kann eine Verzögerungsausgabe am PLC hinzugefügt werden. . .
Solche Alarmsignale sollten doch alle eine RS-Halt- und Reset-Funktion haben, oder? Mit der RS-Unterstützung wird die HMI sicherlich darauf reagieren
Diese Situation ist bereits aufgetreten: Der externe Schalter aktiviert sich plötzlich. Man kann die Logikabläufe des PLC erkennen (in den Projektdateien offline), doch im Alarmbildschirm erscheint kein entsprechender Alarm.
Alle Flaggen, die eine Interlocks-Aktivierung auslösen, müssen als Haltezeichen sein :)
Aber es gibt einige Hersteller, die das nicht tun.