+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: C# - LabVIEW (/Thread-C-LabVIEW)
C# - LabVIEW - th89 - 06.09.2013 13:19
Hallo zusammen,
im Folgenden habe ich ein LabVIEW 2012 Projekt angehängt, auf die sich meine
Problemschilderung bezieht.
Um eine Schnittstelle zwischen LabVIEW und einer anderen Programmiersprache
(z.B. C#) zu schaffen, möchte ich beliebige Funktionsabläufe in eine
dynamische Bibliothek exportieren. Im konkreten Fall möchte ich mit LabVIEW
permanent erzeugte Werte zu einem beliebigen Zeitpunkt durch einen
C#-Funktionsaufruf abfragen.
Mein bisheriger Ansatz:
• RT-FIFO Puffer mit gewünschten Werten befüllen (Pufferbefuellen.vi)
z.B. innerhalb einer Dauerschleife (while-Schleife)
• beispielhaft wird das für zyklisch erzeugte Zufalls-Werte (Schleife.vi) durchgespielt
• Funktionsaufruf der Dauerschleifen mittels „exportiertem“ C#-Funktionsaufruf (Steuerung.vi), um die Werte in den Puffer zu schreiben
• RT-FIFO mittels C#- Funktionsaufruf (readpuffer.vi) kann nun durch C# zu beliebigen Zeitpunkten abgefragt werden
Für die folgenden Punkte benötige ich Ihre Unterstützung:
• Gibt es effizientere Lösungen für derartige Abfragen von Werten in Schleifen außer dem RT-FIFO?
• Kann man den Funktionsaufruf von „Dauerschleifen“ einfacher gestalten?
• Existieren noch weitere mögliche Schnittstellen zwischen LabVIEW und anderen Programmiersprachen, außer einer aus LabVIEW erzeugten DLL?
LG
RE: C# - LabVIEW - rolfk - 06.09.2013 14:42
(06.09.2013 13:19 )th89 schrieb: Hallo zusammen,
im Folgenden habe ich ein LabVIEW 2012 Projekt angehängt, auf die sich meine
Problemschilderung bezieht.
Um eine Schnittstelle zwischen LabVIEW und einer anderen Programmiersprache
(z.B. C#) zu schaffen, möchte ich beliebige Funktionsabläufe in eine
dynamische Bibliothek exportieren. Im konkreten Fall möchte ich mit LabVIEW
permanent erzeugte Werte zu einem beliebigen Zeitpunkt durch einen
C#-Funktionsaufruf abfragen.
Mein bisheriger Ansatz:
• RT-FIFO Puffer mit gewünschten Werten befüllen (Pufferbefuellen.vi)
z.B. innerhalb einer Dauerschleife (while-Schleife)
• beispielhaft wird das für zyklisch erzeugte Zufalls-Werte (Schleife.vi) durchgespielt
• Funktionsaufruf der Dauerschleifen mittels „exportiertem“ C#-Funktionsaufruf (Steuerung.vi), um die Werte in den Puffer zu schreiben
• RT-FIFO mittels C#- Funktionsaufruf (readpuffer.vi) kann nun durch C# zu beliebigen Zeitpunkten abgefragt werden
Für die folgenden Punkte benötige ich Ihre Unterstützung:
• Gibt es effizientere Lösungen für derartige Abfragen von Werten in Schleifen außer dem RT-FIFO?
• Kann man den Funktionsaufruf von „Dauerschleifen“ einfacher gestalten?
• Existieren noch weitere mögliche Schnittstellen zwischen LabVIEW und anderen Programmiersprachen, außer einer aus LabVIEW erzeugten DLL?
LG
Die beschriebene Architektur scheint mir ziemlich komplex und eher unsinnig. Wenn du schon einen eigene Schleife machen willst die irgendwo selbständig läuft, ist es meist sinnvoller um das in einem eigen Programm zu machen und die Daten mittels Interprozessdatenaustausch zu übertragen. Dann brauchst Du nicht so komische Klimmzüge zu machen.
Ansonsten sollten Libraries soviel möglich ein synchrones Interface haben, d.h. keine Deamons die im Hintergrund gestartet werden und unkontrolliert Daten in eine Form von Globalen schreiben die dann asynchron wieder irgendwie, manchmal, vielleicht und ab und zu aus dem Programm abgerufen werden. Ich weiss dass es für viele verlockend ist um solche asynchronen Interfaces zu entwickeln aber in den meisten Fällen ist das unnötig und verkompliziert nur die Programmierung, das Testen und Debuggen und nicht zuletzt den Unterhalt einer solchen Lösung auf längere Frist.
Schon alleine das Managen dieses FIFOs (ob das jetzt ein RT-FIFO, eine Global oder was auch ist) im Falle einer Blockierung Deines Hauptthreads der die Daten abfragt ist ein Alptraum. Wann und bei wieviel willst Du das FIFO beschränken wenn keine Daten mehr gelesen werden? Unendliches erweitern ist sicher keine Option. Und strikte Werte könnten in bestimmten Situation (etwa wenn Windows beschliesst um Deinen Hauptthread mal für eine Weile aufs Eis zu legen) zu Datenverlust führen.
Zudem lässt Deine Bemerkung:
• Gibt es effizientere Lösungen für derartige Abfragen von Werten in Schleifen außer dem RT-FIFO?
vermuten dass Du den Braten auch schon gerochen hast und nun nach einer Lösung suchst um das Ganze (un)elegant zu verschönbessern. Des weitern ist eine solche Frage ziemlich unsinnig, denn Du spezifizierst nicht warum Du denkst dass dies nicht effizient ist und was Du als effizient betrachtest. Kurze Latenz, hohe FIFO Tiefe, oder etwas anderes? Hast Du irgendwelche Benchmarks gemacht die entsprechende Daten liefern aufgrund derer man nach besseren Alternativen suchen kann?
RE: C# - LabVIEW - th89 - 07.09.2013 09:05
Danke für die schnelle Antwort @ rolfk.
Das eigentliche Problem besteht leider darin, dass die von mir beschriebene Schleife nur ein Beispiel darstellt.
Ziel ist es, ein beliebiges LabVIEW-Projekt (oft mir GUI in While-Schleife) im Hintergrund laufen zu lassen und bestimmte Daten abzufragen.
Will man sich nicht um genaue Timings kümmern (oder kann es gar nicht, weil man das komplexe Projekt nicht versteht) bleibt leider nur eine asynchrone Übertragung (meine Meinung, ich lass mich gern verbessern).
Die Frage der effizienteren Lösung zielt nicht direkt auf die Puffer-Architektur ab, sondern eher ob es noch andere Lösungsansätze außer einem Puffer geben könnte, um das oben genannte Problem zu lösen.
Danke und LG
RE: C# - LabVIEW - rolfk - 07.09.2013 11:58
(07.09.2013 09:05 )th89 schrieb: Danke für die schnelle Antwort @ rolfk.
Das eigentliche Problem besteht leider darin, dass die von mir beschriebene Schleife nur ein Beispiel darstellt.
Ziel ist es, ein beliebiges LabVIEW-Projekt (oft mir GUI in While-Schleife) im Hintergrund laufen zu lassen und bestimmte Daten abzufragen.
Will man sich nicht um genaue Timings kümmern (oder kann es gar nicht, weil man das komplexe Projekt nicht versteht) bleibt leider nur eine asynchrone Übertragung (meine Meinung, ich lass mich gern verbessern).
Die Frage der effizienteren Lösung zielt nicht direkt auf die Puffer-Architektur ab, sondern eher ob es noch andere Lösungsansätze außer einem Puffer geben könnte, um das oben genannte Problem zu lösen.
Danke und LG
Nun wenn Du schon das LabVIEW Programm als selbständiges Programm laufen lassen willst, mach das dann auch und bastle nicht ein Bibliotheksinterface darum herum auf. Die angewiesene Architektur hierfür ist ein Interapplicationsinteface (IA) mittels TCP/IP oder ähnlichem dass Du in diese Applikationen einbauen kannst und dann von beliebigen anderen Applikationen ansprechen kannst. Das ist architekturmässig viel übersichtlicher, lässt die LabVIEW Applikation als selbständiges Programm intakt und entkoppelt Deine LabVIEW Applikation weitgehend von allen anderen Applikationen, mit einem einzigen, mit etwas Zeit und Hirnschmalz deutlich definiertem Interface.
Eine bestehende Applikation in eine Bibliothek umzubauen wird Dich beim ersten Mal vielleicht etwas weniger Zeit aber wohl kaum weniger Mühe kosten und vor allem kannst Du Dir diese Mühe für jede neue Applikation immer wieder von vorne machen.
Mit einem gut definierten IA Interface machst Du Dir diese Mühe einmal und baust sie dann einfach in jede neue Applikation ein. Zudem kannst Du bei einem sinnvollen IA Interface ohne grosse Anpassung Deine C Applikationen schnell und einfach mit anderen LabVIEW Applikationen mit dem selben Interface verebinden, auch wenn die Daten die in diesem Programm verfügbar sind nicht die selben sind. Das Bibliotheksinterface um eine Applikation ist da viel weniger geschickt, da es immer dazu neigt sehr applikationsspezifisch zu werden.
RE: C# - LabVIEW - th89 - 07.09.2013 12:10
OK, der Hinweis mit dem IA mittels TCP/IP hilft mir weiter.
Wenn ich das richtig verstanden habe könnte man quasi eine Socket-Schnittstelle über TCP schaffen (Stichwort DataSockets), oder?
Das setzt jetzt doch voraus, dass LabVIEW immer läuft, oder nicht?!
Wenn ich noch als Randbedingung stelle, dass LabVIEW nicht installiert oder gestartet sein muss habe ich bisher nur eine Lösung identifiziert:
NI Runtime Engine und LabVIEW-Projekt als Bibliothek (exe oder dll).
Gibt es da noch einen anderen Ansatz?
Liebe Grüße
Tim