Search the Community

Wenn Sie eine PLC-Logik entwerfen, müssen Sie auf die Namen achten, die Sie den Tags geben. Sie sollten für jeden Programmierer leicht verständlich und interpretierbar sein. Sie sollten weder zu lang noch zu kurz sein. Die Benennungskonvention ist wichtig, da falsches Tagging Programmierern bei der Fehlerbehebung Probleme bereiten kann. Außerdem wird durch die Vergabe langer Namen der Speicher der PLC belegt. Daher muss jeder Programmierer vor dem Schreiben eines PLC-Programms die richtigen Benennungskonventionen befolgen. In diesem Beitrag werden wir uns mit dem Konzept der Benennungskonventionen für PLC-Tags befassen. Benennungskonventionen für PLC-Tags Lassen Sie uns zunächst verstehen, welche große Rolle die Benennungskonvention für Tags bei der PLC-Programmierung spielt. Sie haben einen Motor mit seinem Laufbefehl und seiner Laufrückmeldung als PLC-IOs. Der Motor befindet sich im Gebläseraum und wird als Luftkompressor verwendet. Der Motor-Tag-Name im P&ID ist M-101. Für einen PLC-Programmierer ist es nun wichtig, einen Tag-Standort zu identifizieren. Es gibt also zwei Arten von Denkweisen, die normalerweise einen SPS-Programmierer definieren. Der erste versucht, so viele Informationen wie möglich in einem Tag-Namen zu geben; er kann also den Motorlaufbefehl als M101_Compressor_Run_Command bezeichnen. Der zweite versucht, den Namen als Q_M101_Comp zu vergeben. Die zweite Denkweise sieht sehr klar aus, da er kurze Namen vergibt und die Länge so gering wie möglich hält. Aus diesem Grund ist die Benennung eines SPS-Tags wichtig, da es den Programmierer davon entlastet, solche langen Tags in Situationen zu lesen, in denen eine dringende Fehlerbehebung erforderlich ist. (Es ist zu beachten, dass bei der Benennung von SPS-Tags außer dem Unterstrich (_) keine Sonderzeichen zulässig sind.) Ein SPS-Tag-Name sollte Informationen enthalten, die dem Programmierer helfen können, seine Bedeutung zu verstehen. Dies impliziert im Allgemeinen die folgenden Informationen: Datentyp (z. B. Boolesch, Ganzzahl), Datenfluss (z. B. Eingabe, Ausgabe), Bereich (z. B. lokal, global), Instrumenten- oder Gerätetyp (z. B. Motor, Ventil, Sensor), Prozessparameter (z. B. Druck, Durchfluss, Temperatur) und Standort des Geräts. Tag-Namensstile Es gibt verschiedene Stile gemäß IEC-Standards, die für eine korrekte Benennung befolgt werden müssen. Sehen wir uns einige der am häufigsten verwendeten an: Camel-Stil, Pascal-Stil, Snake-Stil, Präfix mit Datentyp-Stil Camel-Stil In diesem Stil gibt es keinen Unterstrich dazwischen. Dem gesamten Wort wird ein vollständiger Name gegeben, aber jedes Wort darin beginnt mit einem Großbuchstaben. Nehmen Sie beispielsweise das oben besprochene Beispiel. M101_Compressor_Run_Command wird als m101CompressorRunCommand geschrieben. Sie können jedes Wort an einem Großbuchstaben erkennen. Der erste Buchstabe ist ein obligatorischer Kleinbuchstabe. Dieser Stil sieht gut aus, wenn das Wort klein ist. Er verhindert die Verwendung von Unterstrichen und verringert den Speicherverbrauch. Pascal-Stil Er ähnelt dem Camel-Stil; der einzige Unterschied besteht darin, dass der erste Buchstabe ein obligatorischer Großbuchstabe ist. Unser Tag wird beispielsweise als M101CompressorRunCommand geschrieben. Snake-Stil Das Beispiel, das wir zuvor besprochen haben, ist der Snake-Stil. Hier wird jedes Wort durch einen Unterstrich getrennt. Präfix mit Datentyp-Stil Hier wird dem Tag der Datentyp des Tag-Namens vorangestellt. In unserem Fall war der Tag-Typ Boolean. Gemäß IEC-Standards wird einem Boolean-Tag normalerweise das Präfix „x“ zugewiesen. Unser Stil wird also als xM101CompressorRunCommand geschrieben. Dies hilft dem Programmierer zu erkennen, welcher Datentyp für diesen bestimmten Tag verwendet wird. Tipps zur Tag-Benennung bei der SPS-Programmierung Die erste und wichtigste Regel ist, dass die Länge eines Tags kurz sein sollte, aber nicht so kurz, dass niemand es verstehen kann. Wie besprochen, sollte die Länge geeignete Informationen in angemessener Länge enthalten. Lange Namen sollten strikt vermieden werden. Befolgen Sie die allgemeinen Tag-Benennungsstile, die besprochen wurden. Diese entsprechen den IEC-Standards und lassen die Logik ordentlich und sauber aussehen. Um Fehler bei der Tag-Erstellung zu reduzieren, verwenden Sie Excel-Dateien. Excel reduziert den Arbeitsaufwand enorm, da Duplizierung und Kopieren sehr einfach werden. In Excel-Dateien treten kaum Fehler auf. Es ist nicht immer notwendig, einen vollständigen Namen für ein Wort zu verwenden. Beispielsweise kann das Ventil als vlv und die Temperatur als temp geschrieben werden. Vermeiden Sie es, das Tag vollständig in Großbuchstaben zu schreiben. Das sieht umständlich und unleserlich aus.

JSR-, SBR- und RET-Anweisungen werden verwendet, um den Controller anzuweisen, eine separate Unterprogrammdatei innerhalb des Kontaktplanprogramms auszuführen und zur Anweisung nach der JSR-Anweisung zurückzukehren. Allen Bradley SPS-Unterprogramme Die SBR-Anweisung muss die erste Anweisung auf der ersten Sprosse in der Programmdatei sein, die das Unterprogramm enthält. Verwenden Sie ein Unterprogramm, um wiederkehrende Abschnitte der Programmlogik zu speichern, die von mehreren Punkten innerhalb Ihres Anwendungsprogramms aus ausgeführt werden müssen. Ein Unterprogramm spart Speicher, da Sie es nur einmal programmieren. Aktualisieren Sie kritische E/A innerhalb von Unterprogrammen mithilfe von Anweisungen für die sofortige Eingabe und/oder Ausgabe (IIM, IOM), insbesondere wenn Ihre Anwendung verschachtelte oder relativ lange Unterprogramme erfordert. Andernfalls aktualisiert der Controller die E/A erst, wenn er das Ende des Hauptprogramms erreicht (nach Ausführung aller Unterprogramme). Innerhalb eines Unterprogramms gesteuerte Ausgänge bleiben in ihrem letzten Zustand, bis das Unterprogramm erneut ausgeführt wird. Wenn der JSR-Befehl ausgeführt wird, springt der Controller zum Unterprogrammbefehl (SBR) am Anfang der Zielunterprogrammdatei und setzt die Ausführung an diesem Punkt fort. Sie können in keinen anderen Teil eines Unterprogramms springen als in den ersten Befehl in dieser Datei. Das Zielunterprogramm wird durch die Dateinummer identifiziert, die Sie im JSR-Befehl eingegeben haben. Der SBR-Befehl dient als Bezeichnung oder Kennung für eine Programmdatei als reguläre Unterprogrammdatei. Der Befehl muss als erster Befehl des ersten Sprosses eines Unterprogramms programmiert werden. Der RET-Befehl markiert das Ende der Unterprogrammausführung oder das Ende der Unterprogrammdatei. Der Sprosse, der den RET-Befehl enthält, kann bedingt sein, wenn dieser Sprosse dem Ende des Unterprogramms vorangeht. Auf diese Weise lässt der Controller den Rest eines Unterprogramms nur aus, wenn seine Sprossebedingung erfüllt ist.

In den letzten Artikeln haben wir besprochen, wie man mithilfe der TCON- und TDISCON-Blöcke eine Verbindung zwischen zwei SPS herstellt und wie man mithilfe der TSEND- und TRCV-Blöcke Daten zwischen ihnen verschiebt. Datenübertragung zwischen SPS-Systemen In diesem Artikel lernen wir eine neue Anweisung kennen, die zur Kommunikation und Datenübertragung zwischen SPS-Systemen mithilfe der TSEND_C- und TRCV_C-Blöcke verwendet werden kann. TSEND_C Die Anweisung TSEND_C ist eine TIA-Portal-Anweisung, die zum Einrichten und Herstellen einer Verbindung zwischen zwei SPS verwendet wird. Sobald die Verbindung eingerichtet und hergestellt wurde, wird sie automatisch von der SPS aufrechterhalten und überwacht. Die Anweisung TSEND_C wird asynchron ausgeführt und hat die folgenden Funktionen: Einrichten und Herstellen einer Kommunikationsverbindung ähnlich dem TCON-Block. Senden von Daten über eine bestehende Kommunikationsverbindung ähnlich dem TSEND-Block. Beenden oder Zurücksetzen der Kommunikationsverbindung ähnlich dem TDISCON. Daher wird TSEND_C als kompakt bezeichnet, da es gleichzeitig als mehr als 3 Blöcke fungiert. TRCV_C Der TRCV_C-Befehl ist ebenfalls ein TIA-Portal-Befehl, der zum Einrichten und Herstellen einer Verbindung zwischen zwei SPSen verwendet wird. Sobald die Verbindung eingerichtet und hergestellt wurde, wird sie automatisch von der SPS aufrechterhalten und überwacht. Der Befehl „TRCV_C“ wird asynchron ausgeführt und implementiert nacheinander die folgenden Funktionen: Einrichten und Herstellen einer Kommunikationsverbindung ähnlich wie TCON. Empfangen von Daten über eine bestehende Kommunikationsverbindung ähnlich wie TRCV. Beenden oder Zurücksetzen der Kommunikationsverbindung ähnlich wie TDISCON. Daher wird TRCV_C als kompakt bezeichnet, da es gleichzeitig als mehr als 3 Blöcke fungiert. Verwendung von TSEND_C und TRCV_C in unserem SPS-Projekt Im letzten Artikel mussten wir, als wir Daten von SPS_1 an SPS_2 senden und senden mussten, in jeder SPS drei verschiedene Blöcke verwenden. Siehe Bild 1. Bild 1. Logik in PLC_1 Wie Sie sehen, haben wir die TCON- und TDISCON-Blöcke verwendet, um die Verbindung herzustellen und zurückzusetzen, und wir haben TSEND verwendet, um die Daten von PLC_1 zu senden. Und dasselbe wurde für PLC_2 getan. Siehe Bild 2. Bild 2. Logik von PLC_2 Auch hier haben wir die TCON- und TDISCON-Blöcke verwendet, um die Verbindung herzustellen und zurückzusetzen, und wir haben TRCV verwendet, um die Daten von PLC_1 zu empfangen. Nun möchten wir alle diese Blöcke ersetzen und versuchen, stattdessen TSEND_C und TRCV_C zu verwenden, um dieselbe Funktionalität zu erreichen. Zuerst verwenden wir in PLC_1, wo wir Daten senden müssen, den TSEND_C-Block. Ziehen Sie den Block einfach per Drag & Drop in den Haupt-OB1. Siehe Bild 3. Bild 3. TSEND_C-Block hinzufügen. Da TSEND_C im Wesentlichen ein Funktionsblock ist, werden Sie aufgefordert, eine Dateninstanz zu erstellen. Siehe Bild 4. Bild 4. Eine Instanz für TSEND_C erstellen TSEND_C ähnelt dem TSEND-Block insofern, als dass Sie einige Konfigurationen vornehmen und einige Signale hinzufügen müssen. Siehe Bild 5. Bild 5. TSEND_C-Block Jetzt benötigen wir ein Signal für REQ und Daten zum Senden und auch zum Konfigurieren der Verbindung. Für das REQ-Signal haben wir ein SendData-Tag erstellt. Außerdem können wir den Datenblock, den wir im letzten Artikel erstellt haben und den wir an PLC_2 senden müssen, einfach per Drag & Drop auf den DATA-Eingang des Blocks ziehen. Siehe Bild 6. Bild 6. Konfiguration des TSEND_C-Blocks. Um die Verbindungsparameter für den Block zu konfigurieren, können wir auf das kleine Konfigurationssymbol oben auf dem Block drücken, um die Konfigurationsansicht zu öffnen. Die Konfigurationsansicht sieht der des TCON-Blocks sehr ähnlich. Siehe Bild 7. Bild 7. Verbindungsparameter von TSEND_C Wir haben bereits in früheren Artikeln gezeigt, wie die Verbindungsparameter konfiguriert werden, also können wir einfach dasselbe tun wie beim TCON-Block, siehe Bild 8. Bild 8. Konfiguration der Verbindungsparameter Mit dieser Verbindungskonfiguration haben wir alle Konfigurationen des TSEND_C abgeschlossen. Beachten Sie, wie viel schneller das im Vergleich zur Konfiguration der TCON-, TDISCON- und TSEND-Blöcke ging. Jetzt müssen wir TRCV_C zu PLC_2 hinzufügen, damit es die von PLC_1 gesendeten Daten empfangen kann. Ziehen Sie im Haupt-OB1 von PLC_1 einfach TRCV_C per Drag & Drop in Ihre Logik. Siehe Abbildung 9. Denken Sie daran, eine Dateninstanz für den TRCV_C-Block zu erstellen. Abbildung 9. TRCV_C hinzufügen Sobald TRCV_C zu Ihrer Logik hinzugefügt wurde, müssen wir es konfigurieren. Wie bei TSEND_C müssen wir ein Signal hinzufügen, um den Datenempfang zu aktivieren, und wir müssen auch den Datenblock hinzufügen, in dem wir die Daten speichern werden. Siehe Abbildung 10. Abbildung 10.TRCV_C Wir haben ein RecieveData-Tag als EN_R-Signal definiert. Siehe Bild 11. Bild 11. EN_R-Tag definieren Denken Sie daran, die Option „optimierter Blockzugriff“ des Datenblocks zu deaktivieren, sonst funktioniert der Block nicht, wie wir in den letzten Artikeln gezeigt haben. Als nächstes müssen wir die Verbindungsparameter des TRCV_C-Blocks konfigurieren, wie wir es mit dem TSEND_C getan haben. Denken Sie nur daran, dass die nicht angegebene Partner-SPS jetzt die PLC_1 ist, siehe Bild 12. Bild 12. Verbindungsparameter von TRCV_C SPS-Projektsimulation Nachdem wir nun den TSEND_C- und TRCV_C-Block konfiguriert haben, möchten wir unser Projekt simulieren und sehen, wie sie funktionieren. Zuerst erstellen wir jedoch eine einfache Logik, um die Daten von PLC_1 automatisch zu aktualisieren, die an PLC_2 gesendet werden. Siehe Bild 13. Bild 13. Einfache Logik zum automatischen Aktualisieren von Daten. Lassen Sie uns nun eine Simulation für unser Projekt kompilieren und starten. Das Erste, was Sie bemerken werden, ist, dass PLC_1 und PLC_2 sofort versuchen, eine Verbindung herzustellen, da wir TSEND_C und TRCV_C eingerichtet haben. Sie versuchen automatisch, eine Verbindung herzustellen. Deshalb wird eine Verbindung zwischen den beiden SPSen hergestellt. Siehe Abbildung 14. Abbildung 14. Die Verbindung wird direkt hergestellt. Wie Sie sehen, wird die Verbindung zwischen den SPSen direkt hergestellt, da der Parameter CONT in TSEND_C und TRCV_C auf TRUE gesetzt ist, was bedeutet, dass der Block automatisch versucht, eine Verbindung mit der Partner-SPS herzustellen. Wir können hier jedes Steuersignal einfügen, um den Verbindungsaufbau zu steuern. Außerdem können Sie sehen, dass REQ von TSEND_C und EN_R von TRCV_C auf FALSE gesetzt sind, weshalb keine Daten zwischen den SPSen übertragen werden. Siehe Abbildung 15. Abbildung 15. Keine Datenübertragung zwischen den SPSen. Wenn das REQ-Signal von TSEND_C auf true gesetzt ist, versucht PLC_1, die Daten zu senden, wartet aber darauf, dass die andere PLC den Datenempfang freigibt, siehe Bild 16. Bild 16. REQ ist true. Wie Sie sehen, ist SendData TRUE, aber es wurden keine Daten gesendet, da RecieveData immer noch false ist. PLC_2 empfängt nur dann Daten von PLC_1, wenn ReceiveData auf true gesetzt ist. Siehe Bild 17. Bild 17. Daten werden an PLC_2 gesendet Wie Sie sehen, werden Daten von PLC_1 an PLC_2 gesendet, wenn RecieveData true ist. Sie können jedoch sehen, dass die Daten in den beiden PLCs unterschiedlich sind, da sich die Daten von PLC_1 automatisch gemäß der einfachen Logik ändern, die wir zuvor erstellt haben. Das bedeutet, dass das Signal EN_R die Datenübertragung einmal zulässt. Wenn ich erneut Daten übertragen muss, muss dieses Signal erst falsch und dann wieder wahr werden. Sehen Sie sich das beigefügte TIA Portal-Projekt an und sehen Sie sich die Datenübertragung zwischen SPSen an.

Erstellen Sie ein SPS-Programm für automatische Flüssigkeitsmischanwendungen mithilfe der Kontaktplanlogik-Programmierung. Lernen Sie den Mischprozess mithilfe eines SPS-Kontaktplandiagramms kennen. Flüssigkeitsmischanwendung Problembeschreibung In vielen Branchen werden viele Mischsysteme zum Mischen von Lösungen verwendet. Einige Anlagen verwenden Vollautomatik oder Halbautomatik. Ein manuelles System hat viele Nachteile, wie z. B. mangelnde Genauigkeit, Zeitverzögerungsprobleme, Flüssigkeitsverlust, Zeitaufwand usw. Hier diskutieren wir die halbautomatische Anwendung eines Mischsystems. Diagramm Problemlösung Für dieses Beispiel verwenden wir SPS-Programmierung und dafür eine Siemens S7-1200 SPS. Zur einfachen Erklärung können wir ein einfaches Beispiel eines Mischsystems wie oben gezeigt betrachten. In dieser Anwendung kann der Bediener mithilfe der Schalter S1 und S2 eine reine, unvermischte Lösung herstellen. Und der Bediener kann mithilfe des Schalters S3 eine gemischte Lösung oder ein gemischtes Material herstellen. Der Bediener beobachtet den Füllstand des Tanks und kann die Flüssigkeit im Tank durch Betätigen des Ventils V5 ablassen. Außerdem läuft der Rührmotor M, während der Tank gefüllt wird. Wir werden ein Verriegelungssystem bereitstellen, damit der Bediener nicht beide Schalter gleichzeitig betätigen kann. V1, V3 und V5 sind manuelle Ventile, die nicht mit der SPS verbunden sind. V2 und V4 sind elektronisch betriebene Ventile, die von der SPS gesteuert werden können. Liste der SPS-Ein- und Ausgänge Digitale Eingänge Es gibt drei Schalter S1, S2 und S3 S1: I0.0 S2: I0.1 S3: I0.3 Digitale Ausgänge Wir haben zwei Ventile, V2 und V4. ein Rührmotor M1 V2: Q0.0 V4: Q0.1 M1: Q0.2 SPS-Kontaktplan für automatische Flüssigkeitsmischanwendung SPS-Programm erklärt Für diese Anwendung haben wir S7-1200 PLC und TIA-Portalsoftware zur Programmierung verwendet. In Netzwerk 1 haben wir den Schließerkontakt von S1 (I0.0) und den Öffnerkontakt von S2 (I0.1) und S3 (I0.2) in Reihe geschaltet. Durch Aktivieren des Schalters S1 kann der Bediener das Ventil V2 für Lösung 1 (Flüssigkeit 1) STARTEN. In Netzwerk 2 haben wir den Schließerkontakt von S2 (I0.1) und den Öffnerkontakt von S1 (I0.0) und S3 (I0.2) in Reihe geschaltet. Durch Aktivieren des Schalters S2 (I0.1) kann der Bediener das Ventil V4 (Q0.1) für Lösung 2 (Flüssigkeit 2) STARTEN. Für beide Netzwerke 1 und 2 haben wir eine Parallelschaltung gewählt, den Schließerkontakt von S3 (I0.2) und in Reihe mit dem Öffnerkontakt von S1 (I0.0) und S2 (I0.1). Aufgrund der obigen Parallelschaltung kann der Bediener beide Ventile durch Aktivieren des Schalters S3 (I0.2) für die Mischlösung (Flüssigkeit 1 und Flüssigkeit 2) betätigen. Unter unseren Bedingungen sollte der Rührer M1 (Q0.2) automatisch aktiviert werden, während der Tank gefüllt wird. Daher haben wir den Schließerkontakt von V2 (Q0.1) und parallel den Schließerkontakt von V4 (Q0.1) gewählt, sodass der Rührer automatisch durch Betätigen eines beliebigen Schalters aktiviert wird. Laufzeittestfälle Hinweis: Die obige SPS-Logik bietet eine grundlegende Vorstellung von der Anwendung von SPS in Flüssigkeitsmischanwendungen. Die Logik ist begrenzt und stellt keine vollständige Anwendung dar.

SPS-Programmier-Tutorials für SPS-Förderbandmotor-Leiterlogik oder Förderbandsteuerung mit einer speicherprogrammierbaren Steuerung (SPS). SPS-Förderbandmotor-Leiterlogik Ziel: Die sequenziellen Aufgaben sind wie folgt: Wenn die START-Taste gedrückt wird, wird der Motor gestartet. Die Anzeigelampe RUN (grüne Lampe) wird aktiviert. Der Motor läuft, sodass die Kiste sich zu bewegen beginnt. Der Näherungssensor erkennt, wenn die Kiste am anderen Ende ankommt. Der Motor wird gestoppt. Die Anzeigelampe RUN (grüne Lampe) wird deaktiviert. Die Anzeigelampe STOP (rote Lampe) wird aktiviert. Ein Not-Aus-Druckknopf wird verwendet, um den Motor jederzeit zu stoppen. Relaisschema R: STOP-Anzeigelampe, G: RUN-Anzeigelampe, M: Motor, OL: Überlastrelais (Motorschutzrelais), LS1: Näherungsschalter, PB1: Start-Druckknopf, PB2: Not-Aus-Druckknopf, CR: Auftragnehmerrelais Betriebssequenz Startknopf ist betätigt. CR1-1 schließt, um CR1 einzuschließen oder den Startbefehl zu verriegeln CR1-2 öffnet und schaltet die rote Stopp-Kontrollleuchte aus CR1-3 schließt und schaltet die grüne Betriebs-Kontrollleuchte ein CR1-4 schließt, um den Motorstarter und den Motor mit Strom zu versorgen Die Kiste/das Paket bewegt sich und der Näherungsschalter (LS1) erkennt die Kiste, wenn sie die Spule CR1 erreicht hat, und schaltet sie ab CR1-1 öffnet, um den Einschließkontakt zu öffnen (nicht verriegelter Startbefehl) CR1-2 schließt und schaltet die rote Kontrollleuchte ein CR1-3 öffnet und schaltet die grüne Kontrollleuchte aus CR1-4 öffnet, um die Starterspule abzuschalten, den Motor anzuhalten und die Sequenz zu beenden SPS-Kontaktplanlogik

Modbus-Kommunikation von Delta PLC (DVP 14SS2) mit Delta VFD (VFD-L-Serie). Der Motor wird direkt von HMI (DOP-107CV) über Modbus-Kommunikation gesteuert. Delta PLC und VFD Modbus-Kommunikation Der Induktionsmotor wird zusammen mit seiner Drehzahlregelung direkt von HMI gesteuert. Die Drehzahlregelung erfolgt so, dass es in HMI zwei Schaltflächen gibt, die die Drehzahl des Motors in Schritten von einem Hertz (angenommen) erhöhen und verringern. Es gibt einen Delta-AC-Antrieb der VFD-L-Serie, der den Motor basierend auf den von der SPS empfangenen Befehlen steuert. Zunächst müssen im Antrieb Kommunikations- und andere Parameter eingestellt werden, die alle seine Konfigurationen mit der SPS abgleichen, wie Baudrate, Parität, Kommunikationsmodus usw.; mit Ausnahme der Slave-ID (Stationsadresse), die sich von der SPS-Stationsadresse unterscheiden muss. Standardmäßig ist die SPS-Stationsadresse gleich eins (1). Dies bedeutet, dass die Stationsadresse des Laufwerks irgendetwas in seinem definierten Bereich außer eins (1) sein muss. Die detaillierten Parameter, die für den Kommunikationsmodus eingestellt werden müssen, sind wie folgt: 2-00 = 4 2-01 = 4 Kommunikationsparameter Wir müssen die Kommunikationsparameter gemäß der obigen Tabelle einstellen. (aus dem Handbuch entnommen). 9-00 = 2 (kann auf alles außer 1 eingestellt werden) 9-01 = 1 9-04 = 7 (RTU-Modus, Stoppbits gleich 1 & Parität auf gerade) DVP 14SS2 hat zwei Kommunikationsanschlüsse, nämlich RS232 und RS485 separat. Nun müssen die Einstellungen für Kommunikationsanschluss 2 gemäß den eingestellten Parametern des VFD vorgenommen werden, die wie folgt lauten. Öffnen Sie die WPL-Software. (Delta PLC Software) Klicken Sie auf der Programmierseite auf das Symbol des Kommunikationsprogramms. Wählen Sie COM2 und drücken Sie auf Weiter. Stellen Sie die Parameter entsprechend den Kommunikationsparametern des VFD-Antriebs ein und klicken Sie auf Weiter. Hier werden sie entsprechend den im VFD-L-Tauchgang eingestellten Parametern eingespeist. Die Stationsadresse der SPS ist 1 (siehe linke untere Ecke) Markieren Sie das Hervorgehobene und drücken Sie auf Weiter. Sie können die Kästchen unten ankreuzen und die Bedingungen schreiben. Hier überspringen wir dieses Fenster und schreiben stattdessen die Logik direkt im Leiterdiagrammmodus. Klicken Sie auf Fertig stellen. Jetzt wird die folgende Leiterlogik als Ergebnis der oben eingestellten Bedingungen generiert. Die Leiter in Sprosse 2 wird jedes Mal ausgeführt, wenn eine gesendete Anfrage empfangen wird. Die Leiter in Sprosse 3 wird jedes Mal ausgeführt, nachdem Daten vom Laufwerk gelesen oder auf das Laufwerk geschrieben wurden. Bevor wir nun fortfahren, wird die Logik zum Starten und Stoppen des Motors und seiner Drehzahlregelung geschrieben. Wir müssen die Modbus-Adressen des Laufwerks herausfinden, über das dies ausgeführt wird. Für die VFD-L-Serie ist 2000H die Modbus-Adresse zum Starten und Stoppen des Laufwerks und 2001H für die Frequenzänderung. Hier steht H für Hexadezimal. In diesem Thema verwenden wir das Dezimalformat für die jeweilige Adresse. Daher muss Hexadezimal in Dezimalformat geändert werden. Durch den 8421-Code würden wir wie folgt konvertieren: 2000 (Hex) = 8192 (Dez) 2001 (Hex) = 8193 (Dez) Anstelle von 200H und 2001H werden also 8192K und 8193K verwendet. Stellen Sie sicher, dass 8192 und 8193 nur die Modbus-Adressen sind. Wenn 8192K einen Wert von 10 hat, startet der Motor. Wenn 8192K einen Wert von 1 hat, stoppt der Motor. Wenn 8193K einen Wert von 5000 hat, läuft der Motor mit 50 Hz, was bedeutet, dass, wenn die Geschwindigkeit des Motors um 1 Hz erhöht werden muss, 100 zum vorhandenen Wert addiert werden müssen und umgekehrt. Erläuterung des SPS-Programms Nun gehen wir zu den Details des SPS-Programms. Das Sendeanforderungsbit M1122 wird jedes Mal gesetzt, wenn ein Befehl an VFD in Sprosse 5 gegeben wird. MODRW K2 K6 K8192 D70 K1 MODRW steht für Mod Read Write K2 steht für die Stationsadresse des VFD. K6/K3 steht für den Funktionscode, ob geschrieben oder gelesen werden soll. Hier steht k6 für Schreiben. K8192 steht für die Modbus-Adresse, an die Daten geschrieben werden. Daten in D70 werden in k8192 geschrieben. K1 ist die Datenlänge. 10 (dez) und 1 (dez) werden in D70 verschoben, wenn Start- und Stoppbefehle in den Sprossen 6 und 7 gegeben werden. Gleichzeitig findet die Datenübertragung statt, d. h. Daten in D70 werden in die 8192k-Adresse von VFD in Sprosse 8 geschrieben, um den Motor zu starten und zu stoppen. 100 (dez) wird zum Wert von D100 in Sprosse 10 addiert, um die Geschwindigkeit um 1 Hz zu erhöhen, wenn der Geschwindigkeitserhöhungsimpuls (M4) empfangen wird. 100 (dez) wird vom Wert von D100 in Sprosse 9 subtrahiert, um die Geschwindigkeit um 1 Hz zu verringern, wenn der Geschwindigkeitsverringerungsimpuls (M5) empfangen wird. Gleichzeitig findet die Datenübertragung statt, d. h. Daten in D100 werden an die 8193k-Adresse des VFD in Sprosse 11 geschrieben, um den Motor zu starten und zu stoppen. HMI Nun kommen wir zur HMI-Konfiguration. Nachdem Sie das HMI-Modell ausgewählt haben, legen Sie die folgende Konfiguration fest, da die SPS-zu-HMI-Konfiguration hier auf RS232 erfolgt. (Sie müssen sie gemäß dem HMI-Modell konfigurieren) Nehmen Sie vier Taster, weisen Sie die Adressen zu und gestalten Sie den HMI-Bildschirm wie folgt: Start = M0 Stopp = M1 Geschwindigkeit erhöhen = M4 Geschwindigkeit verringern = M5 Prozess testen Das HMI-Design wird in diesem Artikel nicht behandelt.

Die SPS-Dokumentation ist eine sehr wichtige technische Aufzeichnung der Prozesssteuerungsschritte, und wie bei allen technischen Beschreibungen sind genaue, detaillierte technische Aufzeichnungen unerlässlich. Ohne genaue Zeichnungen sind Änderungen und Modifikationen, die für Upgrades und Diagnosen erforderlich sind, äußerst schwierig oder unmöglich. SPS-Systemdokumentation Jedes Kabel von der SPS zur Überwachungs- und Steuerungsausrüstung muss an beiden Enden deutlich gekennzeichnet und nummeriert und im Schaltplan aufgezeichnet sein. Die SPS muss über vollständige, aktuelle Leiterdiagramme (oder eine andere zugelassene Sprache) verfügen, und jede Sprosse muss mit einer vollständigen Beschreibung ihrer Funktion gekennzeichnet sein. Die wesentlichen Dokumente in einem SPS-System sind: 1. Systemübersicht und vollständige Beschreibung des Steuerungsbetriebs; 2. Blockdiagramm der Einheiten im System; 3. Vollständige Liste aller Ein- und Ausgänge, Ziele und Nummern; 4. Schaltplan der E/A-Module, Adressidentifikation für jeden E/A-Punkt und Rack-Standorte; 5. Leiterdiagramm mit Sprossebeschreibung, Nummer und Funktion. Außerdem muss die Möglichkeit bestehen, das Kontaktplanprogramm offline auf einem PC oder im Hintergrundmodus in der SPS zu simulieren, damit Änderungen, Upgrades und Fehlersimulationen ohne Unterbrechung des normalen Betriebs der SPS durchgeführt werden können und die Auswirkungen von Änderungen und Upgrades vor ihrer Einbindung bewertet werden können.

Entwickeln Sie Beispiele für SPS-Programmierung zur industriellen Automatisierung gemäß der unten angegebenen Logik. Eine Säge, ein Lüfter und eine Ölpumpe werden eingeschaltet, wenn ein Startknopf gedrückt wird. Wenn die Säge weniger als 20 s in Betrieb war, sollte die Ölpumpe ausgeschaltet werden, wenn die Säge ausgeschaltet wird, und der Lüfter sollte nach dem Herunterfahren der Säge weitere 5 s laufen. Wenn die Säge länger als 20 s in Betrieb war, sollte der Lüfter eingeschaltet bleiben, bis er durch einen separaten Lüfter-Reset-Knopf zurückgesetzt wird, und die Ölpumpe sollte nach dem Ausschalten der Säge weitere 10 s laufen. Schreiben Sie ein SPS-Programm, das diesen Prozess implementiert. Beispiele für SPS-Programmierung Programmbeschreibung: Sprosse 0000: Start/Not-Aus PB mit Speicher B3:0/0 verriegelt. Sprosse 0001: B3:0/0 aktiviert, um Säge (O: 0/0), Lüfter (O: 0/1) und Ölpumpe (O:0/2) einzuschalten. Der normalerweise geschlossene Kontakt des Stoppschalters ist in Reihe mit dem Sägeausgang, um ihn auszuschalten. Der Lüfterrücksetzschalter und der Timer T4:0 sind angeschlossen, um den Lüfter auszuschalten, wenn die Bedingung erfüllt ist. Der Timer T4:2 hat ein Bit ausgeführt und das Speicherbit dient zum Ausschalten der Ölpumpe. Sprosse 0002: Wenn der Stopp gedrückt wird, muss der Lüfterausgang (O: 0/2) gemäß der in Punkt 2 genannten Logik nach 5 s ausgeschaltet werden. Der Komparatorblock beschränkt den Timer T4:0 auf das Laufen nach 20 s Sägebetrieb. Sprosse 0003: Der Timer T4:1 läuft, wenn der Start gedrückt wird. Wenn der Stopp zu irgendeinem Zeitpunkt nach 20 s gedrückt wird, wird der Sägeausgang ausgeschaltet. Nach 10 s wird die Ölpumpe ausgeschaltet. Dieser Vorgang wird von Timer T4:2 ausgeführt. Das Fertigbit von Timer T4:0 wird verwendet, um den Vorgang von Timer T4:1 einzuschränken, wenn T4:0 eingeschaltet ist. Sprosse 0004: Weniger als ein Komparatorblock wird verwendet, um die in Punkt 2 erwähnte Logik auszuführen, um den Lüfter auszuschalten, wenn der Sägeausgangsvorgang weniger als 20 s dauerte. Programmausgabe: Jetzt sehen wir die Simulation der obigen Leiterlogik für verschiedene Bedingungen, wie unten erwähnt. Wenn Start PB gedrückt wird Wenn der Stoppschalter vor 20 s gedrückt wird Wenn der Stoppschalter nach 20 s gedrückt wird Wenn der Lüfter-Reset-Schalter gedrückt wird Fazit: Wir können dieses Beispiel verwenden, um die Programmierlogik in Allen Bradley PLC zu verstehen.

In diesem Artikel geht es um die Methode zur Fehlerbehebung bei der SPS-Programmierung. In industriellen SPSen, in denen Tausende von Ein- und Ausgängen verwendet werden, hängt die Länge von SPS-Programmen von der Anwendung oder Anlagennutzung ab. Beheben von Problemen mit Siemens-SPS-Programmen Manchmal ändern Leute unwissentlich die Logikparameter, was zu einem Fehler führen kann. Aufgrund der Komplexität des Designs entstehen sogar einige Fehler während der Logikdesignphase. Die Siemens-SPS-Software verfügt über verschiedene praktische Tools zur Fehlerbehebung bei in den Programmen generierten Fehlern. Fehler können beispielsweise Überlappungen der Adressierung, mehrere gleiche Ausgabeinstanzen, Überlappungen von Speicherbitadressen, häufiges wiederholtes Arbeiten mit einem einzigen Programm usw. sein. Um solche Probleme zu finden, stehen in der Siemens-Software vier Arten von Fenstern zur Verfügung, die uns bei der Fehlerbehebung helfen. Sie lauten: Querverweis Aufrufstruktur Zuweisungsliste Abhängigkeitsstruktur Lassen Sie uns besprechen, wie wir sie in unserem Programm zur Fehlerbehebung verwenden und wo wir sie in der Software finden. Querverweis Querverweise werden verwendet, um alle in der Logik verwendeten digitalen und analogen Ein- und Ausgänge zu finden. Sie helfen uns dabei, herauszufinden, wie oft die E/A im Programm verwendet werden, und führen Benutzer auch direkt zum spezifischen Standort der E/A auf den Logikseiten. Hier ist ein Beispiel für eines der Programme, in dem Sie sehen können, wie die Querverweistabelle aussieht. Sie enthält alle Informationen wie Adressierung, die Sprache des Programms, verwendete Ein- und Ausgänge usw. Aufrufstruktur Wenn Sie wissen möchten, welcher Block in der Programmierung verwendet wird, wird die Aufrufstruktur verwendet. Dies ist eine Umkehrung der Querverweisfunktion, bei der wir erfahren, wie oft SFC- und FB-Blöcke in OB (Organisationsblock) verwendet werden, und hier erfahren wir, wie oft OB in SFC und FBs verwendet wird. Zuweisungsliste Die Zuweisungsliste ist eine sehr nützliche Funktion, wenn es darum geht, zu erfahren, wie viele Eingänge, Ausgänge, Timer und Zähler in unserer Anwendung verwendet werden und wie viele davon noch übrig sind, damit wir sie in zukünftigen Logiken verwenden können. Abhängigkeitsstruktur Die Abhängigkeitsstruktur wird verwendet, um anzuzeigen, wo jeder einzelne Block innerhalb der Programmierung verwendet wird. In Schritt 7 gelangen Sie jedoch nicht direkt an die Stelle, sondern in TIA PORTAL an die Stelle, an der das Programm geschrieben ist. HINWEIS: Um diese Fenster in Schritt 7 zu öffnen, verwenden Sie die Informationen wie in der Zeichnung gezeigt. Nach dem Klicken auf „Anzeigen“ stehen Ihnen die Optionen zur Verfügung. Führen Sie im TIA PORTAL die folgenden Schritte aus, die in der Zeichnung dargestellt sind.

Der Hauptunterschied zwischen DCS und PLC ist das Geschäftsmodell, das wir im Vergleich zwischen DCS- und SPS-Architektur erörtert haben. DCS- versus SPS-Architektur Das DCS-Geschäftsmodell basiert auf einem monolithischen integrierten System eines einzigen Herstellers. DCS-Architektur Bei einem DCS sind Controller, E/A-Subsystem, Datenbankserversoftware, Engineering-Software und Bedienersoftware alle eine einzige monolithische Einheit, die gemeinsam entwickelt wurde und nur miteinander funktioniert. Es ist nicht möglich, Komponenten von Drittanbietern zu verwenden. Es ist nicht möglich, eine dieser Komponenten auf einem anderen System zu verwenden. Ein DCS verwendet ein E/A-Subsystemnetzwerk und ein Steuerungsnetzwerk auf Basis von Standard-Ethernet, jedoch mit einem proprietären Anwendungsprotokoll und normalerweise nur mit einem bestimmten zugelassenen Modell von Ethernet-Switches. Abbildung 1 In einem DCS stammen alle Komponenten vom selben Hersteller. Nur eine bestimmte Version von Windows ist zulässig und nur auf einem Typ zugelassener Computer, der vom DCS-Hersteller geliefert wird. Diese Einschränkungen ermöglichen es dem DCS-Hersteller, alles sehr gründlich, in großem Maßstab, mit hoher Belastung, mit vielen Controllern und Arbeitsstationen zusammen zu testen. Anwendungen wie Batch-Steuerung, erweiterte Steuerung und Auto-Tuning usw. werden ebenfalls zusammen getestet. Dadurch wird sichergestellt, dass es keine Kompatibilitätskonflikte und unvorhergesehenen Abhängigkeiten gibt. Gründliche Tests im großen Maßstab sind möglich, da es im Wesentlichen nur einen Typ jeder Komponente gibt, also nur eine oder sehr wenige Kombinationen. Software von Drittanbietern ist nur auf separaten „Anwendungsstationen“ zulässig, wo sie nicht mit den nativen DCS-Anwendungen in Konflikt geraten kann und vom DCS-Hersteller getestet und genehmigt werden muss; auf die Whitelist gesetzt. Ein DCS ist monolithisch und verwendet E/A-Subsystem, Controller und Software derselben Marke sowie eine einzige Computer- und Betriebssystemplattform. Dies wurde im großen Maßstab gründlich getestet. DCS-Langzeitsupport Systeme bleiben normalerweise 15 Jahre oder länger betriebsbereit. Während dieser Zeit wird es mehrere Windows-Versionen, Service Packs, Hotfixes und zahlreiche Updates der Virendefinitionen geben, und auch die Computerhardware muss ersetzt werden. Normalerweise unterstützt DCS nur eine einzige Art von Antivirensoftware, und wenn es eine neue Virendefinition gibt oder wenn es ein Service Pack oder einen Hotfix für das Windows-Betriebssystem gibt, wird die gesamte monolithische Suite aller Hardware und Software vor der Veröffentlichung erneut vom Systemanbieter zusammen getestet, um sicherzustellen, dass die Virendefinition und das Service Pack ohne Kompatibilitätskonflikte bereitgestellt werden können. DCS-Upgrade DCS-Versionen werden auch als eine einzige monolithische Einheit aller Hardware und Software aktualisiert, wie z. B. E/A-Karten-Firmware, Controller-Firmware, Serversoftware, Engineering-Station-Software, Operator-Station-Software sowie jede andere Software, die alle zusammen aktualisiert werden. Jedes Mal, wenn es eine neue Systemversion gibt, werden alle diese Komponenten im Voraus vom Systemhersteller gründlich und in großem Umfang zusammen getestet, um sicherzustellen, dass sie alle miteinander kompatibel sind. Darüber hinaus wurde der Online-Hotcutover-Prozess von der früheren Version auf die neue Version gründlich und in großem Umfang getestet, um eine reibungslose Bereitstellung vor Ort sicherzustellen. Diese Sicherheit, die gründliche und groß angelegte Tests bieten, macht DCS bei großen Anlagen wie petrochemischen Komplexen sehr beliebt. Solche Tests werden durch die wenigen Kombinationen in einem monolithischen System praktikabel. SPS-Architektur/Geschäftsmodell Das SPS-Geschäftsmodell basiert auf einer flexiblen Architektur eines Systemintegrators (SI). SPS-Architektur Die SPS-Architektur ist sehr flexibel, da jede Komponente von einem der vielen Anbieter frei ausgewählt werden kann. Die SPS ist die CPU mit Konfigurationssoftware und IO-Subsystem. Manchmal kann das I/O-Subsystem von einem Drittanbieter stammen. Sogar I/O-Karten, die in die Rückwand eingesteckt werden, können von Drittanbietern stammen. Die HMI-Software stammt normalerweise von einem Drittanbieter. Ein nativer OPC-Server des SPS-Herstellers ist normalerweise am besten, manchmal werden jedoch auch OPC-Server von Drittanbietern verwendet. Abbildung 2 Für eine SPS werden Komponenten verschiedener Hersteller integriert Grundsätzlich funktioniert jede SPS mit jedem E/A-Subsystem, OPC-Server und jeder HMI-Software, da Standardprotokolle wie PROFIBUS-DP, PROFINET, Modbus/RTU, Modbus/TCP, DeviceNet und EtherNet/IP sowie OPC usw. verwendet werden. Netzwerkgeräte, Computer und Windows-Version können frei gewählt werden. Einige Komponenten, die nicht funktionieren, werden auf die schwarze Liste gesetzt. Abbildung 3 DCS verwendet einen einzigen Lieferanten, während SPS-Lösungen mehrere Lieferanten kombinieren, was zu einer großen Anzahl von Kombinationen führt Hinweis: Heutzutage ist auch ein einziger SPS-Paketlieferant verfügbar Diese Flexibilität ermöglicht Hunderte von Kombinationen aus Hardware und Software, was es diesen Herstellern unmöglich macht, zusammenzukommen und jede mögliche Kombination ihrer Hardware und Software auf jeder Windows-Version zu testen, bevor sich ein Werk zum Kauf entscheidet. Einige Kombinationen können von den beteiligten Herstellern getestet werden, aber dies kann in großem Maßstab und mit hoher Belastung erfolgen oder auch nicht. Eine SPS erlaubt jede Kombination aus E/A-Subsystem, CPU und HMI/SCADA-Software auf einer großen Vielfalt von Computer- und Betriebssystemplattformen. Nicht jede Kombination kann getestet werden. Der SPS-Hersteller liefert möglicherweise alle Hardware- und Softwarekomponenten vom selben Hersteller, da viele SPS-Hersteller HMI-Unternehmen übernommen haben. Wenn dies der Fall ist, wurde diese bestimmte Kombination möglicherweise gründlicher getestet als die anderen getesteten Kombinationen. Zusätzliche Anwendungen von Drittanbietern wie Batch-Steuerung, erweiterte Steuerung und Auto-Tuning usw. werden im Allgemeinen nicht zusammen getestet, da dies zu einer noch größeren Anzahl von Kombinationen führt. Die SPS verwendet genau wie DCS proprietäre Konfigurationssoftware. Das heißt, Sie können für Ihre SPS keine Konfigurationssoftware von Drittanbietern verwenden, genau wie für ein DCS. Ein nativer OPC-Server für die SPS ist besser als ein OPC-Server von Drittanbietern, da die SPS-Konfigurationssoftware den Adressraum für den OPC-Server im Allgemeinen automatisch konfiguriert. Langfristige Unterstützung für SPS Während der 15 oder mehr Jahre eines typischen Systembetriebs wird es mehrere Windows-Versionen, Service Packs, Hotfixes, viele Updates für Virendefinitionen geben, und auch die Computerhardware muss ersetzt werden. Normalerweise gibt es für SPS keine Beschränkungen hinsichtlich der Antivirensoftware oder der Version des Windows-Betriebssystems, sodass die Anzahl der Kombinationen aus Virendefinitionen, Service Packs und Hotfixes für diese Hersteller zu groß und unpraktisch wird, um gemeinsam jede mögliche neue Kombination vor einer Bereitstellung in Anlagen zu testen und sicherzustellen, dass es bei der Bereitstellung auf der großen Anzahl von Kombinationen aus Hardware und Software zu keinen Kompatibilitätskonflikten kommt. Der SPS-Hersteller kann sich auf eine einzige Antivirensoftware und Windows-Version beschränken. Wenn dies der Fall ist, wurde diese bestimmte Kombination möglicherweise gründlicher getestet als die anderen Kombinationen, die sie testen. SPS-Upgrade Bei einer SPS werden Hardware- und Softwarekomponenten einzeln aktualisiert. Das heißt, Firmware des E/A-Subsystems, CPU-Firmware und Konfigurationssoftware, OPC-Server, HMI-Software sowie jede andere Software werden unabhängig voneinander aktualisiert. Wenn man die verschiedenen Versionen für jede Komponentenoption berücksichtigt, wird die Anzahl der Kombinationen um ein Vielfaches größer. Diese Flexibilität macht es für diese Hersteller unpraktisch, zusammenzukommen und jede mögliche Kombination neuer Versionen vor dem Einsatz in Anlagen zu testen. Das Testen des Hot-Cutovers einer Kombination von Versionen auf eine andere Kombination von Versionen wird nahezu unmöglich. Der SPS-Hersteller kann alle Hardware- und Softwarekomponenten liefern, sich auf eine einzige Antivirensoftware und Windows-Version beschränken, die vor dem Einsatz getestet werden, und sich auf ein einziges E/A-Subsystem beschränken (Datenbankserver, Controller/SPS, Bedienstation/HMI, DCS, SPS, systemweite Versionsupgrades) und den Hot-Cutover vor dem Einsatz testen. Auf diese Weise würde die Flexibilität der SPS aufgegeben, um die Robustheit eines DCS zu erreichen.

Vergleichsanweisungen in der SPS werden verwendet, um Wertepaare zu testen und die logische Kontinuität einer Sprosse zu prüfen. Vergleichsanweisungen sind daher selten, wenn überhaupt, die letzten Anweisungen auf einer Sprosse. Arten von Vergleichsanweisungen Nehmen wir beispielsweise an, dass eine LES-Anweisung mit zwei Werten präsentiert wird. Wenn der erste Wert kleiner als der zweite ist, ist die Vergleichsanweisung wahr. Gleich-Anweisung (EQU) Verwenden Sie die EQU-Anweisung, um zu testen, ob zwei Werte gleich sind. Wenn Quelle A und Quelle B gleich sind, ist die Anweisung logisch wahr. Wenn diese Werte nicht gleich sind, ist die Anweisung logisch falsch. Quelle A muss eine Adresse sein. Quelle B kann entweder eine Programmkonstante oder eine Adresse sein. Werte werden in Zweierkomplementform gespeichert. Ungleich-Befehl (NEQ) Verwenden Sie den NEQ-Befehl, um zu testen, ob zwei Werte ungleich sind. Wenn Quelle A und Quelle B ungleich sind, ist der Befehl logisch wahr. Quelle A muss eine Adresse sein. Quelle B kann entweder eine Programmkonstante oder eine Adresse sein. Werte werden in Zweierkomplementform gespeichert. Kleiner-als-Befehl (LES) Verwenden Sie den LES-Befehl, um zu testen, ob ein Wert (Quelle A) kleiner als ein anderer (Quelle B) ist. Wenn Quelle A kleiner als der Wert an Quelle B ist, ist der Befehl logisch wahr. Quelle A muss eine Adresse sein. Quelle B kann entweder eine Programmkonstante oder eine Adresse sein. Werte werden in Zweierkomplementform gespeichert. Kleiner-als-oder-gleich-Befehl (LEQ) Verwenden Sie den LEQ-Befehl, um zu prüfen, ob ein Wert (Quelle A) kleiner oder gleich einem anderen (Quelle B) ist. Wenn der Wert an Quelle A kleiner oder gleich dem Wert an Quelle B ist, ist der Befehl logisch wahr. Quelle A muss eine Adresse sein. Quelle B kann entweder eine Programmkonstante oder eine Adresse sein. Werte werden in Zweierkomplementform gespeichert. Größer-als-Befehl (GRT) Verwenden Sie den GRT-Befehl, um zu prüfen, ob ein Wert (Quelle A) größer als ein anderer (Quelle B) ist. Wenn der Wert an Quelle A größer als der Wert an Quelle B ist, ist der Befehl logisch wahr. Größer-als-oder-gleich-Befehl (GEQ) Verwenden Sie den GEQ-Befehl, um zu prüfen, ob ein Wert (Quelle A) größer oder gleich einem anderen (Quelle B) ist. Wenn der Wert an Quelle A größer oder gleich dem Wert an Quelle B ist, ist die Anweisung logisch wahr. Maskierter Vergleich auf Gleichheit (MEQ) Verwenden Sie die MEQ-Anweisung, um Daten an einer Quelladresse mit Daten an einer Vergleichsadresse zu vergleichen. Die Verwendung dieser Anweisung ermöglicht es, Teile der Daten durch ein separates Wort zu maskieren. Quelle ist die Adresse des Werts, den Sie vergleichen möchten. Maske ist die Adresse der Maske, durch die die Anweisung Daten verschiebt. Die Maske kann ein hexadezimaler Wert sein. Vergleich ist ein ganzzahliger Wert oder die Adresse der Referenz. Wenn die 16 Datenbits an der Quelladresse gleich den 16 Datenbits an der Vergleichsadresse sind (abzüglich maskierter Bits), ist die Anweisung wahr. Die Anweisung wird falsch, sobald sie eine Nichtübereinstimmung erkennt. Grenzwerttest-Anweisung (LIM) Verwenden Sie die LIM-Anweisung, um Werte innerhalb oder außerhalb eines angegebenen Bereichs zu testen, je nachdem, wie Sie die Grenzwerte festlegen. Die Werte für Untergrenze, Test und Obergrenze können Wortadressen oder Konstanten sein, beschränkt auf die folgenden Kombinationen: Wenn der Testparameter eine Programmkonstante ist, müssen sowohl der Untergrenze- als auch der Obergrenze-Parameter Wortadressen sein. Wenn der Testparameter eine Wortadresse ist, können die Untergrenze- und Obergrenze-Parameter entweder eine Programmkonstante oder eine Wortadresse sein. Wahr/Falsch-Status der LIM-Anweisung Wenn die Untergrenze einen Wert hat, der gleich oder kleiner als die Obergrenze ist, ist die Anweisung wahr, wenn der Testwert zwischen den Grenzwerten liegt oder gleich einem der Grenzwerte ist. Wenn die Untergrenze einen Wert hat, der größer als die Obergrenze ist, ist die Anweisung falsch, wenn der Testwert zwischen den Grenzwerten liegt.

Dies ist ein SPS-Programm zur Ein-/Ausfahrtskontrolle von Parkplätzen in Kellern oder unterirdischen Anlagen. SPS-Parkplatz Problembeschreibung Aufgrund der Überfüllung von Bereichen haben wir mit vielen Problemen beim Parken von Fahrzeugen in Kellern oder unterirdischen Anlagen von Einkaufszentren, Hotels, Komplexen usw. zu kämpfen. Dies geschieht aufgrund des Widerspruchs zwischen der schnell wachsenden Anzahl von Fahrzeugen und begrenzten Parkmöglichkeiten in Einkaufszentren, Geschäften und Komplexen in Städten, was zu dem Phänomen des „schwierigen Parkens und ungeordneten Parkens“ führt. Das aktuelle Parkproblem hat schwerwiegende Auswirkungen auf die Lebensqualität der Menschen und den Straßenverkehr. Problemdiagramm Problemlösung Durch einfache Automatisierung können wir das Parkproblem in Kellern oder unterirdischen Anlagen von Einkaufszentren, Hotels, Komplexen usw. reduzieren. Die Ein-/Ausfahrt in Kellern ist eine einspurige Passage und benötigt Ampeln zur Kontrolle der Autos. Hier betrachten wir zwei Lichtanzeigen zur Kontrolle der Autos. Rote Ampeln verhindern das Ein- und Ausfahren von Autos, während grüne Ampeln das Ein- und Ausfahren von Autos erlauben. Wenn ein Auto vom Eingang im Erdgeschoss in den Durchgang einfährt, leuchten beide roten Ampeln (Erdgeschoss und Keller). Andere Autos dürfen während des Vorgangs nicht ein- und ausfahren, bis das Auto den einzigen Durchgang passiert hat. Wenn der Durchgang frei ist, leuchten beide grünen Ampeln (Erdgeschoss und Keller) und andere Autos können vom Erdgeschoss oder Keller aus einfahren. Zunächst lassen wir die grünen Lichter AN und die roten Lichter AUS Liste der Ein- und Ausgänge Eingabeliste Hauptschalter: I0.0 Sensor S1 für Eingang/Ausgang Erdgeschoss: I0.1 Sensor S2 für Eingang/Ausgang Keller: I0.2 Ausgabeliste Grünes Licht (Eingang/Ausgang Erdgeschoss): Q0.0 Grünes Licht (Eingang/Ausgang Keller): Q0.1 Rotes Licht (Eingang/Ausgang Erdgeschoss): Q0.2 Rotes Licht (Eingang/Ausgang Keller): Q0.3 M-Speicherspulenliste M10.0: Wird AN sein, wenn ein Auto Sensor S1 passiert M10.3: Wird AN sein, wenn ein Auto Sensor S2 passiert M0.0: Positive Flanke des Systems AN M0.1 & M11.0: Positive Flanke des Sensors S1 M0.3 & M11.1: Positive Flanke des Sensors S2 M11.2: Negative Flanke von Sensor S2 M11.3: Negative Flanke von Sensor S1 SPS-Kontaktplan für Ein-/Ausfahrtskontrolle von Parkplätzen Programmbeschreibung In dieser Anwendung haben wir zur Programmierung die Siemens S7-300 SPS und die TIA Portal-Software verwendet. Netzwerk 1: Gemäß der obigen Erklärung im ersten Netzwerk leuchten zunächst beide grünen Lichter (Erdgeschoss (Q0.0) und Keller (Q0.1)), wenn das System eingeschaltet ist (I0.0). Der SET-Befehl wird ausgeführt und setzt sowohl den Ausgang Q0.0 als auch den Ausgang Q0.1. Netzwerk 2: Gemäß obiger Erklärung im zweiten Netzwerk sind, wenn das System eingeschaltet ist (I0.0), zunächst beide roten Lichter (Erdgeschoss (Q0.2) und Kellergeschoss (Q0.3)) AUS.) Der RESET-Befehl wird ausgeführt und setzt sowohl den Ausgang Q0.2 als auch den Ausgang Q0.3 zurück. Netzwerk 3: Wenn ein Auto vom Erdgeschoss in den leeren Durchgang einfährt, wird Sensor S1 (I0.1) ausgelöst und mit diesem Auslöser wird die Speicherspule M10.0 GESETZT. Netzwerk 4: Wenn ein Auto vom Keller in den leeren Durchgang einfährt, wird Sensor S2 (I0.2) ausgelöst und mit diesem Auslöser wird die Speicherspule M10.3 GESETZT. Netzwerk 5: Beide roten Lichter werden entweder durch einen positiven Trigger des Sensors S1 oder des Sensors S2 gesetzt. Denn wenn ein Auto in eine leere Passage einfährt, verhindern beide roten Lichter (Q0.2 & Q0.3) das Ein-/Ausfahren von Autos auf beiden Seiten. Netzwerk 6: Hier haben wir einen negativen Trigger der beiden Sensoren S1 (I0.1) und S2 (I0.2) genommen. Wenn sie also ausgelöst werden, sind die roten Lichter (Q0.2 & Q0.3) AUS. Wenn ein Auto die leere Passage vollständig passiert, sollten die roten Lichter (Q0.2 & Q0.3) AUS sein. Netzwerk 7: In diesem Netzwerk sind die grünen Lichter (Q0.0 & Q0.1) EIN, wenn die roten Lichter AUS sind. Die grünen Lichter (Q0.0 & Q0.1) ermöglichen anderen Autos das Ein- oder Ausfahren. Netzwerk 8: Wenn die roten Lichter (Q0.2 & Q0.3) zu diesem Zeitpunkt EIN sind, sollten die grünen Lichter (Q0.0 & Q0.1) AUS sein. Wenn in diesem Netzwerk also die roten Lichter (Q0.2 & Q0.3) zu diesem Zeitpunkt EIN sind, wird der Reset-Befehl ausgeführt und die grünen Lichter (Q0.0 & Q0.1) werden AUS sein. Netzwerk 9: Wenn der System-Ein-Schalter (I0.0) AUS ist, sollten alle Speicher 0 sein. Hier haben wir den MOVE-Befehl verwendet, um Nullen in allen Speichern (MB0, QB0 und MB10) zu verschieben. Dieses Beispiel dient nur der Konzepterklärung, nicht alle Parameter werden in diesem Beispiel berücksichtigt (wie Türöffnungs-/Schließsystem, Alarme usw.) Ergebnis Hinweis: Die obige SPS-Logik liefert eine grundlegende Idee zur Anwendung von SPS bei der Parksteuerung von Ein-/Ausgangstoren. Die Logik ist begrenzt und stellt keine vollständige Anwendung dar.

Dies ist ein SPS-Programm zum Implementieren eines Programms zum Zählen von Objekten auf dem bewegten Förderband. Zählen bewegter Objekte auf dem Förderband Objekte bewegen sich auf dem Förderband. Wir müssen die Gesamtzahl der am Ende des Förderbands gesammelten Objekte zählen und auf dem lokalen Bedienfeld anzeigen. Schreiben Sie ein SPS-Programm für diese Anwendung. Problemdiagramm Problemlösung Hier verwenden wir ein SPS-Kontaktplanprogramm, um diese Logik zu implementieren. Meistens werden Näherungssensoren zum Erkennen der Objekte verwendet. Hier montieren wir Näherungssensoren, um die sich auf dem Förderband bewegenden Teile oder Objekte zu erkennen. Induktive Sensoren werden hauptsächlich zum Erkennen von Metallobjekten verwendet. Für andere Objekttypen verwenden wir kapazitive Näherungssensoren zum Erkennen der sich auf dem Förderband bewegenden Objekte. Wir verbinden diesen Sensor mit der SPS und zählen mithilfe der Zählerlogik die Anzahl der Objekte und zeigen die Gesamtzahl auf dem lokalen Bedienfelddisplay an. Hier verwenden wir einen Aufwärtszähler zum Zählen der am Ende des Förderbands gesammelten Objekte. Hinweis: Hier haben wir eine einfache Anwendung zum Zählen von Objekten betrachtet. Wir haben einen Näherungssensor zum Erkennen der Objekte betrachtet. Der Näherungssensor erkennt das Objekt und der PLC-UP-Zähler zählt die gesammelten Objekte. Liste der Ein- und Ausgänge Digitale Eingänge Start: I0.0 Stopp: I0.1 Näherung: I0.2 (Objekterkennung) Zähler zurücksetzen PB: I0.3 Digitaler Ausgang Zyklus EIN: Q0.0 M-Speicher Zähler zurücksetzen: M0.1 Gesamtzahl gesammelter Objekte: MW10 PLC-Kontaktplanlogik zum Zählen von Objekten auf dem Förderband Erklärung der Kontaktplanlogik Für diese Anwendung verwenden wir S7-300 PLC und TIA-Portalsoftware zum Programmieren. Wir können diese Logik auch mit anderen PLCs implementieren. Netzwerk 1: Im ersten Netzwerk haben wir einen Verriegelungskreis für Zyklus EIN verwendet. Hier haben wir START PB (I0.0) verwendet, um den Zyklus zu starten, und STOP PB (I0.1), um den Zyklus zu stoppen. Netzwerk 2: Der PLC-Zählerbefehl wird verwendet, um die Anzahl der Objekte zu zählen. Näherungssensoren sind in der Nähe des Förderbands angebracht. Wenn sich ein Objekt dem Näherungssensor (I0.2) nähert, erkennt dieser das Objekt und der Ausgang des Sensors wird aktiviert oder wechselt in den EIN-Zustand. Wenn sich kein Objekt in der Nähe des Näherungssensors befindet, wird der Ausgang des Sensors deaktiviert oder wechselt in den AUS-Zustand. Der PLC-Zähler zählt inkrementell. Die Gesamtzahl der gezählten Objekte wird im Speicherwort oder Register (MW10) gespeichert. Hinweis: Die obige Anwendung kann von der tatsächlichen Anwendung abweichen. Dieses Beispiel dient nur zu Erklärungszwecken. Wir können diese Logik auch in anderen PLCs implementieren. Dies ist das einfache Konzept des AUFWÄRTS-Zählers. Mit diesem Konzept können wir Objekte zählen, die sich auf dem Förderband bewegen, oder jede andere Zählanwendung. Diese Logik ist nur ein Teil oder nur für eine bestimmte Anwendungslogik. Alle im Beispiel berücksichtigten Parameter dienen nur zu Erklärungszwecken. In tatsächlichen Anwendungen können die Parameter anders sein. Ergebnis

Es gibt viele Steuerungssituationen, in denen Aktionen eingeleitet werden müssen, wenn eine bestimmte Kombination von Logikfunktionsbedingungen in einer SPS erfüllt ist. SPS-Logikfunktionen Bei einer automatischen Bohrmaschine könnte beispielsweise die Bedingung vorliegen, dass der Bohrmotor aktiviert werden soll, wenn die Endschalter aktiviert werden, die das Vorhandensein des Werkstücks und die Bohrposition als an der Oberfläche des Werkstücks liegend anzeigen. Eine solche Situation beinhaltet die UND-Logikfunktion, wobei sowohl Bedingung A als auch Bedingung B erfüllt sein müssen, damit eine Ausgabe erfolgt. Dieser Abschnitt befasst sich mit solchen Logikfunktionen. SPS UND LOGIK Abbildung 1.7a zeigt eine Situation, in der eine Ausgabe nur dann aktiviert wird, wenn zwei normalerweise offene Schalter beide geschlossen sind. Schalter A und Schalter B müssen beide geschlossen sein, was somit eine UND-Logiksituation ergibt. Wir können uns dies als ein Steuerungssystem mit zwei Eingängen A und B vorstellen (Abbildung 1.7b). Nur wenn A und B beide eingeschaltet sind, gibt es eine Ausgabe. Wenn wir also 1 verwenden, um ein Ein-Signal anzuzeigen, und 0, um ein Aus-Signal darzustellen, müssen A und B beide 1 sein, damit es eine 1-Ausgabe gibt. Eine solche Operation wird von einem Logikgatter gesteuert, und die Beziehung zwischen den Eingängen eines Logikgatters und den Ausgängen wird in einer als Wahrheitstabelle bezeichneten Form tabellarisch dargestellt. Für das UND-Gatter haben wir also: Ein Beispiel für ein UND-Gatter ist ein Verriegelungssteuerungssystem für eine Werkzeugmaschine, sodass diese nur betrieben werden kann, wenn die Schutzvorrichtung in Position ist und die Stromversorgung eingeschaltet ist. Abbildung 1.8a zeigt ein UND-Gattersystem in einem Leiterdiagramm. Das Leiterdiagramm beginnt mit j j, einem normalerweise offenen Satz von Kontakten mit der Bezeichnung Eingang A, um Schalter A darzustellen, und in Reihe dazu j j, einem weiteren normalerweise offenen Satz von Kontakten mit der Bezeichnung Eingang B, um Schalter B darzustellen. Die Linie endet dann mit O, um den Ausgang darzustellen. Damit ein Ausgang vorhanden ist, müssen sowohl Eingang A als auch Eingang B vorhanden sein, d. h. die Kontakte von Eingang A und Eingang B müssen geschlossen sein (Abbildung 1.8b). Im Allgemeinen gilt: Auf einem Leiterdiagramm stellen Kontakte in einer horizontalen Sprosse, d. h. Kontakte in Reihe, die logischen UND-Operationen dar. SPS-ODER-LOGIK Abbildung 1.9a zeigt einen Stromkreis, bei dem ein Ausgang aktiviert wird, wenn Schalter A oder B, beide normalerweise offen, geschlossen sind. Dies beschreibt ein ODER-Logikgatter (Abbildung 1.9b), da Eingang A oder Eingang B eingeschaltet sein müssen, damit ein Ausgang vorhanden ist. Die Wahrheitstabelle lautet: Abbildung 1.10a zeigt ein ODER-Logikgattersystem auf einem Leiterdiagramm, Abbildung 1.10b zeigt eine gleichwertige alternative Art, dasselbe Diagramm zu zeichnen. Das Leiterdiagramm beginnt mit j j, normalerweise offenen Kontakten mit der Bezeichnung Eingang A, um Schalter A darzustellen, und parallel dazu j j, normalerweise offenen Kontakten mit der Bezeichnung Eingang B, um Schalter B darzustellen. Entweder Eingang A oder Eingang B müssen geschlossen sein, damit der Ausgang aktiviert wird (Abbildung 1.10c). Die Linie endet dann mit O, um den Ausgang darzustellen. Im Allgemeinen: Alternative Pfade, die durch vertikale Pfade von der Hauptsprosse eines Leiterdiagramms bereitgestellt werden, d. h. parallele Pfade, stellen logische ODER-Operationen dar. Ein Beispiel für ein ODER-Gatter-Steuerungssystem ist ein Förderband, das Flaschenprodukte zur Verpackung transportiert, wo eine Abweiserplatte aktiviert wird, um Flaschen in einen Ausschussbehälter abzulenken, wenn entweder das Gewicht nicht innerhalb bestimmter Toleranzen liegt oder kein Verschluss auf der Flasche ist. SPS, KEINE LOGIK Abbildung 1.11a zeigt einen elektrischen Schaltkreis, der von einem normalerweise geschlossenen Schalter gesteuert wird. Wenn ein Eingang an den Schalter angelegt wird, öffnet er sich und es fließt dann kein Strom im Schaltkreis. Dies veranschaulicht ein NICHT-Gatter, da es einen Ausgang gibt, wenn kein Eingang vorhanden ist, und keinen Ausgang, wenn ein Eingang vorhanden ist (Abbildung 1.11c). Das Gatter wird manchmal als Inverter bezeichnet. Die Wahrheitstabelle lautet: Abbildung 11.11b zeigt ein NICHT-Gattersystem in einem Leiterdiagramm. Die Kontakte von Eingang A sind als normalerweise geschlossen dargestellt. Dies ist in Reihe mit dem Ausgang ( ). Wenn kein Eingang an Eingang A anliegt, sind die Kontakte geschlossen und es gibt einen Ausgang. Wenn ein Eingang an Eingang A anliegt, öffnet er sich und es gibt dann keinen Ausgang. Ein Beispiel für ein NICHT-Gatter-Steuerungssystem ist ein Licht, das aufleuchtet, wenn es dunkel wird, d. h. wenn kein Lichteingang an den Lichtsensor angelegt wird, gibt es einen Ausgang. SPS-NAND-LOGIK Nehmen wir an, wir lassen einem UND-Gatter ein NICHT-Gatter folgen (Abbildung 1.12a). Die Konsequenz des NOT-Gatters ist, dass alle Ausgänge des AND-Gatters invertiert werden. Eine Alternative, die genau dieselben Ergebnisse liefert, besteht darin, an jeden Eingang ein NOT-Gatter anzulegen und dann ein OR-Gatter folgen zu lassen (Abbildung 1.12b). Es ergibt sich dieselbe Wahrheitstabelle, nämlich: Beide Eingänge A und B müssen 0 sein, damit es einen 1-Ausgang gibt. Es gibt einen Ausgang, wenn Eingang A und Eingang B nicht 1 sind. Die Kombination dieser Gatter wird als NAND-Gatter bezeichnet (Abbildung 1.13). Ein Beispiel für ein NAND-Gatter-Steuerungssystem ist eine Warnleuchte, die aufleuchtet, wenn bei einer Werkzeugmaschine der Sicherheitsschalter nicht aktiviert wurde und der Endschalter, der das Vorhandensein des Werkstücks signalisiert, nicht aktiviert wurde. SPS oder Logik Nehmen wir an, wir lassen auf ein OR-Gatter ein NOT-Gatter folgen (Abbildung 1.14a). Die Konsequenz des NOT-Gatters ist, die Ausgänge des OR-Gatters zu invertieren. Eine Alternative, die genau dieselben Ergebnisse liefert, besteht darin, an jeden Eingang ein NOT-Gatter und dann ein AND-Gatter für die resultierenden invertierten Eingänge anzubringen (Abbildung 1.14b). Nachfolgend sehen Sie die resultierende Wahrheitstabelle: Die Kombination aus OR- und NOT-Gattern wird als NOR-Gatter bezeichnet. Es gibt einen Ausgang, wenn weder Eingang A noch Eingang B 1 ist. Abbildung 1.15 zeigt ein Kontaktplandiagramm eines NOR-Systems. Wenn Eingang A und Eingang B beide nicht aktiviert sind, gibt es einen 1-Ausgang. Wenn entweder X400 oder X401 1 sind, gibt es eine 0-Ausgabe. SPS-Exklusiv-ODER-Logik (XOR) Das ODER-Gatter gibt eine Ausgabe aus, wenn einer oder beide der Eingänge 1 sind. Manchmal wird jedoch ein Gatter benötigt, das eine Ausgabe ausgibt, wenn einer der Eingänge 1 ist, aber nicht, wenn beide 1 sind, d. h. das die Wahrheitstabelle hat: Ein solches Gatter wird Exklusiv-ODER- oder XOR-Gatter genannt. Eine Möglichkeit, ein solches Gatter zu erhalten, ist die Verwendung von NICHT-, UND- und ODER-Gattern, wie in Abbildung 1.16 gezeigt. Abbildung 1.17 zeigt ein Leiterdiagramm für ein XOR-Gattersystem. Wenn Eingang A und Eingang B nicht aktiviert sind, gibt es eine 0-Ausgabe. Wenn nur Eingang A aktiviert ist, ergibt der obere Zweig eine Ausgabe von 1. Wenn nur Eingang B aktiviert ist, ergibt der untere Zweig eine Ausgabe von 1. Wenn sowohl Eingang A als auch Eingang B aktiviert sind, gibt es keine Ausgabe. In diesem Beispiel eines Logikgatters haben Eingang A und Eingang B zwei Kontaktsätze in den Schaltkreisen, wobei ein Satz normalerweise offen und der andere normalerweise geschlossen ist. Bei der SPS-Programmierung kann jeder Eingang so viele Kontaktsätze wie nötig haben. SPS Exclusive NOR (XNOR) LOGIC

In einem früheren Artikel haben wir besprochen, was ein Funktionsblock (FB) ist, wie er in einem SPS-Programm funktioniert und wie man ihn erstellt und verwendet. In diesem Artikel sprechen wir über Datenblockinstanzen verschiedener Funktionsblocktypen im Siemens Tia Portal und wann welcher Typ verwendet wird. Inhalt: Was ist ein Funktionsblock (FB)? Verschiedene Optionen für Dateninstanzen. Einzelinstanz. Parameterinstanz. Mehrfachinstanz. Was ist ein Funktionsblock? Ein Funktionsblock oder FB ist einfach ein Block, der Codelogik enthält. Sie verwenden diesen FB, um durch die darin geschriebenen Codeteile bestimmte Funktionen zu erreichen. Wenn Sie einen Funktionsblock in Ihren Code aufrufen, werden Sie aufgefordert, einen Datenblock (auch Dateninstanz genannt) zuzuweisen, der diesem FB zugeordnet werden soll, um die Werte der FB-Parameter zu speichern. Nicht alle Parameter innerhalb eines FB werden in der Dateninstanz gespeichert, aber darauf kommen wir später zurück. Beim Aufrufen eines Funktionsblocks haben Sie 3 verschiedene Optionen, um diesem Funktionsaufruf eine Datenblockinstanz zuzuordnen. Diese verschiedenen Optionen hängen davon ab, wo Sie Ihren FB aufrufen. Kurz gesagt: Ein Funktionsblock-FB ist im Grunde ein Funktions-FC mit einem dedizierten Datenblock-DB. Dieser Datenblock wird zum Speichern der Werte der Funktionsblockparameter verwendet. Verschiedene Optionen für Dateninstanzen Wir haben 3 verschiedene Optionen für eine Dateninstanz eines Funktionsblocks, und zwar: Einzelinstanz. Parameterinstanz. Mehrfachinstanz. Die drei verschiedenen Aufrufdateninstanzen stammen aus den 3 verschiedenen Aufrufmethoden: Sie können einen Funktionsblock-FB innerhalb des Haupt-OB1 aufrufen, wodurch Sie die folgenden Optionen haben: Einzelinstanz. Sie können den Funktionsblock FB innerhalb einer Funktion FC aufrufen, wodurch Sie zwei Optionen haben: Einzelinstanz Parameterinstanz Sie können den Funktionsblock innerhalb eines anderen Funktionsblocks aufrufen, wodurch Sie die drei verfügbaren Optionen zum Erstellen einer Dateninstanz haben: Einzelinstanz Parameterinstanz Mehrere Instanzen Einzelne Dateninstanz Beginnen wir zunächst mit der Erstellung eines Funktionsblocks FB. Wie bereits erwähnt, erstellen wir einen Funktionsblock, indem wir auf „Neuen Block hinzufügen“ klicken und den gewünschten Blocktyp auswählen. Siehe Abbildung 1. Abbildung 1 – Erstellen eines Funktionsblocks FB Rufen wir nun den wiederverwendbaren FB auf, den wir in unserem Haupt-OB1 erstellt haben. Siehe Abbildung 2. Abbildung 2 – Aufrufen des FB innerhalb des Haupt-OB1 Wie Sie im vorherigen Bild sehen, werden Sie beim Aufrufen eines FB innerhalb des Haupt-OB1 aufgefordert, eine Dateninstanz zuzuweisen, die diesem FB-Aufruf zugeordnet werden soll. In diesem Fall gibt es nur eine Option, nämlich die Einzelinstanz. Nach Auswahl der Einzelinstanzoption wird ein Datenblock erstellt und mit dem FB-Aufruf verknüpft. Siehe Abbildung 3. Abbildung 3 – Einzelinstanz erstellt Die erstellte Einzelinstanz wird verwendet, um die Werte einiger FB-Parameter zu speichern. Wie die Eingänge, Ausgänge, In Out und statischen Parameter. Andere Parameter des FB werden nicht gespeichert, wie Temperatur und Konstanten. Siehe Abbildungen 4 und 5. Abbildung 4 – Daten werden in der Dateninstanz gespeichert Abbildung 5 – Daten werden vom FB in der Dateninstanz gespeichert. Erstellen wir nun eine einfache Logik innerhalb des FB, um die Dateninstanzen besser zu verstehen. Diese Logik fügt einer statischen Variable einen konstanten Wert von 15 hinzu und verschiebt das Ergebnis dann zum Ausgang. Siehe Bild 6. Bild 6 – Erstellen Sie eine einfache Logik Gehen Sie nun zurück zum Haupt-OB1 und sehen Sie sich an, wie Ihr FB-Aufruf jetzt aussieht. Siehe Bild 7. Bild 7 – Aktualisieren Sie den FB-Aufruf nach jeder Änderung Jede Änderung, die Sie an der Logik innerhalb des FB vornehmen, führt dazu, dass der Funktionsblockaufruf aktualisiert werden muss, damit die vorgenommenen Änderungen angewendet werden können. Sie können den Blockaufruf aktualisieren, indem Sie mit der rechten Maustaste auf den FB-Aufruf klicken und die Option „Blockaufruf aktualisieren“ drücken oder indem Sie Ihren SPS-Code neu kompilieren. Siehe Bild 8. Bild 8 – Aktualisieren des FB-Aufrufs Nach der Aktualisierung des Blockaufrufs werden die im FB-Code vorgenommenen Änderungen angewendet und im Blockaufruf verwendet. Wie Sie in Bild 9 sehen. Der FB erwartet nun ein Eingangssignal vom Typ bool und gibt einen Ausgang vom Typ int aus. Bild 9 – Eingänge und Ausgänge sind nun mit dem FB-Aufruf verknüpft Lassen Sie uns unseren Code simulieren und sehen, wie sich die SPS verhält. Sehen Sie sich die nächste Animation an, die eine einfache Simulation der bisherigen SPS-Logik zeigt. Wie Sie in der Animation sehen, wird die Funktion immer dann ausgeführt, wenn das Startsignal TRUE ist, und der Ausgang ändert sich weiter. Und sobald das Startsignal nicht mehr verfügbar ist, bleibt der Ausgang auf dem zuletzt aufgezeichneten Wert. Die Verwendung der Dateninstanz besteht hier darin, dass die Werte der statischen Variablen und der Ausgangsvariablen in der einzelnen Instanz gespeichert werden, sodass die Funktion bei erneutem Startsignal mit den zuletzt aufgezeichneten Werten fortgesetzt wird. Sehr wichtiger Hinweis Sie sollten niemals dieselbe einzelne Instanz für zwei verschiedene Aufrufe eines FBs verwenden. Siehe die nächste Animation. Wie Sie in der Animation sehen, haben wir zwei verschiedene FB-Aufrufe, aber beide Aufrufe sind mit derselben einzelnen Instanz verknüpft, weshalb sich der Output2-Wert mit Output1 änderte, selbst wenn das Start2-Signal FALSE war. Wie zu erwarten, wird die Änderung der Dateninstanz des 1. Aufrufs auch im 2. Aufruf beeinflusst, da sie denselben Speicherblock haben. Siehe Abbildung 10. Abbildung 10 – Verwenden Sie niemals dieselbe Dateninstanz mit verschiedenen FB-Aufrufen Wenn Sie dieselbe Dateninstanz mit verschiedenen FB-Aufrufen verwendet haben, ist Ihr Funktionsblock nicht mehr wiederverwendbar. Auch wenn die Ein-/Ausgabeparameter für jeden einzelnen FB-Aufruf unterschiedlich sind. Wie Sie im letzten Video (Animation) gesehen haben, hatten beide Aufrufe dieselben Ergebnisse, obwohl der 2. Aufruf nicht einmal ein Aktivierungseingangssignal hat. Ein weiterer sehr wichtiger Hinweis Wir haben bereits erwähnt, dass Sie, wenn Sie Ihren FB von einem übergeordneten FC aus aufrufen, zwei Optionen für die zugehörige Dateninstanz haben: die Einzelinstanz und die Parameterinstanz. Siehe Abbildung 11. Abbildung 11 – Verwenden einer Einzelinstanz mit einem von einem FC aus aufgerufenen FB Wenn dies passiert und Sie einen FB innerhalb eines FC aufrufen, sollten Sie für Ihre FBs niemals eine Einzelinstanz verwenden. Um zu erfahren, warum das so ist, siehe Abbildung 12 Abbildung 12 – Mehrmaliges Aufrufen des übergeordneten FC Wie Sie in Abbildung 12 sehen, werden Sie nicht aufgefordert, einen Datenblock zuzuweisen, wenn Sie den übergeordneten FC in Ihrer Logik mehr als einmal aufrufen, da FCs keinen benötigen. Sie wissen jedoch, dass sich innerhalb des FC ein aufgerufener FB befindet, diesem FB ist eine Einzelinstanz zugeordnet. Die 3 FC-Aufrufe haben jetzt also dieselbe Dateninstanz für den FB-Aufruf. Ihre Funktion FC ist also nicht mehr wiederverwendbar. Was tun? Wenn Sie einen FB innerhalb eines FC aufrufen müssen, ist die beste Option die Verwendung der Parameterinstanz. Parameterinstanz Wie bereits erwähnt, sollten Sie, wenn Sie einen FB innerhalb eines FC aufrufen, nicht die einzelne Instanz wählen, sondern die Parameterinstanz ist für Ihre Wiederverwendbarkeit besser. Eine Parameterinstanz speichert die Dateninstanz des aufgerufenen FB im In-Out-Bereich der FC-Blockschnittstelle. So können Sie für jeden FC-Aufruf eine neue Dateninstanz eingeben. Siehe Bilder 13 und 14. Bild 13 – Zuweisen einer Parameterinstanz beim Aufrufen eines FB innerhalb eines FC Bild 14 – Jeder FC-Aufruf erfordert eine neue Dateninstanz Wie Sie im vorherigen Bild sehen, wird jedes Mal, wenn Sie den FC innerhalb Ihres Programms aufrufen, eine Dateninstanz für den wiederverwendbaren FB innerhalb des FC angefordert. Auf diese Weise müssen Sie die Dateninstanz jedoch selbst erstellen. Siehe Bild 15. Bild 15 – Erstellen einer neuen Dateninstanz Um eine neue Dateninstanz zu erstellen, gehen Sie genauso vor wie beim Erstellen eines FC oder eines FB, wählen dieses Mal jedoch die DB-Option. Und stellen Sie sicher, dass Sie den DB-Typ so auswählen, dass er mit dem des aufgerufenen FB übereinstimmt. Jetzt kann Ihr FC beliebig oft wiederverwendet werden, Sie müssen lediglich für jeden Aufruf eine Instanz erstellen. Siehe Abbildung 16. Abbildung 16 – Weisen Sie den DB dem FC-Aufruf zu Multiinstanzdatenbank Eine Multiinstanzdatenbank bedeutet einfach, dass der DB des aufgerufenen FB im DB des aufrufenden FBs höherer Ebene gespeichert wird. Diese Option ist nur verfügbar, wenn Sie einen FB von einem anderen FB aus aufrufen. Lassen Sie uns einen weiteren FB erstellen, um ihn als FB höherer Ebene zu verwenden. Rufen Sie diesen HigherLevelFB nach dem Erstellen vom Haupt-OB1 aus auf. Natürlich ist die einzige Aufrufoption eine einzelne Instanz, wie zuvor gezeigt. Siehe Abbildung 17. Abbildung 17 – Rufen Sie den HigherLevelFB vom Haupt-OB1 aus auf Rufen Sie nun den ReusableFB vom HigherLevelFB aus auf. Und wählen Sie die Option Multiinstanz. Siehe Abbildung 18. Abbildung 18 – Mehrfachinstanz-DB zuweisen Wenn Sie die Option Mehrfachinstanz wählen, wird die erstellte DB in den statischen Parametern des aufrufenden FB gespeichert. Siehe Abbildung 19. Abbildung 19 – Instanzen werden in statischen Parametern gespeichert Sie können den wiederverwendbaren FB viele Male aufrufen, bei jedem Aufruf wird die Mehrfachinstanz im statischen Parameter gespeichert. Siehe Abbildung 20. Abbildung 20 – Wiederverwendbaren FB viele Male aufrufen Wie Sie sehen, wird die Dateninstanz des FB auf niedrigerer Ebene in der Dateninstanz des FB auf höherer Ebene gespeichert. Dies ist am besten für eine bessere Programmstruktur und eine leicht lesbare Logik. Fazit Wenn Sie Funktionsblöcke in Ihrem Code erstellen, müssen Sie jedem FB-Aufruf, den Sie in Ihrer Logik vornehmen, einen Datenblock zuordnen. Dieser Datenblock oder auch Dateninstanz genannt, hat je nach Art des Blocks, der Ihren FB aufruft, unterschiedliche Optionen. Seien Sie bei der Auswahl des Dateninstanztyps vorsichtig, da einige Optionen für Ihren Fall möglicherweise nicht geeignet sind, wie wir zuvor gezeigt haben. Und manchmal kann dies zu Problemen in Ihrer Logik führen und Ihre Funktion kann nicht mehr wiederverwendet werden. Die Verwendung mehrerer Instanzen kann Ihnen dabei helfen, Ihre Programmstruktur besser zu organisieren, da alle aufgerufenen FBs ihre DBs im aufrufenden Haupt-FB speichern.

Beim Programmieren einer SPS stehen verschiedene Blockstrukturen zur Verfügung. Dazu gehören Funktions-FCs, Funktionsblöcke FBs und Datenblöcke DBs. Diese Blöcke sind sehr praktische Tools, mit denen Sie Ihre SPS-Logik besser gestalten und Ihren Code lesbarer und einfacher nachvollziehbar und debuggbar machen können. In früheren Artikeln haben wir die FCs und FBs besprochen. In diesem Artikel werden wir die Datenblock-DBs besprechen, genauer gesagt den globalen Datenblock. Inhalt: Was ist ein Datenblock-DB? Typen von Datenblöcken. Was ist ein globaler Datenblock? Erstellen eines globalen Datenblocks? Arbeiten mit globalen Datenblöcken. Beispielsimulation. Was ist ein Datenblock? Ein Datenblock-DB ist ein Speicherbereich, der zum Speichern der Werte der Parameter verwendet wird, die während der Ausführung des SPS-Programms geschrieben werden. Im Gegensatz zum Codeblock enthält der Datenblock-DB nur Variablendeklarationen. Er hat keine Netzwerke oder Anweisungen wie ein FC oder ein FB. Die Struktur des DB wird dadurch definiert, wie viele Variablen Sie im Datenblock deklariert haben. Datenblocktypen in der SPS Es gibt zwei Arten von Datenblöcken: Globale Datenblöcke Instanzdatenblöcke ARRAY-Datenblöcke Globale Datenblöcke Wie der Name schon sagt, wird der globale Datenblock global für die gesamte SPS-Logik deklariert. Er ist keinem bestimmten Codeblock zugewiesen. Sie können von jedem Codeblock an beliebiger Stelle in Ihrer SPS-Logik auf die Werte eines globalen Datenblocks zugreifen. Ein globaler Datenblock enthält nur statische Tags. Die Struktur des globalen Datenblocks kann frei definiert werden. In der Deklarationstabelle für Datenblöcke deklarieren Sie die Datenelemente, die im globalen Datenblock enthalten sein sollen. Instanzdatenblöcke Der Instanzdatenblock wird direkt einem Funktionsblock-FB zugewiesen, unabhängig davon, ob dieser Funktionsblock intern in der SPS definiert ist, wie Timer und Zähler, oder ob es sich um benutzerdefinierte Funktionsblöcke (FBs) handelt. Die Struktur eines Instanzdatenblocks kann nicht frei definiert werden, sondern wird durch die Schnittstelle des Funktionsblocks bestimmt. Der Instanzdatenbaustein enthält genau die Bausteinparameter und Variablen, die in der Funktionsbausteinschnittstelle deklariert sind. Sie können im Instanzdatenbaustein jedoch instanzspezifische Werte definieren, z. B. Startwerte für die deklarierten Variablen. ARRAY-Datenbausteine ARRAY-Datenbausteine sind nur für S7-1500-CPUs verfügbar und sind globale Datenbausteine, die aus einem ARRAY bestehen. Dieses ARRAY kann auf einem beliebigen Datentyp basieren. Beispielsweise ist ein ARRAY eines PLC-Datentyps (UDT) möglich. Der DB enthält neben dem ARRAY keine anderen Elemente. Aufgrund ihrer flachen Struktur erleichtern ARRAY-Datenbausteine den Zugriff auf die ARRAY-Elemente und deren Übertragung an aufgerufene Bausteine. Der Abschnitt „Verschiebeoperationen“ der Task Card „Anweisungen“ bietet Möglichkeiten zur Adressierung von ARRAY-DBs. In diesem Artikel werden wir uns mit dem globalen Datenbaustein befassen und die anderen beiden Typen in separaten Artikeln besprechen. Was ist ein globaler Datenbaustein? Datenbausteine werden zum Speichern von SPS-Programmdaten verwendet. Das heißt, sie enthalten variable Daten, die vom Anwenderprogramm verwendet werden. Globale Datenbausteine speichern Daten, die von allen anderen Bausteinen verwendet werden können. Die maximale Größe von Datenbausteinen variiert je nach CPU. Die Struktur globaler Datenbausteine können Sie frei definieren. Sie haben auch die Möglichkeit, PLC-Datentypen (UDT) als Vorlage für die Erstellung globaler Datenbausteine zu verwenden. Jeder Funktionsbaustein FB, jede Funktion FC oder jeder Organisationsbaustein OB kann die Daten aus einem globalen Datenbaustein lesen oder selbst Daten in einen globalen Datenbaustein schreiben. Diese Daten bleiben auch nach Verlassen des Datenbausteins im Datenbaustein erhalten. Siehe Bild 1. Bild 1 – Zugriff auf globalen Datenbaustein Wie Sie dem vorherigen Bild entnehmen können, kann auf einen globalen Datenbaustein von jedem Codebaustein innerhalb des SPS-Programms aus zugegriffen werden, während auf den Instanzdatenbaustein nur der zugehörige Funktionsbaustein zugreifen kann. Erstellen eines globalen Datenbausteins Sie erstellen einen globalen Datenbaustein auf die gleiche Weise wie einen Funktions-FC oder einen Funktionsbaustein FB. Fügen Sie Ihrem Projektbaum einen neuen Block hinzu. Siehe Abbildung 2. Abbildung 2 – Erstellen eines globalen Datenblocks Lassen Sie uns einige Variablen im globalen Datenblock deklarieren. Klicken Sie dazu auf „Neu hinzufügen“ unter „Name“, schreiben Sie den gewünschten Variablennamen und wählen Sie dann den Variablendatentyp aus. Siehe Abbildung 3. Abbildung 3 – Variablendeklaration in einem globalen Datenblock Arbeiten mit einem globalen Datenblock Deklarieren eines Tags. Wir haben bereits in Abbildung 3 gezeigt, wie man ein Tag/eine Variable deklariert. Definieren eines Startwerts Der Startwert eines Tags ist ein von Ihnen definierter Wert, den das Tag nach einem CPU-Start annimmt. Der Wert muss dem Datentyp des Tags entsprechen und sollte den Bereich des Datentyps nicht überschreiten. Siehe Abbildung 4. Das Tag nimmt beim Start den definierten Wert an, sofern es nicht als remanent deklariert wurde. Bild 4 – Definieren des Startwerts Ihrer Tags Wenn ich also den Startwert von Tank1Level auf einen beliebigen Wert ungleich Null setze, wird dieser Wert beim nächsten Neustart der SPS angewendet. Siehe Abbildung 5. Abbildung 5 – Definieren eines Startwerts für Ihre Variablen Beibehalten von Variablen in globalen Datenbausteinen Um Datenverlust bei einem Stromausfall zu verhindern, können Sie die Daten als remanent markieren. Diese Daten werden in einem remanenten Speicherbereich gespeichert. Die Optionen zum Einstellen des Retains hängen von der Art des Datenbausteins und der Art des eingestellten Bausteinzugriffs ab. Siehe Abbildung 6. Abbildung 6 – Beibehaltungsoption in globalen Datenbausteinen Wie Sie in Abbildung 6 sehen, ist die Variable Tank2Level auf einen Retain-Wert eingestellt, was bedeutet, dass selbst wenn die SPS angehalten hat oder es einen Stromausfall gab, Tank2Level dieselben Daten gespeichert hat, wenn die SPS wieder eingeschaltet wird. Es wird nicht auf den Startwert zurückgesetzt. Zugriff auf/von HMI In einem globalen Datenblock können Sie festlegen, ob eine Variable in den HMI-Tag-Tabellen sichtbar sein kann oder nicht. Sie können auch festlegen, ob diese Variable vom HMI gelesen oder geschrieben werden kann. Siehe Abbildung 7. Abbildung 7 – Zugriff vom HMI Die Standardeinstellung für jede deklarierte Variable in einem globalen Datenblock ist, dass sie vom HMI aus aufgerufen, gelesen und geschrieben werden kann. Wenn Sie diese Funktion für eine bestimmte Variable deaktivieren möchten, müssen Sie die Zugriffsoption für diese Variable deaktivieren. Beispielsimulation Bisher haben wir einen globalen Datenblock erstellt und einige Variablen darin deklariert. Jetzt werden wir versuchen, eine Simulation des Programms auszuführen und zu sehen, ob wir besser verstehen können, was ein globaler Datenblock ist. Nachfolgend sind zwei SPS-Simulationen aufgeführt. Testen der Startwerte einer Variablen Sehen Sie sich die folgende Animation an, die den Startwert einer Variablen in einem globalen Datenblock erklärt. Animation 1 Animation 1 Erklärung: Die Startwerte der Tankfüllstandsparameter sind Null, Sie können im Video sehen, dass sie durch den Simulationsbildschirm geändert werden. Wenn die SPS neu gestartet, aus- und wieder eingeschaltet wird, sehen Sie, dass die Werte auf die Startwerte zurückgesetzt werden, die Null sind. Danach wurden die Startwerte auf 500, 32654 bzw. -356 geändert, und beim Neustart der SPS wurden die Werte auf die neuen Startwerte geändert. Beachten Sie, dass wir beim Ändern der Startwerte unsere Logik erneut auf die SPS herunterladen mussten; Sie müssen das jedes Mal tun, wenn Sie eine Änderung an Ihrer Logik vornehmen. Testen der Beibehaltungsoption von Variablen in der globalen Datenbank Sehen Sie sich die folgende Animation an, die die Beibehaltungsoption einer Variablen in einem globalen Datenblock erklärt. Animation 2 Animation 2 Erklärung: Zuerst werden Sie feststellen, dass die Eigenschaft „Retain“ von Tank2Level jetzt aktiv ist. Sie sehen im Video, wie die Werte der 3 Tanks geändert werden. Wenn die SPS angehalten und dann wieder gestartet wird, werden Tank1Level und Tank3Level auf den Startwert 0 zurückgesetzt, aber Tank2Level behält seinen Wert von -22938. Fazit Auf einen globalen Datenblock kann von überall und von jedem Block aus zugegriffen werden, der im SPS-Programm vorhanden ist. Sie können in einer globalen Datenbank so viele Variablen deklarieren, wie Sie möchten. Die bewährte Vorgehensweise besteht darin, separate Datenblöcke für die verschiedenen Abschnitte Ihrer Logik zu erstellen, damit Ihre Logik sehr einfach zu befolgen ist. Beispielsweise ein separater Datenblock für alle Variablen, die von einer HMI gelesen oder geschrieben werden müssen.

Im vorherigen Artikel haben wir über Datenblöcke gesprochen und die zwei verschiedenen Arten von Datenblöcken besprochen, den globalen Datenblock und die Dateninstanzen von Funktionsblöcken FBs. In diesem Artikel werden wir besprechen, was mit optimiertem Datenblockzugriff und standardmäßigem Datenblockzugriff im Siemens Tia Portal gemeint ist. Inhalt: Was sind optimierte und standardmäßige Datenblöcke? Einfaches Programmbeispiel. Was sind Standard-DBs? Was ist der Offset? Was sind optimierte DBs? Vorteile der Verwendung optimierter DBs. Schlussfolgerungen. Was ist optimierter und standardmäßiger Datenblockzugriff? Erstens sind dies keine neuen Arten von Datenblöcken; wir sagten, wir haben nur zwei verschiedene Arten, den globalen DB und den Instanz-DB. Optimierter Datenblockzugriff ist eine Funktion für den Datenblock. Sie können diese Funktion in den Eigenschaften des von Ihnen erstellten Datenblocks aktivieren oder deaktivieren. Die optimierte Datenblockfunktion ist nur für S7-1200- und S7-1500-SPS verfügbar, nicht für S7-300 oder S7-400. Die Standardeinstellung für Datenblöcke bei der Arbeit mit S7-1200- oder S7-1500-SPS ist, dass sie optimiert sind. Wenn Sie einen Standarddatenblock möchten, müssen Sie diesen selbst festlegen. Was sind also optimierte und Standardblöcke? Um den Unterschied zu verstehen, erstellen wir ein einfaches Programm und versuchen zu zeigen, wie sich ein optimierter Block von einem Standardblock unterscheidet. Einfaches Programmbeispiel: In diesem Beispiel erstellen wir keine SPS-Logik und codieren keine Anweisungen. Wir erstellen nur zwei globale Datenblöcke. DB1 wird OptimizedDB und DB2 StandardDB genannt. In beiden Datenblöcken deklarieren wir jeweils vier Variablen der Datentypen Bool, Int, Real und Word. Siehe Bild 1. Bild 1 – Zwei globale DBs erstellen Als Erstes werden Sie feststellen, dass beide Datenblöcke genau gleich sind. Das liegt daran, dass die Standardeinstellung beim Erstellen eines Datenblocks, wie gesagt, die Optimierung ist. Wir müssen also die Einstellung von DB2 ändern, um daraus einen Standardblock zu machen und zu sehen, ob sich etwas ändert. Wir tun das über die Eigenschaften dieses DB2. Sie greifen auf die Eigenschaften von DB2 zu, indem Sie mit der rechten Maustaste auf den Datenblock klicken und auf Eigenschaften drücken. Siehe Bild 2. Bild 2 – DB2 auf Standardblockzugriff ändern Sobald Sie die in Bild 2 gezeigten optimierten Blockzugriffsattribute abwählen und auf OK drücken, wird eine Warnmeldung angezeigt, siehe Bild 3. Bild 3 – Popup „Blockzugriff ändern“ Sobald Sie auf OK drücken, wird Ihr DB2 auf Standardblockzugriff umgestellt. Siehe Bild 4. Um zu sehen, welchen Unterschied das gemacht hat. Bild 4 – DB2 ist jetzt ein Standardblock Was wir direkt sehen können, ist, dass DB1 und DB2 nicht mehr dasselbe sind. Die in DB2 dargestellte Standardblockzugriffsoption hat eine zusätzliche Spalte namens Offset. Vor jeder Variable im Offset-Feld steht ein … geschrieben, dies ändert sich, sobald Sie Ihr Programm kompilieren. Lassen Sie uns kompilieren und sehen, was passiert, siehe Bild 5. Bild 5 – Kompilieren Sie Ihr Programm, um den Offset neu zu laden Jetzt wird der Offset mit 0,0, 2,0, 4,0 bzw. 8,0 ausgefüllt, wie Sie sehen können. Also, was ist dieser Offset? Was bedeutet er? Darauf kommen wir später zurück, aber jetzt erstellen wir einen weiteren STANDARD-Block und deklarieren dieselben 4 Variablen, aber dieses Mal ändern wir die Reihenfolge der variablen Datentypen, siehe Bild 6. Bild 6 – Einen weiteren Standardblock DB3 erstellen Sie sehen im letzten Bild, dass der Offset von DB2 und DB3 unterschiedlich ist. Warum sind die Offsetwerte unterschiedlich, als wir die Reihenfolge der Datentypen geändert haben? Es sind dieselben Datentypen, aber in anderer Reihenfolge. Erstellen wir einen weiteren Standard-DB und deklarieren dieselben 4 Variablen, aber wieder in anderer Reihenfolge. Kompilieren Sie Ihren SPS-Code und vergleichen Sie nun den Offset der 3 DBs. Siehe Bild 7. Bild 7 – Drei verschiedene DBs mit drei verschiedenen Offsets Das Gleiche passierte erneut. Was sind Standard-DBs? Was ist der Offset? Datenblöcke mit Standardzugriff haben eine feste Struktur. Wenn Sie eine Variable in einem Standard-DB deklarieren, wird dieser Variable eine feste Adresse in diesem DB zugewiesen. Die Adresse dieser Variable wird in der Spalte „Offset“ angezeigt. Was wir also in den vorherigen Bildern im Offset gesehen haben, war die jeder Variable zugewiesene Adresse. Da die Struktur von Standard-DBs fest ist, können Sie nur in DBs mit fester Speicherkapazität arbeiten, d. h. einem 16-Bit-Bereich oder 2 Bytes. Dies ist der Grund für die unterschiedliche Adressierung derselben Variablen, wenn wir die Deklarationsreihenfolge geändert haben. Weitere Erklärungen finden Sie in Bild 8. Bild 8 – Einfache Darstellung von DB2 Bild 8 zeigt eine einfache Darstellung des Standarddatenblocks DB2. Wie bereits erwähnt, hat ein Standard-DB feste Speicherblöcke von 16 Bit. Wenn wir also Variable_1 als Datentyp BOOL deklarieren, belegt diese Variable die gesamten 16 Bit, obwohl sie nur 1-Bit-Speicher benötigt. Deshalb sehen Sie den Rest des Bereichs rot markiert, da er nicht verwendet wird, aber nicht mehr verwendet werden kann. Es handelt sich also um verlorenen Speicher. Bei Variable_2 benötigt der Datentyp INT 16 Bit, sodass 2 ganze Bytes verwendet werden. Dasselbe gilt für Variable_4, die vom Datentyp WORD ist. Bei Variable_3 belegten wir 4 Bytes, da sie vom Datentyp REAL ist. Deshalb beträgt der Offset für DB2 jeweils 0,0, 2,0, 4,0 und 8,0. Dasselbe Konzept wird für DB3 und DB4 ausgeführt. Da jedoch die Datentypreihenfolge der Variablen unterschiedlich ist, ist die Speicherdarstellung unterschiedlich und daher auch der Offset unterschiedlich. Sehen Sie sich die Bilder 9 und 10 für DB3 und DB4 an. Versuchen Sie, die Darstellung anhand der vorherigen Erklärung zu verstehen. Bild 9 – Speicherdarstellung von DB3 Bild 10 – Speicherdarstellung von DB4 Wenn Sie also mit einer Standard-DB arbeiten, müssen Sie beim Deklarieren Ihrer Variablen vorsichtig sein, da Sie wissen, dass jedes Mal, wenn Sie eine neue BOOL-Variable definieren, Speicher verloren geht. Wenn Sie die neue Variable am Ende Ihrer DB-Liste deklarieren, wird der Offset erweitert, um Ihre neue Variable einzuschließen. Wenn Sie die neue Variable jedoch zwischen Ihrer alten oder am Anfang der DB deklarieren, geschieht etwas anderes. Siehe Bild 11. Bild 11 – Deklarieren einer neuen Variable Als Erstes werden Sie feststellen, dass Ihr Offset jetzt verloren ist und Sie Ihren Code kompilieren müssen, um den neuen Offset wiederherzustellen. Siehe Bild 12. Bild 12 – Stellen Sie Ihren Offset wieder her, indem Sie Ihren Code neu kompilieren Ist Ihnen aufgefallen, wie sich die Adressierung der Variablen (OFFSET) geändert hat? Beispielsweise war der Offset des REAL-Tags 2,0, aber nachdem wir die neue Testvariable hinzugefügt haben, ist die Adressierung desselben REAL-Tags (OFFSET) jetzt 4,0, siehe Bild 13. Bild 13 – Offset-Änderung nach dem Hinzufügen der Testvariable Beim Hinzufügen einer neuen Variable wurde also die Adressierung aller alten Variablen geändert. Das bedeutet, dass jede Anweisung in Ihrem Programm, die den Wert einer bestimmten Variable schreiben oder lesen muss, jetzt die zugewiesene Adresse in der Anweisung betrachtet, aber jetzt hat die Adresse andere Daten als erwartet. Einfach ausgedrückt ist Ihre gesamte Logik jetzt durcheinander. Das wird zu einer Menge Ärger führen. Ganz zu schweigen davon, dass Sie jetzt zusätzlichen Speicher verloren haben, nachdem Sie die neue Variable hinzugefügt haben. Siehe Bild 14. Bild 14 – Hinzufügen einer MOVE-Anweisung Fügen wir eine MOVE-Anweisung hinzu, um einen Wert von 1 in das Tag Variable_2 zu verschieben. Sehen Sie, dass die Adresse der MOVE-Ausgabe %DB2.DBW2 lautet. Fügen wir nun eine neue Variable vom Typ INT zu DB2 hinzu. Siehe Bild 15. Bild 15 – Neue INT-Variable hinzufügen Wenn Sie die neue Variable hinzufügen, geht der Offset verloren und die SPS weiß nicht mehr, wo das Ziel von OUT1 der MOVE-Anweisung ist. Wir müssen das Programm kompilieren, um den neuen Offset neu zu laden. Siehe Bild 16. Bild 16 – Neue Adresse von OUT1 Sehen Sie, wie sich die OUT1-Adresse jetzt geändert hat? Es ist jetzt %DB2.DBW4 statt %DB2.DBW2. Dies ist ein sehr großer Nachteil bei der Verwendung von Standarddatenblöcken. Was sind optimierte DBs? Der Unterschied zwischen optimierten Datenblöcken und Standarddatenblöcken besteht darin, dass Variablen in einem optimierten Datenblock keiner festen Adresse zugewiesen werden, sondern den Variablen ein symbolischer Name zugewiesen wird. Außerdem ist die Struktur des Datenblocks nicht so festgelegt wie bei den Standarddatenblöcken, sodass beim Deklarieren neuer Tags kein Speicherverlust auftritt und die Adressen nicht geändert werden. Siehe Abbildung 17. Abbildung 17 – Deklarieren neuer Tags in optimierten Blöcken Das Deklarieren neuer Tags in optimierten Datenblöcken wirkt sich also nicht auf die übrigen Tags aus, da diese durch symbolische Namen und nicht durch absolute Adressierung definiert werden. Ein optimierter Datenblock erlaubt Ihnen nicht, Adressen zu verwenden, wenn Sie mit den darin definierten Tags arbeiten. Siehe Bild 18. Bild 18 – Absolute Adressierung bei optimierten Bausteinen Wie Sie im letzten Bild sehen, ist bei einem optimierten Datenbaustein keine absolute Adressierung erlaubt und nur symbolische Namen sind zulässig. Siehe Bild 19. Bild 19 – Verwendung symbolischer Namen bei optimierten DBs Vorteile von Datenbausteinen mit optimiertem Zugriff Datenbausteine mit optimiertem Zugriff haben keine fest definierte Struktur. Den Datenelementen (Tags) wird nur ein symbolischer Name zugewiesen und es wird keine feste Adresse innerhalb des Bausteins verwendet. Die Elemente werden automatisch im verfügbaren Speicherbereich des Bausteins gespeichert, so dass keine Lücken im Speicher entstehen. Dadurch wird die Speicherkapazität optimal ausgenutzt und Speicherverlust im Vergleich zu Standard-DBs vermieden. Dadurch ergeben sich folgende Vorteile: Sie können Datenbausteine mit beliebiger Struktur erstellen, ohne auf die physikalische Anordnung der einzelnen Variablen zu achten. Ein schneller Zugriff auf die optimierten Daten ist jederzeit möglich, da die Datenablage vom System optimiert und verwaltet wird. Zugriffsfehler, wie beispielsweise bei indirekter Adressierung oder vom HMI aus, sind nicht möglich. Denn es gibt keine Adressen, sondern nur eindeutige symbolische Namen für jede Variable. Sie können bestimmte einzelne Variablen als remanent definieren. In Standard-DBs können Sie nur den gesamten Baustein als remanent definieren. Fazit Optimierte Datenbausteine haben viele Vorteile gegenüber Standard-DBs. Durch die Verwendung symbolischer Namen können Adressänderungen von Variablen vermieden werden, wenn Sie Ihrem Baustein neue Variablen hinzufügen. Bei optimierten Bausteinen geht kein Speicherbereich verloren. Ganz im Gegensatz zu dem, was bei der Verwendung von Standard-DBs passiert.

In früheren Artikeln haben wir über Timer in SPS, verschiedene Typen und ihre Verwendung gesprochen. Timer benötigen nicht unbedingt Echtzeit, um zu funktionieren, da sie je nach Ihren Einstellungen nur Sekunden oder Millisekunden zählen. Für einige Anwendungen müssen Sie jedoch das tatsächliche Datum und die tatsächliche Uhrzeit des SPS-Programms kennen, beispielsweise zu Diagnosezwecken. In diesem Artikel sprechen wir über die System- und Ortszeit einer SPS. Inhalt: Warum brauche ich Echtzeit in der SPS? Beispielprogramm und Simulation Was ist Systemzeit? Was ist Ortszeit? Schlussfolgerungen. Warum brauche ich Echtzeit in der SPS? In vielen Anwendungen von SPS müssen Sie aus vielen verschiedenen Gründen die Echtzeit kennen, während der Prozess ausgeführt wird. Im Folgenden sind einige dieser Gründe aufgeführt: Sicherung der SPS auf dem Hauptserver. Für die Diagnose der SPS benötigen Sie eine Zeitaufzeichnung, um zu wissen, zu welcher Zeit ein bestimmtes Ereignis aufgetreten ist. Andernfalls wären die Diagnoseinformationen nicht sehr nützlich. Für Anwendungen, bei denen Sie mit den Tageszeitinterrupts OB10 arbeiten müssen, müssen Sie die tatsächliche Uhrzeit kennen. Möglicherweise müssen Sie in Teilen Ihrer Logik, in denen Sie Echtzeitanwendungen verarbeiten müssen, die Ortszeit oder die Systemzeit verwenden. Für die Datenprotokollierung: Wenn Sie wichtige Daten speichern müssen und den Zeitstempel für jede Datenaufzeichnung benötigen, müssen Sie die richtige Zeiteinstellung für Ihre SPS haben, damit die gespeicherten Daten sinnvoll sind. Beispielprogramm und Simulation einer SPS Um besser zu verstehen, was Systemzeit und Ortszeit in einer SPS sind, erstellen wir zunächst ein sehr einfaches Programm und erklären damit das Konzept der Echtzeit in SPSen. Überprüfen Sie den folgenden Schritt: In diesem Artikel erstellen wir keine SPS-Logik, sondern zeigen einige Konfigurationen, die sich auf die System- und Ortszeit in der SPS beziehen, wie diese eingestellt werden und was die Unterschiede sind. Öffnen Sie das Siemens Tia Portal, fügen Sie ein neues Gerät hinzu und dieses Mal verwenden wir die CPU 1512C-1 PN. Siehe Bild 1. Bild 1 – Neue SPS hinzufügen Kompilieren und starten Sie eine neue SPS-Simulation. Öffnen Sie die Online- und Diagnoseseite und überprüfen Sie die eingestellte Zeit der SPS. Siehe Bild 2. Bild 2 – Onlinezeit der SPS Aus dem vorherigen Bild können Sie erkennen, dass es zwei verschiedene Zeiten gibt: Die PG/PC-Zeit – dies ist die lokale Zeit Ihres PCs selbst. Die Modulzeit – dies ist die tatsächliche Zeit innerhalb der SPS selbst. Beide Zeiten können auf denselben Wert eingestellt werden oder sie können unterschiedlich sein. Am besten ist es, sie gleich zu machen, es ist besser, die Modulzeit ähnlich Ihrer lokalen Zeit zu machen, oder genauer gesagt ähnlich der lokalen Zeit des Gebiets, in dem die SPS verwendet wird. Siehe Bild 3. Bild 3 – Zeit der SPS einstellen Wenn Sie möchten, dass die Modulzeit mit der Ortszeit übereinstimmt, wählen Sie „Von PG/PC übernehmen“ und drücken Sie „Anwenden“. Ziehen Sie in Ihrem Haupt-OB1 die Anweisungen RD_SYS_T und RD_LOC_T per Drag & Drop. Dies sind die Anweisungen zum Lesen der Systemzeit und zum Lesen der Ortszeit. Diese Anweisungen sind integrierte Funktions-FCs in der SPS und werden verwendet, um die Ortszeit und die Systemzeit der SPS an das von Ihnen im Ausgang OUT der Anweisung gewählte Ziel zu schreiben. Siehe Bild 4. Bild 4 – Anweisungen zum Lesen der System- und Ortszeit hinzufügen Fügen Sie einen neuen globalen Datenblock hinzu und definieren Sie einige Tags, mit denen gearbeitet werden soll. Siehe Bild 5. Bild 5 – Einen neuen globalen Datenblock erstellen Führen Sie Ihre Simulation erneut aus und überprüfen Sie beide Male. Siehe Bild 6 Bild 6 – Online-Lokalzeit und Systemzeit der SPS Sie sehen im vorherigen Bild, dass die Lokalzeit und die Systemzeit der SPS gleich sind, sich aber von der tatsächlichen Lokalzeit Ihres PCs unterscheiden. Wie Sie sich erinnern, haben wir die Modulzeit der SPS so eingestellt, dass sie der PG/PC-Zeit ähnelt, also Ihrer Lokalzeit. Siehe Bild 7. Bild 7 – Modulzeit und PG/PC-Zeit Wie Sie sehen, wird auf der Seite „Zeit einstellen“ die Modulzeit so gewählt, dass sie der PG/PC-Zeit entspricht. In tatsächlichen Fällen sind sie jedoch unterschiedlich. Warum? Warum sind die Zeiten unterschiedlich? Da die Standardeinstellung der Lokalzeit der SPS UTC+0 oder Zulu-Zeit ist, wenn Sie mit diesem Begriff vertraut sind, ändern Sie sie nicht auf der Online- und Diagnoseseite, sondern in den Eigenschaften der SPS selbst. Siehe Bild 8. Bild 8 – Tageszeitkonfiguration in einer SPS Wie Sie sehen, ist die Standardeinstellung der SPS-Tageszeit auf UTC+0 eingestellt, und deshalb unterschied sich die Zeit des SPS-Moduls von Ihrer tatsächlichen Ortszeit. Außer wenn Sie tatsächlich in London wären, hätten Sie dieses Problem nicht. Um die lokale SPS-Zeit zu korrigieren, müssen wir das in der Konfiguration ändern, wir müssen die Zeitzone auf die Zeitzone ändern, die wir haben, was in meinem Fall UTC+02:00 ist. Siehe Bild 9. Bild 9 – Anpassen der lokalen SPS-Zeit an Ihre Zeitzone Sie können auch sehen, dass die Sommerzeitoption deaktiviert wurde, da sie in meinem Land nicht verwendet wird. Sie müssen sie aktivieren, wenn sie in Ihrer Region verwendet wird. Nachdem nun alle Konfigurationen richtig eingestellt sind, gehen Sie zurück und sehen Sie sich die lokale Zeit und die Systemzeit erneut in der Simulation an. Siehe Abbildung 10. Abbildung 10 – Die lokale Zeit der SPS ist jetzt dieselbe wie die des PCs Sie sehen nun, dass nach dem Anpassen der SPS-Zeitzone die lokale Zeit der SPS und die tatsächliche lokale Zeit Ihrer Region identisch sind. Wie wir bereits gesagt haben, ist es aus den vielen oben genannten Gründen sehr wichtig, die richtige lokale Zeit der SPS einzustellen. Können Sie nun definieren, was die Systemzeit und die lokale Zeit der SPS ist? Systemzeit in der SPS Ist die Modulzeit der CPU-Uhr. Die CPU-Uhr interpretiert die Modulzeit als koordinierte Weltzeit (UTC). Dementsprechend wird die Modulzeit immer ohne die Faktoren „lokale Zeitzone“ oder „Sommerzeit“ in der CPU-Uhr gespeichert. Die CPU-Uhr berechnet dann aus der Modulzeit die lokale Zeit der CPU-Uhr. Die Modulzeit der CPU-Uhr dient als Vorlage für alle Zeitprozesse, die von der CPU ausgehen. Anwendungsbeispiele: Berechnung der lokalen Zeit der CPU-Uhr aus der Modulzeit Darstellung der Modulzeit in lokaler Zeit unter „Online & Diagnose“ Einträge im Diagnosepuffer der CPU Lokale Zeit in der SPS Informationen über die Zeitzone und den Beginn von Sommer- und Winterzeit, die Sie in der Konfiguration der CPU-Uhr eingestellt haben, werden zur Ausgabe der lokalen Zeit verwendet. Die lokale Zeit ist die Zeit, die Sie auf Ihrem PC oder in Ihrem Land haben und die von Region zu Region unterschiedlich sein kann. Fazit Viele Anwendungen erfordern, dass die SPS die Echtzeit oder lokale Zeit des Prozesses kennt, damit sie bestimmte Aufgaben ausführen kann, z. B. Datenprotokollierung und Diagnoseaufgaben. In einem zukünftigen Artikel zeigen wir einige Anwendungen, bei denen Echtzeit für Ihre Logik erforderlich ist. Die lokale Zeit der SPS sollte manuell konfiguriert werden, damit sie mit dem Bereich übereinstimmt, in dem die SPS verwendet wird.

In früheren Artikeln haben wir verschiedene Arten von Bausteinen im SIEMENS TIA-Portal besprochen, wir haben über Funktionsbausteine FBs, Funktionen FCs und Datenbausteine DBs gesprochen. In diesem Artikel werden wir uns mit einem anderen Bausteintyp in SIEMENS-SPS befassen, nämlich den Organisationsbausteinen, und in diesem Artikel werden wir den wichtigsten Organisationsbaustein von allen besprechen, nämlich den Hauptorganisationsbaustein oder OB1. Inhalt: Was sind Organisationsbausteine? Verschiedene Arten von OBs. Was ist OB1? Zykluszeitüberwachung. Ein einfaches Programmbeispiel. Fazit. Was ist ein Organisationsbaustein (OB)? Organisationsbausteine können Sie sich als Funktionen FCs oder Funktionsbausteine FBs vorstellen. Der Unterschied besteht jedoch darin, dass Sie sie nicht aufrufen, sondern das Betriebssystem der SPS diese Organisationsbausteine aufruft. Ob das Betriebssystem den OB zyklisch als OB1 aufruft oder ob er aufgerufen wird, wenn ein bestimmtes Ereignis eintritt, in jedem Fall kümmert sich das Betriebssystem darum. Sie müssen nur den Block erstellen und die gewünschte Logik in den Block einfügen. Manchmal müssen Sie nicht einmal Code in den OB einfügen. Allein das Erstellen des OB selbst kann viele Vorteile bieten, die wir bei der Erörterung einiger dieser OBs sehen werden. Organisationsblöcke sind die Schnittstelle zwischen dem SPS-Betriebssystem und dem Benutzerprogramm. Jede SPS hat zwei verschiedene Programme, das Laufzeitprogramm, das das Betriebssystem der SPS ist, und das Benutzerprogramm, das die Logik oder den Code darstellt, den der SPS-Programmierer zur Steuerung eines bestimmten Prozesses schreibt. Diese beiden verschiedenen Softwareprogramme müssen miteinander kommunizieren, und dies geschieht über die Organisationsblöcke (OBs). Organisationsblöcke (OBs) werden zum Ausführen vieler Aufgaben verwendet, von denen einige unten aufgeführt sind: Starteigenschaften des Automatisierungssystems Zyklische Programmverarbeitung Interruptgesteuerte Programmausführung Fehlerbehandlung. Verschiedene Arten von Organisationsblöcken Organisationsblöcke sind im Grunde die Werkzeuge des Betriebssystems zum Ausführen vieler Aufgaben. Verschiedene Aufgaben erfordern unterschiedliche OBs, und deshalb gibt es in einer SPS viele verschiedene OBs. Wie viele verschiedene OBs es sind, hängt vom Typ der von Ihnen verwendeten SPS ab. Hier sind jedoch einige der häufigsten OBs, die Sie in fast allen SIEMENS-SPS finden können: Zyklischer Haupt-OB1. Zeitalarm-OBs. Tageszeit-OBs. Softwarefehler-OBs. Hardwarefehler-OBs Viele weitere Organisationsblöcke stehen zur Verwendung mit Ihrer Logik zur Verfügung. Siehe Abbildung 1. Abbildung 1 – Verschiedene Organisationsblöcke, die im TIA-Portal verfügbar sind In diesem Artikel besprechen wir den wichtigsten Organisationsblock von allen, nämlich den zyklischen Haupt-Interrupt-OB1. Zyklischer Haupt-Interrupt-OB1 Der zyklische Haupt-OB1 ist der Organisationsblock, der für die zyklische Ausführung Ihrer Logik durch die SPS verantwortlich ist. Immer wenn Sie ein neues Projekt erstellen und eine SPS hinzufügen, wird der Haupt-OB1 automatisch von der Software erstellt. Dies sind die mindestens erforderlichen Blöcke für einen SPS-Code. Siehe Abbildung 2. Abbildung 2 – Haupt-OB1 wird automatisch erstellt In diesem Haupt-OB1 können Sie entweder Ihr gesamtes SPS-Programm schreiben, wenn es sich um ein kleines Projekt handelt. Wenn Ihr Projekt ziemlich groß ist, haben Sie wahrscheinlich einige Funktionen FCs oder Funktionsblöcke FBs, die Sie ausführen müssen. In diesem Fall verwenden Sie den Haupt-OB1, um sie aufzurufen. Natürlich müssen Sie nicht jeden FC oder FB über den OB1 aufrufen, aber wenn Ihr OB1 nicht der erste Block Ihrer Verschachtelungsaufrufe ist, wird er nicht ausgeführt. Siehe Abbildung 3. Abbildung 3 – Aufrufen Ihrer Blöcke über OB1 Die wesentliche Grundlage Ihres SPS-Codes ist das zyklische Verhalten, d. h. Ihr Code muss kontinuierlich ausgeführt werden. Wenn die Verarbeitung Ihrer Logik abgeschlossen ist, beginnt das Betriebssystem erneut mit der Verarbeitung. Dies geschieht durch die Verwendung des Haupt-OB1. Sie platzieren und rufen Ihre gesamte Logik und Ihren Code in diesem OB1 auf und das Betriebssystem sorgt dafür, dass er kontinuierlich ausgeführt wird. Sie sollten wissen, dass Sie, auch wenn Sie keinen OB1-Block erstellen können, da dieser automatisch beim Hinzufügen einer neuen SPS erstellt wird, mehr als einen zyklischen Interruptblock erstellen können. OB1 ist ein zyklischer Interrupt, den das Betriebssystem automatisch und kontinuierlich aufruft und die darin enthaltene Logik ausführt. Bei großen SPS-Projekten, bei denen Ihre SPS-Logik viele Funktionen und Funktionsblöcke enthält, können Sie jedoch mehr als einen zyklischen Interrupt-OB verwenden, um Ihren Code besser zu strukturieren und ihn leichter lesbar und nachvollziehbar zu machen. In diesem Fall würden Sie einen weiteren zyklischen Interrupt erstellen, siehe Abbildung 4. Abbildung 4 – Erstellen von mehr als einem zyklischen OB Wenn Sie mehrere Programmzyklus-OBs erstellt haben, werden diese nacheinander in der Reihenfolge ihrer OB-Nummern aufgerufen. Der Programmzyklus-OB mit der niedrigsten OB-Nummer wird zuerst aufgerufen. Siehe Abbildung 5. Abbildung 5 – Programmzyklus mit mehr als einem zyklischen OB Nach Abschluss des zyklischen Programms aktualisiert das Betriebssystem die Prozessabbilder wie folgt: Es schreibt die Werte vom Prozessabbild der Ausgänge in die Ausgangsmodule. Es liest die Eingänge an den Eingangsmodulen und überträgt diese in das Prozessabbild der Eingänge. Die beiden vorherigen Schritte sowie die Ausführung des SPS-Programms werden als Scan-Zyklus bezeichnet. Siehe Abbildung 6. Abbildung 6 – Scan-Zyklus einer Siemens-SPS Zykluszeitüberwachung Die Zykluszeit bezieht sich auf die Laufzeit des zyklischen Programms, einschließlich der Laufzeit aller verschachtelten Programmteile wie FCs, FBs und höherpriorer OBs. Wenn Sie mehrere Programmzyklus-OBs erstellt haben, trägt jeder Programmzyklus-OB zur Zykluszeit bei. Das Betriebssystem überwacht, ob die Zykluszeit kleiner als die konfigurierte maximale Zykluszeit bleibt. Wenn die maximale Zykluszeit überschritten wird, wechselt die SPS je nach Programmierung entweder in den STOP-Modus oder ruft OB80 auf. Neben der Überwachung der maximalen Zykluszeit ist es auch möglich, eine minimale Zykluszeit zu garantieren. Dazu verzögert das Betriebssystem den Start eines neuen Zyklus, bis die Mindestzykluszeit erreicht ist. Sie können die Mindest- und Höchstzykluszeit in den Konfigurationseigenschaften Ihrer SPS konfigurieren. Siehe Abbildung 7. Abbildung 7 – Konfigurieren der Mindest- und Höchstzykluszeit Einfaches Programmbeispiel in der SPS Abbildung 8 – SPS-Programmbeispiel Um den SPS-Programmzyklus und die OB1-Ausführung besser zu verstehen, erstellen wir ein einfaches Programm. Dieses Programm verwendet eine Additionsanweisung, die in jedem Scanzyklus einen Wert von 1 in einem Speicherbereich akkumuliert. Siehe die folgende Simulation. Wie Sie in der Animation sehen, wird die Additionsanweisung sehr schnell ausgeführt; so schnell ist der Scanzyklus. Dies hängt davon ab, wie leistungsstark Ihre SPS ist. Aber hauptsächlich liegt der Scanzyklus im Bereich von Millisekunden. Fazit Organisationsblöcke sind die Schnittstelle zwischen dem SPS-Betriebssystem und Ihrem Steuerungsprogramm. Der Haupt-Zyklische-OB1 wird zyklisch vom Betriebssystem ausgeführt. Sie führen Ihre Logik aus, indem Sie sie in einen oder mehrere Zyklische-OBs einbinden. Die Scan-Zykluszeit ist die Zeit, die zum Ausführen Ihrer Logik 1 Mal benötigt wird.

In einem früheren Artikel haben wir besprochen, was ein Organisationsblock ist, und wir haben über einen sehr wichtigen Organisationsblock gesprochen, nämlich den Haupt-OB1. In diesem Artikel werden wir die verschiedenen OBs weiter besprechen und dieses Mal sprechen wir über die Tageszeit-Interrupt-Organisationsblöcke oder OB10. Inhalt: Was ist der Tageszeit-Interrupt OB10? Wie erstellt und verwendet man OB10? Einfaches Programmbeispiel. Wichtige Regeln für Tageszeit-Interrupts. Schlussfolgerungen. Was ist ein Tageszeit-Interrupt (OB10)? Wie der Name schon sagt, ist ein Tageszeit-Interrupt ein Organisationsblock, der die Ausführung des Hauptzyklus Ihres SPS-Programms zu einer bestimmten Tageszeit unterbricht. Diese Interrupt-Zeit (Datum und Uhrzeit) kann so angegeben werden, dass sie einmal zu einer bestimmten Zeit oder regelmäßig in bestimmten Zeitintervallen auftritt, z. B. jede Minute, Stunde, jeden Tag, jede Woche und einige andere Optionen. Sie können mehr als einen Tageszeit-Interrupt im selben Programm haben. Sie müssen nicht dieselbe Logik oder denselben Code haben, jeder kann seine eigene Funktionalität haben und jeder kann separat so konfiguriert werden, dass er zu einer bestimmten Zeit auftritt. Wie erstelle und verwende ich OB10? Um einen Tageszeit-Interrupt zu erstellen, folgen Sie denselben Schritten, die Sie ausführen würden, wenn Sie einen neuen Block in Ihre Logik einfügen müssen. Siehe Abbildung 1. Abbildung 1 – Einen Tageszeit-Interrupt hinzufügen Klicken Sie im Projektbaum links auf die Option „Neuen Block hinzufügen“, wählen Sie den Organisationsblock und dann einen Tageszeit-Interrupt, wie im vorherigen Bild gezeigt. Jetzt können Sie OB10 öffnen und die SPS-Logik hinzufügen, die Sie ausführen möchten, wenn dieser Block aufgerufen wird. Mit „aufgerufen“ meinen wir, dass das Interrupt-Ereignis oder die Interrupt-Zeit aufgetreten ist und das Betriebssystem daher den Hauptzyklus unterbricht und OB10 ausführt. Wir werden einen sehr einfachen Code in OB10 schreiben, um besser zu verstehen, wie dieser OB10-Block funktioniert. In dieser Logik haben wir den Add-Befehl verwendet, um einem Speicherbereich, den wir TimeOfDayInterruptCounter genannt haben, einen Wert von 1 hinzuzufügen und das Ergebnis der Summierung dann wieder in denselben Bereich zu schreiben. Auf diese Weise können wir einen Zähler für die Ausführung des OB10 haben. Jedes Mal, wenn der OB10 aufgerufen und ausgeführt wird, erhöht sich der Wert von TimeOfDayInterruptCounter um 1. Siehe Bild 2. Bild 2 – Fügen Sie Ihre Logik zum OB10 hinzu Nachdem wir nun den OB10 erstellt und etwas Logik hineingeschrieben haben, müssen wir die eingestellte Zeit des OB10 konfigurieren und festlegen, wie oft er unseren Hauptzyklus unterbrechen soll. Um die Zeit- und Intervalleinstellung des OB10 zu konfigurieren, müssen wir zur Eigenschaftenseite des OB10 gehen. Siehe Bild 3. Bild 3 – Eigenschaften von OB10 In den Eigenschaften von OB10 finden Sie viele Einstellungen und Attribute, die Sie konfigurieren können. Was wir jetzt brauchen, ist die Seite mit den Tageszeit-Interrupts, damit wir festlegen können, wann und wie oft OB10 aufgerufen wird. Siehe Bild 4. Bild 4 – Einstellung der Tageszeit-Interrupts Wie Sie im letzten Bild sehen, können Sie die Ausführung von OB10, das Startdatum und die Tageszeit festlegen, zu der OB10 ausgeführt werden soll. Zur Simulation haben wir das Ausführungsintervall auf jede Minute festgelegt, sodass OB10 jede Minute aufgerufen und ausgeführt wird. Das bedeutet, dass ab dem Datum 23.03.2023 und der Uhrzeit 09:25 Uhr der Wert von TimeOfDayInterruptCounter jede Minute um 1 erhöht wird. Sie haben die Möglichkeit, die Zeit entsprechend der SPS-Systemzeit oder der Ortszeit einzustellen, wie Sie im letzten Bild sehen. In einem früheren Artikel haben wir über die System- und Ortszeit der SPS gesprochen, was jede Zeit bedeutet und wie man sie konfiguriert und verwendet. Wie wir bereits gesagt haben, ist die Ortszeit die Zeit, die Sie jetzt auf Ihrem PC sehen. Es ist also die tatsächliche Zeit der Region, in der die SPS verwendet wird. Sie müssen die Ortszeit für die SPS konfigurieren, je nachdem, wo sie verwendet wird. Siehe Bild 5. Bild 5 – Einstellen der Ortszeit für die SPS Beispiel für ein einfaches SPS-Programm Wir haben unserem SPS-Programm einen Tageszeit-Interrupt OB10 hinzugefügt und ihn so eingestellt, dass er jede Minute ausgeführt wird. Wir haben auch die Ortszeit der SPS konfiguriert. Wir haben eine einfache Logik einer ADD-Anweisung erstellt, um den Wert des TimeOfDayInterruptCounter bei jeder Ausführung des OB10 um 1 zu akkumulieren. Wir werden einen weiteren Befehl hinzufügen, aber im Haupt-OB1 ist dieser Befehl RD_LOC_T oder „Lokalzeit lesen“, damit wir sehen können, wie die Lokalzeit voranschreitet und sie mit der Ausführung von OB10 vergleichen können. Siehe Abbildung 6. Abbildung 6 – Einfaches Programmbeispiel Kompilieren Sie Ihr SPS-Programm und starten Sie eine neue Simulation. Beachten Sie, dass wir die Uhrzeit des Auftretens der Unterbrechung festlegen, damit OB10 aufgerufen und ausgeführt werden kann, während wir die SPS-Logik simulieren. Siehe die folgende Simulation. Wie Sie der Animation entnehmen können, ist der Wert von TimeOfDayInterruptCounter zu Beginn Null und wird dann ab 09:25 Uhr jede Minute um 1 erhöht, was bedeutet, dass der OB10 jede Minute ausgeführt wird. Wichtige Regeln für die Uhrzeitalarme Wenn Sie einen Uhrzeitalarm so einstellen, dass der entsprechende OB einmalig abgearbeitet werden soll, darf der Startzeitpunkt nicht in der Vergangenheit liegen (bezogen auf die Echtzeituhr der CPU). Wenn Sie einen Uhrzeitalarm so einstellen, dass der entsprechende OB periodisch abgearbeitet werden soll, der Startzeitpunkt jedoch in der Vergangenheit liegt, dann wird der Uhrzeitalarm-OB beim nächsten fälligen Zeitpunkt gemäß der aktuellen Uhrzeit abgearbeitet. Das Datum periodischer Uhrzeitalarme muss einem realen Datum entsprechen. Beispielsweise ist die monatliche Wiederholung eines Uhrzeitalarm-OBs mit einem Startdatum vom 31.01. daher nicht möglich. In diesem Fall wird ein OB nur in den Monaten gestartet, die 31 Tage haben. Ein beim Start aktivierter Zeitinterrupt wird erst ausgeführt, wenn der Start abgeschlossen ist. Ein Start löscht alle Zeitinterrupts, die durch eine Anweisung im Benutzerprogramm gesetzt und aktiviert wurden. Fazit OB10 ist ein Organisationsbaustein, der so konfiguriert werden kann, dass er den Zyklus Ihres Programms an einem bestimmten Tag und zu einer bestimmten Uhrzeit unterbricht. Dieser Interrupt kann entweder einmal oder regelmäßig in einem bestimmten Zeitintervall auftreten. Es gibt keinen bestimmten Grund, warum Sie einen OB10 benötigen würden, da dies von Ihrem Prozess und Ihrer Logik abhängt. Und ja, Sie können dieselbe Funktionalität mit Ihrem persönlichen Code erreichen, aber es handelt sich um eine verfügbare und einfach zu verwendende integrierte Funktion. Und Sie wissen, wie man sie verwendet.

In früheren Artikeln haben wir besprochen, was ein Organisationsblock ist, und wir haben über den Haupt-Zyklischen Interrupt OB1 und den Tageszeit-Interrupt OB10 gesprochen. In diesem Artikel werden wir die verschiedenen OBs weiter besprechen, und dieses Mal sprechen wir über den Time Delay Interrupt Organization Block oder OB20. Inhalt: Was ist OB20? Wie ruft man OB20 auf? Parameter der SRT_DINT-Anweisung. Beispielprogramm. Fazit. Was ist Time Delay Interrupt (OB20)? OB20 ist ein Organisationsblock, der vom Betriebssystem aufgerufen und ausgeführt wird, aber wir müssen dem Betriebssystem mitteilen, wann dieser OB20 aufgerufen werden soll. Das Betriebssystem erhält die Informationen vom Benutzer-SPS-Programm, um diesen OB20 aufzurufen. Es wartet auf die konfigurierte Verzögerungszeit und ruft dann die Logik auf und führt sie aus, die sich im OB20 befindet. Wir erstellen einen OB20-Block, indem wir im Projektbaum einen neuen Block hinzufügen. Siehe Abbildung 1. Abbildung 1 – Einen neuen OB20-Block erstellen Nachdem ich nun einen Zeitverzögerungs-Interrupt erstellt habe, stellt sich die Frage, wann dieser ausgeführt wird. Und wie konfiguriere ich die Zeitverzögerung der Blockausführung? Auch hier ist OB20 ein Organisationsblock, was bedeutet, dass Sie den auszuführenden Block nicht aufrufen, sondern dem Betriebssystem mitteilen, wann es ihn aufrufen und die darin enthaltene Funktionalität ausführen kann. Wie teilt man dem Betriebssystem mit, dass es OB20 aufrufen soll? Um dem Betriebssystem mitzuteilen, dass wir OB20 aufrufen möchten, verwenden wir SRT_DINT oder den Startzeitverzögerungs-Interrupt, siehe Abbildung 2. Abbildung 2 – Startzeitverzögerungsanweisung Parameter der SRT_DINT-Anweisung Wie Sie im letzten Bild sehen, können Sie die SRT_DINT-Anweisung verwenden, um OB20 aufzurufen. Sie müssen jedoch einige Parameter konfigurieren, damit die Anweisung funktioniert. EN: Die Anweisung wird erst ausgeführt, wenn am EN-Eingang ein negatives Flankensignal anliegt. Das bedeutet, dass Sie eine Bedingung aus dem Satz von Bedingungen zuweisen müssen, um das Signal zu aktivieren, und die Anweisung funktioniert nur, wenn diese Bedingung wahr und dann wieder falsch ist. OB_NR: Sie weisen die Nummer des Verzögerungsinterrupts zu, den Sie aufrufen müssen, in unserem Fall 20, da wir OB20 erstellt haben, aber wir können mehr als einen Verzögerungsinterrupt erstellen und müssen dann jeden mit einer separaten SRT_DINT-Anweisung aufrufen. DTIME: Dies ist die Verzögerungszeit, die Sie abwarten möchten, bevor Sie OB20 ausführen. Wir werden diese Zeit der Simulation halber auf 5 Sekunden festlegen. SIGN: Kennung, die angezeigt wird, wenn der Zeitverzögerungsinterrupt-OB in den Startereignisinformationen des OB aufgerufen wird. Beispiel-SPS-Programm Um OB20 besser zu verstehen, erstellen wir eine einfache Logik, um zu sehen, wie ein OB20 aufgerufen und ausgeführt werden kann. Wir werden dieses SPS-Beispiel auf der Logik aufbauen, die wir in früheren Artikeln für OB1 und OB10 erstellt haben. In OB20 erstellen wir eine Logik, die zählt, wie viele OB1-Zyklen innerhalb der 5 Sekunden Verzögerungszeit aufgerufen und ausgeführt wurden, die wir für OB20 konfiguriert haben. Siehe Abbildung 3. Abbildung 3 – Logik in OB20 Im letzten Bild sehen Sie, dass wir den MOVE-Befehl verwendet haben, um Informationen zu Zykluszählungen zu Beginn des OB20-Aufrufs und nach dessen Ausführung zu übertragen. Den Rest der Logik finden Sie in Abbildung 4. Abbildung 4 – Berechnen Sie, wie viele Zyklen innerhalb von 5 Sekunden gezählt werden Danach subtrahieren wir die beiden Werte der Zykluszählungen, um zu ermitteln, wie viele Zyklen innerhalb der 5 Sekunden Verzögerung ausgeführt wurden. Nachdem wir nun die gewünschte Logik erstellt haben, wie können wir OB20 aufrufen? Wie bereits erläutert, müssen wir die Anweisung SRT_DINT verwenden. Wir werden diese Anweisung innerhalb des OB10 verwenden, den wir zuvor so konfiguriert haben, dass er jede Minute ausgeführt wird. Das bedeutet, dass der OB20 ebenfalls jede Minute aufgerufen und ausgeführt wird, jedoch mit einer Verzögerungszeit von 5 Sekunden. Im vorherigen Artikel haben wir eine Logik erstellt, die angibt, wie oft der OB1 aufgerufen und ausgeführt wird. Außerdem haben wir eine weitere Logik erstellt, die den OB10 jede Minute aufruft. In diesem Beispiel verwenden wir den Aufruf des OB10, um den OB20 aufzurufen. Siehe Abbildung 5. Abbildung 5 – Aufruf des OB20 über OB10 Wir haben bereits gesagt, dass der SRT_DINT ein negatives Flankensignal am EN benötigt, damit der Aufruf gestartet werden kann. Aus diesem Grund haben wir das Signal TimeOfDayInterruptEnabled verwendet, von dem wir wissen, dass es wahr sein wird, wenn OB10 ausgeführt wird, und dann wieder auf falsch zurückgeht, was uns das Flankensignal gibt, das wir brauchen. Nachdem die gesamte SPS-Logik nun abgeschlossen ist, kompilieren und führen wir eine neue Simulation aus. Sehen Sie sich die folgende Simulation unseres Projekts an. Sie sehen in der Animation, dass die Werte der Zykluszählungen zunächst Nullen sind, aber wenn OB10 aufgerufen wird und TimeOfDayInterruptEnabled wahr ist, wartet die Logik 5 Sekunden, dann werden die Zählwerte mit den Zykluszählungen aktualisiert. Fazit OB20 ist ein Organisationsblock, der vom Betriebssystem aufgerufen und ausgeführt wird. Wir können dem Betriebssystem sagen, dass es OB20 mit der Anweisung SRT_DINT aufrufen soll.

In früheren Artikeln haben wir verschiedene Arten von Organisationsblöcken besprochen, wie den Haupt-OB1, der der wichtigste zyklische Programmblock ist. In diesem Artikel werden wir uns mit einem anderen zyklischen Organisationsblock befassen. Dem OB30 oder zyklischen Interrupt-OB. Inhalt: Was ist ein zyklischer Interrupt OB30? Was ist der Haupt-OB1-Zyklus? Warum brauche ich OB30? Wie konfiguriere ich zyklische Interrupts? Was ist, wenn ich mehr als einen zyklischen Interrupt habe? Fazit. Was ist ein zyklischer Interrupt OB30? Ein zyklischer Interrupt OB30 ist ein Organisationsblock, der in festgelegten und genauen Zeitintervallen aufgerufen und ausgeführt wird. Im Gegensatz zum zyklischen Haupt-OB1, der kontinuierlich aufgerufen und ausgeführt wird, wird der zyklische Interrupt in Zeitintervallen aufgerufen, die Sie beim Erstellen eines zyklischen Interrupt-OB konfigurieren sollten. Wenn ich beispielsweise einen OB30 mit einem Zeitintervall _auch Zykluszeit genannt_ von 20 ms erstellt habe, bedeutet dies, dass das Betriebssystem den Hauptzyklus-OB1 unterbricht und den OB30 alle 20 ms aufruft. Sie müssen sicherstellen, dass die Laufzeit eines zyklischen Interrupt-OB kleiner als sein Zeitintervall ist. Andernfalls kann es passieren, dass der nächste Aufruf des OB30 eintrifft, während dieser Aufruf des OB30 noch ausgeführt wird. In diesem Fall generiert das Betriebssystem einen Zeitfehler, der dazu führen kann, dass die SPS in den STOP-Modus wechselt. Was ist der Hauptzyklus-OB1? Der Hauptzyklus-OB1 ist der Organisationsbaustein, der für die zyklische Ausführung Ihrer Logik durch die SPS verantwortlich ist. Immer wenn Sie ein neues Projekt erstellen und eine SPS hinzufügen, wird der Haupt-OB1 automatisch von der Software erstellt. Die wesentliche Grundlage Ihres SPS-Codes ist das zyklische Verhalten, d. h. Ihr Code muss kontinuierlich ausgeführt werden. Wenn die Verarbeitung Ihrer Logik abgeschlossen ist, beginnt das Betriebssystem erneut mit der Verarbeitung. Dies geschieht durch die Verwendung des Haupt-OB1. Sie platzieren und rufen Ihre gesamte Logik und Ihren Code in diesem OB1 auf und das Betriebssystem sorgt dafür, dass diese kontinuierlich ausgeführt werden. Die Zykluszeit des Haupt-OB1 bezieht sich auf die Laufzeit des zyklischen Programms, einschließlich der Laufzeit aller verschachtelten Programmteile wie FCs, FBs und OBs mit höherer Priorität. Wenn Sie mehrere Programmzyklus-OBs erstellt haben, trägt jeder Programmzyklus-OB zur Zykluszeit bei. Das Betriebssystem überwacht, ob die Zykluszeit kleiner bleibt als die konfigurierte maximale Zykluszeit. Wenn sie die maximale Zykluszeit überschreitet, wechselt die SPS je nach Ihrer Programmierung entweder in den STOP-Modus oder ruft OB80 auf. Warum brauche ich OB30? Jemand könnte argumentieren, dass ich jede beliebige Funktionalität innerhalb des OB30 im Haupt-OB1 platzieren und versuchen kann, damit durchzukommen, abhängig von der sehr schnellen Leistung der meisten SPS heutzutage. Das kann manchmal in Ordnung sein, aber nicht immer. Abhängig von der Leistung Ihrer SPS kann die Hauptzykluszeit zwischen 1 und 150 ms liegen. Sie kann unterschiedlich sein, aber dies ist die Standardkonfiguration. Diese Zykluszeit hängt von vielen Faktoren ab, wie der Größe Ihres SPS-Programms und Interrupts in Ihrer Logik und anderen Faktoren, die die Laufzeit Ihres Zyklus höchstwahrscheinlich instabil machen. Wenn Sie nun bestimmte Funktionen genau alle 10 ms ausführen müssen, nicht alle 9 ms und nicht alle 11 ms, können Sie sich nicht auf den Haupt-OB1 verlassen, da das Ergebnis möglicherweise nicht wie gewünscht ist. In diesem Fall verwenden Sie den zyklischen Interrupt OB30, konfigurieren ihn auf die gewünschten 10 ms und das Betriebssystem stellt sicher, dass diese Funktion genau alle 10 ms aufgerufen und ausgeführt wird. Aus diesem Grund wird er Interrupt genannt, da er die Ausführung des Haupt-OB1 unterbricht, um Ihren OB30 aufzurufen und auszuführen. Beispiele für Funktionen, die OB30 benötigen PID-Reglerverarbeitung. Überwachung von Sicherheitskreisen. Überwachung der Kommunikation zwischen Maschinen. In allen vorherigen Beispielen müssen Sie Ihre Parameter zu bestimmten Zeiten kontinuierlich überwachen und überprüfen, da sie sich auf reale physikalische Größen oder auf die Maschinensicherheit beziehen. Die Ausführung solcher Funktionen sollte nicht verzögert werden, da sie die Sicherheit und Kontinuität Ihres Prozesses beeinträchtigen. Wie konfiguriere ich zyklische Interrupts? Wenn Sie einen zyklischen Interrupt erstellen, müssen Sie einige Parameter konfigurieren. Siehe Abbildung 1 zum Hinzufügen eines neuen OB30. Abbildung 1 – Neuen zyklischen Interrupt OB30 hinzufügen Wenn Sie einen zyklischen Interrupt erstellen, finden Sie viele Parameter, die Sie in den Eigenschaften des Blocks festlegen können, siehe Abbildung 2. Abbildung 2 – Eigenschaften von OB30 Die wichtigsten Parameter, die Sie berücksichtigen müssen, sind folgende: Zykluszeit Verwenden Sie den Parameter „Zykluszeit“, um den Zeitraum zwischen zwei Aufrufen des zyklischen Interrupt-OB festzulegen. Er ist ein ganzzahliges Vielfaches von 1 µs. Phasenversatz Hier stellen Sie die Zeitspanne ein, um die die Startzeitpunkte gegenüber dem Vielfachen der Zykluszeit verschoben werden. Siehe Abbildung 3 für die Konfiguration von Zykluszeit und Phasenversatz. Abbildung 3 – Einstellen der Zykluszeit und des Versatzes von OB30 Priorität des Weckalarm-OB Dies ist ein weiterer wichtiger Parameter, den Sie beim Konfigurieren eines zyklischen Interrupts berücksichtigen müssen, da Sie möglicherweise mehr als einen zyklischen Block haben. Wenn zwei verschiedene OBs gleichzeitig aufgerufen werden müssen, ruft das Betriebssystem den Block mit einer höheren Prioritätsnummer auf und führt ihn aus. Sie sollten wissen, dass der SPS-Hauptprogrammzyklus OB1 die Prioritätsnummer 1 hat, die niedrigste Prioritätsstufe, die ein Block haben kann. Deshalb kann OB1 durch jeden anderen Blockaufruf unterbrochen werden. Siehe Abbildung 4. Abbildung 4 – Festlegen der Priorität von OB30 Was passiert, wenn ich mehr als einen zyklischen Interrupt habe? Es ist nicht ungewöhnlich, dass Sie mehr als einen zyklischen Interrupt in Ihrer Logik haben. Wenn Sie zwei PID-Regler in Ihrer SPS-Logik haben, benötigen Sie möglicherweise zwei zyklische Interrupts, um jeden PID zu verarbeiten. In diesem Fall müssen Sie sicherstellen, dass sich der Aufruf und die Ausführung verschiedener zyklischer Interrupts nicht überschneiden. Wenn Sie beispielsweise OB30 mit einer Intervallzykluszeit von 5 ms und OB31 mit einem Zyklusintervall von 10 ms haben, bedeutet dies, dass der zweite Aufruf von OB30 auch die Zeit für den Aufruf von OB31 ist. Dies kann zu Logikfehlern führen, selbst wenn Sie die Priorität eines der beiden höher als die des anderen einstellen, wird Ihre Zykluszeit für den Block mit der niedrigeren Priorität durcheinandergebracht. Siehe Abbildung 5. Abbildung 5 – Überlappung des Aufrufs verschiedener zyklischer Interrupts In diesem Fall kann ein Phasenversatz ratsam sein, wenn Sie mehrere zyklische Interrupt-OBs verwenden. Wenn ihre Zykluszeiten gemeinsame Vielfache haben, können Sie einen Phasenversatz verwenden, um gleichzeitige Startzeiten zu verhindern. Siehe Abbildung 6. Abbildung 6 – Versatz zwischen verschiedenen OB-Aufrufen Um diese Überlappung zu vermeiden, setzen wir die Versatzzeit von OB31 auf 1 ms. Das bedeutet, dass die Zählung für das OB31-Zeitintervall um 1 ms gegenüber der Startzeit von OB30 verschoben wird. Siehe Abbildung 7. Abbildung 7 – Offset-Einstellung von OB31 Fazit Zyklische Interrupts sind sehr nützlich für zeitkritische Aufgaben, bei denen es zu keinen Verzögerungen kommen sollte. Sie können mehr als einen zyklischen Interrupt in Ihrer Logik haben. Verwenden Sie die Offset-Einstellung der zyklischen Interrupts, um gleichzeitige Startzeiten zu vermeiden. Verwenden Sie die Prioritätseinstellung, um die Reihenfolge der Ausführung verschiedener zyklischer Interrupts zu steuern.

In früheren Artikeln haben wir begonnen, verschiedene Organisationsblöcke von TIA Portal PLCs zu besprechen, wir haben darüber gesprochen, was OBs sind, und wir haben einige der OBs wie OB1- Hauptzyklus, OB10 und OB20, die Tageszeitverzögerung bzw. Zeitverzögerungsinterrupts, besprochen. In diesem Artikel werden wir über den OB100 oder den Start-Organisationsblock im Siemens Tia Portal sprechen. Inhalt: Was ist OB100? Warum wird OB100 benötigt? Wichtige Hinweise beim Start. Einfaches Programmbeispiel. Was ist der Start-Organisationsblock (OB100)? OB100 oder der Start-OB ist ein Organisationsblock, der vom Betriebssystem einmal beim Start der SPS aufgerufen und ausgeführt wird, d. h. einmal bei jedem Übergang vom STOP- in den RUN-Modus. Der Hauptzyklus OB1 wird erst aufgerufen und ausgeführt, wenn alle Startfunktionen innerhalb von OB100 ausgeführt wurden. Sie können mehr als einen Start-OB in Ihrer SPS-Logik haben. Wenn das passiert, ruft das Betriebssystem sie alle nacheinander auf und führt sie aus, beginnend mit einer niedrigeren OB-Nummer zu einer höheren Nummer. Wenn Sie also OB100 und OB123 haben, wird zuerst OB100 aufgerufen und ausgeführt, dann OB123. Nachdem OB100 ausgeführt wurde, liest das Betriebssystem die Eingangsmodule in das PII und startet das Hauptzyklusprogramm OB1. Warum brauchen Sie OB100? Sie verwenden OB100 für viele Aufgaben, die Sie möglicherweise ausführen möchten oder müssen, bevor Sie Ihre zyklische Logik starten. Dies sind die folgenden Gründe: Variablen initialisieren. Systemmodule zurücksetzen. Sensoren/Aktoren neu kalibrieren. Vor dem Starten Ihres Prozesses auf Alarme und Sicherheitsbedingungen prüfen. Auch wenn Sie keinen Anlauf-OB für Ihre Logik erstellt haben, muss das Betriebssystem vor dem Start Ihrer Hauptlogik noch viele Aufgaben ausführen. Einige dieser Aufgaben sind: Nicht remanente Speicher löschen PAA löschen Anlauf-OBs aufrufen und ausführen, falls vorhanden. PAA aktualisieren Ausgänge nach dem Wechsel in den RUN-Modus aktivieren. Haben Sie bemerkt, dass die letzte Aufgabe einer Anlaufroutine darin besteht, die Ausgänge zu aktivieren? Deshalb besteht der erste Schritt bei der Ausführung des Hauptzyklusprogramms OB1 darin, die PAA in das Ausgangsmodul zu schreiben. Wichtige Hinweise während des Anlaufs Beachten Sie die folgenden Punkte zum Modus „STARTUP“: Die Ausgänge an den Modulen sind deaktiviert. Das Prozessabbild wird initialisiert. Das Prozessabbild wird nicht aktualisiert. Um während des „STARTUP“ den aktuellen Zustand von den Eingängen zu lesen, können Sie über direkten E/A-Zugriff auf die Eingänge zugreifen. Um während des Anlaufs die Ausgänge zu initialisieren, können Werte über das Prozessabbild oder über direkten E/A-Zugriff geschrieben werden. Die Werte werden beim Übergang in den „RUN“-Modus an den Ausgängen ausgegeben. Die nicht remanenten Merker, Timer und Zähler werden initialisiert. Die nicht remanenten Variablen in Datenbausteinen werden initialisiert. Beim Anlauf läuft noch keine Zykluszeitüberwachung. Einfaches Programmbeispiel In diesem Beispiel fügen wir unserer SPS-Logik einen Anlauf-OB100 hinzu und sehen, wie oft der OB100 ausgeführt wird. Siehe Bild 1 zum Hinzufügen eines neuen OB100. Bild 1 – Hinzufügen eines OB100 Wie Sie im letzten Bild sehen, fügen Sie Anlauforganisationsblöcke auf die gleiche Weise hinzu, wie wir eine Funktion eines Funktionsbausteins hinzufügen. Innerhalb des gerade erstellten OB100 fügen wir eine einfache ADD-Anweisung hinzu, um zu akkumulieren, wie oft der OB100 aufgerufen und ausgeführt wird. Siehe Bild 2. Bild 2 – Ausführungszeiten von OB100 akkumulieren Kompilieren und führen Sie nun Ihr Programm aus und sehen Sie, was passiert. In der folgenden Animation sehen Sie eine Simulation des SPS-Programms. Animation 1 Wie Sie in der obigen Animation sehen können, ist der OB100CycleCounter 1 und ändert sich nicht, wenn der SPS-Modus von STOP auf RUN wechselt. Er ändert sich zwar, aber Sie sehen diese Änderung nicht. Jedes Mal, wenn die SPS in den STOP-Modus und dann wieder in den RUN-Modus wechselt, wird der Zähler auf Null und dann wieder auf 1 zurückgesetzt, nachdem OB100 ausgeführt wurde. Sie können auch sehen, wie sich der Hauptzykluszähler von OB1 ändert, und wenn die SPS anhält und dann wieder läuft, beginnt der OB1CycleCounter erneut zu akkumulieren. Um die Änderung im Startzähler zu sehen, müssen wir den Wert des Tag-Speichers beibehalten. Siehe Bild 3. Bild 3 – Behalten des OB100CycleCounter-Tagspeichers Nachdem wir den OB100CycleCounter-Tag behalten haben, führen Sie die SPS-Simulation erneut aus und sehen Sie, was passiert. Siehe Simulationsanimation 2. Animation 2 Sie sehen jetzt in der obigen Animation, dass der Startzähler jedes Mal steigt, wenn ich die SPS stoppe und dann wieder starte. Da der Tagspeicher jetzt beibehalten wird, wird der Wert nicht auf Null zurückgesetzt, und deshalb sehen Sie, wie sich der Wert des OB100CycleCounters ansammelt. Jetzt muss ich meiner Start-SPS-Logik zusätzliche Funktionen hinzufügen, nämlich wissen, wann der letzte Start der SPS war. Wir werden das durch eine einfache Logik erreichen, bei der ich die lokale Zeit der SPS beim Start lese und Datum und Uhrzeit in einen bestimmten Speicherbereich verschiebe. Siehe Bild 4. Bild 4 – Lokale Zeit beim Start ablesen Nachdem Sie Ihre Logik hinzugefügt haben, kompilieren Sie die Simulation und führen Sie sie erneut aus. Sehen Sie sich die SPS-Simulationsanimation 3 an. Animation 3 Sie können der obigen Animation entnehmen, dass bei jedem Start der SPS das Startdatum und die Startzeit im von uns zugewiesenen Speicherbereich aufgezeichnet werden. Jetzt habe ich also die Informationen darüber, wie oft meine SPS gestartet wurde und wann der letzte Startzeitpunkt war. Fazit Start-OBs sind sehr wichtig, wenn Sie einige Funktionen auswerten möchten, bevor Sie Ihren zyklischen Prozess ausführen können. Sie können Start-OBs verwenden, um Parameter zu initialisieren, Sensoren zu kalibrieren und sogar Sicherheitsbedingungen zu prüfen, bevor Sie Ihren Prozess ausführen lassen.

In diesem Artikel setzen wir unsere Diskussion über verschiedene Arten von Organisationsblöcken in der Siemens-SPS fort. Dieses Mal sprechen wir über den OB121 oder den Programmierfehler-Interrupt im Tia-Portal. Inhalt: Was sind Programmierfehler-Interrupts OB121? Beispiele für Programmierfehler. Was passiert, wenn ein Programmierfehler erkannt wird? Simulation eines Programmierfehlers im TIA-Portal. Wie kann der OB121 gegen Programmierfehler nützlich sein? Schlussfolgerungen. Was sind Programmierfehler-Interrupts (OB121)? OB121 ist ein Organisationsblock, der vom Betriebssystem der SPS aufgerufen wird, wenn beim Ausführen Ihrer Logik ein Programmierfehler auftritt. Beachten Sie, dass wir nicht von einem Programmierfehler sprechen, der vom Compiler abgefangen wird, wenn versucht wird, Ihre Logik in Ihre SPS herunterzuladen. Siehe Bild 1. Bild 1 – Einige Programmierfehler werden vom Compiler erkannt Wie Sie im letzten Bild sehen, liegt in meiner SPS-Logik ein Programmierfehler vor; einige Operanden fehlen in der Eingabe und Ausgabe von Netzwerk 1. Dieser Fehler wurde jedoch vom Compiler erkannt, bevor die Logik überhaupt in die SPS heruntergeladen wurde. Der Fehler in Bild 1 ist nicht der Programmierfehlertyp, der den Aufruf von OB121 auslösen kann. Fehler in Ihrem SPS-Programm, die vom Compiler nicht gefunden werden können, aber dennoch Probleme in Ihrer Logik verursachen können, während die SPS läuft, sind die Programmierfehler, die wir meinen. Diese Fehler lösen einen Aufruf von OB121 durch das Betriebssystem aus. Beispiele für Programmierfehler Hier sind einige Beispiele für Fehler in Ihrer SPS-Logik, die Programmierfehler verursachen können: Maximale Verschachtelungstiefe von Blockaufrufen überschritten. Sie haben einen NULL-Zeiger verwendet, um einen Operanden anzusprechen. Unbekannte Anweisung. Die adressierte Zeichenfolge weist falsche Längeninformationen auf. Bereichslängenfehler beim Lesen. Bereichslängenfehler beim Schreiben. Fehler in Timer-Nr. Zugriff auf einen nicht geladenen DB; die DB-Nummer befindet sich im zulässigen Bereich. DB existiert nicht. Diese und viele weitere Fehler können Programmierfehler in Ihrer SPS verursachen. Im Hilfebereich des TIA-Portals können Sie nachlesen, welche anderen Gründe zu Programmierfehlern in der SPS führen können. Was passiert, wenn ein Programmierfehler erkannt wird? Wenn Ihre SPS einen Programmierfehler erkennt, kann eines von drei Ereignissen eintreten. Ihre SPS zeigt einen Fehler an und wechselt in den STOP-Modus. Ihre SPS zeigt einen Fehler an, führt Ihre Logik jedoch weiter aus. Ihre SPS zeigt einen Fehler an und versucht dann, diesen Fehler zu beheben. Diese drei Ereignisse hängen im Wesentlichen von Ihrer SPS-Programmierung ab. Das heißt, Ihr Code entscheidet, wie sich das Betriebssystem bei Erkennung eines Programmierfehlers verhält. Simulation eines Programmierfehlers im TIA-Portal Um das Verhalten der SPS besser zu verstehen, erstellen wir ein einfaches Programm, in dem wir einen Programmierfehler verursachen, und sehen dann, was passiert. Siehe Bild 2. Bild 2 – Einfache Programmlogik Die von uns erstellte Logik ist sehr einfach. Wenn InitiateProgError aktiviert wurde, wird der Wert 126 in den Bereich DB52.DBW16 verschoben. Beachten Sie, dass wir DB52 nicht erstellt haben. Dies wird also unser Programmierfehler sein. Beachten Sie, dass dieser Fehler beim Kompilieren oder Herunterladen in die SPS nicht erkannt wird. Siehe Bilder 3 und 4. Bild 3 – Vom Compiler nicht erkannter Fehler Sehen Sie, wie der Block erfolgreich kompiliert wurde, obwohl ein Programmierfehler auftrat. Bild 4 – Block in SPS heruntergeladen Wieder wurde der Block mit einem Programmierfehler in die SPS heruntergeladen. Lassen Sie uns nun unser SPS-Programm simulieren und sehen, was passiert. Die Simulation des SPS-Codes finden Sie in Animation 1. Animation 1 Wie Sie in der obigen Animation sehen, blinkt die PLC ERROR-LED einige Sekunden lang rot, dann wechselt die PLC in den STOP-Modus. Gehen Sie zur PLC-Onlinediagnose, um zu sehen, was passiert ist. Siehe Bild 5. Bild 5 – Online- und Diagnose der PLC Was Sie in der Animation gesehen haben, ist genau das, was Sie im vorherigen Bild sehen. Es kann in 3 Schritten beschrieben werden: Die PLC erkennt den Programmierfehler, nämlich dass OB52 nicht geladen ist. Das Betriebssystem löst den Aufruf des OB121 aus, aber in unserer Logik wurde kein OB121 erstellt. Wenn die PLC feststellt, dass in unserer Logik kein OB121 erstellt wurde, initiiert das Betriebssystem eine STOP-Anforderung. Und die PLC wechselt in den STOP-Modus. Wie kann der OB121 gegen Programmierfehler hilfreich sein? Fügen wir unserem SPS-Code einen OB121 hinzu und sehen wir, wie sich die Dinge ändern. Siehe Bild 6. Bild 6 – Hinzufügen eines OB121 Nachdem wir den OB121 erstellt und in unsere SPS-Logik eingefügt haben, sehen wir, was in der Simulation passiert. Denken Sie daran, dass wir keine SPS-Logik in den OB121 geschrieben haben. Siehe Animation 2. Animation 2 Wie Sie in Animation 2 sehen, blinkt die PLC ERROR-LED rot, wenn InitiateProgError ausgelöst wird, aber die SPS läuft weiter. Das bedeutet, dass die SPS nicht in den STOP-Modus wechselt. Sehen wir uns die Online-Diagnose an, um zu sehen, was tatsächlich passiert ist. Siehe Bild 7. Bild 7 – Fehler hat nicht zum Stoppen der SPS geführt Sie sehen auf dem Bild, dass die SPS den Fehler erkennt, aber nicht in den STOP-Modus wechselt. Sie überspringt diesen Fehler, setzt den Zyklus fort und beginnt wieder von vorne. Wenn der Fehler erneut auftritt, erkennt sie ihn erneut und gibt einen Alarm in der Diagnose aus. Überspringen Sie den Fehler und fahren Sie fort. Das bedeutet, dass die SPS in jedem Scan-Zyklus denselben Alarm ausgibt. Und deshalb sehen Sie auf dem Bild, dass das Ereignis immer wieder ausgelöst wird und der Alarm sich in jedem Scan-Zyklus wiederholt. Ein leerer OB121 bietet Ihnen also den Vorteil, dass die SPS weiterläuft und Ihr Prozess weiterläuft. Aber wir können noch mehr tun: Wir können versuchen, diesen Fehler zu erkennen und zu beseitigen. Außerdem können wir versuchen, die Art des erkannten Programmierfehlers anzuzeigen. Fehlertyp bestimmen Der OB121 verfügt über eine interne Fehler-ID, die wir verwenden können, um den Fehlertyp anzuzeigen, beispielsweise als Alarm auf einem HMI. Innerhalb des OB121 erstellen wir eine einfache MOVE-Anweisung, mit der wir den Fault_ID-Eingang des OB121 in einen definierten Speicherbereich innerhalb unseres globalen DBs verschieben. Siehe Abbildung 8. Abbildung 8 – Fehlertyp identifizieren Wie Sie im vorherigen Bild sehen, wird die Fault_ID bei Auftreten des Programmierfehlers in die Data.ProgErrorID verschoben. Siehe Abbildung 9. Abbildung 9 – Programmierfehler Fault_ID Sie können sehen, dass die Fehler-ID 3A ist. Wenn Sie die TIA Portal-Hilfe überprüfen, können Sie die Bedeutung dieses Fehlers herausfinden. 3A: Zugriff auf einen DB, der nicht geladen ist; die DB-Nummer befindet sich im zulässigen Bereich. Den Fehler abfangen Das bedeutet einfach, dass Sie versuchen, den SPS-Programmierfehler zu beheben, nachdem Sie die Ursache ermittelt haben. Dies hängt hauptsächlich davon ab, was der Fehler ist und wie Sie ihn behandeln möchten. Wir werden einfach eine Lösung für den Fehler simulieren, um zu sehen, wie sich die SPS verhält. Die eigentliche Lösung für den von uns verursachten Fehler besteht darin, einfach den DB52 zu erstellen oder einen bereits erstellten Datenblock zu verwenden. Aber der Simulation halber werden wir einfach einen einfachen Kontakt hinzufügen, der sich öffnet, wenn der Programmierfehler auftritt, um diesen Fehler abzufangen. Siehe Bilder 10 und 11. Bild 10 – Den Fehler abfangen Immer wenn OB121 aufgerufen wird, wird der CatchError gesetzt. Bild 11 – Fehler beheben Wenn OB121 aufgerufen wird, wird CatchError gesetzt und verwendet, um den Programmierfehler in Netzwerk 1 abzufangen. Die SPS-Simulation finden Sie in Animation 3. Animation 3 Aus der obigen Animation können Sie erkennen, dass die SPS beim Auslösen von InitiateProgError kurzzeitig in den Fehlermodus gerät, der dann gelöscht wird und die SPS sich dauerhaft im RUN-Modus befindet. Fazit Einfach ein leeres OB121 in Ihrer Logik stellt sicher, dass Ihre SPS nicht in den STOP-Modus wechselt, wenn in Ihrem Code ein Programmierfehler vorliegt. Sie können das OB121 später auch verwenden, um den Fehler zu identifizieren und zu beheben.

Dieser Artikel handelt von einem Verkehrskontrollsystem für T-Kreuzungen mit Hilfe einer SPS-Leiterlogik, die einen Komparator für den Ampelbetrieb verwendet. Verkehrskontrollsystem für T-Kreuzungen Die Funktion des Verkehrskontrollsystems für T-Kreuzungen besteht aus drei Segmentgruppen. Durch die Logik des Komparatorbetriebs steuern wir das Ampelsystem. Erstes Segment: Im ersten Segment ist der Verkehr auf Spur 1 erlaubt und die Spur 2 und Spur 3 sind angehalten. Hier in diesem Segment leuchtet das grüne Licht (Grün 1) der Spur 1 und die roten Lichter (Rot 2) der Spur 2 und (Rot 3) der Spur 3 leuchten. Dieser Zeitraum dauert fünfzehn Sekunden. Zweites Segment: Im zweiten Segment ist der Verkehr auf Spur 2 erlaubt und die Spur 1 und Spur 3 sind angehalten. In diesem Abschnitt leuchtet das grüne Licht (Grün 2) der Spur 2 und die roten Lichter (Rot 1) der Spur 1 und (Rot 3) der Spur 3 leuchten. Dieser Zeitraum dauert 15 Sekunden. Dritter Abschnitt: Im dritten Abschnitt ist der Verkehr auf Spur 3 erlaubt und Spur 1 und Spur 2 sind angehalten. In diesem Abschnitt leuchtet das grüne Licht (Grün 3) der Spur 3 und die roten Lichter (Rot 1) der Spur 1 und (Rot 2) der Spur 2 leuchten. Dieser Zeitraum dauert 15 Sekunden. Nach der Ausführung aller drei Abschnitte beginnt die Abfolge der Vorgänge erneut und wiederholt sich kontinuierlich. Beschreibung der Ein- und Ausgänge In diesem SPS-Projekt haben wir 2 Eingänge, 6 Ausgänge, 2 Speicher und 1 Einschaltverzögerungstimer verwendet. S.Nr. Symbol Beschreibung 1 I 0.0 START 2 I 0.1 STOP 3 M 0.0 MEMORY 4 M 0.1 MEMORY 1 5 Q 0.0 GRÜN 1 6 Q 0.1 ROT 1 7 Q 0.2 GRÜN 2 8 Q 0.3 ROT 2 9 Q 0.4 GRÜN 3 10 Q 0.5 ROT 3 11 DB1 EIN VERZÖGERUNGSTIMER SPS-Programmierung und ihre Erklärung 1. Wenn die START-Taste (I 0.0) gedrückt wird, wird MEMORY (M 0.0) aktiviert. Dieser M 0.0 ist der Hauptspeicher, der zum Ausführen aller Prozesse im Programm verwendet wird. Da er verriegelt ist, wird er nur im aktivierten Zustand sein. Wenn STOP (I 0.1) gedrückt wird, wird der gesamte Prozess jederzeit gestoppt. 2. Sobald MEMORY aktiviert ist, wird der TIMER DB1 eingeschaltet, der die Zeitsteuerung der Verkehrskreuzung steuert. In diesem Timer stellen wir die voreingestellte Zeit von 45 Sekunden ein. Sobald der Timer die voreingestellte Zeit erreicht, wird MEMORY 1 (M 0.1) aktiviert und dieser M 0.1 setzt den Timer gemäß der Logik zurück und lässt den Zyklus kontinuierlich laufen. 3. Als nächstes spielt der Komparator eine wichtige Rolle bei der Steuerung der Verkehrskreuzung. Zuerst wird der Ausgang GRÜN 1 (Q 0.0) gemäß der Logik eingeschaltet. Hier haben wir Kleiner als oder Gleich für den Komparator verwendet. In dieser Logik befindet sich Q0.0 von 0 Sekunden bis 15 Sekunden im EIN-Zustand. Danach wechselt er in den AUS-Zustand. 4. Als nächstes haben wir für den Ausgang ROT 1 (Q0.1) die Funktion Größer als oder Gleich verwendet. Q0.1 befindet sich von 15 bis 45 Sekunden im EIN-Zustand. Es befindet sich im AUS-Zustand, wenn Q0.0 im EIN-Zustand ist. 5. Dann haben wir für Ausgang GRÜN 2 (Q0.2) sowohl Kleiner als oder gleich als auch Größer als oder gleich für diesen Ausgang verwendet. Beide Komparatorfunktionen wurden in serieller Logikschaltung mit dem Ausgang verbunden. Dabei befindet sich Q0.2 je nach Bedingung von 16 bis 30 Sekunden im EIN-Zustand. 6. Als nächstes haben wir für Ausgang ROT 2 (Q0.3) auch sowohl die Funktion Kleiner als oder gleich als auch Größer als oder gleich verwendet, um den Vorgang auszuführen. Komparatoren wurden in Parallelschaltung mit dem Ausgang verbunden. Dieser Ausgang befindet sich von 0 bis 15 Sekunden und von 30 bis 45 Sekunden im EIN-Zustand. Zwischen 15 Sekunden befindet er sich nur im AUS-Zustand, da sich Q0.2 zu diesem Zeitpunkt im EIN-Zustand befindet. 7. Dann haben wir für den letzten GRÜNEN 3-Ausgang (Q0.4) die Funktion „Größer als oder gleich“ verwendet. Gemäß der bedingten Logik befindet er sich 30 bis 45 Sekunden lang im EIN-Zustand. Vor diesem Zeitpunkt befindet er sich im AUS-Zustand. 8. Schließlich der ROT 3-Ausgang (Q0.5). Hier haben wir die Funktion „Kleiner als oder gleich“ verwendet, um die SPS-Logik auszuführen. Er befindet sich 0 bis 30 Sekunden lang im EIN-Zustand, danach befindet er sich im AUS-Zustand. Fazit Auf diese Weise wird die Verkehrssteuerung der gegebenen T-Kreuzung durch die Komparatorfunktion mit der SPS-Logik ausgeführt. Wir können die Verkehrslogik mithilfe der SPS-Logik auf viele Arten steuern, und dies ist auch eine der Möglichkeiten dazu.