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!
Hi,
ich habe folgendes Problem: ich möchte ein Event zeitgesteuert ausführen. Dafür benutze ich derzeit die property node val(sgnl). Eigentlich funktioniert das soweit. Nun habe ich aber an mehreren Stellen gelesen, dass property nodes langsam sind und dass die property node val(sgnl) generell vermieden werden soll. In der Tat läuft mein Programm über lange Zeit nicht stabil (die Events werden zwischendurch mal nicht ausgeführt) und ich denke, dass die Art meiner Programmierung daran Schuld ist. Leider weiß ich nicht so recht, wie ich das Problem anders angehen soll.
Im Anhang findet ihr ein Minimalbeispiel für das Problem. Der Benutzer soll die 'Ausgabe' über die 'Eingabe' ändern können. Wird die Zeitsteuerung über 'Start' aktiviert, so sollen sich sowohl 'Eingabe', als auch 'Ausgabe' ändern.
Kann mir jemand einen Rat geben, wie ich das anders machen kann? Die grundlegende Struktur, dass sich 'Ausgabe' über 'Eingabe' ändert sollte beibehalten werden!
Vielen Dank, das hat mir weitergeholfen. Kannte Dynamic Event vorher noch nicht! Habe mein Minimalbeispiel jetzt soweit, dass es das tut, was ich möchte, ohne Property nodes zu benutzen.
Kann man die User Events auch anders weitergeben, als über direkte Verbindungen? Am Eingang des "User Event Create" habe ich jetzt meine Eingabe angegeben. Dabei ist ja aber nur ein Dateityp verlangt oder? Dieser wird aber später gar nicht mehr verwendet. Wofür braucht man diesen Dateityp? So ganz bin ich da noch nicht durchgestiegen. Ich habe probiert aus dem "User event out" einen Indicator zu machen und diesen dann an das "User Greate Event" anzuschließen, doch leider gibt LabVIEW dann beim Ausführen dieses "User Greate Event" eine Fehlermeldung aus (An input parameter is invalid).
(27.07.2011 18:49 )Puma schrieb: Am Eingang des "User Event Create" habe ich jetzt meine Eingabe angegeben. Dabei ist ja aber nur ein Dateityp verlangt oder? Dieser wird aber später gar nicht mehr verwendet. Wofür braucht man diesen Dateityp? So ganz bin ich da noch nicht durchgestiegen.
Habe mal dein Beispiel umgeschrieben, um dir zu verdeutlichen, wie das Ganze funktioniert:
Über den Eingang am "User Event Create" legst du sowohl den Datentyp fest, also auch über das Label den Namen des Events. Wenn du nun dieses Event alleine in einem Eventcase aufrufst, kannst du direkt über den Name den neuen Wert benutzen.
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Hmm... hier wird ja angesprochen, dass man val(sgnl) eventuell vermeiden sollte. Was genau ist dabei das Problem?
Ich habe aktuell eine Kommunikation zweier Rechner über TCP / IP realisiert (auf beiden Rechnern sollen möglichst auch verschiedene Labview Versionen laufen können, deswegen habe ich mich gegen shared Variables entschieden). Werteänderungen an einem Rechner frage ich dabei generell über das value Change Event ab, da ich ungern laufend 10 - 20 Variablen auf Wertänderung pollen möchte. Da allerdings einer der Rechner über den anderen Ferngesteuert wird muss ich bei diesem val(sgnl) dafür verwenden. Nun ist mir aber selbst schon aufgefallen, dass das ganze manchmal instabil zu laufen scheint, allerdings hab ich auch erst meine Erste Version ans laufen gebracht...
Kann das grundsätzlich mit den val(sgnl) Eigenschaftsknoten zusammenhängen?
Wie gesagt, ich würde die extrem ungern ersetzen, da die einfach (vom Aufwand her) deutlich handlicher sind als das für jeden internen Schreibvorgang die Variable zum Beispiel über eine Queue gehen zu lassen um die Wertänderung direkt an den zweiten PC zu senden. Auch wollte ich das "ferngesteuerte" VI möglichst wenig umprogrammieren (ist nicht von mir sondern von nem Kollegen geschrieben worden und läuft - never change a running system).
Gruß Kiesch
P.S: Wie gesagt, ich brauch vor allem ne info um einschätzen zu können ob für meinen Zweck (ne intern erzeugte Wertänderung über nen event case "sofort" zu erfassen und weiterzusenden) ausreichend ist (vor allem ausreichend stabil, da das Programm später mehr oder weniger vollautomatisiert laufen soll und sich dabei nicht ständig aufhängen sollte).
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Anzeige
05.08.2011, 07:18 (Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2011 07:19 von rolfk.)
(01.08.2011 12:58 )Kiesch schrieb: Hmm... hier wird ja angesprochen, dass man val(sgnl) eventuell vermeiden sollte. Was genau ist dabei das Problem?
Alle UI Properties werden grundsätzlich im UI Thread ausgeführt. D.h. wenn Du ein val oder val(signal) Property in Deinem Programmcode ausführst, stellt LabVIEW den Code in eine Warteschleife um durch das Betreibssystem im Kontext des UI Threads aufgerufen zu werden. Nach dem dieser Code von Windows dann angekickt wurde (irgendwann us, ms oder was auch immer später) wird das ganze Spiel nochmals wiederholt, diesmal um den Codeteil wieder zum ursprünglichen Thread switchen zu lassen. Das daaaaaaaaaaaaaauert extrem lang im Verhältnis was normaler LabVIEW Code in der selben Zeit macht.
Wenn solche Properties in Deiner UI Ahandlungsschlaufe sind, wo Du auf Usereingaben reagierst, und zum Beispiel ein weiteres Even ankicken willst wenn ein davon abhängiges Userelement durch den Benützer manipuliert wurde, ist das absolut kein Problem. Die Threadcontextswitches sind unzählige Male schneller dann der meist geavanceerde Kungfu Kämpfer jemals Userelement anklicken kann.
Wenn Du dasselbe aber in Programmlogik in Deiner Applikation machst kann das einen grossen Einfluss auf die Reaktionszeit dieses Codeteiles haben. Oder noch schöner ein Property in einer langen Schlaufe. Einmal ein paar ms Threadswitchkontext ist kaum merkbar aber wenn das jedesmal in einer Schlaufe gemacht wird die 1'000'0000 mal ausgeführt wird macht das einen riesigen Unterschied. Ohne Propertynode läuft die Schleife meist in einigen 100ms durch. Mit Propertynode dauert es schnell mal 1 Minute oder mehr.
Das heist es würde sich in meinem Fall vermutlich lohnen das ganze auf Queues umzustellen die dann gleich vor Ort den zu versendenden Befehl generieren bzw. die Sendeschleife bedienen (direkt versenden wäre natürlich sicher schneller, aber auch deutlich mehr aufwand als das nur an die Sendeschleife weiterzureichen). Das sollte ja dann deutlich schneller sein (?).
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
