Parallele Datenaufnahme, Erz-Verbr verbraucht irgendwann nicht mehr

(12.07.2012 14:57 )kiX schrieb:  hier mal ein kleines Update:

Viel hat sich nicht verändert, und manche Probleme bestehen immer noch.

Die Waittime ausm Consumer wurde rausgeworfen, DBL wird direkt in die Queue eingespeist, unnötige Lokale Variablen wurden entfernt (s. Anhang).

Bislang ist es nicht passiert, dass der Consumer einfach nicht mehr gearbeitet hat, selbst wenn ein neues Element in die Queue gesetzt wurde. Schonmal gut.


Was immernoch passiert, ist, dass die Motorsteuerung stockt, wenn irgendwas gemacht wird. Es dauert anscheinend recht lange, die aktuelle Motorposition an die Queue weiterzugeben (währenddessen kann der Motor nicht weiter), aber noch mehr stockt er, wenn der Consumer läuft.

Liegt es am (für heutige Verhältnisse) lahmen PC (2,4GHz Celeron, 2GB Ram) oder kann man das irgendwie beheben?
Eine wirklich parallele Abarbeitung (mit höchster Prio beim Producer) wäre wirklich wünschenswert. Gibts da eine Alternative zum Producer-Consumer-Design?


Kurz noch zum Consumer (s. Screenshot):
Nach meinem Empfinden sollte er die gesamten (alten) Messdaten aus Values1.txt lesen, pro Schleifendurchgang je einen Teilstring anhängen und bei Beenden der Schleife den gesamten String wieder in Values1.txt abspeichern. Tut er aber nicht. Starte ich das Programm mit aktivierten Stopschaltern, speichert er (für den einen Durchlauf) die Messdaten ab, lasse ich jedoch das Programm einfach laufen und beende dann nach ein paar Durchgängen über (beide) Stop-Schalter, speichert er NICHTS ab.

Was geht, ist in jedem Durchgang einen String in Values2.txt abzuspeichern. Er wird dadurch nicht spürbar langsamer (er IST es ja schon ), aber wirklich elegant finde ich das nicht.

Jemand ne Idee?

Nimm mal das Wait aus der Consumer-Loop ganz raus, wenn du das auf 0 setzt bekommt die Schleife Priorität (siehe Kontexthilfe zur Wait-Funktion). Ausserdem anstatt ein 2.Stop in der Consumer-Loop zu verwenden würde ich einfach den Fehlerausgang an die Stopbedingung anschliessen (oder unboundle und den Boolean-Wert des Fehlerclusters verwenden falls das in 7.1 noch nicht geht).

Das Problem mit den nicht gespeicherten Werten mit dem Shift-Register konnte ich nicht nachvollziehen Nimm mal den 2.Stop Knopf wie oben beschrieben raus und schau mal ob es dann funktioniert.

Gruss Marc