Verbindung zu cRio richtig starten und beenden

Hallo Zusammen,
Ich habe ein wenig im Forum herumgesucht aber nichts gefunden. Ich habe ein Crio9024 mit verschiedenen Modulen und habe in einem Projekt ein VI geöffnet, das momentan nur Werte eines Temperaturmodules( 9013) über shared variables einliest. Wenn ich das VI starte und beende bekomme ich eine Fehlermeldung: Communication Error Occured. Und dann Warning: Connection to the RT target has failed. Wenn ich im Projekt connect oder deploy wähle startet das VI trotzdem immer erst wenn einmal diese Fehlermeldungen erschienen sind. Genauso beim Beenden. Ich vermute, dass ich im Blockdiagramm mit einem anderen VI starten muss. Hab aber nichts passendes gefunden, wobei ich vorallem unter RT Utilities gesucht habe...
Ich wäre euch sehr dankbar wenn jemand etwas weiß

Vielen Dank vorab

Ich benutze LV 2009 auf einem PPC 2115 von NI

Anzeige

Dann bitte .
Leider kenne ich mich mit dem cRIO nicht aus.

Gruß Markus

' schrieb:Ich benutze LV 2009

Hallo,
ok ich hoffe das mit dem Profil passt jetzt so?! Schade, hab es leider immer noch nicht herausgefunden. Ich habe es mal mit einem Methodenknoten versucht dort konnte ich Project open auswählen. Allerdings gab es diese Option nicht für close Project
Bin für jede Hilfe dankbar

Hallo,

die Real-Time-Programme können auf 2 Arten laufen: Direkt aus LabVIEW heraus gestartet oder eigenständig nach dem Einschalten des cRIO. Für letzteres ist eine Real-Time-Exe zu erstellen (Rechtsklick auf "Build specifications" im Projekt-Explorer.

' schrieb:Wenn ich das VI starte und beende bekomme ich eine Fehlermeldung: Communication Error Occured. Und dann Warning: Connection to the RT target has failed.

FÜr beide gilt jedoch, dass die CPU nicht dauerhaft zu 100% ausgelastet sein sollte, sonst bleiben keine Ressourcen, um die Netzwerkverbindung aufrecht zu erhalten. Das ist z.B. bei einer ungebremsten While-Schlife gerne der Fall (kurze Verzögerungszeit einfügen). Und dann erhältst du diese Meldung. Natürlich gibt es auch andere mögliche Gründe.

Nutzt du das integrierte FPGA und beendest das nicht korrekt?
Versuchst du große Datenmengen in eine Datei zu schreiben?

Hilfreich wäre, den relevanten Teil des Blockdiagramms zu sehen, sonst muss ich raten.

Hallo,

wir hatten bei uns eine cRio9022 bei der trat so ein Fehler auch auf, es lag bei unserem Fall an der Netzwerkverbindung - wir hatten sie bei uns im Netz einfach mit hinein gehangen, was eigentlich keine Probleme verursachen sollte, die Lösung für uns war dann ein Crosskabel, also eine direkt Verbindung.

Gruß snuz

P.S. es ging um eine Strecke von ca. 15m

Hallo zusammen,
vielen Dank für die Antworten
@snuz
Danke aber ich benutze schon ein Crossoverkabel, der Computer hängt gar nicht am Netz...dann kann es daran wohl nicht liegen?!
@Mechatronik Ingenieur
Erst mal danke, ich benutze kein FPGA, ob das große Datenmengen sind weiß ich nicht so recht, was ist groß? Ich möchte über LABVIEW starten, und habe die Variablen einfach in das VI gezogen. Im Anhang sieht man einen Ausschnitt.Das ganze läuft in einer Timed Loop ab, dazu habe ich im Forum gelesen, das das für die CPU-Auslastung kein Problem sein dürfte oder??
Das Vi wird allerdings nicht initialisiert oder so...Ich habe festgestellt: wenn ich das laufende VI nicht mit dem roten Stopp Button beende sondern im Project unter dem Controller auf disconnect gehe, startet er mir beim nächsten Mal sofort auf Anhieb. Nur beim Beenden kommt wieder die Fehlermeldung. Da ich das ganze über das VI steuern möchte bin ich immer noch einwenig ratlos...
Vielen Dank für die Hilfe
Liebe Grüße

Hallo,

naja, man erkennt nicht wirklich was.
Die großen Datenmengen bezogen sich nur aufs Speichern in Dateien. Wenn du damit herum rechnest, ist das kein Problem.
Die Timed-Loop ist ebenfalls in Ordnung, sofern der Code innerhalb der Schleife nicht länger zur Ausführung braucht als die Periodendauer der Schleife (auch hier gibt es Ausnahmen).

Im Endeffekt funktioniert das Ganze so wie auch unter Windows.
Verlässt du die Hauptschleife(n), wird das VI beendet.

Der rote, runde Abbruch-Button sollte nur verwendet werden, wenn es anders nicht geht. Er bricht die Ausführung knallhart ab und es können undefinierte Zustände auftreten.

Hi,
ich habe versucht das VI mit screenshots zusammenzubasteln... leider sehr schlecht gelungen...*sorry*
Mal abgesehen vom Problem, des Starten und Beenden, habe ich nun auch das Problem der CPU Auslastung. Seit ich eine Schleife in die Timed Loop eingefügt habe, verliere ich die Verbindung auch während des ausführens zum Controller. Eine Wartezeit habe ich der for-schleife zugewiesen. Allerdings kann ichdie timed loop nicht noch langsamer laufen lassen, sie ist derzeit synchronisiert mit der Scan Engine mit 1Scan per Periode.? Weiß jemand wo der Fehler liegt?

' schrieb:Hi,
ich habe versucht das VI mit screenshots zusammenzubasteln... leider sehr schlecht gelungen...*sorry*
Mal abgesehen vom Problem, des Starten und Beenden, habe ich nun auch das Problem der CPU Auslastung. Seit ich eine Schleife in die Timed Loop eingefügt habe, verliere ich die Verbindung auch während des ausführens zum Controller. Eine Wartezeit habe ich der for-schleife zugewiesen. Allerdings kann ichdie timed loop nicht noch langsamer laufen lassen, sie ist derzeit synchronisiert mit der Scan Engine mit 1Scan per Periode.? Weiß jemand wo der Fehler liegt?

Kannst das VI nicht hinaufladen, wäre sicher besser...

Ein Blockdiagramm in ein Word-Dokument verpackt sehe ich jetzt zum ersten Mal. Wie erwähnt: Sinnvoll ist das nicht, aber besser als gar nichts.

Feher 1:
Fatal sind Wartefunktionen in einer mit der Scan-Engine synchronisierten Schleife. Das kann nicht synchron laufen, wenn du in der Schleife plötzlich wartest. Solche VIs müssen aus der zeitkritischen Schleife raus.
Es hängt natürlich auch etwas von der eingestellten Abtastrate ab. Wie hoch ist diese denn bei dir?
In der For-Schleife warttest du knapp 320 ms. Erfasst du die Daten schneller als 3 Hz, kann alleine das schon gar nicht gehen.

Fehler 2:
Wieso nutzt du Frontpanel-Elemente wie ein Tab-Control oder einen XY-Graph?
Die verlangsamen u.U. einiges und eine Real-Time-Anwendung hat im Idealfall kein Frontpanel. In einer schnellen zeitkritischen Schleife hat eine Visualisierung eh nichts verloren (eigentlich in gar keiner zeitkritischen Schleife).
Die Visualisierung sollte, wenn möglich, über eine Host-Anwendung erfolgen, die z.B. auf einem Windows-PC ausgeführt wird. Über Shared Variables o.ä. kannst du dann Daten per Ethernet austauschen und in der Host-Anwendung darstellen. Echtzeitfähig ist die dargestellte Visuslisierung sowieso nie.

Fehler 3:
Du machst in der zeitkritischen Schleife sehr viel. Ist der Code langsamer als die Erfassungsrate der Scan-Engine, gerät die zeitgesteuerte Schleife in eine Art Timeout und alles ist nicht mehr synchron.
Gehe lieber her und nutze die zeitkritische Schleife für die Erfassung und bereite die Daten in einer parallelen Schleife auf. Diese muss auch nicht zeitkritisch sein. Die Daten könntest du per RT-FIFOs austauschen und in der parellelen Schleife immer 50 Werte auf einmal auslesen (ggf. mehrere RT-FIFOs nutzen, je nach dem). D.h. diese läuft langsamer und hat dann genug Zeit, die Werte blockweise zu verarbeiten.