Datenerfassung und - verarbeitung an einem Ventilatorenprüfstand

Hallo Gerd,

ich habe jetzt verstanden wie du das mit den seriellen Abfragen gemeint hast.
Ich habe eine 2013er-Version angehängt, da die als 2014er abgespeicherte Datei leider eine 2015er-Version bleibt.
Diese Version enthält auch keine versteckten Drähte mehr.

Danke für deine Geduld

Hallo lu,

den ganzen Messteil würde ich jetzt in ein eigenes VI packen und evtl. noch mit einer Statemachine versehen, die auf Befehle hört. So kann man die Messung eben starten, Messwerte lesen lassen und die Messung beenden (oder auf Fehler reagieren). Die Messwerte dann ein einem (typdefinierten) Cluster packen und per Queue oder Notifier für andere Routinen bereitstellen.

Deine "anderen Routinen" sind dann die Datenauswertung und -präsentation. Da würde ich erstmal mit einer einfache Case-Struktur in einer Schleife anfangen, über die die einzelnen "Versuche" ausgewählt werden: jeder Versuch hat seine eigene Auswertung.
"Messgrößen" sehe ich nur als Parameter für die jeweilige Auswertung, ebenso wie "Spannung".

Guten Tag Gerd,

ich konnte in den letzten Tagen meinen Versuchsstand fertig aufbauen und mir ein genaues Konzept für meine Versuche überlegen.
Im Zuge dessen habe ich dank deiner Tipps auch etwas an der Programmierung weitergearbeitet.

Kurz nochmal etwas zum Versuch allgemein:

Es werden grundsätzlich 2 Versuchstypen an der Anlage gefahren:

1. Das Verändern der Versorgungsspannung der Ventilatoren (12V bis 6V in 1 Volt Schritten)
2. Das Verändern der Drosselklappenstellung (100% bis 40% in 10% Schritten)

Diese beiden Versuchstypen werden jeweils für 4 unterschiedliche in die Anlage einsetzbare Ventilatoren durchgeführt.
Die Messungen, Umformungen, Mittelwertbildungen und Berechnungen sollten somit für beide Versuchstypen vom selben VI durchgeführt werden können. Von diesen 2 mal 28 Messreihen benötige ich im Anschluss die aus der Berechnung übergebenen Werte für jede der Messreihen für die Erstellung der Diagramme. Ich habe das grundsätzliche Schema zum Verständnis in einem Bild, das ich angehängt habe, dargestellt. Im Optimalfall habe ich mir das so vorgestellt, dass man eine Messreihe durchführt, die gewonnenen Daten unter bestimmten Namen zwischenspeichert, Klappenstellung oder Spannung verändert, und dann per Bestätigung eine neue Messreihe durchführt, die dann auch wieder zwischengespeichert (bzw. einfach nicht überschrieben) wird. Das geschieht bis man nach 7 Messreihen den Ventilator wechselt und beginnt dann von Neuem.
Wie Umsetzung im BD, auch in Hinsicht auf ein Hauptprogramm, dass den Versuch steuert, bereitet mir leider doch große Schwierigkeiten.

Zitat:den ganzen Messteil würde ich jetzt in ein eigenes VI packen und evtl. noch mit einer Statemachine versehen, die auf Befehle hört. So kann man die Messung eben starten, Messwerte lesen lassen und die Messung beenden (oder auf Fehler reagieren). Die Messwerte dann ein einem (typdefinierten) Cluster packen und per Queue oder Notifier für andere Routinen bereitstellen.

Ich habe mir eine Art Statemachine (Hauptprogramm) erstellt, über die sich die Versuche steuern lassen sollen. Für den Messteil habe ich das VI "Messung_Berechnung" vorgesehen. Dabei habe ich das Problem dass ich nicht verstehe wie genau die Übergabe über eine Queue funktionieren soll.
Für die Statemachine habe ich auch noch eine Verbraucherschleife erzeugt. Allerdings bin ich sehr unschlüssig wie ich die Programmteile zu einem sinnvollen Programm verschalte.

Zitat:Deine "anderen Routinen" sind dann die Datenauswertung und -präsentation. Da würde ich erstmal mit einer einfache Case-Struktur in einer Schleife anfangen, über die die einzelnen "Versuche" ausgewählt werden: jeder Versuch hat seine eigene Auswertung.

Auch hier bin ich mir nicht sicher, wie ich das in das Hauptprogramm einbinden soll.

Ich hoffe, du findest die Zeit dir das ganze nochmal anzuschauen. Vielen Dank für deine bisherigen Tipps.

Guten Tag zusammen,

leider habe ich immernoch Probleme bei der Umsetzung meines LV-Programms. Mein letzter Post war wohl etwas verwirrend und nicht gut durchdacht.
Ich konnte die Programmierung heute erstmals am Versuchsstand testen, jedoch gibt es ein paar Probleme.

Ich habe für jeden Versuch einen eigenen Case, in denen dann jeweils eine Art Zustandsautomat den Versuch steuert. Grundsätzlich soll auf dem FP nach Durchführung der Offset-Messung ein Versuch ausgewählt werden. Anschließend werden in der jeweiligen Registerkarte die benötigten Einstellungen und eine Speicherdatei ausgewählt. Die Auswertung meiner Messdaten habe ich nach Excel verlagert, indem ich eine Tabelle mit meinen Daten, dort an definierte Tabellenplätze exportiere. Die Messung kann dann über das FP unter "Einstellungen" oder "Diagramme Live" gestartet werden.
Das habe ich über eine Eventstruktur gelöst, die bei einer Wertänderung in den Messen und Berechnungsteil meines Programms führt. Dort werden die Werte in eine Tabelle geschrieben und nach Excel übertragen. Danach kehrt das Programm wieder in den "Warten"-Modus zurück.

Nun zu den Problemen:

1. Wenn ich das VI starte und eine Messung durchführe, kann ich nach Abschluss dieser Messung keine weitere durchführen lassen, da der Schieber wie eingefroren ist
Eigentlich sollte das Programm doch bei erneuter Wertänderung wieder in den Messen und Berechnungsteil gehen, oder?

2. In der ersten Zeile meiner Messdatentabelle erhalte ich überall den Wert 0 und erst in der zweiten Zeile werden meine Werte eingetragen.
Wie könnte ich diesen Fehler beseitigen? Nach Abschluss der ersten Messung werden Änderungen vorgenommen und anschließend eine zweite Messreihe gestartet. Diese soll dann in die zweite Zeile der Tabelle eingetragen werden.

3. eine sinnvolle Abbruch-Struktur fehlt mir leider auch noch. Damit habe ich mich allerdings noch nicht beschäftigt, nur damit Ihr euch nicht wundert.


Ich bin für jede Hilfe und jeden Denkanstoß dankbar. Im Anhang sind meine VI`s zu finden.

Mit freundlichen Grüßen,
Lucas

Ein paar allgemeine Kritikpunkte:
- Mehrere Event-Strukturen innerhalb eines VIs führt meist zu Problemen. Besser wäre es, du verwendest nur eine.
- Bitte NIE das Label eines Controls entfernen. Wenn du es nicht auf dem Frontpanel brauchst, dann mach es da unsichtbar (Rechtsklick -> Visible -> Label), aber nicht auf leeren String abändern.
- Was erhoffst du dir davon, parallel einen Indicator und eine lokale Variable des Indicators zu schreiben?

(24.01.2017 13:14 )schneiderlu52048 schrieb:  Nun zu den Problemen:

1. Wenn ich das VI starte und eine Messung durchführe, kann ich nach Abschluss dieser Messung keine weitere durchführen lassen, da der Schieber wie eingefroren ist
Eigentlich sollte das Programm doch bei erneuter Wertänderung wieder in den Messen und Berechnungsteil gehen, oder?

Welcher Schieber?

(24.01.2017 13:14 )schneiderlu52048 schrieb:  2. In der ersten Zeile meiner Messdatentabelle erhalte ich überall den Wert 0 und erst in der zweiten Zeile werden meine Werte eingetragen.
Wie könnte ich diesen Fehler beseitigen? Nach Abschluss der ersten Messung werden Änderungen vorgenommen und anschließend eine zweite Messreihe gestartet. Diese soll dann in die zweite Zeile der Tabelle eingetragen werden.

Think Dataflow: Du hast das Schreiben der Tabelle nach jedem Schritt deiner State-Machine eingefügt. Dummerweise übergibst du Warten-Case keine Werte bzw. genauer den Default-Wert von Numerics an dieses VI. Der Default Wert eines Numeric ist 0

(24.01.2017 13:14 )schneiderlu52048 schrieb:  3. eine sinnvolle Abbruch-Struktur fehlt mir leider auch noch. Damit habe ich mich allerdings noch nicht beschäftigt, nur damit Ihr euch nicht wundert.

So wird es auf jeden Fall nicht funktionieren.

Gruß, Jens

Hallo Jens,

vielen Dank für deine Tipps.

Zitat:Mehrere Event-Strukturen innerhalb eines VIs führt meist zu Problemen. Besser wäre es, du verwendest nur eine.

Habe ich in diesem Forum schon des Öfteren gelesen. Allerdings fällt mir keine Alternative dazu ein. Theoretisch könnte ich für jeden Versuch ein eigenes VI erstellen.

Zitat:Bitte NIE das Label eines Controls entfernen. Wenn du es nicht auf dem Frontpanel brauchst, dann mach es da unsichtbar (Rechtsklick -> Visible -> Label), aber nicht auf leeren String abändern.

Da hast du vollkommen Recht, werde ich ändern!

Zitat:Was erhoffst du dir davon, parallel einen Indicator und eine lokale Variable des Indicators zu schreiben?

Da hast du natürlich auch Recht. Ist beim Implementieren der Offsetmessung entstanden und ich habe vergessen es abzuändern.

Zitat:Welcher Schieber?

Damit meine ich den Button mit dem ich die Messung starte. Dieser lässt sich nicht mehr bedienen, wenn eine Messung durchgeführt wurde. Hat das einen bestimmten Grund? Wie könnte man das anders lösen, wenn das so nicht funktioniert?

Zitat:Think Dataflow: Du hast das Schreiben der Tabelle nach jedem Schritt deiner State-Machine eingefügt. Dummerweise übergibst du Warten-Case keine Werte bzw. genauer den Default-Wert von Numerics an dieses VI. Der Default Wert eines Numeric ist 0

Das war mir so nicht bewusst. Das heisst ich ziehe das schreiben der Tabelle und den Export nach Excel in meinen Messung- und Berechnungsteil hinein, wodurch die erste Messung auch in die erste Zeile gelangt.

Gruß,
Lucas

Anzeige

(24.01.2017 14:50 )schneiderlu52048 schrieb:  

Zitat:Welcher Schieber?

Damit meine ich den Button mit dem ich die Messung starte. Dieser lässt sich nicht mehr bedienen, wenn eine Messung durchgeführt wurde. Hat das einen bestimmten Grund? Wie könnte man das anders lösen, wenn das so nicht funktioniert?

Also den Start-Button derjenigen Messung, dessen Reiter bei Start des VIs aktiv ist, den solltest du mehrfach betätigen können. Aber an die anderen Messungen kommst du gar nicht ran. THINK Dataflow, dein VI startet, wertet 1x den Wert des Tab-Control aus und bleibt dann in diesem einem Case hängen. Andere Buttons kannst du dann bedienen. Und wenn du es trotzdem machst, dann tappst du in die Falle mit den mehreren Event-Strukturen. Das Event des anderen Buttons kann ja nicht abgearbeitet werden, die Standard-Einstellung ist aber, dass das FP solange blockiert wird, bis das Event abgearbeitet wird. FAIL. Du könntest das zwar anders konfigurieren, guter Stil ist das aber nicht. Merke: Eine Event-Struktur sollte IMMER die Möglichkeit haben, möglichst schnell auf ein User-Event zu reagieren.

(24.01.2017 14:50 )schneiderlu52048 schrieb:  

Zitat:Think Dataflow: Du hast das Schreiben der Tabelle nach jedem Schritt deiner State-Machine eingefügt. Dummerweise übergibst du Warten-Case keine Werte bzw. genauer den Default-Wert von Numerics an dieses VI. Der Default Wert eines Numeric ist 0

Das war mir so nicht bewusst. Das heisst ich ziehe das schreiben der Tabelle und den Export nach Excel in meinen Messung- und Berechnungsteil hinein, wodurch die erste Messung auch in die erste Zeile gelangt.

Ja, sollte so funktionieren.

Gruß, Jens

Hallo zusammen,

ich habe das Gefühl ich komme dem Ziel langsam näher. Ich habe das VI aufgeteilt, sodass es nur eine Eventstruktur pro VI gibt. Auch das Übertragen der Daten nach Excel hat schon so funktioniert wie ich mir das vorstelle. Allerdings haben sich weitere Probleme ergeben, bei denen ich eure Hilfe brauche:

Aus den Formelknoten erhalte ich für manche Ausgaben NaN, obwohl eigentlich alle Eingänge Werte enthalten, die Variablen deklariert sind und die Formeln nacheinander abarbeitbar sein sollten. Könnte da jemand einen Blick draufwerfen?

Das VI habe ich angehängt.

Gruß,

Lucas

Hallo Lucas,

Zitat:Aus den Formelknoten erhalte ich für manche Ausgaben NaN, obwohl eigentlich alle Eingänge Werte enthalten, die Variablen deklariert sind und die Formeln nacheinander abarbeitbar sein sollten. Könnte da jemand einen Blick draufwerfen?

Blick geworfen und entschieden: da musst du wohl selbst debuggen…

Im Ernst: Wenn deine Berechnung NaN liefert, dann wird das seine Ursache in den Parametern der Berechnung haben. Leider haben wir diese Parameter nicht - du aber schon!
Aufgabe für dich: Prüfe, bei welchen Parametern du das Ergebnis NaN bekommst. Dann prüfen, warum du genau dann NaN bekommst.
Idee: du hast da einige SQRT-Funktionen verwendet, die liefern schnell mal NaN… (Vereinfacht ausgedrückt bei der Hälfte aller möglichen Eingangswerte! )

Welche Werte sind NaN? Immer dieselben? Wirklich immer? Dann sollte es dir doch ein leichtes sein, den Formelknoten nach Fehlern zu durchsuchen.

Gruß, Jens

P.S.: NaN kommt u.a. vor, wenn du irgendwo einmal durch 0 teilst...