Laden...

Projekt "Messdaten graphisch darstellen", suche Lösungsansätze

Erstellt von Locutus vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.833 Views
Locutus Themenstarter:in
68 Beiträge seit 2008
vor 6 Jahren
Projekt "Messdaten graphisch darstellen", suche Lösungsansätze

Hallo,

nach langer Abstinenz von .NET (Asche auf mein Haupt) habe ich nun mal wieder den Bedarf, da etwas zu programmieren. Mir geht es primär um die Architektur der Software (deswegen poste ich es hier, wenn das doch der falsche Ort ist, bitte darauf hinweisen).
Bisher hatte ich Applikationen programmiert, die relativ klein und überschaubar waren und den Zustand quick-but-dirty wahrscheinlich nur knapp überboten haben. Das was ich jetzt benötige, schreit nach einem ordentlichen Konzept und Vorplanung, sonst wird das nix.

Ich will also keine fertigen Lösungen vorgesetzt bekommen, sondern suche für das Projekt die passenden Stichwörter bzw. Lösungsansätze, mit denen ich mich dann beschäftigen kann, um das ganze zu realisieren.

Erst mal eine kurze Beschreibung um was es geht, und ggf. was ich durch die FAQ- bzw. Artikelsuche bzw. Forumrecherche, etc. schon an Ansätzen gefunden habe.
*Es sollen Messdaten graphisch dargestellt werden. *Die Daten kommen von einem Mikrocontroller. Schnittstelle ist aktuell eine serielle COM-Schnittstelle, ich möchte aber später USB implementieren, und dann nicht auf virtuelle COM-Schnittstellen beschränkt sein. *Die Anzeige der Daten sollte wahlweise Oszilloskop-artig (also mit Trigger-Funktion, etc.) oder fortlaufend mit Begrenzung der Anzahl angezeigter Datenwerte. *Es sollen mehrere Datenanzeigen möglich sein, denen Messwerte zugeordnet werden können (also z.B. insgesamt fünf Messwerte, zwei Datenanzeigen, drei Messwerte in die eine und zwei in die andere Anzeige oder auch ein Messwert auf mehreren Anzeigen). *Skalierung bzw. Modifikation der Messwerte vor graphischer Darstellung sollte möglich sein. *Die Darstellung der Messdaten soll einstellbar sein, z.B. die Farben der Datenlinien, Skalierung der Zeitachse, etc. *Die empfangenen Daten sollen gespeichert und auch geladen werden können (quasi offline-Betrieb). *Daten, die aus der Anzeige "herausfallen", bleiben erhalten, um Langzeitaufzeichnungen zu realisieren. *Die graphische Darstellung sollte auch gespeichert werden können (ideal für Dokumentationen). *Die Anzahl der Datenanzeigen, die Schnittstelleneinstellungen, etc. sollen ebenfalls gespeichert und geladen werden können, damit man schnell zwischen verschiedenen Messaufgaben wechseln kann. *Es soll auch möglich sein, benannte Telegramme bzw. Kommandos zu definieren und diese zu senden (z.B. um den Mikrocontroller zu einer Aktion zu veranlassen). *Das Datenformat der eingehenden Messdaten soll definierbar sein, also z.B. optionaler Header/Trailer, Anzahl Bytes und Datentyp pro Messwert, etc.) *...

So, hoffe ich habe nichts vergessen, aber die wichtigsten Dinge sind denke ich benannt. Die obige Liste beschreibt, was mir zu dieser Anwendung vorschwebt, aber nicht jeder Punkt bedeutet, dass ich dazu einen Lösungsansatz brauche. Es soll nur die Gesamtübersicht gegeben werden.

Nun zu den Ansätzen:
Die GUI muss ich bei so einer Anwendung strikt von der Logik trennen und separat laufen lassen, das ist mir klar. Es gibt hierzu ja auch sehr gute Artikel, das sollte vermutlich(tm) kein Problem sein. Bisher habe ich nur mit Windows Forms gearbeitet, sollte ich zeitgemäß WPF verwenden (oder gibt es etwas noch neueres)?

Für die graphische Anzeige habe ich das MS Chart Control im Auge. Das sollte für die Anzeige vermutlich ausreichen. Ich war auch am Überlegen, ZedGraph zu verwenden, sehe aber momentan nichts, was eher gegen das MS Chart Control bzw. eher für ZedGraph spricht. Hat da jemand Erfahrungswerte?

Für die Schnittstellen dachte ich daran, ein fest implementiertes SerialPort Control für die COM-Schnittstelle zu verwenden, für die spätere Implementierung von USB liebäugele ich damit, die Anwendung diesbezüglich PlugIn-fähig zu machen. Auch hierzu gibt es bereits einige Beiträge, ich denke auch hier brauche ich vorerst keine weitere Hilfestellung (sagt der Grünschnabel jetzt noch 😃 ).

Die Einstellungen der graphischen Anzeige selbst (z.B. Achsenskalierung, Beschriftungen, etc.) sollten auch kein Problem sein, ebenso wie die Vorskalierung der Messwerte. Ein Optionsdialog für die Farben, etc. sehe ich auch nicht als Problem, aber das dynamische Anlegen der Anzeigen macht mir noch ein bisschen Kopfzerbrechen. Ich dachte daran, ein Formular mit einer Anzeige zu definieren, und dieses Formular mehrfach zu instanzieren. Auf diese Weise kann der Benutzer sich so viele Anzeigen setzen, wie er möchte und diese auch munter hin und her schieben. Die Anzeigen führe ich in einem Array, ebenso wie die einzelnen Messwerte und deren Skalierungen. Für die Messwerte überlege ich, eine Klasse anzulegen, in der die Messwerte verarbeitet werden und welche die Skalierung, etc. übernimmt.
Das gleiche für die eingehende Datensätze.

Die empfangenen Daten würde ich beispielsweise als CSV o.ä. speichern. Aber bei den Einstellungen zu Anzahl der Anzeigen, Format der Eingangsdaten, Farben der Anzeige, Definition von Kommandos etc. bin ich etwas verwirrt. Einerseits wird für .NET von der Verwendung von INI/CFG-Dateien o.ä. abgeraten und man soll Einstellungen Anwendungs- bzw. Benutzerorientiert speichern (so habe ich zumindest das .NET-Modell verstanden), aber für so etwas wie auf ein Messprojekt bezogene Einstellungen finde ich kein .NET-Äquivalent. Dabei wäre etwas in der Art einer INI-Datei doch eigentlich das ideale Mittel - vom Benutzer les- und schnell anpassbar und einfach strukturiert (wenn man's nicht übertreibt). Oder ist genau dafür XML gedacht? Wenn ja, dann hätte ich endlich mal den Zweck von XML-Dateien verstanden 😃 Ich empfinde XML-Dateien aufgrund der Struktur mit den ganzen Tags etc. für so etwas zwar schlechter lesbar als die guten alten INI-Dateien, aber wenn das State-of-the-Art ist, dann verwende ich das.

Insgesamt sehe ich mindestens drei Threads in der Anwendung: Die GUI an sich, die Bedienung der Schnittstelle und die restliche Programmlogik.

Hmmm, ich glaube ich habe die wichtigsten Dinge geschildert, aber momentan schaue ich ja erst noch von ganz weit oben drauf.

Wie seht ihr das? Komme ich damit weiter? Oder ist mein Ansatz, wie ich das aufziehen möchte völlig falsch? Wie sieht die Vorarbeit/Planung/etc. für so ein Projekt aus, damit das was wird?

Ich bin gespannt auf Kritik, Vorschläge, Meinungen, etc.

Grüße

====================================
1001011010101010101101110101111000101010101010
Ich assimilier dich...
Und dich auch...
Ich mein's ernst!

P
441 Beiträge seit 2014
vor 6 Jahren

Grob umrissen hast du es ja schon.

Für WPF habe ich ganz gute Erfahrungen mit Oxyplot gemacht.

Zur Architektur bietet sich für WPF ja MVVM mehr als an.
Für das generelle würde ich dir empfehlen *abstrahiere die Datensammel Schnittstelle. Vielleicht kommt ja irgendwann noch einmal etwas Netzwerkbasiertes dazu *Speichere Daten zwischen, die du aktuell nicht mehr anzeigst. Nimm dafür etwas wie SQLite *Überlege ob es sinnvoll ist, gleichartige Daten von mehreren Geräten anzeigen zu können und schaffe deine Datenstruktur von Anfang an so

16.807 Beiträge seit 2008
vor 6 Jahren

Würde eine Einbettung von Power BI in eure Applikation in Frage kommen?
Wir machen damit sehr gute Erfahrungen.

Get started with Power BI Embedded sample

Locutus Themenstarter:in
68 Beiträge seit 2008
vor 6 Jahren

Hallo,

danke für die Tipps.

@Papst:
Oxyplot schaue ich mir an. Könnte ggf. für die Sache besser geeignet sein als MS Chart. Das MVVM-Konzept muss ich mir erst verinnerlichen, das würde die GUI-Trennung lösen.
Wegen der Schnittstelle, du meinst, ich soll die serielle Schnittstelle nicht direkt verwenden, sondern auch gleich kapseln? So dass die Applikation immer identisch die Daten erhält, ohne zu wissen, woher die Daten eigentlich kommen?
Das Zwischenspeichern der Daten hätte ich einfach über einen Buffer gelöst, die Daten bei Bedarf eben als CSV gespeichert. Eine SQLite-DB wäre für so etwas doch oversized, oder?
Guter Tipp, mehrere Datenquellen gleichzeitig verwalten zu können, ist notiert.

@Abt:
Danke für den Hinweis, ich schau mir das an.

Grüße

====================================
1001011010101010101101110101111000101010101010
Ich assimilier dich...
Und dich auch...
Ich mein's ernst!

U
16 Beiträge seit 2009
vor 6 Jahren

Hallo Locutus,

die Anforderungen kommen mir doch ziemlich bekannt vor 😃, in den letzten Jahren mache ich fast ausschließlich solche Anwendungen. Ich kann mal ein paar Eckepunkte meines/unseres Ansatzes und Erfahrungen aufführen:

*Wir setzten WPF ein. WPF ist zwar langsam in der Ausführung aber im Gesamtpaket (VS und Blend) doch die komfortabelste und leistungsstärkste Entwicklungsumgebung für Desktop Anwendungen die ich kenne. (Ich hatte in den letzten Tagen mal wieder mit MFC und C++ gearbeitet und allein ein ToolTip für ein Control zu erstellen ist richtig Tipparbeit)

*Das MVVM Pattern bietet sich für komplexe WPF Anwendungen an. Es bringt zwangsläufig Struktur in die Software. Es ist erst mal bei den grundsätzlichen Sachen nicht so kompliziert kann aber bei anspruchsvolleren Dingen schon sehr komplex werden, so dass viel Zeit dafür drauf gehen kann bis es das macht was es soll. Man sollte allerdings keine Religion daraus machen Code-Behind hat auch seine Berechtigung und kann für kleine Module entfilzter sein.
Außerdem wenn Du den Vorzug von genügend Kapazitäten und Ressourcen hast und Unit-Tests schreiben kannst/darfst/sollst ist es notwendig.

*Als Chart-UI Komponente setzen wir Telerik ein, kostet zwar einiges aber für das Geld kann man es keinesfalls selber schreiben, kann relativ viel und sie haben eine guten Support (vielleicht hilft Dir das weiter)

*Als strategischer Quantensprung hat sich erwiesen Plugins mit MEF einzusetzen (so wie hier). Auch bei der besten Planung und mit viel Erfahrung laufen die Dinge doch immer mehr oder weniger aus dem Ruder, bedingt durch neue Anforderungen. Mit Plugins kann man dem doch deutlich gegensteuern. Das ist jedenfalls meine Erfahrung.

*Als Datenspeicherung benutzen wir SQLEXPRESS und binden es mit EF 6.1 (6.1.2?) an. SQLEXPRESS kostet nichts und man darf es auch beim Kunden einsetzten. Es ist nun doch mal sicherer seine Daten in einer SQL DB zu speichern und hat auch den Vorteil das wenn es performancemäßig doch mal knapp wird kann man es auseinanderziehen, sprich den SQL Server auf eine andere Maschine legen.
Für kleinere Datenmengen (im KB Bereich) ist auch die C# XML Serialisierung echt cool und schnell. CSV ist oftmals eine Kundenanforderung für Export und so.

*Für die Serielle Schnittstelle wäre eine Abstraktion zu überlegen wir machen viel mit TCP Sockets und verwenden dazu MINA.Net die kann auch serielle Schnittstellen bedienen, allerdings bin ich noch nicht dazu gekommen es dafür mal auszuprobieren. Mit USB im industriellen Einsatz habe ich übrigens die schlechtesten Erfahrungen gemacht. Mit einer Schnittstelle geht es vielleicht noch doch kommen mehrere ins Spiel und längere Kabel kann es wirklich unangenehm werden. Bei uns hat so was die Probleme fast vollständig gelöst.

Viele Grüße und frohes Schaffen

Locutus Themenstarter:in
68 Beiträge seit 2008
vor 6 Jahren

Hallo uwalter,

da ich das Projekt eher für mich privat mache, sind Unit-Tests & Co. wahrscheinlich eher nicht auf dem Programm. Ich hätte es anfangs erwähnen sollen, dass es ein privates Projekt ist, sorry (irgendwas vergisst man doch immer).
Aus diesem Grund fand ich auch SQL als oversized. Ich muss mir das aber nochmal genau anschauen, denn die Daten als SQL zu speichern ist vielleicht doch nicht so abwegig. Ich könnte die komplette Messaufgabe inkl. Einstellungen der Kanäle etc. als SQL speichern und nur die reinen Daten bei Bedarf als CSV o.ä. exportieren.

MEF hatte ich auch schon auf dem Schirm, das möchte ich probieren. MINA hört sich gut an, ich werd das auch mal anschauen. Könnte auch einiges an Arbeit abnehmen.

Was USB angeht, die von dir genannten Probleme kenne ich hardwareseitig wenn eben schlecht geschirmte oder zu lange, über die Spezifikation hinausgehende Kabel verwendet werden. Grob gesagt für USB-HS max. fünf Meter, danach MUSS ein Hub verwendet werden. Steht auch so in der Spezifikation, aber viele Leute haben ein Verlängerungskabel in der Hand und denken sie könnten beliebig verlängern. Und dann kommt's auch noch drauf an, wie gut der USB-Schaltungsteil designed ist.
Treiberseitig kann auch viel falsch laufen, ich finde für reine USB-Seriell-Brücken die FTDI-Treiber immer noch am stabilsten. Und wenn es ein Mikrocontroller ist, der direkt USB integriert, sollte man sich den Sourcecode genau anschauen.

Wenn du sagst, dass dir das Projekt bekannt vorkommt, darf ich fragen, was genau du in der Richtung schon gemacht hast?

Grüße

====================================
1001011010101010101101110101111000101010101010
Ich assimilier dich...
Und dich auch...
Ich mein's ernst!

U
16 Beiträge seit 2009
vor 6 Jahren

Ja klar,

ich schreibe Software im Bereich der Nahinfrarotspektroskopie, da kommen Spektraldaten (Spektren) an, die per Chemometrie Messdaten liefern, die dann zeitaufgelöst als Chart z.B. dargestellt werden. Also im Prinzip so wie Du es anfangs beschrieben hast. Diese Daten werden gespeichert (in einer SQL DB) so dass man sie als Daten-Historie wider ansehen kann...

so ungefähr

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Locutus,

privat mache, sind Unit-Tests & Co. wahrscheinlich eher nicht auf dem Programm.

Auch wenn es privat ist, kannst du dir mit Unit-Tests eine Menge Ärger sparen und besser strukturierte SW schreiben. Zusätzlich kannst du dadurch eine Menge lernen. Die Vorteile von Unit-Tests wurde im Forum schon öfters behandelt, daher brauch ich hier nicht alles wiederholen, aber ich rate dir, auch wenn es privat ist, dennoch Unit-Tests zu verwenden.

Mit SQL Server ist es auch so. Overkill wäre es nur wenn die Daten nur im kB Bereich vorliegen, sonst eine super Chance etwas "richtig" zu gestalten und sich mit Technologien vertraut zu machen. Schadet ja nie 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

P
441 Beiträge seit 2014
vor 6 Jahren

Bezüglich CSV vs. SQL-Datenbank:
Gerade wenn du eine ganze Reihe von Daten speichern willst, die eine zeitliche Abhängigkeit haben (was auf Messdaten in jedem Fall zutrifft), finde ich eine CSV Datei unpraktisch.
Entweder nimmst du dir für das parsen der CSV eine passende Lib - diese deserialisieren meistens die komplette Datei, auch wenn du nur 2 Datenpunkte aus der Mitte oder vom Ende benötigst, oder du musst das komplette Handling selber schreiben, was den Vorteil einer Lib wieder zunichte macht. Dann doch lieber SQL (DBMS sei dabei erst einmal egal) und ein OR-Mapper, damit es einfach zu handeln geht.

C
1.214 Beiträge seit 2006
vor 6 Jahren

Mit SQL Server ist es auch so. Overkill wäre es nur wenn die Daten nur im kB Bereich vorliegen, sonst eine super Chance etwas "richtig" zu gestalten und sich mit Technologien vertraut zu machen.

Ich hab neulich mal wieder ein privates Projekt ausgegraben, bei dem ich den SQL Server verwendet hatte. Den hatte ich bei mir schon seit fünf Jahren nicht mehr drauf. Es hat Stunden gekostet, und ich fands auch total entnervend, die Datenbank wieder zum Laufen zu bekommen. Ich würde heute praktisch ausschließlich zu Embedded Datenbanken tendieren, die man weder installieren noch einrichten muss.

16.807 Beiträge seit 2008
vor 6 Jahren

Embedded Datenbanken sind nur für gewisse Szenarien geeignet - aber bestimmt nicht für das Reporting größerer Datenmengen.
Dafür wurde keine bestehende Embedded DB konzipiert oder ausgelegt.
Ich nutze sie auch gerne; aber bestimmt nicht für dieses Szenario hier.

SQL Server kann man heutzutage in 10 Minuten ohne Installation, sondern via Docker Container, problemlos betreiben.
Keinerlei Aufwand oder Risiko. Das ist keine Ausrede mehr.

Locutus Themenstarter:in
68 Beiträge seit 2008
vor 6 Jahren

Hallo zusammen,

vielen Dank für eure Beiträge. Sehr interessant, was an Vorschlägen kommt, und auch die jeweiligen Pro/Contra-Argumente. Ich finde das sehr aufschlussreich.

@uwalter:
Ja, das hört sich wie du auch gesagt hast verdächtig nach dem an, was ich vorhabe 😃

@gfoidl:
Ich hab mir das mit den Unit-Tests mal kurz(!) durchgelesen und musste feststellen, dass ich eine etwas andere Vorstellung hatte, was das eigentlich bedeutet. Es scheint nicht so arg aufwendig zu sein, wie ich ursprünglich dachte. Das genaue Konzept muss ich mir noch mal in Ruhe durchlesen, und auch schauen, dass ich dann die eigentliche Software auch passend schreibe (was mich, soweit ich gesehen habe, sowieso dazu zwingen würde, sauberer zu trennen - und das ist ja durchaus gewünscht).

Ich stimme zu, dass es sich anbietet, sich mit Datenbanksystemen "anzufreunden". Ob das nun SQL oder was anderes ist, sieht man ja dann. Was die Datenmenge angeht, für das eigentliche Projekt, für welches ich die Aufzeichnungen brauche, hätte ich im Bereich 10-100kBytes pro Messung veranschlagt, aber wenn die Empfehlung eine DB für größere Datenmengen ist, kann ich das gleich so machen, denn ich möchte die Software wieder verwenden können (deswegen ja auch der Wunsch, das ganze relativ flexibel zu halten).

@Papst, Coder007 & Abt:
Aus euren Antworten schließe ich, dass die Verwendung einer DB an sich nicht verkehrt ist, lediglich die verwendete DB kann "Probleme" bereiten.

Grüße

====================================
1001011010101010101101110101111000101010101010
Ich assimilier dich...
Und dich auch...
Ich mein's ernst!