(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.
