Discussion in 'Feature Preview' started by Dominik, Oct 15, 2008.

  1. Dominik

    Dominik Administrator Staff Member

    Diese Feature Preview wird zum ersten Mal keine Demo enthalten. Es geht vielmehr um die Vorstellung einer Technik wie man als User sein Gerät xyz an LogView "hängen" kann um die Daten darzustellen.

    Die Grundidee stammt dabei gar nicht mal von uns. Sie ist aufgekommen als Ludwich uns gefragt hat wie er denn seine neue Hardware (
    http://www.h-tronicshop.de/artikel.aspx?art=192707) in LogView einbinden könnte. Dabei sind so Stichwörter gefallen wie "Datenlieferantenprogramme" und "Openmultimeterformat" ... Was wir hier nun vorstellen möchten ist unsere Idee dazu.

    Kurzer Überblick
    Die Idee ist LogView mit 1-x Interfaces auszustatten an die ein User mit einer Zusatzanwendung (die er selber schreiben muss) im Openformat Daten liefert die LogView dann auswertet. Im Prinzip verlagert man die Auswertlogik der Geräte von uns auf den User. Das bietet im Gegenzug aber sehr viele Möglichkeiten und Freiheiten für den User. Und solche "Progrämmchen" sind obendrein nicht sonderlich schwer zu programmieren.

    Dateilbeschreibung
    Im Moment gibt es nur 2 Möglichkeiten wie ein Gerät an LogView angeschlossen werden kann. Entweder wir binden es direkt ein (so wie wir es mit Ladern / Datenloggern / ... tun) oder der User benutzt das Openformat um sein Gerät an LogView anzupassen.


    Wenn wir etwas einbinden dann sind das zu 99,9% Geräte die käuflich zu erwerben sind. Das Openformat kommt dagegen oft bei Eigenentwicklung zum Zuge. Beides hat seine Vorzüge, aber es gibt eine Menge Situationen wo das Konstrukt nicht weiter kommt. Das wäre z.B. wenn jemand ...
    • ein bestehendes Gerät einbinden will und es nicht auf OpenFormat umstellen kann (weil das Datenformat fest definiert ist)
    • mehrere Geräte (wie z.B. Multimeter) zu einer Gruppe zusammen fassen möchte um sie dann zusammen (oder über Kanäle getrennt) an LogView zu übergeben
    • von irgendwoher im System Daten bekommt und diese darstellen möchte. Es müssen nämlich nicht unbedingt Geräte sein die Daten liefern. Es wäre durchaus denkbar ( als Beispiel) die CPU Auslastung mit einer externen Anwendung zu messen und LogView visualisiert das.
    • generell gesagt irgendwelche Daten in LogView anzeigen möchte, wo aber das OpenFormat nicht greift und wir auch auf absehbare Zeit keine Einbindung schaffen können.
    Es sollte deutlich werden das die neue Technik sehr flexibel genutzt werden kann. Oder um es ganz deutlich auszudrücken ... Mit dieser Option hätte man die Möglichkeit alles an Daten zu visualisieren was einem in den Sinn kommt - sei es von Hardware oder anderer Software.

    Die Technik dahinter
    Das technische Prinzip besteht in der Umwandlung der vorhandenen Daten in ein OpenFormat die Übermittlung über ein Interface zu LogView. Nehmen wir als Beispiel mal das Gerät von Ludwich : http://www.h-tronicshop.de/artikel.aspx?art=192707

    Der User hätte nun folgende Schritte zu erledigen:
    1) Datenformat / Datenstruktur besorgen
    In unserem Beispiel ist das in der Doku zu finden (http://www.h-tronic.com/Presse/download/1190010_Detailbeschreibung.pdf)

    2) eigene Software Schreiben welche das Gerät abfragen / steuern kann
    Dieser Punkt wird nun sicherlich den ein oder anderen abschrecken. Aber ganz ohne Programmieren geht es nunmal nicht. Es muss also eine sehr kleine und überschbare Anwendung geschrieben werden welche das Gerät abfragt und ggf. auch steuert.
    In unserem Beispiel müsste man also die Schnittstelle zum Gerät öffnen (in dem Fall ein Bluetooth Serieller Port) und dann mit den Kommandos C00 - C09 die Daten abholen.

    3) Umwandlung der Daten in eine OpenFormat Struktur
    Damit LogView nun diese Daten auch ohne Probleme verarbeiten kann müssen die aufgezeichneten Daten (-telegramme) umgewandelt werden in ein LogView leserliches Format. Im Moment stellen wir uns da ein OpenFormat vor. Es wäre aber durchaus denkbar das man hier noch ein eigenes Format innerhalb von LogView implementiert. Bleiben wir aber mal beim Openformat.
    Die Useranwendung müsste also dafür sorgen das die Spannungswerte in einen solchen String umgewandelt werden:
    $1;1;0;1133;318;0;0;0;20;21;0;16<cr><lf>
    Das Rote wären dann die Spannungswerte von der Messkarte.

    Die Umwandlung sollte im Normalfall recht einfach sein, denn das ist nichts weiter als etwas Stringbehandlung. Die Aufgabe müsste ebenfalls in der Useranwendung erfolgen.

    4) Daten an LogView übertragen
    Nun kommen wir zu dem Punkt wo es mitunter etwas schwieriger wird. Denn der User muss nun dafür sorgen das die Daten irgendwie nach LogView kommen. Dafür gibt es im Moment nur einen Weg - eine serielle Schnittstelle. Das wäre hier sicherlich auch machbar, aber wir haben da besseres im Sinn.


    Die Daten könnten über folgende Interfaces an LogView gesendet werden:
    • WM_COPYDATA (http://msdn.microsoft.com/en-us/library/ms649011(VS.85).aspx) - das ist ein Windows Verfahren um Daten zwischen Anwendungen recht unkompliziert auszutauschen. Man sendet letztlich einen String von der Useranwendung an LogView und das direkt ohne irgendwelche Umwege. Dazu gibt es zahlreiche Beispiele für alle möglichen Programmiersprachen.
    • TCP / IP bzw. Socketverbindung - ist sicherlich eine Anbindung die sehr universell einsetzbar ist. Damit wäre es möglich die Useranwendung auch unter Linux / MAC / PocketPC / ... laufen zu lassen. Nur LogView müsste auf einer Windowsmaschine laufen und Zugriff auf das gleiche Netzwerk haben.
    • Webservice - Wir könnten in LogView einen Webservice zum Datenaustausch implementieren. Auch das hätte den grossen Vorteil der Plattformunabhängigkeit. Auch hier würde aber Netzwerk vorausgesetzt sein.
    • Dateiaustausch mittels Filewatcher - Das bedeutet das LogView eine Datei überwacht und sobald dort Daten eingetragen werden diese ausliest und in der Datei löscht. Das ist eine sehr einfache Art des Datenaustausches, aber auf der anderen Seite auch eine sehr anfällige Variante. Insofern wäre dieser Weg eher "suboptimal".
    • Pipes (http://en.wikipedia.org/wiki/Named_pipe) - Windows bietet die Möglichkeit Pipes zum Datenaustausch zu erstellen. Die Sache ist aber nicht so ganz trivial und bedeutet viel Aufwand bei der Implementierung. Insofern ist das zwar ein brauchbares Verfahren, aber wird vermutlich nicht zur Anwendung kommen.
    Wie man sieht würde eine ganze Reihe (und es gibt sicherlich noch mehr Varianten) an Möglichkeiten bestehen wie man LogView die Daten übergeben könnte. Die Netzwerkbasierten Varianten hätten sogar den Vorteil das sie auf vollkommen unterschiedlichen Rechnern - ja sogar übers Internet - funktionieren würden. Vorausgesetzt die Verbindung hat nicht zu hohe Latenzzeiten ...

    Damit der Benutzer nun nicht vor einer unlösbaren Aufgabe steht würden wir zu den gängigsten Programmiersprachen Beispiele liefern wie man die Daten mit den Methoden übertragen / abliefern müsste.

    Fertig :)

    Das wäre auch schon alles zur Technik. Das liest sich im Moment vermutlich recht kompliziert, aber die Sache ist einfacher als sich das manch einer auf den erstenBlick vorstellen würde. Wir haben im LogView Umfeld schon zahlreiche Testanwendungen erstellt und der Aufwand hält sich meist doch stark in Grenzen.

    Was bringt mir das nun?


    Manch einer wird sich nun sicherlich fragen was der ganze Aufwand bringen soll. Deshalb nochmal ein paar Stichpunkte bezogen auf Mailanfragen die wir so bekommen ...
    • Multimeter könnten mit sehr geringem Aufwand selber angebunden werden
    • Zwei oder mehr Multimeter könnten einen Verbund bilden und z.B. U/I Messungen durchführen und LogView visualisiert alles zusammen
    • Ladegerät und Lipobalancer könnten in ein Format zusammengeschrieben werden
    • Zusammenführung der Daten von mehreren Datenloggern
    • Anbindung vollkommen "artfremder" Hardware an LogView (z.B. Solaranlagen, Motortester, Bewässerungsanlangendurchflussmesser, whatever ...)
    • Anbindung von Wetteranlagen
    • Anbindung von Messkarten wie im Beispiel oben
    • Darstellung von CSV Dateien in LogView (Man bedenke das es damit unerheblich ist wo die Daten letztlich weg kommen! Wichtig ist nur das die Useranwendung die Daten dann zeilenweise an LogView im geigneten Format übergibt.)
    • .....
    Man kann sehen das diese Technik LogView noch weit flexibler macht als es heute der Fall ist. Aber die Sache setzt natürlich ein bisschen was vorraus.



    Was brauche ich dazu?
    • Eine Programmiersprache mit der man die Daten entgegen nehmen kann, die Stringverarbeitung kann und die Daten an das LogView Interface senden kann. Oder um es anders auszudrücken ... Eigentlich ist die Programmiersprache Nebensache. Man sollte nur ein bisserl Ahnung von selbiger haben :)
    • Programmierkenntnisse sind sicher nicht schlecht. Aber wie schon weiter oben geschrieben ist das was wir da vom User verlangen würden wirklich kein Hexenwerk sondern im Normalfall in wenigen Stunden zu bewerkstelligen.
    • Eine OpenFormat INI - Denn irgendwie muss LogView ja wissen was da für Daten über das Interface kommen.
    Muss es wirklich das OpenFormat sein?
    Wir haben erstmal das OpenFormat als grundlegende Idee verwendet weil es schon in LogView eingebunden ist und alles bietet was wir für die interne Umrechnung der Daten brauchen. Denkbar wäre aber sicherlich auch eine XML basierte Lösung die zunächst erstmal das Format an LogView überträgt.
    Aber prinzipiell ist die Art der Daten wie sie letztlich an LogView geschickt werden nicht ganz so entscheident.

    Bilder
    So und hier noch ein Bild welches das ganze Konstrukt mit ein paar Strichen zeigen :)

    Attached Files:

  2. gunnark

    gunnark Member

    Moin,

    die Idee kommt mir bekannt vor ...

    Ein par Bemerkungen dazu - es gibt noch die theoretische Möglichkeit Logview als COM-Objekt zu Nutzen und daher von einer Anderen Anwendung aus fernzusteuern.

    Eine andere Möglichkeit wäre das Einbinden einer Skriptsprache alla VBA. Ich meine mich zu erinnern das man das als Objekt einbinden konnte. Gegen Gebühr wenn ich mich recht entsinne.

    Und um zB ein Webinterface zu nutzen brauche ich nicht zwingend ein Netzwerk - das funktioniert auch lokal.

    Ein Sockets - Verbindung hätte natürlich den Charme das man plattformunabhängig wird.

    Gruß

    Gunnar
  3. compander

    compander New Member

    Grundlegendes

    Hallo Dominik.

    Danke für diesen Beitrag. Da sehr lehrreich!
    Nun weiss ich besser, in welche Richtung ich entwickeln muss.

    Herzliche Grüße von Willi (Compander)
  4. Ludwich

    Ludwich New Member

    Messgeräteanbindung

    Ich habe natürlich auf dem Gebiet der Softwareanbindung wenig Erfahrung, vom kurzen Anlesen hat mir aber die Idee einer TCP/IP Anbindung am besten gefallen. In der Anwendung ProfiLab Expert (www.abacom-online.de) steht auch eine TCP/IP Komponenete zur Verfügung. Es steht damit eine nahezu unbegrenzte Reichweite zu Verfügung (Abgesetzte Mess/Wetterstaion...) Und ich denke das ist ein recht etabliertes Transportmodel. Die Anbindung klappt über Rechner und inzwischen recht günstige Netzwerfähige Module wie unter www.pollin.de Bausatz AVR-NET-IO Best.Nr.810058.
    Ich würde mich über eine rege Diskussion zu diesem Thema freuen. Es wäre schön wenn wir die "Rahmenbdingungen" für die Entwicklung dieses ausgesprochen nützlichen LV-Pimps schnell umsetzen können. Es steht dem LV Team in diesen Fall ja offen mal beide Seiten der Anwendung als Vorlage zu schaffen um den "freien" Entwicklern eine gute Startbasis zu liefern :)

    Ich möchte nochmals für die Integration der DPSe danken!!

    Schöne Grüße aus Wasserburg wünscht

    ludwich
  5. Dominik

    Dominik Administrator Staff Member

    @Compander:
    Hmm welche Variante sagt dir denn am ehesten zu? Und für was würdest du das Interface nutzen wollen ?
  6. bbukowski

    bbukowski New Member

    Hi,

    beruflich erstelle ich Graphen mit rrdtool für ca. 2000 Server und sonstige Geräte.

    Als Transport benutze ich simple HTTP Requests:

    http://rrd.lyceu.net/rrd_update?r=eu2625:Ethernet:eth0:1227394643:3107718792:2970570077

    das Format sieht folgendermaßen aus:

    hostname:deviceclass:device:sekundenseit1970:wert:wert:wert..
    Einzelwerte schicke ich per GET Request, größere Mengen natürlich mit nem post.

    Falls ihr was mit Netzwerk machen wollt, würde ich euch http empfehlen, da es auf jeder Plattform in jeder Sprache http clients gibt, die jeder bedienen kann.

    XML hört sich zwar sexy an ist aber einfach nicht dafür gedacht von Menschen verarbeitet zu werden. Man kann es auch nicht wirklich performant parsen und das debuggen find ich ist eine Qual.

    Boris
  7. Porsti

    Porsti New Member

    Kurze Bemerkung: Die Datenbeschreibung würde ich nicht in eine Datei legen, sondern an den Anfang der Datenübertragung stellen. Dies ist 1. flexibler und verhindert 2. Dateienchaos auf dem Rechner. Denkbar wäre auch, daß sich die Daten während der Übertragung "selbst beschreiben". Das hängt davon ab, wie flexibel LogView intern ist.

    Außerdem habe ich den Eindruck, daß sich TCP/IP so langsam aber sicher als beliebtester und einfachster Übertragungsweg herauskristallisiert.

    Porsti
  8. 4712

    4712 New Member

    Hallo Dominik
    ... erscheint mir ein sinnvolle Idee. Allein, weil ich die grafische Anzeige von Messwerten für mich nicht immer so einfach finde (trotz Delphi).
    Könnte mir Vorstellen sowas für mein Keithley DMM (GPIB od. RS232) zu machen.
    Wäre das auch mehrkanalig möglich? Ich hab mich mit Openformat noch nicht beschäftigt...
  9. Dominik

    Dominik Administrator Staff Member

    Moin !

    Wie du im V3 Forumsbereich feststellen wirst ist die Sache mitlerweile (ohne OpenFormat) schon weit ausgereifter :)
  10. 4712

    4712 New Member

    Danke für den Hinweis! :)

Share This Page