Daten gehen verloren beim Kopieren in DB!

RMA · 8 Mai 2008

Ich habe ein komisches Problem und wäre dankbar wenn mir jemand irgendwelche Vorschläge machen könnte, was hier los ist.

Ich suche nach einem sporadischen Problem beim Austragen eines Brammen aus einem Hubbalkenofen an eine Warmwalzstrasse. Weil ein relevanter Teil des Programs flankengesteuert ist, sprich es läuft nur für einen Zyklus, habe ich mir einen Ringpuffer gebastelt um die relevanten Daten zu speichern. So was habe ich schon öfter gemacht, wenn auch meistens mit nur 10 - 12 Datenbytes, diesmal geht's um 120.

Im Prinzip scheint es zu funktionieren, nur Bestimmten Daten werden entweder gar nicht übertragen, bzw. werden mit 0 beschrieben. Ich habe die relevanten Bausteine angehängt, FB505 ist der interessante Teil des Programs, FC1 ist mein Speicherprogram und UDT9 ist der STRUCT der dann 256 mal aufgelegt ist in DB499. Bevor ich anfing habe ich den Diagnostikpuffer angeguckt und es waren kein Lese-/Schreibfehler zu sehen.

FC1 und UDT9/DB499 habe ich neu angelegt und FB505 habe ich erweitert mit dem Aufruf von FC1. Die Merker Bits M505.0/1/2 werden vom Bediener (indirekt über E56.2 & E56.4) gesetzt und nur einer davon kann anstehen, diese Bits benutze ich um die Datenspeicherung anzustoßen. Aus dem Grund bin ich relativ sicher, dass die Daten nicht von einem anderen Program überschrieben werden. Uups, hab' fast vergessen zu sagen, die Stahlwerke hat ein Indirekt-Adressierungs-Verbot und obwohl ich schon ein Paar Beispiele gefunden habe, in diesem Programm habe ich bislang nichts gefunden. Dafür gibt es einige Pointer als Parameter übergeben die auch nicht in der Querverweißliste erscheinen aber wie gesagt, als es kein DB499 gab, gab es auch keine Schreib-Lesefehler im Diagnostikpuffer.

Als Beispiele für die Datenverluste:

M505.0 oder M505.2 wird in DB499 gespeichert (M505.1 habe ich noch nicht gesehen, aber das ist wahrscheinlich ein Teil des eigentlichen Problems) aber die Signale die mitunter notwendig sind um diese Bits auf "1" zu setzen wie z.B. M371.5, M372.4, E56.2 oder E56.4 zeigen immer "0"!

Die INTs DB508.DBW112 - 116 zeigen auch immer null, aber die REALs DB508.DBD60 - 72 die davon generiert werden, sind OK.

Darüber hinaus, die Zeit und Datum Werte sind meist OK aber gelegentlich - 3 - 4 mal in ca. 80 Datensätze - sind sie auch "0"!

Die CPU ist eine 416 -2DP.

Also wenn jemand eine Idee hat was hier los sein kann, wäre ich sehr dankbar dafür!

vierlagig · 8 Mai 2008

das hier ist der Teil, der für mein Verständnis irgendwie nicht zu deiner Beschreibung passen will:

Code:

*
      UN    M    505.0; 
      UN    M    505.1; 
      UN    M    505.2; 
      SPB   Exit;

wenn einer von denen das Speichern anschubsen soll ...

und nur einer davon kann anstehen

... dann sollte doch hier eine ODER-Verknüpfung zum tragen kommen...

...es kann natürlich auch sein, dass du ganz was anderes machen willst

[edit] erst denken, dann posten: da steht ja SPB und nicht SPBN ... sorry! also wird aufgezeichnet, wenn eines der Signale da ist ... also wenn es das ist, was du willst, dann nehme ich alles zurück und behaupte das gegenteil![/edit]

Ralle · 8 Mai 2008

Wird in den Alarm- oder Zeit-OB was gemacht, kann der FC1 also von anderen Programmteilen per Interrupt unterbrochen werden?

Grubba · 8 Mai 2008

Hat wahrscheinlich damit nichts zu tun, aber die Siemens Hilfe sagt:

"Wenn Sie mit der absoluten Adressierung arbeiten, können Fehler beim Zugreifen auf Daten auftreten, die in den Registern gespeichert sind: in einigen Fällen werden die Adressen in dem Register AR1 (Adressregister 1) und in dem DB-Register überschrieben. Dadurch kann es sein, dass Sie falsche Adressen lesen oder in falsche Adressen schreiben."

Gefahr
Gefahr von Sachschäden und Personenschäden bei der Verwendung von:

<LI style="FONT-SIZE: 9pt">CALL FC, CALL FB, CALL Multiinstanz
<LI style="FONT-SIZE: 9pt">vollqualifizierte DB-Zugriffe (z. B. DB20.DBW10)
Zugriffe auf Variablen eines zusammengesetzten Datentyps

Es kann dabei geschehen, dass die Inhalte von DB-Register (DB und DI), Adressregister (AR1, AR2) und Akkus (AKKU1, AKKU2) verändert werden.
Ebenso kann beim FB-CALL/FC-CALL das Verknüpfungsergebnis VKE nicht als zusätzlicher (impliziter) Parameter verwendet werden.
Wenn Sie die oben genannten Programmiermöglichkeiten nutzen, müssen Sie selbst für eine Wiederherstellung der Inhalte Sorge tragen, da es sonst zu einem Fehlverhalten kommen kann."

Du biegst ja in Deinem FC ein wenig mehr am AR1 herum und trägst den alten Wert ja nicht wieder ein. Und Du rufst in Deinem FB ja den FC auf.
Sicher doch vorher dein AR und schreib es doch mal zurück, bevor Du den FC verlässt. Ist ja schnell drin und vielleicht hilfts ja. Gerade, weil Deine Fehler ja nur sporadisch auftreten.

Larry Laffer · 8 Mai 2008

Die von Vierlagig angedachte Möglichkeit erschewint mir in anderer Hinsicht nicht so abwegig :
Was ist, wenn nicht nur eins der genannten Bits da ist, sondern (am Besten zeitlich etwas versetzt) mehrere davon ...?

vierlagig · 8 Mai 2008

Larry Laffer schrieb:
Die von Vierlagig angedachte Möglichkeit erschewint mir in anderer Hinsicht nicht so abwegig :
Was ist, wenn nicht nur eins der genannten Bits da ist, sondern (am Besten zeitlich etwas versetzt) mehrere davon ...?

nichts, das war ja mein gedankenfehler, nur wenn alle null sind wird nicht gespeichert

Larry Laffer · 8 Mai 2008

nein , wenn alle auf "0" sind, dann wird darüber hinweg gesprungen ...
wenn einer auf "1" ist, dann wird gespeichert ...

vierlagig · 8 Mai 2008

Larry Laffer schrieb:
nein , wenn alle auf "0" sind, dann wird darüber hinweg gesprungen ...
wenn einer auf "1" ist, dann wird gespeichert ...

doch!

... wenn alle null sind, wird nicht gespeichert

wenn einer oder zwei oder drei eins sind wird gespeichert

Larry Laffer · 8 Mai 2008

das habe ich doch gearde geschrieben ...

RMA · 8 Mai 2008

@Ralle, daran hatte ich nicht gedacht, aber auch wenn, alle Daten stehen ein Zyklus an und der Zyklus wird ja nur verlängert in diesem Fall - oder habe ich Dich falsch verstanden?

@Grubba, das Problem ist mir bekannt, aber so wie ich es verstehe (und diesen Hilfe-Auszug kenne ich auch), hätte ich hier keine Probleme erwartet. Was auch dagegen spricht ist das einige der frühen Zugriff nie funktionieren aber mehere später immer und ich lade AR1 nie wieder, also würde ich erwarten, einmal kaputtgeschossen, immer kaputt (danach). Aber wie Du sagst, es kostet nichts das abzusichern - werde ich ausprobieren!

@Larry, die M505.0 - 2 Bits sind indirekt von Bediener Auswahl-Schalter abgeleitet, und obwohl ich es noch nicht kontrolliert habe (wäre ziemlich aufwendig), ich glaube ich kann mich darauf verlassen, . Abgesehen davon, in den mittlerweile 200+ Einträge in DB499 ist nie mehr als ein Bit aufgetreten (und die aufgenommene Zeiten sind immer 5 - 10 Min. auseiinander).

Larry Laffer · 8 Mai 2008

Ich habe das Problem so verstanden, dass das Programm (ohne es selbst näher beleuchtet zu haben) vom Grundsatz her korrekt funktioniert.

Unter dem Aspekt kann dann alles Mögliche der Fehler sein - vielleicht die Pointer-Register, vielleicht aber auch ein doppelter Start (weil nicht seperat abgesicher). Mir ist das mit den Merkern und dem "SPB Exit" auch gleich als erstes aufgefallen - deshalb meine Anmerkung ...

Gruß
LL

Grubba · 8 Mai 2008

Um die Idee von Ralle nochmal aufzunehmen:

Es ist zwar nicht so, das nach dem Interrupt dein Code nicht weiter bearbeitet wird, vielleicht wird aber evtl. dort irgendwie/irgendwo Dein AR verbogen und dann wieder in Deinen FC zurückgesprungen. Dann wäre er erst ab einer bestimmten Stelle "verbogen"

RMA · 8 Mai 2008

Obwohl ich durchaus der Meinung bin, dass ein Pointer Problem am wahrscheinlichsten ist, ich finde die Sache mit den Interrupt irgendwie unwahrscheinlich - mit Ausnahme der gelegentlichen Fehler, aber auch dann, alle anderen Daten sind wie immer (ob OK oder nicht). Schliesst natürlich nicht aus, das irgend jemand irgend wo ein Interrupt programmiert hat ohne AR1 und AR2 abzusichern!

Aber wie gesagt, ich hätte erwartet, dass wenn AR1 irgendwo während ein Ablauf von FC1 zerschossen würde, dass alle Transfers danach auch irgendwie kaputt sein würde - und das ist nicht der Fall. Oder habe ich irgend wo da ein Denkfehler?

@Larry, vielleicht habe ich an irgendwas nicht gedacht, aber ich rufe FC1 auf am Ende FB505 wo die M505x Merkers gesetzt werden. Laut Programm Beschreibung kann nur eines von diesen Bits gesetzt werden. Indem das Program mit Ausnahme dieses bestimmten Fehlers was nur sehr selten, unter bestimmten Bedingungen auftaucht, seit etwa sieben Jahren läuft, denke ich, dass ich mich darauf verlassen kann. Zugegeben, wenn der Fehler auftaucht kostet es viel Ärger, Schweiß und noch mehr Geld!

Übrigens, ich glaube ich bin schon auf dem Spur des eigentlichen Problems. In FB505 werden die Bits M505.0 & M505.2 in Zusammenhang mit entweder E56.x oder E64.x. Wie es sich herausstellt, im VAT & Online konnte ich sehen, dass im Moment immer E64.x benutzt wird. Aber im Sonderfall Säule 8 wird ab Label SAE8 nur E54.4 abgefragt, was dazu führt, dass falsche (alte) Werte für Brammen-Länge und Breite übergeben werden, was die Probleme erklären könnte.

Aber in diesem Thread interessiert mich viel mehr wieso ein Technique das ich seit ein Paar Jahren regelmässig benutze, plötzlich nicht mehr zuverlässig arbeitet!

RMA · 8 Mai 2008

So nun habe ich einiges ausprobiert mit keinem direkten Erfolg - aber, als ich dabei war, ist mir aufgefallen, dass die INTs die ich ganz am Ende von FC1 kopiere, habe ich in DBDs statt DBWs kopiert!

Also, nun funktioniert alles ausser den BOOLs. Könnte es sein, dass ich sie mit "S" statt "=" kopieren muss? Werde ich morgen ausprobieren!

Wenn ich darüber nachdenke, ich benutze diese Methode sehr oft beim testen, aber bislang nur mit Byte, WORD oder DW. Ich bin ziemlich sicher, dass ich es bislang nie mit BOOLs probiert habe.

Lars Weiß · 8 Mai 2008

RMA schrieb:
Könnte es sein, dass ich sie mit "S" statt "=" kopieren muss?

Nein, das ist schon so ok.

RMA · 9 Mai 2008

OK - kann mir jemand das erklären!!!

Also, nun habe ich meine Zuweisungen mit SETs ersetzt und siehe da, nun funktioniert alles (vorher DBW6 mit 0 geladen um alte Daten zu löschen)!

Die einzige Erklärung die mir einfällt ist, dass, wie LL sagte, FC1 wird ein zweites mal durchlaufen, obwohl ich kann gar nicht verstehen wieso!

Trotzdem, Danke für die Hilfe.

Übrigens, meine Vermutung in #13 hat sich bestätigt und das Problem ist auch schon gelöst.

Kai · 9 Mai 2008

RMA schrieb:
Also, nun habe ich meine Zuweisungen mit SETs ersetzt und siehe da, nun funktioniert alles (vorher DBW6 mit 0 geladen um alte Daten zu löschen)!

Hast Du diese Zuweisungen aus dem FC1 geändert?

Code:

      U     M    505.0; 
      =     DBX [AR1,P#6.0]; 
 
      U     M    505.1; 
      =     DBX [AR1,P#6.1]; 
 
      U     M    372.4; 
      =     DBX [AR1,P#6.4]; 
 
      U     M    371.5; 
      =     DBX [AR1,P#6.5]; 
 
      U     DB500.DBX   42.6; 
      AUF   DB   499; //reopen Data Save DB
      =     DBX [AR1,P#6.6]; 
 
      U     DB500.DBX   42.7; 
      AUF   DB   499; //reopen Data Save DB
      =     DBX [AR1,P#6.7]; 
 
      U     E     47.4; 
      =     DBX [AR1,P#7.0]; 
 
      U     E     47.5; 
      =     DBX [AR1,P#7.1]; 
 
      U     E     56.2; 
      =     DBX [AR1,P#7.2]; 
 
      U     E     56.3; 
      =     DBX [AR1,P#7.3]; 
 
      U     E     56.4; 
      =     DBX [AR1,P#7.4]; 
 
      U     E     64.4; 
      =     DBX [AR1,P#7.5]; 
 
      U     E     64.6; 
      =     DBX [AR1,P#7.6];

Gruß Kai

RMA · 13 Mai 2008

@Kai, sorry für den verspäteten Antwort, bin Wochenendpendler und war schon um 13:00 Freitag auf der A7 Richtung Nord!

Ja, die zwei Bytes habe ich von Zuweisungen in SETs geändert, nun funktioniert es!

Daten gehen verloren beim Kopieren in DB!

RMA

Level-1

Anhänge

vierlagig

Level-1

Ralle

Super-Moderator , User des Jahres 2006-2007

Grubba

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

vierlagig

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

vierlagig

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

RMA

Level-1

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

Grubba

Level-1

RMA

Level-1

RMA

Level-1

Lars Weiß

Level-3

RMA

Level-1

Kai

Level-1

RMA

Level-1

Similar threads

Wir schützen deine Privatsphäre