' schrieb:Wir haben festgestellt, dass unser Geraet besser arbeitet, wenn ich es ueber eine Producer-Consumer-Schleife steuere.
Das liegt aber an sich nicht an der Producer-Consumer-Schleife - sondern daran, dass durch das Programmierkonzept "Producer-Consumer" eine Modularisierung entsteht. Diese Modularisierung ist der Grund, warum es besser geht. Ein Modul kann man übersichtlich(er) programmieren. Ein Modul alleine arbeitet wie in einer selbständigen Task. Da wird nur das abgearbeitet, was auch tatsächlich für das Modul (respektive in deinem Falle das Endgerät) notwendig ist. Ein Modul ist immer ein SubVI.
Ein solches Modul entspricht einer Klasse im OOP-Sinne.
Ein Modul sorgt intern dafür, dass das Endgerät optimal angesteuert wird. Das geht soweit, dass selbst eine Falschbedienung durch den Anwender ganz leicht ignorierbar ist.
Macht man alles in einer Schleife (in einem BD), kommen so viele Seiteneffekte zusammen - dass man sich irgendwann selbst nicht mehr auskennt.
Zitat:Interessanterweise kann der Motor ohne Probleme seine Richtung schnell aendern, wenn der User abwechselnd "Infuse" and "Withdraw" drueckt.
Das ist leicht erklärt: Bei anwendergesteuert vergeht zwischen den einzelnen Buttonklicks immer viel Zeit - das kommt dem Endgerät zugute. Außerdem entsteht bei diesem Verfahren nur minimaler Code. Du weist ja: Kein Code, kein Fehler. Wenig Code, wenig Fehler ...
Zitat:Falls das gesamte Programm so moeglich ist, wuerde ich versuchen, es als SubVi im Hautprogramm abzuspeichern.
Dieses Vorgehen ist richtig.
Bei mir gibt es immer ein Haupt-VI mit Benutzeroberfläche. Dieses Haupt-VI hat eine Event-Struktur in einer While-Schleife. Hier werden lediglich Events (also einmalige Ereignisse) abgearbeitet, wie z.B. Buttonclicks. Neben dieser While-Schleife kann eine zweite While-Schleife mit einer Statemachine stehen. Diese Statemachine kann genau den automatischen Ablauf enthalten, den du haben willst. Diese zweite While-Schleife befindet sich deswegen in diesem Haupt-VI, weil Anzeigeelemente beschrieben werden sollen. Diese Statemachine kommuniziert mit dem Modul über Queues und Melder. Wäre keine Anzeige notwendig, würde man diese Statemachine auch in ein SubVI (also ein eigenständiges Modul) auslagern oder gar in das Endgeräte-Modul integrieren.
Die Gerätesteuerung selbst (also das ganz oben erwähnte Modul) liegt mit Queue/Melder/Ereignis-Referenzen am Eingang auf dem BD des MainVI. Dieses Modul läuft im Hintergrund parallel zum Haupt-VI.
Ich hab mal ein kleines Muster angehängt. Die untere While-Schleife ist das Endgeräte-Modul und sollte in einem SubVI ausgelagert werden. Benutzerereignisse sind in dieser Ausbaustufe noch nicht erforderlich.
Zitat:Geht es eventuell auch einfacher zu realisieren?
Einfach an sich ist Sache des Standpunktes.
Was für mich "einfach" ist - modulare, also gekapselte, klassenorientierte SubVI-Programmierung mit Queues/Melder und FGVs - erscheint dem einen oder anderen doch recht verwirrend. "Einfach" ist ein Programm dann, wenn es gut auf einen Bildschirm passt. Unabhängig vom Algorithmus ist es wichtig, dass das Programm funktioniert, debugbar, wartungsfreundlich und nach Möglichkeit erweiterbar ist.
Was du als "einfach zu realisieren" suchst, ist der für deine Belange richtige Algorithmus und das richtige Programmierkonzept - und da bist du mit Modularisierung (also SubVI, SubVI, SubVI ...) und Queue/Melder-Steuerung schon mal auf dem richtigen Weg ...
