Step 7 AWL (antiker Code) CPU 315 2DP OK => CPU 315F PN/DP Crash/Stop

shadowdb

shadowdb

Level-1
Beiträge
115
Reaktionspunkte
8
Zuviel Werbung?
-> Hier kostenlos registrieren
Morgen Kollegen,
mein AWL ist zu "eingerostet", vielleicht erkennt ja jmd von Euch, was hier in der "etwas" neueren CPU 315F PN/DP
nicht mehr laufen will. Original Code war auf v5.4, heute mit v5.6.spX bearbeitet.
Code: 
      L     P##Sollwerte_P1             //Zeiger auf Sollwerte Parametersatz 1
      LAR1  
      L     DIW [AR1,P#0.0]             //DB Nr lesen
      T     #DB_Nr
      L     DID [AR1,P#2.0]             //Datenwortnummer lesen
      SRD   3                           // Bitadresse ausblenden
      T     #DW_NR                      //Datenwortadresse zwischenspeichern

Irgendwo dazwischen geht mir die CPU 315F auf STOP, U-Stack Bausteinöffnen öffnet mir genau dieses Netzwerk.
Ja, der Zeiger zeigt auf einen existierenden Datenbaustein und gültige Stuktur, wird als Pointer IN übergeben.

Hat wer eine Idee?
TIA (soll heissen Thank You in Advance) nicht das was Ihr dazu denkt
Gruß aus der sonnigen Schweiz
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was steht denn genau im Diagnosepuffer der CPU?
Und vor allem, auch welche Zeile wird genau gesprungen, wenn du aus dem Diagnosefenster zum Fehler springst?
 
Zuletzt bearbeitet:
Gefunden!

Warum, Erklärung folgt im Screenshot und hier.

Im AWL gibt es wohl einen Unterschied in der Akku Behandlung zwischen der älteren 315 2DP und der neueren 315F PN/DP.
vor meiner Zitierten Stelle lag das Problem:
Code: 
      U     #P2
      L     P##Sollwerte_P2             //Zeiger auf Sollwerte Parametersatz 2
      SPB   PARA
      L     P##Sollwerte_P1             //Zeiger auf Sollwerte Parametersatz 1
PARA: LAR1 
      L     DIW [AR1,P#0.0]             //DB Nr lesen
      T     #DB_Nr
      L     DID [AR1,P#2.0]             //Datenwortnummer lesen
      SRD   3                                // Bitadresse ausblenden
      T     #DW_NR                      //Datenwortadresse zwischenspeichern

#P2 ist ein Eingabe Bool, hier FALSE.
Es wurde L "P##Sollwerte_P2" mit einem Null Pointer ausgeführt. Die CPU 315F PN/DP, eine Fehlersichere, STOP -> Call SFC20.
Die 315 2DP mit der alten Firmware und Nicht Fehlersicher lief ohne zu Zucken darüber hinweg.

In P##Sollwerte_P2 einen gültigen Pointer (z.B. den gleichen wie in P##Sollwerte_P1) geladen, und alles gut. (Oder die Parameterweiche rausgeworfen, wenn man die nicht braucht)

Wieder 2 Büschel Graue Haare mehr.
Danke für's Zuhören, meist hilft ja, anderen das Problem strukturiert zu beschreiben damit man selbst drauf kommt.
 

Anhänge

  • 20220707_100947.png
    20220707_100947.png
    38,6 KB · Aufrufe: 43
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
Es war halt der entsprechende Fehler OB geladen ( und in dem vermutlich keinerlei Reaktion / Fehlermeldung projektiert ). Mit einem Blick in den Diagnosespeicher hätte der Fehler auf der alten CPU schon auffallen müssen.
Zum Vergrößern anklicken....
Nicht unbedingt.
Soweit ich's noch im Kopf hab, gab's da mal nen Unterschied zwischen den Standard- und den F-CPUs.
Bei den alten Standard-CPUs gab's nur nen Fehler im Rückgabewert des SFC20 und bei den F-CPUs gab's AG-Stop.
Da es bei den 300er-CPUs auch diverse Hardwarestände mit unterschiedlichen Prozessoren gab, gab's auch Unterschiede bei der Abarbeitung der Systemfunktionen.
 
Blockmove schrieb:
Bei den alten Standard-CPUs gab's nur nen Fehler im Rückgabewert des SFC20 und bei den F-CPUs gab's AG-Stop.
Zum Vergrößern anklicken....
Warum eigentlich SFC20?
Die CPU ging doch in dem in #1 gezeigten Netzwerk auf STOP ( reiner PointerCode ohne irgendeinen SFC )
shadowdb schrieb:
Fehlersichere, STOP -> Call SFC20
Zum Vergrößern anklicken....
Kann es sein, dass er SFC46 meint ( STP )

PS:
Oder kommt im Netzwerk danach ein SFC 20 Aufruf? Ich weiß es nicht.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
In letzter Konsequenz waren Null-Pointer die Ursache.
Verursacht durch inkonsistente Instanz-DBs und luschig verwendete Lokaldaten, als Mulit Instanz Aufruf verwendet.

Da ich inzwischen TIA "verwöhnt" bin, hatte ich nicht mehr auf diesen "Kleinkram" wie Instanz Daten/Lokaldaten, I-DBs inkonsistent geschaut. Dachte Neu-Laden, Neu-generieren würde reichen. Tat es nicht.

Dabei hat es einen Null-Pointer gegeben, der bei der 315 (alt, nicht Fehlersicher) sich nicht ausgewirkt hatte, weil Irrelevant im Code.
Aber die 315f mochte den Aufruf nicht und ist in Stop gegangen.
Hat mich ca. 8 Std Diagnose uns Suchzeit gekostet.
 
shadowdb schrieb:
Nachdem der 2te Pointer belegt war, lief CPU durch (ohne ob121).
Zum Vergrößern anklicken....
shadowdb schrieb:
In letzter Konsequenz waren Null-Pointer die Ursache.
Verursacht durch inkonsistente Instanz-DBs und luschig verwendete Lokaldaten, als Mulit Instanz Aufruf verwendet.
Zum Vergrößern anklicken....
Die Erklärung mit "Null-Pointer" passt nicht.
In dem von Dir gezeigten Code des Netzwerk 2 kann es nur bei L DIW ... oder L DID ... zu einem CPU-Stop kommen:
- wenn der im DI-Register (DINO) angegebene DB (das sollte der IDB vom FB-Aufruf sein) zu kurz oder nicht vorhanden ist
- oder wenn die IN-Parameter #Sollwerte_P1 oder #Sollwerte_P2 nicht auf "glatten" Byte-Adressen (2.0 und 8.0) liegen, also z.B. Datentyp Bool haben
- oder wenn da die max Zykluszeit überschritten wird
Egal ob der IN-Parameter #Sollwerte_P2 einen gültigen Pointer oder einen Null-Pointer enthält.

Wird vielleicht im Netzwerk 1 das DI-Register verändert? Oder trat der CPU-Stop vielleicht gar nicht in diesem Netzwerk auf?
Willst Du uns nicht doch besser den genauen Diagnosepuffer-Eintrag verraten?

Oder ist da ein Firmware-Fehler Deiner F-CPU 315F PN/DP? Welche Bestellnummer und genau welche Firmwareversion hat Deine CPU?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, da stimme ich zu. Die exakten U/L Stacks hab ich wohl nicht mehr.
Jedoch habe ich das lösen können, dadurch, daß alle I-DBs der Aufrufenden FBs neu generiert wurden, der Sollwert FB mit eigenen I-DBs (3x im Projekt) aufgerufen wird.
> bei L DIW ... oder L DID ... zu einem CPU-Stop kommen
Kam es auch. im Ponter stand Blödsin drin, zeigte auf unmögliche Adresse, einen DB, den es nicht gab, Eine Adresse die es erst recht nicht gab, die Lokaldaten im Call FB wurden beim Übertrag von CPU Alt -> Neu (Übersetzen, Laden) wohl verhunzt.

MMC neu formatiert im PG, Alle neu gemacht, dann trat Problem nicht mehr auf.
Das Handling von Bausteinen und I-DBs ist im Step 7 Classic nicht wirklich der Bringer, besonders wenn man sich schon an TIA gewöhnt hat.

Wie Deine Signatur so schon schreibt, "Wenn man es richtig macht geht's auch"
 
shadowdb schrieb:
im Ponter stand Blödsin drin, zeigte auf unmögliche Adresse, einen DB, den es nicht gab, Eine Adresse die es erst recht nicht gab
Zum Vergrößern anklicken....
shadowdb schrieb:
Ja, der Zeiger zeigt auf einen existierenden Datenbaustein und gültige Stuktur,
Zum Vergrößern anklicken....
Sehr verwirrend. Der genaue Fehler wird wohl unbekannt bleiben.
shadowdb schrieb:
MMC neu formatiert im PG
Zum Vergrößern anklicken....
Wenn du sie formatiert hättest, wäre sie nicht mehr nutzbar. Du hast sie höchstens gelöscht bzw. die Daten auf der Karte.
 

Similar threads

W
Pointerparameter und Datenwortadresse
Antworten
1
Aufrufe
2K
Larry Laffer
Larry Laffer
Zurück
Oben