[LabVIEW]Bindings: Prototypen

Ich habe mich mal an die Implementierung von Bindings auf Basis LabVIEW gemacht. Der bisherige Stand besteht aus den Haupklassen IPConnection und Device. Weiterhin ist die Klasse für das Ambient Light Bricklet komplett implementiert.

Da ich aufgrund der Größenbeschränkung von 192KB den Quellcode nicht hochladen kann erstmal 2 Screenshots damit ihr erstmal nen ersten Eindruck davon bekommen könnt.

http://www.tinkerunity.org/forum/index.php/topic,235.msg2585.html#msg2585

Wenn Interesse besteht kann ich die Quellen dann über das Tinkerforge-Repository im Github bereitstellen.

Edit: Quellcode angehängt. Danke an borg für die Erhöhung des Limits

LV_Tinkerforge.zip

Prima Sache, wird das LabView-Lager sicher freuen.

Sind die Quellen so groß, das selbst das Zippen nix bringt ?

Gezippt sind es aktuell 1 MB.

Gezippt sind es aktuell 1 MB.

Wenn du Platz zum hosten brauchst, schreib mir ne PM, ich hab noch nen Server mit unlimitierter Bandbreite, dort könnte der Kram auch untergebracht werden.

Wenn Interesse besteht kann ich die Quellen dann über das Tinkerforge-Repository im Github bereitstellen.

Wenn du das eh vorhast würde ich dir empfehlen einfach jetzt schon das TF-Repo zu forken, dort den Unterordner für LabView zu erstellen und die Sourcen via github hosten (gibt ja auch Download für Source-Code). Dann kann dir potenziell auch schnell jemand helfen wenn ihm ein Fehler auffällt und du kannst irgendwann nen großen Pull Request an TF stellen

Ich hab mal was zum Thema komprimieren ins Wiki geschrieben

vielleicht hilfts ja

Danke für den Vorschlag. Hilft aber leider nicht so wie notwendig

Sind dann statt 1053 KB trotzdem noch 707 KB und das ist für das Forum immer noch viel zu viel.

Eine Variante ist noch splitten aber das ist denke ich nicht wirklich toll.

Mist... aber immerhin 30%...

Da sollten die Admins das langsam mal auf 1-5MB wenigstens anheben...

Gruß

Christian

Ist das eigentlich nur Quellcode oder sind da auch Bilder mit bei? Weil 1 MB wären 10.000 Zeilen Code wenn jede Zeile 100 Zeichen lang ist...

Ich denke das sinnvollste wäre externes Hosting (GitHub oder Rapidshare oder eigener Webserver).

In Labview gibt es keinen Quellcode in dem Sinn, zumindest habe ich noch nie einen gefunden.

Du hast nur das Block Diagramm und klickst und ziehst dir so dein Programm zusammen. Das Ganze nennt sich dann Vi (ich glaube das steht für virtuelles instrument) und ist eine Binärdatei mit einem Format, mit dem man nur etwas anfangen kann wenn man Labview in der richtigen Version hat.

@Christian: Ich bin ein Beispiel und sogar ein positives... 

@"LabVIEW": Schade, dass es da nur das LabVIEW Format gibt was vermutlich intern bereits komprimiert wurde. Wie groß werden die Bindings wenn erst alles Implementiert wurde?

Die Ambient Light Bricklet Klasse ist insgesamt 700 KB groß, unkomprimiert. Es gibt noch 23 weitere Brick und Bricklets mit jeweils mehr oder weniger API-Funktionen. Wird in Summe dann schon einiges.

Ich habe auch schonmal probiert den kompilierten Code rauszutrennen aber das würde gerade mal 50 KB je Klasse bringen.

Ich hab die Maximal Dateianhanggröße mal auf 10MB gestellt. Warum ist das denn selbst ohne das compilierte so fürchterlich groß? Kann man die LabVIEW Bindings auf dauer überhaupt autogenerieren?

Wenn die Erzählungen stimmen muss man ein ziemlich großes Binärformat generieren ^^

Möglicherweise gibt es ja eine Bibliothek mit der man die Dinger programatisch erstellen kann? Das würde das Generieren denke ich erst erschwinglich machen...

man kann in labview auch dlls ansprechen. da wäre es vermutlich leichter eine windows dll zu nehmen.

Gute Frage was dort in den Dateien alles drin ist. Ohne groß Inhalt fängts bei knapp 20KB je VI (Funktion) bzw. Typdefinition an.

Die Autogenerierung ist auf jeden Fall möglich da mitells VI Scripting programmatisch Code erzeugt werden kann. Primär läuft es darauf hinaus eine Template-Klasse zu erzeugen und dann einfach eine neue Kopie zu erstellen und die jeweils spezifischen API-Funktionen automatisch zu generieren sowie den spezifischen Message-Handler der Klasse.

Aktuell bin ich mir noch nicht sicher ob der Aufwand lohnt den Codegenerator zu schreiben. Ich würde schätzen die 23 noch ausstehenden Brick/Bricklet Klassen per Hand zu erzeugen dauert maximal 1 bis 2 Tage. Der Codegenerator wird wohl schnell mal 1 Woche Entwicklungszeit schlucken. Das kommt insoweit auch zu tragen da ich die Device-Klasse soweit wie möglich mit Code versehen habe und die Brick/Bricklet-Klassen jeweils nur ihre spezifischen Sachen machen und sonst nur ihre Eltern-Klasse aufrufen und somit Änderungen dann nur an 1 Stelle fällig sind.

Zum Thema DLL:

Denke ich ist kein sinnvoller Weg da dort für jede einzelne Funktion ein Wrapper-VI geschrieben werden muss. Die Autogenerierung der Bindings hat ja primär bei den Brick/Bricklet Klassen Vorteile. Die IPConnection Klasse ist auch bei allen anderen Bindings handgeschrieben. Man gewinnt durch die DLL somit leider nicht wirklich was.

DLLs in Labview zu benutzen macht nicht wirklich Spaß, da stimme ich dir zu und das ganze Text parsen für die Autogenerierung möchte ich auch nicht mit Labview machen.

Dein Labview "Code" sieht auf jedenfall schonmal schön aufgeräumt auf, Bleibt zu hoffen dass sich die API nicht zu oft ändert.

Wenn die Bindings nicht autogeneriert sind, sind sie für uns halt nicht wartbar. Wir können unmöglich bei jeder Änderung die wir vornehmen bzgl neuer API etc. alle Bindings von Hand abändern. Das würde nur dazu führen das wir absolut starr werden mit der Funktionalität, weil der Aufwand einfach nicht zu bewältigen wäre.

Daher geht um die Autogenerierung nichts drumherum.

Aber wenn du sagst das du eine Device Klasse hast in der die meiste Funktionalität drin ist und nur noch kleine Brick/Bricklet Klassen zu machen sind, ist das doch eine hervorragende Ausgangssituation fürs Autogenerieren. Es müssen ja schließlich nur die kleinen Brick/Bricklet Klassen erzeugt werden.

Das Problem mit Labview ist, dass man da keinen Text hin und her schiebt sondern alles grafisch machen muss auch das Parsen der Konfigdatei. Da ist der Weg von einem per Hand "geschriebenem" Programm zu einem Autogenerierten einfach deutlich weiter.

Ich habe erstmal per Hand noch die Klassen für Distance IR Bricklet, Temperature IR Bricklet, Humidity Bricklet und IO-4 Bricklet erzeugt. Das werde ich jetzt erstmal alles auf Herz und Nieren durchtesten. Danach mach ich mich an die Programmierung des Generators und wenn der funktioniert dann die Parsingroutinen für die Konfigurationsdateien.

Sobald die Tests des aktuellen Standes fertig sind werde ich diesen nochmal hochladen und würde mich freuen wenn sich jemand Zwecks Verbesserungsvorschlägen, Bugs, etc. das mal anschauen könnte. Mir ist aber auch klar das die Anzahl derer die LabVIEW zur Verfügung haben wohl eher gering ist. Alternativ würde sich aber auch noch die 30-Tage Evaluierungsversion anbieten.

welche Labview Version benutzt du denn? Wir haben hier auf der Arbeit 8.6, wenn du soweit bist kann ich gerne mal einen Blick drüber werfen. Aber was ich auf den Screenshots gesehen habe sah schon sehr ordentlich aus.

Es gab mal labview 6.1 als c't Beigabe, auf der suche danach bin ich gerade auf

http://myopenlab.de/?Screenshots

gestoßen schein ein in Java programmierter Labview Clone zu sein, aber wird wohl nicht mehr so aktiv entwickelt.

Ich selbst benutze die Version 2011 SP1. Ich kann es aber auf jeden Fall runterspeichern. Gibt aber leider eine Stelle die ich dann anders implementieren muss, da es in LV 2011 ein paar neue Primitivies gab.

Grafische Programmieransätze gibt es einige, z.B. VEEpro von Agilent oder auch die Robotics-Suite (?) von Microsoft.

Hab mittlerweile nochmal Zeit gefunden die händisch geschriebenen Klassen durchzutesten. Somit sind erstmal folgende Bricklets für Testzwecke verfügbar:

• Ambient Light Bricklet
  
• Humidity Bricklet
  
• Temperature IR Bricklet
  
• Distance IR Bricklet
  
• IO-4 Bricklet
  

Weiterhin ist in der Library ein Tree.vi enthalten, welches einen ersten Hinweis auf die Verwendung geben soll.

Mit der Autogenerierung habe ich schonmal angefangen und hoffe das es zügig vorran geht. Ist aber wie schon angedeutet leider etwas umfangreicher aber trotzdem sehr spannendes Thema, was ich mittlerweile seit Jahren schonmal angehen wollte.

LV_Tinkerforge.zip

Wäre es möglich das auch für die 2010 Version bereit zu stellen?

Ja natürlich! Würde mich über Feedback freuen. Sollten bei der Verwendung Fragen auftreten beantworte ich die gerne direkt hier oder ggf. per PM.

LV_Tinkerforge_-_LV2010.zip