Werte aus Sub VI im Haupt VI anzeigen

<div align="left">Hallo Achim,

Zitat:@ Stefan:
Irgendwie hab ich's nicht geblickt! Was bringt die Verdrahtung ins SubVÌ?

Dort wird die Referenz (Adresse) des Kontroll- bzw. Anzeigeinstruments der MainVI übergeben. Damit die zu repräsentierenden Werte aus der SubVI in den gewünschten Speicherbereich geschrieben werden können. (Ist analog zur Zeigerübergabe bei einem Funktionsaufruf in C. Die Funktion muss wissen, auf welchem Speicherbereich sie arbeiten soll!)

Zitat:Wenn im SubVI die Schleife läuft, wird das HauptVI, welches das SubVI enthält, auf jeden Fall so lange angehalten, bis das SubVI beendet ist. D.h. es werden vom HauptVI keine Eingaben ins SubVI übernommen!

Nicht ganz... es gibt da noch eine Waitfunktion von 500ms die auch der MainVI Prozessorzeit erlaubt. allerdings wird davon im Hauptprogramm kein Gebrauch gemacht ...
Die Referenzen, die mit der SubVI verdrahtet sind, werden beim Programmstart bzw. dem ersten Aufruf der SubVI übergeben. Sonst würden wir die Ergebnisse nicht auf der Anzeige der MainVI sehen! Danach läuft die Schleife alle 500ms.

Zitat:Kleiner Tip: Wenn du die Referenz des "stop from mainVI" mit gedrückter Strg-Taste vom Blockdiagramm des HauptVI aufs Frontpanel des SubIV ziehst, erhälst du eine "strict refnum" (sichtbar am Sternchen auf dem FP) und du kannst dir die "Variant to Data"-Wandlung sparen!

Danke für den Tip, allerdings ändert das in diesem Fall nichts an unserem Problem, da mit dieser Drag&Drop-Operation auch gleichzeitig ein neues Bedienelement erzeugt wird und somit auch eine neue Referenz. ...Und man sieht wieder nichts im Anzeigeinstrument der MainVI!
Die Typkonvertierung ist also zwingend. Zumindest bei dieser Variante. Vielleicht gibt es noch weitere, aber so geht es nicht.

Frage: Wie soll man ohne einen Zeiger auf den Speicherbereich des Anzeigeinstruments der MainVI aus einer SubVI heraus direkt Ergebnisse dort anzeigen!?

Anbei das Programm mit den erläuterten Änderungen.

Grüße,
Stefan


  MainVI.vi (Größe: 10,2 KB / Downloads: 371)


  SubVI.vi (Größe: 14,18 KB / Downloads: 361)
</div>

Anzeige

Hier die Variante mit Melder, ist denke ich am einfachsten.
Stop: Wenn das Haup-VI gestoppt wird, wird der Melder freigegeben und zerstört. Dadurch gibt es eine Fehlermeldung im Sub-VI, die hier zum Programmabbruch auch des Sub-VIs führt.
Wichtig: Am Sub-VI dürfen im Haupt-Vi keine Ausgänge angeschlossen sein, da sonst das Haupt-VI auf diese Daten warten würde. Hier ist das Sub-VI völlig "freischwebend". Wichtig ist auch, daß man sich beim Meldernamen nicht verschreibt, etwas "Test" im Haupt-VI und "Tesst" im Sub-VI.
   

Hi zusammmen...

@Stefan:
War wohl ein Missverständnis...rein technisch (Referenzen etc.) hab ich's natürlich geblickt, allerdings hast du's ja genauso gemacht (machen müssen!) wie ich schon gesagt habe: Das SubVI muss parallel zur Hauptschleife laufen, ob die Parallel-Schleife jetzt im SubVI läuft, oder ob ne Schleife um das SubVI ist, ist ja mal egal...wenn sie außenrum läuft, find ichs allerdings wesentlich nachvollziehbarer!

Beim Drag@Drop entsteht natürlich ein neues Bedienelement, ist ja auch beabsichtigt ("Drop")! Dann schmeißt man das "alte" raus und schon erspart man sich die Typkonvertierung! Wenn du deine Variante anwendest, dann solltest du sie so abändern:


  MainVI_NEU.vi (Größe: 10,31 KB / Downloads: 503)

  SubVI_NEU.vi (Größe: 11,34 KB / Downloads: 448)




@Myjestic:
Ich hab hier mal nen Dummy-"Regler" in ne Statemachine eingebaut (Var. XX wird einfach immer inkrementiert), man kann ihn stoppen/starten (inkl. Reset)...und du sparst die Verdrahtung deiner Werte nach außen, d.h. du musst außen kein Schieberegister mitschleifen, weil das intern im "Regler" passiert! Wenn du noch Fragen hast, meld dich...


  regler.zip (Größe: 29,42 KB / Downloads: 335)




@Lucki:
Damit du die evtl. Schreibfehler vermeiden kannst, könntest du statt nem Notifier/Melder auch ne Queue mit nur einem möglichen Element erstellen. An die kannst du nämlich seit LV6 jeden beliebigen Datentyp anschließen (nicht nur Strings wie früher, bzw. wie beim Notifier). Dann schließt du eine Enum-Element (als strikte Typdefninition) an, und kannst dann nur noch zulässige Werte in den "Ersatz-Notifier" schreiben (am einfachsten mit "Create Contant"), siehe folgendes Bild! Allerdings muss natürlich der Name der Queue an allen "Abfragestellen" (genau wie beim Notifier) richtig geschrieben werden. Das kann man aber in beiden Fälllen mit ner globalen/lokalen Variable umgehen, siehe ebenfalls dass Bild!



   

Gruss
Achim

' schrieb:@Lucki:
Damit du die evtl. Schreibfehler vermeiden kannst, könntest du statt nem Notifier/Melder auch ne Queue mit nur einem möglichen Element erstellen. An die kannst du nämlich seit LV6 jeden beliebigen Datentyp anschließen (nicht nur Strings wie früher, bzw. wie beim Notifier). Dann schließt du eine Enum-Element (als strikte Typdefninition) an, und kannst dann nur noch zulässige Werte in den "Ersatz-Notifier" schreiben (am einfachsten mit "Create Contant"), siehe folgendes Bild! Allerdings muss natürlich der Name der Queue an allen "Abfragestellen" (genau wie beim Notifier) richtig geschrieben werden. Das kann man aber in beiden Fälllen mit ner globalen/lokalen Variable umgehen, siehe ebenfalls dass Bild!

Kenne zwar LV schon seit der V6, aber leider habe ich Melder (Identifiers) und Queues erst in der Version 8 für mich entdeckt - dem LVF seis gedankt.
Ich weiß jetzt also nicht, wie es in den Vorversionen war, aber für LV8 kann ich sagen: Melder und Queues sind bezüglich der Datentypen völlig identisch, man kann jeden Datentyp, den man mit einer Queue übertragen kann, genau so mit einem Melder übertragen. Auch die gesamte Funktionspalette für Melder und Queue ist weitgehend identisch (oder besser, weil Queues komplexer sind: Die Funktionen für Melder sind eine Untermenge der Queue-Funktionen). Deshalb würde ich sagen, daß wegen der größeren Einfachheit Melder in jedem Fall die bessere Alternative zu Queues mit Warteschlangenlänge 1 sind. Ich würde sogar so weit gehen zu sagen, daß in den meisten Fällen, in denen hier im LVF eine Queue empfohlen wurde, ein Melder die bessere Empfehlung gewesen wäre, weil es fast immer nur um die Kommunikation zwischen VIs geht, nicht aber darum, zwischen Sender und Empfänger außerdem noch eine Warteschlenge aufzubauen. Aber jetzt geht mir ein Licht auf, die Vorliebe für Queues hat also ihre historischen Wurzelen, weil früher in bezug auf die Datentypen Melder nicht so viel konnten wie Queues.

Zum Thema Schreibfehler: Ich wollte nur zeigen, daß die Kommunikaition sogar dann funktioniert, wenn das SUB-VI im Haupt-Vi überhaupt nicht angeschlossen ist. Für besser halte ich es, wenn das Su-VI einen Eingang hat, dann gibt es auch keine Schreibfehler mehr - und außerdem ist es einfacher.
   

@Lucki:
Ups, ich dachte mit Meldern gehen nur Strings...das hat mich eh schon immer gewundert...dass die Queues aufgebohrt werden, die Notifiers aber nicht...ansonsten: Gut gebrüllt, Löwe!

A.

@Achim
Danke für die Blumen. Retour: es könntest sogar Du gewesen sein, dem ich die ersten Hinweise auf die Nützlichkeit von Queues überhaupt verdanke.
Hänge mal noch die VIs hier an

Anzeige

Hi,

den Hinweis auf die Queues/Notifiers hast du bestimmt von eugen graf, der ist da scheinbar ganz wild drauf ;-)

A.

@Achim

Ich glaube auch... danke für den Hinweis. So entwickelt man sich weiter...
So geht es!

Schöne Grüße,
Stefan

' schrieb:Hi,

den Hinweis auf die Queues/Notifiers hast du bestimmt von eugen graf, der ist da scheinbar ganz wild drauf ;-)

A.

EDIT Sorry, hab das Offtopic-Schild weggemacht. Es war wirklich ein Missverständnis

Ich verwende meistens Queues, weil ich den Datenverlust beim Loggen der Daten vermeiden will (es kann z.B. sein dass die Festplattemit der Frequenz der Daten nicht nachkommt).
Zum Anzeigen der Daten würde ich aber auf jeden Fall Notifiers verwenden.

@ eugen graf:
Was meinst du mit "OFF TOPIC" in diesem Zusammenhang? Ich bin mir ziemlich sicher, dass ich Lucki den Hinweis nicht gegeben hab...und da ich bei deinen posts schon mal davon gelesen hatte, bist du mir als evtl. "Hinweisgeber" halt gleich in den Sinn gekommen!

A.