Hallo Thomas,
das ist ein interessanter Vorschlag!
Und das ist ein Thema, worüber Dominik und ich schon oft gesprochen haben. Wir haben uns gerade in den letzten Tagen auch über die mögliche Verwendung von regular expressions Gedanken gemacht.
Dein Vorschlag eines offenen Datenformats klingt sehr vielversprechend und erscheint mir auch umsetzbar.
Es muss in dem von Dir erwähnten ini-File dann auch Anweisungen geben, wie LogView z.B. den Beginn eines Datensatzes erkennen kann. Und ob ein Wert z.B. beim Beginn eines Datensatzes wieder auf Null gesetzt werden soll. ...
Da ist also noch einiges an Details festzulegen.
Wir hoffen, dass sich noch viele Leute an der Diskussion dazu beteiligen werden!
Der bisherige Stand der Umsetzung eines Universalformates in LogView ist in etwa folgendes:
1.) Es muss ein Basisformat geben, welches ohne Änderungen sofort zu brauchbaren Ergebnissen in LogView führt.
2.) Bei Bedarf kann man nachträglich über zusätzliche Steuerdateien Erweiterungen/Änderungen/Anpassungen vornehmen.
3.) Die Trennung der einzelnen Daten in einem Wertesatz (entspricht beim Empfang einem Datentelegramm) erfolgt durch ein Trennzeichen, z.B. das Semikolon. Abschluss eines Wertesatzes über Sonderzeichen.
4.) Die Werte selbst werden nicht mit Dezimaltrennungen versehen. Da es international nun mal Unterschiede bei der Verwendung von Komma und Punkt gibt, würde das insgesamt mehr Ärger als Nutzen bringen.
Deshalb werden z.B. Spannung, Strom, Kapazität und andere elektrische Kennwerte als Tausendstel übertragen, also in mV, mA, mAh.
Bis auf den Punkt 2.) erfüllt das bereits in LogView integrierte Datenformat 'Testformat Lader' diese Anforderungen. (Für Datenlogger gibt es das 'Testformat Logger'). Das Format geht im Moment von einer festen Länge von 44 Zeichen aus, das könnte man aber bei Bedarf flexibel halten. Für feste Längen ist die Verarbeitung in LogView generell schneller.
An Punkt 2.), also die Erweiterbarkeit der Auswertung, kann man arbeiten.
Zum Testen hier mal die Details des Datenformates 'Testformat Lader':
(realisiert für max. 3 Kanäle)
{-------------------------------------------------------------------------------
Datenformatbeschreibung
Schnittstelle: 9600 Baud
8 Datenbits
N keine Parität
1 Stopbit
Code:
1 2 3 4
1234567890123456789012345678901234567890123 4
k;tttttt;UUUUU;IIIII;CCCCCC;TTTTT;xx;y;zzz<cr><lf>
k Kanalnummer (1, 2 oder 3)
tttttt Zeit in Sekunden (neuer Datensatz beginnt bei 0)
UUUUU Spannung in mV
IIIII Strom in mA
CCCCCC Ladung in mAh
TTTTT Temperatur in 0.1°C Schritten
xx Zyklusnummer (wenn keine Zyklen verwendet werden = 00 ansonsten
steht dort halt die Zyklusnummer)
y Status dezimal (0 = laden, 1 = entladen, 2 = Pause,
9 = keine Aktion)
zzz Erweiterungen (im Moment einfach 000 dezimal)
Hinweise:
------------------------
1) Die Daten kommen im Sekundentakt. Die Zeit beginnt bei 0 Sekunden !
2) Wenn Spannung oder Strom nicht in 1000er Schritten zur Verfügung stehen,
muss der Wert passend ausgegeben werden (10V = 10000 im Datenformat)
3) Wird normal geladen / entladen ist die Zyklusnummer gleich 00. Werden
Zyklen verwendet, beginnt der Zyklenwert mit 01.
4) Der Status muss passend gesetzt werden. Für Laden, Entladen entsprechend
0 bzw. 1 in dezimal ausgeben. Wenn der Lader eine Pause macht
(z.b. zwischen Laden und Entladen), dann muss eine 2 gesendet werden.
Macht der Lader nichts, also ist er mit seiner (Ent-)Ladung durch,
dann sendet er 9.
9 wird auch nach dem Start gesendet, erst wenn der Lader seine
Arbeit aufnimmt, geht dieser Wert auf 0,1 oder 2.
5) Die Erweiterungen sind im Moment ungenutzt. Hier einfach 000 dezimal senden.
6) Die Kanalnummer ist bei Geräten mit einem Ausgang halt immer 1. Bei
mehreren Ausgängen je nach Ausgangszahl.
Jeder Kanal sendet trotzdem im Sekundentakt. Alternativ sendet jeder
Kanal nur alle x Sekunden. Dabei muss aber auf die Zeit geachtet werden.
Diese Zeitangaben müssen stimmen!
7) Es können auch permanent Daten gesendet werden. In diesem Fall muss aber
bei sinnlosen Telegrammen die Zeit auf 000000 stehen und der Status auf 9.
-------------------------------------------------------------------------------}
Und zur Vollständigkeit hier noch das Datenformat 'Testformat Logger':
(realisiert für max. einen Kanal)
{-------------------------------------------------------------------------------
Datenformatbeschreibung
Schnittstelle: 9600 Baud
8 Datenbits
N keine Parität
1 Stopbit
Code:
1 2 3 4
12345678901234567890123456789012345678901234567 8
k;tttttt;UUUUU;IIIII;CCCCCC;PPPPPP;TTTTT;y;zzz<cr><lf>
(48 Byte)
k Kanalnummer (Hier immer 1)
tttttt Zeit in Sekunden (neuer Datensatz beginnt bei 0)
UUUUU Spannung in mV
IIIII Strom in mA
CCCCCC Ladung in mAh
PPPPPP digitaler Zähler
y Status dezimal (0 = laden, 1 = entladen, 2 = Antriebsmessung,
9 = keine Aktion)
zzz Erweiterungen (im Moment einfach 000 dezimal)
Hinweise:
------------------------
1) Die Daten kommen im Sekundentakt. Die Zeit beginnt bei 0 Sekunden !
2) Wenn Spannung oder Strom nicht in 1000er Schritten zur Verfügung stehen,
muss der Wert passend ausgegeben werden (10V = 10000 im Datenformat)
3) Der Status kann passend gesetzt werden - muss aber nicht
4) Die Erweiterungen sind im Moment ungenutzt. Hier einfach 000 dezimal senden.
5) LogView startet die Aufzeichnung beim Erkennen einer 000000 in der Zeit und
einem Wechsel im Status von 9 auf 0 oder 1 oder 2.
Infos zu PPPPPP digitaler Zähler
Dieser Zähler kann mit einer beliebigen Zahl beschrieben werden. So kann man
hier z.B. einen Drehzahlmesser mit übertragen. Wichtig ist hier nur folgendes:
Der Zähler wird von LogView nicht angepasst. Es müssen also (falls erforderlich)
Berechnungen vom Logger vorgenommen werden!
-------------------------------------------------------------------------------}
Gruß, Holger
Universal Datenformat
dadurch variable Bytelänge der Daten) und/oder definierter Abschluss eines Datenblocks durch ein Sonderzeichen.
Zitieren
Die Formatierung selbstgestrickt, bringt auch nicht deutlich mehr Ersparnis, das habe ich schon in Opencharge geprüft.
