Discussion in 'OpenFormat' started by gege, Apr 7, 2008.

  1. gege

    gege New Member

    Hallo,

    erstmal ein dickes Lob - LV Openformat läuft wie beschrieben und das Auslesen von Daten aus meinem Eigenbau-Datenlogger war eine Sache eines Abends.

    Der Logger hat - klar - einen Datenspeicher, und hier kommt meine Frage/Vorschlag:

    Um den Datenspeicher zu löschen, Messreihen auszuwählen, Auslesen zu starten etc. muß ich Befehle an den Logger senden.

    Das mach ich z.Zt. per RS232 Terminal, schliesse es, starte LV und kann dann Daten auslesen.

    Etwas hakelig - habe ich was übersehen (d.h. geht das konfigurieren des Loggers von LV aus) bzw. wäre das eine sinnvolle Verbesserung?

    Es würde völlig reichen vordefinierte (Hex?)Strings per Menu-Button o.ä. an das RS232 Gerät senden zu können. Definition der Button-Namen plus Strings im .INI

    Gruß

    Gerd.
  2. wkrug

    wkrug New Member

    Deine Idee ist gut, auch wenn ich es für meine derzeitigen Entwicklungen nicht brauche.
    Diese Option macht bei Geräten Sinn, die einen integrierten Speicher haben, also Datenlogger und einige Ladegeräte.
    Schön wärs natürlich auch, wenn man in der Openformat Beschreibung auch gleich ein paar Strings fest definieren würde.
    z.B. Daten auslesen.
    Speicher löschen.
    Logvorgang starten.
    Logvorgang beenden.

    Zusätzlich sollten dann noch eigene Strings definierbar sein, die noch speziellere Funktionen des entsprechenden Openformat Gerätes ansprechen.
    Diese Strings könnte man sinnvollerweise in der Openformat.ini definieren, wenn das technisch möglich ist.

    Mal schaun was Dominik dazu sagt.
  3. gege

    gege New Member

    Für Datenlogger sollte man sich auf ein Betriebsmodell einigen. Die meisten Logger sind ja im (Dauer)Entwicklungsstadium und könnten sich an LV anpassen (-> weniger Aufwand für LV).

    >Daten auslesen.
    >Speicher löschen.
    >Logvorgang starten.
    >Logvorgang beenden

    bräuchte ich z.B. nicht unbedingt. Mein Logger startet beim Einschalten, loggt bis er ausgeschalten wird bzw. Speicher voll. Interessant wär Logvorgang starten/beenden aber unter dem generellen Aspekt Gerätesteuerung z.B. für Lader o.Ä.

    Für meine Loganforderungen reicht
    > Daten/Meßreihe selektieren
    > Daten/Meßreihe auslesen
    > Speicher löschen

    (Meßreihe = Mehrere Aufzeichnungen hintereinander im Speicher, Start jeweils mit Zeitstempel 0 bzw. Header auseinanderzuhalten).

    Bis auf weiteres mach ich auslesen/löschen mit eigenem Programm und übergeb LogView die Daten per vorgefiltertem File.

    Die String-Idee würd ich unterstützen, wobei ich mirs einfach machen würde daß die Strings auf einige wenige Buttons in der GUI gemappt werden und deren Beschriftung definieren und vordefinierte Strings, die bei Drücken des Buttons gesendet werden. Textmeldungen vom Gerät wären dann in MEssagebox / Fenster anzeigbar.
    Noch einfacher zu realisieren wäre ein Text-Eingabefenster zur Eingabe und senden von Freitext ans Gerät, Ausgabe von Antworten die keine OpenFormat Tickets sind (als z.B. nicht mit $ beginnen) auf Fenster/Messagebox. Über die Buttons könnte man sich vordefinierte Texte ins Eingabe-Fenster holen, evtl. ändern und abschicken

    Alles darüber hinaus wäre schön aber aufwendig. Ich find auch die jetzige OpenFormat Lösung schon sehr schön.

    Gruß

    Gerd.
  4. Dominik

    Dominik Administrator Staff Member

    Moin !

    Ich lese hier euer "Treiben" aufmerksam mit und nun sollten wir aus der Entwicklungssicht mal was dazu sagen, wie :)

    Also ich halte generell dieses Feature für sehr sinnvoll und es war ja eh schon länger angedacht dass das OF auch zum Gerät was senden kann. UND es wird auch ein Logging für das OF geben. Aber dazu gleich noch mehr.

    Zu dem Senden ... Ich denke es wäre sinnvoll, wenn man diese Funktion universell hält. Damit meine ich, das jeder seine Kommandos so absetzen können sollte wie er es braucht. Was wir sicherlich nicht einbauen werden sind so "Frage-Antwort Spielchen". Also nach dem Motto:
    • LV -> Device : Lese Datensatzanzahl
    • Device -> LV : Datensätze : 5
    • LV -> Device : Lese Datensatz 3
    • Device -> LV : sendet Daten
    Das kann man sicherlich in 2 Schritten erledigen, aber nicht als Block. Also es wird immer nur eine Anfrage geben auf die der Logger wie auch immer reagiert. Danach muss vom Benutzer eine neue Aktion initiiert werden.

    Statusmeldungen
    So nun wäre es ja durchaus sinnvoll wenn der Logger in LogView Statusmeldungen abgeben könnte. Damit meine ich folgendes:
    • LV -> Device : Lese Datensatz 3
    • Device -> LV : sendet Daten
    • Device -> LV : sendet Statusmeldung "Alles gesendet"
    Das hätte den Charme, dass der Benutzer nicht einfach was auf "blauen Dunst" startet, sondern am Ende ein Feedback bekommt das es fertig ist (oder auch mitten drin einen Status wie weit das Device z.B. ist).
    Diese Meldungen müssten dann explizit definiert sein nach dem Motto:

    $OF_STATUS : Dies ist dann der Text !<cr><lf>

    Die dort gesendeten Infos würden wir dann in der Oberfläche in einem extra Dialog anzeigen (und im Logging ablegen). Einen Extra Dialog braucht das OF dann sowieso, denn von irgendwo muss man ja die Anforderungen senden können.

    Daten zum Device senden
    Ich könnte mir vorstellen, dass man dafür die INI erweitert. Es würde sich anbieten die Sachen dort abzulegen denke ich. Das könnte dann so aussehen:
    [SendData]
    ' Hier würde die Anzahl der Sendebefehle abgelegt
    ' damit LogView eine Liste aufbauen kann.
    CommandCount = 1

    [SendData 001]
    Name = Datenspeicher löschen
    ' % -> Daten werden als ASCII interpretiert
    ' $ -> Daten werden als HEX interpretiert
    Send = %lösche Speicher
    'Send = $02,3f,3f,3f,03 ' HEX Beispiel
    Beschreibung = Diese Funktion löscht den Internen Speicher des Loggers komplett. Alle Daten gehen verloren !

    Es wäre denke ich schon wichtig auch HEX Werte senden zu können. Denn damit kann man meist einfacher hantieren in einem µC. Die Beschreibung würde dann in LogView in einem kleinen Textfeld angezeigt. So hätte man gleich eine kurze Info was denn der Befehl macht.
    Die Befehle würde ich in eine ComboBox packen in der man dann auswählen könnte. Dazu ein Button ala "Senden" und ggf. ein Button um mittels Timer zu senden um im Intervall Daten anzufordern.

    Das wäre ein überschaubarer Dialog zum Senden von Kommandos und mit einem Statusfenster bezüglich Device Feedback.

    Logging für das OpenFormat
    Holger und ich nutzen in letzter Zeit sehr oft das SmartInspect Logging. Wir haben dieses Logging in LogView ja konsequent eingesetzt und ich denke mal es liefert gerade im OF Umfeld eine Menge sinnvoller Infos. Siehe dazu auch : http://www.logview.info/cms/d_openformat_debug.phtml

    Ich denke es würde Sinn machen wenn man das OpenFormat mit ein Paar Loggingmethoden ausstatten würde. Dann könntet ihr vom Gerät direkt Debugausgaben an das Logging von LV senden. Beispiele:
    • $LOG : TEXT (Text loggen)
    • $LOGD 123 (Int loggen)
    • $LOGF 12,1231 (Float loggen)
    • $LOGDUMP xx xx xx xx xx (Hex Dump loggen)
    • .....
    Also sagen wir mal so ... Wir könnten diese Funktionen vermutlich ohne grossen Umstand anbieten. Vielleicht sagt ihr mal was dauz was ihr davon haltet und ob das brauchbar ist.


    Ich hoffe die Vorschläge sind in eurem Sinn. Alles ist natürlich noch NICHT verfügbar und steht hier mal zur Diskussion. :)

    Also Meldung bitte :eek:
  5. gege

    gege New Member

    Logging..

    Dominik,

    1) das Logging über SmartInspect find ich sehr attraktiv. Damit war die OF Integration mit meinem Logger ein Traum. Deshalb fiände ich die von Dir vorgeschlagenen Logging-Methoden einen tollen Vorschlag, vor Allem wenns für Euch einfach zu realisieren geht. Damit könnte man auch auf die schnelle Rückmeldungen vom Logger ("Daten übertragen") realisieren.

    2) Zum Aufbau des INI-Files und der Dialoge: Da die Realisierung voll zu Lasten der Entwickler geht möchte ich mich hier wenig einmischen, da Ihr sicher eine Vorstellung habt welcher kompromiss zwischen einfach und gut sinvoll ist. Ich kommentiere aber gerne Eure Vorschläge. Wie Vorgeschlagen (Combobox etc.) wär's ok für mich.

    3) Je komplexer und spezieller das Zusammenspiel zwischen Logger und LV wird, desto mehr würde es mir gefallen wenn das .INI File vom Logger zu LV geschickt werden kann um Inkonsistenzen zu vermeiden. Alternativ könnte man auch erstmal mit einer ID bzw. Versions-Nummer des INI Files arbeiten (z.B. LV und Logger schicken sich gegenseitig die IDs) um Inkonsistenzen wenigstens zu erkennen. Oder man behilft sich elegant mit den Logging-Methoden (Logger schickt Log-Meldung zu LV welche INI Version er erwartet, im .INI File kann man per Kommentar eintragen (und per "Show Ini" ansehen) obs das richtige ist.

    Fazit: Mit den Logging-Methoden könnte man schon eine Menge machen.. dazu noch die Combox zum Senden vordefinierter Strings und "der Kittel wäre geflickt", wie wir hier sagen:D

    Gruß

    Gerd.
  6. gege

    gege New Member

    Vorschlag:
    • $LOGT: TEXT (Text loggen)
    • $LOGD: 123 (Int loggen) - oder $LOGI wie Integer??
    • $LOGF: 12,1231 (Float loggen)
    • $LOGX: xx xx xx xx xx (Hex Dump loggen)
    • .....
    ..und das leidige . / , Format bei float - sollte da nicht ein punkt sein, also 12.1231?

    Gruß

    Gerd.
  7. Dominik

    Dominik Administrator Staff Member

    Moin !

    Dafür haben wir mittlerweile eine eigene Funktion die je nach Ländersetting den Floatwert passend konvertiert.

    Das ist ganz nebnbei auch eine der kompliziertesten Funktionen die wir je für LogView geschrieben haben ... :rolleyes:
  8. gege

    gege New Member

    Log Format?

    Dominik,

    willt Du das Format schonmal rudimentär festlegen? Bin nämlich dieses Wochenende wieder am proggen (es regnet).

    Mir persönlich würde "$LOG ..." reichen.

    Überlegenswert wäre ein Mechanismus, um die -potentiell vielen- Logmeldungen zu kategorisieren/filtern.

    Im einfachsten Fall durch eine ID (also z.B. "$LOG;1;..."). Könnte aber auch einfach Teil der Log-Meldung sein die man nutzen könnte für:
    • Priorisierung (asserts, Meldung, Warnung, Fehler, kritischer Fehler, ..)
    • Filterung - z.B. Logmeldungen von versch. Teilen des Programms
    • ...
    Gruß

    Gerd.
  9. Dominik

    Dominik Administrator Staff Member

    Moin !

    Naja rudimentär könnte es schon so aussehen:
    $LOGT: TEXT (Text loggen)
    $LOGD: 123 (Int loggen) - oder $LOGI wie Integer??
    $LOGF: 12,1231 (Float loggen)
    $LOGX: xx xx xx xx xx (Hex Dump loggen)

    Ist ja fast wie mein erster Vorschlag. Nur etwas gestutzt.

    Sorry wir waren mit ganzer LogView Truppe auf meinem Junggesellenabschied :rolleyes:

    Brauchn ma ned. Kann alles die Loggingkonsole !

    Soweit im Moment ...
  10. looking

    looking New Member

    Hallo,

    gibt es inzwischen Neuigkeiten zur Sende-Funktion? Wird sowas demnächst kommen? Ich könnte das nämlich auch ganz gut gebrauchen...
    Danke.

    Grüße
    looking
  11. Dominik

    Dominik Administrator Staff Member

    Moin !

    Wer mehr zu diesem Thema erfahren möchte kann sich mal bei mir per Mail melden. Ich könnte dann mal was zur Demo zeigen und wir würden uns dann aber auch für eure Meinung dazu interessieren.
    Ist aber noch nonpublic - deswegen dominik ÄTT logview DOTTER info

Share This Page