Hallo, wie in Beitrag "Re: Visualisierung von geloggten Daten" schon angedroht, habe ich mal begonnen, den csv-viewer auf FLTK zu portieren, um ihn nativ unter Linux laufen lassen zu können. Das Projekt ist noch in einem frühen Stadium, daher hier und nicht in der Codesammlung. Begonnen habe ich damit, den Unterbau neu zu schreiben, mittlerweile hab ich auch den "Kern" des Programmes transplantiert und angepasst. Auch wenn die Funktion bisher rudimentär ist, wollte ich es schon mal vorstellen, damit man sich vorstellen und drauf einrichten kann, wie es weitergehen soll. Sprache der Benutzeroberfläche ist bisher stümperhaftes Englisch, später sollen andere per Textdatei Sprachen geladen werden können; Arbeitstitel ist bisher banal "plot" (Name der fertigen Programmdatei). Was geht schon? Grundfunktionen zum Öffnen der Datei im Standardformat (muster.csv); Zoomen, Ändern der Schriftgröße über Menü; Scrollen über die Buttons; Ausgabe in PostScript-Datei unter Linux (derzeit noch feste "test.ps" im atuellen Verzeichnis, wegen meiner Faulheit beim Testen); rudimentäre Druckausgabe unter Linux, im Hochformat; quer hab ich noch nicht hinbekommen, evtl über die Treibereinstellungen, mein PDF-Druckertreiber gibt dies als Voreinstellung nicht her, den Papierdrucker wollte ich deswegen nicht vom Schrank holen. Die Änderungen am Unterbau sollten schnell deutlich werden, wenn man mal das Fenster größer/kleiner zieht, oder ggf. mal die Schriftgröße ändert. Was kommt als Nächstes? Erstmal die restlichen Funktionen aus dem Originalprogramm, einschließlich der einknöpfbaren Konverter. Zum Zeitrahmen kann ich noch keine Versprechen machen, bisher geht es aber besser voran, als ich ursprünglich dachte, die nächsten Wochen sind allerdings schon etwas verplant. Zum Kompilieren, sind im src-Archiv auch die passenden shell-scripte ("c" und "c.bat"). Benötigt wird das FLTK https://de.wikipedia.org/wiki/Fast_Light_Toolkit und ein passender c-Compiler, idealerweise der gcc, oder MinGW für Windows. mfG Edit:Typo
Hab die Darstellung jetzt so umgebaut, das der horizontale Zoomfaktor nicht mehr Sekunden/Pixel, sondern Sekunden für gesamten Bildschirmausschnitt ist, genauso wie vorher schon die vertikale Skalierung. Damit bleibt das Zeitfenster immer gleich, auch wenn Bildschirmfenster vergrößert/verkleinert wird und ausgedruckt/als PostScript ausgegeben wird damit auch der gleiche Ausschnitt. Benutzung - horizontal vergrößern/verkleinern: Plus/Minustasten oder Strg-Mausrad; - horizontal scrollen: Pfeil links/rechts oder Mausrad; - vertikal vergrößern/verkleinern: Bild hoch/runter; - vertikal scrollen: Pfeil hoch/runter; mfG
Bin mal wieder ein paar kleine Schritte weiter gekommen. Wer das Programm unter Gnome einsetzen möchte, kann sich mit "Extras->Create Starter", eine Desktop-Datei im Nutzerprofil (.local/share/applications) erstellen lassen, dann ist eine Verknüpfung von Dateitypen möglich. Ansonsten erstmal Korrekturen/Feinschliff. mfG
Ist mir doch noch böser ein Patzer durchgerutscht: wenn keine Datei geöffnet war, weil man das Programm "einfach so", ohne zu öffnende Datei aufgerufen hat, ist es abgestürzt. Ist mir so nicht aufgefallen, weil ich es immer mit Datei aufgerufen hab, ist jetzt korrigiert. Jetzt merkt sich das Programm auch die wichtigsten Einstellungen (Fenstergröße, Position, Zoomeinstellungen der letzten bis zu 20 Dateien), in der Datei $HOME/.config/csvplot.conf (Linux), oder %APPDATA%\csvplot.conf (Windows). Ist aber immernoch Einiges zu tun...
Hallo, R. M. schrieb: > wie in Beitrag "Re: Visualisierung von geloggten Daten" schon > angedroht, habe ich mal begonnen, den csv-viewer auf FLTK zu portieren, > um ihn nativ unter Linux laufen lassen zu können. bitte entschuldige meine vermutlich dumme Frage, aber was ist das Ziel des Projekts? Ich meine, CSV-Dateien kann ich mit Open- oder LibreOffice lesen und anzeigen, mit Gnuplot plotten, mit Python und Kommandozeilenwerkzeugen wie csvkit verarbeiten, berechnen, visualisieren, mit Pandas analysieren, mit FDW sogar als Postgres-Tabelle einbinden... Versteh' mich nicht falsch, ich kenne "csv-viewer" nicht, habe ich da etwas verpaßt, was kann dieses Wunderding? Und warum -- nur der Neugierde halber -- braucht es dazu ein kompiliertes C++-Programm? Beim Lesen von CSV-Dateien ist bei mir meistens der Disk- oder Network-I/O der Flaschenhals, nicht der Parser. Und wenn es schon C++ sein soll, warum benutzt Du keinen fertigen Parser wie Boost::Tokenizer?
Sheeva P. schrieb: > bitte entschuldige meine vermutlich dumme Frage, aber was ist das Ziel > des Projekts? Ich meine, CSV-Dateien kann ich mit Open- oder LibreOffice > lesen und anzeigen, mit Gnuplot plotten, mit Python und > Kommandozeilenwerkzeugen wie csvkit verarbeiten, berechnen, > visualisieren, mit Pandas analysieren, mit FDW sogar als > Postgres-Tabelle einbinden... Ich habe jetzt echt lange im Strafgesetzbuch gesucht, ich habe aber nirgends eine Stelle gefunden, in der nur solchen Wunderkindern wie dir erlaubt wäre, CSV Dateien anzeigen zu lassen. Die CSV Dateien die ich kürzlich mal hatte, konnte man eben nicht mit OpenOffice öffnen, da es nach 10 Minuten noch immer damit beschäftigt war, die Datei zu lesen. Ja, und ich habe dann Gnuplot genommen, mit dem ich schon 20 Jahre nix mehr gemacht habe. Hat halt eine Zeit gedauert bis ich so halbwegs was angezeigt bekommen habe. Da wäre der CSV-Viewer eventuell hilfreich gewesen (wenn es mit 100000 Zeilen umgehen kann).
Ich schließe mich der Aussage an. Hatte früher des Öfteren mit schlecht formatierten csv zu tun, die man noch umständlich bearbeiten musste. Mit einem Zwischenprogramm in C habe ich das erstal sortieren müssen, um es importfähig zu bekommen. So ein Programm kann schon ein Vorteil sein, insbesondere, wenn man man Daten in großen Mengen von Testgeräten bekommt, aufarbeiten und archivieren muss. Ich habe das immer in Access-Datenbanken gemacht, damit ich wenigstens ab erfolgtem Import der Daten automatisierte Berichte anfertigen konnte. Werde das Projekt mal im Auge behalten.
Fritz G. schrieb: > Die CSV Dateien die ich kürzlich mal hatte, konnte man eben nicht mit > OpenOffice öffnen, da es nach 10 Minuten noch immer damit beschäftigt > war, die Datei zu lesen. Tja, es halt immer wieder faszinierend, wie schwer sich sogar erfahrene Informatiker in renommierten Unternehmen damit tun, korrekte CSV-Dateien zu liefern. > Ja, und ich habe dann Gnuplot genommen, mit dem ich schon 20 Jahre nix > mehr gemacht habe. Hat halt eine Zeit gedauert bis ich so halbwegs was > angezeigt bekommen habe. > Da wäre der CSV-Viewer eventuell hilfreich gewesen (wenn es mit 100000 > Zeilen umgehen kann). Der csv-viewer kann also mit kleinen, kaputten CSV-Dateien umgehen? Damit wäre meine Frage schon beantwortet gewesen, ganz ohne StGB.
Jürgen S. schrieb: > Ich schließe mich der Aussage an. Hatte früher des Öfteren mit schlecht > formatierten csv zu tun, die man noch umständlich bearbeiten musste. Mit > einem Zwischenprogramm in C habe ich das erstal sortieren müssen, um es > importfähig zu bekommen. Warum in C? Sowas schreit doch nach einer Skriptsprache?!
Über den Sinn und Zweck des Projektes, hatte ich mich im Eröffnungspost nicht ausgelassen, da ich davon ausgegangen bin, das es nur für Diejenigen relevant sein dürfte, die den CSV-Viewer nutzen. Im verlinkten Faden ist dies bereits ausführlich diskutiert worden. Daher bitte ich diejenigen, die für die Aufgabenstellung bessere Lösungen haben, für den Verlust an Lebenszeit um Verzeihung. Daher hier nachgereicht, eine kurze Zusammenfassung: Ziel ist die grafische Darstellung von Messwertreihen, aus geloggten Dateien, ohne erst Importdialoge abzuarbeiten. Bei mir sind dies u.A. Daten aus MCS-51 Rechnern, welche über ein, ursprünglich für Windows geschriebenes Programm ausgelesen und in Dateien geschrieben werden. Dies läuft derzeit unter WINE, werde ich später auch umschreiben. Wer heute FHEM auf einem RasPi einsetzt, wird es nicht benötigen, also einfach ignorieren. Bisher hab ich zur Anzeige den CSV-Viewer, ebenfalls unter WINE genutzt, da dort aber ohnehin noch offene Baustellen bestehen, hab ich mir Den, als erstes größeres Migrationsprojekt vorgenommen.
Sheeva P. schrieb: > Tja, es halt immer wieder faszinierend, wie schwer sich sogar erfahrene > Informatiker in renommierten Unternehmen damit tun, korrekte CSV-Dateien > zu liefern. Die Datei war korrekt aber für die meisten Programme zu groß.
restmuell schrieb: > Ziel ist die grafische Darstellung von Messwertreihen, Vielen Dank, dies und der verlinkte Thread erklären alles. ;-)
Fritz G. schrieb: > Die Datei war korrekt aber für die meisten Programme zu groß. Naja, Tabellenkalkulationen sind ja auch nicht für die Verarbeitung von großen Datenmengen gedacht, da gibt es andere Werkzeuge. Für eine reine, einfache Visualisierung, wie sie hier bezweckt wird, kenne ich leider auch nicht viel -- sogar Gnuplot wird mit größeren Datenmengen bald ziemlich langsam und macht dann keinen Spaß mehr, von seiner Bedienung und der dazu notwendigen Lernkurve einmal abgesehen. Aber es gibt eine Reihe sehr leistungsfähiger Analysewerkzeuge, bei denen die Visualisierung quasi "am Rande" mit abfällt. R ist bei Analysten und Statistikern sehr beliebt, ich selbst bin eher Python-zentriert und nutze iPython, numpy, scipy und Pandas, und zur Visualisierung die äußerst leistungsfähige Matplotlib. Das hat den Vorteil, daß ich große Datenmengen vor der Anzeige vorverdichten kann, was zwar zulasten der Genauigkeit geht, dafür aber eine viel schnellere Anzeige ermöglicht. Aber das ist natürlich auch mit einer ziemlichen Lernkurve verbunden, die sich nur lohnt, wenn man das öfter macht oder deutlich mehr will als eine reine Visualisierung. Insofern ist der Ansatz des OP sicher eine gute Idee, wenngleich mich mal interessieren würde, wie eine browserbasierte Umsetzung mit flot und AJAX sowie einer Vorverdichtung der auf das jeweilige Anzeigefenster performen könnte. Die gesamten Daten unverdichtet komplett in den Anzeigelayer zu laden ist ja nicht sehr sinnvoll, wenn die Datenpunkte am Ende so nahe beieinander liegen, daß man sie nicht mehr unterscheiden kann; das kostet nur Arbeitsspeicher und Rechenleistung im Anzeigelayer und ist nur dann sinnvoll, wenn man die Datenfenster nicht dynamisch nachladen kann. Na, das sind nur so ein paar Gedanken. Nachdem ich den Sinn des Projekts nun verstanden habe, werde ich es weiterverfolgen und wünsche viel Spaß und Erfolg bei der weiteren Entwicklung!
Bin jetzt so weit, das ich für mich das Originalprogramm in den wohlverdienten Ruhestand geschickt habe. Detaillierte Hinweise zum aktuellen Stand, siehe anhängendem PDF.
Mittlerweile sind auch andere Formate möglich, als Beispiel für einen "dicken Brummer", hab ich mal eine Aufzeichnung von meinem Rigol DS1052 mit dem Kalibratorsignal angehängt. Ausgepackt sind das 25MB oder reichlich 1 Million Zeilen (Messwerte). Der Zeitmaßstab ist hier Sekunden (time_format=1), 2 Kopfzeilen (head_lines=2), Trennzeichen ist Komma (separator_char=44). Zu den anderen möglichen Zeitformaten, siehe Anleitung. Für mich persönlich, ist die Sache damit weitestgehend abgeschlossen, der weitere Weg, ist damit auch von Euren eventuellen Anforderungen abhängig. mfG
Hallo, gelungenes Tool soweit. Ich wollte mal fragen, da ja anscheinend nicht weiter entwickelt wird an dem Programm ob du vielleicht den Source Code teilen würdest. MfG HopeSource
HopeSource schrieb: > Ich wollte mal fragen, da ja anscheinend nicht > weiter entwickelt wird an dem Programm Habe das Programm in täglicher Nutzung, es erfüllt bei mir seinen Zweck, bisher sind hier auch keine Änderungswünsche geäußert worden. HopeSource schrieb: > ob du vielleicht den Source Code > teilen würdest. Der steht in dem "src_[Datum-Uhrzeit].tar.gz"-Archiv. Dies lässt sich unter Windows u.A. mit dem Programm "7zip" öffnen. Kolja L. schrieb: > Unter W10 schleißt das Programm sofort, wenn ich eine CSV öffne :-( Wie sieht die Datei denn aus? Edit: Hab nochmal die Anleitung angehängt. Die hab ich scheinbar komplett vergessen. Dort ist auch beschrieben, wie die Datei aussehen sollte.
Hi, ich tue mir ziemlich schwer den csv-viewer auf macOS zu compilieren. Hat das jemand schon geschafft und könnte diesen Hier zur Verfügung stellen? Danke
Wenn man sich mal die Dokumentationen zum FLTK anschaut, scheint der MAC dort eigentlich überproportional gut vertreten zu sein, so das ich eigentlich auch davon ausgehen würde, dass das Programm lauffähig zu bekommen sein sollte. Da ich selbst aber bisher nur mit Linux und Windows zu tun hatte, kann ich leider keine eigene Erfahrung beisteuern. Ich gehe mal davon aus, das FLTK und ein geeigneter Compiler schon vorhanden ist, gibt es denn Fehlermeldungen?
Es ist das neue Zeitformat 5 (JJJJ-MM-TT hh:mm:ss) hinzugekommen.
Hi Ingo, ich bin auf deine beiden CSV-Viewer gestossen, sieht genau nach dem aus, was ich suche. Die Programme haben eine ordentliche Evolution hinter sich, auch von meiner Seite großes Lob. Leider werden mit keinem der beiden Programme die Daten komplett angezeigt. Der Aufbau meiner Daten ist simpel: 1.Zeile: "Kanal 1" (ohne Anführungszeichen) alle weiteren Zeilen: Wert zwischen 0 und 255, ASCII, abgeschlossen mit CrLf Ich habe etwa 6 Mio. Datensätze. Mit dem Konverter aus der alten CSV-Viewer Version konnte ich die Daten auch mit Zeitstempel versehen:
1 | Datum;Zeit;Spannung |
2 | 13.02.2018;18:16:7.000000;0.000000 |
3 | 13.02.2018;18:16:8.000000;206.000000 |
4 | ... |
Pro Sekunde ein Datensatz (ich weiß nicht woher der erste Datensatz mit 0 kommt, der taucht in meinen Daten nicht auf). Ich brauche eigentlich auch keinen echten Zeitstempel, da es sich um ADC-Werte handelt. Beide Programme zeichnen den Graphen bis etwa zehn Tage, danach passiert ein paar Sekunden nichts, dann wird wieder von vorn begonnen :/ Ich habe die Daten mit der Muster.csv Datei, welche ordentlich geladen wird verglichen: einzige Abweichung ist, dass die Zeiteinheit nur Sekunden umfasst und die Werte als Dezimaltrennzeichen ein Komma anstatt dem Punkt haben. Anpassen meiner Daten auf dieses Schema bringt leider auch keine Besserung. Habe auch mal die Daten auf den ersten Monat beschränkt, ebenfalls kein Ergebnis. Was übersehe ich? Oder bin ich einfach zu ungeduldig? Grüße
Hallo R.M. Danke nochmal! Ich habe alles so umgesetzt, wie es von Dir perfekt beschrieben wurde. Ich meine da noch ein Problem mit dem Zeitformat zu haben (siehe Screenshot). In der Datei findet sich dieses Format "DD.MM.JJJJ hh:mm". Zeitformat 5 (JJJJ-MM-DD hh:mm:ss) paßt demnach nicht. Ich habe einfach mal 1 bis 5 probiert => bei allen das gleiche Ergebnis. Welches Format könnte ich noch probieren? Gruß Sonnenspeicher
Sonnenspeicher schrieb: > In der Datei findet sich dieses Format "DD.MM.JJJJ hh:mm". > Zeitformat 5 (JJJJ-MM-DD hh:mm:ss) paßt demnach nicht. > Ich habe einfach mal 1 bis 5 probiert => bei allen das gleiche Ergebnis. > Welches Format könnte ich noch probieren? Das ist aber ulkig, im Beitrag Beitrag "Re: Visualisierung von geloggten Daten" hatte die Datei noch folgendes Format: TimeStamp;V(V);VS(V);I(A);CE(Ah);SOC(%);TTG(Minutes);ALARM;RELAY;H1(Ah); H2(Ah);H3(Ah);H4;H5;H6(Ah);H7(m);H8(V);H9(Seconds);H10;H11;H12;H13;H14;H 15(V);H16(V) 2018-04-15 11:45:23;59,377;0;124,475;0;100;- - -;"OFF";"OFF";-1041,465;0;-464,476;13;0;-18568,034;30,788;60,04;0;4;0;0; 0;0;0,001;0,004 2018-04-15 11:45:29;59,374;0;123,941;0;100;- - -;"OFF";"OFF";-1041,465;0;-464,476;13;0;-18568,034;30,788;60,04;0;4;0;0; 0;0;0,001;0,004 2018-04-15 11:45:33;59,422;0;126,45;0;100;- - -;"OFF";"OFF";-1041,465;0;-464,476;13;0;-18568,034;30,788;60,04;0;4;0;0; 0;0;0,001;0,004 > In der Datei findet sich dieses Format "DD.MM.JJJJ hh:mm". Hat sich das inzwischen geändert? entspricht(bis auf das Leerzeichen, statt dem Komma) fast dem Originalformat 0. Kann ich aber zufügen. Edit: Link zugefügt
Ralf schrieb: > Ich habe etwa 6 Mio. Datensätze. Mit dem Konverter aus der alten > CSV-Viewer Version konnte ich die Daten auch mit Zeitstempel > versehen:Datum;Zeit;Spannung > 13.02.2018;18:16:7.000000;0.000000 > 13.02.2018;18:16:8.000000;206.000000 > ...Pro Sekunde ein Datensatz (ich weiß nicht woher der erste Datensatz > mit > 0 kommt, der taucht in meinen Daten nicht auf). Ich brauche eigentlich > auch keinen echten Zeitstempel, da es sich um ADC-Werte handelt. Könnte sein, das im Konverter, die Anzahl der Kopfzeilen auf 0 konfiguriert ist, dann kommt die 0, aus dem vergeblichen Versuch, Daten aus der Kopfzeile, oder einer eventuell vorhandenen Leerzeile zu lesen; > Beide Programme zeichnen den Graphen bis etwa zehn Tage, danach passiert > ein paar Sekunden nichts, dann wird wieder von vorn begonnen :/ > > Ich habe die Daten mit der Muster.csv Datei, welche ordentlich geladen > wird verglichen: einzige Abweichung ist, dass die Zeiteinheit nur > Sekunden umfasst und die Werte als Dezimaltrennzeichen ein Komma anstatt > dem Punkt haben. Anpassen meiner Daten auf dieses Schema bringt leider > auch keine Besserung. Habe auch mal die Daten auf den ersten Monat > beschränkt, ebenfalls kein Ergebnis. Sollte eigentlich möglich sein, der Konverter kann eigentlich die Zeitstempel bei vorgegebenem Intervall selbst erzeugen, muss dann aber die Startzeit irgendwoher bekommen. Könntest ja mal eine (gezippte) Beispieldatei und deine Konverterkonfig einstellen, dann schau ich mal drüber. Hab mir die letzten Tage schon einige Gedanken gemacht, wie es hier weitergehen könnte, die müssen nur noch etwas reifen ;-)
R. M. schrieb: > Das ist aber ulkig,... > Hat sich das inzwischen geändert? > entspricht(bis auf das Leerzeichen, statt dem Komma) fast dem > Originalformat 0. Kann ich aber zufügen. > > Edit: Link zugefügt Ich bin mir keiner Schuld bewußt? Evtl. stolpere ich da später noch drüber. Soll ich "0" probieren oder welchen "Link" hast Du wo hinzugefügt?
Sonnenspeicher schrieb: > Ich bin mir keiner Schuld bewußt? > Evtl. stolpere ich da später noch drüber. > Soll ich "0" probieren oder welchen "Link" hast Du wo hinzugefügt? Der Link zeigt auf den Beitrag, in dem du die Beispieldatei hochgeladen hast. Mit dieser Datei (ohne den Kopf auf halber Höhe), und dem Zeitformat "5", habe ich die Beispiele aus der Anleitung erstellt.
Ich habe "0" probiert => geht auch nicht. Momentan fehlt mir eine Erklärung für das geänderte Zeitformat. Könntest Du etwas passendes mit der Bezeichnung "6" basteln? Mich würde auch sehr interessieren, welche Darstellungen "1"-"4" erfordern. So wie das in deiner PDF aussieht, gefällt mir das sehr gut.
R. M. schrieb: > Könntest ja mal eine (gezippte) Beispieldatei und deine Konverterkonfig > einstellen, dann schau ich mal drüber. Ich schick dir eine PN, ich möchte das Forum nicht mit unnötigen Daten vollmüllen. Das Ergebnis deiner Untersuchung würde ich dann hier posten, falls andere das gleiche Problem haben. Ralf
Sonnenspeicher schrieb: > Könntest Du etwas passendes mit der Bezeichnung "6" basteln? > Mich würde auch sehr interessieren, welche Darstellungen "1"-"4" > erfordern. Habe das Zeitformat 6 = "TT.MM.JJJJ hh:mm(:s)" eingebaut und noch einige Fehler berichtigt. Die Zeitformate sind u.A. in der anhängigen PDF-Anleitung beschrieben.
Jetzt komme ich voran :-) Die Zeitachse paßt jetzt und die Graphen werden dargestellt. Es lassen sich alle Kanäle ausschalten, beim einschalten der einzelnen benötigten Kanäle (Klick mit linker Maustaste auf den jeweiligen Kanal) erscheint jedoch nur ein "*", der Kanal bleibt aber aus. In Deinem PDF ist das leider nicht näher beschrieben. Mache ich da einen Fehler? Horizontal zoomen kann ich mit Linksklick ins Diagramm. Zurück klappt es mit rechter Maustaste und "gesamte Datei". Vertikaler Zoom geht mit Bild rauf und runter nicht. Mit den Cursor-Tasten kann ich in der Darstellung leider nur rauf oder runter wandern. Wie bekomme ich die Darstellung der y-Achse größer? Gruß Sonnenspeicher
Sonnenspeicher schrieb: > (Klick mit linker Maustaste auf den jeweiligen Kanal) > erscheint jedoch nur ein "*", der Kanal bleibt aber aus. Ein/Ausschalten mit Doppelklick, einfaches Klicken setzt die Markierung auf den Kanal (wird fett gezeichnet, der Stern markiert ihn in der Legende). Sonnenspeicher schrieb: > Wie bekomme ich die Darstellung der y-Achse größer? <Bild hoch> vergrößert vertikal <Bild runter> verkleinert, Bezugspunkt dafür ist die untere Grenze des Diagramms, <+> vergrößert horizontal <-> verkleinert Scrollen mit den 4 Pfeiltasten. Wenn das nicht funktioniert, kann man auch die Faktoren über den Einstellungsdialog erreichen, Zoom(hor) ist die Breite des Diagramms in Sekunden, Zoom(vert) ist die Höhe des Diagramms.
Jetzt habe ich den Dreh raus :-) Vielen Dank! Doppelklick - argh, das hätte ich aber auch mal probieren können. Nach dem einschalten der mir wichtigen Kanäle stellten sich alle Graphen als Gerade dar. Damit hätte ich nicht gerechnet und bin wieder ins Grübeln gekommen. Dann versucht zu zoomen und zu scrollen - und siehe da, es geht. Ich bin Dir sehr dankbar und werde mich jetzt intensiv damit auseinandersetzen. Gibt es eine Möglichkeit mich für Deine Mühen zu revanchieren? Gruß Sonnenspeicher
Warum nehmt ihr denn für so etwas nicht einfach GNUPLOT, das ist fertig und erprobt, gibt es für Linux, Windows, läuft auch auf Mac
bingo schrieb: > Warum nehmt ihr denn für so etwas nicht einfach GNUPLOT, das ist fertig > und erprobt, gibt es für Linux, Windows, läuft auch auf Mac Ist das auf deutsch und gibst Du mir Support bis es so funktioniert wie ich es benötige?
Sonnenspeicher schrieb: > bingo schrieb: >> Warum nehmt ihr denn für so etwas nicht einfach GNUPLOT, das ist fertig >> und erprobt, gibt es für Linux, Windows, läuft auch auf Mac > > Ist das auf deutsch und gibst Du mir Support bis es so funktioniert wie > ich es benötige? http://gnuplot.info/help.html wenig runterscrollen bis German Und was bekomme ich nun von Dir?
Hallo, dies ist eine CSV Datei von einem Bediengerät. Immer pro Wert eine Zeile. Kann so etwas dargestellt werden? Viel Grüße Ingo
Hallo Ingo, dies ist ein etwas spezielles Format, insbesondere was die Zeitstempel angeht. Hab dir mal einen Konverter dafür gebaut, damit kann die Datei in ein darstellbares Format umgewandelt werden. Hier in diesem Beispiel ist das Ergebnis der Umwandlung, die Datei "Ziel.csv". Im Anhang, die Quelldateien, ein Compile-script für Linux und eine Programmdatei für Windows. Diese wird aufgerufen mit conv_ellischnelli <quelldatei> dummy <zieldatei> Die eigenartige Syntax, mit dem Dummyparameter ist, damit du den Konverter auch (unter Windows) mit dem alten CSV-Viewer benutzen kannst. Dort benötigte der mitgelieferte Konverter an dieser Stelle eine Konfigdatei, die hier nicht benötigt wird. Ich hoffe mal, das alles korrekt funktioniert, die Zeitstempel haben mir ziemliche Rätsel aufgegeben, die Spalte "time_ms" enthält nicht etwa Milliselunden, sondern etwa Elftel Sekunden. Hier wäre noch interessant, um was für ein Gerät es sich handelt, könnte vielleicht für andere Besitzer gleicher Technik interessant sein.
Hallo zusammen, bin durch Zufall auf dieses super Tool gestoßen. Bis jetzt habe ich Excell und OpenOffice im Einsatz. Nun zu meinem Problem.... Es geht um das Zeitformat. Fast hätte Format "0" gepasst. Die CFV-Dateien werden von einem AVR-Net-IO mit einer alternativen Software auf eine SD-Karte geschrieben. Hier mal die ersten Zeilen von der CFV-Datei: Datum;Uhrzeit;Aussentemp.;Labor;Server1;Server2;Server3;Heizungskeller;V orlauf;Ruecklauf 2018.08.15;00:01:00;20,1;24,9;30,9;28,9;28,0;24,3;25,8;27,5 2018.08.15;00:02:00;20,2;24,9;31,0;28,9;28,0;24,3;25,8;27,5 Habe zum Test das Datum ins passende Format gebracht. Aber das ist auf Dauer keine Lösung. Schön wäre ein weiteres Format "7" für meine cfv-Dateien. Oder gibt es eine andere, einfache Lösung, das Datum anzupassen? Desweiteren stürzt das Progamm ab, wenn ich den Graph ausdrucken will. Was mache ich falsch? mfG Helmut
Helmut schrieb: > Datum;Uhrzeit;Aussentemp.;Labor;Server1;Server2;Server3;Heizungskeller;V > orlauf;Ruecklauf > 2018.08.15;00:01:00;20,1;24,9;30,9;28,9;28,0;24,3;25,8;27,5 > 2018.08.15;00:02:00;20,2;24,9;31,0;28,9;28,0;24,3;25,8;27,5 > > Habe zum Test das Datum ins passende Format gebracht. Aber das ist auf > Dauer keine Lösung. > Schön wäre ein weiteres Format "7" für meine csv-Dateien. Mache ich mich in Kürze bei, macht nicht viel Aufwand. Edit: warum sieht man Typos immer erst, nachdem man auf "veröffentlichen" geklickt hat?
Helmut schrieb: > einem AVR-Net-IO mit einer alternativen Software Ist die öffentlich? Wenn ja, wäre eine Quellenangabe nett. > Schön wäre ein weiteres Format "7" für meine csv-Dateien. Ist die "8" geworden, die "7" ist schon für "keine Zeitstempel, festes Intervall" genutzt. > Desweiteren stürzt das Progamm ab, wenn ich den Graph ausdrucken will. Hab es bei mir mal getestet, die Windows-Version unter WINE, auf den "PDF"-Drucker, dort funktioniert es. Welche Umgebung/Drucker nutzt Du?
Hallo, und Danke für die schnelle Reaktion. Werde gleich mal das Zeitformat "8" testen. AVR-Net-IO: Ich nutze die Version NetIO_Reloaded_V0.42c. Autor ist Thomas Schlitz und wurde seinerzeit (2014) im Forum von netio.de veröffentlicht. Leider gibt es dieses Forum nicht mehr. Falls jemand Interesse an diese Version hat, bin ich gerne bereit diese zuzuschicken. Drucker: Ich benutze Win7 und einen Canon MG5150. Werde es gleich mal mit dem "FreePDF" - Drucker testen. Schönen Gruß Helmut
Hallo, Das Zeitformat "8" funktioniert. Dummerweise befindet sich in der 1.Zeile zwischen "Datum" und "Uhrzeit" auch ein Semikolon. Dadurch erhält die erste Messwertkurve die Überschrift "Uhrzeit", obwohl es die "Aussentemp." ist. Datum;Uhrzeit;Aussentemp.;Labor;Server1;Server2;Server3;Heizungsraum;Vor lauf;Ruecklauf 2018.08.19;00:01:00;20,3;24,1;30,1;28,1;27,1;24,4;28,5;27,3 2018.08.19;00:02:00;20,3;24,1;30,1;28,1;27,1;24,4;28,5;27,3 Mit einem Editor ersetze ich das Semikolon durch ein Leerzeichen, und schon wird alles richtig dargestellt. Kann diese Besonderheit in der Kopfzeile in Verbindung mit dem Zeitformat "8" berücksichtigt werden? Ansonsten muss ich versuchen im Code vom NetIO das Ausgabeformat der csv-Datei zu ändern... Das Drucken klappt noch nicht. Wenn ich unter Datei "Drucken" anklicke, stürzt das Programm ab. Schönen Gruß Helmut
erst das Zuckerbrot... im Anhang die GUI-Texte in fr und it NB: diese Uebersetzungen sind frei Schnauze und nicht mit einschlaegigen Standards wie ISBN-13: 978-0-201-62216-4 abgeglichen; auch habe ich Umgang mit GUIs in fr und it nur so regelmaessig wie ein Papst stirbt... (in de ebenso :-)
@Helmut: hätte mir auch auffallen müssen, kümmere ich mich drum, @Kommandozeile vor dem Frühstück für Alle!: Danke für die Unterstützung! Mit dem Ausdrucken unter Windows, muss ich mal schauen, wo ich das testen kann.
...und nun die Peitsche! Ist es nicht an der Zeit dass dieses Programm die C Standardfunktionen strptime und/oder REGEX benutzt? Anders gefragt: vieviele Zeitformate sollen es noch werden? >>> https://linux.die.net/man/3/strptime >>> https://linux.die.net/man/3/REGEX Damit kann dann der Nutzer seinen Formatstring selber definieren ohne dass das Programm mehr binären RestMüll (pun intended) bekommen muss.
1 | 0: "%d.%m.%Y;%H:%M:%S\.\d\d" |
2 | 1: "%s" |
3 | 2: "\d{1,64}\.{0,9}" |
4 | 3: "\d{1,64}\.{0,9}" |
5 | 4: "\d{1,64}\.{0,9}" |
6 | 5: "%Y-%m-%d %H:%M:%S\.\d\d" |
7 | 6: "%d-%m-%Y %H:%M:%S\.\d\d" |
8 | 7: "" |
9 | 8: "%Y.%m.%d;%H:%M:%S\.\d\d" |
Kommandozeile vor dem Frühstück für Alle! schrieb: > die C Standardfunktionen > strptime und/oder REGEX benutzt? Danke, lese ich mich mal ein, hatte auch schon über den Formelparser aus dem alten Konverter nachgedacht. Bei Standardfunktionen befürchte ich auch nicht so gravierende Laufzeitauswirkungen, wie bei einem selbstgeschriebenen Formelparser.
Jetzt merkt man dass ich das Programm gar nicht wirklich benutze... Die millisekunden sind demnach optional. Das ist im PDF nicht so dokumentiert. > 0: "%d.%m.%Y;%H:%M:%S(\.\d\d)?" > 1: "%s" > 2: "\d{1,64}\.{0,9}" > 3: "\d{1,67}\.{0,6}" > 4: "\d{1,70}\.{0,3}" > 5: "%Y-%m-%d %H:%M:%S(\.\d\d)?" > 6: "%d-%m-%Y %H:%M:%S(\.\d\d)?" > 7: "" > 8: "%Y.%m.%d;%H:%M:%S(\.\d\d)?"
Tipp am Rande: um in die Syntax von strftime *strptime* und PCRE einzusteigen, erstmal mit Python rumspielen. Ist interaktiv! >>> https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior >>> https://docs.python.org/3/library/re.html
Kommandozeile vor dem Frühstück für Alle! schrieb: > Tipp am Rande: um in die Syntax von strftime *strptime* und *PCRE* > einzusteigen, erstmal mit Python rumspielen. Ist interaktiv! Würde es sich bei einem C++-Programm nicht eher empfehlen, eine moderne C++-Library wie Boost::Date_Time [1] zu benutzen? [1] https://www.boost.org/doc/libs/1_68_0/doc/html/date_time.html
Sheeva P. schrieb: > Kommandozeile vor dem Frühstück für Alle! schrieb: >> Tipp am Rande: um in die Syntax von strftime *strptime* und *PCRE* >> einzusteigen, erstmal mit Python rumspielen. Ist interaktiv! > > Würde es sich bei einem C++-Programm nicht eher empfehlen, eine moderne > C++-Library wie Boost::Date_Time [1] zu benutzen? > > [1] https://www.boost.org/doc/libs/1_68_0/doc/html/date_time.html Yeah, whatever. Es war mehr als Konzepthinweis gedacht. Wenn ich mir jedoch die Qualität/Struktur des bestehenden Quellcodes so anschaue... irgendwas mit Perlen und Schinkenlieferanten... Aber man wächst ja mit der Aufgabe :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.