Polling von Curser-Position in Waveform Graph vermeiden

Hallo zusammen,

ich hab mir ein Programm geschrieben, das Messdaten erfasst und sie in einem Waveform Graph darstellt und anschließend speichert. Funktioniert alles ganz gut soweit.

Nun wollte ich eine "kleine Spielerei" einbauen, und zwar zwei frei ziehbare Curser (x-Achse), die mir den Bereich des gemessenen Signalmaximums wiedergeben. Die Position wird per Eigenschaftsknoten abgefragt und ausgegeben.
Das ganze erzeugt allerdings nochmal deutlich an CPU-Last, die ich vorher nicht hatte, entweder liegt es an der Cursoraktualisierung im Graphen oder am Polling der Cursorpositionen. Die Messdaten kommen so im 1 Sekunden-Takt, die Cursor flimmern allerdings etwas, es scheint, als würden die häufiger aktualisiert.

Das Programm besteht aus der Haupt-Whileschleife (ungebremst), welche eine Case- (Statusmaschine) und Eventstruktur (Benutzereingaben) beinhaltet. Der Graph wird in einem Case dargestellt. Der Eigenschaftsknoten und die Cursorpositionsanzeiger liegen in der While-Schleife.

Ich habe schon versucht, es irgendwie hinzubekommen, dass die Position der Cursor erst aktualisiert wird, wenn man sie verschiebt (was in der Regel recht selten vorkommt), so a la Eventstruktur, ging aber nicht. Mir würde es auch reichen, wenn die Cursor später (im nächsten Durchlauf, z.B.) aktualisiert werden.

Liegt es an der Natur des Graphen/der Cursor, dass die Last hochgeht oder lässt sich das irgendwie regeln.

Vielen Dank schonmal und viele Grüße!

Anzeige

Hallo UFPhC,

wenn man Polling vermeiden will, nutzt man die Eventstruktur!

In deinem Fall das "Cursor verschieben"-Event…

Zitat:Das Programm besteht aus der Haupt-Whileschleife (ungebremst)

Du hast überhaupt keine Wartezeiten in dieser Schleifen???

Zitat:Ich habe schon versucht, es irgendwie hinzubekommen, dass die Position der Cursor erst aktualisiert wird, wenn man sie verschiebt (was in der Regel recht selten vorkommt), so a la Eventstruktur, ging aber nicht.

Wenn jemand sagt "geht nicht", aber keine vernünftige Fehlerbeschreibung liefert, muss man antworten: "Geht doch!"

Allgemein: Wenn du ein Problem mit deinem VI hast, solltest du uns einen Blick darauf gönnen…

Hallo Gerd,

Vielen Dank für Deine Hilfe, Du hattest völlig recht, es geht doch! Ich hatte nur falsch gesucht und dachte, es gäbe einen extra Eintrag dafür, musste aber natürlich beim Graphen selber nachschauen.
So ist jetzt auch die Last wieder auf das ursprüngliche Level (ca. 60%, 50% machen allein schon die Fastcard aus) gefallen.

Zu Deiner Frage mit der Wartezeit: In der Haupt While-Schleife ist keine Wartezeit, in der Benutzereingabe (Event-Struktur) musste ich eine setzen, sonst hat er manche Sachen nicht sauber angezeigt. Bin mir allerdings noch nicht ganz im Klaren, wie der Timeout der Eventstruktur mit einer Bremse in der While-Schleife zusammenspielt.

Ich hab mal ein Bild angehängt.

Hallo UFPhC,

- wozu die Abfrage auf FirstCall mit dem Case hinterher, wenn deine Schleife endlos läuft? Außerdem hast du hier eine RaceCondition!
- wenn du eine Statemachine programmierst, dann nimm ein Schieberegister. Du musst nicht in jedem State in eine lokale Variable des States schreiben. Und der FirstCall wird dann auchnicht mehr benötigt!
- wozu liegen die ganzen Terminals ungenutzt in der Schleife? Warum nutzt du die nicht, um wenigstens ein paar der lokalen Variablen zu löschen?
- UnbundleByName erhöht die Lesbarkeit eines Blockdiagramm ungemein!
- Ja, dein Aufbau benötigt einen kleinen Timeout der Event-Struktur…

Hallo Gerd,

vielen Dank für Deine Tipps und Hinweise!

Zitat:- wozu die Abfrage auf FirstCall mit dem Case hinterher, wenn deine Schleife endlos läuft? Außerdem hast du hier eine RaceCondition!

Das mit der RC hab ich mir fast gedacht, ich hab die FirstCall Abfrage nachträglich eingebaut, weil beim Beenden des VIs (ein State mit dem 8-eckigen Stop-VI) das Programm danach wieder auf Standby gesetzt werden muss, wenn ich es erneut laufen lasse, unschön, ich weiß. Muss mal noch sehen, wie ich das besser hinbekomme. (So wie es jetzt ist müsste das in eine Sequenz vor der While-Schleife, oder?)

Zitat:- wenn du eine Statemachine programmierst, dann nimm ein Schieberegister. Du musst nicht in jedem State in eine lokale Variable des States schreiben. Und der FirstCall wird dann auchnicht mehr benötigt!

Funktioniert das auch, wenn ich mal händisch (per GUI) in einen anderen State springen will? Muss mir die Beispiele mal nochmal genauer zu Gemüte führen.

Zitat:- wozu liegen die ganzen Terminals ungenutzt in der Schleife? Warum nutzt du die nicht, um wenigstens ein paar der lokalen Variablen zu löschen?

Die hab ich alle mal zusammengestellt, um das ganze etwas übersichtlicher zu halten. Habe jetzt aber auch mitbekommen, dass lokale Variablen bei LV weitestgehend vermieden werden sollten.

Zitat:- Ja, dein Aufbau benötigt einen kleinen Timeout der Event-Struktur…

Wie müsste ich das denn machen, um keinen Timeout zu brauchen, oder geht das hier gar nicht anders?

Die ganzen Status LEDs müssten sich eigentlich auch irgendwie anders abfragen lassen, das ist mit Sicherheit nicht die eleganteste Lösung

Hallo UFPhC,

Zitat:Muss mal noch sehen, wie ich das besser hinbekomme. (So wie es jetzt ist müsste das in eine Sequenz vor der While-Schleife, oder?)

Nein, das wird die Initialisierung des schon erwähnten Schieberegisters. Fertig…

Zitat:Funktioniert das auch, wenn ich mal händisch (per GUI) in einen anderen State springen will?

Ja.

Zitat:Die hab ich alle mal zusammengestellt, um das ganze etwas übersichtlicher zu halten.

Was ist daran übersichtlicher? Man sieht nicht mehr den DATAFLOW! Und das ist das Grundprinzip von LabVIEW…

Anzeige

Hi Gerd,

(14.10.2014 07:52 )GerdW schrieb:  Was ist daran übersichtlicher? Man sieht nicht mehr den DATAFLOW! Und das ist das Grundprinzip von LabVIEW…

Ich finde es auf jeden Fall übersichtlicher, wenn man alle benutzten Objekte auf einen Blick erfassen kann. Und den Dataflow gibt es ja innerhalb der Strukturen ja trotzdem noch. Bei uns in der Firma ist das jedenfalls Standard. Desweiteren hat das den Vorteil, dass in der liste der lokalen Variablen nicht der eine Zugriff fehlt, der über das Terminal geht.

Hallo th,

Zitat:wenn man alle benutzten Objekte auf einen Blick erfassen kann.

Woher weiß ich, dass die Controls/Indicator benutzt sind, wenn alle Terminals an einer Stelle gesammelt wurden? Ich weiß nur, dass sie existieren…

Zitat:Und den Dataflow gibt es ja innerhalb der Strukturen ja trotzdem noch. Bei uns in der Firma ist das jedenfalls Standard.

Es ist also Standard, dass man RaceConditions provoziert, weil man zwar innerhalb von Strukturen auf den DATAFLOW achtet, aber dies womöglich außerhalb verdrängt?

immer noch
Hi Gerd,

Zitat:Woher weiß ich, dass die Controls/Indicator benutzt sind, wenn alle Terminals an einer Stelle gesammelt wurden? Ich weiß nur, dass sie existieren…

Man kann auch Controls/Indicators erstellen und sie nie wieder benutzen. Sei es weil der Draht unbenutzt an einer Schleife endet oder in einem Cluster gespeichert wird und nie wieder gebraucht wird. Dagegen hilft in beiden Fällen nur saubere Programmierung.

Zitat:Es ist also Standard, dass man RaceConditions provoziert, weil man zwar innerhalb von Strukturen auf den DATAFLOW achtet, aber dies womöglich außerhalb verdrängt?

Man hat keine RaceConditions, wenn sich außerhalb der äußeren Struktur nur die Terminals (ohne Defaultzuweisungen oder dergleichen) befinden. Es gibt bei uns außerhalb keinen Code.

Wenn wir weiter diskutieren wollen, sollten wir evtl. einen eigenen Thread anlegen.

Thomas

Hallo nochmal,

das mit den Variablen wird wohl immer eine kleine Streitsache bleiben, an manchen Stellen ist es vll. übersichtlicher, an manchen nicht.

Nichtsdestotrotz stört mich die Initialisierungs-RC in meinem Programm schon ein wenig, daher habe ich über die Realisierung mit dem Schieberegister nachgedacht.
So ganz klar ist mir jedoch die User-Interaktion mittels Eventstruktur nicht. Steht die Eventstruktur wie in meinem Beispiel auch innerhalb der Programm-Whileschleife? Ich müsste dann ja noch irgendwie eine Abfrage einbauen, die klärt, ob es eine Benutzereingabe gegeben hat, damit dieser Status dann weiter gegeben werden kann oder ob die SM ihre Aufgaben weiter abarbeiten soll.

Hat da vll. jemand ein Beispiel für mich?

Vielen Dank schon mal!

P.S.: Unbundle by name ist geändert