AI Advisor

Hallo zusammen,

NI hat ja den AI Advisor in der LV Pro Version mit zur Verfügung gestellt.

Dieser soll ja lt. NI bei der „Beschleunigung Ihrer LabVIEW-Codeentwicklung“ mitwirken und „Nigel ist anders als jeder andere KI-Berater“.

Gibt es hierzu von euch Erfahrung?

Arbeitet jemand damit?

Lohnt es sich damit näher zu beschäftigen?

Was ist euere Meinung hierzu?

Gruß Hubert R.

Anzeige

Hi Hubert,

es ist eben ein AI Advisor und mehr scheint das auch wirklich nicht zu sein. Ich habe mir bisher nur das ein oder andere Video dazu angesehen. Das was dort aus AI Advisor heraus kommt, macht für mich keinerlei verwertbaren Aussagen - eher Zeitverschwendung das auch noch zu lesen. Nein, ich habe an dem AI Advisor in der aktuellen Form null Interesse. Da muss schon sehr viel mehr dabei heraus kommen.

Hallo Hubert,

Zitat:NI hat ja den AI Advisor in der LV Pro Version mit zur Verfügung gestellt.

Ja, aber erst in der/den neuesten LabVIEW-Version(en)!
Und viele Profis arbeiten noch mit älteren Versionen, da wirst du also nicht sofort viel Rückmeldung erhalten.

Laut deinem Profil hast du ja auch noch keinen Zugriff auf Nigel…

Nigel leidet an den gleichen Punkten wie andere GPTs auch: es werden häufig Dinge herbeifantasiert die es nicht gibt. Trotzdem finde ich es durchaus hilfreich.

Bei kleinen Applikationen, die größtenteils in ein VI passen kann man sich gut z.B. eine Readmes erstellen lassen.
Mitunter gibt er einen sinnvollen Ansatz, wenn man irgendwo festhängt.

Auf der GDevCon gab es einen Vortrag zu KIs, bei dem Nigel aber gar nicht erreichbar war und deswegen durchgefallen ist (LabVIEW vs. LLM: A Generational Showdown). Spaßeshalber habe ich die Fragestellung mal mal nachgeholt. Dabei schneidet er recht gut ab.
(Formatierung gibt Nigel als Markdown, muss man etwas mühsam in vbulletin konvertieren oder eine andere KI beauftragen.)

Der Prompt war:

Zitat:"In LabVIEW 2025, I want to create a vi that programmatically opens a project file, finds EXE build specification and allows to see the current build version. Can you help me with this?"

Und das Ergebnis:


Absolutely! You can create a VI in LabVIEW 2025 that programmatically opens a project file, finds EXE build specifications, and reads the current build version. Here’s how you can approach this, using the built-in Application Builder API:

---

Step-by-Step Guide

1. Open the Project File

Use the Project Open method (Invoke Node) to open your .lvproj file.

2. Find EXE Build Specifications

• Use the Get All Descendents method (Invoke Node) on the project root reference.
• Filter descendents by type "EXE" to get all application build specifications.
  

3. Read the Build Version

• For each EXE build specification reference, use the Get Build Specification Version.vi.
• This VI returns the Major, Minor, Fix, and Build version numbers.
  

---

Example Block Diagram

Here’s a high-level block diagram flow:

1. Invoke Node: Project.Open: Opens the project file
2. Property Node: Root: Gets project root reference
3. Invoke Node: Get All Descendents: Finds all EXE build specs
4. For Loop + Get Build Specification Version.vi: Reads version info for each EXE build spec
   

Visual Reference



Block diagram example from NI:

---

Key VIs and Methods

1. Project.Open (Programming » Application Control » Invoke Node): Opens project file
2. Get All Descendents (Programming » Application Control » Invoke Node): Finds build specs
3. Get Build Specification Version.vi (vi.lib » AppBuilder » ab-api-simple): Reads version info
   

• Get Build Specification Version.vi Documentation
• How to Find Build Specs Programmatically
  

---

Common Pitfalls

• Project Reference: Always close the project reference after use to avoid memory leaks.
• Error Handling: Wire error clusters throughout to catch issues (e.g., missing build specs).
• Saving Changes: If you modify build spec versions, you must manually save the project.
  

---

Next Steps

• Do you want to see a sample VI or code snippet for this workflow?
• Are you interested in reading or also updating the build version programmatically?
  

Let me know your preferred workflow, and I’ll help you build it out!

Ich habe immer mal wieder Probleme mit log-Dateien, bei denen ein Eintrag fehlt, nachdem ich den Error 8 herausgefunden habe, habe ich den AI Advisor mal gefragt und das vorhaben verifizieren lassen:

Auf meine Frage: Was kann ich tun, wenn mein write delimited spreadsheet meine Daten ganz selten mal nicht schreibt, weil die Rechte in dem moment fehlen?

Code:

Antwort: Das ist ein klassisches Problem beim Dateizugriff: Wenn Write Delimited Spreadsheet in LabVIEW keine Schreibrechte auf die Datei oder den Ordner hat, schlägt der Schreibvorgang fehl. Das kann sporadisch passieren, z. B. wenn die Datei gerade von einem anderen Prozess gesperrt ist, die Netzwerkverbindung unterbrochen ist, oder die Benutzerrechte temporär entzogen werden.
Hier sind bewährte Strategien, um damit umzugehen:

1. Fehler abfangen und behandeln
Das VI gibt einen Fehlercluster aus. Prüfe nach jedem Schreibvorgang den Fehlerausgang und reagiere darauf:

Fehlercode    Bedeutung    Typische Ursache
7    Datei nicht gefunden    Pfad falsch, Datei gelöscht
8    Keine Berechtigung    Datei/Ordner schreibgeschützt, Rechte fehlen
5    Datei bereits geöffnet    Datei von anderem Prozess gesperrt
2. Retry-Mechanismus implementieren
Wenn ein Fehler auftritt, versuche den Schreibvorgang nach kurzer Wartezeit erneut. Beispiel: 3 Versuche mit je 100 ms Pause.

Versuch 1: Fehler? → 100 ms warten → Versuch 2: Fehler? → 100 ms warten → Versuch 3
3. Fehler protokollieren
Schreibe Fehler in eine Logdatei oder zeige sie im Frontpanel an, damit du später analysieren kannst, wann und warum das Problem auftritt.

4. Rechte vorab prüfen
Nutze das Check File Permissions-VI (oder prüfe mit Open/Create/Replace File im Modus "Test") vor dem Schreiben, um festzustellen, ob du Schreibrechte hast.

5. Alternative Speicherorte nutzen
Wenn der Standardpfad nicht verfügbar ist, schreibe temporär in einen lokalen Ordner und synchronisiere später.

Typische Fehlerquellen vermeiden
Netzlaufwerke: Sind oft unzuverlässig, besonders bei kurzen Unterbrechungen.
Antivirus/Backup-Software: Kann Dateien sperren.
Mehrfachzugriff: Vermeide parallelen Zugriff auf dieselbe Datei.
Beispiel für einen Retry-Mechanismus in LabVIEW
Schritt    Aktion
1    Schreibe Daten mit Write Delimited Spreadsheet
2    Prüfe Fehlerausgang
3    Bei Fehler: Warte 100 ms, versuche erneut (max. 3x)
4    Bei Erfolg: Weiter, bei erneutem Fehler: Loggen und ggf. Benutzer informieren
Frage:
Möchtest du ein Beispiel-VI für den Retry-Mechanismus oder suchst du eine andere Lösung, z. B. automatisches Umschalten auf einen Backup-Pfad?

Den Lösungsansatz hatte ich auch und mich nach meiner Umsetzung erkundigt:
Folge Frage: Ist eine for schleife mit 3 iterationen und einer conditional terminal geeignet?

Code:

Antwort: Ja, eine For-Schleife mit Conditional Terminal ist für einen Retry-Mechanismus in LabVIEW sehr gut geeignet! Damit kannst du den Schreibvorgang bis zu drei Mal versuchen und die Schleife vorzeitig verlassen, sobald das Schreiben erfolgreich war.
Hier sind die Vorteile und typische Umsetzung:

Vorteile
Vorteil    Beschreibung
Einfach    Klarer, kompakter Code ohne komplexe Strukturen
Effizient    Schleife bricht sofort ab, wenn der Schreibvorgang gelingt
Flexibel    Anzahl der Versuche leicht anpassbar
Typische Umsetzung
For-Schleife mit 3 Iterationen.
Conditional Terminal (kleines rotes Quadrat unten rechts): Schleife verlässt, wenn ein Versuch erfolgreich war.
Fehlerausgang von Write Delimited Spreadsheet prüfen.
Wartezeit (z. B. 100 ms) zwischen den Versuchen mit Wait (ms).
Beispiel-Logik
Schritt    Aktion
1    Schreibe Daten
2    Prüfe Fehlerausgang
3    Bei Erfolg: Schleife verlassen (Conditional Terminal)
4    Bei Fehler: Warte 100 ms, nächster Versuch
Typische Fehlerquelle
Vergiss nicht: Das Conditional Terminal muss auf "Continue if True" oder "Stop if True" gesetzt werden, je nach gewünschtem Verhalten.
Fehlercluster richtig auswerten: Prüfe den Fehlercode, nicht nur ob ein Fehler vorliegt.
Tipp:
Du findest die Conditional Terminal-Option, indem du mit Rechtsklick auf die For-Schleife gehst und „Conditional Terminal hinzufügen“ auswählst.

Frage:
Möchtest du ein konkretes Beispiel, wie du das Fehlercluster mit dem Conditional Terminal verbindest? Oder brauchst du Tipps zur Fehlerauswertung?

Ich denke aber, selbst wenn es keine gute Idee ist es so zu machen, wird er es vermutlich trotzdem bestätigen. Die Zusammenfassung an sich klingt aber vernünftig (aber genau das macht ja ein LLM, vernünftig klingen..)

Was schrecklich ist, es gibt keine Möglichkeit ein Gespräch zu speichern.
Auch muss ich mich immer wieder neu einloggen.

MfG Timo

Hi Timo,

ich spekuliere mal:
Hier würdest du als Antwort etwas anderes bekommen: Versuche erst einmal die Ursache herauszufinden. Ist es dein Programm, welches das Problem verursacht. Kommt es von extern und kannst du etwas dagegen tun. Erst wenn dich das alles nicht weiter bringt, dann kannst du durchaus einmal versuchen, ob ein solcher (ziemlich furchtbarer) Workaround weiter hilft.

Ja, es würden hier bestimmt auch konkretere Hinweis dabei sein, wie du der Ursache etwas näher kommen kannst. Anscheinend hat die KI keine Ahnung, wie du mit dem Problem umgehen könntest. Da du selbst eine Lösung vorschlägst, welche in manchen Fällen durchaus sehr sinnvoll sein kann, findest sie das ganz super :-)

Ein netter Spass ist es natürlich.

Hat es dir aber neben dem Spass auch irgend einen Nutzen gebracht?

Guten Morgen Martin,

jein, hier hätte ich mehr Details dazu geschrieben, ich weiß ja, das der Error 8 (Zugriffsrechte fehlen) auftritt, die log Datei wird mit dem Auftrag auf dem Server gespeichert.
Tatsächlicher nutzen würde ich jetzt als minimal einstufen, wäre etwas anderes rausgekommen als ich im Kopf habe, dann hätte ich weiter nachgeforscht, so habe ich mich bestätigt gefühlt und es als ausreichend definiert (für mich).
Ich habe das Ende "weil die Rechte in dem moment fehlen" mal weggelassen und dann folgende Antwort erhalten:

Code:

Wenn dein „Write Delimited Spreadsheet“-VI in LabVIEW gelegentlich Daten nicht schreibt, gibt es mehrere mögliche Ursachen und Lösungsansätze. Das Problem kann sporadisch auftreten, wenn z. B. das Ziel-File gerade von einem anderen Prozess geöffnet ist, ein Race Condition vorliegt, oder die Dateioperation nicht korrekt abgeschlossen wird.
Häufige Ursachen und Lösungen
Ursache    Lösung    Hinweise
Datei ist bereits geöffnet (von LabVIEW oder anderer Software)    Stelle sicher, dass die Datei vor jedem Schreibvorgang geschlossen ist. Verwende das Error-Cluster, um Fehler abzufangen und ggf. einen Retry-Mechanismus zu implementieren.    Siehe Error 5: File already open
Mehrere parallele Schreibzugriffe    Serialisiere die Schreibvorgänge, z. B. mit einer Queue oder einem Mutex.    Parallele Zugriffe können zu inkonsistentem Verhalten führen.
Fehlerhafte Dateipfade oder Zugriffsrechte    Prüfe, ob der Pfad existiert und die Anwendung Schreibrechte hat.    Besonders bei Netzwerkpfaden oder USB-Laufwerken relevant.
Fehler im Datenfluss (Race Condition)    Stelle sicher, dass die Daten wirklich geschrieben werden, bevor das VI beendet wird. Nutze das Error-Cluster, um Fehler zu erkennen.    Race Conditions sind schwer zu finden, daher Debugging-Tools nutzen.
Fehlerhafte oder fehlende Fehlerbehandlung    Implementiere eine robuste Fehlerbehandlung und logge Fehlercodes.    Fehler können im Error-Cluster angezeigt werden.
Datei wird nicht korrekt geschlossen    Verwende „Close File“-VI nach jedem Schreibvorgang.    Offene Handles können zu Problemen führen.
Debugging-Strategien in LabVIEW
Nutze die folgenden Tools, um das Problem einzugrenzen:

Tool    Zweck    Anwendung
Highlight Execution    Zeigt den Datenfluss im Blockdiagramm animiert.    Erkenne, ob der Schreibvorgang wirklich ausgeführt wird.
Probes    Überwache Werte auf den Drähten während der Ausführung.    Prüfe, ob die Daten korrekt zum „Write Delimited Spreadsheet“-VI gelangen.
Error Cluster    Zeigt Fehlerstatus, -code und -quelle.    Logge und analysiere Fehler nach jedem Schreibvorgang.
Breakpoints    Pausiere die Ausführung an kritischen Stellen.    Untersuche, ob und wann das VI den Schreibvorgang ausführt.
Mehr zu Debugging-Techniken findest du hier:

LabVIEW Debugging Techniques
Debugging Techniques - LabVIEW User Manual
Best Practices für File I/O in LabVIEW
Datei immer schließen: Nach jedem Schreibvorgang das „Close File“-VI verwenden.
Fehler abfangen: Das Error-Cluster auswerten und ggf. einen Retry bei Fehlern wie „File already open“ implementieren.
Serialisierung: Bei mehreren parallelen Zugriffen auf dieselbe Datei eine Queue oder einen Mutex verwenden.
Pfad prüfen: Vor dem Schreiben sicherstellen, dass der Pfad existiert und beschreibbar ist.
Logging: Fehler und Statusmeldungen in eine Logdatei schreiben, um sporadische Fehler später nachvollziehen zu können.
Typische Fehlerquellen vermeiden
Datei im Windows Explorer geöffnet lassen
Mehrere Instanzen des VIs, die gleichzeitig schreiben
Fehlende Fehlerbehandlung im Code
Nicht geschlossene Dateihandles
Wenn du möchtest, kann ich dir zeigen, wie du einen Retry-Mechanismus für den Schreibvorgang implementierst oder wie du mit Queues die Zugriffe serialisierst. Sag mir einfach, wie dein aktueller File-I/O-Workflow aussieht!

Frage zurück: Tritt das Problem bei bestimmten Dateinamen, Pfaden oder unter bestimmten Bedingungen auf? Bekommst du einen spezifischen Fehlercode im Error-Cluster?

Finde ich (als doch immer noch eher Anfänger) jetzt ganz ok, von hier auch anwesenden Full-Time-Job Entwickler wahrscheinlich eher belächelt, wenn nicht sogar als nutzlos betrachtet..

grüße Timo