LabVIEWForum.de

(25.11.2024 12:05 )GerdW schrieb: [ -> ]Die ScanEngine war für mich aber immer sehr limitierend, selbst bei einfachen DIOs. Deshalb habe ich auch DIO gern im FPGA erledigt, vor allem, wenn ich anderes dort sowieso erledige.

Naja.
Wie sag ich immer: Erfahrungen von Anwendern sind in jedem Fall den Versprechungen der Hersteller und der Gerätebeschreibung vorzuziehen.

Zitat:Definiere "in Echtzeit übertragen"! Du hast Netzwerk-Kommunikation zwischen cRIO und PC, da wirst du (sehr wahrscheinlich) keinerlei "Echtzeit"-Spezifikationen haben…

Für NSV gibt es FiFo-Eigenschaften. Die sind erstmal ausreichend. Im gegebenen Fall wäre "Echtzeit" in ca. 100ms ausreichend. Der PC dient nur als Anzeige und zum Datenspeichern. Es soll halt bei der Anzeige nichts hakeln ...

Das mit dem FiFo im NSV funktioniert (bisher) zu meiner Zufriedenheit. Auch mit der Laufzeit der NSV (unter LV2024!!) hab ich kein Problem: Hin und wieder zurück: 50ms (eigene Debugger-Funktionen).

[/quote]Und ja, man kann auch 48kHz-Signale vom FPGA zum RT per FIFO übertragen und von dort dann zum PC. Aber dafür würde ich bei den aktuellen cRIOs eben DAQmx verwenden.[/quote].Klar. Und um den Umweg zu vermeiden eben DAQmx auf RT.

Zitat:NSVs sind verhältnismäßig langsam.

Ich sag mal "Applikationsabhängig"

Zitat:Das Deploy kann hakelig sein.

Sehr, sehr, sehr hakelig - auch unter LV2024. Bis hin zu Fehler irgendwas mit 608 am Ende: "NSV unbekannt". Ging relativ schnell, bis ich das mit dem Hekelig festgestellt habe: LV2024 und cRIO neu starten, gut ist.

Zitat:NetworkStreams sollten "angenehmer" sein.

Das ist doch mal ein Schlagwort.

Zitat:Oder auch einfaches "eigenes" TCP oder UDP…

Das glaub ich, dass das Selbstgemachte funktioniert - aber: Aus dem Alter, als ich noch alles selber gemacht habe, bin ich heraus.

Bisherige Erfolge:

Nachdem die LabVIEW-IDE plötzlich sinngemäß was von "SSH ungenügend" behauptet hat und die auf dem cRIO installierte SW im MAX nicht mehr anzeigbar war, was für mich nicht nachvollziehbar ist, haben wir uns zusammen mit dem Service-Personal von NI für eine Neuinstallation der SW auf cRIO einschließlich "Laufwerk formatieren" entschieden. Während der Installation sind auch Updates(?) vom NI-Server geladen worden.

Nach der Neuinstallation hat alles nach meinen Wünschen funktioniert: Das Starten von Tasks mit dem DAQmx funktioniert jetzt ohne Fehler.

Was bleibt ist aber das hakelige Deploy besonders der Variablen, die über die Scan-Engine bearbeitet werden (DIOs). Klappt das nicht, erscheint der Fehler -66208, der durch Spannungsreset am cRIO und Neustart LabVIEW-IDE am schnellsten zu lösen geht.

Weitere Erkenntnis:

(26.11.2024 14:34 )IchSelbst schrieb: [ -> ]Was bleibt ist aber das hakelige Deploy besonders der Variablen, die über die Scan-Engine bearbeitet werden (DIOs). Klappt das nicht, erscheint der Fehler -66208, der durch Spannungsreset am cRIO und Neustart LabVIEW-IDE am schnellsten zu lösen geht.

Beim Auftreten des Fehlers -66208 gebe ich folgenden Rat: Wenn die Möglichkeit besteht, soll das Scan Interface durch DAQmx ersetzt werden. Solange der Fehler anscheinend undefiniert auftritt und weder automatisch noch intuitiv zu beheben geht (leider nützt die Methode aus dem Zitat auch nicht immer, wäre intuitiv) ist dieses System wenig brauchbar. - Zumal selbst die IDE (LV2024Q4) regelmäßig abstürzt: Nicht nur mit der freundlichem Meldung "tut uns leid (sprich: wir können auch nichts dazu)", sondern auch komplett alle Fenster ohne Vorwarnung zu.

Alles nur halbe Sachen:
Eine kurze Zeitlang hat es funktioniert. Nachdem wir EtherCAT nachinstalliert haben, ging der ganze Mist wieder von vorne los. Wieder Fehler -66208. Diesmal auch im MAX. Nicht beim Ablauf der Task, sondern bei der Funktion Selbstkalibrierung. Diesmal ging aber alles schneller: User-Rechte erweitert, LV (2024Q3) am PC deinstalliert und neu installiert. cRIO formatiert und neu installiert. Alles als Administrator. Verarbeitung der 6 Module am cRIO eingestellt (4xDAQmx, 2xScan). Tasks erstellt. Alles läuft. Zu meiner Zufriedenheit.

Hinweise:

• PC-App und cRIO-App befinden sich in einer Projektdatei.
• Die Netzwerkvariablen befinden sich in einer Lib unter der PC-App (also nicht unter der cRIO-App)
• Folgender, bisher unkritische Fehler tritt auf: Es ist nicht möglich, eine im MAX erstellte Task in LV in ein VI umzuwandeln. Das entstandene VI ist leer ...
  

Allerdings:
Das Projektfile (eigentlich die PC-App), das bisher sowohl auf dem Prüfstandrechner, der das cRIO enthält, wie auch auf meinen Laptop im Homeoffice, das natürlich kein cRIO enthält, funktioniert hat, funktioniert plötzlich nicht mehr. Das allerdings war ganz einfach: Rechner IP von DCHP auf IP des Prüfstandrechners umgestellt. Und es geht wieder.

Jetzt muss ich mich aber fragen:
Warum hat dasselbe Projekt vorher grundsätzlich auf dem Prüfstandrechner und meinem Laptop funktioniert, wo doch die IPs unterschiedliche waren. Laptop ohne cRIO und Prüfstand mit cRIO sagten vorher und sagen jetzt wieder, dass die Verteilung (u.a. der Netzwerkvariablen) funktioniert hat. Das PC-Programm ist also auf dem Prüfstandrechner und dem Laptop lauffähig.

Zwischenrein hab ich gegoogelt und diverse Hinweise (aber keine Lösungsvorschläge oder gar Lösungen) mit "Web-Server" und "TSN auf dem cRIO" gefunden. Also alles Funktionen, hinter denen IP-Adressen stehen ...

Vermuteter Ursprung des Problems:
Ich vermute, dass der Fehler passiert ist, weil ich die Library mit den Netzwerkvariablen von der cRIO-App in die PC-App geschoben habe - und zwar auf dem Laptop. Dadurch haben die Netzwerkvariablen die von DCHP ermittelte IP-Adresse erhalten und die PC-App hat auf meinem Laptop funktioniert. Dann hab ich das Projekt samt Projektfile auf den Prüfstandrechner kopiert: Die beiden Programme PC und cRIO waren lauffähig, nur dieser Fehler -66208 war halt da. Verteilen von Allem war OK - obwohl doch offensichtlich die IPs verschieden waren.

Erkenntnis:
Netzwerkvariablen in Library behutsam handhaben - spricht: Nicht mit IP-Adressen spielen. LV ist da wie ein kleines Kind: heulen, aber nicht sagen warum. Hoffen wir mal, dass jetzt alles funktionierend bleibt, zumal ja immer noch keiner weiß, warum es zu dem Fehler -66208 gekommen ist.