Quittierungstaster

Hallo liebe LVF-Gemeinde!

Ich habe mir zum Ziel gesetzt, einen EKG-Simulator zu entwerfen, der neben dem normalen Herzschlag auch diverse Fehler simulieren soll. So weit so gut. Mein Problem ist folgendes:
Wenn ein Herzstillstand auftritt (Drehschalter), soll dies durch einen langgezogenes Ton signalisiert werden, der erst aufhört, wenn entweder eine normale EKG-Kurve ausgegeben wird oder (während des Herzstillstands) ein Taster gedrückt wird.
Hat jemand von euch eine zündende Idee, wie ich das realisieren kann? Ich habe bereits versucht, mit einem True-False-Selector zu arbeiten, aber bisher ohne nennenswerten Erfolg. Den Alarm stumm zu schalten kriege ich auch noch hin, allerdings wäre gut,
Mein zweites Anliegen: Kann mir jemand erklären, warum im Case 1 (Herzstillstand) die Aktualisierung der Signalverlaufskurve zeitverzögert auftritt und im Normal-Case nicht? Ich vermute das liegt daran, dass ich beim beep.vi eine Dauer von 500ms eingestellt habe und diese 500ms auf den gesamten Case angewandt werden. Kann man diesen Makel beheben? Die Verzögerung wirkt sich negativ auf das Umschalten von Case 1 auf Case 0 aus, wäre schön, wenn die Umschaltung flüssig stattfindet.

Anbei ein Auszug aus meinem Projekt, sowie die Datei zum generieren der Herzfrequenz.


Vielen Dank im Voraus,
Villus

Hallo Villus,

herzlich willkommen im Forum!

Zitat:Hat jemand von euch eine zündende Idee, wie ich das realisieren kann?

Versuch es mal mit Statemachines und Producer-Consumer-Schemata! Einfach geschachtelte Case-Strukturen behindern dich ja schon jetzt bei diesem einfachen VI…

Zitat:Ich vermute das liegt daran, dass ich beim beep.vi eine Dauer von 500ms eingestellt habe und diese 500ms auf den gesamten Case angewandt werden.

Korrekt: THINK DATAFLOW! (Grundprinzip von LabVIEW, solltest du verinnerlichen… )

Zitat:Kann man diesen Makel beheben?

Besser programmieren: Producer-Consumer und so…

Zitat:Die Verzögerung wirkt sich negativ auf das Umschalten von Case 1 auf Case 0 aus, wäre schön, wenn die Umschaltung flüssig stattfindet.

Einfache Konsequenz: dann darf in diesem Case eben keine Verzögerung vorhanden sein! Erwähnte ich schon das Producer-Consumer-Schema?

Zitat:Wenn ein Herzstillstand auftritt (Drehschalter)

Allgemeine Kritik:
Wenn du zwischen zwei Zuständen hin- und herschalten willst, solltest du keinen Drehregler nehmen und schon gar keinen mit Datentyp DBL! Nimm doch einfach einen Schalter oder stelle den Datentyp wenigstens auf I32 um…

Erkläre bitte das Ergebnis des "=0"-Vergleichs mit deinem DDT-Draht! DDT-Drähte mögen "nett" sein, verhindern aber, wie hier sichtbar, sehr effektiv, dass man korrekte Programme erstellt!

Hallo GerdW,

vielen Dank für die Begrüßung und deine Antwort!

Da ich auch zu den Anfängern bei LabVIEW gehöre, sagen mir deine beiden Begriffe nichts. Aber ich werde mal Google fragen, wie ich die Dinger einzusetzen habe.

Zitat:Wenn du zwischen zwei Zuständen hin- und herschalten willst, solltest du keinen Drehregler nehmen und schon gar keinen mit Datentyp DBL! Nimm doch einfach einen Schalter oder stelle den Datentyp wenigstens auf I32 um…

Ich will nicht nur zwischen zwei Zuständen hin und her schalten, es soll zwischen insgesamt 5 verschiedenen Zuständen umgeschaltet werden können. Wie gesagt, ist nur ein vereinfachter Auszug aus meinem ursprünglichen VI.

Zitat:Erkläre bitte das Ergebnis des "=0"-Vergleichs mit deinem DDT-Draht! DDT-Drähte mögen "nett" sein, verhindern aber, wie hier sichtbar, sehr effektiv, dass man korrekte Programme erstellt!

Mit dem "=0"-Vergleich möchte ich den folgenden Case ansteuern, der dann den Alarmton ausgibt. Mir fällt auf die schnelle keine andere Möglichkeit ein, ohne den Vergleicher bleibt alles still.

Bezüglich den State-Machines habe ich mir einige Tutorials auf YouTube angesehen, scheint wirklich besser zu sein. Ich werde mal etwas herumprobieren, um das auf mein VI zu adaptieren.

Hallo Villus,

Statemachines und Producer-Consumer findest du bei LabVIEW im Dateimenü unter "Neu…"!

Hallo GerdW,

Entschuldigung für die späte Antwort, momentan viel um die Ohren....

Zitat:Statemachines und Producer-Consumer findest du bei LabVIEW im Dateimenü unter "Neu…"!

Habe mir sowohl Statemachine wie auch Consumer/Producer angeguckt, weiß allerdings nicht so wirklich, wie ich das sinnvoll auf mein VI adaptieren kann. Bescheidene Frage, kannst du mir da evtl ein/zwei Tipps geben?

Habe noch ein "kleines" Problem bei der Generierung der EKG-Kurve: Ich würde gerne ein Signal erstellen, das aus mehreren Funktionen besteht. Also z.B:
Funktion 1: P-Welle (Sinus- bzw. Funktion nten-Grades)
Funktion 2: isoelektrische Linie (lineare Funktion)
Funktion 3: Abfall zur Q-Zacke (lineare Funktion)
Funktion 4: Anstieg zur R-Zacke (lineare Funktion)
Funktion 5: Abfall zur S-Zacke (lineare Funktion)
Funktion 6: Anstieg zur isoelektrischen Linie (lineare Funktion)
Funktion 7: isoelektrische Linie (lineare Funktion)
Funktion 8: P-Welle (Sinus- bzw. Funktion nten-Grades)
Funktion 9: U-Welle (Sinus- bzw. Funktion nten-Grades) [optional]

Schaffe ich es irgendwie, ein schönes EKG-Signal anhand dieser Parameter zu erstellen, wenn ja wie? Meine Überlegung wäre, je einen Sinus- und DC-Generator an einen MathScript- bzw. Formula-Node anzuschließen, mir dort mit den Funktionen mein Signal zu basteln und anschließend das End-Signal mit einem Graphen wiederzugeben. Sinn der Sache ist, mit möglichst wenig Aufwand die Parameter und daraus resultierend das Signal zu verändern, um verschiedene Herzkrankheiten und deren Variationen darzustellen. Also beispielsweise den Ausschlag der P-Welle erhöhen, dafür die Q- und R-Zacke verkleinern und sone Scherze.
Ich kann zwar mit "Arbitrary Waveform" ein Signal ausgeben lassen, das ich selbst definieren kann, jedoch ist es ein Grauen, jede Herzkurve einzeln zu modulieren und eine nachträgliche Modulation ist auch nicht gegeben.

Dem Anhang habe ich je eine Grafik beigefügt, einmal die Original-Datei eines Norm-EKGs und eine Einteilung, wie ich mir das Endergebnis ungefähr vorstelle.

Das war jetzt ein bisschen viel auf einmal, bitte um Tipps, Tricks oder Lösungsansätze, wie ich mein Vorhaben in die Tat umsetzen kann.

Vielen Dank im Voraus und einen schönen Sonntag,
Villus

Hallo Villus,

Zitat:Schaffe ich es irgendwie, ein schönes EKG-Signal anhand dieser Parameter zu erstellen, wenn ja wie? Meine Überlegung wäre, je einen Sinus- und DC-Generator an einen MathScript- bzw. Formula-Node anzuschließen, mir dort mit den Funktionen mein Signal zu basteln und anschließend das End-Signal mit einem Graphen wiederzugeben. Sinn der Sache ist, mit möglichst wenig Aufwand die Parameter und daraus resultierend das Signal zu verändern, um verschiedene Herzkrankheiten und deren Variationen darzustellen. Also beispielsweise den Ausschlag der P-Welle erhöhen, dafür die Q- und R-Zacke verkleinern und sone Scherze.

Du hast doch jetzt schon sehr schön 9 Abschnitte (oder auch "States") definiert, die nacheinander abgearbeitet werden müssen, um deine Waveform zu generieren.
Man könnte das jetzt mit einer Sequenz erledigen und damit einen festen Ablauf vorgeben, aber eine Statemachine macht das auch und dazu noch schöner/eleganter/erweiterbarer!

Und deinen Parametersatz würde ich als (typdefinierten) Cluster in die Statemachine hineinschicken…

Anzeige

Hallo GerdW,

Danke für den Tipp, die verschiedenen Funktionen als States zu funktionieren. Ich werde das gleich mal ausprobieren!

Was genau meinst du mit "typdefinierten Cluster"? Ein Cluster mit einem bestimmten Datenformat, z.B. I32 oder DBL?

Hallo Villus,

Zitat:Was genau meinst du mit "typdefinierten Cluster"?

Wenn man einen Cluster anlegt, packt man ja meist verschiedene Elemente hinein. Und meist benutzt man den Cluster dann auch in subVIs. Und damit man dann bei Änderungen des Clusters nicht alle subVIs händisch ebenfalls ändern muss, macht man aus dem Cluster eine "Typdefinition"…

Hallo GerdW,

dein Tipp mit der Statemachine ist Gold wert, danke nochmal dafür!

Zitat:Wenn man einen Cluster anlegt, packt man ja meist verschiedene Elemente hinein. Und meist benutzt man den Cluster dann auch in subVIs. Und damit man dann bei Änderungen des Clusters nicht alle subVIs händisch ebenfalls ändern muss, macht man aus dem Cluster eine "Typdefinition"…

Stimmt, konnte mit dem Begriff erstmal nichts anfangen, da ich die englische Version habe. Wenn ich mich nicht irre, wäre das bei mir dann "make type def.", oder stehe ich da gerade auf dem Schlauch?

Hi Villus,

yes, you're right!
"Typdefiniert" = "type definition"…