Hallo Twobobbels,
du greifst doch nicht etwa von deinem Windows-Host aus direkt auf den FPGA deines cRIO9074 zu?
Sowas sollte man nicht machen…
Jedes Beispiel-Projekt, das mit LabVIEW mitgeliefert wird, zeigt folgendes:
- Es gibt ein FPGA-VI, dass auf die im cRIO verbaute Hardware zugreift
- Es gibt ein RT-VI, welches auf dem cRIO läuft. Dieses kommuniziert mit dem FPGA-VI über die bekannten Methoden.
- Es gibt ein Windows-/PC-Host-VI, welches ein UI darstellen kann. Dieses kommuniziert über Netzwerk-Schnittstellen mit dem RT-VI.
Dummerweise hast du den mittleren Punkt weggelassen - und darfst dich deshalb nicht wundern, dass Netzwerkprobleme zu Fehlverhalten führen!
Einfache Lösung: Das oben genannte Projekt-Schema einhalten!
Einfache Lösung 2: Im FPGA einen Watchdog programmieren, der das System in einen sicheren Zustand schaltet, wenn sich der Windows-Host nicht (mehr) meldet!
Zum Windows-VI:
- Viel zu viele lokale Variablen!
- Es fehlt eine vernünftige Programmstruktur!
- Ein VI, welches mit der STOP-Funktion beendet wird, ist (IMHO) grundsätzlich "schlecht". Entweder beendet man ein Executable mit EXIT (nach dem Runterfahren aller wichtigen Prozesse) - oder das Programm beendet alle Schleifen regulär über irgendwelche Stop-Bedingungen: wozu also ein hartes "STOP",
bevor irgendwelche Schleifen korrekt beendet wurden?
- Wozu eine Event-Struktur mit einem TimeOut von 10ms, wenn im TimeOut NICHTS passiert?
- LabVIEW bringt ein VI zum Umrechnen von Pt100-R nach Temperatur mit, sowas muss man nicht selbst programmieren…
- Es gibt "+1" und "-1"-Funktionen…
- Es gibt Funktionen zum Berechnen von Polynomen. Deine Methode mit diversen "X^Y"-Aufrufen und CoercionDots ist hochgradig Rube-Goldberg:
- Wenn du beim Formatieren von Zahlen ein Komma (statt des schönen Punktes) als Dezimaltrennzeichen haben willst, musst du nur den passenden Formatcode verwenden…
