# Schrittkette: Initialisierschritt (...mal wieder)



## FoodFighter (10 März 2018)

Mahlzeit zusammen,

mir brennt momentan eine Fragestellung auf der Seele, zu der ich keine eindeutige Antwort finde und mir erhoffe, dass man mir hier kompetent weiter helfen kann.

Vorweg folgende Veranschaulichung:



Gelernt habe ich den Aufbau einer Schrittkette (vor langer Zeit) mal nach Variante 2, also mit einem Schrittmerker, der eine laufende Schrittkette speichert, als Initialschritt und einem Rücksetzmerker als letzten Schritt der Kette.
In Fachliteratur und auch generell sonst sieht man häufig die Variante 1 aus o.g. Gegenüberstellung. Hier werden im Initialschritt schlichtweg ALLE Schrittmerker auf "nicht gesetzt" zur Initialisierung abgefragt.
Das ist schön und gut, bei sehr vielen Schritten wird das allerdings ein sehr großer Initialschritt, die Variante 2 wäre hier eindeutig einfacher.
Eine dritte Variante, die man auch gelegentlich sieht, ähnelt der Variante2, nur wird hier ein Anlaufmerker in Verbindung mit einer ODER-Verknüpfung zur Setzung des Initialmerkers genutzt und dieser dann im Schritt 1 deaktiviert. 

```
O "Anlaufmerker"
O "letzter Schritt"
S SM0

U SM1
R SM0
```
Dass beide bzw. alle drei Versionen sehr wohl funktionieren ist mir auch bewusst.

Meine eigentliche Frage ist, ob die Variante 2 in der Form sozusagen "regelkonform" ist oder ob es irgendeine Norm, Vorschrift, o.ä. gibt, was einem diese Variante gewissermaßen "verbietet"?

Man liest zur Definition des Initialschrittes häufig "ist beim Initialisieren des Grafcets aktiv". In der Variante 2 wäre er deaktiviert und für die komplette Dauer der Schrittkette aktiviert.
Daher rührt meine Überlegung.

Weiß da jemand was genaueres?


----------



## Tigerente1974 (11 März 2018)

Hallo,

Normen dazu gibt es nicht. Wie man das löst, ist vermutlich auch eine Geschmacksfrage. Am Ende muss Code richtig funktionieren, gut strukturiert und nachvollziehbar sein.
Mir persönlich gefällt Variante 2 am besten.


----------



## Blockmove (11 März 2018)

Dazu gibt es unzählige Varianten.
Es muss schlichtweg zur Aufgabe / Anlage passen.
Oftmals verhindern schlichtweg die mechanischen Gegenheiten, dass die Kette erneut gestartet wird.
In anderen Fällen braucht man eben einen Startspreicher.
Mindestens genauso wichtig ist ein Schrittkettenreset.

Wenn ich nicht in S7Graph oder AS programmiere, dann verwende ich meist auch Variante 2.

Gruß
Blockmove


----------



## FoodFighter (11 März 2018)

Danke, das hat mein Gewissen beruhigt.

Klar, größere Anlagen programmiert man sowieso oft in Graph oder SFC...ich persönlich vermeide Schrittketten dieser Art sogar gerne komplett (sofern es geht)...sobald da irgendein NotAus gedrückt wird oder irgendein Ini mal nicht funktioniert, wie er soll, kommt man schnell in Bredouille, wenn man beim Programmieren nicht an aller erdenklichen Szenarien gedacht hat.
Mag Geschmackssache sein.

Hier momentan ging es eher um unsere AzuBis, die bald zur Übung mit Ablaufketten konfrontiert werden sollen.

Besten Dank erstmal und schönes Rest-Wochenende.


----------



## Blockmove (11 März 2018)

FoodFighter schrieb:


> ich persönlich vermeide Schrittketten dieser Art sogar gerne komplett (sofern es geht)...sobald da irgendein NotAus gedrückt wird oder irgendein Ini mal nicht funktioniert, wie er soll, kommt man schnell in Bredouille, wenn man beim Programmieren nicht an aller erdenklichen Szenarien gedacht hat.



Die Alternative zur Schrittkette ist die Verknüpfungssteuerung / - Logik.
Die ist aber noch anfälliger für Fehlschaltungen und undefinerte Zustände.
Wenn eine Weiterschaltbedingung (Ini) fehlt, dann sollte eine entsprechende Diagnose vorhanden sein.
Im einfachsten Fall eine einfache Schrittüberwachungszeit bis hin zu Lösungen wie Prodiag.

Bei Not-Halt muss man eben Überlegen wie man danach weiterfährt.
Aber das Problem hat man sowohl bei Schrittkette als auch bei Verknüpfungslogik.

Es greift da auch die alte Weisheit:
Für jede Arbeit das richtige Werkzeug verwenden

Gruß
Blockmove


----------



## Draco Malfoy (11 März 2018)

FoodFighter schrieb:


> ich persönlich vermeide Schrittketten dieser Art sogar gerne komplett (sofern es geht)...sobald da irgendein NotAus gedrückt wird oder irgendein Ini mal nicht funktioniert, wie er soll, kommt man schnell in Bredouille, wenn man beim Programmieren nicht an aller erdenklichen Szenarien gedacht hat.



Ich frage mich, wie dann aussieht ? 1,5km KOP-FUP Verschaltungen mit Set Reset ? Und was passiert, wenn da mal einer nicht an einen ausgefallenen Ini gedacht hat ?


----------



## FoodFighter (12 März 2018)

Draco Malfoy schrieb:


> Ich frage mich, wie dann aussieht ?



Da ich mich beruflich größtenteils per CFC mit PTE400-Library bewege, ist das alles ein wenig anders. Es gibt fix-und-fertige FBs für Motoren und Ventile mit Laufzeitüberwachung, Schutz- und Stopp-Verriegelung, Auot/Hand-Umschaltung usw. usf. Will heißen - der größte Teil an möglichen Fehlern wird direkt über den jeweiligen Motor-/Ventil-Baustein abgefangen.
Man muss dem "Klotz" also nur noch mitteilen, wann er denn in der Automatik laufen soll - im Fall einer Folgeschaltung ist das schlichtweg meistens der Fall, wenn der Antrieb vor ihm für Xs läuft.
Die Möglichkeit SFCs zu nutzen habe ich sehr wohl auch...manchmal kommt man auch nicht oder nur schwierig drum herum, wie ich aber schon sagte - ich persönlich vermeide es gerne.

Ich mache mal ein sehr vereinfachtes Beispiel um dir zu verdeutlichen, was ich meine:


> Beispiel Förderbandanlage:
> Nach Tasterdruck "Anlage Ein" schalten 3 Förderbänder jeweils um 3s versetzt (Reihenfolge 1-2-3) ein.
> Bei Tasterdruck "Anlage Aus" schalten die Bänder in Reihenfolge 3-2-1 um je 3s versetzt ab.
> Bei Betätigung des NotAus bleibt die Anlage sofort komplett stehen.



Persönlich würde ich das ungefähr folgendermaßen lösen:
https://www.docdroid.net/a0LwQGx/fc1.pdf

Nach Grafcet bzw. über eine Schrittkette würde ich folgenden Weg einschlagen:
https://www.docdroid.net/bvPIDpU/fc3.pdf (Schrittkette)
https://www.docdroid.net/i3Kxr6S/fc4.pdf (Ausgangszuweisung)

Für meinen Geschmack deutlich umständlicher...und es fehlt sogar noch (bewusst) etwas: Wenn die Anlage während des "Hochfahrens" schon gestoppt wird, fährt diese nach FC3/FC4 NICHT in umgekehrter Reihenfolge direkt wieder runter - es müssen erst alle 3 Bänder laufen, um die Anlage wieder Stoppen zu können. Um das zu realisieren müsste man z.B. noch Querpfade in die Schrittkette einbauen.

Ich will Grafcets gar nicht verteufeln oder schlecht reden...jedoch gibt es immer mehrere Mittel und Wege um zum erwünschten Ergebnis zu kommen.

Wie Blackmove schon schrieb:


> Es greift da auch die alte Weisheit:
> Für jede Arbeit das richtige Werkzeug verwenden


----------



## acid (12 März 2018)

Sicher mag das Geschmackssache sein, aber selbst bei kleineren Anlagen mit überschaubaren Schrittketten ist Graph eine gute Lösung, die schnell nachvollziehbar ist und gute Diagnosemöglichkeiten bietet, auch in Verbindung mit Überwachungen bzw. ProDiag, was in TIA IMHO wirklich gut funktioniert.

Ich durfte erst unlängst wieder Fehlersuche an einer AWL Schrittkette betreiben, ~40 Bedingungen pro Transition die alle untereinander verundet/verodert sind und dazu keine vernünftige Doku (Sofern man so ein Konstrukt überhaupt dokumentieren kann...). Auch in KOP/FUP ist sowas schnell undurchschaubar, erschwert die Wartung und Fehlersuche und deckt auch nicht jede Konstellation ab. 
Sowas ist ein Quell steter Freude und lässt die Quecksilbersäule schnell auf Anschlag fahren.


----------



## Draco Malfoy (12 März 2018)

FoodFighter schrieb:


> Da ich mich beruflich größtenteils per CFC mit PTE400-Library bewege, ist das alles ein wenig anders. Es gibt fix-und-fertige FBs für Motoren und Ventile mit Laufzeitüberwachung, Schutz- und Stopp-Verriegelung, Auot/Hand-Umschaltung usw. usf. Will heißen - der größte Teil an möglichen Fehlern wird direkt über den jeweiligen Motor-/Ventil-Baustein abgefangen



Mit CFC arbeite ich auch, sofern es sich um prozesstechnische Anlagen handelt. Zu den den Librarys kannst du aber gerne mehr erzählen. PTE400 sagt mir nichts, ich kenne nur APL mit entsprechenden Erweiterungen.

Dein Beispiel ist indes nicht aussagekräftig. 3 Asynchron-Motoren in u/f Regelung ist nichts worüber wir uns unterhalten müssten. Wenn du beispielsweise Hydraulik-Zylinder mit Proportionalventilansteuerung und dazu noch Positionierantriebe hast, die durch Mechanik so beschränkt sind, dass die nicht einfach in der Gegend frei rumfahren dürfen. Was machst du dann .


----------



## FoodFighter (12 März 2018)

Draco Malfoy schrieb:


> Zu den den Librarys kannst du aber gerne mehr erzählen.


https://www.industry.siemens.com/datapool/industry/industrysolutions/services/de/PTE400-de.pdf
Die Freigabe für V9 soll m.W. diesen Monat noch kommen.
An und für sich bin ich mit der Library ganz zufrieden - firmenpolitisch habe ich aber ohnehin keine (großartig) andere Wahl.



Draco Malfoy schrieb:


> Wenn du beispielsweise Hydraulik-Zylinder mit Proportionalventilansteuerung und dazu noch Positionierantriebe hast, die durch Mechanik so beschränkt sind, dass die nicht einfach in der Gegend frei rumfahren dürfen. Was machst du dann



Sofern ich dich richtig verstehe, würde ich einfach die Schutzverriegelung oder die Zwangs-Position vom Ventilbaustein entsprechend verschalten und ungewollte Zustände dadurch verhindern.

Letztendlich ahne ich aber worauf das hier hinaus läuft.
Ich wollte kein "Was ist besser" oder "Du hast das aber so zu tun, weil ich das schon immer so mache" vom Zaun brechen oder irgendwem seine Schrittketten-Technik schlecht reden. Falls das so aufgefasst wurde, muss ich mich entschuldigen.
Ursprünglich ging es nur um die Frage ob der Initialschritt noch Initialschritt genannt werden "darf", wenn es im Prinzip nur ein "Kette-läuft-Merker" ist.
Diese Frage wurde mir beantwortet, dafür bin ich dankbar.

In diesem Sinne möchte ich die Diskussion an dieser stelle gerne beenden.
Vielen Dank und bis bald
FoodFighter


----------



## Draco Malfoy (12 März 2018)

FoodFighter schrieb:


> https://www.industry.siemens.com/datapool/industry/industrysolutions/services/de/PTE400-de.pdf
> Die Freigabe für V9 soll m.W. diesen Monat noch kommen.
> An und für sich bin ich mit der Library ganz zufrieden - firmenpolitisch habe ich aber ohnehin keine (großartig) andere Wahl.



Man lernt ja nie aus.

Ist es eine Erweiterung der APL, oder sind da Bausteintypen hinterlegt die auch in der APL vorkommen, nur halt in diesem PTE400 Standard ? 
Was ist daran besser / schlechter als APL ? Entwickelt ihr auch eigene Typicals, um die Funktionalität zu erweitern ? Sind diese dann nach dem APL Standard gemacht ?

Benutzt diese Library eigene Baugruppentreiber, oder werden dort die Treiber der BL aus der jeweiligen PCS7 Version genommen ? Gibt es Erweiterungen für die Baugruppentreiber ?
Gibt es dort z.B. Standardbausteine, um Sinamics Servodrives einzubinden ?


Sorry für die vielen Fragen, bin neugierig.


----------



## FoodFighter (12 März 2018)

Ich muss ehrlich gestehen, dass ich da überfragt bin.
Meines Wissens (! und da begebe ich mich jetzt auf dünnes Eis !) ist die PTE400 keine Erweiterung der APL sondern einfach eine komplett eigene Bilbiothek, welche zusätzlich zu den Standard-PCS7-Libs genutzt wird.
Ich weiß, dass es bei uns schon öfter mal zur Diskussion stand auf APL umzusteigen (u.a. aus Sorge, dass die PTE400 evtl irgendwann nicht mehr gepflegt oder für neuere Versionen freigegeben wird), was letztlich aber ein enormer Aufwand wäre. Manche Schwesterwerke haben wohl angefangen damit und fahren gewissermaßen zweigleisig...zufrieden sind die Kollegen nach meinen Kenntnissen aber überhaupt nicht.
Da sich im Lauf der Jahre einiges an Programmen angesammelt hat, kommt man schlichtweg so einfach nicht mehr davon weg.
Um dir einen Anhaltspunkt zum Umfang zu geben: Als ich damals dazu kam, wurde gerade von PCS7 V4 auf V5 hochgerüstet - mit V6.1 hatte ich persönlich dann am meisten zu tun, aktuell ist die V9.0. Das "große Projekt" hat momentan ca.1,8GB und ist ziemlich verstrickt ... da kann man nicht mal eben "nur einen Teil" umrüsten...mal ab von der Zeit, Kosten, Testbetrieb, Produktionsausfall/-stillstand....
Ich vermute (!) daher, dass die PTE400 der APL Bibliothek vielleicht gar nicht (mehr) so viele Vorteile bringt - vor 15 Jahren (als sie noch ILS-PTE o.ä. hieß) aber vermutlich enorme Vorteile Gegenüber der Standard-Libs hatte.

Nein wir entwickeln keine eigenen Typicals, das könnte ggf. zu erheblichen Problemen bei Hochrüstungen führen, daher nimmt man was man hat und was von Siemens gepflegt wird.

Die Baugruppentreiber sind m.W. die Standard-Treiber...wäre mir neu, falls die auch aus der PTE kämen.

Mit Servodrives habe gar nichts zu tun, dazu kann ich keine Auskunft geben.

Alle Angaben ausdrücklich ohne Gewähr!
Ich bin mit der APL Bilbiothek einfach nicht vertraut genug um dir genauere Informationen liefern zu können, tut mir leid.

Gruß
FoodFighter


----------



## Draco Malfoy (13 März 2018)

FoodFighter schrieb:


> Alle Angaben ausdrücklich ohne Gewähr!
> Ich bin mit der APL Bilbiothek einfach nicht vertraut genug um dir genauere Informationen liefern zu können, tut mir leid.



Dennoch interessant. Jedesmal, wenn man glaubt, man kennt sich mit einer bestimmten Materie aus, taucht irgendeine Erscheinung auf, die einen völlig aus dem Konzept bringt. Ich kenne Firmen, die für sich eigene Librarys auf der Basis und Grundlage der APL entwickeln, aber daß es von Siemens neben der Industry Library noch etwas anderes für den allgemeinen Mark (keine kundenspezifische Entwicklung) gab oder gibt, war mir neu.


----------

