Fehleranalyse bei Siemens AWL Schrittketten

Bitte.ein.Bit

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

Frage in die Expertenrunde: Ich habe die Aufgabe, für eine bestehende umfangreiche Anlage, die in Schrittketten mit AWL programmiert wird, eine Diagnose einzubauen.
Hintergrund ist, dass die Anlage immer mal wieder hängen bleibt (natürlich immer nachts :sad:), weil irgend ein Sensor verbogen ist, eine Lichtschranke verschmutzt usw. Nun bleibt die Schrittkette folgerichtig stehen, weil
eine Übergansbedingung nicht erfüllt ist. Gibt es eine einfache Möglichkeit, dass ich von Außen frage, in welchem Schritt die Anlage gerade hängt und warum es nicht weitergeht (welche Bit nicht
gekommen ist?).
Es sind eigentlich ja alle Infos in der SPS: Sie weiß wo sie steht und welche EA gekommen und nicht gekommen sind. Kann doch nicht sein, dass man nur mit dem Programmiersystem an die Infos rankommt.
Das muss anders gehen.
Ziel wäre:
Taster Drücken, danach kommt beispielsweise eine Meldung:
"Beladung nicht freigegeben. Eingangslichtschranke am Förderband 6 belegt".
"Beladung" wäre die verhinderte Schrittkette, "Eingangslichtschranke" das verbogene Bit.
Damit kann das Bedienpersonal was anfangen. Lichtschranke gerade biegen, weiter geht's.

Geht sowas, wenn schon nicht beim puritanischen AWL, dann wenigstens bei den "richtigen", bzw. komfortableren Ablaufsprachen, z.B. Grafcet?

Danke!
 
Gibt es eine einfache Möglichkeit, dass ich von Außen frage, in welchem Schritt die Anlage gerade hängt und warum es nicht weitergeht (welche Bit nicht
gekommen ist?).
Ja: mit Step7 das Programm online beobachten. :cool:

Wie "von Außen" willst fragen?
- Du könntest eine Visualisierung erstellen, die die Schrittvariablen und Bedingungen visualisiert
- Du könntest mit Libnodave die Schrittvariablen auslesen und Hinweistexte programmieren

Es gibt aber auf jeden Fall nichts fertiges, was nur anhand von ausgelesenen Schrittvariablen einen Sinn und fehlende Bedingungen im Klartext erkennt. Egal ob die Schrittkette in AWL, KOP, SCL oder Graph erstellt ist. Das Programm von außen sieht nur universelle Bits und Bytes ohne Namen und Beschriftung. Den Zustand der Schrittketten visualisieren und mit aussagekräftigen Texten versehen muß man extra programmieren. Vermutlich wird es auch noch nötig/hilfreich, in dem SPS-Programm zusätzlichen Diagnose-unterstützenden Code zu programmieren.

Harald
 
Kannst du denn mal einen Codeausschnitt deiner AWL-Schrittkette hier posten?
Ich bin vermutlich nicht der Einzige, der mehr als eine Art kennt in AWL eine Schrittkette zu bewerkstelligen, die man dann aber anders bei der "Spezial-Fehleranalyse-für-Dummies" behandeln muss...

Beispielsweise kann man jeden Schritt mit einem eigenen Integer-Wert deklarieren und diesen schon mal zur Anzeige bringen. Über eine Textliste in einem HMI kann man dann auch immer schön den Schritt ablesen, an dem die Kette gerade ist...

MfG Fabsi
 
Du fragst als ersten Schritt die gesamte Sensorik ab. Ist ein Bit nicht so wie erwartet kannst du entweder eine Sammelfehlermeldung ausgeben oder du programmierst für jeden Sensor eine eigene Meldung
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten morgen,
wir haben früher mal ein paar einfache Montagelinien für einen Automobilzulieferer gebaut. Diese waren auch mit Schrittketten programmiert ( AWL ).
Im Bediengerät ( TP177B ) waren dann im Montagebild 2 Textlisten zu sehen.
In der ersten stand der aktuelle Montageschritt ( z.B. Deckel xy aufsetzen und verschrauben ) und in der zweiten
Textliste immer die Bedingung, auf die gewartet wird, bis es weitergeht ( Warte auf Deckel 3x verschraubt ). Das 3x war dann
in der Textliste noch als Variable angelegt, so dass sobald eine Schraube verschraubt wurde und ich dier Rückmeldung vom Schrauber
bekam angezeigt wurde "Warte auf Deckel 2x verschraubt ).


Dass ganze war total simpel programmiert. Es gibt z.B. drei Bedingungen, dass ein Schritt weiter geht. Mit diesen drei Bedingungen
füttert man dann die zweite Textliste.

Also wir sind z.B. im Schritt 100 "Bauteil Deckel einlegen", Bedingung für den nächsten Schritt ist Eingang 50.0 = TRUE
Dann wird für die zweite Testliste ausgewertet:

hier vereinfacht geschrieben
U Schritt 100
UN E 50.0
= Textliste auf Wert 1000 ( 1000 = "Warte auf Deckel eingelegt")

Ich habe immer die Schrittnummer * 10 oder * 100 für diese Textliste genommen, damit ich für jeden Schritt mehrere Meldungen anlegen kann.

Ich hoffe dass ist so verständlich.
 
Und wenn seine "AWL"-Schrittkette nicht mit Schrittnummern (INT) sondern mit Schritt-Bit-Merkern realisiert ist, womöglich mit mehreren Schritten/Merkern gleichzeitig aktiv? Dann ist die Programmierung zu Visualisierungszwecken nicht mehr total simpel. Vielleicht sollten wir mit detaillierten Tipps warten bis er mal ein Stück seines Codes gezeigt hat?

So eine Zusatz-Programmierung für das Zusammenstellen von Informationen für die Visualisierung der Schrittkette kann schnell mehr Code erfordern als für die Schrittkette selber.

Harald
 
Dass ganze war total simpel programmiert.
Das war auf unsere Anlagen bezogen. Wir haben es von Anfang an einfachst gehalten.

So eine Zusatz-Programmierung für das Zusammenstellen von Informationen für die Visualisierung der Schrittkette kann schnell mehr Code erfordern als für die Schrittkette selber.

Ja, dass ist richtig. Es war zumindest genau so viel Arbeit wie für die Schrittkette. Wenn man es von Anfang an mit macht, geht es recht gut. Das ganze "nachzuziehen" erfordert etwas mehr
Arbeit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
nicht mit Schrittnummern (INT) sondern mit Schritt-Bit-Merkern realisiert ist, womöglich mit mehreren Schritten/Merkern gleichzeitig aktiv?

Woher wusstest du das ? :D Ich schreib gerade die AWL-Kopie in "INT-Brauchbar" von einer KOP-Schrittkette mit RS-Gliedern, welche auf 3 FCs verteilt ist... Eigentlich nur um die Gesamt-Restzeit des Vorgangs zu erhalten, welche aber netterweise nit S5Ts und Zählern realisiert wurde... Liest sich wie ein immer weiter fortgeschrittener "Programmierlehrgang"... Da schreibt man es nämlich am besten gleich neu und baut solche Funktionen dann passend mit ein ;)

MfG Fabsi
 
Da schreibt man es nämlich am besten gleich neu und baut solche Funktionen dann passend mit ein ;)
Ja, das Konzept sollte man tunlichst schon vor der Umsetzung haben und nicht erst nachträglich reinwürgen.
Hatte mal in S7-AWL etwas gestrickt, das die Diagnose vereinfachen sollte. Der Ansatz war aber ein ganz anderer. Egal welcher Schritt welcher Schrittkette auf die ausbleibende Rückmeldung wartete, wurde an einer zentralen Stelle die entsprechende Meldung generiert. Wobei die hängende Aktion vom dem beeinflussten Ausgang und die fehlende Bedingung aus dem abgefragten Eingang abgeleitet wurde.
Der andere Ansatz bestand im wesentlichen darin, in den Schritten nicht die Ausgänge direkt anzusprechen, sondern stattdessen die "zentrale Stelle", die entsprechend mit Ausgängen, Eingängen, Zeitwert für die TimeOuts und MeldungsNr parametriert wurde. Dieser FB war also über Sollwert und Istwert informiert und wusste, wie lange er die Diskrepanz zwischen Sollwert und Istwert tolerieren musste, bevor er die Meldung generiert. Wenn ich mich richtig erinnere, war die Anzeige, welcher Schritt in welcher Schrittkette aktiv war, ein davon unabhängiges Thema. Lang, lang ist's her und die Details habe ich leider nicht mehr im Kopf. Ich weiss noch, dass die zentrale Stelle eigentlich zwei FBs waren. Einmal die VollVersion für jeweils 4 Ein- und Ausgänge und die abgespeckte Version für jeweils 2 Ein- und Ausgänge.
Vermutlich MultiInstanz oder etwas entsprechendes zu Fuss gebasteltes. Die individuelle Zeitüberwachung war auf jeden Fall selbst gemacht und benutzte nur 1 SIEMENS-Timer (vermutlich noch vom ach so verpönten S5-Typ) als "ZeitNormal". Die abgespeckte Version des FB war nicht wirklich erforderlich - sie war nur praktisch für Schreibfaule wie mich und platzsparend in der Darstellung der Schrittketten.
Bezüglich der TimeOutVorgaben bin ich mir jetzt ganz unsicher - wurden sie wirklich beim FB-Aufruf parametriert oder im DB hinterlegt?
Dies ist also kein präzises KochRezept, aber vielleicht kann es als DenkAnstoss dienen.
Gruss, Heinileini
 
Zuletzt bearbeitet:
Hallo,

ich gehe davon aus das an deiner Anlage auch eine HMI verbaut ist. Darauf ist es kein Problem eine Bitmeldung anzulegen. Zusätzlich könntest du auch deine Schrittvariable anzeigen oder eine Textliste mit dieser Variable anlegen.

mit freundlichen Grüßen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich gehe davon aus das an deiner Anlage auch eine HMI verbaut ist. Darauf ist es kein Problem eine Bitmeldung anzulegen. Zusätzlich könntest du auch deine Schrittvariable anzeigen oder eine Textliste mit dieser Variable anlegen.

Na ja, dass wäre ja viel zu kompliziert. Wenn man eine Schrittvariable anzeigt, bringt dass dem Werker ja erst einmal nicht viel, da er ggf. 10-20 Weiterschaltbedingungen
in der Kette hat. Nun muss man ja drauf kommen, welche Bedingung fehlt. Also warum es nicht in den nächsten Schritt weiter geht.

In der Automobilindustrie ist dass oft sehr einfach und verständlich gelöst:

Zeile 1 mit Textliste "Schritt 13 Spiegelgehäuse einlegen" In dieser Zeile gibt es pro Schritt nur einen Text
Zeile 2 mit Textliste " Warte auf Sensor Spiegelgehäuse eingelegt ( E4.2 = 1 ) In dieser Zeile gibt es pro Schritt so viele Texte, wie es eben Weiterschaltbedingungen gibt.
Je nachdem was für eine Bedingung fehlt, wird entsprechend die Zeile dafür angezeigt.
 
Zeile 1 mit Textliste "Schritt 13 Spiegelgehäuse einlegen" In dieser Zeile gibt es pro Schritt nur einen Text

Das meinte ich ja damit. Es reicht aber nur die Schritte anzuzeigen die für den Bediener relavant sind. So zum Beispiel wie du geschrieben hast "Bauteil einlegen/entfernen" usw. Für Sonderfälle in denen es zu einer Störung kommt sind die Bitmeldungen da. Zb. "Ausheberzylinder 06Z2" Arbeitsstellung wurde nicht erreicht. AS =250B1, GS =205B0"

Grüße
 
Zurück
Oben