RMA
Level-1
- Beiträge
- 400
- Reaktionspunkte
- 24
-> Hier kostenlos registrieren
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!
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!