Auslastung CX9000 bei Nutzung der Oscat Lib 320

[woga]

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

[gravieren]

Hi

Verrate uns noch, welche OSCAT-Bausteine du verwendest  ?


Oder passiert das auch ohne Aufruf der Bausteine ?

[Tom]

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.

[gravieren]

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.   

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

[woga]

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

[gravieren]

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

[woga]

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

[woga]

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

[woga]

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

[gravieren]

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

[woga]

Ich würde dir gerne mal einen Screenshot anhängen aber ich weiß nicht wie

[peewit]

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..

 

[woga]

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]

[peewit]

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]

[peewit]

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]