Holy Geschrieben May 22, 2012 at 23:33 Geschrieben May 22, 2012 at 23:33 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 LimitsLV_Tinkerforge.zip Zitieren
Nic Geschrieben May 23, 2012 at 08:40 Geschrieben May 23, 2012 at 08:40 Prima Sache, wird das LabView-Lager sicher freuen. Sind die Quellen so groß, das selbst das Zippen nix bringt ? Zitieren
Holy Geschrieben May 23, 2012 at 09:19 Autor Geschrieben May 23, 2012 at 09:19 Gezippt sind es aktuell 1 MB. Zitieren
Paul Geschrieben May 23, 2012 at 12:18 Geschrieben May 23, 2012 at 12:18 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. Zitieren
AuronX Geschrieben May 23, 2012 at 13:50 Geschrieben May 23, 2012 at 13:50 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 Zitieren
Christian Geschrieben May 23, 2012 at 18:16 Geschrieben May 23, 2012 at 18:16 Ich hab mal was zum Thema komprimieren ins Wiki geschrieben vielleicht hilfts ja Zitieren
Holy Geschrieben May 23, 2012 at 18:31 Autor Geschrieben May 23, 2012 at 18:31 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. Zitieren
Christian Geschrieben May 23, 2012 at 19:00 Geschrieben May 23, 2012 at 19:00 Mist... aber immerhin 30%... Da sollten die Admins das langsam mal auf 1-5MB wenigstens anheben... Gruß Christian Zitieren
AuronX Geschrieben May 23, 2012 at 19:18 Geschrieben May 23, 2012 at 19:18 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). Zitieren
ThomasKl Geschrieben May 23, 2012 at 19:38 Geschrieben May 23, 2012 at 19:38 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. Zitieren
The_Real_Black Geschrieben May 23, 2012 at 20:09 Geschrieben May 23, 2012 at 20:09 @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? Zitieren
Holy Geschrieben May 23, 2012 at 20:20 Autor Geschrieben May 23, 2012 at 20:20 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. Zitieren
borg Geschrieben May 23, 2012 at 20:40 Geschrieben May 23, 2012 at 20:40 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? Zitieren
AuronX Geschrieben May 23, 2012 at 20:45 Geschrieben May 23, 2012 at 20:45 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... Zitieren
ThomasKl Geschrieben May 23, 2012 at 20:51 Geschrieben May 23, 2012 at 20:51 man kann in labview auch dlls ansprechen. da wäre es vermutlich leichter eine windows dll zu nehmen. Zitieren
Holy Geschrieben May 23, 2012 at 20:56 Autor Geschrieben May 23, 2012 at 20:56 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. Zitieren
ThomasKl Geschrieben May 23, 2012 at 21:40 Geschrieben May 23, 2012 at 21:40 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. Zitieren
borg Geschrieben May 24, 2012 at 11:58 Geschrieben May 24, 2012 at 11:58 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. Zitieren
ThomasKl Geschrieben May 24, 2012 at 12:32 Geschrieben May 24, 2012 at 12:32 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. Zitieren
Holy Geschrieben May 25, 2012 at 09:59 Autor Geschrieben May 25, 2012 at 09:59 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. Zitieren
ThomasKl Geschrieben May 25, 2012 at 10:31 Geschrieben May 25, 2012 at 10:31 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. Zitieren
Holy Geschrieben May 25, 2012 at 16:50 Autor Geschrieben May 25, 2012 at 16:50 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. Zitieren
Holy Geschrieben May 30, 2012 at 00:46 Autor Geschrieben May 30, 2012 at 00:46 Hab mittlerweile nochmal Zeit gefunden die händisch geschriebenen Klassen durchzutesten. Somit sind erstmal folgende Bricklets für Testzwecke verfügbar: Ambient Light BrickletHumidity BrickletTemperature IR BrickletDistance IR BrickletIO-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 Zitieren
BorgelMorgel Geschrieben May 30, 2012 at 05:56 Geschrieben May 30, 2012 at 05:56 Wäre es möglich das auch für die 2010 Version bereit zu stellen? Zitieren
Holy Geschrieben May 30, 2012 at 06:35 Autor Geschrieben May 30, 2012 at 06:35 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 Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.