Welches Meldeverfahren?

Promoter

Level-1
Beiträge
24
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen

Bin schon länger dabei mich in das Thema Meldesystem für ein TP177 einzulesen. Leider habe ich noch immer zu wenig Ahnung um mich für ein Meldeverfahren entscheiden zu können. Follgende Aufgabe soll erfüllt werden:
- Fehler-,Warnungs- und Ablaufmeldungen sollen am TP angezeigt werden.
- Es sollen mehrere TP's an der Steuerung (über Profibus) mit den Meldungen versorgt werden
- Fehlermeldungen sollten über TP und über SPS (Eingang) quittiert werden können

Grösster Knackpunkt ist, dass z.B. ein Ventil einen Fehler auslöst (Aufruf eines FC's) und danach im Fehlerzustand auf die quittierung wartet. Der "Fehler-FC" wird also nur einmal aufgerufen.
Jedes Ventil kann gleichzeitig den gleichen Fehler oder Warnung aufweisen.

Nun, ich wäre froh, wenn mir jemand ein wenig helfen könnte. Im Moment denke ich, dass ich mit dem Meldenummernverfahren besser zurecht komme, da Warnungen bei mir ja nicht anstehen, sondern nur kurz (eben ein einmaliger Aufruf des FC's) ausgelöst werden. Mit dem Bitmeldeverfahren müssten die Warnungen immer anstehen, bis sie nach einer gewissen Zeit nicht mehr vorhanden sind.

Vielen Dank
Promoter
 
Ich nutze ausschließlich das Bitmeldeverfahren. Hauptgrund ist eigentlich, daß ich damit auf dem kleinsten gemeinsamen Nenner aller Steuerungen und Visualisierungen liege, denn, das können wirklich alle. Wenn ein Ventil in Störung steht, ist es doch eigentlich kein Problem, den Fehler dauerhaft als Bit auszugeben? Ich kann mit gut vorstellen, daß es bei großen Anlagen vorteilhaft sein kann, an die Visualisierungen Meldungen abzusetzen, aber das war bei mit bisher nie nötig.

Alle drei Punkte, die du aufführst, sind mit den Bitmeldungen zu realisieren, zumindest bei Siemens-Panels, gibt es getrennte Bits für die Quittierung von OP und SPS.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du mehrere TPs hast, würde ich mir Überlegen auf AlarmS zu gehen.
Vorteil: Du brauchst die Alarme nicht auf jedem Panel anlegen. Während der Projektierung sicher kein Problem, wenn aber bei der IB ein Alarm dazukommt, machst Du einen Rundgang durcht die Anlage und spielst über all die neue Projektierung auf.

Ralle hat recht, Bit-Meldeverfahren ist Siemens unabhängig. Aber so wie Du schreibst, hast Du nur Siemens Panels.

Gruss
Audsuperuser
 
Besten Dank für die Schnellen Antworten.

Bei den Fehlermeldungen ist das Anstehen des Fehlers kein Problem, da ich die mit dem quittieren dann wieder zurücksetzen kann. Doch bei Warnungen und Ablaufmeldungen sieht das etwas anderst aus. Einzige Möglichkeit, die mir bis jetzt in den Sinn gekommen ist, dass ich diese Meldungen für ca 5 Sekunden anstehen lasse (mit einem Timer) und dann zurücksetze. Ist aber nicht wirklich elegant.

Weiteres Problem ist, dass jedes Ventil gleichzeitig einen Fehler (ca. 10 Mögliche) anzeigen soll. Und natürlich dann auch die Warnungen.
Also muss ich soviele Einträge in der Bitmeldetabelle vornehmen, wie ich Ventile habe, und dann anhand einer Textliste einer der 10 Fehler auslesen. Das ganze noch einmal für die Warnungen. Ist irgend wie nicht so toll.

Übrigens: Ja, verwende ausschliesslich Siemens-Material :)

Grüsse
Promoter
 
@Promotor

Man kann ja String-Variablen in die Meldetexte (Flexible) einfügen, das wäre evtl. eine Möglichkeit, ich weiß nicht, ob man auch Textlisten da einfügen kann. So könnte man also ein Bit für die Störung nutzen und über eine Variable/String/Nummer diese Störung präzisieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja genau so habe ich es gemacht, mit Textlisten das geht. Doch muss ich trotzdem für jedes Ventil einen Eintrag machen. Und dann noch mal Anzahl Meldetypen, da Feher, Warnungen und Ablaufmeldungen zusammen anstehen können. Puhhh...werd mich jetzt mal an einen Versuch mit Alarm_? wagen.
Danke euch allen.
 
Suche doch mal hier nach "Alarm_S" und du wirst interessante Infos finden...

Ich verwende bis jetzt nur das Meldenumernverfahren - bis jetzt.

Zur zeit überlege ich aber das Bitmeldeverfahren mal auszuprobieren da die Alarm_S Geschichte recht ist so lange du bei der CPU nicht kleckern musst (sondern klotzen kannst).

Bei sehr vielen Meldungen wird das aber ganz schön aufgebläht - vor allem wenn man viel (aus faulheit natürlich) Reserve lässt.

Der Editor für die Meldetexte in Step7 ist einfach nur schlecht aber das Hauptproblem sehe ich bei den Meldebausteinen.

Diese sind eben auch sehr aufwändig abzugleichen.

Ich sammle die Bits ohnehin schon in entsprechenden DBs welche wiederum die Meldung anstossen - da wäre es eigentlich rel. leicht umzustellen (für mich jetzt).

Einfach die Bits in die Visu umbiegen und die Texte zuordnen.

Vielleicht lasse ich es aber auch so - denn funktionieren tuts ja hervorragend und mache für kleinere CPUs mit wenig Meldungen einfach was neues mit dem Bitmeldeverfahren.

Wie gesagt - da bin ich noch am überlegen...

Ich habe wohl den Vorteil daß ich immer in der gleichen Materie bin und die Meldungen so gut wie immer wieder verwenden kann - dann loht sich die einmalige Arbeit eigentlich schon.

Aber es kommt halt auch immer mehr dazu weswegen die Menge halt auch immer mehr wird.

Ich muss also pro Projekt die nicht benötigten Meldungen auskommentieren da sonst der Baustein zu groß werden würde - speziell bei den "16kB-CPUs"

Einen Vorteil möchte ich aber auch nicht verschweigen:

Bei Alarm_S ist die Sache mit den Begleitwerten ziemlich geschickt da oft der Wert beim Auftreten der Meldung interessant ist. Dieser kann rel. elegant in die Meldung mit eingebaut werden - aber auch hier gilt: Sparsam damit umgehen wegen Speicherplatzverbrauch!

Beispiel: "Differenz Messwert A / B -> Wert A: 100°C / Wert B: 88°C"

Die beiden hervorgehobenen Werte sind als Begleitwerte beim Aufteten der Störung hineingeschoben und können danach zu jedem Zeitpunkt in der Meldeliste nachgesehen werden ohne sie irgendwo zwischenzuspeichern...
 
Zurück
Oben