Mehrere Cases verwenden

Hallo!

Ich versuche mich derzeit an folgendem Programm:

   

(ohne die zwei ereignisgesteuerten Cases funktioniert es einwandfrei, sind nur zu Probezwecken drin)

Nun hätte ich folgende Frage: Ich hätte gerne, dass abhängig von einem Druck auf einen Button, der hinter jeder einzustellenden Variable (auf dem Frontpanel) stehen soll, folgendes passiert:

- 1. die Messung in der Schleife wird angehalten
- 2. der Messwert wird neu an das Gerät geschickt
- 3. die Messung wird wieder gestartet

Wie würde man da am besten vorgehen? Gibt es eine Möglichkeit, mit dem Druck von einem Button mehrere Cases auszulösen und dann auch wieder die Messung zu starten?
Das scheint mir das größte Problem momentan zu sein...

Danke & Gruß

Schönen Nachmittag

Erstmals: Zwei Eventstrukturen sind nicht zu empfehlen, da kannst du dir schnell mal viele Fehler einhandeln!

Zu deiner eigentlichen Frage würde sich ein Zustandsautomat (State-Machine) anbieten

Diesen realisierst du am besten mit einem Enum (typedef verwenden!!!) und einer While Schleife, im Forum solltest du dazu schnell einmal ein Beispiel dazu finden

Solltest du noch fragen dazu haben nur her damit

Hmm, okay!

Da muss ich mal schauen, ob sich das auf mein Beispiel anwenden lässt. Momentan bin ich diesbezüglich ein wenig ratlos. Grundsätzlich wäre es am wichtigsten, dass die Producer/Consumer-Schleife bestehen bleibt, da diese Dreh- und Angelpunkt im Programm ist (Danke nochmal an das Forum für die Hilfe dazu!).

Es soll in diesem Fall auf mehrere Buttons abgefragt werden, wodurch jeweils dann ein Sub-VI aufgerufen wird, dass dann die Parameteränderung dem Analyzer mitteilt.
Ich weiß nicht, ob es nötig ist, die Messung zu stoppen, denke aber schon, da ja innerhalb der Schleife ein VISA-Write und Read stattfindet. Würde das mit den anderen Anfragen kollidieren?

Gruß

EDIT: Ich habe jetzt in einem Buch ein Beispiel gefunden, in der eine FSM am Beispiel eines Getränkeautomaten illustriert wird. Ich hoffe, das bringt mich meiner Problemlösung näher.

Heyho Yantit

Mit was für Daten arbeitet der Analyser? Mit den Daten aus der Consumer-Loop?
Oder sind damit die Veränderungen an der VISA-Verbindung gemeint?

Die Messungs kannst du grundsätzlich laufen lassen, wenn du nichts an der VISA-Verbindung änderst.


Ich hab dir mal ein kleines Beispiel gebastelt wie ichs machen würde (Is sicher nicht perfekt aber sollte funktionieren)

LabVIEW 8.5

  TestNotifier.vi (Größe: 33,29 KB / Downloads: 257)



Hoffe das hilft dir weiter

Mit freundlichen Grüssen

MNussbaumer

' schrieb:Ich versuche mich derzeit an folgendem Programm:
[attachment=56051:Case_Strukturen.png]

Oh neeeeeeeeeeeiiiiiiiiiiiiiiiiiiiiiiiinnnnnnnnn...eine Tapete!

' schrieb:
Oh neeeeeeeeeeeiiiiiiiiiiiiiiiiiiiiiiiinnnnnnnnn...eine Tapete!

Ein weiterer Grund für ne State-Machine

Hallo zusammen,

"...eine Tapete!"

Hier muss ich Yantit (teilweise) in Schutz nehmen. Ich hatte ihn gebeten, seine VIs vor dem Posting erstmal automatisch aufräumen zu lassen. Glaubt mir, das war nötig:)Ich hatte ihn aber nicht gebeten, bei jedem subVI den Namen anzeigen zu lassen, was hier wohl für mindestens 50% der BD-Breite zuständig ist...

@Yantit:
Wenn du den subVIs keine eigenen Icons spendierst, wirst du bei NI nie gehobene Programmiersphären erreichen:)Ich sage nur "StyleGuide"!

' schrieb:Grundsätzlich wäre es am wichtigsten, dass die Producer/Consumer-Schleife bestehen bleibt, da diese Dreh- und Angelpunkt im Programm ist (Danke nochmal an das Forum für die Hilfe dazu!).

Geht es nur mir so, oder seht ihr auch keine Producer-Consumer Architektur?

' schrieb:Geht es nur mir so, oder seht ihr auch keine Producer-Consumer Architektur?

Guck mal ganz rechts

@Yantit
Ich glaube hier geht es mit dem Thema erst produktiv weiter, wenn du deine Kommunikation in sinnvolle Abschnitte einteilst und das ganze in eine State-Machine packst; bzw. zwei State-Machines, eine für die Producer und eine für die Cosumer Loop.

' schrieb:Guck mal ganz rechts

@Yantit
Ich glaube hier geht es mit dem Thema erst produktiv weiter, wenn du deine Kommunikation in sinnvolle Abschnitte einteilst und das ganze in eine State-Machine packst; bzw. zwei State-Machines, eine für die Producer und eine für die Cosumer Loop.

Definitiv! Ich bin auch momentan dabei, mir das Thema zu erarbeiten und einen Plan zu machen, wie ich das am besten umsetze. Dann hat auch das elend lange Blockdiagramm ein Ende

Aber mit 4 Wochen LV-Erfahrung lässt sich das eben nicht mal so aus dem Handgelenk schütteln, daher musste ich mir gestern erstmal Wissen anlesen, wie man die Sache am besten anpackt. Aber ich werde die Ergebnisse hier dann noch posten.