Grafcet Gleichzeitigkeit vs. ST- Sequentiell

sims1122

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich stehe aktuell vor der Herausforderung, Grafcets automatisch in ST zu überführen. Das ganze ist Teil eines größeren Projektes und ich komme auch gut voran, habe nur hinsichtlich der formellen Absicherung noch Verständnisschwierigkeiten. Bitte korrigiert mich bei allem, wo ich falsch liege: Grafcet beschreibt "synchronous machines", in denen Zustandsübergänge ereignisgesteuert und gleichzeitig stattfinden. Eine PLC ist aber nunmal sequentiell - ich gehe hier auch von der ein-Prozessor-ein-Task-Programmierung aus.
Im Bild unten jetzt ein Grafcet mit dem Fall, der mir Probleme bereitet: Was passiert, nachdem die oberste Transition gefeuert hat? Ist der Output (a=1,x=1) oder (a=1,x=0)? Im Falle der SFC ist die Auswertung von Aktionen und Transitionen implementierungsabhängig, im Falle von Codesys von links nach rechts. Dort wäre der Output im ersten Zyklus also klar (a=1,x=1). Da bei Grafcet aber alles gleichzeitig passiert, bin ich mir unsicher. Kann jemand helfen?

20150407_114950711_iOS.jpg

Bonuspunkte für Hinweise zu weiterem Material, dass mir bei dem Verständnis der Herausforderungen von parallelen Konstrukten wie in Grafcet aus sequentiellen Maschinen helfen kann.

Vielen Dank.

Max
 
Hallo,
du kannst ein GraphCet (also eine Schrittkette) zu 100% in ein PLC-Programm umsetzen - auch die bei dir dargestellte simultane Verzweigung.
Es kommt hierbei allerdings darauf an, wie du es konkret im Code machst.
Was wird denn bei dir im Code daraus ? Ein Select-Case mit einer INT-Variablen (ggf. als Enum) ? Oder wird jeder Schritt durch einen bool repräsentiert ?

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Larry,
jeder Schritt und jede Transitionsbedingung wird jeweils durch einen Bool repräsentiert. Ich werte in einer Schleife erst die Transitionen aus (deaktiviere und aktiviere also die notwendigen Steps) und führe anschließend die Aktionen zu den aktiven Steps aus. Natürlich ist das alles noch ein bisschen feiner im Hinblick auf transiente States, forcing orders etc., aber so grob der Ablauf. In dem konkreten Fall ist es nur eben relevant, ob im SourceCode erst die Aktion für den linken Schritt und dann die für den rechten steht, oder eben andersherum, da dies (zumindest für einen Zyklus) unterschiedliche Ausgaben geben wird.

Gruß

Max
 
Hallo Max,
üblicherweise aktualisieren die SPS'en ihr Prozessabbild (also Einlesen der Eingänge bzw. Schreiben auf die Ausgänge) zu einem festgelegtem Zeitpunkt (i.d.R. am Ende des Haupt-Programms). Dadurch ist die Reihenfolge, mit der du intern rechnest micht relevant (soweit ich dich hier richtig verstanden habe).

In deinem speziellen Fall der Simultan-Verzweigung ist es ja eigentlich sowieso so, dass die Zweige selbst wieder zueinander unsynchron ablaufen können (und auch können sollen), da ihre Synchronisierung ja am Ende durch eine Simultan-Zsammenführung erreicht wird (es geht nur insgesamt weiter wenn beide Zweige an derem Endschritt stehen und die ggf. vorhandene Bedingung erfüllt ist).

Gruß
Larry
 
Da kommen wir zum Kern der Frage: a ist eine interne Variable, gehört also m.E. nicht zum Prozessabbild und wird direkt geschrieben. Dadurch ist die Reihenfolge sehr wohl relevant, oder irre ich mich? Hinzu kommt die Frage, wie der korrekte Output vom Grafcet selbst wäre. Wenn ich da eine Möglichkeit hätte, eindeutig zu sagen, was passiert, könnte ich mich auch auf eine Reihenfolge festlegen.

Zu dem unsynchronen Ablauf nachher hast du natürlich Recht, mir geht es wirklich um den einen Zyklus nach dem Feuern der ersten Transition.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu dem unsynchronen Ablauf nachher hast du natürlich Recht, mir geht es wirklich um den einen Zyklus nach dem Feuern der ersten Transition.

Es gibt unzählige Arten und Möglichkeiten eine Schrittkette in der SPS zu realisieren.
Anfang und Ende einer Simultanverzweigung sorgt dabei manchmal für Diskussionen.
Aber letztlich ist es egal wie du es löst. Du musst dieses Verhalten einfach dokumentieren.
Wenn das Verhalten bekannt ist, dann kann der Anwender eben entscheiden ob er einen weiteren Schritt an der Stelle einfügen muss.
 
Da kommen wir zum Kern der Frage: a ist eine interne Variable, gehört also m.E. nicht zum Prozessabbild und wird direkt geschrieben. Dadurch ist die Reihenfolge sehr wohl relevant, oder irre ich mich?

OK ... da hast du Recht.
Die Variable ändert sofort bei der Zuweisung ihren Wert und ist ab da mit dem neuen Wert verfügbar.
Wenn du jetzt allerdings im Strang 1 eine Zuweisung machen möchtest um dann im Strang 2 ggf. davon zu partizipieren dann machst du m.E. von der Überlegung her etwas falsch - es sein denn es soll sich hier um eine Art Verriegelung handeln.
Wenn du die Umsetzung deiner Schrittkette so machst, dass du die Schritte mit ihren Transitionen nur genau das sein läßt und die Zuweisung später im Code gesammelt (quasi als Zusammenfassung) machst dann stellt sich das Problem mit der Unsynchronität und dem ggf. Nacheinander hier auch wieder nicht.

Poste doch vielleicht mal einen Beispielcode und dann diskutieren wir darüber ...

Gruß
Larry
 
OK ... da hast du Recht.
Die Variable ändert sofort bei der Zuweisung ihren Wert und ist ab da mit dem neuen Wert verfügbar.
Wenn du jetzt allerdings im Strang 1 eine Zuweisung machen möchtest um dann im Strang 2 ggf. davon zu partizipieren dann machst du m.E. von der Überlegung her etwas falsch - es sein denn es soll sich hier um eine Art Verriegelung handeln.
Wenn du die Umsetzung deiner Schrittkette so machst, dass du die Schritte mit ihren Transitionen nur genau das sein läßt und die Zuweisung später im Code gesammelt (quasi als Zusammenfassung) machst dann stellt sich das Problem mit der Unsynchronität und dem ggf. Nacheinander hier auch wieder nicht.

Ganz so simpel ist es bei Grafcet nicht.
In den Grafcet-Aktionen ist wesentlich mehr möglich als z.B. bei S7-Graph. Bedingt durch die seq. Bearbeitung wirst du immer irgendeinen Problemfall haben.
Ich würd mal sagen, "Das war schon immer so und das wird immer so bleiben".
Selbst bei Schütztechnik gab es - trotz Gleichzeitigkeit - Probleme und somit die Notwendigkeit zu vor- oder nacheilenden Kontakten.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Dieter:
Dein Einwand in allen Ehren.
Der TE hat jedoch geschrieben, dass er die GraphCet-Funktionalität (also im Grunde genommen die Umsetzung des grafischen Aufbaus) in ST erstellen will.
Basis ist hierbei die Verwendung von Schrittmerkern, mal unabhängig von wo die kommen - also echte Merker oder Instanz-Bits (so habe ich es jedenfalls verstanden).
Und in diesem Fall würde es mit meinem Beitrag dann schon passen ...
Du hast ansonsten natürlich Recht : es ist immer wichtig zu beachten, dass man nicht auf ein Ergebnis aufbaut bevor es erstellt wurde - das ist aber unabhängig von der jeweiligen Programmier-Methodik oder der Rahmen-Spielregel. Das läßt sich aber auf dem von mir beschriebenen Weg ganz gut im Griff behalten ...

Gruß
Larry
 
@Larry

Das Problem an Grafcet oder auch an CFC ist, dass hier aufgrund der einfachen grafischen Programmierung die sequentielle, zyklische Bearbeitung in den Hintergrund tritt.
Gleichzeitigkeit gibt es zwar auf dem Blatt Papier aber eben nicht in der SPS. Deshalb muss man eben "Rechenregeln" (von links nach rechts, in der Aktionsliste von Oben nach Unten, ...) enführen und dokumentieren.

Im Grunde unterscheiden sich unsere Aussagen nicht. Wir wissen beide, dass der erste Zyklus bei Parallelverzweigungen oder beim Start von weiteren Schrittketten eben Aufmerksamkeit bedarf.

Gruß
Dieter
 
Für mich sind Parallelschritte ein NOGO .... BOSCH verbietet so etwas z.B. in OpCon explizit ... EIN Schritt zu einer Zeit ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für mich sind Parallelschritte ein NOGO .... BOSCH verbietet so etwas z.B. in OpCon explizit ... EIN Schritt zu einer Zeit ...
Letzlich ist es doch nur eine Frage der grafischen darstellung.
In den meisten Fällen sind paralle Schritte doch sowieso eigenständige Abläufe, die du in eine eigene Kette ausgliedern könntest.

Gruß
Dieter
 
... das sehe ich auch so und handhabe es auch üblicherweise so.
Die Dokumentation (also die Darstellung der Schrittkette) wird dadurch auch wesentlich sauberer ...

Gruß
Larry
 
... das sehe ich auch so und handhabe es auch üblicherweise so.
Die Dokumentation (also die Darstellung der Schrittkette) wird dadurch auch wesentlich sauberer ...

Bei uns werden Schrittketten mit S7-Graph programmiert.
Da die Diagnose mit den Simualtanverzweigungen keine Probleme hat, mache ich da schon sehr häufig Gebrauch.

In den seltenen Fällen in denen ich auf herkömmliche Ketten zurückgreife, handhabe ich es wie du.

Die eigentliche Schrittkette ist heute sowieso kein Thema mehr. Wichtig ist, dass die Diagnosefunktionen aussagekräftige Informationen liefern.
Vor 30 Jahren wurden Schrittketten mit 2 Timern überwacht. Ein Timer für die geraden Schritte, ein Timer für die ungeraden Schritte. Das Resultat war eine simple Meldeleuchte.
Heute hast du die Diagnose bis runter zum defekten Ini. Und morgen mit Industrie 4.0 weckt dich die Anlage per What's App nachts um 3 und will ein Date mit dir

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... das bekommt man, wenn man es richtig macht, aber immer noch mit 1 oder 2 Timern hin - nur vielleicht nicht auf die Millisekunde genau ... (also das mit der Diagnose)
 
Vielen Dank für die zahlreichen Überlegungen,

ich habe natürlich auch weiter ein wenig Hirnschmalz hineingesteckt. Das Problem ist, dass das ganze Ding eine Masterarbeit wird, also entsprechend wissenschaftlich belegt sein muss. Da die Norm für Grafcet an sich recht schwammig ist, gibt es ein paar Paper dazu, die sich mit genau der Problematik befassen, und da heißt es in einem, dass Aktionen "kompatibel" sein müssen. Und kompatibel heißt in diesem Fall, dass zwei Aktionen, die gleichzeitig aktiv sein können, nicht auf den gleichen Variablen arbeiten dürfen. Fertig. Damit ist das konkrete Problem gelöst.

Zur Implementierung an sich halte ich es jetzt einfach so wie Blockmove es gesagt hat, und gebe eine Auswertungsreihenfolge vor (von links nach rechts). Damit ist mein Programm dann in jedem Fall deterministisch.
Und zu der generellen Problematik paralleler Schritte: In meiner Arbeit geht es darum, Grafcets inkl. der hierarchischen Strukturen umzusetzen. D.h. da gibt es nicht nur parallele Schritte in einem Graph, sondern sogar parallel arbeitende Graphen, die sich gegenseitig manipulieren können. Das ist dann so richtig hässlich. :p
 
Und zu der generellen Problematik paralleler Schritte: In meiner Arbeit geht es darum, Grafcets inkl. der hierarchischen Strukturen umzusetzen. D.h. da gibt es nicht nur parallele Schritte in einem Graph, sondern sogar parallel arbeitende Graphen, die sich gegenseitig manipulieren können. Das ist dann so richtig hässlich. :p

Willkommen in unserer Welt :p
Wie bereits festgestellt, gibt es ja auf der SPS keine wirkliche parallele Bearbeitung. An deiner Stelle würde ich versuchen ein bestehendes System (Siemens S7-Graph, Codesys Ablaufsprache) in Hinblick auf parallele Bearbeitung zu analysieren und weitgehend kompatibel dazu zu werden.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das war auch erst mein Ansatz und der meines Betreuers. Er hat in seiner bisherigen Arbeit Grafcets in Codesys Ablaufsprache umgesetzt. Ich mache das aus folgenden Gründen allerdings jetzt doch nicht:
  • Ziel ist, wenn überhaupt in IEC 61131-3 Ablaufsprache, und nicht in Codesys Ablaufsprache zu transformieren. Hinsichtlich der Bearbeitungsreihenfolge paralleler Transitionen ist die IEC aber nicht eindeutig, d.h. eine Codesys-Implementation könnte von einer Multiprog-Implementation abweichen. Codesys wertet von links nach rechts aus, bei Multiprog weiß ich es gerad gar nicht
  • Um hierarchische Konzepte umszusetzen, muss ich auch mit entsprechenden genesteten Graphen bzw. Funktionsblöcken arbeiten. Die IEC 61131-3 ist aber nicht eindeutig, ob ein Funktionsblock, wenn er unterbrochen wird, seinen aktuellen Zustand behält oder in den Initialzustand zurückkehrt.
  • In Grafcet gibt es sog. einschließende Schritte, die einen Graph niederer Priorität in eine bestimmte Situation zwingen, wo er dann verharrt bis der einschließende Schritt wieder deaktiviert wird. Für diesen Zweck müsste ich dann also in der Ablaufsprache für den Teil-Grafcet an jeder Transition eine zusätzliche Verzweigung mit Sprung in diese Situation hinein hinzufügen. Um das ganze noch schwieriger zu machen, kann der selbe Teil-Grafcet aber von verschiedenen Stellen in verschiedene Situationen gezwungen werden, d.h. ich müsste jede Transition um eine ellenlange Liste an Verzweigungen ergänzen. Da das Ziel ja ist, die Hierarchie zu erhalten um eine gewisse Übersichtlichkeit zu wahren, kann ich es so auch gleich sein lassen.

Mit meinem Ansatz, Strukturierten Text zu verwenden und Schritte und Transitionen als BOOL zu modellieren, bin ich viel flexibler. Zudem mache ich mir noch das neue Konzept der objektorientierten Eigenschaften für Funktoinsbausteine zu nutze. So kann ich über Methodenaufrufe Variablen eines Funktionsbausteins manipulieren, ohne ihn ganz aufzurufen.

Wenn ich ein paar Beispiele niedergeschrieben habe, dokumentiere ich die an dieser Stelle gerne einmal.
 
Grafcets nach Codesys Ablaufsprache umzusetzten ist - meiner persönlichen Meinung nach - nicht sinnvoll.
Dazu ist Codesys Ablaufsprache zu unflexibel. Hier ist dein gewählter Ansatz sicher geeigneter. Siemens arbeitet bei S7-Graph intern mit Sprungverteilern. Damit lässt sich das Thema auch relativ elegant lösen. Persönlich bin ich der Auffassung, dass Grafcet etwas über das Ziel hinausschießt.

Gruß
Dieter
 
die diagram ist SFC kein CFC.
in CFC es sind die folgennummer an zu halten.
In SFC ist das ganze eine statemachine.
es ist aber die folge wichtig.
hab es probiert in codesys
in das erste block hab ich mir eine counter1 gemacht
dan if statement.
da auch ein counter2.
dan seh ich eine auf 60 und die zweite auf 59
also bei ein durchlauf geht erst die linke block und dan die rechte.
ich habe a:= direct im block gemacht also das ganze wird immer getan, und nur das erste mahl geht es "falsch"
die beide parallel werden solange gemacht bis der untere trans true ist.
In IEC kan das anders auswirken wen man die buchstabe andert also eine N, T, S usw.
SFC kann sehr einfach in ST gemaht werden mit eine state machine, sogar in LD moglich.
 
Zurück
Oben