TIA Fehlerbehandlung in einer Ablaufsteuerung

[Blaner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Mein derzeitiges Projekt (FUP) besteht aus einer Schrittkette mit 7 Schritten die eine Vielzahl an Hubzylinder aus bzw. einfahren.
Jeder Hubzylinder hat seine Endlagensensoren.

Aufgabe:
Im Fehlerfall soll in jedem Schritt nach Ablauf von 2 Sekunden eine Fehlermeldung am HMI ausgegeben werden, welche der Endlagensensoren fehlen damit der
Schritt ausgeführt wird.

Wäre der ideale Vorgang darin, einen Verzögerungsalarm (SRT_DINT) im vorherigen Schritt zu starten, der im nächsten Schrittende wieder zurückgesetzt wird.
Der Verzögerungsalarm ruft dann einen OB20 auf der je nach Schritt die Transitionsbedingungen einzeln abfragt?

Oder gibt es einen viel einfacheren Weg?

Lösung:
Hallo Blaner an Blaner :wink:
, ich habe die einfach Lösung deine Problems für dich.

Als Beispiel habe ich ich im FC1 (FUP) ein SR-Glied an dem am Setzeingang der Digitale Eingang %i0.0 hängt.

1. Ich erstelle einen Datenbaustein DB1 und deaktviere unter Eigenschaften/Attribute den optimierten Bausteinzugriff.
2. Ich füge im Datenbaustein DB1 eine neue Variable mit dem Namen Fehler (was dann auch die Triggervariable ist) mit dem Datentyp INT hinzu.
3. Man fügt hinter das SR-Glied eine Zuweisung (=) dahinter
4. Ein Klick in die Zuweisung und man tippt folgendes ein: "DB1".Fehler.%X0

In den weiteren Schritten fährt man wie im Handbuch beschrieben fort. (Projektieren von Bitmeldungen)

 

[Draco Malfoy]

Oder gibt es einen viel einfacheren Weg?

Ja, gibt es. Meldemechanismen des S7 Graph und ProDiag zu benutzen.

 

[dentech]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, gibt es. Meldemechanismen des S7 Graph und ProDiag zu benutzen.

Das ist bei 7 Schritten ein bißchen mit Kanonen auf Spatzen geschossen.

Da du in jedem Schritt mehrere Zylinder bewegst bzw. Ventile ansteuerst, wird dir eine Schrittüberwachung nicht viel bringen. Ich denke du möchtest ja wissen genau welcher Zylinder den Sensor nicht erreicht. Also würde ich einen FC oder FB machen, der die Ventilansteuerung über einen Zeit mit den Endlagensensoren vergleicht.

 

[TP-Inc]

Wir führen z.B. Ventile als Standardbaustein den wir X-Fach benutzen. Dieser Baustein verwaltet auch die Fehlerbehandlung. Die Schrittkette muss ( und darf auch ab einer gewissen Komplexität) sich nicht darum kümmern.

 

[Blockmove]

Das ist bei 7 Schritten ein bißchen mit Kanonen auf Spatzen geschossen.

Da du in jedem Schritt mehrere Zylinder bewegst bzw. Ventile ansteuerst, wird dir eine Schrittüberwachung nicht viel bringen. Ich denke du möchtest ja wissen genau welcher Zylinder den Sensor nicht erreicht. Also würde ich einen FC oder FB machen, der die Ventilansteuerung über einen Zeit mit den Endlagensensoren vergleicht.

Genau diese Endlagen-Überwachung ist mit ProDiag mit ein paar Mausklicks erledigt.
Dazu die grafische Darstellung der Schrittkette und der betroffenen Programmteile macht ProDiag interessant.
Ist auf jeden Fall Mal nen Blick wert.

Gruß
Blockmove

 

[jok3r]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir führen z.B. Ventile als Standardbaustein den wir X-Fach benutzen. Dieser Baustein verwaltet auch die Fehlerbehandlung. Die Schrittkette muss ( und darf auch ab einer gewissen Komplexität) sich nicht darum kümmern.

Das ist die einzig richtige Lösung, wie ich finde.

 

[Thomas_v2.1]

Das ist die einzig richtige Lösung, wie ich finde.

+1
Zumindest für alles was sich "objektifizieren" lässt. Und ein Ventil welches Endlagen besitzt lässt sich ohne Einschränkungen in ein Objekt überführen. Eine Motorschutzschalterüberwachung würde doch auch niemand innerhalb der Schrittkette auswerten.

PrioDiag hat sicher seine Berechtigung, aber den Nutzen der Darstellung des Programmteils am Panel sehe ich nicht wirklich. Ein Programm welches im Fehlerzustand notwendig macht in den Quellcode zu schauen (und das ist die Programmanzeige) ist meiner Meinung nach nicht optimal. Optimal wäre es, die Störmeldung im Störmeldetext so eindeutig zu beschreiben, dass sich der Fehler damit eindeutig lokalisieren lässt.

 

[Blaner]

Störmeldung im Störmeldetext

+1
Optimal wäre es, die Störmeldung im Störmeldetext so eindeutig zu beschreiben, dass sich der Fehler damit eindeutig lokalisieren lässt.

Danke für die Antworten.
Ich habe jedoch noch grundlegende Probleme mit Alarme/Meldungen.

Erstelle ich am besten mit SRT_DINT einen Verzögerungsalarm oder erstelle ich eine Bitmeldung, wobei ich damit Probleme mit der Triggervariable BOOL/UINT habe.

Ich bin auch für jeden Link zu Videos/Pages/Beispielen sehr dankbar.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

PrioDiag hat sicher seine Berechtigung, aber den Nutzen der Darstellung des Programmteils am Panel sehe ich nicht wirklich. Ein Programm welches im Fehlerzustand notwendig macht in den Quellcode zu schauen (und das ist die Programmanzeige) ist meiner Meinung nach nicht optimal.

ProDiag ermöglicht genauso "objektorientierte" Störungen.
Wir haben schon seit S5-Zeiten Aktorbausteine mit den üblichen Paar- und Endlagenüberwachungen im Einsatz.
Diese lassen sich ohne Aufwand in ProDiag integrieren. Aber das funktioniert auch ähnlich einfach mit ProgrammAlarm.
Solange es simple Anlagen und Schrittketten sind, gibt es sicher keine großen funktionallen Vorteile mit ProDiag.
Interessant ist aber aber trotzdem, da der Programmieraufwand für die Strungsauswertung geringer ist.
Einfache Stöungen (Motorschutz, Sicherungsfall, Druckluft, ...) kannst du einfach in der Symboltabelle anlegen.
Nur am entsprechenden Eingang eine Überwachung hinzufügen und gut ist. Bitmeldung oder Programmalarm sind hier mehr Aufwand.

Jeder muss halt abwägen, welche Lösung für welchen Zweck am sinnvollsten ist.

Gruß und Guten Rutsch
Blockmove

 

[Thomas_v2.1]

Einfache Stöungen (Motorschutz, Sicherungsfall, Druckluft, ...) kannst du einfach in der Symboltabelle anlegen.
Nur am entsprechenden Eingang eine Überwachung hinzufügen und gut ist. Bitmeldung oder Programmalarm sind hier mehr Aufwand.

Du meinst wie bei den SCAN-Meldungen in Step7? Da konntest du deine Meldungen auch schon in der Symboltabelle parametrieren.
Ich habe das selber aus diversen Gründen nie verwendet, und ich habe auch hier im Forum noch nie davon gelesen.

Aber es gibt ja diverse weitere Funktionen welche die S7-300/400 schon beherrschten, die aber nie verwendet wurden (Baustein-/Symbolbezogene Meldungen, ProDiag). Und jetzt beim TIA-Portal soll das auf mal die große Sensation sein.

 

[Cassandra]

Aber es gibt ja diverse weitere Funktionen welche die S7-300/400 schon beherrschten, die aber nie verwendet wurden (Baustein-/Symbolbezogene Meldungen, ProDiag). Und jetzt beim TIA-Portal soll das auf mal die große Sensation sein.

Scheinbar gab es Programmierer, die bei einem Fehler nur eine rote Lampe zum leuchten brachten. Die „Diagnose“ erfolgt dann per „PG“! *ROFL*

http://w3.siemens.com/mcms/automati...tal-optionen/videos/seiten/video-prodiag.aspx

 

[Senator42]

Zuviel Werbung?
-> Hier kostenlos registrieren

einfaches Beispiel:

L s5t#2s
U automatik
U A-Ventil
UN E-Rückmeldung
SE Tx

U Tx
= Meldebit

Dies für beide Richtungen.
In einem Objekt-FB mit SFB/SFC-Timer ist auch gut. (Dort auch automatik,hand etc.)

 

[Blockmove]

L s5t#2s
U automatik
U A-Ventil
UN E-Rückmeldung
SE Tx

U Tx
= Meldebit

Warum ist da überhaupt Automatik drin?
Die Inbetriebnahme und auch eine Fehlersuche findet nicht in Automatik statt.

 

[Senator42]

Warum ist da überhaupt Automatik drin?
Die Inbetriebnahme und auch eine Fehlersuche findet nicht in Automatik statt.

Weil bei einer Störung normalerweise die Automatik raus fliegt.
Bei manchen Softwarekonstrukten kann man mit anstehender Störung auch in Hand nicht mehr fahren.
In Hand muss man immer fahren können. (bis zum HW-Endschalter etc.)
Dann und wann poppt auch eine Meldefenster hoch, und das behindert dann die Handfunktionen am Touchdisplay.

Hab was vergessen:
U Quit
R Meldebit
U Tx
S Meldebit

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber es gibt ja diverse weitere Funktionen welche die S7-300/400 schon beherrschten, die aber nie verwendet wurden (Baustein-/Symbolbezogene Meldungen, ProDiag). Und jetzt beim TIA-Portal soll das auf mal die große Sensation sein.

Sensation sicher nicht.
Ich hab PDiag und ProAgent auch schon in Classic verwendet.
Aber da war Speicherplatz, Zykluszeit, Lizenzkosten und Handling schlichtweg das Thema.
Bei den meisten Änderungen musste das HMI neu übersetzt werden und so dauerte eine Inbetriebnahme mit PDiag eigentlich länger als ohne.

Ich denke die meisten hier werden auch bei der 1500er ihre "normale" Diagnose verwenden.
Wenn ich bei unseren ext. Firmen das Thema "Programalarm" angesprochen habe, dann kam nur erstauntes Achselzucken.

 

[Thomas_v2.1]

ProDiag kostet doch jetzt auch extra, oder?

Was es bei WinCC (V6.x / V7.x) auch schon seit sehr langer Zeit gibt, ist der Codeeinsprung zur Verwendungsstelle einer Variable. Also z.B. ein EA-Feld einfügen in der eine Variable angezeigt wird oder ein Kreis dessen Farbe bei Störung rot wird, und dann bei Mausklick auf das Objekt wird automatisch der Programmbaustein geöffnet. Hat nur niemand verwendet.

 

[jok3r]

ProDiag kostet doch jetzt auch extra, oder?

Wenn du nur die Meldungen meinst, 250 Meldungen kosten 150 Euro.. ab 5 Lizenzen kannst du dann bis zu 10.000 Meldungen projektieren.
Aktuell musst du nur die gekauften Meldungen in der HW Config angeben,.... mehr will ich jetzt dazu nicht mehr sagen die meisten wissen wohl was ich damit meine .
Die kosten halten sich also bisher in grenzen

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du nur die Meldungen meinst, 250 Meldungen kosten 150 Euro.. ab 5 Lizenzen kannst du dann bis zu 10.000 Meldungen projektieren.
Aktuell musst du nur die gekauften Meldungen in der HW Config angeben,.... mehr will ich jetzt dazu nicht mehr sagen die meisten wissen wohl was ich damit meine .
Die kosten halten sich also bisher in grenzen

Du vergisst die Panel-Lizenz.
Dabei handelt es sich um eine "richtige" Lizenz und die kostet ca. 400€
Arbeitet man bisher mit normalen Bitmeldungen rechnet sich ProDiag durch die Arbeitsersparnis.
Bei "objektorientierten" Meldungen mit ProgramAlarm sieht es anders aus.
Es gilt ganz einfach der alte Spruch "Für jede Arbeit das richtige Werkzeug".

Gruß und Gutes Neues Jahr
Blockmove

 

[Blaner]

Hallo Blaner an Blaner ;-)
, ich habe die einfach Lösung deine Problems für dich.

Als Beispiel habe ich ich im FC1 (FUP) ein SR-Glied an dem am Setzeingang der Digitale Eingang %i0.0 hängt.

1. Ich erstelle einen Datenbaustein DB1 und deaktviere unter Eigenschaften/Attribute den optimierten Bausteinzugriff.
2. Ich füge im Datenbaustein DB1 eine neue Variable mit dem Namen Fehler (was dann auch die Triggervariable ist) mit dem Datentyp INT hinzu.
3. Man fügt hinter das SR-Glied eine Zuweisung (=) dahinter
4. Ein Klick in die Zuweisung und man tippt folgendes ein: "DB1".Fehler.%X0

In den weiteren Schritten fährt man wie im Handbuch beschrieben fort. (Projektieren von Bitmeldungen)