Ich hab ehier ein Problem, ich habe 2 "Treiber"-Klassen gebaut, die je eine Run-VI haben, nun kann es dazu kommen, dass im Programmablauf unerwartet ein externes Kommunikationsproblem auftritt und diese VIs neu gestartet werden müssen. Also hab ich mir gedacht, legst du den Start der VIs in deine Event-Schleife ... blöd nur dass die Eventschleife jetzt einfach das Event solange nicht verlässt, bis tatsächlich auch das Run-VI beendet ist! Wie kann ich das umgehen?
Die Idee innerhalb der Run-VIs das Reset durchzuführen hatte ich auch schon, aber bei einer "unglücklichen" Terminierung des Haupt-VI würde das mit einer hohen Wahrscheinlichkeit zum Freeze der Anwendung führen.
Daher hätte ich es schon gern innerhalb des Events gestartet um im Notfall auch das VI abschießen zu können!
(05.08.2011 09:23 )ceos schrieb: [ -> ]... blöd nur dass die Eventschleife jetzt einfach das Event solange nicht verlässt, bis tatsächlich auch das Run-VI beendet ist! Wie kann ich das umgehen?
Wie startest du denn dein RunVi? Wenn du es mittels VI Server startest, dann kannst da am 'Waituntildone'-Anschluss festlegen, dass nicht gewartet werden soll, bis das VI beendet ist:
[
attachment=35094]
Sonst lade doch mal dein VI hoch, oder ein Beispiel, damit man sich das ganze besser vorstellen kann.
Beste Grüße,
NWO
Eine zweite Möglichkiet ist, daß vom Event aus über Melder, Queues oder globale Variable mit dem VI kommuniziert wird. Damit kann man es starten und anhalten.
Damit das klar wird, mal ein Beipiel:
Das Sub-Vi sei z.b. eine Statemachine mit den Zuständen "Idle", "Active" und "Exit"
Es wird bei Start des Haupt-VI mit gestartet, befindet sich aber zunächst im Zustand "Idle". Vom Haupt-VI läßtes es sich dann über Melder beliebig oft zwischen "active" und "idle" umschalten. Bei Beenden des HauptVI sollte das SubVI in den Status "Exit" versetzt werden.
über Server kann cih es nur bedingt starten.
EDIT: Beispiel entfernt. Ich versuch einfach noch ein paar Tutorials anzuwenden da hab ich wahrscheinlich mehr Erfolg.
Ich komm aus der Ecke Informatik und tu mich ehrlich gesagt noch sehr schwer in Labview zu denken, weshalb ich einen etwas anderen Blickwinkel habe, also nich wundern falls mein Beispiel merkwürdig aussieht!
Ich verwende darin einen paramtergesteuerten Prozess, also keine Statemachine.
So wie ich die Queue dort verwendet habe dient sie mir zum einen als Thread-Lock und zum anderen als Referenz oder "quasi"-this-Pointer. Grund hierbei ist ein Ansatz für eine generische Klasse, über die ich für verschiedene Geräte, die verwendet werden, die gleiche API bereitstellen will, also von ihr ableite und dann die Gerätespezifischen Befehle umsetze.
MfG
Danke für die Anregungen bisher ^^
Die Idee den Prozess gleich komplett als Statemachine laufen zu lassen ist garnicht sooo verkehrt und ähnelt vom Konzept ja meiner parametergesteuerten Threadschleife. Ich versuch mal das Beispiel drauf umzustellen.