DE102013005542A1

DE102013005542A1 - Verfahren und Steuerungsvorrichtung zur Ausgabe von Daten auf einen Lokalbus

Info

Publication number: DE102013005542A1
Application number: DE201310005542
Authority: DE
Inventors: Thomas Geffers
Original assignee: Phoenix Contact GmbH and Co KG
Current assignee: Phoenix Contact GmbH and Co KG
Priority date: 2013-04-03
Filing date: 2013-04-03
Publication date: 2014-10-09
Also published as: WO2014161855A1; DE102013005542A8

Abstract

Die Erfindung beschreibt ein Verfahren und eine Steuerungsvorrichtung zur Ausgabe von Daten auf einen Lokalbus, unter Verwendung eines echtzeitfähigen Betriebssystems mit einem Systemtakt, einem SPS-Laufzeitsystem zur Ausführung von SPS-Tasks, und einer Anschalt- und Steuereinrichtung zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS-Task erhaltenen Daten auf einen angeschalteten Lokalbus, wobei das SPS-Laufzeitsystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, gekoppelt sind.

Description

Zur Herstellung eines synchronen Betriebs zwischen einem SPS(Speicher-Programmierbare-Steuerung)-Laufzeitsystem und einem lokalen I/O(Input/Output)-Bus mit dem Ziel der Jitter-Minimierung bedarf es in der Regel einer hardwareunterstützten Synchronisierung dieser Komponenten, bei der sowohl die CPU (Central Processing Unit) als auch die Logik des Lokalbusses von einem durch Hardware generierten Signal getriggert werden muss. Steht dieses Signal nicht zur Verfügung oder sprechen andere Gründe gegen eine hardwareunterstützte Synchronisierung, wie z. B. die Komplexität der FPGA(Frei Programmierbaren Gate Array)-Modelle oder die damit verbundenen Kosten, laufen das SPS-Laufzeitsystem und der Lokalbus asynchron zu einander.
Werden dann z. B. I/O-Daten stets nach Abschluss eines jeweiligen SPS-Zyklusses direkt auf den Lokalbus ausgegeben, hat dies in der Regel zur Folge, dass ungleichmäßige Bearbeitungsdauern von SPS-Tasks oder auch der allgemeine Systemjitter, z. B. hervorgerufen durch die Interrupt-Last und also durch kurzfristige Unterbrechungen der normalen Programmausführung, um andere, meist kurze, aber zeitkritische Verarbeitungen durchzuführen, sich ungefiltert auf den Lokalbus auswirken und dort als unerwünschte Jitter, d. h. Störungen, die eine Genauigkeitsschwankung im Übertragungstakt hervorrufen, erkennbar sind. Je kleiner jedoch die vorgegebene Zykluszeit und das Zeitraster von aufeinanderfolgenden Zyklen eines Lokalbusses sind, desto gravierender sind die Auswirkungen solcher Jitter auf den Lokalbus und verhindern deterministische Ausgaben von I/O-Daten auf dem Lokalbus.
Eine Synchronisierung ausgehend vom Lokalbus zur Erzielung deterministischer Ausgaben von I/O-Daten auf den Lokalbus, z. B. indem nach jedem Zyklus ein ”Zyklus beendet” Interrupt generiert wird, hat zumindest dann ihre Grenzen, wenn die Zykluszeiten so schnell sind, dass dadurch das komplette System blockiert werden würde und/oder der Lokalbus dahingehend ausgelegt ist, dass systembedingt permanent Zyklen gefahren werden müssen und somit keine künstlichen Pausen zwischen den Zyklen eingebaut werden dürfen.
Insbesondere in Fällen eines Lokalbusses mit extrem kurzen und/oder systembedingt permanent zu fahrenden Zyklussen können die Jitter-Werte zum Einen zu hoch und zum Anderen derart nicht deterministisch sein, da die Größe eines jeden Jitters von vielen Systemparametern abhängt, wie z. B. von der SPS-Zykluszeit, dem Jitter der Ausführungsdauer einer SPS-Task und/oder der Interrupt Last, dass die im asynchronen Betrieb erzielten Werte des Jitters auf einem Lokalbus unbefriedigend sind und sich folglich Prozess-störend, gegebenenfalls auch sicherheitskritisch auf die an den Lokalbus angeschlossenen Lokalbus-Teilnehmer auswirken.
Eine Aufgabe der Erfindung ist es, einen Weg zur Synchronisierung eines SPS-Laufzeitsystems mit einem lokalen I/O Bus mit dem Ziel zu schaffen, den Jitter auf dem lokalen I/O Bus einerseits absolut zu minimieren sowie andererseits die durchschnittlichen Abweichungen vom Mittelwert des Jitters zu minimieren, so dass die Werte des Jitters unabhängig von den Systemparametern ansonsten konstant bleiben.
Die Lösung der Aufgabe ist durch ein Verfahren sowie eine Steuerungsvorrichtung mit den Merkmalen der unabhängigen Ansprüche gegeben. Vorteilhafte oder zweckmäßige Ausführungen und Weiterbildungen sind Gegenstand der abhängigen Ansprüche.
Die Erfindung schlägt folglich als eine Lösung ein Verfahren zum Betreiben einer Steuerungsvorrichtung, welche ein SPS-Laufzeitsystem zur Ausführung von SPS-Tasks und eine Anschalt- und Steuereinrichtung zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung bestimmter SPS-Tasks erhaltenen Daten auf einen angeschalteten Lokalbus aufweist, vor, ein echtzeitfähiges Betriebssystem mit einem Systemtakt vorzusehen und das SPS-Laufzeitsystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, zu koppeln.
Ferner schlägt die Erfindung als Lösung eine Steuerungsvorrichtung vor, welche ein echtzeitfähiges Betriebssystem mit einem Systemtakt, ein SPS-Laufzeitsystem zur Ausführung von SPS-Tasks sowie eine Anschalt- und Steuereinrichtung zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS-Applikation erhaltenen Daten auf einen angeschalteten Lokalbus aufweist, und wobei das SPS-Laufzeitsystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, gekoppelt sind.
Die Erfindung schlägt zur Synchronisierung eines SPS-Laufzeitsystems mit einem lokalen I/O-Bus folglich zwei in einander greifende Komponenten bzw. Maßnahmen vor. Zum Einen die Kopplung des SPS-Laufzeitsystems an ein Taktgebersignal für den Systemtakt des Betriebssystems und zum Anderen die Kopplung der Steuerung der Ausgabe auf den Lokalbus an dasselbe Taktgebersignal, welches insbesondere der Systemtick ist. Durch das Zusammenspiel beider Maßnahmen wird eine Synchronisierung zwischen SPS-Laufzeitsystem und lokalem I/O-Bus erreicht, und also das SPS-Laufzeitsystem und der lokale I/O-Bus aufeinander abgestimmt.
In einer bevorzugten Ausführung sieht die Erfindung hierbei vor, durch Ausführung einer SPS-Task erhaltene Daten, welche auf den Lokalbus auszugeben sind, in einem ersten Schritt in einen von wenigstens zwei Buffer abzulegen, welcher nicht an den angeschalteten Lokalbus gekoppelt ist und in einem zweiten Schritt einen Wechsel der Buffer durchzuführen, so dass der Buffer mit den abgelegten Daten an den angeschalteten Lokalbus gekoppelt wird und in einem dritten Schritt die abgelegten Daten auf den angeschalteten Lokalbus ausgeben werden.
In einer bevorzugten Ausführung sieht die Erfindung vor, dass unter Ansprechen auf ein Interrupt von dem Betriebssystem hin und bei Vorliegen von Daten in einem Buffer, zunächst die Ausgabe dieser Daten auf den Lokalbus gesteuert wird, insbesondere ein Bufferwechsel durchgeführt wird und die Daten in dem dann an den angeschalteten Lokalbus gekoppelten Buffer auf diesen ausgegeben werden, und anschließend eine SPS-Task zum Erhalt von weiteren auf den angeschalteten Lokalbus auszugebenden Daten gestartet wird.
In einer bevorzugten Ausführung sieht die Erfindung vor, nach Ausführung der SPS-Task zum Erhalt von auf den angeschalteten Lokalbus auszugebenden Daten und Ablage dieser Daten in dem Buffer für die Anschalt- und Steuereinrichtung ein Signalisierungsflag zu setzen, wobei bei gesetztem Signalisierungsflag auf das Vorliegen von Daten in einem Buffer, welcher nicht an den angeschalteten Lokalbus gekoppelt ist, erkannt wird.
Im Folgenden wird der bisherige Stand der Technik sowie der Erfindungsgedanke anhand von Ausführungsbeispielen in den beigefügten Figuren näher erläutert. Hierbei zeigen:
1 ein prinzipiell möglicher interner Aufbau zwischen einem SPS Laufzeitsystem und einem Lokalbus nach dem Stand der Technik;
2 einen zeitlichen Verlauf eines asynchronen Betriebs aufbauend auf einem internen Aufbau zwischen einem SPS Laufzeitsystem und einem Lokalbus nach dem Stand der Technik gemäß 1;
3 ein Beispiel eines prinzipiell möglichen internen Aufbaus zwischen einem SPS Laufzeitsystem und einem Lokalbus im Rahmen der Erfindung; und
4: einen zeitlichen Verlauf eines synchronen Betriebs im Rahmen der Erfindung aufbauend auf einem Aufbau gemäß 3, am Beispiel einer mit Firmware basierenden Synchronisierung.
1 zeigt ein Ausführungsbeispiel eines prinzipiell möglichen internen Aufbaus zwischen einem SPS Laufzeitsystem und einem Lokalbus nach dem Stand der Technik;
Skizziert ist eine Steuerungsvorrichtung 100, welche z. B. eine Kompaktsteuerung mit integriertem Ethernet- und Lokalbus-Anschluss sein kann. Die Steuerungsvorrichtung stellt als Kopf einer Lokalbus-Station die Funktion einer Steuerung zur Verfügung. Der Lokalbus 500 wird aufgebaut, indem Lokalbus-Module an die Steuerungsvorrichtung angereiht werden.
Die Steuerungsvorrichtung 100 umfasst ein echtzeitfähiges Betriebssystem mit einem Systemtakt, z. B. als Herstellereigene Firmware 200, und bietet einer SPS zur Ausführung von SPS-Tasks ein Laufzeitsystem 300. Ein solches Laufzeitsystem kann im Rahmen der Erfindung zweckmäßig ein eCLR-Laufzeitsystem (Embedded Common Language Runtime) sein.
Ferner weist die Steuerungsvorrichtung 100 eine Anschalt- und Steuereinrichtung 400 auf, zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS-Tasks erhaltenen Daten auf einen angeschalteten Lokalbus. Die Anschalt- und Steuereinrichtung 400 kann somit eine Schnittstelle für die Lokalbus-Module 500 zur Verfügung stellen.
Die Anschalt- und Steuereinrichtung 400 kann hierbei in der Steuerungsvorrichtung 100 vorintegriert sein oder mit dieser über entsprechende Schnittstellen, insbesondere modulhaft, verbunden sein.
Das SPS-Laufzeitsystem bietet das Umfeld, dass zu bestimmten Zeiten eine SPS-Task 310 abgearbeitet wird, wodurch Daten erhalten werden, die auf einem angeschalteten Lokalbus 500 und daran angeschlossenen Lokalbus-Teilnehmern zur Verfügung zu stellen sind. Bei diesen Daten kann es sich im Rahmen der Erfindung folglich bevorzugt um I/O Daten handeln, insbesondere um Prozessdaten, die ein jeweils aktuelles Datenbild eines jeweiligen (Teil-)Prozesses darstellen. Um nach einer jeweiligen Abarbeitung einer solchen SPS-Task 310 dann die erhaltenen Daten, und also insbesondere das aktualisierte Prozessdatenbild dem Lokalbus zur Verfügung zu stellen, ist eine Einrichtung 320, z. B. ein I/O-Treiber, vorgesehen.
Die Anschalt- und Steuereinrichtung 400 kann hierfür ferner einen Buffer vorsehen, in welchem die auf den Lokalbus auszugebenden Daten vor Ausgabe zwischengespeichert werden können. So kann die Anschalt- und Steuereinrichtung 400 zweckmäßig mit einem wenigstens zwei Buffer 410, 420 umfassenden Wechselbuffer ausgebildet sein, wobei, z. B. mittels eines Bufferschalters 430, jeweils einer der Buffer wechselweise an einen angeschalteten Lokalbus zu koppeln ist, um die darin enthaltenen Daten auf den Lokalbus auszugeben. Anstelle des Vorhandenseins eines Wechselbuffers kann z. B. auch nur lediglich ein einziger Buffer vorgesehen sein, so dass dann, z. B. mittels des Bufferschalters 430, lediglich die im Buffer enthaltenen Daten auf den Lokalbus auszugeben sind.
Basierend auf obigen Ausführungen einer im Rahmen der Erfindung grundsätzlich einsetzbaren Steuerungsvorrichtung, besteht ein prinzipiell möglicher interner Aufbau zwischen dem SPS Laufzeitsystem 300 und dem Lokalbus 500 nach dem Stand der Technik gemäß 1 darin, dass nach Abarbeitung der SPS-Task 310 die Einrichtung 320 aufgerufen wird. Diese kopiert in einem ersten Schritt das Prozessdatenbild zunächst in den aktuell nicht benutzten Buffer, gemäß 1 in den Buffer 420, des Wechselbuffers und anschließend weist sie in einem zweiten Schritt die Anschalt- und Steuereinrichtung 400 für den Lokalbus an, den Bufferwechsel durchzuführen, um daraufhin in einem dritten Schritt das aktualisierte Prozessdatenbild auf den Lokalbus auszugeben.
Fehlt die Synchronisierung zwischen SPS-Laufzeitsystem 300 und Lokalbus 500, werden somit auch die zur Ausgabe an den Lokalbus vorgehaltenen Daten asynchron zum Zyklus des Lokalbusses auf diesen ausgegeben.
Basierend auf 1 wird nach dem Stand der Technik im asynchronen Betrieb somit wie folgt verfahren. Am Ende eines jeden SPS-Zyklusses wird das durch die SPS-Task 310 aktualisierte Prozessdatenabbild durch die Einrichtung 320 in den aktuell freien Buffer des Wechselbuffers für den Lokalbus 500 kopiert und die Anschalt- und Steuereinrichtung 400 für den Lokalbus unmittelbar angewiesen, den Bufferwechsel durchzuführen und somit die neuen Daten auf den Lokalbus auszugeben, z. B. sofort nach dem Bufferwechsel das aktualisierte Prozessdatenbild auf den Lokalbus auszugeben.
2 zeigt einen zeitlichen Verlauf eines asynchronen Betriebs aufbauend auf einem internen Aufbau zwischen einem SPS Laufzeitsystem und einem Lokalbus nach dem Stand der Technik gemäß 1.
Zu einem Zeitpunkt t₀ wird mittels eines Interrupt Request (IRQ) ein Interrupt generiert. Ein auf einen Interrupt Request zur Durchführung der anderen Verarbeitung folgendes Programm kann als Interrupt Service Routine (ISR) verstanden werden. Ist dieser Zeitpunkt z. B. der Systemtick für den Systemtakt des Betriebssystems, bei 2 mit „Systick” wiedergegeben, wird das Interrupt folglich mit einer Systick IRQ generiert. Die auf die IRQ folgende ISR, bei 2 aufgrund der angenommenen Systick IRQ als „OS (Operating System) Tick Handler” bezeichnet, ruft daraufhin mit einer Verzögerung t_d1 den Scheduler des SPS-Laufzeitsystems auf, welcher wiederum die SPS-Task 310 startet. Die Dauer der SPS-Task 310 ist mit t_d2 angegeben. Nach Abarbeitung der SPS-Task 310 werden dann die Ausgangsdaten in einen Buffer für den Lokalbus kopiert und daraufhin im Falle eines Wechselbuffers gemäß 1 die Anschalt- und Steuereinrichtung für den Lokalbus unmittelbar angewiesen, den Bufferwechsel durchzuführen, um dann zu einem Zeitpunkt t1, die Daten auf den Lokalbus auszugeben.
Zu einem nächstfolgenden Zeitpunkt t₀ wird der nächste Interrupt durch die Systick IRQ generiert, auf die wiederum die ISR „OS (Operating System) Tick Handler” folgt, für eine erneute Abarbeitung der SPS-Task 310. Die Kopplung des SPS-Laufzeitsystems an den Systemtick kann zweckmäßig dadurch erfolgen, dass der Aufruf des SPS Laufzeitsystem Schedulers aus einer speziell für diesen Zweck angelegten hochprioren Task, z. B. einer sogenannten Systemtick Task, erfolgt.
Maßgeblich für den Jitter ist folglich zusammenfassend jedoch die Verzögerung t_d1 des Aufrufs des SPS Schedulers nach einem Interrupt, der z. B. durch eine Systick Interrupt Request (IRQ) zum Zeitpunkt t₀ hervorgerufen wird, sowie die Dauer t_d2 der SPS Task 310. Der in Bezug auf den Lokalbus unerwünschte Jitter ist letztendlich das Delta über die Zeit zwischen aufeinander folgenden Zeitpunkten t₁. Der Jitter entspricht somit im Wesentlichen der in 2 dargestellten Zeitspanne t_j.
3 zeigt nunmehr ein Beispiel eines prinzipiell möglichen internen Aufbaus zwischen einem SPS Laufzeitsystem und einem Lokalbus im Rahmen der Erfindung.
In Abwandlung zum prinzipiell möglichen internen Aufbau zwischen einem SPS Laufzeitsystem und einem Lokalbus nach 1 wird gemäß Lösung nach der Erfindung wie folgt verfahren.
Die Ausgabe der Daten auf den Lokalbus 500, basierend auf 3 zweckmäßig bereits die Initiierung des Bufferwechsels, wird erfindungsgemäß von der Abarbeitung der SPS-Task 310 entkoppelt und stattdessen an ein Taktgebersignal für den Systemtakt, insbesondere den Systemtick des Systemtaktes, gekoppelt. Damit sich das SPS-Laufzeitsystems 300 synchron zum Lokalbus 500 verhält, und insbesondere der Scheduler des SPS-Laufzeitsystems 300, der unter anderem für den Start der SPS-Task 310 zuständig ist, wird das SPS-Laufzeitsystem 300, insbesondere der Scheduler des SPS-Laufzeitsystems 300 ebenfalls an dasselbe Taktgebersignal für den Systemtakt, und also insbesondere auch an den Systemtick des Systemtaktes, gebunden, z. B. indem direkt aus der entsprechenden Interrupt Service Routine des Interrupts der Aufruf der Schedulers getriggert wird.
Damit dient ein einziges Taktgebersignal für den Systemtakt, insbesondere der Systemtick, und insbesondere dessen entsprechende Interrupt Service Routine, als Koppelglied zwischen SPS-Laufzeitsystem 300 und Lokalbus 500.
Ferner wird gemäß Erfindung zweckmäßig vor Abarbeitung der SPS-Task 310 immer zunächst in einem ersten Schritt die Funktion eines optionalen Bufferwechsels und einer hierauf in einem zweiten Schritt basierenden Ausgabe der Daten des dann aktuell benutzen Buffers auf den Lokalbus 500 aufgerufen. Ist anstelle des Vorhandenseins eines Wechselbuffers nur lediglich ein einziger Buffer vorgesehen, wird folglich gemäß Erfindung zweckmäßig vor Abarbeitung der SPS-Task 310 immer zunächst die Funktion einer optionalen Ausgabe von Daten des Buffers auf den Lokalbus 500 aufgerufen.
Anschließend wird dir SPS-Task 310 abgearbeitet und die hierauf zur Ausgabe auf den Lokalbus 500 erhaltenen Daten in einem Buffer abgelegt. So wird z. B. basierend auf 3 nach Abarbeitung der SPS-Task 310 die Einrichtung 320 aufgerufen, um in einem dritten Schritt das Prozessdatenbild zunächst in den aktuell nicht benutzten Buffer, gemäß 3 in den Buffer 420, des Wechselbuffers der Anschalt- und Steuereinrichtung 400 für den Lokalbus 500 zu kopieren. Anstelle jedoch unmittelbar einen Bufferwechsel zu initiieren oder alternativ bei Vorhandensein nur eines Buffers lediglich die Ausgabe vom im Buffer enthaltenen Daten auf den Lokalbus zu initiieren, wird bevorzugt lediglich ein Flag für die Anschalt- und Steuereinrichtung 400 für den Lokalbus 500 gesetzt, zur Signalisierung, dass neue Daten vorliegen.
Der eigentliche Bufferwechsel und die hierauf basierende Ausgabe der Daten des dann aktuell benutzen Buffers auf den Lokalbus 500 oder alternativ im Falle lediglich eines einzigen Buffers die Ausgabe von Daten des Buffers auf den Lokalbus 500 wird dann durch den nächstfolgenden globalen Systemtick aufgerufen, und zwar unmittelbar vor der dann nächstfolgenden Abarbeitung der SPS-Task 310.
4 zeigt einen zeitlichen Verlauf eines synchronen Betriebs im Rahmen der Erfindung aufbauend auf einem Aufbau gemäß 3, am Beispiel einer mit Firmware basierenden Synchronisierung gemäß der Erfindung.
Wie in Bezug auf 3 bereits beschrieben, besteht die Implementierung aus zwei ineinander greifenden Komponenten bzw. Maßnahmen, zum Einen die Kopplung des SPS-Laufzeitsystems an ein Taktgebersignal für den Systemtakt des Betriebssystems, insbesondere an den Systemtick des Systemtakts, und zum Anderen die Kopplung der Steuerung der Ausgabe auf den Lokalbus an dasselbe Taktgebersignal für den Systemtakt des Betriebssystems und also insbesondere an den Systemtick des Systemtakts.
Wie bei 4 zu sehen, kann die Kopplung des SPS-Laufzeitsystems an den Systemtick, wie bereits in Bezug auf 2 aufgezeigt, zweckmäßig dadurch erfolgen, dass der Aufruf des SPS Laufzeitsystem Schedulers aus einer speziell für diesen Zweck angelegten hochprioren Task, z. B. einer sogenannten Systemtick Task, erfolgt. Um jedoch, im Gegensatz zu 2, den Jitter t_d1 des Aufrufs des SPS Laufzeitsystem Schedulers zu minimieren, wird vorzugsweise ferner ein Betriebssystem-Event, auch als OS(Operating System)-Event bezeichnet, angelegt, auf welches in der Systemtick Task dann vor Aufruf des Schedulers des SPS Laufzeitsystems gewartet wird.
Das Triggern dieses OS-Events erfolgt ferner zweckmäßig direkt aus der Interrupt Service Routine (ISR) des Systemtick Interrupts heraus. Damit der Jitter des Aufrufs des SPS Laufzeitsystem Schedulers nochmals minimiert wird, ist in besonders bevorzugter Ausführung zum Einen die Systemtick Task diejenige Task im System mit höchster Priorität und zum Anderen der Systemtick Interrupt seinerseits ebenfalls derjenige Interrupt im System, dem die höchste Priorität zugewiesen wurde.
Nach Abschluss der Abarbeitung einer SPS Task 310 werden die aktuellen Ausgangsdaten in einen Buffer der Anschalt- und Steuereinrichtung für den Lokalbus geschrieben, z. B. in den jeweils nicht genutzten Buffer eines Wechselsbufferss der Anschalt- und Steuereinrichtung für den Lokalbus, ohne jedoch unmittelbar die Ausgabe der Daten bzw. zuvor einen Bufferwechsel zu initiieren.
Stattdessen wird lediglich ein Flag zur Signalisierung, dass neue Daten vorliegen, gesetzt. Die eigentliche Ausgabe der Daten bzw. ein hierfür notwendiger vorheriger Bufferwechsel erfolgt dann in der oben genannten Interrupt Service Routine des Systemticks, und zwar vor dem Triggern des OS Events, durch Aufruf einer entsprechenden Schnittstellenfunktion der Anschalt- und Steuereinrichtung für den Lokalbus. In dieser Schnittstellenfunktion wird geprüft, ob das Flag zum Signalisieren eines erforderlichen Bufferwechsels gesetzt ist. Ist dies der Fall, wird die Ausgabe der Daten im Buffer bzw. alternativ zuvor der Bufferwechsel direkt im Kontext der Interrupt Service Routine in der Anschalt- und Steuereinrichtung für den Lokalbus, z. B. durch entsprechende Anweisung eines Bufferschalters, initiiert.
In der Interrupt Service Routine des Systemticks wird also immer zunächst die Funktion zur optionalen Ausgabe von Daten im Buffer bzw. zum optionalen vorherigen Bufferwechsel aufgerufen und anschließend die SPS-Task 310 bzw. insbesondere der SPS-Laufzeitsystems Scheduler.
Damit ist folglich das SPS-Laufzeitsystem als auch die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt des Betriebssystems, und insbesondere an den Systemtick, gekoppelt.
Bei einem typischen Intervall des Systemtick Timers von 1 ms werden somit die Ausgangsdaten höchstens einmal pro Millisekunde auf dem Lokalbus aktualisiert, dies allerdings synchron zum Taktgebersignal, insbesondere zum Systemtick, und somit mit minimiertem sowie geglättetem Jitter.
Maßgeblich für den Jitter ist gemäß 4 folglich zusammenfassend, dass durch die Verwendung eines OS Events zum Aufrufen der SPS-Task bzw. zum Triggern des SPS Laufzeitsystem Schedulers der Jitter von t_d1 nochmals wesentlich geringer und konstanter als beim asynchronen Betrieb gemäß 2 ist.
Der Jitter der SPS Task Ausführungsdauer t_d2 bleibt zwar unverändert, wird jedoch durch die auf den Zeitpunkt t₁ synchronisierte Datenausgabe bzw. bzw. den auf diesen Zeitpunkt synchronisierten Bufferwechsel unwirksam gemacht. Durch die Synchronisierung von t₁ zum Systick t₀ kann das Delta von aufeinanderfolgenden t₁, also der Jitter t_j, minimiert und geglättet und folglich ein synchroner Betrieb aufrechterhalten werden.
Die Erfindung bietet somit eine auf einem echtzeitfähigen Betriebssystem basierende und somit insbesondere eine implementierte Firmware-basierende Lösung zur Synchronisierung eines SPS Laufzeitsystems mit einem Lokalbus.
Als SPS-Laufzeitsystem kann im Rahmen der Erfindung daher zweckmäßig ein eCLR-Laufzeitsystem eingesetzt werden. Die Synchronisierung gemäß der Erfindung bietet ferner den Vorteil, dass sie insbesondere auch für Lokalbusse mit extrem kurzen und/oder systembedingt permanent zu fahrenden Zyklussen anwendbar ist, so dass in bevorzugter Ausführung als Lokalbus ein Axioline-Bus bzw. Axioline-Lokalbus im Rahmen der Erfindung an die Anschalt- und Steuereinrichtung anschaltbar ist, welcher Zykluszeiten im Mikrosekundenbereich besitzt.

Claims

Verfahren zum Betreiben einer Steuerungsvorrichtung (100) mit – einem echtzeitfähigen Betriebssystem (200) mit einem Systemtakt, – einem SPS-Laufzeitsystem (300) zur Ausführung von SPS-Tasks, und – einer Anschalt- und Steuereinrichtung (400) zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS-Task (310) erhaltenen Daten auf einen angeschalteten Lokalbus, wobei das SPS-Laufzeitsystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, gekoppelt werden.
Verfahren nach Anspruch 1, wobei durch Ausführung einer SPS-Task erhaltene Daten, welche auf den Lokalbus auszugeben sind, in einem ersten Schritt in einen von wenigstens zwei Buffer abgelegt werden, welcher nicht an den angeschalteten Lokalbus gekoppelt ist und in einem zweiten Schritt ein Wechsel der Buffer durchgeführt wird, so dass der Buffer mit den abgelegten Daten an den angeschalteten Lokalbus gekoppelt wird und in einem dritten Schritt die abgelegten Daten auf den angeschalteten Lokalbus ausgeben werden.
Verfahren nach Anspruch 1 oder 2, wobei unter Ansprechen auf ein Interrupt von dem Betriebssystem hin bei Vorliegen von Daten in einem Buffer, zunächst die Ausgabe dieser Daten auf den Lokalbus gesteuert wird, insbesondere ein Bufferwechsel durchgeführt wird und die Daten in dem dann an den angeschalteten Lokalbus gekoppelten Buffer auf diesen ausgegeben werden, und anschließend eine SPS-Task zum Erhalt von weiteren auf den angeschaltete Lokalbus auszugebenden Daten gestartet wird.
Verfahren nach Anspruch 1, 2 oder 3, wobei nach Ausführung der SPS-Task zum Erhalt von auf den angeschalteten Lokalbus auszugebenden Daten und Ablage dieser Daten in den Buffer für die Anschalt- und Steuereinrichtung ein Signalisierungsflag gesetzt wird, wobei bei gesetztem Signalisierungsflag auf das Vorliegen von Daten in einem Buffer, welcher nicht an den angeschalteten Lokalbus gekoppelt ist, erkannt wird.
Steuerungsvorrichtung (100) enthaltend – ein echtzeitfähiges Betriebssystem (200) mit einem Systemtakt, – ein SPS-Laufzeitsystem (300) zur Ausführung von SPS-Tasks, und – eine Anschalt- und Steuereinrichtung (400) zum Anschalten eines Lokalbusses (500) und zur Steuerung der Ausgabe von durch Ausführung einer SPS-Task (310) erhaltenen Daten auf einen angeschalteten Lokalbus, wobei das SPS-Laufzeitsystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, gekoppelt sind.
Steuerungsvorrichtung (100) nach Anspruch 5, wobei die Anschalt- und Steuereinrichtung wenigstens zwei Buffer umfasst und ausgebildet ist, jeweils einen der Buffer wechselweise an einen angeschalteten Lokalbus zu koppeln und darin enthaltene Daten auf den Lokalbus auszugeben.
Steuerungsvorrichtung (100) nach Anspruch 6, wobei das SPS-Laufzeitsystem eingerichtet ist, durch Ausführung einer SPS-Task erhaltene Daten, welche auf den Lokalbus auszugeben sind, in einem ersten Schritt in einen der wenigstens zwei Buffer abzulegen, welcher nicht an einen angeschalteten Lokalbus gekoppelt ist und die Anschalt- und Steuereinrichtung zur Steuerung der Ausgabe dieser Daten auf den Lokalbus eingerichtet ist, in einem zweiten Schritt einen Wechsel der Buffer durchzuführen, so dass daraufhin der Buffer mit den abgelegten Daten an den angeschalteten Lokalbus gekoppelt ist und in einem dritten Schritt die abgelegten Daten auf den angeschalteten Lokalbus auszugeben.
Steuerungsvorrichtung (100) nach Anspruch 5, 6 oder 7, welche eingerichtet ist, auf einen Interrupt von dem Betriebssystem hin zunächst die Anschalt- und Steuereinrichtung anzuweisen, bei Vorliegen von Daten in einem Buffer, zunächst die Ausgabe dieser Daten auf den Lokalbus zu steuern, insbesondere einen Bufferwechsel durchzuführen und die Daten in dem dann an den angeschalteten Lokalbus gekoppelten Buffer auf diesen auszugeben, und anschließend eine SPS-Task zum Erhalt von weiteren auf den angeschaltete Lokalbus auszugebenden Daten zu starten.
Steuerungsvorrichtung (100) nach Anspruch 6, 7 oder 8, welche eingerichtet ist, nach Ausführung der SPS-Task zum Erhalt von auf den angeschaltete Lokalbus auszugebenden Daten und Ablage dieser Daten in den Buffer für die Anschalt- und Steuereinrichtung ein Signalisierungsflag zu setzen, und die Anschalt- und Steuereinrichtung eingerichtet ist, bei gesetztem Signalisierungsflag auf das Vorliegen von Daten in einem Buffer, welcher nicht an den angeschalteten Lokalbus gekoppelt ist, zu erkennen.
Steuerungsvorrichtung (100) nach einem der Ansprüche 5 bis 9, wobei die Anschalt- und Steuereinrichtung eingerichtet ist, dass als Lokalbus ein Axioline-Lokalbus anschaltbar ist und/oder wobei das Laufzeitsystem ein eCLR-Laufzeitsystem ist.