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