Universalanwendung zur Messdatenerfassung und Sicherheitsabschaltung.

Hallo liebe LabVIEW Community,

ich habe ein Problem mit meinem Projekt.

Mein Projekt soll eine Universal-Anwendung zur variablen Messdatenerfassung mit Integrierter Sicherheitsabschaltung für DAQ Geräte sein.

Sie funktioniert so Eigendlich, nur das nach einer Zeit der RAM immer voller wird und die CPU Auslastung teilweise auf 100% Steigt.

Bitte nicht Kritisieren, ich habe mir LabVIEW selber bei gebracht.
Bitte nur Empfehlungen wie ich etwas verbessern kann, damit es Stabil läuft.
Projekt kann auch gerne weiter verwendet werden, nur über Hilfe wäre ich sehr Dankbar.

Das Projekt wurde mit LabVIEW 2012 erstellt.

Ich nutze im Projekt 3 State Maschines, 1 zum Lesen, 1 zum Werte in TDMS-Datei schreiben, und eine zur Abschaltung.
Wer sie Testet, es wird im root Verzeichnis ein Ordner erstellt.

Kleine Anleitung

1. Task auswählen
2. Dateinamen vergeben / Menge der Sec/Min auswählen
3. Digitalen Abschalt-Kanal auswählen / Min/Max Werte eintragen.

Eigene Task-leiste unten.
Dann über ersten Button (Pfeil nach unten) zum Signalverlauf wechseln.
Über Play Button, wird die Erfassung gestartet.
Über Rec Button, wird Messdaten-Aufzeichnung gestartet.
Und über den Close Button, wird die Abschaltung Aktiviert.
+ Button = Einblenden der Plotleiste im Signalverlaufsdiagramm
Ordner mit Blatt = Ordnerpfad c:/Messungen öffnen


  v01 alpha.zip (Größe: 2,48 MB / Downloads: 468)

---

Wer kein DAQ Gerät besitzt, kann auch eins Simulieren.

Hallo samael,

Zitat:Bitte nur Empfehlungen wie ich etwas verbessern kann, damit es Stabil läuft.

- Im "TDMS Write" gibt es eine Case-Struktur, die nach den Speicherintervallen unterscheidet. Warum gibt es drei State (10 pps, 100pps, 1000pps), die sich nur um eine einzige Konstante unterscheiden? Sowas kann man in einem Case erledigen… (Code nicht duplizieren)
- Warum fehlen bei etlichen Controls/Indicators/PropertyNodes im Blockdiagram das Label? (wenig übersichtlich)
- Muss man die diversen PropertyNodes wirklich in jeder Iteration erneut setzen? Kann man da keine Eventstruktur verwenden? (Architekturproblem)
- Lokale Variablen führen gern zu Datenkopien. Datenkopien von großen Datenmengen ("Signalverlaufsdiagramm") führen schnell zu Speichermangel. Mehrere Datenkopien derselben großen Datenmenge führen noch schneller zu Speicherproblemen. (THINK DATAFLOW!, außerdem schlechte Übersichtlichkeit wegen unspezifischer Label)
- Benötigt man wirklich eine Case-Struktur mit 21 Cases, um eine Plotlegende zu bearbeiten? (viele PropertyNodes, die in jeder Iteration gesetzt werden. Architekturproblem)
- Muss man eben diese Case-Struktur auch noch doppelt im Code verwenden? Einmal in der Messschleife und einmal in der Event-Schleife? (duplizierter Code, Architekturproblem)
- Insgesamt zu viele lokale Variablen: THINK DATAFLOW!
- Mehrere Controls mit identischem Label: das geht ja gar nicht!
- Muss die Trigger-Loop so schnell wie es geht iterieren und damit nur unnötig CPU-Leistung in Wärme umsetzen??? (Architekturproblem)
- Desöfteren unnötige Sequenzstrukturen: THINK DATAFLOW!
- Muss man das alles mit nur einem einzigen subVI erledigen??? (Architekturproblem)

Das sind so die "groben" Sachen, die mir auf die Schnelle aufgefallen sind…

(20.06.2018 15:02 )GerdW schrieb:  Hallo samael,

Zitat:Bitte nur Empfehlungen wie ich etwas verbessern kann, damit es Stabil läuft.

- Im "TDMS Write" gibt es eine Case-Struktur, die nach den Speicherintervallen unterscheidet. Warum gibt es drei State (10 pps, 100pps, 1000pps), die sich nur um eine einzige Konstante unterscheiden? Sowas kann man in einem Case erledigen… (Code nicht duplizieren)
- Warum fehlen bei etlichen Controls/Indicators/PropertyNodes im Blockdiagram das Label? (wenig übersichtlich)
- Muss man die diversen PropertyNodes wirklich in jeder Iteration erneut setzen? Kann man da keine Eventstruktur verwenden? (Architekturproblem)
- Lokale Variablen führen gern zu Datenkopien. Datenkopien von großen Datenmengen ("Signalverlaufsdiagramm") führen schnell zu Speichermangel. Mehrere Datenkopien derselben großen Datenmenge führen noch schneller zu Speicherproblemen. (THINK DATAFLOW!, außerdem schlechte Übersichtlichkeit wegen unspezifischer Label)
- Benötigt man wirklich eine Case-Struktur mit 21 Cases, um eine Plotlegende zu bearbeiten? (viele PropertyNodes, die in jeder Iteration gesetzt werden. Architekturproblem)
- Muss man eben diese Case-Struktur auch noch doppelt im Code verwenden? Einmal in der Messschleife und einmal in der Event-Schleife? (duplizierter Code, Architekturproblem)
- Insgesamt zu viele lokale Variablen: THINK DATAFLOW!
- Mehrere Controls mit identischem Label: das geht ja gar nicht!
- Muss die Trigger-Loop so schnell wie es geht iterieren und damit nur unnötig CPU-Leistung in Wärme umsetzen??? (Architekturproblem)
- Desöfteren unnötige Sequenzstrukturen: THINK DATAFLOW!
- Muss man das alles mit nur einem einzigen subVI erledigen??? (Architekturproblem)

Das sind so die "groben" Sachen, die mir auf die Schnelle aufgefallen sind…

Das sind n Menge Probleme.
Also Heißt es aufräumen, umstrukturieren, umbenennen.
Das Wird ein bisschen Dauern, ich melde mich später wieder mit einer neuen Version.

Danke für die Information.