Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
25.06.2010, 08:17 (Dieser Beitrag wurde zuletzt bearbeitet: 25.06.2010 20:33 von dimitri84.)
Ich habe noch nie was mit serieller Kommunikation gemacht, trotzdem hier mein Vorschlag:
Für den Datentyp der Queue würde ich einen Cluster aus Enum (Status für Consunmer Loop) und String (Daten) nehmen.
In der Producer Loop machst du 3 States: "Init" (VISA konfigurieren), "VISA Read", "VISA Close".
In der Consumer Loop bringst du den Rest unter: "Init" (vielleicht deine Berechnungen für f0 und df, und deine x-Achsen Maximas setzen), "Darstellung" (hier wird die Queue gelesen und die ankommenden Daten verarbeitet), ...
anscheinend hast du einen "verständigen" Arbeitgeber und keine Deadlines
1-Jahres-Absolventenpraktikum. Ich bin hier um was zu lernen. Nebenbei fallen ein paar Programme ab die das Institut schon seit vielen Jahren nötig hatte.
Selbst findest du aber auch die ein oder andere Minute, Gerd
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
Ich habe es jetzt soweit geschafft, mein Programm in eine Art FSM umzubauen. Funktioniert auch eigentlich ganz toll, nur habe ich jetzt noch ein Problem:
Wenn ich auf dem FP einen der Werte ändere und auf übernehmen klicke, hängt sich das Programm auf mit der Fehlermeldung in den Sub-VIs im Case "Parameter": 'Die gegebene Session oder Objektreferenz ist ungültig".
Jetzt kann ich mir eigentlich nicht erklären, woran das jetzt liegen sollte, denn das Sub-VI ist ja das gleiche wie in der Initialisierung und da funktioniert es ja auch. Die Session sollte eigentlich auch keinen Timeout oder ähnliches liefern, da ja vom Gerät permanent Werte abgefragt werden.
du hast mehrere Fehler in deinen VIs:
- bei diversen Case-Strukturen hast du undefinierte Ausgänge ("Use default if unwired") - das kann tötlich enden bei einer Statemachine!
- du verwendest zu viele Sequenzstrukturen - die sind unnötig!
- du hast einiges an RubeGoldberg drin (warum machst du einen Vergleich eines boolschen Wertes mit TRUE???)
- du hast für meinen Geschmack zu viele lokale Variablen - die zugehörigen Terminals gehören außerhalb der Casestruktur hin, evtl. mit einem Shiftregister verbunden und schon brauchst du keine locals mehr...
Ich hab schon mal angefangen zu editieren, schau's dir an. Insbesondere die diversen Case-Strukturen und deren Ausgänge!
du hast mehrere Fehler in deinen VIs:
- bei diversen Case-Strukturen hast du undefinierte Ausgänge ("Use default if unwired") - das kann tötlich enden bei einer Statemachine!
Verbindet man die Ein- und Ausgänge dann einfach durch, falls diese in einem Case nicht gebraucht werden oder gibt es eine andere, bessere Lösung?
Zitat:- du verwendest zu viele Sequenzstrukturen - die sind unnötig
!
Ok, ich werde die Sequenzen löschen. Aber ich weiß immer noch nicht genau, wann es sinnvoll ist, eine Sequenz zu benutzen und wann nicht...?
Zitat:- du hast einiges an RubeGoldberg drin (warum machst du einen Vergleich eines boolschen Wertes mit TRUE???)
Das ist wahr, ist mir gar nicht aufgefallen, dass das total sinnlos ist
Zitat:- du hast für meinen Geschmack zu viele lokale Variablen - die zugehörigen Terminals gehören außerhalb der Casestruktur hin, evtl. mit einem Shiftregister verbunden und schon brauchst du keine locals mehr...
Ich fand, dass die Variablen eigentlich ein bisschen mehr Übersicht hineinbringen, da dann nicht noch mehr Leitungen in einen Case hineinführen und die Variablen auch noch "schön" benannt sind.
Ich habe zwar schon gelesen, dass man Variablen eher meiden sollte, aber irgendwie konnte ich keine Begründung finden. Was ist denn das Hauptproblem damit?
Zitat:Ich hab schon mal angefangen zu editieren, schau's dir an. Insbesondere die diversen Case-Strukturen und deren Ausgänge!
Danke & Gruß
28.06.2010, 15:25 (Dieser Beitrag wurde zuletzt bearbeitet: 28.06.2010 15:52 von jg.)
"oder gibt es eine andere, bessere Lösung?"
Wieviel einfacher als einen einfachen Draht brauchst du es noch?
"wann es sinnvoll ist, eine Sequenz zu benutzen"
Nie. Mach dir lieber ein subVI mit ErrorIO-Anschlüssen...
"Was ist denn das Hauptproblem damit?" RaceConditions. Zusätzlicher Speicherbedarf. Unübersichtlichkeit.
"da dann nicht noch mehr Leitungen in einen Case hineinführen und die Variablen auch noch "schön" benannt sind."
In einem Cluster bündeln: nur eine Leitung.
Clusterelemente ordentlich benennen (und typedef anlegen): immer ordentlich benannt dank (Un)BundleByName (oder InPlace-Struktur).
Edit:
Hab mal 2 Cluster eingebaut, einen für die Eingaben, einen für deine Rechenwerte. Diese Rechenwerte waren typisch textbasiertes Programmieren: versteckte Anzeigeelemente, nur damit man einen "Variablennamen" zur Verfügung hat. Für solche Zwecke reicht immer ein Shiftregister!
