Design "Erzeuger/Verbraucher

' schrieb:Oh, da gibt es schon noch Möglichkeiten. Das Auslesen des Elementes, in dessen Folge zuerst mal lediglich der Wert des Elementes zurückgesetzt wird, erzwingt zwar einen Refresh am Bildschirm - der kann aber zeitversetzt (zwischen 1ms und 10 Sekunden sag ich jetzt mal) passieren.

Wenn die gesamte GUI (also dein FP) blockiert ist, kann das auch daran liegen, dass irgendwo eine While-Schleife (z.B. die vom Verbraucher) soviel Prozessor-Leistung für das Blockdiagramm verbraucht, dass keine Zeit mehr für den FP-Refreh bleibt. Manchmal hilf da eine Wartezeit von 1ms in die While-Schleife zu plazieren.

Gut wäre es, wenn du ein MusterVI mit den Auffälligkeiten erstellen kannst.

Hi,
ich antworte so spät, weil ich langsam begreife wo es hängt.
Meine Erzeugerschleife reagiert auf Drücken von Buttons meines Frontpanels, und stellt dann passende Strings in die Queue.
Meine Verbraucherschleife holt sich diese Strings raus, und bearbeitet sie im passenden case.
Auch wenn ich in so einem Case einen LabVIEW-Timer mit einer Wartezeit von 10000ms stelle, funktioniert die GUI korrekt.

Ich habe aber eine DLL in C (VS2005) erstellt, die ich im betreffenden case aufrufe. Diese DLL kommuniziert über TCP/IP mit einem SerialDeviceServer, der im Prinzip eine RS232 Schnittstelle bereitstellt. Daran hängen RS232-Geräte (mehrere). Die Kommunikation funktioniert so, dass so ein Gerät ein Kommando gesendet bekommt (z.B.: "VALVE7 OPEN") und dann antwortet (z.B: "OK"). Diese Antwort erfolgt zeitverzögert, z.B.: nach 10 Sekunden.

Was bei mir vermutlich der Fall ist, ist dass LV in meine DLL springt (CallLibraryFunctionNode) und da halt etwa 10 Sekunden hängt. Im C-Code hänge ich in den 10 Sekunden in einer while-Schleife, wo ich mit sleep(100); halt warte, und dachte so CPU-Zeit abzugeben. Aber offensichtlich blockiere ich so das gesamte LabVIEW, so dass weder meine GUI-Buttons sich bewegen, noch sonst was ausgeführt wird.

Hier ein C-Code-Fragment von mir:

[code]//unterscheiden zwischen UDP und TCP