HI Leute.
Es ist zwar vieles hier über Eigenschaftsknoten und Referenzen geshcrieben, jedoch habe ich keine Erklärung gefunden, was eigentlich besser ist. Ich schreibe ein Programm in LabView und benutze Produser/Consumer Event based Design dabei. 3 Schleifen: 1. - Events/Producer for Consumer, 2. - Consumer/Producer for Display, 3. - Display ... 1. und 2. bzw. 2. und 3. sind über 2 vershciedene Queue synchronisiert... Natürlich noch ein Haufen von SubVi ..
Situation:
Ich schreibe in der 2. schleife(Consumer/Producer fpr Display) Befehle für 3. (Display) ... In einem SubVi wird in Queue ein Cluster aus dem Befehl + Variant geschrieben. Variant besteht meistens aus Referenz einer der Controls + Wert ( Entweder für Werteingabe oder Aktiviert/Deaktiviert). Also in der Schleife Display passiert folgendes: Variant nach Cluster, Cluster aufschlüsseln , Eingänge an Eigenschaftsknoten, Referenz schließen ... Ich konnte aber nur den Befehl in die Queue schreiben, Eigenschaftsknoten ohne Referenz von dem Control direkt erstellen und dann in der 3. Schlefe diese Eigenschaftsknoten verwenden.
Meine Gedanke:
warum ich mich für die Lösung mit Referenzen entschieden habe.
1. Da ist schon was generisches drin ( mag ich ja)
2. Angst von Raice Condition.
Frage:
Performanz!!!??? .. Ich bin mir nicht sicher , ob ich vielleicht mit direkt erzeugten Eigenschaftsknoten etwas bessere Performanz haben werde...
Hallo aljasik,
ich würde einen Schritt weiter gehen und statt irgendwelcher Referenzen nur Namen/Befehle per Queue versenden!
Um das ganze Konstrukt noch generischer zu machen, sollte der Producer keinen direkten Bezug zum Consumer haben. Solbald du aber Referenzen benutzt, muss der Producer wissen, wie der Consumer aussieht! Entweder verschickst du einen Cluster [Befehl(-Enum), Wert] oder [Befehl, Label, Wert] - und der Consumer entscheidet dann, was mit dem Wert zu tun ist: Wert in einem Graph oder einfachen Indicator darstellen, speichern, etc.
Das Problem mit den Eigenschaftsknoten ist, dass sie verhältnismäßig langsam abgearbeitet werden. Und du musst bei deiner Lösung erst einmal alle Referenzen einsammeln, bevor du sie im Producer verwenden kannst.
(15.08.2014 11:40 )GerdW schrieb: [ -> ]..
Das Problem mit den Eigenschaftsknoten ist, dass sie verhältnismäßig langsam abgearbeitet werden. Und du musst bei deiner Lösung erst einmal alle Referenzen einsammeln, bevor du sie im Producer verwenden kannst.
mit dem einsammeln hast du schon recht. Hat mir aber sehr gefahlen im Consummer mit for-schleifen zu arbeiten.. nach Label die Controls zu unterscheiden habe ich noch nicht versucht.. wird es aber dann nicht so, dass das Program gesamte Frontpanel nach einen einzigen Control durchsucht? ... Eigenschaftsknoten brauche ich sowieso, bloss wenn ich die direkt von dem Control holle und dann Befehl für jeden schreibe, kann ich nicht mehr nur einen case für alle benutzen, sondern für jeder Befehl einen neuen Schreiben ... ??? ..
Ich werde mit den labels versuchen...
Danke!
Hallo aljasik,
Zitat:Eigenschaftsknoten brauche ich sowieso…
Ich persönlich halte wenig davon, im Producer schon Werte für einen bestimmten Indicator zu versenden. Ich löse das mit einem Datenpuffer, der Werte zu bestimmten Labels verwaltet. Jeder Consumer kann von dort Werte abholen und darstellen, jeder Producer kann dort Werte ablegen. Per Queue werden nur Befehle (mit ihren Parametern) versendet - aber nicht die Aufforderung, einen bestimmten Wert in einem bestimmten Indicator darzustellen! Wie oben gesagt: ich trenne da lieber den Producer vom Consumer, keiner von beiden muss wissen, wie der jeweils andere aussieht. Ohne Eigenschaftsknoten komme ich dabei auch nicht aus, aber ich muss keine expliziten Referenzen umherschicken. Ist meine persönliche Meinung und kein Zwang in deine Richtung.
Zitat:nach Label die Controls zu unterscheiden habe ich noch nicht versucht.. wird es aber dann nicht so, dass das Program gesamte Frontpanel nach einen einzigen Control durchsucht?
Das Durchsuchen des FP macht man nur einmal und nicht jedesmal erneut!
Durch die Unabhängigkeit von Referenzen ermöglichst du einen weiteren Aspekt: du kannst verschiedene Indikator-Typen (numerisch, bool, Array, Graph, Chart, etc.) verwenden/unterstützen…
Nur so als Hinweis: Man könnte Dir hier noch viel effektiver helfen, wenn Du dich überwinden könntest, das (oder die) Vis zu posten.
(16.08.2014 08:36 )Lucki schrieb: [ -> ]Nur so als Hinweis: Man könnte Dir hier noch viel effektiver helfen, wenn Du dich überwinden könntest, das (oder die) Vis zu posten.
Sorry, es würde aber viel zu vile zum Anhängen..
Da ist auf die schnelle gebasteltes Beispiel dazu...im debbuger modus nur benutzbar..
Hallo aljasik,
ich verstehe den Sinn deines Beispiels nicht…
Im ersten Producer (Eventstruktur) wertest du Control-Events aus und im letzten Consumer werden eben diese Controls (per Referenz/PropertyNode) wieder neu gesetzt!?
Nochmal:
Ein Producer erzeugt Befehle, die ein (oder mehrere kaskadierte) Consumer verarbeiten. Ich halte überhaupt nichts davon, im ersten Consumer Referenzen zu verschicken. (Wenn überhaupt: Warum nicht schon in der Event-Struktur? Dort bekommst du doch die Referenzen frei Haus geliefert!)
Ich bleibe dabei:
Verschicke Kommandos mit Parameter an deinen Display-Consumer und nur dieser kümmert sich um die Darstellung der Werte in den Controls/Indicators. Es werden dafür überhaupt keine Referenzen benötigt…
(17.08.2014 12:31 )GerdW schrieb: [ -> ]Hallo aljasik,
ich verstehe den Sinn deines Beispiels nicht…
Im ersten Producer (Eventstruktur) wertest du Control-Events aus und im letzten Consumer werden eben diese Controls (per Referenz/PropertyNode) wieder neu gesetzt!?
Beispiel diente nur um den Veraluf zu verdeutlichen. Es gibt keinen Sinn drin
(17.08.2014 12:31 )GerdW schrieb: [ -> ]Nochmal:
Ein Producer erzeugt Befehle, die ein (oder mehrere kaskadierte) Consumer verarbeiten. Ich halte überhaupt nichts davon, im ersten Consumer Referenzen zu verschicken. (Wenn überhaupt: Warum nicht schon in der Event-Struktur? Dort bekommst du doch die Referenzen frei Haus geliefert!)
In meinem Programm werden die Referenzen tatsächlich schon im Event Struktur als Variant mit dem Befehl versendet und im Consumer weiter geschoben. Dadurch wird im Display nur ein Case für alle Controls benötigt.
(17.08.2014 12:31 )GerdW schrieb: [ -> ]Ich bleibe dabei:
Verschicke Kommandos mit Parameter an deinen Display-Consumer und nur dieser kümmert sich um die Darstellung der Werte in den Controls/Indicators. Es werden dafür überhaupt keine Referenzen benötigt…
Ich weiß es nicht, wie ich das ohne Referenzen ellegant lösen konnte, ausser für jeden Control einen Case zu schreiben " Update Alice" , "Update Bobb" , "Update Ceaser" ...
Ich habe mich nicht in das VI vertieft, aber viellelcht doch dieser Rat:
Referenzen brauchst Du nicht. Mache aus den Queuelementen Cluster und transportiere die Daten mit in der Queue. In der unteren Queue hast Du ja so etwas in dieser Art gemacht, warum nicht auch in der oberen.