INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Universalanwendung zur Messdatenerfassung und Sicherheitsabschaltung.



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

20.06.2018, 14:12 (Dieser Beitrag wurde zuletzt bearbeitet: 20.06.2018 14:21 von erzengelsamael.)
Beitrag #1

erzengelsamael Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 88
Registriert seit: Aug 2012

12.0f3
2012
DE


Deutschland
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


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


Wer kein DAQ Gerät besitzt, kann auch eins Simulieren.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
20.06.2018, 15:02 (Dieser Beitrag wurde zuletzt bearbeitet: 20.06.2018 15:18 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 15.726
Registriert seit: May 2009

09SP1, 11SP1, 17 (18)
1995
DE_EN

10×××
Deutschland
RE: Universalanwendung zur Messdatenerfassung und Sicherheitsabschaltung.
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? Hmm (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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.06.2018, 17:50 (Dieser Beitrag wurde zuletzt bearbeitet: 20.06.2018 17:53 von erzengelsamael.)
Beitrag #3

erzengelsamael Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 88
Registriert seit: Aug 2012

12.0f3
2012
DE


Deutschland
RE: Universalanwendung zur Messdatenerfassung und Sicherheitsabschaltung.
(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? Hmm (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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Gehe zu: