Richtige Syntax in der Main für den Verbindungsaufbau zur Seriellen Schnittstelle

Hi,

Ok ich weiß mein Titel ist etwas lang, aber ich wusste nicht wie ich ihn besser formulieren soll.
Es geht um die Syntax meiner Main.vi

Hier funktioniert erstmal nur eine Einstellung und das ist die Manuelle Steuerung.

Also ich habe über meine Erzeuger-Verbraucher Struktur eine Sequenzstrutkur gelegt. Außerhalb dieser Struktur verbinde ich mit meiner Schnittstelle und beende sie, falls ich aus der Struktur rausgehe.

Kurz gesagt, ist das so sinnvoll wie ich das gemacht habe? Es funktioniert. Also ich kann, wie gewollt, einzelne LED ein und ausschalten.

Und ich hättenoch eine Frage und zwar wie kann ich meine Datenübergabe so gestalten, das ich die Daten sende auf knopfdruck? Weil momentan muss ich die Bedingung zum senden an die Queue erfüllen, aber er sendet erst wenn ich zwischen der Auswahl hin und her switche. Das ist nicht schön.


  Main.vi (Größe: 48,7 KB / Downloads: 252)


  Main2.vi (Größe: 10,95 KB / Downloads: 217)


  LEDan.vi (Größe: 14,04 KB / Downloads: 209)


Danke

Gruß Atilla

P

Hallo,

erstmal: Cool das mal ein VI gezeigt wird, dass (sauber) das Producer/Consumer-Pattern benutzt. Prima ist auch, dass keine überflüssigen lokalen Variablen zu sehen sind! Ich finde es muss auch mal gelobt werden

Ich habe mir dein VI mal angeschaut und ein paar kleine Änderungen eingebaut. Andere Sachen erwähne ich nur, die könntest du ja noch nachpflegen:

• Ich würde die Datenerzeugung direkt in die Eventstruktur machen. Die Status-Abfrage(ist es doch, oder?) könnte erstmal in den TimeOut-Case.
• Der Optik halber wird ich erst die Producer-, dann die Consumer-Loop anordnen
• Das VISA-Open-SubVI würde ich nicht bauen, da dort nur ein VI drin ist
• Die angeschlossenen Konstanten beim VISA-Open, würde ich weglassen, wenn sie dem Standardwert entsprechen
• Das Diagramm&Frontpanel könnte etwas aufgeräumt werden
• Die Geschichte mit dem Ein/Ausblenden der Frontpanel-Elemente find ich noch nicht super, ich habe das mal mit nem Tab-Control gemacht.
• Die Consumer-Loop braucht noch Feinschliff für die anderen Cases
• Den OK-Button zum Übernehmen brauchst du so nicht mehr unbedingt
• Unbedingt aus dem enum eine Typ-Definition machen!
  

   

Hab es nicht getestet; funktioniert es weiterhin bei dir?
ps.: Du weißt, dass du ein Snippet (das angehängte Bild) direkt in das Blockdiagramm ziehen kannst? Dann wird es direkt zu Quellcode.
pps.: Ich sehe grade das im Snippet das Event vom Tab-Control losgelöst wurde. Das ist keine Absicht. Bitte stelle als Event wieder ' "Tab Auswahl": Value Change' ein.

Gruß
eb

(28.11.2012 16:58 )eb schrieb:  Hallo,
erstmal: Cool das mal ein VI gezeigt wird, dass (sauber) das Producer/Consumer-Pattern benutzt. Prima ist auch, dass keine überflüssigen lokalen Variablen zu sehen sind! Ich finde es muss auch mal gelobt werden

Hey eb,

Danke für deine Antwort und deinen Lob. Das schön wenn man mal etwas richtig gemacht hat
Das mit dem Snippet wusste ich nicht, aber jetzt, auch danke dafür

Zitat:[*] Ich würde die Datenerzeugung direkt in die Eventstruktur machen. Die Status-Abfrage(ist es doch, oder?) könnte erstmal in den TimeOut-Case.
[*] Den OK-Button zum Übernehmen brauchst du so nicht mehr unbedingt

Warum ist es sinnvoll da die Daten zu erzeugen?
Ja es ist eine Status-Abfrage und es klingt sinnvoll die da zu platzieren. Aber wird ddann der status durchgehen abgefragt bzw regelmäßig?
Doch den Ok-Button brauche ich. Wie soll der Benutzer wissen, ob die daten gesendet wurden? Und ich darf ja nur eins von den Menüpunkten nutzen und übergeben und so lange die Messung läuft, darf der Benutzer nichts anderes machen.

Zitat:[*] Unbedingt aus dem enum eine Typ-Definition machen!

Verstehe ich nicht.
ich glaube, dass könnte dann auch der Grund sein warum er bei mir keine Daten sendet :/ Also es tut nicht das was es tuen soll.
Wenn du mir sagen könntest du ich das mit der Typ-Definition und der Typumwandlung vernüftig nachlesen kann, dann würde es bestimmt anders aussehen.

p.s. Die anderen menüPunkte kommen nach der Zeit. Ich möchte erstmal eins nach dem anderen sauber zu laufen bekommen.


Gruß Atilla

Moin,

1. Eine Typ-Definition ist ganz einfach ein Control (Bedien/Anzeigeelement), dass du in seiner Datenstruktur/-typ und seinem Aussehen festlegst (speicherst). Das hat den Vorteil, dass du fortan immer die gleiche (gespeicherte) TypDef nehmen kannst um: a) sie an einen Selektor für nen Case zu drahten b) sie zentral zu erweitern. Kommt mal ein Element dazu verändern sich alle mitbenutzenden Stellen gleich mit! Du brauchst dann nicht manuell überall das Enum ersetzen/erweitern.
2. Der Begriff "Datenerzeugung" war hier in dem Kontext unglücklich. Ich habe das aus deinem ursprünglichen VI übernommen. Eigentlich wird nur ein Command in die Queue für die ConsumerLoop gesendet. Das ist keine Datenerfassung oder sowas. Es ist aber üblich die Commands für die ConsumerLoop u.a. in einer Eventstruktur zu erzeugen.
3. Wie du im Snippet sehen kannst wird ja bei Frontpanelaktivität ein Event ausgelöst und damit sofort ein Command gesendet. Wenn du möchtest, dass der Nutzer das mitbekommt, dann baue doch einfach eine StatusInfo ein à la: "letztes Event: Tab geändert. letztes Command: Ratensteuerung".
4. Hast du mein Snippet ausprobiert? Dazu musst du nur noch das vorne liegende Event zuweisen zu dem Control "Tab Auswahl - Wertänderung"
5. Wenn du Lust hast, dann poste doch nochmal deinen Aktuellen Stand
   

Gruß
eb

Morgen,

also das mit der Typendefinition, ist dafür da, dass ich eine dynamische Struktur habe, habe ich dich richtig verstanden?

zu3.
Das Ding ist, das die Daten gesendet werden, bevor ich irgendetwas ausgeben kann. Also wenn ich einen Tap auswähle, sendet er sofort. Das darf ja nicht.
Außerdem sendet er immer nur einen leeren Fall. Ich habe beim Verbraucher einen Fall, falls es nichts sendet und erhalte einfach nur eine Bestätigung dieser Leersendung. Und das erhalte ich jetzt jedesmal bei jedem Tab.
Theoretisch brauche ich diesen Fall nicht mehr mit dieser Struktur.

Ich habe bis jetzt noch nichts verändert. Also an deiner Version, weil ich das mit der Typ Defintion nicht verstanden habe.

P.S.
Du kannst es auch selbst testen mit dem Menü "Ratensteuerung". Es soll nur zwei Werte übergeben.
Aber dies Funktioniert nicht.

Ich habe nun versuch einen OK-Button einzubauen und das mit der Typdefintion umzusetzen, aber iwie hängt sich das Programm total auf, nicht mal Ratensteuerung funktioniert.

P.P.S.
Jetzt sollte Ratensteuerung funktionierne.

   

Hallo nochmal,

Also wenn du den OK-Button unbedingt brauchst, dann würde ich das Senden des Commands davon abhängig machen.
so zum Beispiel:
   

Achtung: Die Reihenfolge der Tabs und der Bedienelemente beim Anschließen beachten!
Achtung: Irgendwie zerschließt er bei den Snippets immer die EventZuordnung, bitte stelle das gezeigte Event auf die Wertänderung des OK Buttons


Gruß
eb

Danke, es funktioniert nun genauso wie es soll. Also das mit dem OK-Button. So kann ich nun nämlich die Werte ändern und dann erst losschicken. Danke.

Aber ich bekomme es irgendwie noch nicht in den Kopf, was es mit der TypDef auf sich hat. Ich habe bei mir die Auswahl in der EReignisstruktur zu einer Typ def umgewandelt. Dafür habe ich dann ein VI erhalten in dem nur ein Enum enthalten ist und dieses hat die von mir gewünschten Menüs.
Nun habe ich noch dieses VI in die Elementdatentyp geladen. Aber das blöde ist ja nun, dass er mnun jedes mal die Manuelle Steuerung auswählt, egal was ich mache.
Also so weit ich es verstanden habe hast du das eingefügt damit mein VI dynamisch bleibt. Also wenn ich etwas in meiner Auswahl ändere, brauche ich dafür nur ein enum zu ändern statt z.b. 3 oder so. Richtig?

Kennst du vll ein gutes Beispiel, zur typDef. Ich würde es gerne verstehen, falls es dir keine Umstände bereitet.

Danke

gruß Atilla.

Zitat:Tut mir leid, ich meine es geht um Typumwandlung.

Zitat:Atilla schrieb:Hallo eb,
du hast mir mal vor einigen Monaten bei meiner Syntax geholfen und als Antwort bekam ich dann von dir http://www.labviewforum.de/attachment.php?aid=42447
(siehe Thema: http://www.labviewforum.de/Thread-Richti...ittstelle)
Ich bin dir dafür sehr Dankbar, denn damit habe ich große Fortschritte machen können. aber nun tut sich eine Frage auf und irendwie finde ich keine Antwort. Es geht um die Typdefinition, die du verbaut hast.
Warum du sie gemacht hast ist mir klar. Nur mein Problem ist nur, dass die Typdefintion immer nur die selbe Auswahl ausgibt. Zum testen habe ich ein kleine Vi erstellt, wo ich eine Registerkarte mit 4 Tabs erstellt habe und eine Typdefinition mit den selben Namen. Und dennoch wählt er immer nur den ersten Tab aus.
Warum?
Kannst du mir da vll helfen?

Mit freundlichen Grüßen

Atilla

Hallo Atilla,

Also die TypUmwandlung (TypeCast) dient dazu die Tab-Auswahl (Registerkarten-Element) auf die Enum-Konstante zu übertragen.
Wenn also z.B. der 2. Reiter ausgewählt ist, dann "wählt" die Typumwandlung den 2. Wert aus der Enum-Auflistung aus, und gibt diesen dann weiter. Der Vorteil dabei ist, dass der blaue enum-Draht nach der Typumwandlung eben ein enum ist; dieser kann z.B. einfach an einen Case-Struktur-Selektor angeschlossen werden und die Cases sind dann benannt, statt einfach nur Nummern zu tragen.

Um diesen Vorteil durch die Typumwandlung zu nutzen muss aber die Reihenfolge im enum gleich der Reihenfolge der Tabs im Registerkarten-Element sein!

Hab ich das soweit besser beschrieben?
Gruß

(27.02.2013 13:09 )eb schrieb:  Hab ich das soweit besser beschrieben?
Gruß

Ja das hast du. Vielen Dank.
Aber ich sehe nun auch das ich es richtig verstanden habe, das Problem lag eher an der Darstellung, also um welches format es sich hier handelt und deshlab kam es die ganze zeit nur zu Fehlern.

Aber ich danke dir trotzdem für diesen Beitrag, vll hilft er noch jmd anderem

Gruß Atilla