OSCAT Forum
oscat.lib => oscat.lib fuer TwinCAT/CoDeSys => Thema gestartet von: woga am 14. November 2010, 13:32:22
-
Hallo Leute,
ich hab das seltsame Phänomen, dass sich meine CX9000 immer scheinbar aufhängt, sobald ich mein Projekt mit der Oscat Lib 320 downloade. Nach diversen erfolglosen Versuchen hab ich mir für einen Test eine CX1000 geliehen und das Projekt, bei dem sich die CX9000 aufhängt, auf die CX1000 geladen. Und siehe da, es läuft problemlos... ???
Beim Einloggen des Projekts auf die CX9000 bekomme ich folgende abschließende Compilermeldungen:
Bausteinindizes 1687 (82%)
Größe der verbrauchten Daten: 62109 von 1048576 Bytes (5.92%)
Größe der verbrauchten Retain-Daten: 5350 von 131072 Bytes (4.08%)
0 Fehler, 0 Warnung(en)
Codegröße 293317 Bytes
Auslastung im Systemmanager geht von 9% auf 78% nach dem Runterladen des Projekts mit Oscat Lib
Beim CX1000 sieht es so aus
Bausteinindizes 1651 (80%)
Größe der verbrauchten Daten: 57281 von 1048576 Bytes (5.46%)
Größe der verbrauchten Retain-Daten: 4256 von 131072 Bytes (3.25%)
0 Fehler, 0 Warnung(en)
Codegröße 204073 Bytes
Die Auslastung im Systemmanager bleibt bei 5%
Ich hab sogar schon bei gestoppter SPS nach dem Runterladen 78% Auslastung.
Hat irgendjemand eine Idee woran das liegen könnte? Ich weiß langsam nicht mehr weiter...
Wolfgang
-
Hi
Verrate uns noch, welche OSCAT-Bausteine du verwendest ?
Oder passiert das auch ohne Aufruf der Bausteine ?
-
Die Auslastung erscheint schon recht hoch. Arbeitest du viel mit REAL oder STRING?
Ich hab auf meinem CX9001:
Bausteinindizies: 1873 (91%)
Größe der verbrauchten Daten: 61850 von 1048576 Bytes (5.90%)
Größe der verbrauchten Retain-Daten: 0 von 32768 Bytes (0.00%)
0 Fehler, 0 Warnung(en)
Codegröße 228053 Bytes
Auslastung ca. 20%. Ich war aber auch schon mal bei 80%, als ich ein paar STRING-Funktionen aus der OSCAT eingesetzt hatte.
Allerdings hatte sich der CX nicht aufgehängt, so weit ich mich erinnere.
-
Hi
Auslastung ca. 20%.
O.K.
Ich war aber auch schon mal bei 80%, als ich ein paar STRING-Funktionen aus der OSCAT eingesetzt hatte.
Möglicherweise läuft die STRING-Konvertierung in JEDEM Zyklus. ;D
Einmal den String wandeln reicht ja nicht ?
(Ist Ironisch gemeint)
Allerdings hatte sich der CX nicht aufgehängt, so weit ich mich erinnere.
CPU-Stop bei zykluszeitüberschreitung soll es geben. ;)
Gruß Karl
-
Hi
Verrate uns noch, welche OSCAT-Bausteine du verwendest ?
Vorerst arbeite ich nur mit dem Calendar Baustein.
Oder passiert das auch ohne Aufruf der Bausteine ?
Aber dieser Hänger passiert auch ohne Aufruf. Es reicht die Library einzubinden
Die Steuerung ist eine CX9000-N000
-
Hi
Aber dieser Hänger passiert auch ohne Aufruf.
Es reicht die Library einzubinden
Die Steuerung ist eine CX9000-N000
Nur Speicherplatz mit der OSCAT belegen.
KEIN Aufruf ?
Falls ja, denke ich deine Hardware ist defekt.
Kannst du dir mal eine andere ausleihen (Gleicher Typ)
Und das nochmals testen ?
Gruß Karl
-
Hallo Karl,
tja, leider kann ich mir keine weitere CX9000 zum Test besorgen. Aber ich halte einen Hardwaredefekt auch eigentlich für unwahrscheinlich. Immerhin läuft der größte Teil des Programms fehlerfrei bei 9% Systemauslastung.
Der Unterschied zwischen den beiden Steuerungen liegt in der Zielplattform. Möglicherweise liegt der Hund da irgendwo begraben!?
CX9000 -> "CX(ARM)"
CX1000 -> "PC oder CX(x86)"
Allerdings sollte man meinen, dass die Library auch schon auf einigen CX9000 problemlos läuft. Wird im Forum ja auch in ein, zwei Threads erwähnt. Deshalb denke ich, dass es an irgendeiner blöden Einstellung liegen muss... aber an welcher?
Wolfgang
-
Die Auslastung erscheint schon recht hoch. Arbeitest du viel mit REAL oder STRING?
Hallo Tom,
ohne die Library liegt meine Auslastung lediglich bei 9%. Die Einzige Funkiton, die ich von der Oscat im Moment nutze ist der Calendar Baustein.
Ich hab auf meinem CX9001:
Bausteinindizies: 1873 (91%)
Größe der verbrauchten Daten: 61850 von 1048576 Bytes (5.90%)
Größe der verbrauchten Retain-Daten: 0 von 32768 Bytes (0.00%)
0 Fehler, 0 Warnung(en)
Codegröße 228053 Bytes
Auslastung ca. 20%. Ich war aber auch schon mal bei 80%, als ich ein paar STRING-Funktionen aus der OSCAT eingesetzt hatte.
Allerdings hatte sich der CX nicht aufgehängt, so weit ich mich erinnere.
Karl hat vorgeschlagen mein Programm mal auf einer anderen CX9000 laufen zu lassen. Vielleicht könntest du mein Programm mal auf deinem Controller testen? Was denkst du?
Gruß, Wolfgang
-
Hallo Leute,
ich hab noch ein paar Tests gemacht. Irgendetwas hab ich vor lauter Tests zuvor wohl falsch interpretiert. :-\ Die Steuerung geht nicht in maximale Auslastung wenn die Library nur eingebunden wird. Es muss schon ein Bausteinaufruf dazu kommen. In meinem Fall ist das nun der Calendar_Calc. Erst wenn dieser Baustein aufgerufen wird geht das System in den Wald. Fehlermeldung beim debuggen: Page Fault! Abarbeitung gestoppt.
Ich hab die Funktion Calender_Calc mal mit Hilfe der Breakpoints Step by Step durchlaufen. Die Steuerung bleibt in der Sun_Time hängen. Und zwar bei der Berechung der declination. Die funktion DEG scheint hier wohl das Problem zu sein! Zumindest bekomme ich exakt in dieser Zeile den Page Fault.
Wolfgang
-
Hi
Ich habe nur eine Wago 750-841.
Lege doch mal deinen Code hier herein.
Stelle sicher, dass dieser Code das Problem verursacht !.
Gruß Karl
-
Ich würde dir gerne mal einen Screenshot anhängen aber ich weiß nicht wie ???
-
hallo woga
laut deiner aussage sollte dieser aufruf das problem sein
sun_declination := DEG(DK);
kannst du uns mitteilen welchen wert die variable DK vor dem aufruf hat ?
ich habe da einen verdacht, das hier bei der berechnung ein real wert entsteht, der entweder "NAV" (not a value) oder "INF" unendlich ist
und das konnte durch einen bug in runtime vom beckhoff alles stoppen
screenshoot ?
man drückt die "ALT+DRUCK" Taste dann öffnest du paint oder ähnliches und machst einfügen, speichern etc...
und beim posten in oscat sagst du "erweiterte optionen", denn rest wirst du selber finden..
-
Hallo Peewit,
beim Aufruf von DEG(DK) ist der übergebene Wert (DK) -0.3402102
beim Debuggen von DEG wird MODR aufgerufen wobei RAD eben den übergebenen Wert von -0.3402102 hat.
MODR.In ist -19.49261
Die Zeile MODR := in - DINT_TO_REAL(FLOOR2(in / divi)) * divi;
wird mit folgenden Werten ausgeführt:
In=-19.49261 DIVI=360
Somit wird Floor2 aufgerufen hier ist X -5.414614e-002 Floor2 ist 0 und somit größer als X
Somit wird die If Anweisung Floor2:=Floor2-1; ausgeführt und es sollte 0-1=-1 herauskommen. Wenn diese Funktion mit F8 verlassen wird, kommt sofort der Page Fault.
Kann ich eigentlich auf deine Anfrage direkt antworten? Wie?
Gruß,
Woga
[gelöscht durch Administrator]
-
kannst du mal ein komplett neues projekt anlegen, wo du nur folgendes machst (siehe bild)
wenn es dann auch noch abstürzt , haben wir zumindest mal sicher eingegrenzt
[gelöscht durch Administrator]
-
du kannst auch mal probeweise meine bug-exploid probieren
mal sehen ob auch bei deine version dieser bug auch noch vorhanden ist.
[gelöscht durch Administrator]
-
du kannst auch mal probeweise meine bug-exploid probieren
mal sehen ob auch bei deine version dieser bug auch noch vorhanden ist.
Hallo Peewit,
danke für die exploid. Weiß nur nicht recht wie ich die einbinden und testen soll!?
Was den Test mit der Funktion DEG betrifft, so hab ich die mal eingebunden und den Übergabeparameter wie beschrieben fest eingestellt - und was soll ich sagen? Die Ergebnisse sind Uneinheitlich. Hört sich blöd an - ist aber so. Zuerst hatte ich eine normale Auslastung. Dann wollte ich debuggen, ging aber irgendwie nicht... also noch mal alles Bereinigen, alles übersetzen und einloggen. Danach Auslastung 81% -> also wieder page fault. Steuerung restarten. Noch mal testen wieder der Page Fault. Also nochmal alles Bereinigen, alles übersetzen und einloggen. Breakpoint setzen und starten. Kein Pagefault mehr. Ein paar mal durchlaufen mit F8, dann mit F5 und dann Breakpoint gelöscht. Auslastung bleibt bei 2%. Ich kann machen was ich will - der Fehler kommt jetzt nicht mehr ???
Bin jetzt doch etwas ratlos. Was kann hier nur anders sein als beim Aufruf in der Calendar_calc?
Wolfgang
-
wenn du es nicht wirklich eingrenzen kannst, dann solltest du schrittweise dein projekt verkleinern.
also alles entfernen, was möglich ist, so dass theoretisch nur mehr der fehlerauslösende code überbleibt.
und dieses minmalprojekt mit dem bug, solltest du online stellen.
es wird genug leute geben, die es dann für dich testen können, um zu sehen, ob das problem bei allen ist.
-
Hi Pewitt,
die Ergebnisse kommen mir nicht ganz echt vor. Vermutlich bin ich schon ein bisschen zu lange dran. Ich werde heute nicht mehr weiterkommen... Morgen bin ich unterwegs. Ich schau mal dass ich am Mittwoch mal weitermachen kann und der Sache etwas mehr auf die Spur komme. Ich denke es sollte kein Problem sein ein kleines Minimalprojekt hinzubekommen...
Was dein Exploit betrifft, kannst du mir noch einen kleinen Tipp geben wie ich das einsetzen soll?
Danke, Wolfgang
-
das ist ja nur ein kleines projekt, mit einen programm das eine berechnung durchführt, die bei manchen systemen einen totalabsturz verursacht
eigentlich sollte es reichen wenn du dieses projekt auf deine sps lädst und startest
wenn du online werte sehen kannst, dann ist dein system von diesem bug nicht betroffen
wenn schon, dann wirst du ja mit dem absturz-dialog bekanntschaft machen
(siehe bild im anhang)
[gelöscht durch Administrator]
-
Ich war aber auch schon mal bei 80%, als ich ein paar STRING-Funktionen aus der OSCAT eingesetzt hatte.
Möglicherweise läuft die STRING-Konvertierung in JEDEM Zyklus. ;D
Einmal den String wandeln reicht ja nicht ?
(Ist Ironisch gemeint)
Gruß Karl
Es waren diverse Umwandlungen von DT_TO_STRF und DWORD_TO_STRF für Visualisierungszwecke. Da die Daten dynamisch sind, musste ich auch die Umwandlung ständig ausführen. Hatte schon Zykluszeit bei 250ms und die Bearbeitung nur, wenn die Daten benötigt werden. Ansonsten hätte ich jeden einzelnen Wert auf Änderung prüfen müssen. Das fand ich zu dicke und hab alles in die Visu verlegt.