Schieberegler Wertänderung

Hi,

ich habe einen Schieberegler mit zwei Cursern mit denen ich die X Achse eines XY Graphen (Min-Max)Wert verändern kann.
Dazu habe ich ein Event in der Eventstruktur für den Schiebregler angelegt, indem ich den alten und neuen Wert der Cursor 1 und 2 als Min und Max Werte des XY Graphen verwende.

Das lief alles 1a bis ich mein Timeoutcase für eine Datenverarbeitung verwendeten muss und ich das Ereignistimeout der Event Struktur von -1 auf 1 setzen musste.

Nun laggt der Schieberegler und das ist unschön.

Andere Ereignisse im Eventcase Schieberegler wie Ziehen führten leider nicht zum Erfolg.

Was kann man tun?

Gruß HCO

Anzeige

Hallo HCO,

Zitat:Das lief alles 1a bis ich mein Timeoutcase für eine Datenverarbeitung verwendeten muss und ich das Ereignistimeout der Event Struktur von -1 auf 1 setzen musste.

Einfache Lösung: die Datenverarbeitung aus dem Timeout heraus nehmen und wieder -1 als Timeout-Wert einstellen!
Dass du die Datenverarbeitung im Timeout-Event durchführen MUSST, bezweifle ich. Oder zwingt man dich dazu?

Wenn du den timeout auf 1 (ms!) stellst, wird deine Datenverarbeitung nach spätestens 1ms aufgerufen. Wenn diese Datenverarbeitung nun etwas Zeit benötigt (es reichen schon 10ms, aber es fehlt mal wieder ein VI, um das zu beurteilen), wird die Abarbeitung anderer Events entsprechend verzögert: ein ValueChange eines Schiebereglers wird als stark verzögert wahrgenommen… (Hinzu kommt der unschöne Nebeneffekt von Schiebern mit Defaulteinstellungen, das du wahnsinnig viele ValueChange-Events erzeugst: für jedes Pixel, um das sich der Schieber bewegt, gibt es ein Event!)

Wenn du wirklich mit 1kHz Daten verarbeiten musst, dann mach das in einer parallel laufenden Schleife!
Grundregel Event-Struktur: die Abarbeitung von Events sollte so kurz wie möglich dauern, damit es nicht zu Verzögerungen bei anderen Events kommt…

Ok, verstehe ich.

Danke für die Hilfe.

Gruß HCO

Ich habe von "könnte im Timeout-Case" geschrieben. Und von 1 ms Sekunde Time-out habe ich auch nichts geschrieben. Ist ja auch völlig unsinnig, wenn dir erstens die Queue das Buffern übernimmt und zweitens nur jede Sekunde ein neuer Datensatz in der Queue landet.

Gruß, Jens

Hi Jens,

stimmt, da gebe ich dir recht.

Das Problem ist ja immer noch mit dem Dateneinlesen in die Txt. Datei, da ich ja wie schon bekannt in der Eventstruktur
eine neue Logdatei anlege(Event) und die Referenz dann über das Scheiberegister in den Timeoutcase schiebe, wo ich die Daten kontinuierlich in die TXT.datei schreibe und bei dem Event " In Txt. Datei schreiben beenden " dann die Referenz über das Schieberegister in "Datei schließen" gesendet wird.

Habe ja deswegen auch die Speicherloop (Element aus Queue entfernen) in den Timeoutcase der Ereignisstruktur gepackt. (siehe Anhang)
So läuft zwar jetzt alles was mit der Stringtabelle zutun hat, zieht aber auf der anderen Seite negative Aspekte auf andere Parameter wie das mit dem
Schieberegler.

Die Operation die ich auch nur einmal ausführe können ja gut im jedem Eventcase bleiben.

Wenn ich jetzt ne neue Loop erstelle zur "Datenspeicherung in die TXT. Datei", wie kann ich diese dann mit meiner Referenz verbinden? (Wieder über die oder eine neue Queue und die Referenz dann einmal reinschieben zu der anderen Loop, jedoch muss diese dann aber wieder zurück zu der Eventstruktur zum Event" Lesen in TXT Datei beenden"
Die Eventstruktur ist momentan in der Textdatei/datenverabreitung ein geschlossener Vorgang mit einem Schieberegister.

Was kann ich tun?

Gruß HCO

Erstelle eine eigene Schleife für die Datenspeicherung, und in der führst du auch das Schieberegister mit deinem File-Pointer und packst auch die File-Erstellung mit rein (quasi eine State-Machine mit den Fällen: File erstellen, Daten speichern, File schließen). Das steuerst du dann per Queue. Dazu kannst du z.B. den Datentyp der Queue, die du schon jetzt für die Datenweitergabe verwendest, erweitern um weitere Kommandos und Elemente.

Gruß, Jens

Hallo HCO,

denkst du manchmal über das nach, was du so prorammierst?

Du hast einen Timeout-Eventcase, der nach 1ms ohne weitere Events aufgerufen wird. Im Event wartest du dann (bis zu) 500ms auf einen Queue-Eintrag, der nur im 1000ms-Takt zu erwarten ist…
Und du wunderst dich, warum deine ValueChange-Events des Schiebereglers stark verzögert abgearbeitet werden?

Und was soll der dieser RubeGoldberg: Da werden mehrere Datenarrays in einen Cluster geschrieben, um diesen Cluster dann Nanosekunden später wieder auszulesen? Warum nicht einfach (möglichst gerade) Drähte verwenden???

(06.11.2015 11:00 )GerdW schrieb:  Und was soll der dieser RubeGoldberg: Da werden mehrere Datenarrays in einen Cluster geschrieben, um diesen Cluster dann Nanosekunden später wieder auszulesen?

Daran bin wahrscheinlich ich Schuld: s. Anhang aus http://www.labviewforum.de/Thread-String...#pid179445
Allerdings bin ich bei diesem Bsp davon ausgegangen, dass die Spalten wie schon vorher unterschiedliche Breiten bekommen sollten, und dann wäre das mit mit 1x "Array to Spreadsheet-String" erledigt gewesen.

Gruß, Jens

Hallo Gerd,

vielen Dank für die Kritik.
Du hast natürlich in allen Punkten recht und ich werde mich bessern.
Habe den Case nochmal überarbeitet (siehe Anhang) und versucht der diese Rube Goldberg entgegenzuwirken.
Ist es nun so in Ordung?
Nun habe ich alles auf 1 Sek. gesetzt und die Wertänderung macht keine Klagen mehr.

Jedoch ich verstehe ich nun die Problematik und versuche den Vorschlag von Jens umzusetzen.

Gruß HCO

Hallo HCO,

ein Problem bleibt noch: deine Eventstruktur kann immer noch bis zu einer Sekunde lang blockiert sein - durch die Wartezeit beim Dequeue.
Nochmal eine der Grundregeln bei der Eventstruktur: Eventcases sollten so schnell wie möglich abgearbeitet sein!

Ich würde sowas nicht im Tiemout einer Event-Struktur erledigen, die sich um UI-Dinge kümmern soll. Die von Jens vorgeschlagene Statemachine wäre auch mein Favorit!
(Einer der Gründe: möglichst klare Trennung von UI-Handling und Datenverarbeitung…)