Step 7 CPU 318-2AJ00 Batteriestatus auslesen

DeltaMikeAir

User des Jahres 2018; 2023
Beiträge
21.465
Reaktionspunkte
7.076
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich möchte an einer CPU 318-2AJ00-0AB0 den Batteriestatus auslesen. Allerdings nicht über den OB81 PS Fault sondern mittels SFC51
Siemens liefert hierfür folgendes Beispiel:

CALL "RDSYSST" // SFC 51 : lesen des Systemstatus
REQ :=TRUE // Anstoss der Bausteinbearbeitung
SZL_ID :=W#16#19 // Kommando an SFC51 : 0019 auslesen aller LED's
INDEX :=W#16#0 // Zum Auslesen des Batteriefehlers ist der Index irrelevan
RET_VAL :=MW2 // Fehlercode
BUSY :=M1.0 // 1 Baustein im Prozess : 0 Fertig - 1 in Process : 0 ready
SZL_HEADER:=#szl_header // Angabe über Datensatzlänge und
DR :=P#M 20.0 BYTE 20

L MW 20 // DS1 : Kennung LED : Sammelfehler 0001 h
L MB 22 // DS1 : An 1 / Aus 0
L MB 23 // DS1 : Blinken der LED : ja/nein

L MW 24 // DS2 : Kennung LED : Run 0004 h
L MB 26 // DS2 : An 1 / Aus 0
L MB 27 // DS2 : Blinken der LED : ja/nein

L MW 28 // DS3 : Kennung LED : Stop 0005 h
L MB 30 // DS3 : An 1 / Aus 0
L MB 31 // DS3 : Blinken der LED : ja/nein

L MW 32 // DS4 : Kennung LED : Force 0006 h
L MB 34 // DS4 : An 1 / Aus 0
L MB 35 // DS4 : Blinken der LED : ja/nein

L MW 36 // DS5 : Kennung LED : Batteriefehler 0008 h
L MB 38 // DS5 : An 1 / Aus 0
L MB 39 // DS5 : Blinken der LED : ja/nein
BE

Ich habe alles soweit eingefügt und teilweise funktioniert es: RUN LED wird korrekt angezeigt und dass sie leuchtet. Wenn ich auf Stopp stelle wird
auch dies richtig angezeigt. Bei den Werten für Batteriefehler steht allerdings immer 0 drin, obwohl sie permanent leuchtet ( keine Batterie drin ).

Ich habe anders als in dem Siemens Beispiel nicht Merker verwendet sondern mit einen DB mit 20 Byte angelegt, so dass es zu keinen Überschreidungen
kommen kann.

Kennt jemand dieses Problem und kann mir weiterhelfen

Ich bin für jede Hilfe dankbar.
 
Welche Anzahl an LED-Einträgen sollst du denn laut SZL_header zurückbekommen?
20 Bytes Datenbereich ist auch etwas wenig, damit bekommst du nur max 5 LEDs zur Anzeige. Meistens werden die LED der ID nach aufsteigend übermittelt. Wenn du z.B. noch die INTF und EXTF LEDs hast, dann sind 5 Einträge zu wenig. Wie viele LEDs vorhanden sind, lässt sich über Abfrage der SZL-Headerinformationen (0x0f19) herausfinden.

Ist im Datensatz der LED denn ein Eintrag mit der BAF-Kennung vorhanden, also mit 8?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei den Werten für Batteriefehler steht allerdings immer 0 drin, obwohl sie permanent leuchtet ( keine Batterie drin ).
Erhältst Du tatsächlich die Datensatzkennung W#16#0008 und den Zustand 0?
Versuche alternativ die SZL-ID W#16#0074 oder W#16#0174 mit INDEX W#16#0008

RUN LED wird korrekt angezeigt und dass sie leuchtet. Wenn ich auf Stopp stelle wird
auch dies richtig angezeigt.
Das klingt ja "magic" - kann man im Programm feststellen, daß die STOP-LED leuchtet oder die RUN-LED aus ist bevor die CPU in STOP ist??? :cool:

Harald
 
Das klingt ja "magic" - kann man im Programm feststellen, daß die STOP-LED leuchtet oder die RUN-LED aus ist bevor die CPU in STOP ist??? :cool:

Wenn die CPU auf Stop steht, kann das Programm es natürlich nicht mehr auswerten. Allerdings steht im DB unter dem Status der STOP LED sobald man in
Stopp geht der Wert 5 ( statt 0 ) was ja laut Siemens Beschreibung richtig wäre

Welche Anzahl an LED-Einträgen sollst du denn laut SZL_header zurückbekommen?
20 Bytes Datenbereich ist auch etwas wenig, damit bekommst du nur max 5 LEDs zur Anzeige. Meistens werden die LED der ID nach aufsteigend übermittelt. Wenn du z.B. noch die INTF und EXTF LEDs hast, dann sind 5 Einträge zu wenig. Wie viele LEDs vorhanden sind, lässt sich über Abfrage der SZL-Headerinformationen (0x0f19) herausfinden.

20 Bytes gibt Siemens vor. Dies ist ja ein Beispiel von Siemens welches laut diesen natürlich auch funktionieren soll.
 
Wenn die CPU auf Stop steht, kann das Programm es natürlich nicht mehr auswerten. Allerdings steht im DB unter dem Status der STOP LED sobald man in
Stopp geht der Wert 5 ( statt 0 ) was ja laut Siemens Beschreibung richtig wäre
5 ist nicht der Zustand der STOP-LED sondern deren Kennung. Der Zustand steht im nächsten Byte und kann laut Dokumentation nur 0 oder 1 sein.

Harald
 
Hallo Thomas,

im Datensatz steht 0. Das steht bei den anderen aber auch. Der Wert wechselt erst auf den entsprechenden Wert, wenn die LED leuchtet oder blinkt ( Mit dem entsprechenden Wert im nächsten Byte )
nur eben bei dem BatF nicht. Es steht immer 0 drin. Egal ob an oder aus.

Mit der Anzahl der LED´s und das evtl. verlängern der Struktur werde ich Montag ausprobieren.
Danke Thomas
 
Guten morgen noch einmal,

ich schreibe noch einmal bezüglich der Auswertung des Batteriefehler, welchen ich mittels SFC51 auswerten möchte.
Ich habe die alte CPU 318-2AJ00-0AB0 mit dem letzten Firmwarestand. In diesem habe ich das original Programmbeispiel
von Siemens enigefügt:
https://support.industry.siemens.co...inen-batteriefehler-der-s7-300?dti=0&lc=de-WW
https://cache.industry.siemens.com/dl/files/722/23330722/att_114692/v1/23330722_battery_fault.pdf

Laut Siemens funktioniert das Beispiel mit jeder S7-CPU, welche noch keinen MMC Card Slot hat ( weil diese keine Pufferbatterie mehr haben )

Der Batteriefehler steht an, der Baustein gibt am Ausgang "BAF" FALSE raus. Wenn ich in den Siemens Baustein reingehe kommt der RET_VAL 32898 ( = 8082 )
welcher bedeutet: "SZL_ID falsch oder in der CPU bzw. in der SFC unbekannt"

Ich bin für jede Hilfe dankbar.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich überlege ich daran schon die ganze Zeit ob dein Problem sein könnte, das die alte 318er ja eigentlich eine umgewandete 400er und eben eigentlich keine 300er ist ...
Was sagt SZL-ID 0392 dazu?

Mfg
Manuel
 
Hallo Manuel und danke für deine Nachricht.

Mit W#16#0392 wird der gleiche Status geliefert. Ich hatte auch schon den Gedanken mit der 400ér CPU. Ich habe noch eine alte 315 DP im Regal und werde das ganze nachher
mit dieser einmal ausprobieren. Ich gebe dann kurze Rückmeldung.

Mit Grüßen
 
Hallo Manuel,

ich werde noch verrückt. Jetzt habe ich eine alte 315-2AF03 und hier kommt auch der RET VAL 8082 unbekannte SZL ID.
Das kann doch nicht so schwer sein. Es scheitert wieder an den einfachsten Dingen :-(
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist im Datensatz der LED denn ein Eintrag mit der BAF-Kennung vorhanden, also mit 8?
Erhältst Du tatsächlich die Datensatzkennung W#16#0008 und den Zustand 0?
Diese Frage hast Du noch nicht beantwortet.


Versuche alternativ die SZL-ID W#16#0074 oder W#16#0174 mit INDEX W#16#0008
Hast Du dies mal ausprobiert?

Oder nimm dieses fertige Programmierbeispiel: Getting the Status for the CPU LED Indicators
Der da gezeigte FC112 "GetLEDState" versucht es zuerst mit der SZL-ID W#16#0119 und bei Misserfolg mit der SZL-ID W#16#0174

Was sagt SZL-ID 0392 dazu?
Laut der Operationsliste der 318-2 kennt diese CPU die SZL-ID 0392 wohl nicht.

Harald
 
Hallo Harald

Hast Du dies mal ausprobiert?

Oder nimm dieses fertige Programmierbeispiel: Getting the Status for the CPU LED Indicators
Der da gezeigte FC112 "GetLEDState" versucht es zuerst mit der SZL-ID W#16#0119 und bei Misserfolg mit der SZL-ID W#16#0174

Erhältst Du tatsächlich die Datensatzkennung W#16#0008 und den Zustand 0?
Wie oben beschrieben, in der Datensatzkennung steht 0, bei Zustand ebenfalls

Das ist genau das Beispiel, welches ich aktuell benutze ( mit der SZL ID W#16#392 )

Ist im Datensatz der LED denn ein Eintrag mit der BAF-Kennung vorhanden, also mit 8?
Nein, er ist nicht vorhanden, nur 4 und nach einem Stopp 5

Laut der Operationsliste der 318-2 kennt diese CPU die SZL-ID 0392 wohl nicht.

Ich habe das gleiche gerade mit einer alten 315-DP probiert. Es kommt ebenfalls der RET Val welcher aussagt "SZL ID unbekannt".
Laut dem Siemens Beispielprogramm soll es mit allen S7-300 funktionieren, welche noch keine MMC Card haben ( diese haben auch keine Pufferbatterie mehr )

Der Siemens Support weiß auch nicht so genau wie es gehen sollte :evil:
 
Hallo zusammen,

für alle die es interessiert, es funktioniert jetzt.

Ich rufe den SFC51 mit SZL Index W#16#19 und Index W#16#0 auf. Auf DR setze ich eine Struktur von 0..320 OF BOOL.
Das Bit [144] auf dem DR Block spiegelt die BATF LED wieder.

Grüße und eine schöne Woche
 
Zuviel Werbung?
-> Hier kostenlos registrieren
für alle die es interessiert, es funktioniert jetzt.

Ich rufe den SFC51 mit SZL Index W#16#19 und Index W#16#0 auf. Auf DR setze ich eine Struktur von 0..320 OF BOOL.
Das Bit [144] auf dem DR Block spiegelt die BATF LED wieder.
"funktioniert" - sicher???

Spielst Du da an einer Industrieanlage oder ist das ein Testaufbau?
Verstehst Du eigentlich auch was Du da tust?
Hast Du Dir mal die Dokumentation der SZL-ID W#16#xy74 und W#16#xy19 angesehen?

Beim Auslesen des LED-Status mit der SZL-ID W#16#0019 oder W#16#0074 bekommt man eine Liste von Datensätzen, wo man zunächst anhand der Datensatz-Kennung vergleichen muß, auf welche LED sich ein Datensatz bezieht. In der Dokumentation der SZL-ID steht nichts davon, daß die Datensätze garantiert in einer bestimmten Reihenfolge kommen. Sich einfach irgendein Bit aus der Liste herausgreifen und daraus irgendeine Information interpretieren, bezeichne ich als stümperhaft.

Harald
 
Hallo,
beim Auftrag W#16#0119 kommt die Kennung mit ( siehe hier Seite 394 :
http://www.kleissler-online.de/Siemens/SFCs.pdf
)
Mit W#16#0019 kommen kontinuierlich alle LED´s im folgenden Format:

W#16#0000: nicht relevant
W#16#0001: SF (Sammelfehler) Bit 32
W#16#0002: INTF (interner Fehler) Bit 48
W#16#0003: EXTF (externer Fehler) Bit 64
W#16#0004: RUN Bit 80
W#16#0005: STOP Bit 96
W#16#0006: FRCE (Forcen) Bit 112
W#16#0007: CRST (Neustart) Bit 128
W#16#0008: BAF (Batteriefehler/Überlast, Kurzschluß von Batteriespannung am Bus) Bit 144
W#16#0009: USR (anwenderdefiniert) usw.....
W#16#000A: USR1 (anwenderdefiniert)
W#16#000B: BUS1F (Busfehler Schnittstelle 1)
W#16#000C: BUS2F (Busfehler Schnittstelle 2)
W#16#000D: REDF (Redundanzfehler)
W#16#000E: MSTR (Master)
W#16#000F: RACK0 (Baugruppenträger-Nr. 0)
W#16#0010: RACK1 (Baugruppenträger-Nr. 1)
W#16#0011: RACK2 (Baugruppenträger-Nr. 2)
W#16#0012: IFM1F (Schnittstellenfehler Interface-Modul 1)
W#16#0013: IFM2F (Schnittstellenfehler Interface-Modul 2)

Gruß
 
Zuletzt bearbeitet:
Zurück
Oben