Hier Beitrag "40/50MS/s AVR Digital Storage Oscilloscope" ist die Idee aufgekommen, eine geeignete Visualisierung für ein Selbstbau-DSO oder Logicanalyzer etc. auf Basis von Eclipse zu entwickeln. Dinge die vorher geklärt werden sollten: * Wer schreibt Schnittstellen für USB (libusbjava), RS232 (rxtx.org), usw. * Wer schreibt Visualisierungs-Widgets (Plotter, LEDs usw.) * Wie soll das Framework designt werden * Wie wird der Datenfluss geregelt: ** Läuft im Gerätetreiber ein Thread, der Daten durch die Verarbeitungskette bis zur Visualisierung schiebt? ** Läuft in der Visualisierung ein Thread, der Daten vom Gerät holt? ** Oder soll sich das Framework darum kümmern?
Hi Manuel, ich habe bereits Interesse angemeldet und würde mich erst mal für die Basisarbeit zur Verfügung stellen. Also das Interface zur Hardware. Ich warte zZ noch auf die Lieferung der Platine um die Schaltung aufzubauen, um dann die Kommunikation/Schnittselle mit dem PC zu realisieren. Ich denke der erste Schritt ist es die Daten von der Seriellen Schnittstelle zu lesen und in einem Puffer bereit zu stellen. Um sie dann als BufferedStream auszulesen und als Interface für weitere Verarbeitung auslesen zu können. Ein weiterer Schritt währe die RCP-Application aufzusetzen. Also des GUI zu designen. Der erste Schritt ist z.B. ein RPC mit einem Menü, wo die Datenschnittstelle konfiguriert werden kann. (USB/Seriell, Port, Übertragungsparameter, usw ) Im nächten Schritt natürlich die Darstellung. Da habe ich noch keine gute Idee, wie das aussehen kann. Wo würdest Du Dich bei der Entwicklung sehen, bzw. wo liegen Deine Stärken? Ich kann ein SVN-Repository auf meinem Server bereit stellen. Wir können aber auch gleich ein Projekt auf Sourceforge aufmachen. Nochwas: Allerdings habe ich nicht vor einen LabViewClone zu realisieren, das übersteigt meine zeitlichen Resourcen, sondern meine Vorstellung ist es, eine modulare Anwendung für die Hardware von Uli zu entwicklen. Mal sehen was daraus wid. Bis jetzt bist Du der einzige, der sich für das Thema interessiert. Also straigt forward. Gruß netdieter
Angehängte Dateien:
-
plot_neu.png
9,2 KB
Ich hab mir schonaml eine Komponente geschrieben welche Spannungsverläufe von der RS232 plottet könnte ich euch gern zur Verfügung stellen ist aber natürlich noch nicht sooo arg ausgereift... Sieht dan etwa so aus wie im Screenshot, hab das noch etwas verbesser aber gerade keinen aktuellen Screenshot vorliegen ;)
> Ich denke der erste Schritt ist es die Daten von der Seriellen > Schnittstelle zu lesen und in einem Puffer bereit zu stellen. Um sie > dann als BufferedStream auszulesen und als Interface für weitere > Verarbeitung auslesen zu können. Dafür hab ich schon fertige Eclipse-Plugins, die die libUSB und auch RXTX.org kapseln. Darauf kann dann ein Parser für die entsprechende Hardware aufsetzen. > Ein weiterer Schritt währe die RCP-Application aufzusetzen. Also des GUI > zu designen. Der erste Schritt ist z.B. ein RPC mit einem Menü, wo die > Datenschnittstelle konfiguriert werden kann. (USB/Seriell, Port, > Übertragungsparameter, usw ) > Im nächten Schritt natürlich die Darstellung. Da habe ich noch keine > gute Idee, wie das aussehen kann. > Wo würdest Du Dich bei der Entwicklung sehen, bzw. wo liegen Deine > Stärken? Eigentlich auch mehr im Lowlevel-Bereich. Visualisierung hab ich noch nicht so viel gemacht, aber wie man Eclipse-Views, Menüs, Property-Seiten und Wizards erstellt weiß ich. > Ich kann ein SVN-Repository auf meinem Server bereit stellen. Wir können > aber auch gleich ein Projekt auf Sourceforge aufmachen. Ich würde gleich SF.net vorschlagen, wenn wir uns auf einen Namen für das Projekt einigen können. > Allerdings habe ich nicht vor einen LabViewClone zu realisieren, das > übersteigt meine zeitlichen Resourcen, sondern meine Vorstellung ist es, > eine modulare Anwendung für die Hardware von Uli zu entwicklen. Mal > sehen was daraus wid. Bis jetzt bist Du der einzige, der sich für das > Thema interessiert. Da ist dann nicht mehr viel hin. Für einen Labview-Clone fehlt nur noch ein Editor mit dem man die Hardwareschnittstelle, evtl. Filter und die Ausgabe graphisch verbinden kann. Ich würde auch vorschlagen die Aufteilung in Projekte von Eclipse zu übernehmen. In einem Projekt könnte dann die konkrete Verschaltung von Hardwareschnittstellen mit Filtern und Anzeigeelementen gespeichert werden.
@Läubi: Das ist aber kein SWT mit Draw2D oder? Wenn dann sollten wir schon beim Eclipse Toolkit bleiben.
@Manuel Wie wäres mit dem Projektname: jLab?
Klingt gut. Alternativ vielleicht Labclipse oder Eclipse-Lab
Manuel Stahl wrote: > @Läubi: > > Das ist aber kein SWT mit Draw2D oder? Wenn dann sollten wir schon beim > Eclipse Toolkit bleiben. Ich hab keien Ahnung was du brauchst, das ganze ist einfach ein JLabel mit einem Icon drauf was dann auf ein Graphics2D Objekt zeichnet...
Wenn man auf die Sonnenfinsternis (Eclipse) verzichten kann gäbe es auch noch MyOpenLab (http://www.myopenlab.de/), kann einiges, was LabView auch kann, aber halt nicht alles und es ist wenn ich das richtig sehe nicht so einfach in was anderes zu integrieren. Aber es steht schon mal :) [edit] argl Da wurde es bereits ein paar Beiträge eher genannt, ich sollte lesen lernen!
Johannes Slotta wrote: > Wenn man auf die Sonnenfinsternis (Eclipse) verzichten kann gäbe es auch > noch MyOpenLab (http://www.myopenlab.de/), kann einiges, was LabView > auch kann, aber halt nicht alles und es ist wenn ich das richtig sehe > nicht so einfach in was anderes zu integrieren. Aber es steht schon mal > :) Das habe ich mir auch schon angesehen. Aber leider ist kaum Doku vorhanden, jedenfalls keine dich ich verstehe und die Sourcen sind auch ohne jegliche Inlinedoku. Und das nennet der Mensch auch noch Open Source.
Naja, ist halt nicht als OpenSource-Projekt gestartet. Und bei den Komponenten gibts einige, die halbwegs vernünftig dokumentiert sind, da muss man dann halt abschreiben. Nicht schön, aber was ich bisher mit rumgespielt habe ging irgendwie. Dass die meiste Doku nur auf spanisch verfügbar ist finde ich auch eine doofe Sache, aber es ist denke ich das ausgereifteste kostenlose Programm in dieser Richtung, das ich finden konnte. Also das müsst (und könnt) ihr mit dem Eclipse-Dingens toppen ;)
Hier schon mal die Plugins für RS232 (RXTX.org)...
Nochmal zum Thema Name: * jLab gibts schon: https://jlab.dev.java.net/ * Eclipse-Lab ist mir suspekt: http://www.angelfire.com/scifi/EclipseLab/ Bleibt noch Labclipse in Anlehung an Subclipse. Weitere Vorschläge?
Manuel Stahl wrote: > Nochmal zum Thema Name: > > > * jLab gibts schon: https://jlab.dev.java.net/ MIST!!!1elf! > * Eclipse-Lab ist mir suspekt: > http://www.angelfire.com/scifi/EclipseLab/ > > Bleibt noch Labclipse in Anlehung an Subclipse. Weitere Vorschläge? Labclipse klingt irgendwie nicht gut. Vielleicht nehmer wir einfach erst mal einen Arbeitsnamen wie zB nglab (von next Generation Lab)
Manuel Stahl wrote: > Hier schon mal die Plugins für RS232 (RXTX.org)... Danke, ich werde Deine Plugins verwenden. Ich erstelle mir erst mal eine Entwicklungsumgebung für das [[DSO von Uli Radig]] - Beitrag "40/50MS/s AVR Digital Storage Oscilloscope". Da ich die Hardware noch nicht aufgebaut habe, erstelle ich mit ein pseudo DSO mit meinem AVR-Board von Pollin. Dazu muss ich erst den Orginalcode umschreiben, so dass der AVR das Protokoll beherrscht und mir pseudo Daten liefert. Wenn Du vielleicht schon mal den RCP-Rahmen aufsetzen könnest? Oder wenn Du bereits was hast, nur her damit ;-) Gruß netdieter
Angehängte Dateien:
> Danke, ich werde Deine Plugins verwenden. > Wenn Du vielleicht schon mal den RCP-Rahmen aufsetzen könnest? OK, ein paar Sachen würde ich trotzdem gerne erst noch klären. Besonders die Frage vom Anfang: * Wie wird der Datenfluss geregelt: ** Läuft im Gerätetreiber ein Thread, der Daten durch die Verarbeitungskette bis zur Visualisierung schiebt? ** Läuft in der Visualisierung ein Thread, der Daten vom Gerät holt? ** Oder soll sich das Framework darum kümmern? * Wie sollen die Daten zwischen Device, Filter und UI ausgetauscht werden? ** byte[] ** InputStream / OutputStream ** eigene Objekte Im Anhang hab ich mal versucht die Namespaces etwas einzuteilen.
Hab mir zum Datenfluss noch ein paar Gedanken gemacht. Folgender Vorschlag: Das Visualisierungsmodul (z.B. Plotter) kann vom Device einen Frame mit vorgegebenem Startzeitpunkt, gewünschter Samplerate und Länge anfordern. Das Device versucht diesen zu liefern, muss aber die Parameter nicht zwingend einhalten, wenn dies nicht möglich ist (Daten liegen noch nicht vor, Samplerate zu hoch). Geliefert wird ein Frame-Objekt, das die nötigen Informationen enthält. Im Live-Modus versucht der Plotter z.B. immer den aktuellsten Frame zu bekommen. Frames können analog oder digital sein und einen beliebigen numerischen Typ haben (int, float ...). Ein Frame enthält außerdem Informationen über die X- und Y-Achse. Damit kann z.B. auch eine FFT mit der Frequenz als X-Achse dargestellt werden. Ein Device kann mehrere Channels haben, welche dann Frames liefern.
Manuel Stahl wrote: > Hab mir zum Datenfluss noch ein paar Gedanken gemacht. Folgender > Vorschlag: Vorschläge sind immer willkomme. > > Das Visualisierungsmodul (z.B. Plotter) kann vom Device einen Frame mit > vorgegebenem Startzeitpunkt, gewünschter Samplerate und Länge anfordern. > Das Device versucht diesen zu liefern, muss aber die Parameter nicht > zwingend einhalten, wenn dies nicht möglich ist (Daten liegen noch nicht > vor, Samplerate zu hoch). Geliefert wird ein Frame-Objekt, das die > nötigen Informationen enthält. Nach meiner Auffassung, sollte, das Visualisierungsmodul dumm sein. Es dient lediglich der Visualisierung. Es ist also mit einem Objekt verbunden, dass im Daten liefert, die es einfach darzustellen hat. > > Im Live-Modus versucht der Plotter z.B. immer den aktuellsten Frame zu > bekommen. Was ist ein Live Modus und was ein Frame? > Frames können analog oder digital sein und einen beliebigen numerischen > Typ haben (int, float ...). Wenn ich Frames als Objekte interpertiere, dann können die im Prinzip jeden Datatyp haben. Also ein Interface, dass eine abzählbare Datenmenge enthält und eine definierte Schnittstelle auf die Daten repräsentiert. >Ein Frame enthält außerdem Informationen > über die X- und Y-Achse. Damit kann z.B. auch eine FFT mit der Frequenz > als X-Achse dargestellt werden. Das sollte das VisObjekt tun. Im Idealfall dynamisch. Es kommen also Daten (Werte (U,I, oder was auch immer)) mit einem Zeitstempel an, und das VObj analysiert wie die Daten am besten darzustellen sind. > > Ein Device kann mehrere Channels haben, welche dann Frames liefern. Is klar. Zur Begrifflichkeit: Wir sollten ein Device als eine Datenquelle definieren die genau einen Eingang hat. Es gibt Filtermodule die mehrere Eingänge haben und die Eingänge mit der Filterregel verarbeiten. Diese haben genau einen Ausgang. Es gibt weiterhin VObjects, die das Ergebnis visualisieren. Diese haben zu den Dateneingang zusätzlich Steuereingänge, um die Darstellung dynamisch zu beeinflussen. Daraus folgen also auch Steuerobjekte die über Events eine Änderung den Filter oder VObjecte mitteilen. Ein Filter kann nur Filtern, ein Visualisierungsobjekt kann nur darstellen und eine Device kann nur Daten liefern. Gesteuert wir nur über Steuerobjekte. >* Wie wird der Datenfluss geregelt: >** Läuft im Gerätetreiber ein Thread, der Daten durch die >Verarbeitungskette bis zur Visualisierung schiebt? >** Läuft in der Visualisierung ein Thread, der Daten vom Gerät holt? >** Oder soll sich das Framework darum kümmern? <Brainstorm> Wenn das Teil diverse Module bedienen soll, dann kommen wir nicht um einen Dispatcher rum, der als Hauptinstanz den Datanfluss regelt. Oder eben ein inteligentes Design, das sich jedes Object per Konfiguration um seine Daten selbst kümmert. </Brainstorm> >* Wie sollen die Daten zwischen Device, Filter und UI ausgetauscht >werden? >** byte[] >** InputStream / OutputStream >** eigene Objekte Scheißegal, ja nach Anforderung kriegt jedes Objekt seine Daten. Wenn es sein muss, auch via Webservice ;-) Der Ansatz von MyOpenLab-http://www.myopenlab.de/ ist sicher nicht verkehrt. Wenn die Doku nicht so dürftig wäre, würde ich das Projekt sofort unterstützen. @Manuel: Es lohnt sich das mal anzusehen. Gruß netdieter
Dieter Engelhardt wrote: > Manuel Stahl wrote: >> Im Live-Modus versucht der Plotter z.B. immer den aktuellsten Frame zu >> bekommen. > > Was ist ein Live Modus und was ein Frame? So wie ich die Beschreibung vom DSO verstanden hab, richtet man einen Trigger ein, lässt es laufen und kann sich anschließend Ausschnitte aus dem Speicher holen. Ein Frame wäre dann so ein Ausschnitt. "Live" wäre dann die Möglichkeit mit der verfügbaren Bandbreite direkt Messwerte zu bekommen. >>Ein Frame enthält außerdem Informationen >> über die X- und Y-Achse. Damit kann z.B. auch eine FFT mit der Frequenz >> als X-Achse dargestellt werden. > > Das sollte das VisObjekt tun. Im Idealfall dynamisch. > Es kommen also Daten (Werte (U,I, oder was auch immer)) mit einem > Zeitstempel an, und das VObj analysiert wie die Daten am besten > darzustellen sind. Klär sollen nicht die Einstellungen der Achsen geliefert werden, aber zumindest die Einheit. Auch die X-Achse muss nicht zwingend eine Zeit sein. Das VisObjekt kann dann nachsehen ob es bereits eine Achse mit einer kompatiblen Einheit besitzt oder gegebenenfalls eine neue Achse erstellen (z.B. zwei Y-Achsen für U und I). >> Ein Device kann mehrere Channels haben, welche dann Frames liefern. > > Is klar. > Zur Begrifflichkeit: > Wir sollten ein Device als eine Datenquelle definieren die genau einen > Eingang hat. Dann gibt es aber keinen Unterschied zwischen Device und Channel. > Es gibt Filtermodule die mehrere Eingänge haben und die Eingänge mit der > Filterregel verarbeiten. Diese haben genau einen Ausgang. Hier taucht jetzt ein kleines Problem auf, wenn die Daten aktiv vom Device kommen. Wann soll der Filter neu berechnen? Erst wenn neue Daten auf allen Eingängen anliegen? Oder sobald sich ein Eingang geändert hat? > Es gibt weiterhin VObjects, die das Ergebnis visualisieren. > Diese haben zu den Dateneingang zusätzlich Steuereingänge, um die > Darstellung dynamisch zu beeinflussen. > Daraus folgen also auch Steuerobjekte die über Events eine Änderung den > Filter oder VObjecte mitteilen. Das klingt gut. Dann hat man ein schönes Model-View-Controller Konzept. Vielleicht können wir uns dem ganzen auch mal mit ein paar Anwendungsbeispielen nähern: 1. Ich will wie oben geschrieben eine Messung triggern und will diese anschließend analysieren. Dazu öffne ich ein Scope-View und das Control-View für das DSO. Dann verbinde ich das Scope mit dem DSO ohne Filter dazwischen. Das Triggern starte ich über das Control-View welches dem DSO über den Gerätetreiber Bescheid gibt. Soll der Gerätetreiber jetzt den kompletten Speicher auslesen und an das Scope schicken? Oder nur soviele Messpunkte, wie das Scope Pixel in x-Richtung hat (schneller)? 2. Ich will mir live die FFT eines Signals ansehen. Dazu kann ich (im Control-View des FFT?) einstellen, welchen Frequenzausschnitt ich haben möchte. Anhand dessen kann der FFT Filter die nötige Framelänge (abhängig von der unteren Frequenz) und die Samplerate (abhängig von der oberen Frequenz) berechen und an den Gerätetreiber weitergeben. Sobald Daten eintreffen schickt der Gerätetreiber diese an den FFT Filter, dieser Filtert und schickt das Ergebnis an den Scope-View. > Der Ansatz von MyOpenLab-http://www.myopenlab.de/ ist sicher nicht > verkehrt. > Wenn die Doku nicht so dürftig wäre, würde ich das Projekt sofort > unterstützen. > @Manuel: Es lohnt sich das mal anzusehen. Hab schon mal grob reingeschaut, aber man muss sich alles anhand des Quellcodes erschließen, oder hast du noch eine Skizze über die Zusammenhänge gefunden?
Ich werd es mir bei Gelegenheit anschauen. Hab grad relativ wenig Zeit da ich grad die Hardware für das DSO aufbaue.
Manuel Stahl wrote:
> Hier schon mal die Plugins für RS232 (RXTX.org)...
Hi Manuel,
kannst Du mir mal ne Instalationsanleitung für die RS232 zukomme lassen?
Gruß
Dieter
@ netdieter > kannst Du mir mal ne Instalationsanleitung für die RS232 zukomme lassen?0 Mach doch mal was deine Namen andeutet, finde die Infos im Netz. > Hier schon mal die Plugins für RS232 (RXTX.org)... Also bei mir funktioniert es. Die Informationen wie man es macht hab ich von RXTX.org ! Oder soll ich es kopieren und hier posten?
Hallo, also bei mir startet die neue Version (vom 24.02.2009) nicht. Ich habe 2 Rechner und auf beiden erscheint nur der Eclipse-Splashscreen. Nach 5 Sekunden geht der weg und nichts tut sich... Sind beides WinXP Maschinen. Gruß Majus
Thread beobachten
Seitenaufteilung abschalten
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.