FAQ 10/2015. Taktsynchronität - Ein Beispiel. SIMATIC S / TIA Portal V13 SP1.

Transkript

1 FAQ 10/2015 Taktsynchronität - Ein Beispiel SIMATIC S / TIA Portal V13 SP1

2 Dieser Beitrag stammt aus dem Siemens Industry Online Support. Es gelten die dort genannten Nutzungsbedingungen ( Securityhinweise Siemens bietet Produkte und Lösungen mit Industrial Security-Funktionen an, die den sicheren Betrieb von Anlagen, Lösungen, Maschinen, Geräten und/oder Netzwerken unterstützen. Sie sind wichtige Komponenten in einem ganzheitlichen Industrial Security-Konzept. Die Produkte und Lösungen von Siemens werden unter diesem Gesichtspunkt ständig weiterentwickelt. Siemens empfiehlt, sich unbedingt regelmäßig über Produkt-Updates zu informieren. Für den sicheren Betrieb von Produkten und Lösungen von Siemens ist es erforderlich, geeignete Schutzmaßnahmen (z. B. Zellenschutzkonzept) zu ergreifen und jede Komponente in ein ganzheitliches Industrial Security-Konzept zu integrieren, das dem aktuellen Stand der Technik entspricht. Dabei sind auch eingesetzte Produkte von anderen Herstellern zu berücksichtigen. Weitergehende Informationen über Industrial Security finden Sie unter Um stets über Produkt-Updates informiert zu sein, melden Sie sich für unseren produktspezifischen Newsletter an. Weitere Informationen hierzu finden Sie unter Inhaltsverzeichnis 1 Einführung Taktsynchronität Überblick Funktion Besonderheiten im Systemaufbau Ziel dieses Dokuments Motivation Aufbau des Beispielprojekts Signalerfassung und -ausgabe am Prozess Funktion Einstellungen E/A-Module in der dezentralen Peripherie Antrieb als dezentrale Peripherie Antrieb mit Technologieobjekt Achse Untersetzung der Synchron-OBs Die Sync-Domain Einstellung einer Sync-Domain im Netz Übersicht der Einstellungen der Taktsynchronität Programmierung im Synchron-OB Die Funktionen SYNC_PI und SYNC_PO Das EVA-Modell Das AEV-Modell Beispiele zu den Modellen Voraussetzung Nutzung des EVA-Modells Nutzung des AEV-Modells Beitrags-ID: , V1.0, 10/2015 2

3 1 Einführung 1 Einführung 1.1 Taktsynchronität Überblick Funktion Die Funktionalität Taktsynchronität wird in der SIMATIC S immer dann genutzt, wenn mehrere Parameterwerte vergleichbar bzw. zueinander in einer Beziehung stehend innerhalb eines Zyklus verarbeitet werden sollen. Diese Vorgabe ist beispielsweise bei folgenden Szenarien erfüllt: Gleichzeitige Erfassung von mehreren Messwerten, die über verschiedene Eingangsbaugruppen erfasst werden sollen. Ausführung von regelungstechnischen Prozessen auf der SIMATIC S CPU, bei denen die Erfassung der Messwerte und die Ausgabe der Aktorsignale über verschiedene Baugruppen erfolgt. Zusammengehörige Regelung von mehreren Antrieben über die in der SIMATIC S integrierten Antriebsfunktionen. Als Beispiel für die Vorstellung der Funktionalität Taktsynchronität soll die zusammengehörige Erfassung von mehreren Messwerten innerhalb eines Programmzyklus dienen. Abbildung 1-1 Beispiel für die Vorstellung der Funktionalität Taktsynchronität Eine Nockenwelle soll während einer Umdrehung genau vermessen werden. Dazu ist es wichtig, dass die einzelnen Messwerte der Nockenmessung und der aktuelle Drehwinkel der Nockenwelle zum gleichen Zeitpunkt erfasst werden, so dass diese Messwerte in der SIMATIC CPU ausgewertet und verglichen werden können. Um die gleichzeitige Erfassung der Messewerte realisieren zu können, wird die Funktionalität Taktsynchronität in der SIMATIC CPU genutzt. Diese Funktion bietet die Möglichkeit, die Messwerte auf den einzelnen Baugruppen der dezentralen Peripherie der SIMATIC CPU zur gleichen Zeit zu erfassen und in einem festgelegten Takt-Raster an die SIMATIC CPU zu übertragen. Reaktionen auf die Auswertung der Messwerte in der SIMATIC CPU können über diese Funktion dann ebenfalls zu einem festgelegten Zeitpunkt über die Baugruppen der dezentralen Peripherie ausgegeben werden. Beitrags-ID: , V1.0, 10/2015 3

4 1 Einführung Abbildung 1-2 Datenaustausch im taktsynchronen Betrieb Taktsynchron-Zyklus Taktsynchron-Zyklus Taktsynchron-Zyklus CPU Anwenderprogramm (OB 6x) Verzögerung Anwenderprogramm (OB 6x) Anwenderprogramm (OB 6x) Bus Slave 1 Slave 2 Azyklischer Teil Reserve G C Slave 1 Slave 2 Azyklischer Teil Reserve G C Slave 1 Slave 2 Azyklischer Teil Reserve G C Rückwandbus Modul TW E TW A TW E TW A Prozess Prozess Der vollständige Ablauf der Datenerfassung, Verarbeitung und Datenausgabe stellt sich wie folgt dar: Tabelle 1-1 Datenaustausch im taktsynchronen Betrieb Nr. Beschreibung 1 Der gewünschte Messwert wird im Prozess erfasst. 2 In der Eingangsbaugruppe wird der erfasste Messwert verarbeitet bzw. digitalisiert. 3 Danach wird der digitale Messwert innerhalb der dezentralen Peripherie über den Rückwandbus von der Eingangsbaugruppe an die Kopfbaugruppe übertragen. 4 Mit Hilfe des taktsynchronen Datenaustauschs wird der Messwert dann zu Anfang des Bustakts an die SIMATIC CPU gesendet. 5 Nach der Übertragung wird in der SIMATIC CPU der Synchron-OB gestartet, in dem der gewünschte Messwert dann verarbeitet wird. 6 Das aus der Verarbeitung des Messwerts resultierende Ergebnis bzw. die Reaktion auf den Messwert wird dann wieder mit Hilfe des taktsynchronen Datenaustauschs zu Anfang des Bustakts an die dezentrale Peripherie übertragen. 7 Von der Kopfbaugruppe wird das Ausgabesignal dann wieder an die Ausgabebaugruppe übertragen. 8 Dort wird das Ausgabesignal verarbeitet, beispielsweise in einen Analogwert gewandelt. 9 Das Ausgabesignal wird dann an den Prozess übergeben. Durch die taktsynchrone Datenübertragung werden damit alle Messwerte um die definiert vorgegebene Zeitspanne vor der Datenübertragung über den Kommunikationsbus im Prozess erfasst, bzw. um die definiert vorgegebene Zeitspanne nach der Übergabe an den Kommunikationsbus an den Prozess übergeben. Die Zeitspanne und kann vom TIA Portal in Abhängigkeit der Anzahl von taktsynchronen Baugruppen in einer dezentralen Peripheriestation für jede Station individuell berechnet werden. Es können die Zeitspannen und jedoch auch für alle dezentralen Peripheriestationen gleich eingestellt werden, was sehr zu empfehlen ist, wenn die Messwerte von mehreren Stationen erfasst werden sollen. Beitrags-ID: , V1.0, 10/2015 4

5 1 Einführung Besonderheiten im Systemaufbau Die Funktionalität Taktsynchronität kann aktuell im Zusammenhang mit der SIMATIC S nur über einen Systemaufbau mit dezentraler Peripherie genutzt werden. Im zentralen Aufbau der SIMATIC S steht die Funktionalität Taktsynchronität aktuell nicht zur Verfügung. Die Baugruppen der dezentralen Peripherie können dabei über PROFIBUS oder PROFINET mit der SIMATIC S CPU verbunden sein. Es muss jedoch darauf geachtet werden, dass die Kopfbaugruppen der dezentralen Peripherie die Funktionalität Taktsynchronität unterstützen. 1.2 Ziel dieses Dokuments Motivation Dieses Dokument soll Ihnen anhand von verschiedenen Beispiel-Parametrierungen die Einstellmöglichkeiten und Zusammenhänge der Funktionalität Taktsynchronität im TIA Portal nahe bringen Aufbau des Beispielprojekts Das Beispielprojekt, das diesem Dokument zu Grunde liegt ist wie folgt aufgebaut: Abbildung 1-3 Aufbau des Beispielprojekts Das Beispielprojekt besteht aus einer SIMATIC S CPU, die die Messwerte verarbeiten soll. einer dezentralen Peripherie, über die die Messwerte erfasst werden sollen. einem Antrieb, der die zu den Messwerten zugehörige Position liefert. Alle Komponenten des Beispiels sind über eine taktsynchrone PROFINET-Verbindung miteinander verbunden. Beitrags-ID: , V1.0, 10/2015 5

6 2 Signalerfassung und -ausgabe am Prozess 2 Signalerfassung und -ausgabe am Prozess 2.1 Funktion Die Erfassung von Signalen in einem Prozess bzw. die Ausgabe der Steuersignale an einen Prozess wird über eine dezentrale Peripheriestation realisiert. 2.2 Einstellungen E/A-Module in der dezentralen Peripherie Über die Eigenschaften zur Einstellung der E/A-Adressen des entsprechenden E/A-Moduls, das die Signale des Prozesses erfassen bzw. wieder an den Prozess ausgeben soll, können die Parameter für den taktsynchronen Betrieb des Moduls eingestellt werden. Abbildung 2-1 Einstellung der E/A-Adressen des Moduls Für den taktsynchronen Betrieb dieses E/A-Moduls müssen die Ein- und Ausgänge des Moduls einem Teilprozessabbild (PIP) zugewiesen werden. Die Daten dieses Teilprozessabbilds können dann synchron zu dem in dieser Maske definierten Organisationsbausteinen (OB) aktualisiert werden. Beitrags-ID: , V1.0, 10/2015 6

7 2 Signalerfassung und -ausgabe am Prozess Hinweis Durch die Zuordnung der Ein- und Ausgänge des Moduls zu einem Teilprozessabbild (PIP), sind diese Ein- und Ausgänge von der automatischen Aktualisierung der E/A-Daten im zyklischen Organisationsbaustein MAIN ausgeschlossen. Hinweis Jedem Synchron-OB Synchronous Cycle kann nur ein Teilprozessabbild (PIP) zugeordnet werden. Jedem Teilprozessabbild (PIP) kann nur eine begrenzte Anzahl an Ein- und Ausgängen zugeordnet werden. Wird ein Modul der dezentralen Peripherie dem taktsynchronen Betrieb zugeordnet, wird automatisch auch die Bus-Schnittstelle der dezentralen Peripherie, im gezeigten Beispiel ist das die PROFINET-Schnittstelle der Kopfbaugruppe in den taktsynchronen Betrieb gesetzt. Abbildung 2-2 Automatische Einstellung der Taktsynchronität an der Kopfbaugruppe Antrieb als dezentrale Peripherie Bei einem Antrieb als dezentrale Peripherie können die Parameter für den taktsynchronen Betrieb ebenfalls über die Eigenschaften zur Einstellung der E/A-Adressen eingestellt werden. Hier ist jedoch zu beachten, dass die E/A-Adressen des Antriebs dem entsprechenden Antriebstelegramm zugeordnet sind. Man findet die entsprechenden Parameter in den Eigenschaften des Antriebstelegramms. Beitrags-ID: , V1.0, 10/2015 7

8 2 Signalerfassung und -ausgabe am Prozess Abbildung 2-3 Einstellung der E/A-Adressen des Antriebstelegramms Zusätzlich muss auch an der Bus-Schnittstelle des Antriebs, im gezeigten Beispiel ist das die PROFINET-Schnittstelle, ebenfalls die Taktsynchronität aktiviert werden. Über diese Einstellungen kann dann auch der Sendetakt für die taktsynchrone Verbindung und die Zeitspanne und für das Einlesen und Ausgeben der Signale bzw. der Telegrammdaten im Antrieb definiert werden. Hinweis In der detaillierten Übersicht der Einstellungen der Taktsynchronität kann überprüft werden, ob die gewünschten Antriebsmodule bzw. Achsen sich ebenfalls im taktsynchronen Betrieb befinden. Gegebenenfalls kann durch Setzen des Hakens in der Übersicht das Antriebsmodul bzw. die Achse in den taktsynchronen Betrieb aufgenommen werden. Beitrags-ID: , V1.0, 10/2015 8

9 2 Signalerfassung und -ausgabe am Prozess Abbildung 2-4 Einstellung der Taktsynchronität der PROFINET-Schnittstelle des Antriebs Antrieb mit Technologieobjekt Achse Wird der Antrieb über die CPU-internen Motion Control Funktionen gesteuert, werden beim Anlegen eines Technologieobjekts Achse und der Zuordnung des Antriebs zu diesem Technologieobjekt automatisch die notwendigen Einstellungen am Antrieb vorgenommen. Abbildung 2-5 Zuordnung des Antriebs an das Technologieobjekt Achse Beitrags-ID: , V1.0, 10/2015 9

10 2 Signalerfassung und -ausgabe am Prozess Abbildung 2-6 Einstellung der E/A-Adressen des Antriebstelegramms Eine weitere Besonderheit entsteht, wenn der Antrieb über die CPU-internen Motion Control Funktionen gesteuert werden soll. Wird in der SIMATIC CPU eine Achse angelegt, werden im Programm automatisch die Organisationsbausteine MC-Servo und MC-Interpolator angelegt. Abbildung 2-7 Programmbausteine bei Nutzung der CPU-internen Motion-Funktionen Der Antrieb wird beim Anlegen der Achse dann automatisch dem Organisationsbaustein MC-Servo und dem Teilprozessabbild PIP OB Servo zugeordnet. Um die taktsynchrone Verbindung zwischen dem Technologieobjekt Achse in der SIMATIC CPU und dem Antrieb vollständig einzustellen, muss nun noch in den Eigenschaften des Organisationsbausteins MC-Servo erreichbar über das Beitrags-ID: , V1.0, 10/

11 2 Signalerfassung und -ausgabe am Prozess Kontextmenü des Bausteins in der Baumansicht die synchrone Bearbeitung des Bausteins zum Datenbus eingestellt werden. Abbildung 2-8 Eigenschaften des Organisationsbausteins MC-Servo Untersetzung der Synchron-OBs Den Applikationszyklus eines Synchron-OBs können Sie zum Sendetakt eines taktsynchronen PROFINET IO-Systems untersetzen. Als Faktor können Sie ein ganzzahliges Vielfaches des Sendetakts einstellen. Für den Applikationszyklus sind Werte bis zum 14-fachen des Sendetakts (maximal 32 ms) möglich. Damit kann die Belastung der SIMATIC CPU reduziert werden und eine taktsynchrone Verarbeitung von Signalen in der CPU mit einer längeren Zykluszeit des Taktsynchron-OBs als der Sendetakt der taktsynchronen PROFINET-Verbindung ermöglicht werden. Untersetzung des OB Synchronous Cycle In den Eigenschaften des Organisationsbausteins Synchronous Cycle erreichbar über das Kontextmenü des Bausteins in der Baumansicht kann die synchrone Bearbeitung des Bausteins zum Datenbus eingestellt werden. Abbildung 2-9 Einstellung eines Untersetzungsfaktors am OB Synchronous Cycle Über den Faktor kann die Belastung der SIMATIC CPU durch die Ausführung des Organisationsbausteins Synchronous Cycle reduziert werden. Der Organisationsbaustein wird in der im Beispiel gezeigten Einstellung nur noch nach jedem vierten Datenaustausch über den Datenbus in der SIMATIC CPU aufgerufen. Beitrags-ID: , V1.0, 10/

12 2 Signalerfassung und -ausgabe am Prozess Abbildung 2-10 Einstellung des Untersetzungsfaktors 4 und automatischer Verzögerung Untersetzung des OB MC-Servo Ebenso kann in den Eigenschaften des Organisationsbausteins MC-Servo erreichbar über das Kontextmenü des Bausteins in der Baumansicht die synchrone Bearbeitung des Bausteins für das integrierte Motion Control der SIMATIC CPU zum Datenbus eingestellt werden. Abbildung 2-11 Einstellung eines Untersetzungsfaktors am OB MC-Servo Hinweis Über den Untersetzungsfaktor des Organisationsbausteins MC-Servo wird jedoch auch die Achsregelung des Technologieobjekts Achse beeinflusst. Störeinflüsse an der Achse können gegebenenfalls durch einen zu hoch eingestellten Untersetzungsfaktor nicht mehr zufriedenstellend ausgeregelt werden. Gleichzeitige Nutzung beider Synchron-OBs Soll in einer Applikation sowohl die taktsynchrone Verarbeitung von Signalen im Organisationsbausteins Synchronous Cycle als auch die Funktionalität des integrierten Motion Control der SIMATIC CPU genutzt werden, kann ebenfalls zur Reduzierung der CPU-Belastung eine Untersetzung der Synchron-OBs eingestellt werden. Dabei muss die Untersetzung an allen beteiligten Taktsynchron-OBs, die Daten untereinander nutzen oder austauschen sollen, auf den gleichen Faktor eingestellt werden. Hinweis Sollen mehrere Taktsynchron-OBs Daten untereinander nutzen, muss die Untersetzung an allen Taktsynchron-OBs auf den gleichen Wert eingestellt werden. Beitrags-ID: , V1.0, 10/

13 3 Die Sync-Domain 3 Die Sync-Domain 3.1 Einstellung einer Sync-Domain im Netz Über die Sync-Domain wird die Zuordnung der einzelnen dezentralen Peripheriestationen (Sync-Slaves) zu einer SIMATIC CPU (Sync-Master) in Bezug auf den taktsynchronen Datenaustausch vorgenommen. Die Eigenschaften der Sync-Domain erreicht man in der Netzsicht durch einen Doppelklick auf das entsprechende Netzwerk. In der Anzeige der IO-Devices kann dann die Festlegung des Sync-Master und der dem Master zugeordneten Sync-Slaves vorgenommen werden. Abbildung 3-1 Übersicht der Eigenschaften einer Sync-Domain Hinweis Für den taktsynchronen Datenaustausch muss an den Sync-Slaves für die RT Class stets die Einstellung IRT gewählt werden. 3.2 Übersicht der Einstellungen der Taktsynchronität Im gleichen Eigenschaftendialog wird auch eine Übersicht der Einstellungen der Taktsynchronität angeboten. Über diese Übersicht kann man sich die durchgeführ- Beitrags-ID: , V1.0, 10/

14 3 Die Sync-Domain ten Einstellungen im Überblick anzeigen lassen. Zusätzlich sind hier jedoch auch noch übergreifende Einstellungen in der Sync-Domain möglich. Abbildung 3-2 Übersicht der Einstellungen der Taktsynchronität In der Übersicht der IO-Devices kann man in der Spalte /-Settings noch zwischen folgenden Einstellungen auswählen: Abbildung 3-3 Einstellung der /-Settings Die Einstellungen haben folgende Bedeutung: Automatic Minimum: Das ist die Standard-Einstellung. Für die Zeitspanne und wird jeweils die minimale Zeit ausgewählt. Die Zeiten sind in dieser Einstellung für jede dezentrale Peripheriestation unterschiedlich und können sich durch Veränderung der Hardware-Konfiguration ändern. Sollen die Zeitspannen und im Anwenderprogramm genutzt werden, muss darauf geachtet werden, dass die richtige, dem entsprechenden Signal zugeordnete Zeitspanne oder benutzt wird. Manual: In dieser Einstellung können die Zeitspannen und manuell in der Übersicht vorgegeben werden. Die vorgegebenen Zeitspannen müssen dabei größer oder gleich dem möglichen Minimum sein und müssen bei Veränderung der Hardware-Konfiguration gegebenenfalls angepasst werden. From OB: In dieser Einstellung können die Zeitspannen und zentral für alle dezen- Beitrags-ID: , V1.0, 10/

15 3 Die Sync-Domain tralen Peripheriestationen gleich vorgegeben werden. Diese Einstellung empfiehlt sich, wenn die Zeitspannen und im Anwenderprogramm als Einstellparameter oder als Festwerte genutzt werden sollen, da dann für jedes Signal die gleiche Zeitspanne und gilt. Die zentrale Einstellung der Zeitspannen und erfolgt über die Einstellmaske oberhalb der Übersicht der IO-Devices. Abbildung 3-4 Zentrale Einstellung der Zeitspannen und Werden die Werte zusätzlich noch manuell vorgegeben, kann für die Verwendung der Zeitspannen und im Anwenderprogramm ein geeigneter, einfach zu handhabender Wert (mit wenigen Nachkommastellen) gewählt werden. Beitrags-ID: , V1.0, 10/

16 4 Programmierung im Synchron-OB 4 Programmierung im Synchron-OB 4.1 Die Funktionen SYNC_PI und SYNC_PO Die Systemfunktionen SYNC_PI und SYNC_PO können nur in den Synchron-OBs aufgerufen werden und sind für die taktsynchrone und konsistente Aktualisierung des dem Synchron-OB zugeordneten Teilprozessabbilds zuständig. Über die Anordnung des Aufrufs der beiden Systemfunktionen im Synchron-OB kann die Aktualisierung des Teilprozessabbilds genau festgelegt werden. 4.2 Das EVA-Modell Einlesen (E): Beim EVA-Modell wird zuerst im Netzwerk 1 das Teilprozessabbild des Synchron- OB eingelesen. Im Beispiel ist es das Teilprozessabbild 1 (PIP 1), wie am Eingang PART des Bausteins SYNC_PI definiert. Damit werden die Eingänge des Teilprozessabbilds eingelesen und im Synchron-OB zur Verfügung gestellt. Verarbeiten (V): Im Netzwerk 2 kann dann das eigentliche Anwenderprogramm des Synchron-OB programmiert werden. Ausgeben (A): Im Netzwerk 3 werden dann die über das Anwenderprogramm veränderten Daten über die Ausgänge des Teilprozessabbild 1 (PIP 1) ausgegeben. Abbildung 4-1 Programmierung des EVA-Modell im Synchron-OB Hier kann das eigentliche Anwenderprogramm programmiert werden Beitrags-ID: , V1.0, 10/

17 4 Programmierung im Synchron-OB Hinweis Das EVA-Modell sollte nur zur Anwendung kommen, wenn sichergestellt ist, dass die Laufzeit des Synchron-OB immer deutlich kürzer ist als der Takt (Send Clock) des Kommunikationsnetzes. Die Ausgabedaten des Synchron-OB können so immer mit dem nächsten Buszyklus übertragen werden. Wird mit einer Taktuntersetzung zwischen Applikationszyklus (Aufruftakt des Synchron-OB) und Buszyklus des Kommunikationsnetzes gearbeitet, kann die oben aufgestellte Forderung in der Regel nicht eingehalten werden. In diesem Fall sollte das AEV-Modell zum Einsatz kommen. 4.3 Das AEV-Modell Ausgeben (A): Beim AEV-Modell werden zuerst im Netzwerk 1 die im vorherigen Zyklus über das Anwenderprogramm veränderten Daten über die Ausgänge des Teilprozessabbild 1 (PIP 1) ausgegeben. Einlesen (E): Im Netzwerk 2 werden dann die Eingänge des Teilprozessabbilds des aktuellen Zyklus des Synchron-OB eingelesen. Verarbeiten (V): Im Netzwerk 3 kann dann das eigentliche Anwenderprogramm des Synchron-OB programmiert werden. Abbildung 4-2 Programmierung des AEV-Modell im Synchron-OB Hier kann das eigentliche Anwenderprogramm programmiert werden Beitrags-ID: , V1.0, 10/

18 4 Programmierung im Synchron-OB Hinweis Wird mit einer Taktuntersetzung zwischen Applikationszyklus (Aufruftakt des Synchron-OB) und Buszyklus des Kommunikationsnetzes gearbeitet, bietet die Nutzung des AEV-Modells Vorteile. Beim AEV-Modell wird das Schreiben der Ausgänge und das Einlesen der Eingänge des Teilprozessabbilds im Synchron-OB immer im gleichen Bustakt des Kommunikationsnetzes durchgeführt. Der Datenaustausch mit dem Prozess findet daher immer deterministisch, d.h. zu einem genau festgelegten Zeitpunkt, bezogen auf die Ausführung des Synchron-OB, statt. 4.4 Beispiele zu den Modellen Die Auswahl des geeigneten Datenverarbeitungsmodells in einer Anwendung soll nun nochmals durch zwei Beispiele verdeutlicht werden Voraussetzung In den beiden hier dargestellten Beispielen wird von folgendem Verhalten der Anwendungen und von folgenden Einstellungen im Projekt ausgegangen: Zwischen dem Applikationszyklus (Aufruftakt des Synchron-OB) und dem Buszyklus des Kommunikationsnetzes ist eine Untersetzung von 1:2 eingestellt, d.h. während der möglichen Laufzeit des Applikationszyklus kann es zweimal zum Austausch von Daten über das Kommunikationsnetz kommen. Das Anwenderprogramm im Applikationszyklus ist so gestaltet, dass es zu stark unterschiedlichen Programmlaufzeiten im Synchron-OB kommen kann Nutzung des EVA-Modells Der Datenfluss und die Datenverarbeitung für einen Applikationszyklus ist in der nachfolgenden Grafik farblich hervorgehoben dargestellt: Abbildung 4-3 Datenaustausch im Syncronous Cycle nach dem EVA-Modell me-based IO ming (Synchronous Cycle with fluctuating cycle time and Sync_PI and Sync_PO EVA data processing) TIO_me TIO_me TIO_me me CPU I Synchronous Cycle O I Synchronous Cycle O Application-Cycle Application-Cycle Bus Data Data Data Data Data Rückwandbus Modul PROFINET-Cycle PROFINET-Cycle PROFINET-Cycle PROFINET-Cycle Prozess Process Data Process Data Process Data Process Data Legend: I = Function block SYNC_PI O = Function block SYNC_PO Der Austausch der Daten erfolgt bei diesem Datenverarbeitungsmodell möglichst zeitnah zur Verarbeitung. Die Daten werden eingelesen, im Synchron-OB verarbeitet und danach im nächst möglichen Bustakt wieder an den Prozess ausgegeben. Beitrags-ID: , V1.0, 10/

19 4 Programmierung im Synchron-OB Vergleicht man jedoch die beiden aufeinanderfolgenden Synchron-OBs mit unterschiedlich langer Laufzeit, stellt man fest, dass durch diese Wahl des Datenverarbeitungsmodells kein deterministischer Datenaustausch mit dem Prozess möglich ist. Bei langer Synchron-OB Laufzeit liegen zwischen dem Einlesen der Prozesssignale und dem Ausgaben der verarbeiteten Signale an den Prozess zwei Bustakte. Bei kurzer Synchron-OB Laufzeit kann dieser Prozess auch nur einen Bustakt in Anspruch nehmen. Fazit Wird zwischen dem Applikationszyklus und dem Bustakt eine Untersetzung genutzt und schwankt die Ausführungszeit des Synchron-OB bedingt durch das Anwenderprogramm, so ist die Nutzung des EVA-Modells nicht zu empfehlen. Das EVA-Modell sollte nur eingesetzt werden, wenn die Ausführungszeit des Synchron-OBs immer konstant ist oder keine Untersetzung eingestellt ist. Dann bietet dieses Modell einen Geschwindigkeitsvorteil in der Verarbeitung von Prozess-Signalen Nutzung des AEV-Modells Der Datenfluss und die Datenverarbeitung für einen Applikationszyklus ist auch in dieser Grafik farblich hervorgehoben dargestellt: Abbildung 4-4 Datenaustausch im Syncronous Cycle nach dem AEV-Modell me-based IO ming (Synchronous Cycle with fluctuating cycle time and Sync_PI and Sync_PO AEV data processing) TIO_me TIO_me TIO_me me CPU O I Synchronous Cycle O I Synchronous Cycle Application-Cycle Application-Cycle Bus Data Data Data Data Data Rückwandbus Modul PROFINET-Cycle PROFINET-Cycle PROFINET-Cycle PROFINET-Cycle Prozess Process Data Process Data Process Data Process Data Legend: I = Function block SYNC_PI O = Function block SYNC_PO Man erkennt in der Grafik sofort den langen Zeitraum zwischen dem Einlesen der Prozess-Signale und der Ausgabe der verarbeiteten Signale an den Prozess von drei Bustakten. Das AEV-Modell ist bei eingestellter Untersetzung somit langsamer im Signalaustausch als das EAV-Modell. Durch die festgelegte Ausgabe der Signale aus dem vorherigen Synchron-OB Lauf vor dem Einlesen der Eingangssignale und der Verarbeitung im Synchron-OB ist jedoch sofort das deterministische Verhalten dieses Modells erkennbar. Unabhängig von der Laufzeit des Synchron-OBs wird das Einlesen und Ausgeben der Signale aus Sicht des Prozesses zum immer gleichen Zeitpunkt durchgeführt. Fazit Trotz des langsameren Datenaustauschs des AEV-Modells verglichen mit dem EVA-Modell ist dieses Datenverarbeitungsmodell bei der Verwendung einer Untersetzung und unterschiedlich langen Synchron-OB Laufzeiten zu bevorzugen. Beitrags-ID: , V1.0, 10/