LabVIEWForum.de

Hi Freaks!

Ganz kurz vorab: Ich habe als erstes Projekt ein recht umfangreiches NF-Messgerät (Filter, FM/FDM, Statistik, Soundcard als IO) realisiert. Learning by Doing hat Zeit gekostet (natürlich), aber ich konnte letztlich ALLE gewünschten Funktionen realisieren. Help und Examples sind vorbildlich und äußerst hilfreich. Andere professionelle Tools, mit denen ich beruflich arbeiten durfte, könnten sich davon diverse Scheiben abschneiden.

EIN Problem bleibt aber, das ich nicht lösen kann:
Ich importiere kontinuierlich Sound in einer While Loop.
Sporadisch ist ein User Dialog erforderlich. Während das Dialog Fenster offen ist, steht der Prozess in der aktuellen Loop und der Sound Buffer läuft in den Overflow, was den Prozess beendet. Um das abzufangen, habe ich mit Sound Input Stop/Start experimentiert. Mit dem bescheidenen Erfolg, dass Sound Input Read in den Timeout läuft. Hilft nicht wirklich.
Ausgerechnet für Sound Input Stop/Start konnte ich keine Beispiele finden. Wie sie in den Task ID Flow einzubinden sind, ist nicht dokumentiert. “MUP“ (Methode des unbekümmerten Probierens) hat leider keine Lösung gebracht. Hier einer meiner Versuche:
[attachment=62868]
Die elegantere Lösung wäre ein User Dialog, der die aktuelle Loop nicht pausieren lässt. Für eine solche Lösung fehlt mir aber die Idee schon im Ansatz. Eine Variante, die den Sound Import während des User Dialogs unterbricht, wäre aber ausreichend.

Vielen Dank schon mal,
Frank

Hallo Frank,

dein Parallel-Thread ist gelöscht…

Zitat:EIN Problem bleibt aber, das ich nicht lösen kann:
Ich importiere kontinuierlich Sound in einer While Loop.
Sporadisch ist ein User Dialog erforderlich. Während das Dialog Fenster offen ist, steht der Prozess in der aktuellen Loop und der Sound Buffer läuft in den Overflow, was den Prozess beendet.

Eine einfache Lösung sollte das Auftrennen von SoundIO und UI-Handling sein.
Wenn Dinge parallel/unabhängig laufen sollen/müssen, dann musst du sie auch parallel/unabhängig programmieren!

(13.02.2025 23:34 )DropOut schrieb: [ -> ]Ausgerechnet für Sound Input Stop/Start konnte ich keine Beispiele finden. Wie sie in den Task ID Flow einzubinden sind, ist nicht dokumentiert. “MUP“ (Methode des unbekümmerten Probierens) hat leider keine Lösung gebracht. Hier einer meiner Versuche:

Die elegantere Lösung wäre ein User Dialog, der die aktuelle Loop nicht pausieren lässt. Für eine solche Lösung fehlt mir aber die Idee schon im Ansatz. Eine Variante, die den Sound Import während des User Dialogs unterbricht, wäre aber ausreichend.

Vielen Dank schon mal,
Frank

Dein Puffer läuft voll weil die Verarbeitung steht bis der Nutzer eingegeben hat. Daher: Eingabe von Verarbeitung trennen. Dafür brauchst du eine zweite While Schleife. Eine verarbeitet nur den Sound, die andere nur die Nutzereingaben. Kommunikation zwischen beiden Schleifen ggf. über eine Queue um die Nutzereingaben weiterzuleiten. Vorlagentechnisch könnte man sich dazu die Statemachine bzw. Queued State Machine anschauen.
Je nach konkretem Szenario kann dabei sogar die Nutzung lokaler Variablen ausreichend sein um das zu realisieren (vorher prüfen ob Racing Conditions zu relevantem Fehlerverhalten führen können!).

Gruß Kiesch

Der Hinweis auf PARALLELE Programmierung war der wesentliche Tipp. Völlig klar, man muss nur drauf kommen. Vielen Dank dafür!

Die Kommunikation zwischen den Loops habe ich mittels Property Nodes realisiert. War für mich am einfachsten. Auch ein zusammengefasstes STOP geht damit. Der Restart war etwas tricky. Mit Auswertung beider Iterations Counter geht das aber nun auch.
[attachment=62870]

Also alles bestens, nochmals vielen Dank!

Hallo Frank,

noch etwas Manöverkritik zu deinem VI:
- Warum "value"-PropertyNodes, wenn man auch lokale Variablen nutzen könnte? (Die brauchen weniger Ressourcen!)
- Warum so viele Coerciondots? Warum verwendest du unpassende Datentypen?
- Warum dieser Vergleich mit einer Konstanten "0"? Es gibt da spezielle Vergleichsoperatoren!
- Warum 2 Stopp-Buttons? Sollte dem User nicht ein Button ausreichen???
- Warum ein ExpressVI (FromDDT), um aus einem Array ein Element zu indizieren? Wozu gibt es eigentlich Array-Funktionen, z.B. IndexArray???
- Für mehrere boolsche Eingänge kann man auch die CompoundArithmetik verwenden, statt mehrere gleiche boolsche Operationen zu verketten…
- Warum eine Wartezteit parallel zu deiner Event-Struktur??? Wenn die Loop mit 100ms iterieren soll, kann dein Event auch 100ms auf den TimeOut warten…

Hallo Gerd,
Ich bin Autodidakt und Absolute Beginner. Da sind solche Hinweise und Kritiken eines Profis sehr hilfreich. Ich lerne auch mit 67 immer noch gern dazu, danke.

- Warum "value"-PropertyNodes, wenn man auch lokale Variablen nutzen könnte? (Die brauchen weniger Ressourcen!)
Weil es damit ging. Lokale Variablen hatte ich noch nicht entdeckt. Sehr wertvoller Tipp.
- Warum so viele Coerciondots?
Die kannte ich auch noch gar nicht. Habe aufgeräumt.
- Warum verwendest du unpassende Datentypen?
Wo, bei den Loop Countern? Ich wollte sicher die Interpretation als negative Zahl beim Vergleich verhindern. Aber originär scheint
[ i ] I32 zu verwenden, dann nehme ich das auch.
- Warum dieser Vergleich mit einer Konstanten "0"? Es gibt da spezielle Vergleichsoperatoren!
Musste ausprobieren, ob es ab 0 oder 1 funktioniert. Da 0 geht, kann man das jetzt vereinfachen.
- Warum 2 Stopp-Buttons? Sollte dem User nicht ein Button ausreichen???
Der folgte aus den Property Nodes als "Empfänger" für den STOP-Transfer von Loop1 nach Loop2. Sollte final "gehided" werden. Mit einer lokalen Variabel braucht es den natürlich nicht.
- Warum ein ExpressVI (FromDDT), um aus einem Array ein Element zu indizieren? Wozu gibt es eigentlich Array-Funktionen, z.B. IndexArray???
Habe ich aus einem Example abgeschrieben ohne zu wissen was da geschieht. Hat gepasst, Hurra!
Wenn ich ans Array und an die Waveform einen Indikator hänge, sehe ich, wie sie aufgebaut sind und wie man das raus-indizieren kann. Dann gerne so, man muss ja nicht mit Kanonen auf Spatzen schießen.
- Für mehrere boolsche Eingänge kann man auch die CompoundArithmetik verwenden, statt mehrere gleiche boolsche Operationen zu verketten…
Um ein paar pW und fs beim Kompilieren einzusparen ;-)
Hatte sich historisch so entwickelt. Kann man der Übersichtlichkeit wegen natürlich zusammenfassen.
- Warum eine Wartezteit parallel zu deiner Event-Struktur??? Wenn die Loop mit 100ms iterieren soll, kann dein Event auch 100ms auf den TimeOut warten…
Ei verbibscht (sagt der Sachse). Den Überblick habe ich (noch) nicht. Übernehme ich gerne.

Besser so?:
[attachment=62872]

P.S.: Ich sehe gerade, am Sound Input Configure VI ist noch ein Coercion Dot! Schaue ich mir noch an.

Hallo Frank,

Zitat:P.S.: Ich sehe gerade, am Sound Input Configure VI ist noch ein Coercion Dot! Schaue ich mir noch an.

Aus dem Input bei dem subVI eine Konstante erzeugen, die hat dann automatisch den richtigen Datentyp. Und damit dann ein Bundle(ByName) füttern, das zeigt dann auch gleich die korrekten Label der Cluster-Elemente an…

Außerdem: die "0" am IndexArray kann weg.
IndexArray fängt per default mit dem ersten Element zu indizieren an - und kann natürlich auch mehr als ein Element indizieren, falls das nötig wird…

(16.02.2025 17:24 )GerdW schrieb: [ -> ]Hallo Frank,

noch etwas Manöverkritik zu deinem VI:
- Warum "value"-PropertyNodes, wenn man auch lokale Variablen nutzen könnte? (Die brauchen weniger Ressourcen!)

*hust* weil man im Umgang mit Eventstrukturen "value (signaling)" arbeiten sollte wenn man nicht wie hier nen timeout von 1ms hat. Achja - so wie jetzt aufgebaut wäre ein "value (signaling)" kontraindiziert, da dann mit jedem durchlauf der unteren Schleife das event oben auf das Stop event getriggert würde ^^ (das muss man sauber ausprogrammieren, so dass das nur bei Änderungen auch signalisiert)

Gruß Kiesch