private Daten lesen und schreiben in separaten VI's

Hallo,

ich finde keine Loesung fuer mein Problem, aber ich denke, dass ich etwas nicht verstanden habe.

Ich wuerde gerne eventbasierend die privaten Daten einer Klasse aendern, sie aber dauerhaft auslesen (bzw intervallsmaessig).
Wie in dem VI zu sehen, liesst die obere Schleife die Daten aus, was auch funktioniert.
Wenn ich jetzt aber durch ein erzeugtes Event Daten in den Privaten bereich der Klasse schreiben will, werden sie nicht veraendert.

Muss ich den Ausgang der unteren Methode in eine Art Shift-Register fuehren?
Ich habe leider keine Idee wie ich das verwirklichen soll.
Bitte um Ratschlaege


Gruesse,
Metzlmane

Hi
LabVIEW Objekte verhalten sich genauso wie alle anderen elementaren LabVIEW Datentypen: Sie folgen dem Datenflusskonzept. An Drahtabzweigen werden Duplikate erzeugt.

LabVIEW Objekte sind keine Entitäten wie in in anderen konventionellen OO-Programmiersprachen.

In dem LVOOP Bereich dieses Forums gibt es aber viele Links zu diesem Thema.

Gruß Holger

Ok, vielen Dank. So in etwas dachte ich mir schon.
Ich werde es mal mit der Methode versuchen:
Abrissbirne

Theoretisch sollte es funktionieren, wenn du dir eine Referenz auf das Objekt holst und über die Referenz schreibst / liest (soweit ich gelesen habe geht das seit LV2009 (?)). Dann sollte das funktionieren.

Gruß Kiesch

Hi Kiesch
Das widerspricht aber dem Datenfluss-Paradigma von LabVIEW und birgt die Gefahr von Daedlocks in komplizierteren Situationen. Die Referenzen auf LabVIEW Daten sollte man mit Vorsicht geniessen.

Besser: Referenz-Muster. (LabVIEW Examples->Fundamentals->Object-Oriented->ReferenceObject.lvproj) Das basiert im wesentlichen auf einer Queue der Größe 1, die also nur genau ein LabVIEW-Objekt aufnehmen kann. Das Queue-Referenz Objekt kann beliebig geklont werden. Das eigentliche LabVIEW-Objekt kann aber immer nur ein Thread haben, wechselseitiger Ausschluss.

Gruß Holger

Die Referenz wäre halt nur das einfachst zu realisierende - mit Datenfluss kann man nunmal nicht alles machen - auch wenn er zu bevorzugen ist so lange haltbar.

Ansonsten könnte man auch das Objekt in einer FGV Speichern und diese mit einer Sperrarchitektur ausstatten. (Sperren bei Lesen (falls nötig; unterschieden nach Lese- und Schreibsperre), Entsperren und Rückspeichern nach Verarbeitung - und sei es auch nur ein get irgendwas (potentiell kann da ja eine Berechnung dahinter stecken - also sollte auf jeden Fall vermieden werden, dass zwei Prozeduren gleichzeitig auf das Objekt zugreifen können).

Potentiell bräuchte man außerdem ne Warteschlage in der FGV (wer wann zum Zug kommen darf, um das nicht dem Zufall zu überlassen; hängt aber ganz davon ab wie wahrscheinlich es überhaupt ist, dass zwei Zugriffe gleichzeitig stattfinden - passiert das potentiell fast immer braucht man das, passiert das nur in 1% der fälle macht das nur sinnlos overhead und wird durch den "Zufall" auch hinreichend gut geregelt.

Gruß Kiesch

Anzeige

(21.12.2011 12:01 )Kiesch schrieb:  Die Referenz wäre halt nur das einfachst zu realisierende - mit Datenfluss kann man nunmal nicht alles machen - auch wenn er zu bevorzugen ist so lange haltbar.

Ansonsten könnte man auch das Objekt in einer FGV Speichern und diese mit einer Sperrarchitektur ausstatten. (Sperren bei Lesen (falls nötig; unterschieden nach Lese- und Schreibsperre), Entsperren und Rückspeichern nach Verarbeitung - und sei es auch nur ein get irgendwas (potentiell kann da ja eine Berechnung dahinter stecken - also sollte auf jeden Fall vermieden werden, dass zwei Prozeduren gleichzeitig auf das Objekt zugreifen können).

Potentiell bräuchte man außerdem ne Warteschlage in der FGV (wer wann zum Zug kommen darf, um das nicht dem Zufall zu überlassen; hängt aber ganz davon ab wie wahrscheinlich es überhaupt ist, dass zwei Zugriffe gleichzeitig stattfinden - passiert das potentiell fast immer braucht man das, passiert das nur in 1% der fälle macht das nur sinnlos overhead und wird durch den "Zufall" auch hinreichend gut geregelt.

Gruß Kiesch

Oder einfach wie Holger sagt das Reference Pattern benutzen (LabVIEW Examples->Fundamentals->Object-Oriented->ReferenceObject.lvproj).

(21.12.2011 13:59 )abrissbirne schrieb:  Oder einfach wie Holger sagt das Reference Pattern benutzen (LabVIEW Examples->Fundamentals->Object-Oriented->ReferenceObject.lvproj).

Genau so mache ich es jetzt und es funktioniert wunderbar.
Auf die Idee ware ich bei Weitem nicht gekommen..