Step 7 Störungsbaustein mit DB

Matthias 68

Level-1
Beiträge
12
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich benötige eure Hilfe. Ich habe mir einen Störungsbaustein mit Merkeradressen gebastelt. Dieser Funktioniert auch soweit einwandfrei. Ansteuern tue ich damit Meldungen in WinCC die als Warnung deklariert sind. Durch das erst und Zweitquittieren am Störungsbaustein bleibt meine Meldung im WinCC auch Stehen bis die Störung wirklich beseitigt ist und nochmals quittiert ist. Nun habe ich das ganze von Merkeradressen in Datenbausteinadressen umgebaut und mit der PLC-Sim nochmals getestet, aber nun kommen alle Störungsbits gleichzeitig, wenn nur eine Störung ansteht. Kann das an der PLC-Sim liegen, oder an dem Datenbaustein? Ich benütze die Version 5.5.

DB40.DBX0.0 = Hupenstörung
DB40.DBX0.1 = Sammelstörung
DB40.DBX0.2 = Sammel-Quittierstörung
DB40.DBX0.3 = Schmiermerker Störung
DB40.DBX0.4 = Störung Quittieren

U #Eingang
= DB40.DBX 0.3

U DB40.DBX 0.3
UN #Stoerung
U #Hupe_Ein
S DB40.DBX 0.0

U DB40.DBX 0.3
UN #Stoerung
S DB40.DBX 0.1
S #Stoerung

U #Stoerung
UN DB40.DBX 0.1
S DB40.DBX 0.2

UN DB40.DBX 0.3
U DB40.DBX 0.4
R #Stoerung
 
Hallo,

ich glaub nicht, dass es am PLCSim oder an dem DB liegt. Ich denke eher, dass hier Mehrfachzugriffe stattfinden. Hast Du mal in die Querverweisliste geschaut? Auch adressübergreifend (Byte, Word usw.)? Vielleicht hattest Du die Mehrfachzugriffe auch zufällig bei den Merkern und jetzt nicht mehr.

Ansonsten:
Was heißt, es kommen alle Störungsbits gleichzeitig? Welche?
Welche von den Bits sind im WinCC verwendet?
In welchem Bereich liegen die #-Variablen (Temp, Static, ...)?
Du setzt etliche Bits - wo werden die wieder rückgesetzt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo MRose,

habe ich alles geprüft. Habe sogar die Bausteine aus dem Projekt herauskopiert in ein Leerprojekt, aber ohne Erfolg.
Gleichzeitig heißt: Ich rufe die oben genannte Logik bei meinen einzelnen Störung immer wieder auf (z.B. Motorschutz, Automaten oder Niveaus usw.) Meine gesetzte OUT-Variable in den Schnittstellen, wird wie gesagt bei der DB-Lösung bei allen Störungen gesetzt. Bei der Merker-Lösung habe ich das Problem nicht hier funktioniert alles einwandfrei. Mein Kunde möchte aber die Schnittstelle zum Panel mit DB´s haben. Ich habe dir auch mal mein Reset des Störungsbausteins angehängt.

NW1 Hupen-Störung zurücksetzen

U DB40.DBX 0.5 F1-Taste am Panel
R DB40.DBX 0.0

NW2 Ansteuerung Hupe

O DB40.DBX 0.0
O DB40.DBX 2.0 Lampentest
= A 21.2

NW3 Störung quittieren

U DB40.DBX 0.6 F6-Taste am Panel
R DB40.DBX 0.1
R DB40.DBX 0.2
= DB40.DBX 0.4

Leider kann ich es an der Anlage noch nicht testen, deshalb habe ich es mit der PLC-Sim getestet.
 
Die Codeschnipsel sind also 4 Netzwerke, zuerst der Code aus Post #1, dann der aus #3, oder?
Steht das in einem FC oder FB?

Ist #Stoerung die OUT-Variable, die letzten Endes die Meldung am Panel erzeugen soll?
Ist das so, dann steht beim Aufruf des FC/FB hoffentlich jedes Mal eine anderes Bit (Merker/DB) dran.

Oder, falls FB, greifst Du direkt die OUT-Variable #Stoerung aus dem Instanz-DB ab?
Dann verwendest Du hoffentlich bei jedem FB-Aufruf (= bei jeder Deiner Störungen) einen neuen Instanz-DB bzw. bei Multiinstanz einen neuen Bereich.


Irgendwie ist mir das Zusammenspiel insgesamt noch schleierhaft.
Poste doch mal den FC/FB-Aufruf und wie die zugehörige Meldungsprojektierung beim Panel aussieht.
 
... ich muss MRose hier zustimmen.
Irgendwie macht das Ganze, so aus einem möglichen Zusammenhang heraus, überhaupt keinen Sinn ...

@TE:
Vielleicht solltest du den Thread wirklich, wie vorgeschlagen, mit etwas mehr Drum-herum-Informationen "würzen" ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Noch eine Anmerkung:

Wenn diese Codeschnipsel tatsächlich der Inhalt des Störungs-FC/FB sind, dann würde ich dort nicht mit Absolutzugriffen auf eine DB arbeiten. Sinnvoller wäre es, in dem Baustein nur Variablen (In, Out, Temp usw.) zu verwenden. Erst beim Aufruf wird er dann mit DB-Zugriffen beschaltet.
 
Hallo Matthias,

lobenswert was Du da machst aber warum verwendest Du nicht die Systemfunktionen von STEP 7 ALARM_S ALARM_DQ SFC17, SFC 18, SFC 117, SFC118 oder im Falle der S7 400 ALARM_8P?
Diese Meldeverfahren sind optimal auf WinCC abgestimmt.

Gruß
Johannes
 
@JOHKU
Hast Du bei der 300er schon Langzeiterfahrungen damit sammeln können?
Bei der 400er hab ich den Alarm_8P auch schon eingesetzt. Bei der 300er haben mich bisher die ganzen Warnungen beim Alarm_DQ (blockierte Systemressourcen, nicht mehr funktionierende Alarme) davon abgehalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe nun mal die Bausteine in ein Word-Dokument kopiert, vielleicht wird es dann etwas deutlicher was ich machen muss. Die Bits des DB160 sind in WinCC den einzelnen Bitmeldungen zugeordnet. Wie gesagt mit Merkern geht das ganze nur eben mit den DB´s nicht. Das mit den SFC´s werde ich mir mal anschauen, für weitere Projekte.

Gruß
Matthias
 

Anhänge

  • Störungsprogramm.doc
    165 KB · Aufrufe: 113
Hallo,

benützt habe ich schon ein paar Mal diese Bausteine, und immer mit der 300-Steuerung. Allerdings muss ich auch sagen, dass ich Programme nur sporadisch mache, wenn es klemmt. Mein Hauptaufgabengebiet ist EPlan. Ich habe diese Variante auch deshalb vorgezogen, weil mir damit das Quittieren besser gelungen ist in WinCC bzw. ich nicht mehr quittieren muss in WinCC. Ich kann so mit einer F-Taste oder einem separaten Taster am Schaltschrank quittieren. Auch wenn wir mehrere Steuerungen miteinander verbunden haben kann ich das Quittieren leichter weitergeben. Verwendet wird in diesem Fall eine IM151-8F PN/DP CPU und ein KTP600.

Gruß
Matthias
 
Ich hatte die Rückfrage eigentlich an JOHKU gerichtet, wegen den Alarmbausteinen.
Egal.


Und wenn Du nur M1.0 setzt, dann werden alle Bits DB160.DBX0.0 bis DB160.DBX0.3 aktiv?
 
Zurück
Oben