Hallo zusammen,
ich programmiere für das cRIO. Starte ich meine Anwendung aus LabVIEW heraus (über den Ausführen-Pfeil), dann wird das Programm sofort abgearbeitet.
Erstelle ich nun eine RT-Exe daraus, dann dauert es 1 - 2 Minuten, bis das Programm läuft. Die CPU-Auslastung liegt in der Zeit bei rund 100%. Der Arbeitsspeicher nimmt in dieser Zeit kontinuierlich zu, bis er so voll ist, wie auch bei der aus LabVIEW heraus gestarteten Anwendung. Dann sinkt die CPU-Auslastung und das Programm läuft.
Muss man da irgendetwas beachten (Compiler-Optionen o.ä.) oder wie ist das Verhalten zu erklären?
Die Anwendung läuft ohne RT-Exe viel besser als mit. Ich hätte eigentlich das Gegenteil erwartet, da der ganze Ethernet-Overhead (Frontpanel in LabVIEW sichtbar, Sonden etc.) wegfällt.
Grüße
Matze
Das ist ganz klar von Deiner Anwendung abhängig und kein typisches Verhalten.
Die autarke RT Applikation läuft aus meiner Sicht in der Regel als Zustandsmaschine ab, soll heissen InputProcessingOutput.
In der Verarbeitungsphase muss man bekanntermassen auf die CPU Last achten und die Schleifen etwas timen, da bei zu hoher CPU Last die Kommunikation abbricht.
Meine Vermutung: Die Zunahme des genutzten RAM liegt wohl an dynamischer Alloziierung was in der Regel auch CPU Last bedeutet.
Du könntest zum Debuggen Deine RT Appl in Teile zerlegen, die Du per Variable weiterschaltest, um die Lasten der Einzelphasen zu monitoren. Das RT TraceExecToolkit ist auch ok, bei 100% RT Last aber unwirksam.
(Bei der Verwendung von Shared Variablen muss man wissen, dass der RT in Runtime-Konfiguration das der RTExe beigestellte *.aliases File liest, um die zu nutzende SVEngine im Netzwerk zu bestimmen.)
Hope it helps
Christian
Hallo,
fast den gesamten Speicher weise ich zu Beginn zu, bevor ich in die parallelen Schleifen gehe, die eigentlich ununterbrochen laufen (sollen). Alles fest zuzuweisen ist natürlich nicht praktikabel, aber der Speicherbedarf ändert sich im laufenden Programm kaum, es sei denn, man hat mal einen Dateizugriff, doch auch ohne diese ist das Problem vorhanden.
Es geht auch alles einwandfrei, wenn ich über den Pfeilbutton aus LabVIEW starte.
Shared Variables nutze ich keine. Ich habe die Unterstützung dafür auch gar nicht erst installiert.
Die RT-Exe macht irgendwas ganz komisches im Vergleich zum Start aus LabVIEW heraus. Nach ca 2 Minuten kann ich das Programm verwenden, davor leider gar nicht.
Weiß keiner, was das sein könnte?
Wenn es aus LabVIEW heraus nicht ging, wäre klar, dass es am Programm liegt. Aber selbst wenn der Speicher dynamisch zugewiesen werden würde, darf sich die Anwendung im kompilierten Zustand nicht so von der "nicht richtig kompilierten" unterscheiden. Doch wie gesagt, den Speicher weise ich einmalig zu.
Das RT Trace Execution Toolkit ist für eine Aufzeichnungsdauer von 2 Sekunden ok, mehr wird nicht protokolliert, auch wenn ich 10 MB Speicher zuweise. Aber wie gesagt, es kann kein generelles Problem mit dem Programm sein, da es aus LabVIEW heraus läuft.
Hab's grad nochmals getestet:
Das erste, was ich nun im Programm mache ist, die User-LED einzuschalten. Anschließend wird der Rest ausgeführt.
Die LED geht erst nach der Wartezeit von ca. 2 Minuten an. D.h. davor läuft mein Programm noch gar nicht. Gibt's da Netzwerk-Optionen/-Timeouts o.ä. oder was könnte das denn sein?
Die 2 Minuten sehen aus wie die Bootzeit des cRIO + Startzeit deiner Anwendung. Aus der Entwicklungsumgebung greift das natürlich nicht, da dein cRIO dann schon gestartet ist und du entsprechend nur die Startzeit deiner Anwendung hast.
Danke. Auf dieses Ergebnis bin ich mittlerweile auch gekaommen.
In den 2 Minuten werden Betriebssystem gebootet, Treiber geladen etc. Aber 2 Minuten sind verdammt lange, finde ich. Doch das scheint bei den cRIOs normal zu sein.
Leider etwas spät aber noch ein Vorschlag um deine Bootzeit zu verkürzen.
Installier am besten nur die Komponenten die du wirklich brauchst. Mittlerweile (LV 2010) gibt es sehr viele verschiedene Komponenten die man meist nicht alle braucht aber die Bootzeit doch erheblich erhöhen.