TIA Meldungen mit Program_Alarm

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für TIA und 1500 gabs da auch mal irgend ne Bibliotheksvorlage, aber keine Ahnung, wie da der Stand ist und ob das schon für Unified geht...
LBP Library for Basic Processes:

Die Bibiliothek ist aktuell.

Die Verwendung mit WinCC V8 ist für mich interresant um die mal aus zu werten.

 

[de vliegende hollander]

Ja, das wird einige Zeit dauern das aufzubauen. Aber so ist der Plan.
Fast alles was du geschrieben hast benötigen wir in dem Projekt. Also ist vermutlich ein sehr gutes Projekt zum Einstieg, vor allem weil es vor Ort auch sehr klein gehalten ist.

Als Beispiel habe ich jetzt einen Baustein zur Ansteuerung eines monostabilen Ventils gebaut. Der wird über einen UDT mit den Signalen zur automatischen und händischen Ansteuerung versorgt. Diese entstehen teils durch eine Schrittkette oder durch das HMI (Handansteuerung).
Es sind aber auch zusätzliche Eingänge für diese Signale vorgesehen, falls da doch noch was zusätzlich kommen sollte.
Der Baustein verwaltet auch Schaltfreigaben und Schutzabschaltungen. Außerdem werden die DI-Endlagen an den Baustein übergeben und in den UDT geschrieben, falls diese an anderer Stelle im Programm benötigt werden.
Der Baustein hat eine Simulations-Funktion, mit der die Endlagen automatisch geschrieben werden.
Ach und die Ventil-spezifischen Fehler werden auch im Baustein generiert (Laufzeitstörung, SchutzAus...) und mit dem Program_Alarm ausgegeben, aber auch über zwei Meldewörter an den UDT übergeben.

Erst 1 Baustein standarisieren. In mei Fall hatte ich ein Antrieb genommen "DRIVE".
Diese Baustein komplett optimieren.
Dann diese baustein als weitere Vorlage benutzen um andere Antriebe zu programmieren "Valve", "SolenoidValve". Und so weiter.
Offset der Signalen gleich halten. In Vorteil mit HMIUDT Anbindung an WinCC Unified
Gleiche principe mit Analogwertverarbeitung.

Und du kannst weiter optimieren um nicht oft verwendete IN/OUT Schnittstellen zu verbergen. So das dein Baustein optisch nicht so gross wird.
Variabelen vorbelegen die immer gleich sind. Zum beispiel eine Reset.
Startwerte IN Variablen sinnvol vorbestimmen so das nu nicht unbeding alles immer beschalten musst.

Es wird sowieso ein paar Anlagen dauern bis die Bausteinen auf Hochglanz sind.

In mein Fall is da auch ein paar TIA, HMI und SPS Generationen darüber gegangen

Es muss nicht auf 1 mal komplett sein was du machst.
Es muss aber fehlerfrei sein was du machst.

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Analogwertverarbeitung gibt es ja Bausteine.Scale und Norm.
Aber was ich zum Bsp. nicht gefunden habe oder weiss ausgegraut war, war ein Rampenbaustein.
Bei den Reglerbausteinen ist auch nicht so viel vorhanden wie frueher meine ich.

 

[de vliegende hollander]

Analogwertverarbeitung gibt es ja Bausteine.Scale und Norm.

Ja, da kannst du was skalieren.
Ist bei Verwendung nur ein Bruchteil einer Standart Baustein

 

[sps_klassik]

Wie meisnt du das?

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie meisnt du das?

Mit dem Scale oder Norm alleine kanst du ein Eingangswort skalieren.
Direkt am Baustein parametrieren. Und as skalierungsergebnis irgendwo hinschreiben. Merkerwort, DB oder so.

In ein wiederverwendbare Standart Baustein ist den Scale / Norm mit intergriert. Also ein Teil des Standart Bausteins.
Ein wiederverwendbare Standart Baustein enthält mehr wie skalierung. U.a. wie hier ober geschrieben Rangierung zum Zentrale Leittechnik, alarmierung, Schnittstelle zu HMI.

 

[sps_klassik]

Ja das ist so.In der Leittechnik haben sie gleich Grenzwertalarmmeldungen.
Oder Ersatzwerte oder letzter gültiger Wert wenn das Signal ausfällt.
Das hätte man schon integrieren können in den neuen Bausteinen.

 

[ducati]

Wie meisnt du das?

Schau Dir die Doku zum Scale an und schau Dir die Doku zum Messwertbaustein der Industry Library an...

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier mal von mir zum pProgramm Alarm:

Bei uns hatte das auslösen maßiv auf den zyklus geschlagen, wir begrenzen nun wieviel Alarme pro Zyklus ausglöst werden dürfen. Dadurch haben wir den programlarm baustein gekapselt, was es etwas unschön macht, da man von der Störmeldung immer in den geleichen Baustein springt, und im Stack dann erst einen Aufruf zurück muß.
Vorteil ist eben das unsere Visu automatisch aktuell ist, wenn es eine neue Störmeldung gibt.
Wobei wir es mitlerweile auch unterstützen, einen DB direkt von der Steuerung als Störmeldung auszulesen, und dessen Kommentare als Meldetext einzulesen. D.h. das ist dann auch aktuell ohne Visu anpassung (ist ne eigene Visu).
Für fremdvisualisierungen, melden wir uns innerhalb der CPU am meldesystem an, uns setzten die Meldungsnummer in ein Bit um. Auch haben wir dann noch einen Modus jede Störmeldung einmalig anzutriggern (ist einfach da wir programalarm ja gekapselt haben), dadurch kann man sich bei uns per TCP eine Liste aller Meldungen der CPU abrufen.

 

[de vliegende hollander]

Bei uns hatte das auslösen maßiv auf den zyklus geschlagen, wir begrenzen nun wieviel Alarme pro Zyklus ausglöst werden dürfen.

Die massive zykluszeit ist ein Nachteil ja.
ich aktiviere nur die vorhandene Alarme. Das betrifft vor alm die Analogwert Verarbeitung.
habe ich zum Beispiel keine LowLow oder HighHigh Alarmen/Abschaltung werden die Alarmen nicht aktiviert.
und damit wird der programAlarm übersprungen

 

[for_real]

Moin zusammen,

gibt es hier jetzt schon mehr Erkenntnisse zu Programmalarmen bei laufenden Anlagen ?
Habe ne mittelgroße Ablaufmaschine und planen auch das Fehlermanagement per Programmalarme umzusetzen.
Selbst bei Siemens konnte ich noch keine verlässliche Antwort bekommen, wie sich die Prog.Alarm genau auf die Zykluszeit auswirken.

@Jochen Kühner verwendet ihr auch Weckalarme ?

VG Jan

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was sind weckalarme?

 

[for_real]

Weckalarm-OB´s,

HMI und Rezepturen will ich im Main(OB1) laufen lassen. Also auch die die ganzen Programmalarm Aufrufe (fest auf 50ms).
Weil wir aber ne relativ schnelle Applikation haben will ich den Prozess und die Prozessrelevante Peripherie im Weckalarm-OB laufen lassen(2-4 ms).

Eigentlich dürften die Programmalarme daher mich kaum stören.

 

[Jochen Kühner]

miss doch mit dem RUNTIME baustein die laufzeit

 

[for_real]

Zuviel Werbung?
-> Hier kostenlos registrieren

das wäre jetzt mein nächster Schritt gewesen, wenn es bisher noch Niemand gemacht hat.
Haben gerade nur, wie immer, Zeitdruck
Aber trotzdem danke für den Tipp

 

[de vliegende hollander]

das wäre jetzt mein nächster Schritt gewesen, wenn es bisher noch Niemand gemacht hat.
Haben gerade nur, wie immer, Zeitdruck
Aber trotzdem danke für den Tipp

Ich habe beim Unstieg auf programalarm schnell die nicht verwendete programalarme übersprungen.
Also zum Beispiel im mehrfach verwendete Analogwert Baustein. ich brauche nicht immer 4 Alarme.

Das hat bei mir schon einige milisekunden ausgemacht auf eine 1516 CPU

 

[Moritz_]

Also bei uns hatte es auch massive Auswirkungen auf die Zykluszeit, ich habe es aber auch nicht gekapselt wie @Jochen Kühner (glaube du hattest dazu irgendwo code gepostet).
Nicht benutzte Alarme wurden aber deaktiviert @de vliegende hollander schon weiter oben geschrieben hatte.

Schlussendlich habe ich mich doch gegen den ProgramAlarm entschieden, da wir hin und wieder mehrsprachige Projekte haben und mit dem ProgramAlarm der Text im Meldearchiv nur in der Sprache hinterlegt ist, in der der Fehler ausgelöst wurde. Heißt wenn die Visu auf polnisch stand, dann die Sprache gewechselt wird, sind die Meldungen im Archiv immer noch auf polnisch.

Ich habe es nun so, dass ich eine Liste mit all meinen "Geräten" habe die Standardbausteine haben und daraus erzeuge ich mir über ein Excel-Makro eine Störmeldeliste, die ich ins HMI importiere.
Teilweise auch wieder umständlich , weil man nur eine Sprache auf einmal importieren kann.

Finde den ProgramAlarm aber trotzdem eine nette Möglichkeit.