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!
Ich nutze eine Wrapper-DLL um eine DLL einzubinden.
Die DLL hat internen Speicher und der Wrapper kopiert diesen in meine LV Anwendung.
Für diesen Speicher habe ich ein Byte Array angelegt, dass klappt auch soweit.
Wenn ich das kopieren nach jeder Änderung selber per Hand anstroße ist auch alles Ok.
Nur soll die Wrapper-DLL dies selbständig in allen Funktionen die es benötigen ausführen.
Ich möchte zudem das Array als lokale Variable in die entsprechenden Sequenzstrukturen einbinden.
Nur kommen dann die geänderten daten dort nicht an.
Wenn ich dies mittels einer langen Verbindung mache, funktioniert dies.
Was passiert da in LAbView?
Bekommt LV die Speicheränderung nicht mit und aktualisiert die localen Variablen nicht?
Ich dachte aber die verweisen direkt auf das eigentliche Element.
"Bekommt LV die Speicheränderung nicht mit und aktualisiert die localen Variablen nicht? Ich dachte aber die verweisen direkt auf das eigentliche Element."
Ganz allgemein zu lokalen Variablen: die verweisen nicht auf das FP-Element, sondern legen eine Kopie an! Dies ist einer der (Haupt-)Gründe, die gegen die Verwendung von lokalen Variablen in LabVIEW sprechen. Daten werden in Drähten gespeichert!
Zu Fragen bzgl. der DLL-Nutzung/-Programmierung verweise ich lieber an RolfK...
Das Management eines Controls (Ein/Ausgabe-Element) ist selbstverständlich konsistent. Das Problem mit Lokalen Variablen ist aber: Extrem anfällig für Raceconditions. In deinem Fall könnten Raceconditions auftreten.
' schrieb:Für diesen Speicher habe ich ein Byte Array angelegt, dass klappt auch soweit.
Wo? In LabVIEW?
Heißt das, du hast einen Pointer auf dieses LV-Array in deine DLL übergeben, sodass die DLL in der Lage wäre, kontinuierlich in dieses Bytearray zu schreiben? - Das könnte große Probleme machen.
Zitat:Wenn ich das kopieren nach jeder Änderung selber per Hand anstroße ist auch alles Ok.
"Manuell" bewirkt immer, dass beim Schreiben in eine lokale Variable alle anderen lokalen Variablen automatisch refreshed werden. Siehe die Kopie, die GerdW erwähnt hat.
Zitat:Nur soll die Wrapper-DLL dies selbständig in allen Funktionen die es benötigen ausführen.
Arbeitet die im Hintergrund, also als eigenständiger Thread (Loop) oder wird die immer im Datenfluss abgearbeitet und kopiert lediglich die Daten so nebenbei?
Zitat:Was passiert da in LAbView?
Wenn du einen Pointer auf einen Lokale Variable übergibst, schreibst du lediglich in einen Puffer - das ganze Mnagement, das notwendig ist alle Lokalen Variablen und das FP zu refreshen findet nicht statt.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Das Management eines Controls (Ein/Ausgabe-Element) ist selbstverständlich konsistent. Das Problem mit Lokalen Variablen ist aber: Extrem anfällig für Raceconditions. In deinem Fall könnten Raceconditions auftreten.
Wo? In LabVIEW?
Heißt das, du hast einen Pointer auf dieses LV-Array in deine DLL übergeben, sodass die DLL in der Lage wäre, kontinuierlich in dieses Bytearray zu schreiben? - Das könnte große Probleme machen.
genau.
Allerdings weiß ich, wann sie es macht.
' schrieb:"Manuell" bewirkt immer, dass beim Schreiben in eine lokale Variable alle anderen lokalen Variablen automatisch refreshed werden. Siehe die Kopie, die GerdW erwähnt hat.
Ok.
' schrieb:Arbeitet die im Hintergrund, also als eigenständiger Thread (Loop) oder wird die immer im Datenfluss abgearbeitet und kopiert lediglich die Daten so nebenbei?
Nein, das ganze ist im Moment eine einzige sequazielle Sequenz.
' schrieb:Wenn du einen Pointer auf einen Lokale Variable übergibst, schreibst du lediglich in einen Puffer - das ganze Mnagement, das notwendig ist alle Lokalen Variablen und das FP zu refreshen findet nicht statt.
Also muss ich kurz zusammengefasst immer Dräte ziehen.
Oder ich mache das "kopieren in der DLL" offizielle, also übergebe den Pointer mit.
Dann kann ich lokale Variablen an den Pointer anlegen.
"Oder ich mache das "kopieren in der DLL" offizielle, also übergebe den Pointer mit. Dann kann ich lokale Variablen an den Pointer anlegen."
Bin mal gespannt, wie du den Pointer auf den Datenbereich der lokalen Variablen herausfinden willst...
Nochmal: LabVIEW verwaltet Daten in Drähten. Also nimm auch Drähte zum Weiterreichen von Daten... Lokale Variablen sind (fast) immer Krücken, die man nicht braucht!
' schrieb:Also muss ich kurz zusammengefasst immer Dräte ziehen.
Letztendlich ja. Auch der Pointer wäre ein Draht - notgedrungen.
Du kannst dir hier hier mal mein DLL-Tutorial ankucken. Da gibt es ein Programm TestDLL_, da wird in einer DLL auf ein FP-Element geschrieben. Möglicherweise kannst du, aber eben nur mit einigen Tricks, es so hinbekommen wie du willst.
[*nachdenk*]
Wenn du den DLL-Knoten sowieso kontinuierlich aufrufst, würde ich die Methode mit den expliziten Ausgang (also den Draht) aber vorziehen. Nur wenn die DLL im Hintergrund läuft und die Daten quasi wie ein Callback versenden werden soll, würde sich der Aufwand lohnen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
ich baue mir ein Array, darin werden dann 16 Cluster gespeichert.
Einen gleichgroßen Speicher hat die DLL intern.
Da ich da mit LabView (doppelpointer) nicht ran komme, gibt es in der Wrapper DLL eine Kopierfunktion.
Diese bekommt nun das Array aus Labview und kopiert den DLL Speicher da hinein.
Ich rufe eine Funktion die den DLL-Speicher befüllt auf.
Dann lasse ich mit der Kopierfunktion den DLL-Speicher in den LabView-Speicher kopieren.
Dann rufe ich zwei weitere Funktionen auf, die den DLL-Speicher verändern und den DDL-Speicher selber in den LabView Speicher kopieren.
Davon bekommt LabView aber nichts mit.
Wie kann ich das Labview Mitteilen?
Oder muss ich dann wieder die Kopierfunktion in Labview Aufrufen?
Ich wollte mir nun einen Schleife machen, die mir den ersten Cluster des Speichers kontinuierlich anzeigt.
Wie kann ich das nun sinnvoll verbinden?
Stefan
16.08.2010, 14:16 (Dieser Beitrag wurde zuletzt bearbeitet: 16.08.2010 14:18 von IchSelbst.)
' schrieb:Dann rufe ich zwei weitere Funktionen auf, die den DLL-Speicher verändern und den DDL-Speicher selber in den LabView Speicher kopieren.
Davon bekommt LabView aber nichts mit.
Dieses Vorgehen finde ich gut.
Zitat:Wie kann ich das Labview Mitteilen?
Vergleiche auch Bild.
Im DLL-Knoten wird der Pointer auf den Ausgangsdraht gespeichert. Der Ausgangsdraht referenziert einen Speicher. Solange der Ausgangsdraht besteht, kann man über den Pointer Daten in den Draht schreiben. Der Draht entspricht dem Tunnel auf der While-Schleife. Da der Tunnel permanent ist, ist es auch der Speicher, auf den der Pointer zeigt. (Man beachte, dass die Sache auch mit einem Schieberegister funktioniert.)
Da die While-Schleife ständig läuft, wird der Wert des Tunnels ständig in das FP-Element geschrieben.
Der im Bild dargestellt DLL-Knoten muss nur ein einziges Mal aufgerufen werden. Der entsprechende Pointer wird DLL-intern gespeichert und steht allen anderen DLL-Funktionen (DLL-Knoten) zur Verfügung.
Jeder andere DLL-Knoten kann jetzt also mittels dieses Pointers in den Tunnel und folgedessen in das FP-Element schreiben. In meinem Muster läuft in der DLL ein Hintergrund-Thread, der kontinuierlich den Tunnel refreshed.
Zitat:Ich wollte mir nun einen Schleife machen, die mir den ersten Cluster des Speichers kontinuierlich anzeigt.
Das wäre ja genau das, was ich in meinem Muster gemacht habe.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
, da wird in einer DLL auf ein FP-Element geschrieben. Möglicherweise kannst du, aber eben nur mit einigen Tricks, es so hinbekommen wie du willst.