Programm bleibt hängen bei zweitem Durchlauf - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +---- Forum: Grafik & Sound (/Forum-Grafik-Sound) +---- Thema: Programm bleibt hängen bei zweitem Durchlauf (/Thread-Programm-bleibt-haengen-bei-zweitem-Durchlauf) Seiten: 1 2 |
RE: Programm bleibt hängen bei zweitem Durchlauf - GerdW - 04.12.2013 10:20 Hallo Brongx, - du hast den SoundInput auf "Kontinuierlich" konfiguriert, legst aber immer wieder große Pausen zwischen den Leseoperationen ein. Dies könnte den Lesebuffer sprengen... Was soll das hier bitte bringen? [attachment=47607] - Was erwartest du von der While-Loop im ersten Frame? Das Schieberegister startet mit Null (als Default). Null mod 2 = 0. Vergleich mit Null = TRUE. Sofortiger Schleifenabbruch und merken von i=0 im Schieberegister... - "Numeric" ist nach dieser Loop also Null. Im zweiten Frame gilt (0+1)mod2=1 und dass dann ungleich Null: der True-Case wird nie ausgeführt... - Warum diese ganzen lokalen Variablen? - Im GetRowFrquency-VI werden sich überlappende Frequenzbereiche geprüft. Ist das wirklich so - und ist das sinnvoll? (Statt der gestaffelten Vergleiche könnte man auch mit 1D-Schwellwert aus der Array-Palette arbeiten...) - Im listen_3.vi wird TransmitMode vor der Loop abgefragt. Ist das so gewollt? THINK DATAFLOW... RE: Programm bleibt hängen bei zweitem Durchlauf - Brongx - 04.12.2013 10:33 Zum Bild: Das habe ich gestern nachts noch herausgefunden, aber trotzdem danke! (War schon bisschen übernächtigt und hatte was probiert was eigentlich Schwachsinn war ^^) Die überlappenden Bereiche sind mir erst jetzt aufgefallen! DANKE! Macht natürlich nicht wirklich Sinn, der Offset ist zu groß gewählt bei der Row. Für den Transmit-Mode muss ich mir noch was überlegen. Der wird eigentlich von einem aufrunden VI aktiviert...habe aber nun gesehen, dass der Wert ja nie im listen.vi ankommen kann -.- Ich werde es mal mit Finite-Mode versuchen, Danke! EDIT:---> funktioniert ja nicht in einer Schleife -.- EDIT: So wenn ich die Pause raus nehme bleibt nix mehr hängen! War also wohl ein Überlauf! Vielen Dank! RE: Programm bleibt hängen bei zweitem Durchlauf - Brongx - 11.12.2013 21:02 Hallo zusammen, also Problem gelöst. Ich nehme jetzt im finite mode auf, das aber in einer Schleife (jedes mal neu init und clear). Funktioniert so wie ich es brauche. War wohl genau das Problem was GerdW angesprochen hat. Danke dir! Der Decoder funktioniert nun auch wunderbar! Erkenne alle Frequenzen und kann diese nun auch richtig zu ordnen. Mein einziges und letztes Problem ist jetzt noch das Umschalten von Receive- in Transmit-Mode. Ich habe in meinem "Haupt"-VI ja einen Button mit dem ich vom Empfangen auf Senden umschalten möchte. Nun ist leider das Problem, dass ich sobald ich das VI starte mich logischerweise sofort im listen.vi befinde und ich den Wert von dem anderen nicht da rein übertragen kann zur Laufzeit. Hätte da jemand eine elegante Idee wie ich das lösen könnte? Vielen Dank! RE: Programm bleibt hängen bei zweitem Durchlauf - Trinitatis - 11.12.2013 21:41 (11.12.2013 21:02 )Brongx schrieb: Nun ist leider das Problem, dass ich sobald ich das VI starte mich logischerweise sofort im listen.vi befinde und ich den Wert von dem anderen nicht da rein übertragen kann zur Laufzeit. Hätte da jemand eine elegante Idee wie ich das lösen könnte? Hallo Brongx, die Status von Knöppen kann man mit glob. Variablen oder eleganter über die Referenz des Knopfes und dessen Wertabfrage innerhalb des SubVIs lösen. Hierbei sollte bei schnellem Polling aber über den Umweg einer parallelen Schleife innerhalb des SubVIs und einer zusätzlichen Variablen nachgedacht werden. Oder man macht es (noch eleganter) über einen Melder. Gruß, Marko RE: Programm bleibt hängen bei zweitem Durchlauf - Brongx - 11.12.2013 22:03 Hallo Trinitatis, danke für die schnelle Antwort! Auf die Sache mit den Meldern bin ich auch schon gestoßen, leider versteh ich nicht genau wie ich diese benutze. Das Beispiel in der Hilfe macht mich auch nicht schlauer -.- Hatte mir das so wie in den Bildern gedacht, aber funktioniert leider nicht wirklich...bitte nicht haun wenn ich mich gerade wieder wie der erste Mensch anstelle ^^ RE: Programm bleibt hängen bei zweitem Durchlauf - Trinitatis - 11.12.2013 22:19 Im Grunde ist in deinem Beispiel schon alles enthalten. Man definiert einen Melder und weist ihm einen Datentyp zu (in deinem Fall z.B. boolesch). Dann geht man entweder mit der Melder Referenz in das SubVI oder fordert ihn dort namentlich separat an. Dann wartest du im SubVI auf eine neue Meldung (mit einem Timeout, damit es sich nicht aufhängt) und verschickst die Nachricht im MainVI. Vielleicht ist es für anfängliche Zwecke aber einfacher, über die Referenz des Knopfes zu gehen. Dazu erstellst du vom Knopf auf dem FP (über rechte Maus-Menü) eine Referenz, die du an dein Sub-VI übergibst. Diese Referenz ist sozusagen die Adresse deines Knopfes. In deinem SubVI kannst du dann einen Eigenschaftsknoten einbauen, an den du diese Referenz anschließt und aus dem du die Eigenschaft WERT ausliest. So bist du auch im SubVI über den boolschen Zustand deines Knopfes (oder jedes x-beliebiegen Controls) informiert und kannst drauf reagieren. Gruß, Marko RE: Programm bleibt hängen bei zweitem Durchlauf - Trinitatis - 11.12.2013 22:35 Ich hab´mal ein Beispiel mit Melder zusammengeklickt. Gruß, Marko |