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!
Ich habe ein Problem, ich habe 7 parallele Loops welche Daten von 2 USB-Schnittstellen auslesen müssen. Dies klappte eigentlich ganz gut, bis ich die letzte Schleife generiert habe. Mein Problem ist, dass das Programm nie darauf zugreift, obwohl ich Queues habe, welche bereits Elemente enthalten. Es handelt sich um die Schleife, "Search Telegrams".
Ja das habe ich auch zuerst, habe dann aber gemerkt, dass ich das Firmenlogo noch aufgeschaltet habe
Die Queue hat Elemente. Ich habe auch schon nur eine Queue in Search Telegramm versucht, aber das will einfach nicht.
Reicht es wenn ich einfach das Hauptprogram ohne die SubVI hoch lade, damit man sieht was gemeint ist?
21.12.2017, 09:25 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2017 09:25 von GerdW.)
Zitat:Ich habe auch schon nur eine Queue in Search Telegramm versucht, aber das will einfach nicht.
Warum nicht? Wo hakt es?
Zitat:Reicht es wenn ich einfach das Hauptprogram ohne die SubVI hoch lade, damit man sieht was gemeint ist?
Leider nicht ganz…
Man sieht leider nicht, ob in den subVIs jetzt gesendet oder gelesen wird.
Meine Vermutung:
Du hast bei dem ganzen Hin und Her in deinem Haupt-VI irgendwo DATAFLOW-Anhängigkeiten zwischen den verschiedenen Loops. Diese führen zu einem Deadlock: der Receiver wartet auf Daten vom Sender, der aber (aufgrund DATAFLOW-Anhängigkeit) noch nichts senden kann. (Vielleicht auch Sender/Receiver umgekehrt.)
Bei 6 Queues in einem VI würde ich auch den Überblick verlieren…
Tipp: Highlight-Execution-Debugging, um zu sehen, ob irgendwo ein DATAFLOW "hängenbleibt"…
Tipp2: Vorher aufräumen, um etwas mehr Überblick zu bekommen.
Tipp3: Ein kleines Test-VI erstellen, wo nur Zufallsdaten hin- und hergeschickt werden. Dort dann die Zusammenhänge aufdröseln…
Danke für deine Hilfe.
Ich habe leider praktisch keine LabVIEW Erfahrung. Ich habe lediglich Core 1 und 2 besucht, wobei man da ja nur ein Bisschen an der Oberfläche kratzt.
Ja das mit dem Aufräumen ist leider nicht so einfach. Ich habe schon relativ viele SUB-VI s generiert und der Nachteil daran ist ja, dass man dann die schreibende Queue nicht mehr sieht. Für Tipps wie man das übersichtlicher machen kann, wäre ich sehr froh, später kommt dann noch der bidirektionale Funktest dazu, dann verdoppelt sich das Ganze (Halleluja!).
In der letzten Schlaufe geht es darum, die gefilterten und aufbereiteten Telegrame eines Senders und Empfängers zu vergleichen.
Mit Elementen meine ich, dass bereits diverse "Telegrame" in der Queue sind (String) , aber trotzdem nicht ausgelesen wird.
Hallo Ratio,
in der While-Schleife "Search Telegram" werden alle Schieberegister auf 0 gesetzt, wenn die Array Schieberegister größer als 5 werden oder wenn beim Suchen im String nichts gefunden wird.
Ist das so gewollt?
Gruß
Freddy
Diesen Teil wollte ich eigentlich ausprobieren, die Schieberegister sollten nur am Anfang 0 sein (initialisieren). Ich kam aber nicht zum testen der Schleife wegen dem beschriebenen Problem, Wenn ich Sonden setze, sind alle Werte innerhalb der Schleife unberührt. Das wird ja kaum am Schieberegister liegen oder?
Wie gesagt, diese letzte Schleife ist noch nicht getestet und ohne sie, funktioniert auch alles wie gewollt.
Und nochmals Danke für die Hilfe, ich freue mich wirklich sehr darüber....
21.12.2017, 10:20 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2017 10:25 von GerdW.)
Zitat:Für Tipps wie man das übersichtlicher machen kann, wäre ich sehr froh
Generelle Sachen:
- StyleGuide beachten: Eingänge links, Ausgänge rechts (deine SearchTelegram-Loop hat das nicht immer)
Spezielle Sachen:
- ich würde die MatchPattern-Funktion aus FilerParts2 nach FilterPart1 verschieben, das erhöht die (logische) Übersicht in beiden subVIs!
Zitat:Ja das mit dem Aufräumen ist leider nicht so einfach.
In den subVIs einfach mal Ctrl-U drücken: dann siehst du, wie einfach das sein kann!
Zu deinem Problem:
- Dein FilterPart2 verschickt nur bedingt Strings in die Queue: bsit du dir sicher, dass hier alle gewünschten Pakete weitergeleitet werden?
- Wenn FilterPart2 nichts weitersendet, dann wird in der PrepareTelegramLocControlRX-Loop auch nichts passieren
- Dann passiert auch in SearchTelegram nichts!
Diese Verkettung von Queues ist wirklich nicht hilfreich (oder übersichtlich)!
- du liest in SearchTelegram aus zwei Queues, die aus verschiedenen Quellen gespeist werden: wenn eine der beiden leer ist, dann blockiert deine Consumer-Schleife!
- du könntest beim QueueRead einen Timeout vorgeben - dann musst du aber eben auch den Timeout-Fall speziell behandeln!
Zitat:später kommt dann noch der bidirektionale Funktest dazu, dann verdoppelt sich das Ganze (Halleluja!).
- Manchmal soll es helfen, sich vor dem Programmieren eine Programmstruktur zu überlegen - und auf Papier aufzumalen…
- Es soll auch hilfreich sein, Dinge an TestVIs auszuprobieren - bis man sie verstanden hat und sie fehlerfrei funktionieren…
P.S.: Wenn du das nächste mal mehr als 3 Anhänge bereitstellen willst: ZIP verwenden!
Danke für deine Hilfe. CTRL+U, das wird dann leider noch viel unübersichtlicher. Ich verstehe das Programm, da ich es ja selber geschrieben habe.
Ich weiss leider nicht wie man das sonst lösen könnte. Die Daten müssen bearbeitet und kontinuierlich geprüft werden, wie kann man das sonst machen? Ich hatte eine Sitzung mit einem LabVIEW Entwickler, der wusste auch nur diesen Weg, der Ansatz mit den nächsten Queues kamen sogar von Ihm.
Das Problem liegt nur bei der Queue 5 und 6, die Daten werden schön sauber und korrekt aufgelistet in den Fenstern "ready to Compare".
Ich sehe auch dass sie gleich sind, nur muss das Programm dies noch prüfen (kontinuierlich). Dazu wäre die Schlaufe "Search Telegram" vorgesehen.
Die Queue 5 und 6 werden mit "Daten" versorgt, ich sehe mit der Sonde wie der Speicher entsprechend hochzählt bzw. die Daten "ready to compare" eingelesen werden (in Queue 5 und 6).
Es handelt sich dabei um ein Streckendämfpungstest für eine Funkübertragung. Die Telegramme werden aber je nach Dämpfungswert nicht oder sehr verzerrt "auf der anderen Seite" ankommen.
Mein Ziel ist es eigentlich nur die Daten "ready to Compare" zu vergleichen (welche auch vorhanden sind). Alles andere ist +/- getestet.
Wenn mir jemand sagen kann, wie ich die Daten "zusammen bekomme", probiere ich das natürlich aus. Aber ich denke, dass geht nicht ohne Queue...
Zitat:Die Queue 5 und 6 werden mit "Daten" versorgt, ich sehe mit der Sonde wie der Speicher entsprechend hochzählt bzw. die Daten "ready to compare" eingelesen werden (in Queue 5 und 6).
In beiden "Prep Telegram"-Loops wird ein "ready to compare"-Array aufgebaut? Die Daten dazu kommen aus Queue2/4…
Hast du geprüft, ob (und was) auch jeweils Werte nach Queue5/6 geschrieben wird?
Hast du geprüft, ob die Werte in der SearchTelegram-Loop ankommen?
Hast du mittlerweile (per Highlight-Execution, Breakpoints oder Sonden) geprüft, ob deine SearchTelegram-Loop überhaupt gestartet wird?
Zitat:CTRL+U, das wird dann leider noch viel unübersichtlicher
Ich habe explizit die subVIs empfohlen für den Anfang!
Zitat:Aber ich denke, dass geht nicht ohne Queue...
Queues sind immer nur ein Mittel unter vielen. Aber sie können, richtig verwendet, den Aufwand minimieren…
(lokale/globale/Netzwerk-Variablen, FGVs aka AEs, Notifier, Channels, NetworkStreams, …)
