Werte aus Sub VI im Haupt VI anzeigen

Ich hab das erst jetzt gelesen, weil in einem anderen Thread darauf verwiesen wurde und muss da (leider, ich hoffe zu verzeihst mir Lucki) da nochmal drauf eingehen:

<klugscheiss>

' schrieb: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

soweit stimme ich zu

' schrieb:(oder besser, weil Queues komplexer sind: Die Funktionen für Melder sind eine Untermenge der Queue-Funktionen).

falsch! Queues sind Queues und Notifyer sind Notifyer. Es sieht zwar ähnlich aus und man kann ähnliche Dinge damit anstellen, aber die beiden Systeme sind grundsätzlich verschieden! Ein Notifyer ist eine per se verlustbehaftete Möglichkeit Daten von einem Sender zu einem Empfänger zu übertragen. Wenn der Sender die Nachricht nicht rechtzeitig abholt kann diese von der darauffolgenden Nachricht überschrieben werden. Wenn man das an einem Beispiel festnageln möchte: Stell dir eine DruckerQ vor, die nicht als Q sondern als Notifyer angelegt ist. Diese wird immer nur das zuletzt abgeschickte Dokument drucken. Solange die Sender so langsam senden, dass alles zwischen zwei Sendungen erledigt werden kann, ist das kein Problem, aber sobald die Druckaufträge schneller gesendet werden als der Drucker drucken kann, gehen Druckaufträge verloren.

' schrieb: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.

Eine Q ist eine Warteschlange - analog zu einem First In First Out Puffer. Die Begrenzung der Anzahl der Elemente in einer Q hat den Hintergrund, dass man beim SENDER durch die entsprechende Fehlermeldung darauf hingewiesen werden kann, dass die Q voll ist - und dann entsprechend Reagieren kann. Die Aussage, dass ein Notifyer für die Steuerung einer Statemachine mit Producer und Consumer Loop das Mittel der Wahl wäre ist somit falsch, weil ggf. - wenn die Consumer-Loop "zu lange" - braucht Aktionen (z.B. Klicks auf Buttons) verloren gehen.

' schrieb: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.

auch nicht. Die Vorliebe für Qs hat ihr Wurzeln darin, dass sie die einzig zuverlässige Methode zur zeitlich korrekten Abarbeitung von Events in einer Statemachine sind.

</klugscheiss>

Anzeige

Yeah Baby, yeah Baby, yeah!

Hossa...das war ja mal was! Nee, ohne Scheiß (!): Gut erklärt, wusste ich soooo auch nicht! Immer gut, wenn's ein bisschen Hintergrundinfo gibt!

Thanxalot!

A.

Ein kleiner Nachtrag zu dem Thema. Für die Queued State Machine, als auch für die Datenübertragung von einem VI zum anderen kann man auch Dynamische User Events verwenden. Die Daten landen zuerst in der Message Queue und alle "Event Strukturen", die es registriert haben werden über das Event benachrichtigt. Vorteil ist, man kann in einem Schritt Daten an alle Teilnehmer übertragen. Weiteres Vorteil ist, dass man die Events zur Laufzeit des Programms anmelden(registrieren) und abmelden kann. Noch ein Vorteil ist, dass man die Daten mit z.B. Front Panel Events "vermischen" kann. Dieses und weitere interessante Sachen will ich demnächst in meinem Tutorial vorstellen.

eg

P.S. kann mir bitte jemand sagen ab welcher LV Version die dynamischen User Events unterstützt sind? Ich glaube in LV 6.1 (für Linux) diese nicht gefunden zu haben.

' schrieb:Ich hab das erst jetzt gelesen, weil in einem anderen Thread darauf verwiesen wurde und muss da (leider, ich hoffe zu verzeihst mir Lucki) da nochmal drauf eingehen:

--Und ich lese das jetzt auch erst Monate später, nachdem Eugen jetzt etwas gepostet hat, wurde ich mit der Nase darauf gestoßen.
Die Hast ja in allem Recht, nur bleibe ich dabei, Queues nur dann zu verwenden, wenn es sinnvoll ist, und ansonsten Melder.
Die weitaus meisten Anwendungen sind Größenordnungen davon entfernt, zeitkritisch zu sein, das Warten auf neue Daten ist oft geradezu unendlich gegenüber der anschließenden Verarbeitungszeit. Bei solchen Anwendungen, bzw. ohne auf die Anwendung näher hinzuschauen, wegen der "Gefahr des Datenverlustes" immer wieder stereotyp vor Meldern zu warnen läuft dann wirklich auf "Klugscheiß" hinaus.

Im Übrigen hat ja man auch bei Meldern die Möglichkeit ein Fehlmeldung bei Datenverlust zu generieren, und andererseits gibt es bei Queues die Möglichkeit hat, bei Datenüberlauf keinen Fehler zu generieren.

Und wahr ist doch auch, daß nur früher die Melder zu recht so hießen, denn sie dienten nur zur Meldung über einen String, konnten aber selbst - außer in diesem String - keine Daten transportieren. Heute hat man sie aufgebohrt, eigentlich müßten sie umbenannt werden, denn sie leisten jetzt das Gleiche wie eine Queue mit der Länge 1. (Ja, ich weiß, das gibt es nicht, eine Queue sollte wenigsten 2 Elemente lang sein, aber zur Veranschaulichung was ein Melder leistet kann man es schon mal so sagen)

' schrieb:Die Hast ja in allem Recht, nur bleibe ich dabei, Queues nur dann zu verwenden, wenn es sinnvoll ist, und ansonsten Melder.

Ich mache es andersrum.

' schrieb:Die weitaus meisten Anwendungen sind Größenordnungen davon entfernt, zeitkritisch zu sein, das Warten auf neue Daten ist oft geradezu unendlich gegenüber der anschließenden Verarbeitungszeit. Bei solchen Anwendungen, bzw. ohne auf die Anwendung näher hinzuschauen, wegen der "Gefahr des Datenverlustes" immer wieder stereotyp vor Meldern zu warnen läuft dann wirklich auf "Klugscheiß" hinaus.

Gerade bei MSR ist es nicht so. Einfaches Beispiel ist Speichern der Daten auf die Festplatte. Wenn die Daten z.B. mit 100 Hz kommen und die Festplatte gerade beschäftigt ist, kann es zu einer Verzögerung kommen. Da hast du schon den Datenverlust. Ausserdem kann man aus der Queue alle Elemente auf ein Mal auslesen (mit Flush Queue).

' schrieb:Im Übrigen hat ja man auch bei Meldern die Möglichkeit ein Fehlmeldung bei Datenverlust zu generieren, und andererseits gibt es bei Queues die Möglichkeit hat, bei Datenüberlauf keinen Fehler zu generieren.

Wenn du mit einem Timeout die Daten in die übergelaufene Queue reinschreibst, bekommst du die Fehlermeldung. Ohne gesetzten Timeout wird der Sender solange warten bis Platz in der Queue frei ist.

' schrieb:Und wahr ist doch auch, daß nur früher die Melder zu recht so hießen, denn sie dienten nur zur Meldung über einen String, konnten aber selbst - außer in diesem String - keine Daten transportieren. Heute hat man sie aufgebohrt, eigentlich müßten sie umbenannt werden, denn sie leisten jetzt das Gleiche wie eine Queue mit der Länge 1. (Ja, ich weiß, das gibt es nicht, eine Queue sollte wenigsten 2 Elemente lang sein, aber zur Veranschaulichung was ein Melder leistet kann man es schon mal so sagen)

Alle meine Queues und Melder sind vom Typ String. Mit Flatten und Unflatten werden die Daten gepackt und entpackt. Vor den Nutzdaten schreibe ich noch den dazugehörigen Befehl, damit weiß der Empfänger, was er mit Daten machen muss und wie er diese entpacken soll.

eg

Und Queued State Machine kann nur mit Queue funktionieren, sonst hätte die einen anderen Namen. Wenn du hier einen Melder nimmst, und zwei States von zwei unterschiedlichen Stellen reinschreibst, wird das eine davon nicht ausgeführt, was zu einem kompletten Stop des Programms führen kann.

eg

Anzeige