Sensor auslesen - Datenüberlauf aufgrund zu langsamer Programmlaufzeit

Hallo!

Wie bereits oben beschrieben habe ich folgendes Problem:

Ich lese einen Sensor über die serielle Schnittstelle aus. Dieser liefert mir alle 10 ms einen Wert ( 17 Byte ).

Um die Daten des Sensors zu lesen benötige ich daher eine Laufzeit von ~ 10 ms, da mir ansonsten der Puffer vollläuft.
In meiner Testumgebung funktioniert das auch soweit.. da ich hier nur einen Producer verwende und einen Consumer. - die 10 ms können soweit problemlos eingehalten werden.

Habe nun meine Schleife in einem Hauptprogramm mit 6 gleichzeitig ablaufenden parallelen Schleifen und erreiche diese Zeit nicht mehr und es kommt zum
Pufferüberlauf. ( Sehe mir hierfür über die Eigenschaft Bytes at Port die Bytes im Puffer der Schnittstelle an -> diese steigt kontinuierlich, solange bis es zum Überlauf kommt)
Puffergröße ändern bringt auch nur bedingt Vorteile:

Ein weiteres Problem tritt in meiner Visualisierung auf: wenn ich solange zum auslesen der Daten brauche, werden Änderungen vom
Sensor erst extrem spät visualisiert, da ja immer die ältestens Informationen aus dem Puffer zuerst ausgelesen werden. ( das ganze verschlimmert sich eben bei größeren Puffern)

Da ich mit meinem Latein ein wenig am Ende bin.. meine Frage:

Gibt es iwie die Möglichkeit für diese Schleife eine bestimmte Rechenleistung zu reservieren, damit ich die Zeit "garantieren" kann? .. / oder eine Art Priorisierung?
oder wie kann man so ein Problem noch beheben?

(das ganze Programm läuft auf einem Windows 7 Rechner)

Vielen Dank für eure Unterstützung!

LG
  DDU4_Forum.vi (Größe: 44,96 KB / Downloads: 312)

Hallo Stefan,

was würde passieren, wenn du einen Producer schreibst, der sich nur (so schnell wie möglich) darum kümmert, die Daten vom Sensor zu lesen? Also einfach eine Schleife, die 17 Bytes liest und in eine Queue schreibt…

Wozu die zusätzliche Wartezeit in deiner Schleife? Die Wartezeit ergibt sich doch einfach daraus, das VISARead auf eben jene 17 Bytes warten muss!
Wozu diese obere Queue "LOGIK_DDU4-Steuerung", mit der du eine Statemachine implementierst? Geht das nicht einfacher?

Hallo Gerd!

Vielen Dank für die Antwort!

Ich verstehe nicht ganz was du mit dem Producer meinst? ... hätte dann ja das gleiche Problem mit der zu langsamen Programmlaufzeit oder?

oder meinst du das ich eine zweite Producer Schleife verwenden könnte, die über eine Event struktur auf die ausgelesenen Bytes reagieren soll? - das dann der Zugriff eben über einen Interrupt erfolgt?
Vl könntest du das noch ein wenig genauer ausführen..

Mich würde auch interessieren was du dazu meinst:

Ist es besser die Daten aus der seriellen Schnittstelle auszulesen, einen Sensorabgleich durchzuführen, die Messdaten zu visualisieren und anschließend an die Queue weiterzugeben?
oder sollte die Schleife so aufgebaut sein, dass man die Daten ausliest, sofort in die Queue schreibt und anschließend in einer anderen Schleife die Visualisierung und den Sensorabgleich durchführt?


Das mit der Zeit habe ich deshalb probiert.. weil ich das Problem hatte, dass bei schnelleren Programmlaufzeiten als 10 ms die Werte nicht mehr richtig ausgelesen wurden? (in meiner Testumgebung)

Mir kam es so vor, als wie wenn die Read Funktion "max" 17 Byte auslest. Sind bei einem Leseauftrag weniger als 17 vorhanden.. dann werden auch weniger ausgelesen.. falls zum Lesezeitpunkt noch keine 17 Bytes vorhanden sind... kann das sein? .. weiß leider sonst nicht, wo mein Problem sonst noch herkommen könnte.. sobald ich die 10 ms nicht unterschreite funktioniert es soweit einwandfrei?... solangs dann aber auch wieder nicht zu lange dauert - da es ansonsten eben zum Pufferüberlauf kommt

Die Logik Queue habe ich deshalb verwendet, da ich es persönlich als übersichtlich empfinde.. wenn man eine Queue rein für die Logik der Schleifen verwendet und eine 2. eben zur Speicherung der Messdaten.
Wie hättest du es gelöst? .. hättest du es aufgrund der Programmlaufzeit anders gelöst?

-> die Programmzustände über Schieberegister weitergegeben?...


Aja kurze Frage: gibt es im Forum iwo eine Seite wo man Buchempfehlungen abgeben kann?
Habe letztens dann zum Glück ein Buch gefunden, wo die serielle Kommunikation und die Implementierung in
Labview recht gut erklärt wird .. da du micht extra auf meinen Fehler bezüglich meiner Bytes at Port Einstellung hingewiesen hast.. und war dann auf der Suche nach sinnvoller
Literatur...
Hätte diese gerne geteilt

Vielen Dank!

LG Stefan

Hallo Stefan,

Zitat:Mir kam es so vor, als wie wenn die Read Funktion "max" 17 Byte auslest. Sind bei einem Leseauftrag weniger als 17 vorhanden.. dann werden auch weniger ausgelesen.. falls zum Lesezeitpunkt noch keine 17 Bytes vorhanden sind... kann das sein? .. weiß leider sonst nicht, wo mein Problem sonst noch herkommen könnte..

Du hast dem VISARead doch gesagt, dass es maximal 17 Bytes lesen soll!
Du stellst ein TermChar beim SerialPortConfig ein, und erwartest maximal 17 Bytes vom VISARead…

Wie sieht denn deine erwartete Botschaft aus? Benutzt dein Sensor ein TermChar? Wenn ja: welches?

   
Funktioniert das hier?

Zitat:Ist es besser die Daten aus der seriellen Schnittstelle auszulesen, einen Sensorabgleich durchzuführen, die Messdaten zu visualisieren und anschließend an die Queue weiterzugeben?
oder sollte die Schleife so aufgebaut sein, dass man die Daten ausliest, sofort in die Queue schreibt und anschließend in einer anderen Schleife die Visualisierung und den Sensorabgleich durchführt?

Ich würde im Producer den seriellen Port lesen und den String schon mal in einen (Float-)Messwert umwandeln. Dann (falls es keine Fehler gab) diesen Messwert in eine Queue schieben.
Eine andere Schleife soll sich um die Anzeige kümmern, das hat nichts mit Gerätekommunikation zu tun…

Zitat:Ich verstehe nicht ganz was du mit dem Producer meinst? ... hätte dann ja das gleiche Problem mit der zu langsamen Programmlaufzeit oder?

Wie kommst du darauf, dass dein PC es nicht schafft, 100mal pro Sekunde 17 Bytes vom seriellen Port zu verarbeiten? Wir reden hier über weniger als 2kB/s!

Hallo Gerd!

Vielen Dank für den Hinweis! , mir war leider (bis jetzt) nicht ganz bewusst, dass ich ein TermChar eingestellt habe..
Und nein, ich hätte in der Doku (die leider ein wenig bedürftig ist), nichts gelesen das dieser Sensor ein TermChar verwendet...

Werde dein Programm demnächst testen, vielen Dank! bin leider erst Freitags wieder in der Arbeit..

Du sprichst unten vom Producer.. Meinst du damit, jene Schleife die bei einer Producer / Consumer Struktur über eine Eventstruktur auf Benutzereingaben reagiert?
Oder verstehst du unter einem Producer eine Schleife die eben Daten generiert ( in unserem Fall eben Messdaten vom Sensor)

Ich habe es deshalb gemeint, weil ich aufgrund der parallel laufenden Threads (in meinem Fall 6) eben keine konstante Laufzeit der Schleife hinbekomme mit der ich die Sensordaten auslese und aus diesem
Grund mein Puffer vollläuft... ( im Schnitt beträgt die Durchlaufzeit ungefähr 70ms - schwankend)

Habe leider noch keine Erfahrung wie groß in solchen parallel laufenden Schleifen die Laufzeit durchschnittlich ist / mit was man ungefähr rechnen kann...
Deshalb meine Frage.. ob es eine Möglichkeit gibt eine möglichst "garantierte" Durchlaufzeit einer Messschleife programmtechnisch sicherzustellen?

LG Stefan

Hallo Stefan,

Zitat:Du sprichst unten vom Producer.. Meinst du damit, jene Schleife die bei einer Producer / Consumer Struktur über eine Eventstruktur auf Benutzereingaben reagiert? Oder verstehst du unter einem Producer eine Schleife die eben Daten generiert ( in unserem Fall eben Messdaten vom Sensor)

Ein Producer in einem Producer-Consumer-Schema hat erst einmal nichts mit einer Eventstruktur zu tun.
Der/die Producer generiert Daten, die ein/mehrere Consumer verarbeitet…

Zitat:Ich habe es deshalb gemeint, weil ich aufgrund der parallel laufenden Threads (in meinem Fall 6) eben keine konstante Laufzeit der Schleife hinbekomme mit der ich die Sensordaten auslese und aus diesem Grund mein Puffer vollläuft... Blink ( im Schnitt beträgt die Durchlaufzeit ungefähr 70ms - schwankend)

Unter Windows wirst du sowieso keine "konstante" Iterationszeit hinbekommen!
Und wenn deine 6 Schleifen, die alle solche Sensoren einlesen (?), so langsam sind, dann ist irgendwas anderes deutlich verkehrt!
Außerdem: wie sicher bist du, dass dein Messgerät exakt 10ms benötigt, um Messdaten zu senden? Wie sicher bist du, dass die serielle Schnittstelle in Messgerät und PC keine Verzögerungen verursacht?

Nochmal:
Wenn du auf Messdaten eines Sensors warten musst, dann benötigst du keine separate Wartezeit in der Schleife - die ist dann eher hinderlich!
Grundgedanke ist: einfach auf die gewünschten Messdaten per VISARead warten und dann so schnell wie möglich weiter verarbeiten/senden.
(Meine PST-Software arbeitet mit deutlich >100 parallelen Schleifen - mit etlichen Geräten wie deinem, wo auf neue Messdaten gewartet wird…)

Zitat:Habe leider noch keine Erfahrung wie groß in solchen parallel laufenden Schleifen die Laufzeit durchschnittlich ist / mit was man ungefähr rechnen kann...
Deshalb meine Frage.. ob es eine Möglichkeit gibt eine möglichst "garantierte" Durchlaufzeit einer Messschleife programmtechnisch sicherzustellen?

In deinem Fall: einfach per VISARead auf Messdaten warten.