Step 7 Verhalten von Temp. Merker unklar

S

Strömling

Level-2
Beiträge
66
Reaktionspunkte
17
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo
Hatte hier mehrere CPU-316-2 DP 316-2AG00-0AB0 V1.2.0
beobachtet mit Step7 Prof V5.6_SP2_HF3
Es geht wie im Foto zu sehen um den #Loesch mit Deklaration, NW4 Scheiben , NW5 Lesen -sonst nicht weiter verwendet
Darf man hier kein temp -Merker verwenden-und wenn nein Warum ?temp_loesch.JPG Gruß Strömling
 
Schalte den Code mal auf AWL um, in Netzwerk 5 wird vermutlich in den Lokaldaten ein Zwischenmerker für die FUP-Darstellung verwendet. Nicht dass es da eine Überschneidung mit der Adresse von #Loesch gibt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
NW4

U "DB_DÜ_MPI".Stat.Error
FP "DB_DÜ_MPI".Stat.I_Error
= #Loesch
U #Loesch
SPBNB _003
L 0
T DB59.DBD 0
_003: NOP 0


NW5

U "HIGH"
= L 4.0
U L 4.0
U "DB_DÜ_MPI".Stat.neu
= "DB_DÜ_MPI".Fi.weiter
U "DB_DÜ_MPI".Fi.weiter
= "Due_akt"
U L 4.0
U "DB_DÜ_MPI".Stat.Busy
FN "DB_DÜ_MPI".Stat.I_Busy
O #Loesch
R "DB_DÜ_MPI".Stat.neu
 
Ich denke dass die positive Flanke das Problem ist. Loesch wird nicht dauerhaft beschrieben. Dann kann die Temp Variable ein beliebige Zustand haben. Weil das Temp Bereich in mehrere Bausteinen vetwendet wird. Schreib testweise den mal auf dauer false
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Thomas_v2.1 schrieb:
Firmwareversion der CPU? Vielleicht gab es da mal einen Fehler.
Zum Vergrößern anklicken....
Er schrieb ja oben schon V1.2.0
Die letzte Version wäre V1.2.1

Folgende Fehler wurden mit dem neuen Firmware-Stand behoben:

  1. Uhrzeitsynchronisation auf MPI: nach Änderung des Zeitintervalls sendet der Master nicht mehr
    Wird das Sendeintervall einer als Uhrzeitmaster (MPI) projektierten CPU geändert, abgespeichert und in die CPU geladen und danach die Uhrzeit noch mal geändert, ohne abzuspeichern, dann wird ab sofort die geänderte Uhrzeit mit Synchronisations-Telegrammen an die Slaves gesendet.
  2. Urlöschanforderung nach Komprimieren im RUN oder bei RAM-to-ROM
    Komprimieren im RUN führt nicht mehr zur Urlöschanforderung. Dieses Fehlverhalten wurde in Einzelfällen auch bei RAM-to-ROM (implizit wird hier urgelöscht) festgestellt und tritt hier ebenfalls nicht mehr auf.
  3. Status Baustein mit Aufrufumgebung funktioniert nicht
    Aufrufpfad mit Adresse (in neuen STEP7 Versionen mit rechter Maustaste aktivierbar) ist nun möglich.
  4. An Sprungzielen liefert Status Baustein ein falsches Ergebnis
    Der Status von nicht bearbeiteten (übersprungenen) Programmzeilen wird nun nicht mehr angezeigt.
  5. Defekt 6e10 nach mehrmaligem "Stack"-Auslesen
    Mehrmaliges "Stack"-Auslesen führt nicht mehr zum Defekt 4550: 6e10.
Zum Vergrößern anklicken....
https://support.industry.siemens.co...m-updates-für-s7-316-2-dp-cpus?dti=0&lc=de-WW
 
Zumindest gibt es dort schon mal einen Hinweis zum falschen Status Baustein:
An Sprungzielen liefert Status Baustein ein falsches Ergebnis
Zum Vergrößern anklicken....
Hier noch mal was mit Status Baustein:
  1. Status Baustein mit Aufrufumgebung funktioniert nicht
    Aufrufpfad mit Adresse (in neuen STEP7 Versionen mit rechter Maustaste aktivierbar) ist nun möglich.
Zum Vergrößern anklicken....
 
#Loesch wird in NW4 immer beschrieben. #Loesch darf grundsätzlich eine TEMP-Variable sein und in NW5 wieder gelesen werden.

Wie Thomas schon schrieb, könnte es sein, daß die FUP-Darstellung in NW5 automatisch eine TEMP-Adresse verwendet, die sich mit #Loesch überschneidet. Dann müsste es aber eine Warnung beim Anlegen/Deklarieren von #Loesch gegeben haben.
Die Überschneidung kann beseitigt werden:
- in AWL umschalten und vorsichtshalber "Speichern"
- wieder in FUP umschalten und "Speichern"
- Baustein in die CPU laden

Es könnte aber auch ein FUP-Darstellungsfehler oder ein Firmware-Fehler der CPU sein. Mache möglichst das CPU 316 Firmware Update zur V1.2.1

Welche
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Firmware oder Hardwaredefekt war auch mein zweiter Gedanke .
Aber ich wollte erst mal sicher sein das der temp Merker im Prinzip richtig verwendet wurde

Step 7 - CPU316 Temp Stack Fehler - nach Jahren endlich gelöst!

Ich wusste schon lange, dass manche ältere S7-300 CPUs diverse Fehler mit dem TempStack hatten. Nur wusste ich nicht welche. Jetzt war ich vor kurzem an einer Anlage, die genau diesen Fehler hatte. Dort waren 2 CPUs verbaut: eine mit Fehler, eine ohne Fehler. Folgendes passiert: Bei CPUs mit...
www.sps-forum.de www.sps-forum.de
 
Auf welche TEMP-Adresse ist #Loesch deklariert? Das dürfte höchstens L3.7 sein.
PS: Arggg, jetzt sehe ich es. Es ist L0.1, also OK. Evtl. wurde L4.0 in NW5 erst durch die Umschaltung zu AWL gesetzt?
PN/DP schrieb:
Die Überschneidung kann beseitigt werden:
- in AWL umschalten und vorsichtshalber "Speichern"
- wieder in FUP umschalten und "Speichern"
- Baustein in die CPU laden
Zum Vergrößern anklicken....

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
s_kraut schrieb:
wenn du schon Temps benutzt, dann setz sie doch im Netzwerk 1 auf 0
Zum Vergrößern anklicken....
Wozu? Es werden doch alle Temp-Variablen eindeutig beschrieben bevor sie gelesen werden.

Der Unterschied bei Busy zwischen NW3 und 5 war von Oberchefe gut erkannt, da liegt wohl noch mehr im Argen, wenn da nicht von einem anderen OB oder anderweitiger asynchroner Kommunikation auf den DB zugegriffen wird.
 
weiß nicht, das war in informatik semester 1 halt so erklärt. bevor man eine variable liest, sollte sie sinnvoll beschrieben sein.
 
s_kraut schrieb:
weiß nicht, das war in informatik semester 1 halt so erklärt. bevor man eine variable liest, sollte sie sinnvoll beschrieben sein.
Zum Vergrößern anklicken....
Die Aussage ist richtig.
Die TEMP-Variable #Loesch wird allerdings vor dem Lesen in NW4 und NW5 im NW4 immer beschrieben - es ist also nicht nötig, ihr vorher irgendwas zuzuweisen.


In FUP/KOP kann man eigentlich nicht gegen eine korrekte VKE-Abgrenzung programmieren. Doch um gaaanz sicher zu gehen, daß da nicht irgendwas aus dem Netzwerk 3 von dem Baustein-Aufruf verschleppt wird, würde ich spontan testweise zwischen Netzwerk 3 und Netzwerk 4 zur garantierten VKE-Abgrenzung eine Dummy-Zuweisung zu irgendeiner BOOL-Variable einfügen (hier am einfachsten zu #Loesch, kann aber auch eine andere Variable sein z.B. eine extra angelegte TEMP-Variable #Bool_Dummy):
Code: 
Netzwerk 4: garantierte VKE-Abgrenzung

                      #Loesch
         +-------+   +-------+
         |   &   |   |   =   |
"HIGH" --|       |---|       |
         +-------+   +-------+

Wie sehen die Netzwerke 1..3 aus?

Harald
 
Korrektur: alle SPS sind schon HW Stand 2 FW V1.2.1 -Sorry

Der Unterschied bei Busy zwischen NW3 und 5 ist wohl durch Zufall bei der Aufnahme entstanden
Busy toggelt- was normal ist

Beim Beobachten ergibt sich ein ergibt sich ein Zeitverzug bei zustandwechsel von ca. 250 ms zwischen NW3 und 5

In der laufenden Anlage wurde schon vor 2 Wochen der Temp -Merker durch einen Absolutmerker ersetzt

Sofort nach Verwendung des Absolutmerkers war das beobachtete Phänomen weg

Vorher war die Bedingung für das nicht setzen des Temp -Merker war aber längere Zeit statisch und klar zu beobachten

Durch das einspielen des Altprogramms in eine einzelne Test SPS mit HW Stand 1 FW 1.2.0 konnte der Fehler nicht simuliert werden
Bedingt dadurch das damit kein MPI Datenverkehr zu simulieren war -waren die Werte nicht dynamisch

code der NW 1..3 alle in FUP geschrieben nach Umschaltung auf AWL ( L4.0 ,BLD, SPBNB usw wird erst durch die Umschaltung erzeugt)

NW1 Prüfen auf neue Daten Kennung SPS ******: 2 -> neuer Datensatz ist eingetroffen -> das Signal wird als Lebendkennung zur *****-SPS zurückgesendet -> wenn keine Änderung der Kennung innerhalb von 15s erfolgt: Störung DÜ L "DB_DÜ_MPI".SPW.ZNr L 2 ==I = L 4.0 U L 4.0 BLD 102 S "DB_DÜ_MPI".Stat.neu U L 4.0 L S5T#15S SE "LZ_DÜ_H" NOP 0 NOP 0 NOP 0 U "LZ_DÜ_H" = #Error O( UN L 4.0 L S5T#15S SE "LZ_DÜ_L" NOP 0 NOP 0 NOP 0 U "LZ_DÜ_L" ) O #Error = "DB_DÜ_MPI".Stat.Error NW 2 Senden der eigenen Kennung an den Slave U "DB_DÜ_MPI".Stat.neu = L 4.0 U L 4.0 SPBNB _001 L "DB_DÜ_MPI".SPW.ZNr T "DB_DÜ_MPI".Fi.Re_ZNr _001: NOP 0 UN L 4.0 SPBNB _002 L 0 T "DB_DÜ_MPI".Fi.Re_ZNr _002: NOP 0 NW3: U "DB_DÜ_MPI".Stat.neu UN "DB_DÜ_MPI".Stat.Error = L 4.0 BLD 103 U( ON "DB_DÜ_MPI".Stat.neu O "DB_DÜ_MPI".Stat.Error ) = L 4.1 BLD 103 CALL "X_PUT" REQ :=L4.0 CONT :=L4.1 DEST_ID :=W#16#3 VAR_ADDR:=P#DB59.DBX66.0 BYTE 8 SD :="DB_DÜ_MPI".Fi RET_VAL :=#Ret BUSY :="DB_DÜ_MPI".Stat.Busy NOP 0
 
Bei Firmeare 1.2.0 wär das klar, da die CPUs einen Serien Hardwarefehler hatten,
die den Temp-Stack betreffen

bei 316-2AG00-0AB0 Hardware Ver. 2 Firmware 1.2.1 ist das Problem aber behoben.


Ich kenn genau solche Fehler aber sowohl von der 316 als auch auch von andern CPUs.
Ich hatte genau gleichen Effekt das letzte mal 2017 bei einer 315-2PN/DP mit etwas älterer Firmware.
Da ich den Fehler bereits kannte, war mit klar, dass ein Firmwarupdate das löst.
 
Zurück
Oben