Projekt: Virtuelle Instrumente an serielle Schnittstelle

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Für die kommenden Wintertage suche ich noch eine Beschäftigung und 
möchte mir ein Tool zur Visualisierung von Microkontroller Daten anhand 
von virtuellen Instrumenten erstellen. Wie so etwas aussehen könnte habe 
ich mal anhand des beigefügten Bildes skizziert.
Prinzip: Der MC sendet Daten in einem festgelgten Format an den PC 
(Windows) und meine Software stellt die dekodierten Daten an den 
zugewiesenen Instrumenten dar. Sowas gibt es zwar schon als Payware, ich 
kenne aber bisher keine Freeware die sowas macht. Aber da lass ich mich 
auch eines Besseren belehren.
Wenn euch das Projekt interessiert, könnt ihr gerne eure Ideen 
beisteuern. Allerdings sollte es nicht ausufern und überschaubar 
bleiben.

Siehe auch meine bisherigen Freeware Projekte hier im Forum:
Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden"
Beitrag "Daten von der seriellen Schnittstelle einfach darstellen"

[Quak (Gast)]

Albert M. schrieb:
> Sowas gibt es zwar schon als Payware, ich
> kenne aber bisher keine Freeware die sowas macht.

Hoffen wir mal, dass nicht morgen einer kommt, der deinen Job fuer lau 
macht.

[Martin S. (sirnails)]

Ohh, bevor ich zum Strom kam, war ich bei der Software - und da hat man 
sofort einen Haufen an Ideen. Du scheinst ja recht fit zu sein - deine 
bisherigen Sachen sehen sehr gut aus; funktional, wie auch die Optik!

Wieviel Zeit planst Du denn ein? Ich hätte da schon eine "kleine" Idee, 
aber das macht natürlich auch nur Sinn, wenn man entsprechend viel 
Entwicklungsarbeit investieren möchte.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Quack

Das musst Du mir jetzt mal erklären. Welchen Job und was für lau?
Falls Du es wirklich nicht verstehst: Das wird eine Freeware.

[Karl H. (kbuchegg)]

... schöne Grafik
(und aus Erfahrung weiß ich, dass das eine Heidenarbeit ist, so etwas so 
zu programmieren, dass es gut aussieht, weitgehend konfigurierbar ist 
und dann auch noch fehlerfrei arbeitet)

Doch, sowas, denke ich, können wohl viele brauchen. Ein Programm, mit 
dem man sich ein Frontend auf einfache Art und Weise zusammenklicken 
kann.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Martin Schwaikert schrieb:
> Wieviel Zeit planst Du denn ein? Ich hätte da schon eine "kleine" Idee,
> aber das macht natürlich auch nur Sinn, wenn man entsprechend viel
> Entwicklungsarbeit investieren möchte.

Für mein Projekt SerialComGrapher habe ich alles zusammengerechnet ca. 
14 volle Tage investiert. Für das neue Projekt wird wohl ungefähr die 
selbe Zeit oder etwas mehr rauskommen, natürlich über einige Monate 
verteilt.

[Karl H. (kbuchegg)]

Ich hab jetzt den anderes Projekt nicht im Detail studiert. Was ich mir 
wünschen würde, währen Elemente, denen ich mit einer eingebbaren Formel 
irgendwelche einfache Logik unterjubeln kann.
zb. Ein LED-Anzeigeelement. Mit einer Formel kann ich ich zb bestimmen, 
dass die LED bei einem angebundenen Messwert von 287 einschalten soll 
und darunter ausschalten. Wobei ich in diesem Fall das eben nicht mit 
einem Schwellwert erledigt sehen möchte, sondern dass ich tatsächlich 
(ähnlich wie bei Excel) einen kleinen Formelparser dahinter liegen habe, 
mit dem ich auch Werte zuerst verknüpfen kann, die mglw. aus einer 
Datenbank kommen etc.

Wenn du sowas sowieso schon im Angebot hast, dann will ich nichts gesagt 
haben.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Karl Heinz Buchegger schrieb:
> ... schöne Grafik
> (und aus Erfahrung weiß ich, dass das eine Heidenarbeit ist, so etwas so
> zu programmieren, dass es gut aussieht, weitgehend konfigurierbar ist
> und dann auch noch fehlerfrei arbeitet)
>
> Doch, sowas, denke ich, können wohl viele brauchen. Ein Programm, mit
> dem man sich ein Frontend auf einfache Art und Weise zusammenklicken
> kann.

So gross ist der Arbeitsaufwand auch nicht. Ich programmiere in Delphi 
und habe für die virtuellen Instrumente fertige Delphi-Componenten. 
Daher bleibt "nur" der Aufwand für die Dekodierung und Verteilung des 
Datenstromes und die Logic für die freie Platzierung der Instrumente.

[Martin S. (sirnails)]

Also das erste, was mir in diesem Zusammenhang gefallen würde, wären n 
Instrumente, die frei anzuordnen sind, sodass man etwas "Grafik" 
hineinbringen kann. Die Elemente könnten dann über Datenquellen 
angeschlossen werden, wobei eine Datenquelle ein Objekt ist, dass aus 
dem Com-Datenstrom generiert wird, und z.B. alle Pakete beinhaltet, die 
mit 0x25 anfangen.

Also in etwa: Der Prozessor schickt 0x01 0x05 0x02 0x10, das ganze wird 
dann dekodiert und auf Instrument 1 (0x01) der Wert 5 angezeigt, auf 
0x02 der Wert 16.

Im Grunde ein stark abgespecktes Labview.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Martin Schwaikert
Genau so habe ich mir das vorgestellt.

[W.S. (Gast)]

Albert M. schrieb:
> Prinzip: Der MC sendet Daten in einem festgelgten Format...

O je, Steinzeit-Ideen. Was passiert, wenn du was Neues brauchst? Oder 
wenn du neben der Visualisierung auch noch ne Kommunikation brauchst?

Denk dir lieber ein flexibles Protokoll für die serielle Schnittstelle 
(oder VCP über USB) aus. So eines, wo man ohne Mühe die Synchronisation 
wiederfindet, falls der Nachwuchs mal über die Strippe gestolpert ist 
und was einigermaßen beliebig erweiterbar ist.

Ein Beispiel von vielen: NMEA

Albert M. schrieb:
> Ich programmiere in Delphi

HA! noch einer. Da sind wir ja schon zwei in diesem Forum...

W.S.

[spess53 (Gast)]

Hi

>> Ich programmiere in Delphi

>HA! noch einer. Da sind wir ja schon zwei in diesem Forum...

Drei.

MfG Spess

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

W.S. schrieb:
> Albert M. schrieb:
>> Prinzip: Der MC sendet Daten in einem festgelgten Format...
>
> O je, Steinzeit-Ideen. Was passiert, wenn du was Neues brauchst? Oder
> wenn du neben der Visualisierung auch noch ne Kommunikation brauchst?
>
> Denk dir lieber ein flexibles Protokoll für die serielle Schnittstelle
> (oder VCP über USB) aus. So eines, wo man ohne Mühe die Synchronisation
> wiederfindet, falls der Nachwuchs mal über die Strippe gestolpert ist
> und was einigermaßen beliebig erweiterbar ist.

Meine Aussage bezieht sich auf einen festgelegten Präfix als 
Kennzeichnung für die einzelnen Instrumente, meinetwegen A bis Z oder 
wie auch immer.
Zuerst wird es mal nur Einbahnstrasse sein, MC > PC. Danach könnte man 
auch die andere Richtung PC < MC ins Auge fassen, was ja wahrscheinlich 
sinnig ist. Aufgeblähte Protokolle sind meines Erachtens nicht unbedingt 
notwendig. Es reicht ein Start- und Endezeichen für einen kompletten 
Zyklus aus. Damit wird auch die Synchronisation nach Übertragungsabruch 
problemlos wiedergefunden.
Je einfacher umso besser, z.B. so (die Zahlen stehen für Messwerte):

Start A24536 B45378 C83643 Ende

oder

Start Z93643 C74352 K73844 A73843 Ende

Das bekommt im MC auch jeder Hobbybastler hin.
Oder wo siehst Du darin ein Problem?

[hoppla ! (Gast)]

es muss ein Master-Slave Protokol sein, der Pc ist der Master. Dann muss 
es ueber einen (logischen) Bus laufen, dh die Geraete muessen adressiert 
sein, sonst sind sie ja nicht unterscheidbar. Ich wuerd dynamische 
Adressierung vorziehen. Also muessen folgende Standard Commands 
implementiert sein.
-Devicedescriptor , als binary und als text, damit man erkennt, was fuer 
ein Device
-Userdescriptor, als binary und als text - damit kann man identische 
einheiten unterscheiden kann.
- Adressierungsmechanismus, neue Geraete werden gefunden und adressiert

vorzugsweise :
- Das Benutzermenu als Baumstruktur wird vom Device geliefert.

fuer schnelle Geschichten:
- Gemeinsamen Referenzclock auf den Bus
- gemeinsamen Trigger auf dem Bus

Ich mach solches Zeug in Hardware und aufm Pc mit Delphi

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

hoppla ! schrieb:
> es muss ein Master-Slave Protokol sein, der Pc ist der Master. Dann muss
> es ueber einen (logischen) Bus laufen, dh die Geraete muessen adressiert
> sein, sonst sind sie ja nicht unterscheidbar. Ich wuerd dynamische
> Adressierung vorziehen. Also muessen folgende Standard Commands
> implementiert sein.
> -Devicedescriptor , als binary und als text, damit man erkennt, was fuer
> ein Device
> -Userdescriptor, als binary und als text - damit kann man identische
> einheiten unterscheiden kann.
> - Adressierungsmechanismus, neue Geraete werden gefunden und adressiert
> vorzugsweise :
> - Das Benutzermenu als Baumstruktur wird vom Device geliefert.
> fuer schnelle Geschichten:
> - Gemeinsamen Referenzclock auf den Bus
> - gemeinsamen Trigger auf dem Bus


Nö - das ist unnötig Aufwendig.
Was meinst Du denn wie viele virtuelle Instrumente ich anbiete oder 
wieviele überhaupt sinnvoll sind? Mehr als 10 bis 15 sind das nicht, 
wenn überhaupt. Schau mal auf meinen Screenshot und denk Dir noch einige 
dazu. Als Bezeichner reichen da die Buchstaben A bis Z aus und alle 
Instrumente (Kanäle / Messdatenquellen) sind damit unterscheidbar.
Deine Master Slave Problematik sehe ich auch nicht:
Der MC schickt was oder der PC schickt was. Da braucht man über Master 
oder Slave nicht nachdenken und eine gemeinsame Referenzclock auf dem 
Bus wird auch nicht benötigt.

Es fängt schon an wie bei meinem vorigen Projekt SerialComGrapher. Alles 
wird viel zu kompliziert gesehen und Bedenken getragen. Keep it simple!
Das ist KEIN Projekt für die Industrie und hat auch nicht den Anspruch, 
sondern für Bastler die ihre Messdaten einfach visuell darstellen wollen 
ohne komplizierte Protokolle für dem Microkontroller programmieren zu 
müssen.

[Sascha E. (baracuss)]

Ich bin schon sehr gespannt auf dein Projekt.
Habe auch schon öfters nach so einer Software gesucht.
Werde das aufjedenfall ausprobieren wenn es fertig ist.

Schön wäre es wenn die Instrummente frei Verschiebar wären.
Zudem wäre auch die Komunikation von PC > MC praktisch.
So wäre es ganz schön wenn man z.B. ein Paar Virtuelle Schalter hatt.

Eine eingebaute Screenshot Funktion wäre auch ganz Praktisch.
So das man einfach ein Bild machen kann von seinen Messwerten.

Evt. auch die aufzeichnung von Werten wäre gut.
Die man dan nacher z.B. nach Excel expotieren kann, für anwendungen wie 
nen Datenloger z.B.

Ich hoffe ich denke jetzt nicht schonwieder viel zu Kompliziert.

[randy (Gast)]

...als anregung fuer die GUI:

im DMX feld benutze ich die opensource software Q Light Controller

http://qlc.sourceforge.net/ (MacOS X, Linux, Win32)

damit kann man z.b. lineare regler, buttons etc.. recht einfach
"zusammenklicken". vielleicht sind diese routinen fuer das projekt
hier auch brauchbar?

gruss,
-- randy

[Hoppla ! (Gast)]

Ja, Bezeichner A-Z sind genuegend. Aber wie kommen die ins Geraet ? 
Erstens muessen die im Geraet gespeichert sein, und zweiten aussen am 
Geraet sichtbar. Dann moechte man vielleicht zwei, drei identische 
Geraete ansteuern. Die brauchen also verschiedene Bezeichner. Auch 
aussen sichtbar.
Dann moechte man zu einem laufenden System noch eins hinzufuegen, ohne 
alles neu booten zu muessen. Oder eines auswechseln.

Jedes Geraet hat seine eigene Schnittstelle am PC ? Kann man machen. 
Dann hat man einen Tisch voll gestaffelter USB Hubs und an jedem einen 
USB-to-Serial. Und wenn man dann ein Neues einsteckt, muessen alle neue 
im PC numeriert werden. Das macht der PC zwar von selbst, die laufende 
Messung ist aber kaputt. Besser waere alle Geraete an einem Bus laufen 
zu lassen, der Hot-plug kann, ohne Aufstand. Vielleicht verschwinden ein 
paar Messwerte, aber die Messung muss nicht abgebrochen werden. Sobald 
man einen Bus hat kann nicht jeder Teilnehmer etwas plappern. Und so 
weiter.
Der Witz daran ist, es ist eher guenstiger als jedem seine eigene 
Schnittstelle am PC zu geben.

[Markus R. (maggus)]

Nur zur allgemeinen Information: Eine LabVIEW Studentenversion gibts für 
ca. 20 Euro, alternativ beim Buch "Einführung in LabVIEW" dabei oder 
ganz einfach in der nächsten Uni-Bibliothek.

[Martin S. (sirnails)]

Markus R. schrieb:
> Nur zur allgemeinen Information: Eine LabVIEW Studentenversion
> gibts für
> ca. 20 Euro, alternativ beim Buch "Einführung in LabVIEW" dabei oder
> ganz einfach in der nächsten Uni-Bibliothek.

Jap, das ist schon richtig. Aber nicht jeder hat Lust auf Labview und 
außerdem ist das COM-Getue mit Labview auch nicht unbedingt der größte 
Spaß. Vor allen Dingen, dass es riesen Probleme mit nicht geschlossenen 
COM-Verbindungen gibt.

[Hoppla ! (Gast)]

Aaaahhhhh ... Labview. Extrem unpraktisch. Klotzig aufm Rechner und 
unheimlich invasiv. Labview laesst eine ganze Menge Prozesse aufm 
Rechner laufen, auch wenn das dazugehoerige Programm gar nicht laeuft. 
Und die sind schwer wieder loszuwerden. Labview ist also quasi als Virus 
anzusehen.
Nebenbei hat man keine Kontrolle ueber den Ablauf des Geschehens.

[./. (Gast)]

Wen die $25 nicht stoeren, kann sich ja mal MakerPlot ansehen.

[Martin S. (sirnails)]

./. schrieb:
> Wen die $25 nicht stoeren, kann sich ja mal MakerPlot ansehen.

Wen die 50.000 Euro nicht stören, kann sich ja mal nen gebrauchten 
Porsche ansehen. Ist zwar auch ganz nett, tut hier aber ebensowenig zur 
Sache.

[obscurity (Gast)]

Ich würde heute keine Desktoplösung für diesen Zweck mehr neu anfangen 
zu Programmieren. Vielmehr würde ich die virtuellen Instrumente in 
html/javascript bauen und per Ajax die Daten von einem selbst 
geschriebenen Webserver holen der gleichzeitig auch die Kommunikation 
mit der Sensorhardware und das Logging abwickelt. Das kann man als 
portablen Code für alle gängigen Betriebssysteme schreiben. Da auf der 
Serverseite die GUI entfällt ist das wesentlich entspannter zu 
programmieren. Als Client dient dann nur noch ein beliebiger Webbrowser. 
Der Server kann z.B. auf einer Fritzbox o.ä. laufen, ne serielle 
Schnittstelle gibts da denke ich.
Der große Vorteil von so einer Lösung ist, dass jedes Handy und Tablett 
als Frontend verwendet werden kann. Zu irgendwas müssen die Geräte von 
heute ja in 2 Jahren noch nützlich sein wenn man sich gerade das 
übernächste neue angeschaft hat.
Wenn sich für so ein Konzept Mitstreiter finden würden, wäre ich dabei. 
Das ganze noch mit Plugins für unterschiedliche Sensorquellen (CAN, 
Ethernet, SPI...) und ein WebLabView wäre geboren. Als 
Programmiersprache käme aber nur sowas in Frage was sich auch gut von 
Windows uber Linux(x86 und Arm)sowie Osx portieren lässt. Da hier auch 
Zugriffe auf die Hardware eine Rolle spielen bleibt fast nur C/C++ 
übrig.

[Martin S. (sirnails)]

Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz 
auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in 
vielerlei Hinsicht auch noch unsagbar langsam.

[Hoppla ! (Gast)]

Hardwarezugriffe ? Nee. Braucht's nicht. Ein einzelnes Serialport 
genuegt. Dieses Serialport kann auch Ethernet, Bluetooth, WLan sein. 
Denn Javascript/Ajax, kann auch Serial/Hardwarezugriffe  Zugriffe 
machen. Eine Frage der Library.

Vergesst das mal. Immer mit diesem C/C++...

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hoppla ! schrieb:
> Ja, Bezeichner A-Z sind genuegend. Aber wie kommen die ins Geraet ?
> Erstens muessen die im Geraet gespeichert sein, und zweiten aussen am
> Geraet sichtbar. Dann moechte man vielleicht zwei, drei identische
> Geraete ansteuern. Die brauchen also verschiedene Bezeichner. Auch
> aussen sichtbar.
> Dann moechte man zu einem laufenden System noch eins hinzufuegen, ohne
> alles neu booten zu muessen. Oder eines auswechseln.
>
> Jedes Geraet hat seine eigene Schnittstelle am PC ? Kann man machen.
> Dann hat man einen Tisch voll gestaffelter USB Hubs und an jedem einen
> USB-to-Serial. Und wenn man dann ein Neues einsteckt, muessen alle neue
> im PC numeriert werden. Das macht der PC zwar von selbst, die laufende
> Messung ist aber kaputt. Besser waere alle Geraete an einem Bus laufen
> zu lassen, der Hot-plug kann, ohne Aufstand. Vielleicht verschwinden ein
> paar Messwerte, aber die Messung muss nicht abgebrochen werden. Sobald
> man einen Bus hat kann nicht jeder Teilnehmer etwas plappern. Und so
> weiter.
> Der Witz daran ist, es ist eher guenstiger als jedem seine eigene
> Schnittstelle am PC zu geben.

Ich glaube Du hast mein Konzepz noch immer nicht verstanden :)
Es gibt da keine physischen Geräte in die Bezeichner hinein müssten. 
Noch gibt es gestaffelte USB-Hubs und mehrere Schnittstellen.

Nochmal für Dich:
Du hast EIN Mikrocontroller-Board mit analogen und digitalen 
Ein-/Ausgängen. Das schickt dem PC über EINEN USB/Seriell-Wandler Daten 
von den Ein-/Ausgängen über ein simples Protokoll. Ab und an schickt 
auch der PC mal (wenige) Daten zum MC-Board, z.B. Schalter in der GUI 
betätigt.
Die "Instrumente" sind nichts anderes als die bildliche Darstellung in 
der GUI am PC, die den einzelnen analogen und gitalen I/O des MC 
zugeordnet werden.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

obscurity schrieb:
> Ich würde heute keine Desktoplösung für diesen Zweck mehr neu anfangen
> zu Programmieren. Vielmehr würde ich die virtuellen Instrumente in
> html/javascript bauen und per Ajax die Daten von einem selbst
> geschriebenen Webserver holen der gleichzeitig auch die Kommunikation
> mit der Sensorhardware und das Logging abwickelt. Das kann man als
> portablen Code für alle gängigen Betriebssysteme schreiben. Da auf der
> Serverseite die GUI entfällt ist das wesentlich entspannter zu
> programmieren. Als Client dient dann nur noch ein beliebiger Webbrowser.
> Der Server kann z.B. auf einer Fritzbox o.ä. laufen, ne serielle
> Schnittstelle gibts da denke ich.
> Der große Vorteil von so einer Lösung ist, dass jedes Handy und Tablett
> als Frontend verwendet werden kann. Zu irgendwas müssen die Geräte von
> heute ja in 2 Jahren noch nützlich sein wenn man sich gerade das
> übernächste neue angeschaft hat.
> Wenn sich für so ein Konzept Mitstreiter finden würden, wäre ich dabei.
> Das ganze noch mit Plugins für unterschiedliche Sensorquellen (CAN,
> Ethernet, SPI...) und ein WebLabView wäre geboren. Als
> Programmiersprache käme aber nur sowas in Frage was sich auch gut von
> Windows uber Linux(x86 und Arm)sowie Osx portieren lässt. Da hier auch
> Zugriffe auf die Hardware eine Rolle spielen bleibt fast nur C/C++
> übrig.

Deine Überlegungen in Ehren, da mag man mal so machen, aber ich glaube 
Du unterschätzt den Aufwand für Deine Lösung gewaltig.
Du sparst nichts an Aufwand, indem Du das Ganze in Richtung Webserver 
verschiebst. Du verschiebst das GUI nur eine Instanz weiter. Das GUI ist 
der extreme Aufwand, da Du dann nicht auf fertige Tools für die 
virtuellen Instrumente zurückgreifen kannst. Hast Du eine Ahnung wieviel 
Mann-Monate es benötigt um nur einen Satz ansehnlicher virtueller 
Instrumente zu erstellen mit jeweils hunderten von Properties?
So ein Projekt ist als One-Man Show nicht zu stemmen.

[Hans M. (hansilein)]

Cooles, Projekt!

Schau mal, es gibt schon ein etabliertes Protokoll, Firmware und PC 
Software, darauf könntest Du aufbauen:
http://firmata.org/wiki/Main_Page

Eine tollere, konfigurierbare Oberfläche fänden bestimmt viele Leute 
gut,
firmware für weitere Controllerfamilien auch.

[Hoppla ! (Gast)]

Aha. Sorry. Das hab ich schon lange. Fuer ein neues Device klopp ich mir 
auf die schnelle jeweils ein GUI mit meinen Delphi Komponenten zusammen. 
Meine Komponenten:

vom System :
Button, Memo, Slider, Progress bar, ..

eigene Komponenten:
-XY Graph, mit reelen und komplexen Datentypen, fuer log, loglog und 
anderer Anzeige.
-diverse online bearbeitungsfunktionalitaeten der Daten
-Loggerfunktionalitaet
-Prozessueberwachung, zB Abschalten und Restarten
-..

Das bisherige ist nicht so schwierig.

Ich hab alles an einem Bus. Mit einem Controllerservice, sodass mehrere 
unabhaengige GUIs auf mehrere Devices am Bus zugreifen koennen. Routing 
des Serialports ueber Sockets, sodass das GUI nicht aufm lokalen Rechner 
sein muss.

Fuer Tablets wuerd ich gerne mal ein Bluetooth interface bauen. Also mit 
Bluetooth auf den seriellen Bus. Und fuer schnellere Devides fehlt mir 
noch der Synch & Trigger auf dem Bus.

[obscurity (Gast)]

Martin Schwaikert schrieb:
> Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz
> auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in
> vielerlei Hinsicht auch noch unsagbar langsam.

Falls du da meine Vorschlag meinst, kann ich nur sagen sagen: Schuß 
nicht gehört. Im  Moment betreibe ich meine Heizungs- und Haussteuerung 
auf diese Art und Weise. Der komplette statisch gelinkte Server besteht 
aus einer einzigen Datei und ist ca. 180kb bzw. 780kb mit ssl gross. Der 
macht die komplette CAN-Kommunikation mit meinen Hausnetz, das Logging 
der Daten und den http/https-Server der die Daten als auch den 
html/js-Teil bereitstellt. Das passt auch ganz entspannt auf einen 
Rasperry.

Ich bin hier aber weit davon entfernt eine Diskussion darüber los zu 
treten zu wollen. Jeder soll es so machen wie er will. Und die Klappe 
halten wenn man von was keine Ahnung hat.


Hoppla ! schrieb:
> Denn Javascript/Ajax, kann auch Serial/Hardwarezugriffe

Im Browser? Scherzkeks! Und dieses unsägliche NodeJs ist das letzte mit 
dem ich sowas auf der Serverseite schreiben würde. Die ganzen C++ Hasser 
sind aber die die das geil finden.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hoppla ! schrieb:
> Aha. Sorry. Das hab ich schon lange. Fuer ein neues Device klopp ich mir
> auf die schnelle jeweils ein GUI mit meinen Delphi Komponenten zusammen.
> Meine Komponenten:
> vom System :
> Button, Memo, Slider, Progress bar, ..
> eigene Komponenten:
> -XY Graph, mit reelen und komplexen Datentypen, fuer log, loglog und
> anderer Anzeige.
> -diverse online bearbeitungsfunktionalitaeten der Daten
> -Loggerfunktionalitaet
> -Prozessueberwachung, zB Abschalten und Restarten
>
> Das bisherige ist nicht so schwierig.
> Ich hab alles an einem Bus. Mit einem Controllerservice, sodass mehrere
> unabhaengige GUIs auf mehrere Devices am Bus zugreifen koennen. Routing
> des Serialports ueber Sockets, sodass das GUI nicht aufm lokalen Rechner
> sein muss.
> Fuer Tablets wuerd ich gerne mal ein Bluetooth interface bauen. Also mit
> Bluetooth auf den seriellen Bus. Und fuer schnellere Devides fehlt mir
> noch der Synch & Trigger auf dem Bus.

Super,
wenn Du das schon alles hast, stell es uns hier einfach zur Verfügung 
und ich brauche mir die Mühe das Rad neu zu erfinden nicht mehr machen.
Bin mal gespannt auf Deine Software!

[HennesB (Gast)]

Ich werfe mal folgenden Link in den Raum:

http://www.mitov.com/products/instrumentlab#overview


Vor Jahren gab es das mal kostenfrei für Delphi 7 und war ganz nett zu 
benutzen. Keine Ahnung wie es heute ist.

[obscurity (Gast)]

Albert M. schrieb:
> Du verschiebst das GUI nur eine Instanz weiter. Das GUI ist
> der extreme Aufwand, da Du dann nicht auf fertige Tools für die
> virtuellen Instrumente zurückgreifen kannst. Hast Du eine Ahnung wieviel
> Mann-Monate es benötigt um nur einen Satz ansehnlicher virtueller
> Instrumente zu erstellen mit jeweils hunderten von Properties?
> So ein Projekt ist als One-Man Show nicht zu stemmen.

Das ist mir schon klar. Ich habe das für mich auch nur soweit gemacht 
wie ich es brauche. Nicht mehr und nicht weniger. Allerdings gibt es mit 
html5 einen Standard den es für GUIs auf den verschiedenen Systemen 
leider nicht gibt. Und auf den Systemen muss nichts installiert sein 
ausser einem überall vorhandenen Browser. Mit was macht man denn eine 
GUI die auf allen Rechnern, Handy und Tabletts läuft? Mir fällt da 
leider nichts ein was auch nur im Ansatz überall laufen würde. Delfi ist 
in dieser Beziehung das letzte.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

obscurity schrieb:
> Das ist mir schon klar. Ich habe das für mich auch nur soweit gemacht
> wie ich es brauche. Nicht mehr und nicht weniger. Allerdings gibt es mit
> html5 einen Standard den es für GUIs auf den verschiedenen Systemen
> leider nicht gibt. Und auf den Systemen muss nichts installiert sein
> ausser einem überall vorhandenen Browser. Mit was macht man denn eine
> GUI die auf allen Rechnern, Handy und Tabletts läuft? Mir fällt da
> leider nichts ein was auch nur im Ansatz überall laufen würde. Delfi ist
> in dieser Beziehung das letzte.

Sorry, aber das geht mir zu weit an meinem Thema vorbei.
Ich erstelle eine Software für den PC unter Windows. Da interessieren 
mich Webbrowser-Lösungen für Tabletts und Handys eher wenig.
Du kannst ja dafür einen eigenen Thread aufmachen.
Und was in Delphi geht bist Du auch nicht auf dem neuesten Stand. Geh 
mal auf die Embarcadero Seite :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

HennesB schrieb:
> Ich werfe mal folgenden Link in den Raum:
> http://www.mitov.com/products/instrumentlab#overview
> Vor Jahren gab es das mal kostenfrei für Delphi 7 und war ganz nett zu
> benutzen. Keine Ahnung wie es heute ist.

Danke für den Hinweis. Ja Mitov kenne ich schon lange. Ist super aber 
mir zu teuer. Die wollen 150 Euro, mit Source Code 510 Euro. Eine freie 
Version gibt es da wohl nicht mehr.

[Armin Klose (Gast)]

Schau dir mal uCProbe an, macht inn Prinzip das was du willst, und gibt 
es auch für verschiedene Prozessoren.

http://micrium.com/tools/ucprobe/trial/

Für Studi´s und Non-Profit ist es wohl kostenlos, ich habe da mal ein OS 
von denen gekauft, da war es auch dabei. Ist auf jedenfall eines der 
besten was ich da kenne, da ist das Protokoll und die GUI schon fertig. 
Super zum Debuggen von embedded SW.

mfg Armin

[Martin S. (sirnails)]

obscurity schrieb:
> Martin Schwaikert schrieb:
>> Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz
>> auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in
>> vielerlei Hinsicht auch noch unsagbar langsam.
>
> Falls du da meine Vorschlag meinst, kann ich nur sagen sagen: Schuß
> nicht gehört.

Obach Bürschle, sonst ziag'ad Dir'd Ohrawatschla lang!

> Im  Moment betreibe ich meine Heizungs- und Haussteuerung
> auf diese Art und Weise. Der komplette statisch gelinkte Server besteht
> aus einer einzigen Datei und ist ca. 180kb bzw. 780kb mit ssl gross. Der
> macht die komplette CAN-Kommunikation mit meinen Hausnetz, das Logging
> der Daten und den http/https-Server der die Daten als auch den
> html/js-Teil bereitstellt. Das passt auch ganz entspannt auf einen
> Rasperry.

Yea, muss ich jetzt auch noch eine Heizung mit dran hängen, um ein paar 
Werte über die serielle Schnittstelle zu übertragen?

Was Du vorschlägst mag mit Sicherheit technisch interessant sein, und in 
Deiner Umgebung gut funktionieren, ist hier aber totale Übertötung!

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Armin Klose schrieb:
> Schau dir mal uCProbe an, macht inn Prinzip das was du willst, und gibt
> es auch für verschiedene Prozessoren.
> http://micrium.com/tools/ucprobe/trial/
> Für Studi´s und Non-Profit ist es wohl kostenlos, ich habe da mal ein OS
> von denen gekauft, da war es auch dabei. Ist auf jedenfall eines der
> besten was ich da kenne, da ist das Protokoll und die GUI schon fertig.
> Super zum Debuggen von embedded SW.

Da gibt es nur eine Trail, lauffähig 45 Tage und ansonsten verraten die 
alle Preise nur auf Anfrage, was vermuten lässt, dass die Software wohl 
im 4 stelligen Euro Bereich liegt. Ansonsten sieht es ja nicht schlecht 
aus.

[obscurity (Gast)]

Martin Schwaikert schrieb:
> Yea, muss ich jetzt auch noch eine Heizung mit dran hängen, um ein paar
> Werte über die serielle Schnittstelle zu übertragen?

Sag ich doch, du hast nichts verstanden. Es ging nicht darum um ein paar 
Werte über die serielle Schnittstelle zu übertragen. Es ging darum die 
zu Loggen und zu Visualisieren. Und mein Vorschlag war das in einen 
Serverteil und eine GUI die im Browser läuft zu teilen um damit 
universeller zu sein. Wenn beides auf der selben Maschine läuft ist es 
vergleichbar mit einer nativen Applikation. Man hat aber die Option den 
Server auf beliebiger Hardware laufen zu lassen und die verschiedenen 
anderen Geräte als Frontend zu verwenden. Bei mir läuft der Serverteil 
auf einem NAS der sowieso an ist und als Interface wird ein einfaches 
CAN-USB-Interface verwendet. Der Rasperry war nur als Möglichkeit 
genannt.

Was deine sinnlosen Kommentare damit zu tun haben erschließt sich mir 
nicht.

[Philipp P. (pippo_88)]

Albert M. schrieb:
> Für die kommenden Wintertage suche ich noch eine Beschäftigung und
> möchte mir ein Tool zur Visualisierung von Microkontroller Daten anhand
> von virtuellen Instrumenten erstellen. Wie so etwas aussehen könnte habe
> ich mal anhand des beigefügten Bildes skizziert.
> Prinzip: Der MC sendet Daten in einem festgelgten Format an den PC
> (Windows) und meine Software stellt die dekodierten Daten an den
> zugewiesenen Instrumenten dar. Sowas gibt es zwar schon als Payware, ich
> kenne aber bisher keine Freeware die sowas macht. Aber da lass ich mich
> auch eines Besseren belehren.
> Wenn euch das Projekt interessiert, könnt ihr gerne eure Ideen
> beisteuern. Allerdings sollte es nicht ausufern und überschaubar
> bleiben.
>
> Siehe auch meine bisherigen Freeware Projekte hier im Forum:
> Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden"
> Beitrag "Daten von der seriellen Schnittstelle einfach darstellen"


Hallo Albert,

klingt nach einem spannenden Projekt!
Wünsch dir viel Ausdauer und Erfolg bei deinem Vorhaben - kenne mich 
persönlich nicht mit der Materie aus, aber vielleicht hilft dir diese 
Infoseite (grad ergooglet) : http://serielleschnittstelle.com/

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Ist ja echt putzig :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Ich habe mal übers Wochenende was gebastelt.
Was bereits funktioniert:

- Erzeugen, Darstellen und Verschieben per Mouse von Instrumenten
  Die Instrumente können in der Grösse verändert und
  beliebig gemischt werden. Die Parameter können auch nachträglich
  editiert werden.
  Alle in den Check-Boxen markierten Instrumente werden angezeigt.

- Zuordnung von Kanälen(Instrumenten):
  Alle möglichen Instrumente haben eine feste Kennung,
  wie z.B. #05 (siehe Bild 2). Vom Mikrocontroller werden
  die Werte als Strings dann im folgenden Format gesendet:
  '#KanalNr'Messwert, . . . . . ,'#KanalNr'Messwert'CRLF

- Die Trend Anzeige kann bis zu 4 Kanäle darstellen

- Mit Virtuellen Kanälen können Berechnungen durchführt werden
  und diese dann einem Instrument zugeordnet werden.

- Es gibt Rückmelde Kanäle (Gruppe #80) die Informationen
  vom PC zum Mikrokontroller schicken können.

[Abdul K. (ehydra)]

Mir gefallen deine drei Projekte und vor allem deine Arbeitseinstellung 
betreffend Effektivität. Weiter so! Das scheint brauchbare Tools zu 
ergeben.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Ein paar möglicherweise interessante Links:

http://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

http://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture

http://sigrok.org/wiki/Main_Page

Letztere könnte dir beim Interpreterscheiben helfen (sources zum 
nachschaun)...

73

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Abdul
> Mir gefallen deine drei Projekte und vor allem deine Arbeitseinstellung
> betreffend Effektivität. Weiter so! Das scheint brauchbare Tools zu
> ergeben.

Danke !


@ Hans Wilhelm
Danke für die Links Wilhelm. Mein "Protokoll" habe ich allerdings 
bewusst so simpel gehalten, das der "Interpreter" nur den jeweilig vom 
MC gesendeten String in die einzelnen Bestandteile aufdröseln muss, was 
sehr einfach ist. Die extrahierten Substrings (Instrument Nummer und 
Messwert) werden dann an die einzelnen Instrumente passend verteilt. 
Dafür ist nun wirklich keine hohe Programmierkunst notwendig. Das ganze 
Projekt ist eher eine reine Fleissarbeit.


Ansonsten habe ich noch mal Prinzipbilder eingefügt was so alles an 
Darstellung möglich ist :)

[GrobiG (Gast)]

Hi, wirklich ein sehr coole Projekt, die UI Elemente sehen recht schick 
aus!
Kleine Anmerkung, wenn ich darf, falls du das mal irgendwann etwas 
flexibler ausbauen möchtest... z.B. könnte man die Logik(Funktionalität) 
des Instruments von der UI lösen. Man könnte z.B. sowas wie interfaces 
oder templates für z.B. Kippschalter, Taster, Lineare Anzeigen, Lampen, 
Drehknöpfe usw. erstellen, diese mit dem Nötigsten an Logik ausstatten 
und dann dem Endanwender selbst überlassen wie er das Element visuell 
gestaltet, indem er seine eigene "Klasse" ableitet oder vorhandene 
vervollständigt oder überschreibt. Wie ein Baukastensystem aus dem man 
sich das Nötigste raussucht und damit das Instrument aufbaut, aber die 
Freiheit hat jedes Teil des Instruments individuell in Visualisierung 
und Funktionalität zu gestalten, wenn man mag. Dazu evtl. noch die 
Möglichkeit eine Art "Theme" z.B. als xml Datei oder ähnliches zu laden 
was Grundlegendes wie z.B. Hintergrundfarbe etc. generell festlegt.
Das ganze "Werk" dann noch schön als .Net assembly und bis morgen und 
ich bin glücklich ;-)

VG
GrobiG

[Bernd N (Gast)]

Hallo Albert,

schöne Idee, ich habe schon deinen SerialComGrapher im Einsatz. Freu 
mich schon deine 1ste Version zu testen.

Lg,

Bernd

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

GrobiG schrieb:
> Kleine Anmerkung, wenn ich darf, falls du das mal irgendwann etwas
> flexibler ausbauen möchtest... z.B. könnte man die Logik(Funktionalität)
> des Instruments von der UI lösen. Man könnte z.B. sowas wie interfaces
> oder templates für z.B. Kippschalter, Taster, Lineare Anzeigen, Lampen,
> Drehknöpfe usw. erstellen, diese mit dem Nötigsten an Logik ausstatten
> und dann dem Endanwender selbst überlassen wie er das Element visuell
> gestaltet, indem er seine eigene "Klasse" ableitet oder vorhandene
> vervollständigt oder überschreibt.

Der Aufwand hierfür entspricht in etwa fast dem Gesamtaufwand des 
vorgesehen Projektes. Das ist mir zu viel. Davon abgesehen mache ich 
viele Properties der Instrumente zugänglich, die das Aussehen verändern. 
Also warte mal ab was da kommt :)

> Das ganze "Werk" dann noch schön als .Net assembly und bis morgen und
> ich bin glücklich ;-)

Was meinst Du warum ich in Delphi programmiere?
Um das Endprodukt unabhängig von DLL's, Net Framework's und dem ganzen 
sonstigen Microsoft-Käse zu halten. Die fertige Distributable besteht 
einzig aus einer EXE-Datei. Und es werden keine Registry-Einträge 
benutzt, nur eine Ini-Datei wird geschrieben. Damit ist mein Programm 
von Hause aus auf allen Windows Versionen sofort lauffähig.
Du kennst doch bestimmt inzwischen meine Devise:
KEEP IT SIMPLE
- Weil das Projekt in absehbarer Zeit fertig werden soll
- Weil der Anwender es auch ohne Handbuch verstehen soll

[Abdul K. (ehydra)]

Genau!

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Das GUI Konzept ist soweit fertig und mit der ersten Instrumentengruppe 
"Vertikal Meter" funktionsfähig (siehe angehängtes Programm).
Ihr könnt es ja mal testen :)

Die Bedienung ist einfach:

- Auf "Instrumente" klicken
- Klick auf gewünschte Instrumentenbezeichnung z.B #01
- Rechts können nun die Instrument Eigenschaften eingegeben werden
- Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen
- Links die darzustellenden Instrumente in der Checkbox aktivieren
- Die Einstellungen mit"Instrumente Status zuweisen" übernehmen
- Auf "Show" klicken
- Die Instrumente mit der Mouse an die gewünschte Stelle platzieren

Für die Instrumente eignet sich als Standardgrösse Breite = 130 und Höhe 
= 400, als Skala Steps =5 und Skala Substeps = 2.
Für Instrument Name und Einheit die gewünschten Bezeichnungen als Text 
eingeben.

Die ini Datei wird zur Zeit in C:\Users\Anwender\AppData\Local 
geschrieben. Der Ordner und Dateiname wird aber später frei wählbar 
sein, da in der ini die kompletten Einstellungen des jeweils aktuellen 
Projektes gespeichert sind. Damit lässt sich also das individuelle 
Projekt dann speichern und wieder laden.

[Bernd N (Gast)]

>> "Vertikal Meter" funktionsfähig

Man kann ein Anzeigeinstrument erzeugen aber ich denke da verbirgt sich 
noch keine weitere Funktionalität dahinter. Eine Schnittstelle kann ich 
nicht zuweisen, ein Wert wird schon angezeigt wo auch immer der her 
kommt. Screenshot anbei.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Bernd N
Genau, habe ich auch nirgends behauptet:

Albert M. schrieb:
> Das GUI Konzept ist soweit fertig

Und der angezeigte Wert hat überhaupt keine Bedeutung. Wie gesagt es 
geht hier zuerst mal NUR um das GUI Konzept der Instrumente. Das Andere 
kommt in den nächsten Tagen :)
Hast Du keine Steps und Substeps zugewiesen?

[Bernd N (Gast)]

ok,

>> Hast Du keine Steps und Substeps zugewiesen?

Nein, funktioniert aber, gerade ausprobiert.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Ich dachte schon es wäre ein seltsamer Grafikfehler in den Komponenten.

Als nächstes kommt die Schnittstelle dran, damit man das Ganze auf 
prinzipielle Funktionsfähigkeit testen kann. Und danach die anderen 
Instrumentarten.

[W.S. (Gast)]

Albert M. schrieb:
> Meine Aussage bezieht sich auf einen festgelegten Präfix als
> Kennzeichnung für die einzelnen Instrumente, meinetwegen A bis Z oder
> wie auch immer.

Mir kommt das schon ein bissel SEHR zu eng vor. Wirklich, ich meine es 
ernst: Denk lieber JETZT nochmal gründlich über ein gutes Protokoll 
nach, das sich auch dann noch kompatibel erweitern läßt, wenn bereits 
die ersten Anwendungen damit laufen.

BTW: Für was für Update-Geschwindigkeiten hast du das Ganze denn so 
vorgesehen? Deine (wie mir scheint) doch eher textlastige Übertragung 
sieht eher nach "langsam" aus. Immerhin muß ja die Firmware im µC 
jeweils darauf abgestimmt sein.

Weswegen ich das schreibe?
Nun, ich hatte vor Jahren mich schwarz geärgert über die Software zum 
damaligen "Funkamateur-Netzwerktester", weil diese ausgesprochen 
unflexibel war (und immer noch ist). Ich hatte mir damals was Eigenes 
dazu ausgedacht und herausgekommen ist ein Protokoll, mit dem ich quasi 
gleichzeitig:
- mehrkanalig mit einstellbarer Bitbreite wobbeln kann
- Kommandos vom PC zum µC schicken kann (mit Echo zwecks Kontrolle oder 
wenn mal ein Terminalprogramm dran hängt)
- Geräte-Kennwerte vom µC zum PC senden kann
- eine IR-fernbedienung via Wobbler zum PC durchgeschleift wird, damit 
man auf dem Basteltisch nicht ne Tastatur rumfliegen haben muß

Mittlerweile verwende ich dieses Protokoll auch woanders, es macht sich 
ganz gut. Auf der PC-Seite benutze ich im Delphi-Programm einen 
dedizierten Thread, der das gesamte I/O erledigt und dabei die 
verschiedenen Ströme (Org-Datenverkehr, Wobbeldatenverkehr, 
Fernbedienungsverkehr usw. auseinandernimmt, so daß er eigentliche 
Oberflächenkram sich damit nicht befassen muß.

Wahrscheinlich paßt mein Entwurf zu deinem Vorhaben nur mit einigem 
"Umschliff", aber eines weiß ich: Wenn man sowas nicht vorher sich gut 
überlegt und genau niederschreibt, dann kommt man später ganz gewaltig 
ins Stolpern.

Ach ja, nochwas: Für so einen Datenverkehr auf nem seriellen Kanal 
braucht es nicht zu sein, daß alles im Klartext vorliegt. Damit vergeigt 
man sich bloß ne Menge Möglichkeiten.

W.S.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

W.S. schrieb:
> BTW: Für was für Update-Geschwindigkeiten hast du das Ganze denn so
> vorgesehen? Deine (wie mir scheint) doch eher textlastige Übertragung
> sieht eher nach "langsam" aus. Immerhin muß ja die Firmware im µC
> jeweils darauf abgestimmt sein.

Bei den Instrumenten, ausser der Trendanzeige, macht eine hohe 
Updategeschwindigkeit naturgemäss keinerlei Sinn. Ich denke mal so max. 
5-10 Updates pro Sekunde reichen da voll aus. Bei der Trendanzeige darf 
es ruhig etwas mehr sein.

Meine vorläufige Protokoll-Idee sieht erst mal so aus:

#x Instrument Nummer
A Analog-Kennung
D Digital-Kennung
danach der Messwert

als Beispiel mal so:

#1A80,52#2A5#3D0#29A6,30#5A10CRLF

Man kann vom MC alle Instrumente in einem Durchlauf bedienen oder aber 
z.B. die Trendanzeige zwischendurch öfter mit Daten beaufschlagen.

Danke für Deine Ideen, die für Deinen Fall bestimmt Gold wert waren. 
Aber ich will hier keine Eierlegendewollmilchsau kreieren, noch möchte 
ich die nächsten Monate nur an dieser Software verbringen. Und ich denke 
für die meisten Hobbybastler wird meine Lösung sicherlich ausreichen. 
Die Profis mögen sich eigene Programme erstellen oder kaufen.

Nochmal: Keep it Simple.

Das fängt beim Protokoll an. Da dieses Stringorientiert ist, kann man da 
schnell auch mal reinschauen mit dem Logic-Analyser oder 
Terminal-Programm und sieht in Klartext was da so vom MC kommt. Das geht 
mit Binary nicht mehr, obwohl das natürlich auf der Schnittstelle 
schneller wäre. Aber Schnelligkeit ist hier nun mal überhaupt nicht 
gefragt.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Nochmal zum Protokoll:

Das Protokoll ist einfach und hat jetzt folgende Parameter:

X  -  Identifier für neuen Messwert
n  -  gewünschte Instrumenten Nummer
A  -  Identifier für Analogwert
D  -  Identifier für Digitalwert
m  -  Messwert
S  -  Start eines Datensatzes
E  -  Ende eines Datensatzes
CRLF  -  als Ende Zeichen #13#10 für die Schnittstelle

Ein Datensatz kann dann z.B. so aussehen:

SXnAmXnAmXnDmE  oder auch nur so:  SXnAmE

und sähe mit wirlichen Werten z.B. so aus:

SX1A24,67X25A12,2X31D0E

Das kann von jedem Microcontroller einfach als String geschickt werden 
und lässt sich einfach mit jedem Terminalprogramm oder LogicAnalyzer 
betrachten.

Die Datenstrings können beliebig gemischt an den Pc übertragen werden, 
eine bestimmte Reihenfolge muss nicht eingehalten werden.
Diese Struktur gewährleistet bei mir eine sehr schnelle Verarbeitung bei 
der Stringaufdröselung und beim anschliessenden Dispatcher.
Eine spätere Erweiterung ist einfach möglich, insbesondere da meine 
Delphi Komponenten für die serielle Schnittstelle eine zusätzliche 
universelle DataPaket Verwaltung hat.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Das Projekt macht gute Fortschritte und ich hoffe nächste Woche die 
erste funktionsfähige Version vorstellen zu können.

Ich habe noch ein Terminal für die serielle Schnittstelle integriert, um 
sehen zu können was da so auf der Schnittstelle ankommt oder um Befehle 
zum MC zu schicken. Ich denke mal das die Funktion für Basteleien 
hilfreich ist:)

[Abdul K. (ehydra)]

Und so einen Anzeigepfeil am Thermometer kann ich dann tracken und die 
Position wo ich den hinziehe, wird an den uC zurückgeschickt (optional)? 
Dann noch die Möglichkeit ein Hintergrundbild anzulegen und die 
Instrumente festzunageln und fertig ist die Steuerzentrale für was auch 
immer. Schön.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Abdul K. schrieb:
> Und so einen Anzeigepfeil am Thermometer kann ich dann tracken und die
> Position wo ich den hinziehe, wird an den uC zurückgeschickt (optional)?

Für die Kommunikation vom PC in Richtung MC wird es Schieberegler, 
numerische Eingabefelder und Taster/Schalter und Ereignisse geben.

> Dann noch die Möglichkeit ein Hintergrundbild anzulegen und die
> Instrumente festzunageln und fertig ist die Steuerzentrale für was auch
> immer. Schön.

Ein frei wählbares Hintergrundbild (im PNG-Format) ist vorgesehen.
Man kann sich somit ein Prozessbild zeichnen und die Instrumente darauf 
setzen. Dafür bekommen die Instrumente noch zusätzliche Eigenschaften, 
wie z.B. ohne Umrandung, Transparent usw.

[Martin S. (sirnails)]

Und 3... 2... 1... fertig ist die eierlegende Wollmilchsau :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Martin Schwaikert schrieb:
> Und 3... 2... 1... fertig ist die eierlegende Wollmilchsau :)

War zwar zuerst nicht so gedacht, da aber nach bereits 11 Tagen, davon 
vielleicht 6 Programmiertage, das Ganze im Prinzip funktionsfähig ist 
(alles läuft bei mir , incl. Schnittstelle), kann man sich ja mal 
Gedanken über einen Ausbau machen.

[Joe G. (feinmechaniker)]

Ein Blick auf diese Software lohnt auch:
http://www.abacom-online.de/html/profilab-expert.html

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Joe G. schrieb:
> Ein Blick auf diese Software lohnt auch:
> http://www.abacom-online.de/html/profilab-expert.html

Die Darstellungsart die man da sieht (Verknüpfung der Instrumente anhand 
von Linien) könnte patentrechtlich Probleme nach sich ziehen. Ich weiss 
aus eigener Erfahrung wovon ich da rede. Ein grosser US-amerikanischer 
Hersteller von Messtechnik und Messtechnik-Software hält ein grosses 
Paket von Patenten, bezogen auf die Darstellung von Messtechnik und 
versteht da nicht viel Spass. Das kann gutgehen, solange man denen nicht 
gross in die Quere kommt, muss es aber nicht.

[Martin S. (sirnails)]

Albert M. schrieb:
> Das kann gutgehen, solange man denen nicht
> gross in die Quere kommt, muss es aber nicht.

Softwarepatente gehören eh abgeschafft. Worin besteht denn bitte eine 
"erfinderische Leistung", wenn ich mir ein umstricheltes Kästchen 
patentiere?

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Martin Schwaikert

Das ist auch meine Meinung, leider ist es aber so.
Wobei nicht das "Kästchen" ansich patentiert ist, sonder die Verbindung 
von Kästen mit eigener Funktionalität und die Darstellung des 
Signalflüsses zwischen diesen Kästchen.
Wie gesagt ein heikles Thema, das schon 2 mal ganz böse geendet hat.

[W.S. (Gast)]

Albert M. schrieb:
> Aber ich will hier keine Eierlegendewollmilchsau kreieren, noch möchte
> ich die nächsten Monate nur an dieser Software verbringen.

OK, schon klar.

Mir ist nur beim Lesen eingefallen, daß du ja eventuell später mal 
sowas wie eine grafische Anzeige (also Oszi-Bild, Kurvendarstellung oder 
so) haben möchtest - und für sowas braucht man schon ein bissel 
Bandbreite auf der Seriellen.

Nur als Anregung (unterste Stufe aus meiner Protokoll-Definition):
00h .. 0Fh = Bereich für Steuerzeichen  (CR, LF usw.)
10h .. 1Fh = Bereich für Meßpunkt-Infobytes (synchronisieren von 
Blöcken)
20h .. 5Fh = Bereich für Klartext aller Art
60h .. 6Fh = Bereich für Kurvenprotokoll-Infos
70h .. 7Fh = spezifisch je nach Kurvenprotokoll
80h .. FFh = binäre Meßwerte. Bedeutung je nach Art des aktuellen 
Kurvenprotokolles.

Im Prinzip ist das sogar jetzt schon mit deinen Vorstellungen 
kompatibel, solange bei dir die Kleinbuchstaben und alles >0x7F nicht im 
Text vorkommen.

Albert M. schrieb:
> SXnAmXnAmXnDmE  oder auch nur so:  SXnAmE

Hmm..
Naja, kann man alles so machen, ich hab aber dazu noch nen Vorschlag:
Du programmierst geradeaus und eher doch aus PC-Sicht als aus µC-Sicht.

Albert M. schrieb:
> X  -  Identifier für neuen Messwert
> n  -  gewünschte Instrumenten Nummer
> A  -  Identifier für Analogwert
> D  -  Identifier für Digitalwert
> m  -  Messwert
> S  -  Start eines Datensatzes
> E  -  Ende eines Datensatzes
> CRLF  -  als Ende Zeichen #13#10 für die Schnittstelle

Deshalb hast du ne Menge eigentlich überflüssiger Steuer- und 
Ende-Kenner und damit ne Menge Zeugs, was sich der jeweilige Empfänger 
zum Dekodieren merken muß. Finde ich so nicht günstig. Dreh das ganze 
doch um, etwa so:
123K4711.0815A92K1D
was bedeutet das:
K selsktiert ein Gerät
A liefert nen Analogwert
D liefert nen Digitalwert
Also ünersetzt sich obiges zu

- selektiere Gerät 123
- gib dem Gerät den Analogwert 4711.0815
- selektiere Gerät 92
- gib dem Gerät den Digitalwert 1

Die Dekodier-Regel dafür ist extrem simpel:
kommt eine Ziffer (oder ein Dezimalpunkt) dann wird das unmittelbar zu 
einer Zahl zusammengesetzt. Einen String oder einen führenden Buchstaben 
braucht sich niemand zu merken.
Kommt ein Buchstabe, dann beendet er die zuvor übertragene Zahl und löst 
die zugehörige Aktion aus, also z.B. eines der Geräte auswählen, wo 
nachfolgende Infos hingehen sollen, oder eine Analog- oder Digital-Info 
an das selektierte Gerät geben oder je nach anderen Buchstaben 
irgendwelche anderen Aktionen auslösen. Dabei löscht jeder Buchstabe 
nach seiner Abarbeitung die zuvor übertragene Zahl.

Das hat den Vorteil, daß du kein Rahmen-Protokoll brauchst, also dein S 
oder E nebst CR-LF sind überflüssig. Ebenso kannst du bei Bedarf 
unendlich viele (auch unterschiedliche) Infos an dasselbe Gerät 
übertragen, ohne es jedesmal wieder auswählen zu müssen. Die 
übertragenen Kommandos sind also atomar und damit nicht an irgendwelche 
einengenden Rahmenbedingungen gebunden. Damit ist das Protokoll offen 
für Erweiterungen aller Art.


W.S.

[W.S. (Gast)]

Nachtrag: Sorry für die Tippfehler..

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ W.S.

Danke für die Info über Dein Protokoll, sehr interssante Lösung.

Mein Pakethandler(fertige Delphi-Komponente) erlaubt es mir das alles 
sehr zu vereinfachen. Der erzeugt aus einem Datenfluss durch Angabe von 
Start und Endzeichen den Sub-String zwischen Start und Ende. Das 
ermöglicht es mir ohnen riesen Protokoll ein einfaches Extrahieren der 
ankommenden Daten.
Mein Protoll konnte ich jetzt noch mehr abspecken:

- CRLF sind jetzt überflüssig wie bei Dir
- Senden eines oder mehrer Messwerte mit:
  #IMw;   wobei
  #=Startkennung, I=Instrumenten-Nummer
  M=Kennung für Messwert, w=Messwert, ;=Endennung

Das lässt sich beliebig anderandergefügt oder auch einzeln senden.
Durch die Instrumenten-Nummer ist die Funktionalität eindeutig in beide 
Datenflussrichtungen gekennzeichnet. Die Instrumenten-Nummer 
kennzeichnet automatisch ob der empfangene oder gesendete Wert numerisch 
oder alphanumerisch ist.
Das Protokoll lässt sich einfach erweitern, indem ich in weiteren 
Pakethandlern andere Start - und Endekennungen angebe.

[Abdul K. (ehydra)]

Noch ne Anregung in Bezug auf Protokolle: Man könnte auch die Syntax von 
SPICE übernehmen. Das mag zwar komisch klingen, aber so wie ich es 
momentan ohne jetzt tiefe philosophische Gedanken umherschweifen 
gelassen zu haben, sehe, könnte das klappen.
Der Vorteil ist schlicht, daß man nicht noch eine Syntax lernen muß. In 
ferner Zukunft wäre vielleicht eine Anbindung an ein SPICE möglich mit 
einem Helper-Programm. Das was an physikalischen Daten geliefert wird, 
würde so zu einer fertigen Simulationslandschaft...
Schau es dir einfach mal an.

Wichtiger ist mir aber eine funktionsfähige Software in naher Zukunft. 
Egal was du als Protokoll festlegst. Man verliert ja auch leicht die 
Lust an sowas und dann ist es nur wieder eine halbfertige Baustelle, die 
niemanden nützt außer Staub und Zeit aufgewirbelt zu haben :-)


Ich bin nicht ganz unvorbelastet, da ich mal an einem Projekt zur 
Prozeßsteuerung mitarbeitete. Sozusagen als Betatester. Die Sache war 
aber auf dem Mac und ist lange gestorben. Kann mich noch an die 
Diskussionen erinnern, wie man den Signalfluß in Software gegossen 
kriegt und das alles in Echtzeitanforderung. Und wir hatten Linien 
zwischen den Boxen ;-)

[W.S. (Gast)]

Albert M. schrieb:
> Der erzeugt aus einem Datenfluss durch Angabe von
> Start und Endzeichen den Sub-String zwischen Start und Ende.

Jajaja doch.
Tokenizer gibt's wie Sand am Meer.
Aber du hast PAKETE -  das isses.

Du hast keine atomaren Aktionen und damit hast du immer, immer immer!! 
wieder die Not, Strings hereinzuholen und Substrings zu bilden und 
obendrein ne ausgiebige Fehlerbehandlung, weil eben deine Daten im Paket 
daherkommen und nicht in einzelnen Brocken. Im PC mit seinen riesigen 
Ressourcen ist das nur ne simple Fleißaufgabe, aber du mußt ja auch 
derartige Info-Pakete (oder eben Atome) vom PC zum µC schicken und dort 
wird es dann eng. Schließlich soll die Kommunikation ja nicht den µC 
voll ausbuchen und für den Rest, nämlich die eigentliche Funktionalität, 
nur den Katzentisch lassen.

Abdul K. schrieb:
> Das mag zwar komisch klingen,..

ähemm.. naja isses auch. Irgendwelche Spice-Notationen sind nicht für 
nen bidirektionalen Datenverkehr zwischen zwei völlig unterschiedlichen 
Geräten gedacht. Was dir vorschwebt, ist also ne andere Baustelle. 
Ansonsten gibt es bei dem hier andiskutierten Projekt keine "noch ne 
Sprache" auswendig zu lernen.

Das einzige, was es geben MUSS, ist die Korrespondenz zwischen einem 
Stück Programm im µC und einem grafischen Element auf dem Bildschirm des 
PC. Das muß jeweils aus einem "Guß" sein und folglich wohl am besten aus 
einer Hand kommen.

Wie das aussieht mit verschiedenen µC Sorten und auf denen mit nach 
außen gleichgesichtigen Programmelementen, das wäre eine der vielen 
sofort aufkommenden Folgefragen. Insofern hat jedes Entwurfsdetail an 
der jetzigen Stelle mit Sicherheit schwerwiegende Folgen.

W.S.

[Abdul K. (ehydra)]

Du interessierst dich nur für deinen Ansatz. Das akzeptiere ich, mehr 
aber auch nicht. Die SPICE-Syntax gibt einiges her:

Vthermometer max=42 min=35 level=36,8

als Beispiel. Wäre vollkommen SPICE-kompatibel und den Inhalt brauche 
ich wohl nicht weiter zu erklären. Das könnte ein Thermometer sein, was 
sich der µC nun für den Benutzer wünscht. Oder als Alarmmeldung 
aufpoppt.

Nicht das ich SPICE toll fände, aber ich lernte die Vorteile durch 
schnöde tägliche Arbeit kennen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

W.S. schrieb:
> Aber du hast PAKETE -  das isses.
> Du hast keine atomaren Aktionen und damit hast du immer, immer immer!!
> wieder die Not, Strings hereinzuholen und Substrings zu bilden und
> obendrein ne ausgiebige Fehlerbehandlung, weil eben deine Daten im Paket
> daherkommen und nicht in einzelnen Brocken.

Das erledigt, wie bereits gesagt, mein Pakethandler zu 90% intern. Der 
Rest sind Peanuts. Fehlerbehandlung wird keine durchgeführt, weil das 
erstens kein Industrieprojekt ist und zweitens meine Test mit 115200 
Baud und vielen aktivierten Instrumenten keinerlei Fehler im Datenstrom 
ergeben haben. Wenn dann doch mal unwahrscheinlicherweise ein Fehler auf 
der Schnittstelle sein sollte, wird entweder der Messwert nicht 
weitergereicht, weil z.B. die Kennung falsch ist oder eben einmal ein 
falscher Wert angezeigt. So what, das ist ein Projekt für Hobbyisten und 
wer das nicht akzeptiert, braucht es ja nicht nutzen. Das Protokoll 
werde ich auf keinen Fall weiter aufblähen. Ich bleibe bei meinem 
Konzept das Ganze so einfach und funktional wie möglich zu halten, sowie 
nur Strings und keine Binärwerte über die Schnittstelle zu schicken.

W.S. schrieb:
> aber du mußt ja auch
> derartige Info-Pakete (oder eben Atome) vom PC zum µC schicken und dort
> wird es dann eng. Schließlich soll die Kommunikation ja nicht den µC
> voll ausbuchen und für den Rest, nämlich die eigentliche Funktionalität,
> nur den Katzentisch lassen.

Die Kommunikation vom PC zum MC läuft genau so ab wie umgekehrt.
Anhand der Instrumenten-Nummer weiss der PC von welchem Element die 
Daten kommen. Ein "Instrument" kann dabei durchaus auch ein Taster, 
Schalter oder Eingabefeld sein.
Also so: # Instr.-Nr M Messwert;
Damit dürfte die MC Seite nicht ungewöhnlich belastet sein, insbesondere 
auch deshalb, weil diese Datenrichtung ja nur einen Bruchteil der Zeit 
in Anspruch nimmt. Man ist ja am PC nicht andauernd mit Eingaben für den 
MC beschäftigt.

[W.S. (Gast)]

Albert M. schrieb:
> Das erledigt, wie bereits gesagt, mein Pakethandler zu 90% intern.

OK, sieh es bitte so: sowohl Abdul's als auch meine Beiträge zum Thema 
sind Vorschläge, eben Vorschläge.

Aber mal ne andere Frage: Hast du diesen Pakethandler auch schon für die 
µC-Seite und wenn, für welche Prozessorfamilien?

W.S.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

W.S. schrieb:
> Aber mal ne andere Frage: Hast du diesen Pakethandler auch schon für die
> µC-Seite und wenn, für welche Prozessorfamilien?
>
> W.S.

Der Pakethandler gehört zu den Delphi-Components für die serielle 
Schnittstelle.

[--chloro (Gast)]

Lasst doch den Albert. Er zieht ja nur sein Ding durch. Dabei gab's 
sicher viel zu lernen. Der Rest kommt ein anderes Mal. Egal.

[Reiner O. (elux)]

--chloro schrieb:
> Lasst doch den Albert. Er zieht ja nur sein Ding durch. Dabei gab's
> sicher viel zu lernen. Der Rest kommt ein anderes Mal. Egal.

Lass Ihn doch sein Ding machen! Eine Menge Leute haben sicher Bedarf an 
grafischen Sachen, ohne die Cracks in Sachen Java Scrpt, CGI oder so zu 
sein. Von daher...

Ich habe mir den ganzen Faden interessenhalber duchgelesen und ich frage 
mich, wozu ich im Protokoll eigentlich eine Kennung A und D brauche...
Entweder ein Instrument ist digital oder analog, oder? Anhand der 
Instrumentennummer weiss ich ja, wer was ist...

Ich habe mich seit gewisser Quälereien mit einem Turbo-Pascal 7 nie 
wieder mit Abkömmlingen der Fa. Borland befasst, aber es scheint mir für 
Einsteigerzwecke ist diese Lösung schon sehr gut geraten! Und mehr soll 
sie wohl auch nicht sein...
Klar gibt es immer was zu bemängeln, aber braucht man das wirklich? Muss 
es immer ein z.B. ein CRC32 sein, oder reicht nicht auch ein einfaches 
XOR (like xmodem) um zu wissen, das was schief gegangen ist ?

Just my 3 Cents.

Gruss aus Peking

Elux

[Purzel H. (hacky)]

>Muss es immer ein z.B. ein CRC32 sein, oder reicht nicht auch ein einfaches XOR 
(like xmodem) um zu wissen, das was schief gegangen ist ?

Das ist immer eine Frage gegen was eine Pruefsumme denn schuetzen soll.
Ein CRC16 zB schuetzt 2^16 bit (= 8kByte) gegen Einzelbitfehler. Ein 
CRC32 schuetzt 2^32bit = 500MByte gegen Einzelbitfehler.
Ein XOR ist vielleicht auch gut...
Man kann einmal ein gutes Protokoll fuer alle kommenden Applikationen 
implemetieren, oder sich eben langsam dorthin bewegen. Die Fuersprecher 
eines guten Protokolles waren einfach schon dort.

Eigentlich geht das Ganze etwas weiter. Man kann ein Protokoll einem 
Kontext folgen lassen, oder eben auf kontextlos optimieren. Kontextlos 
bedeutet ein Command und seine Antwort beziehen sich auf keine 
Vorgeschichte, sind in sich abgeschlossen und haben keinen versteckten 
Zustand.

zB auslesen eines Loggers :

mit Zustand/Kontext
-ReadHeader
-ReadNext
-ReadNext
-ReadNext
-..

ohne Zustand/Kontext
-ReadHeader -> pointer
-ReadRecord(1) bezuegl pointer
-ReadRecord(2) bezuegl pointer
-ReadRecord(3) bezuegl pointer
-ReadRecord(4) bezuegl pointer
..

Wenn man im ersten Fall einen Block verliert ist der Rest fuer die 
Tonne.

[flädu (Gast)]

Welche Felder in einem Protokoll bringen was fuer Vorteile? Eigentlich 
trivial, wenn man's schon mal gehoert hat.

-Header
zeigt wo die Meldung beginnt, falls man denn mal ein Zeichen verloren 
hat. Oder den Anfang des Blockes verpasst hat.

-Laenge
zeigt wie lange die Meldung ist. Was verschieden lange Meldungen 
erlaubt.

-Command code
erlaubt als Selektor verschiedene Funktionalitaet auszuloesen.

-Adressierung
erlaubt verschiedene Endgeraete zu unterscheiden

-Escape Sequenz
schuetzt den Header, falls man in minimaler Zeit neu synchronisieren 
moechte/muss.

-Checksumme
ausgefuehrt als CRC, XOR, oder irgendwas. Gibt eine Indikation in die 
Zuverlaessigkeit der Daten

-Ack/Nack
Soll man Befehle implizite Antwort beantworten oder nicht?

[Martin S. (sirnails)]

Reiner O. schrieb:
> Ich habe mir den ganzen Faden interessenhalber duchgelesen und ich frage
> mich, wozu ich im Protokoll eigentlich eine Kennung A und D brauche...

Es ist doch toll, wenn man Analoganzeigen auch für digitale Aufgaben 
nutzen kann. Bei Digitial ist 1 gleichzeitig auch Messbereichsendwert.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hier gibt es eine erste Testversion mit bis zu 10 
Vertikal-Analog-Metern.
Weitere Instrumente folgen.
Bedienung:
- Auf "Instrumente" klicken
- Klick auf gewünschte Instrumentenbezeichnung z.B #01
- Rechts können nun die Instrument Eigenschaften eingegeben werden
- Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen
- Links die darzustellenden Instrumente in der Checkbox aktivieren
- Die Einstellungen mit"Instrumente Status zuweisen" übernehmen
- Auf "Show" klicken
- Die Instrumente mit der Mouse an die gewünschte Stelle platzieren

Die Einstellung der Schnittstelle nicht vergessen.
Die Schnittstelle kann noch nicht an den MC senden, empfangen geht mit 
bis zu 115200 Baud.

Das aktuelle Protokoll ist unter Schnittstelle erklärt.

Für die Instrumente eignet sich als Standardgrösse z.B. Breite = 130 und 
Höhe = 400, als Skala Steps =5 und Skala Substeps = 2.
Für Instrument Name und Einheit die gewünschten Bezeichnungen als Text
eingeben.

Die ini-Datei wird zur Zeit in C:\Users\Anwender\AppData\Local
geschrieben. Der Ordner und Dateiname wird aber später frei wählbar
sein, da in der ini die kompletten Einstellungen des jeweils aktuellen
Projektes gespeichert sind. Damit lässt sich also das individuelle
Projekt dann speichern und wieder laden.

Zum schnellen Test und Beispiel für 8 Instrumente habe ich noch ein 
Bascom Programm angehängt.

[Abdul K. (ehydra)]

Das Instrument wird nicht groß, sondern bleibt so ein kleiner Knopf. 
Durchschaue die Einstellerei nicht wirklich. Naja, warten wir auf die 
nächste Version.
Die Fenster werden übrigens auch nicht automatisch am gegebenen 
Bildschirm begrenzt/skaliert.

Und die ini-Datei bitte einfach im Projektordner suchen lassen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Abdul K.

Da brauchst Du nicht auf die nächste Version warten, sondern Dich nur an 
meine obige Kurzanleitung halten, dann werden die Instrumente auch so 
wie Du möchtest :)

Und nicht vergessen:
- Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen

[Abdul K. (ehydra)]

Sorry, bevor ich frage probier ich es mindestens 3x aus und variiere es 
auch mal wenn ich nicht weiterkomme. Offensichtlich kennst du mich noch 
nicht lange.

Und ich habe es gerade nochmal exakt probiert. Das sieht dann so aus.

Das "- Die Einstellungen mit dem Button "Instrument Werte zuweisen 
bestätigen" heißt wohl "Instrument #1 Werte zuweisen", oder?

Ne Konfigurationsdatei zum Selbereditieren würde mir reichen.

Es sind auch noch andere Unstimmigkeiten in deiner Beschreibung. Z.B. 
warum soll ich ein Instrument extra aktivieren, wenn es bereits beim 
Öffnen des Fenster aktiv ist?

Irgendwie reden wir aneinander vorbei. Hat das jemand anders auf Anhieb 
zum Laufen gebracht?

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

... und hier auch noch was zum Programm testen mit Luna

Ich glaube das Protokoll ist so simpel, dass jeder damit sofort zurecht 
kommt. Das dürfte in C genau so einfach sein wie in Bascom oder Luna.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Abdul K. schrieb:
> Und ich habe es gerade nochmal exakt probiert. Das sieht dann so aus.

Das zeigt, dass Du dem Instrument die Werte entweder nicht zugewiesen 
hast oder keine sinnigen Einträge in Höhe und Breite vorgenommen hast. 
Ich habe dazu oben extra als Beispiel Standardwerte angegeben.

> Das "- Die Einstellungen mit dem Button "Instrument Werte zuweisen
> bestätigen" heißt wohl "Instrument #1 Werte zuweisen", oder?

Die linken Buttons #01 ... #10 aktivieren auf der rechten Seite die 
Einstellungen für das zugehörige Instrument und zeigen die bereits 
zugewiesenen Werte.

> Es sind auch noch andere Unstimmigkeiten in deiner Beschreibung. Z.B.
> warum soll ich ein Instrument extra aktivieren, wenn es bereits beim
> Öffnen des Fenster aktiv ist?

Das brauchst Du nicht. Der Button "Instrumenten Status zuweisen" braucht 
Du nur drücken wenn sich Veränderungen ergeben habe, entweder 
Instrumente zugefügt oder abgeschaltet.


> Irgendwie reden wir aneinander vorbei. Hat das jemand anders auf Anhieb
> zum Laufen gebracht?

Ja

[Bernd N (Gast)]

So, hab es ausprobiert. Max Anzeige ist wohl 3 Stellig, ansonsten 
funktioniert es. Kannst du das auf 4 Stellen erweitern ? Danke.

[Abdul K. (ehydra)]

OK, dann gehts. Dachte beim Sehen da du bereits Werte eingetragen 
hattest, die kann ich einfach übernehmen. Nur war die Fenstergröße viel 
zu klein eingestellt.

Danke.

[Abdul K. (ehydra)]

Pfeil draggen geht aber nicht. Noch nicht drin?

[matze (Gast)]

ich hoffe das es keinen stört aber ich lege den Finger nochmal in die 
Laview-Wunde.

zur Ehrenrettung muss man sagen das Programme wie Step 7, Rockwell 
automation usw. in sachen unterprogramme und Hintergrundprozesse nicht 
besser sind! Eine so mächtige Software benötigt auch Rechenleistung.

zum Thema Visa - Serieller Treiber,

was soll jetzt daran schwierig sein???
1. konfigurieren
2. Lesen oder Schreiben
3. Fehler auswerten

das sind 4 Blöcke, 10 Konstanten und ein paar verbindungen!!

dafür gibts jedemenge Beispiele im Netz, sogar bei NI selbst. Wer meint 
das Labview selbst den Rechner zu sehr belastet kann sich, auch mit 
einer Studenten oder Demo Version, eine Autarke exe Datei erzeugen! wir 
haben so in der Schule einen Mega32 als Messkarte benutzt über... 
genau... RS232!

nicht falsch verstehen, hatte mal was ähnliches mit Java gemacht (nicht 
in dem Umfang) und bin von solchen Projekten immer wieder fasziniert! 
ich werde den Threat aufjedenfall weiterhin folgen!

gr
matze

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Bernd N schrieb:
> So, hab es ausprobiert. Max Anzeige ist wohl 3 Stellig, ansonsten
> funktioniert es. Kannst du das auf 4 Stellen erweitern ? Danke.

Kein Problem, Fehler gefunden :)
In der nächsten Version stellt sich das numerische Anzeigenfenster 
automatisch auf die vom Anzeige Format String vorgegebene Grösse ein.
Für z.B. 4-stellige Anzeige dann Format String ###0 eingeben.

[Bernd N (Gast)]

Pefekt.

[Abdul K. (ehydra)]

matze schrieb:
> ich hoffe das es keinen stört aber ich lege den Finger nochmal in die
> Laview-Wunde.
>
> zur Ehrenrettung muss man sagen das Programme wie Step 7, Rockwell
> automation usw. in sachen unterprogramme und Hintergrundprozesse nicht
> besser sind! Eine so mächtige Software benötigt auch Rechenleistung.
>

Naja. Die Software an der ich beteiligt war, lief auf einem Mac anno 
1996 ohne ihn voll auszulasten, mit einem Batterie-Teststand. Heute 
laufen die PCs 10x schneller oder mehr.
Man konnte problemlos in Echtzeit den Ablauf verändern, Icons 
rumschieben usw.

Also kein Argument. Ich weiß auch nicht was Labview so aufwändig 
rechnet. Firmen wie TI benutzen es ja für ihre Demos und ich bekomme da 
immer das Kotzen wenn ich nur daran denke sowas runterladen zu müssen.

Labview ist wirklich irre langsam.

[Renixor (Gast)]

Guten Abend/Nacht erstmal ;)

@albertm
Hab eben mal dein Programm ausgetestet und ein kleines C Programm/ Ne 
Funktion für das Protokoll geschrieben. (Hier, falls es jmd gebrauchen 
kann. (Sollte selbsterklärend sein))

#include <stdlib.h>
void setInstrument(uint8_t nr, uint32_t wert)
{
  unsigned char str_nr[5];
  itoa(nr, str_nr, 10);
  
  unsigned char str_wert[14];
  itoa(wert, str_wert, 10);
  
  uart_sendstring("#");
  uart_sendstring(str_nr);
  uart_sendstring("M");
  uart_sendstring(str_wert);
  uart_sendstring("<");
}

Zuerst einmal: Tolles Projekt! Werde das mal weiter verfolgen, wird 
bestimmt toll :)

Während ich bissel gedebuggt hab sind mir 2 kleine Bugs/Nervige Dinge in 
deinem Programm aufgefallen:

1. Wenn man das Programm frisch startet ist es bei mir so, dass als 
COM-Port schon die Nr. 2 ausgewählt ist (bei "Schnittstelle"), ich aber 
mit einem Fehler Nr. 2 nicht connecten kann ( Denke Fehler Nr.2 ist 
"COM-Port nicht vorhanden" o.Ä) bei einem Blick auf "Terminal" zeigt 
sich das in Wahrheit noch COM-Port 10 ausgewählt ist! Beheben lässt sich 
dies durch erneutes klicken auf COM 2 bei "Schnittstelle".

2. Während des Debuggens von der String Übertragung vom µC habe ich dein 
Terminal genutzt, bin aber nach kurzer Zeit zurück zu Putty, da es bei 
deinem unpraktisch ist, dass die Zeile einfach weitergeht und nicht bei 
Bildschirm-/Fensterende umbricht.

3. Ein Instrument, dessen Einstellungen nicht verändert wurden, man 
sondern nach dem Aktivieren einfach nur auf "#0n" und dann "[...] Wert 
zuweisen" drückt, übernimmt es diese Standardwerte nicht und bleib ohne 
Skala.

Das alles dürfte sich schnell beseitigen lassen.

Ansonsten finde ich es echt gut ! :)
Auch die "Eingewöhnungszeit" war total kurz, innerhalb von ein paar 
Minuten versteht man wie du dir das gedacht hast..

Zu dem Protokoll: Ich denke es ist so sehr einfach gehalten und so 
effektiv . Es ist leicht zu verstehen.

Alles in allem ein wirklich nettes Projekt.


Das war's von mir soweit, werde auch die nächsten Versionen testen!

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Renixor

Danke für Dein konstruktives Interesse!
Die Behebung der Fehler ist in Arbeit.

Da ist ja mal einer dem mein Protokoll gefällt :)

[Renixor (Gast)]

Albert M. schrieb:
> @Renixor
>
> Danke für Dein konstruktives Interesse!
> Die Behebung der Fehler ist in Arbeit.
>
> Da ist ja mal einer dem mein Protokoll gefällt :)

So ists ja nicht ;)

Glaube es gibt nochn paar mehr denen das Gefällt.

Viel Spaß bei der Fehlerbehebung ;),
Renixor

[Leonard S. (renixor)]

So habe gerade mal ein bisschen weiter getestet.

Mir sind keine weiteren Fehler (außer dem schon angesprochenen Problem 
mit den 4-stelligen Zahlen.
Anbei ein Bild von allen 10 Instrumenten, mit Zufallszahlen vom µC.
Hab auch mal die maximale mögliche BAUD ausprobiert. Bei meinem 
verwendeten Mega8 mit 8MHz liegt sie bei 56000. Funktioniert mit der 
Geschwindigkeit auch noch einwandfrei.

Das wars dann erstmal mit Testen bis zur nächsten Version! :)

MFG Renixor

[chris_ (Gast)]

Vor einiger Zeit habe ich mich auch mit euerem Thema befasst.
Meiner Meinung nach ist es am Besten, wenn man vom Mikrocontroller aus 
die graphischen Elemente platzieren kann. Das heist, die Konfiguration 
der GUI soll im MC stecken. Der Vorteil ist, dass dann das MC-Programm 
immer zur GUI passt.
Ein sehr nützliches GUI-Element ist auch eines, bei dem der MC einfach 
Punkte oder Linien zeichnen kann. Das kann man verwenden, falls gerade 
kein passendes, vorgefertigtes Element GUI-Element vorhanden ist.
Hier habe ich das Prinzip in einem Python Script umgesetzt:
http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=139
Damit ich es schnell implementieren konnte und das Prinzip gut 
verdeutlicht wird, habe ich Klartextkommandos verwendet. Dadurch ist die 
Datenübertragung natürlich entsprechend langsam. Das solte man in einer 
entgültigen Version natürlich verbessern.

[Sebastian E. (s-engel)]

Dein Programm gefällt mir sehr gut.
Genau so etwas fehlt mir häufig.

Einen eigenen Ansatz hatte ich auch mal. (Siehe angehängten Screenshot)

Da war mir wichtig:
- mehrere Balkendiagramme zu haben um mehrere AD Kanäle zu vergleichen 
zu können
- Beliebige Zahlen in Anzeigen darzustellen (Umschaltbares Zahlenformat)
- Buttons, welches einen einstellbaren Wert senden.
- Ein Mini Terminal um alles ankommende darzustellen (Debugging)

Dein Programm geht in die gleiche Richtung, nur mit deutlich mehr 
Software Know How.
Ich bin auf das Ergebnis gespannt.

VG!
Se

Edit: Nur im Gegensatz zu meinem Vorredner würde ich so wenig wie 
möglich im µC machen lassen.
Wenn die Einstellungen im Programm speicherbar sind kann man sich 
Projektspezifisch die Gui ablegen.

[Leonard S. (renixor)]

chris_ schrieb:
> Meiner Meinung nach ist es am Besten, wenn man vom Mikrocontroller aus
> die graphischen Elemente platzieren kann. Das heist, die Konfiguration
> der GUI soll im MC stecken. Der Vorteil ist, dass dann das MC-Programm
> immer zur GUI passt.

Da muss ich dir widersprechen und s-engel beipflichten. :)
Ich denke auch, man braucht nicht den µC unnötig zu belasten und ihn die 
ganzen Elemente platzieren lassen. Ich würde es so machen wie in dem 
Projekt auch schon angedeutet:
Datei->Projekt Speichern/Laden. Dann z.b. die Projekt-Datei aufm Desktop 
mit entsprechendem Name und gut is. Dann öffnet man die einfach und hat 
alles.

chris_ schrieb:
> Ein sehr nützliches GUI-Element ist auch eines, bei dem der MC einfach
> Punkte oder Linien zeichnen kann. Das kann man verwenden, falls gerade
> kein passendes, vorgefertigtes Element GUI-Element vorhanden ist.

Ich bin mir nicht sicher ob ich das richtig verstanden habe, aber meinst 
du nicht einen einfachen Graph? Habe auch kurz dein Python Script 
angeguckt. Aber dort ist das ja auch nur im Grunde ein Graph und der ist 
hier ja schon im ersten Post drin. ( Bild )

[Abdul K. (ehydra)]

Das eine schließt das andere nicht aus. Und ich hatte bereits dafür ein 
Beispiel gebracht: Alarmmeldung.

[Renixor (Gast)]

Warum sollte der uC bei einer Alarmmeldung die Instrumente setzen?
Erwarten würde ich sowas wie z.b. ne Füllstandsanzeige und wenns 
überläuft setzt der uC einfach ein LED Instrument...
Müsstest nochmal erklären was du meinst :)

MFG Renixor

[Plod (Gast)]

Der Ansatz mit den selbstanzeigenden Instrumenten ist passend fuer ein 
unbestimmte Vielfalt und ebenfalls unbestimme Entwicklungsrichtung 
dieser Geraete, die unter immer demselben GUI sich selbst anzeigen 
sollen. Dh man sollte da auf einen hinreichend verbreiteten Standard 
setzen. zB Python.
Wir haben das auch mal probiert und haben Javascript und AJAX verwendet. 
Anzeige war dann der Internetbrowser. Das ging. Jedes Device hatte die 
konstanten Elemente seiner Anzeige in einem 500kByte AT45DB041D Flash.
Dieses Flash wurde dann fuer jeden refresh der Anzeige abgespult und die 
passenden Messwerte wurden dann in den Stream eingefuegt, sodass der 
Browser das dann umsetzen konnte. Floatingpoint Berechnung zur 
Skalierung der Messwerte wurden dann per Javascript auf dem Browser 
gerechnet.

Ein abgehobenes Projekt, nett zum Ueberlegen, sehr aufwendig zum 
Implementieren.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Plod

Vergiss Phyton für so ein Projekt wie meines.
Phyton ist gegenüber Delphi schnarchlangsam und könnte die schnellen 
Abläufe nicht handeln. Ich habe hier Tests laufen mit 115200 Baud und 50 
Instrumenten. Wie willst Du das "realtime-mässig" in Phyton handeln? Nix 
für Ungut, aber das ist Wunschdenken. Bis dass Du mir das Gegenteil 
beweist.

Dein Ansatz mit den selbstanzeigenden Instrumenten vom MC aus ist genau 
so abwegig. Willst Du freiwillig damit noch wesentlich mehr Daten über 
die Schnittstelle schaufeln und den MC übermässig auslasten?
Und was machst Du, wenn Du z.B. nur einen anderen Monitor mit 
kleinerer/grösserer Auflösung am PC hast. Schreibst Du dann Deine MC 
Firmware neu? Hört sich alles ziemlich nach Elfenbeinturm an.

Wie auch immer, mein Projekt ist inzwischen gut weiter gediehen:
- Fehler beseitigt
- weitere Instrumenten Eigenschaften,
  wie z.B. transparent, ohne Rahmen usw.
- Hintergrundbild (z.B. Prozess-Schema) kann eingefügt werden

[Leonard S. (renixor)]

Albert M. schrieb:
> Wie auch immer, mein Projekt ist inzwischen gut weiter gediehen:
> - Fehler beseitigt
> - weitere Instrumenten Eigenschaften,
>   wie z.B. transparent, ohne Rahmen usw.
> - Hintergrundbild (z.B. Prozess-Schema) kann eingefügt werden

Schön zu hören :)

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hier mal ein Beispiel mit Hintergrunbild, zwar noch nicht ganz perfekt, 
aber sieht doch gut aus.
Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen. 
Das hab ich mal investiert :)
In einem beliebigen Vektor-Zeichenprogramm dann damit ein Prozessbild 
gezeichnet und als Hintergrundbild geladen. Darauf dann die Instrumente 
vom Programm auf transparent gestellt und plaziert.

Das Ganze soll nur zeigen was man mit meiner Software so alles anstellen 
kann. Macht mir selber richtig Spass.

[Leonard S. (renixor)]

Abend zusammen,
Ich habe mal eben das Programm in ein kleines "Projekt" eingebunden:
Mein Mega8 mit ner Photodiode, die mitm Widerstand nen Spannungsteiler 
bilden und an ADC0 geht. Funktioniert klasse und man sieht SEHR schön 
den Zusammenhang der ADC Werte und der ADC-Spannung. Die Werte im Bild 
sind bei normaler Zimmerbeleuchtung und gehen bei Dunkelheit in Richtung 
5V. Ganz nette Sache ;)

Albert M. schrieb:
> Hier mal ein Beispiel mit Hintergrunbild, zwar noch nicht ganz perfekt,
> aber sieht doch gut aus.
> Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen.
> Das hab ich mal investiert :)

Sieht zwar noch nicht perfekt aus, aber schon ganz gut ;) Ist natürlich 
vieeel schöner so als.

[chris_ (Gast)]

>Wir haben das auch mal probiert und haben Javascript und AJAX verwendet.
>Anzeige war dann der Internetbrowser.
@Plod
Die Version mit Internetbrowser finde ich sehr gut, weil man dann nur 
einen Server braucht und die Anzeige auch über das Internet visualiseren 
kann.
Ich hatte die Idde auch schon, aber ich hätte nicht gewusst, wie man 
dynamische Vorgänge darstellen kann.

[Abdul K. (ehydra)]

Albert, niemand will dir dein gelungenes Projekt zerreden. Das sind 
einfach nur Gedankengänge, die man vielleicht mal umsetzen kann oder 
eben nicht realisiert werden. Die wurden ja auch schon x-mal woanders 
durchgekaut. Jeder hat so seine Erfahrungen und Träume.

Mach es einfach fertig und nimm kleinere Ideen mit auf. Dann wird das ne 
super Sache und eigentlich weiß ich nicht, wieso sowas nicht schon von 
jemand anders in Angriff genommen wurde.

Auch wenn ich dafür gerade keine Anwendung habe. Eine kommt bestimmt.


Teiltransparente Hintergründe/Vordergründe wären übrigens toll in fast 
allen Programmen. Mir ist genauso unverständlich, warum das nicht 
generell verwendet wird. Zumal es Windoof seit XP standardmäßig 
unterstützt. Die Anwendungen sind vielfältig, z.B.:
- Diagramme aus Datenblatt zum Vergleich mit selbergeschriebenen 
SPICE-Modell hinterlegen und Parameter dann justieren.
- Fertiges Layout oder Maßzeichnung eines Gehäuses hinter ein Layout 
einer Platine legen und Bauelemente passend platzieren.

Komischerweise findet man diese Funktion nur sehr selten und oft nur 
umständlich realisiert.

[Benedikt K. (benek)]

Wow ich muss sagen, ich bin wirklich begeistert von deiner Arbeit! Werde 
die Software demnächst mal Ausprobieren. Was ich persönlich noch 
spannend fände, die Projekte als eigentstänige .exe Dateien exportieren 
zu können.

MfG Bene

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Benedikt K. schrieb:
> Was ich persönlich noch spannend fände, die Projekte als eigentstänige
> .exe Dateien exportieren zu können.

Das geht jetzt schon. Du gibst die exe- und ini-Files, sowie event. das 
Hintergrundbild mit. Die installierst Du irgendwo anders und alles läuft 
sofort :)

[Leonard S. (renixor)]

Ich muss leider jetzt auch nochmal ein Problem berichten:

Haben das Programm mal so im Hintergrund laufen lassen (mit meinem 
kleinen Photodioden Projekt) und dann weiterprogrammiert. Wunder ich 
mich irgendwann warum das denn so ruckelt. Programm ausgemacht -> läuft 
wieder flüssig. Das Programm kann scheinbar mit der hohen Baudrate nicht 
umgehen. Die Bilder sagen wahrscheinlich einiges... Mein ATMega8 schickt 
~ 20 Werte/s. Mit einer BAUD von (wieder) 19200 ist es dann "normal", 
zwar immer noch ~20% Auslastung aber das ist in Ordnung. Hoffe das hat 
einen Programmierfehler Hintergrund... :)

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Leonard S.

Deine Programmversion hatte noch Probleme.
Mit meiner aktuellen Version liegt die Prozessorauslastung des PC bei 
kontinuierlicher Übertragung mit 115200 Baud und 5 Instrumenten bei 3%.

[Leonard S. (renixor)]

Das ist ja Super ! ;) Dann ist ja alles in Butter..

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Habs gerade mal mit dem Logic-Analyzer angeschaut. Zur Zeit schaffe ich 
mit einem ATMega328 und 115200 Baud durchschnittlich 700 Messwerte/s 
(incl. Protokol). Die stellt meine Software ohne ohne zu mucken dar.

[Leonard S. (renixor)]

Das klingt ja gut :) Glaube man braucht selten 700 Werte/s ;)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Leonard S. schrieb:
> Das klingt ja gut :) Glaube man braucht selten 700 Werte/s ;)

Es komm ja noch eine Trendanzeige hinzu, die darf dann was schneller 
beaufschlagt werden :)
Aber im Prinzip hast Du recht, mit zu hoher Updaterate lastet man nur 
den MC zu stark aus. Da muss man eben abwägen. Ich wollte nur mal 
schauen was mit meinem Protokoll so geht. Beschränkt man die Messwerte 
auf Integer, kommt man locker über 1000 Messwerte/s.

[Leonard S. (renixor)]

Ja sehe ich genau so. Bei mir würden auch 10 Werte/s reichen und das ist 
ja wenig... Kommt immer aufs Projekt an.

EDIT: Wann glaubst du kommt die nächste Version raus ? ;)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Leonard S. schrieb:
> EDIT: Wann glaubst du kommt die nächste Version raus ? ;)

Ich hoffe diese Woche noch, kanns aber nicht versprechen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Nochmal was mit dem Hintergrundbild rumgespielt. Dabei hat sich 
rausgestellt, dass die Instrumenten-Darstellung weitere Eigenschaften 
braucht, insbesondere bei den Zusatztexten und Schriftfarbe. Das 
Ergebnis sieht jetzt wie oben aus.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hier gibt es die Version 0.22 zum Testen.

Erstaunlich was Delphi bei dem doch inzwischen schon umfangreicherem 
Projekt für kleine exe-Dateien zaubert. Nach Entpacken nur ca. 1,3 MB.

[Leonard S. (renixor)]

Ich habe natürlich ;) gerade eben getestet, Ergebnis:
Ich habe nur ein kleines Problem gefunden :D, und zwar ist es mir nicht 
möglich die substeps einzustellen. Wenn ich sie änder und auf 
"zuweisen+Show" klicke passiert gar nix. Sieht man auch oben im Bild 
"neueAnzeige.jpg", bei #1 stehen die substeps auf 5, bei #2 auf 2. Bei 
beidem habe nicht ich die Werte gemacht, sie waren einfach da.

Ansonsten: Wirklich klasse Arbeit! Man kann jetzt alles schön gestalten 
und mit dem Hintergrundbild sieht man direkt was wofür ist. Das 
Hintergrundbild hab ich nicht getestet, da ich kein passendes hatte. 
Alle anderen Fehler wurden behoben und das Terminal ("terminal.jpg") ist 
auch gut lesbar.

Ich denke das Projekt wird was!

MFG Renixor

//EDIT: Fast vergessen, dabei ist das ja so wichtig: Wie du gesagt hast, 
Prozessor-Auslastung bei ~3%: Als wär dein Programm gar nicht da :). Bin 
jetzt auch zurück zur 56000 BAUD. Klappt wunderbar.

[Grafiksucher (Gast)]

Albert M. schrieb:
> Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen.

Wo hast die denn runtergeladen?

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Grafiksucher schrieb:
> Albert M. schrieb:
>> Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen.
> Wo hast die denn runtergeladen?

http://www.iconshow.de/shop/show_product.php?products_id=137
und hier kann man sich online eine Hintergrundschematik erstellen. 
Anschliessend kopieren oder Screenshot, in png umwandeln und in mein 
Programm laden:
http://www.engineeringtoolbox.com/p-id-drawing-d_1639.html
und hier gibt es ein passendes gratis DrwaingTool als Starteredition:
http://www.serif.com/int/de/freedownloads/free-graphic-design-software/
Damit habe ich mein Hintergrundbild erzeugt.


Leonard S. schrieb:
> Ich habe nur ein kleines Problem gefunden :D, und zwar ist es mir nicht
> möglich die substeps einzustellen. Wenn ich sie änder und auf
> "zuweisen+Show" klicke passiert gar nix.

Danke für's Testen. Fehler ist behoben.
Korrigierte Programmversion anbei :)

[Leonard S. (renixor)]

WoW, dass ging ja schnell :)
Getestet und funktioniert. Alles gut jetzt denke ich :)
Freue mich schon auf die nächsten Instrumente ;)

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Was haltet ihr von der Implementation einer Realtime 3-D Anzeige?
3 von einander anhängige Messwerte können so dargestellt werden.
Das ganze lässt sich mit der Mouse drehen und von allen Seiten 
betrachten.
Oder geht da jetzt der Spieltrieb mit mir durch :)
Funktionsfähige Demo wie so was aussehen könnte anbei.

[Leonard S. (renixor)]

Mhh einen gute Frage.
So auf Anhieb fällt mir nichts wirklich ein wofür man das gebrauchen 
könnte.
Höchstens sowas wie ein Regensensor, der den Niederschlag auf einer 
bestimmten Fläche so anzeigt..

Albert M. schrieb:
> 3 von einander anhängige Messwerte können so dargestellt werden.

Dann wäre das doch nur ein einzelner Punkt im Koordinaten System !? Also 
müsste der µC mehre Koordinaten setzten.

Ich denke das ist dann doch schon eher Spielerei ;)

MFG Renixor

[Renixor (Gast)]

Außerdem müsste man dann ein eigenes Protokoll für das Modell einführen.
So ala #px100y250z300< könnten man einen Punkt setzten.(beispiel)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Renixor schrieb:
> Außerdem müsste man dann ein eigenes Protokoll für das Modell einführen.
> So ala #px100y250z300< könnten man einen Punkt setzten.(beispiel)

Nein - wieso denn?
Das 3-D Instrument bekommt 3 freie Kanäle zugewiesen,
z.B. #70, #71, #72.
Das ist schon alles und zeigt wie flexibel mein simples Protokoll ist :)

[Renixor (Gast)]

Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8)
Und angenommen #70 == X #71 ==  Y #72 == Z
Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32.
Verstehe noch nicht ganz wie das gehen soll

[Martin S. (sirnails)]

Renixor schrieb:
> Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8)
> Und angenommen #70 == X #71 ==  Y #72 == Z
> Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32.
> Verstehe noch nicht ganz wie das gehen soll

Richtig angefangen, falsch gefolgert. Die drei Kanäle repräsentieren die 
XYZ-Koordinaten. Dass der Prozessor dann auch diese drei Punkte schicken 
muss, ist ja keine Frage des Anzeigeprogramms, sondern der Firmware :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Renixor schrieb:
> Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8)
> Und angenommen #70 == X #71 ==  Y #72 == Z
> Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32.
> Verstehe noch nicht ganz wie das gehen soll

Denk noch mal drüber nach. Die Kanäle #70, #71, #72 representieren doch 
bereits den kompletten Datensatz. Also:
Du schickst jeweils EINEN Messwert an die drei Kanäle. X > #70, Y > #71, 
und Z nach #72. Dann wird intern die 3-D Grafik upgedatet. Fertig.

[Renixor (Gast)]

Albert M. schrieb:
> Denk noch mal drüber nach. Die Kanäle #70, #71, #72 representieren doch
> bereits den kompletten Datensatz. Also:
> Du schickst jeweils EINEN Messwert an die drei Kanäle. X > #70, Y > #71,
> und Z nach #72. Dann wird intern die 3-D Grafik upgedatet. Fertig.

Bin ich gerade zu Doof dafür?! Die drei Kanäle haben dann nur einen Wert 
-> ein Punkt.
Also muss man mehrere Punkte schicken. Also hat dann jeder Kanal mehere 
Werte.

[Martin S. (sirnails)]

Renixor schrieb:
> Also muss man mehrere Punkte schicken. Also hat dann jeder Kanal mehere
> Werte.

Klar, für ein Diagramm braucht es natürlich x*y*z Datensätze.

[Renixor (Gast)]

Habs nun verstanden :) Hast Recht: Funktioniert so mit den Kanälen. Also 
an sich ein Nice-to-have aber nicht zwingend notwendig.

MFG Renixor

[Basti (Gast)]

Super Projekt, hat potential uns sieht echt genial aus...

Mir fällt gerade noch eine kleine Idee ein, bin mir nur nicht sicher ob 
das sinnvoll wäre:

Bei einer MC Berechnung haben ich den Wert 3540 welcher eine Spannung 
oÄ. repräsentiert (zB. 3,540V). Diese Zahl ist aber nicht der Endwert, 
mit dem wird weitergerechnet. Will ich diesen Wert nun aber korrekt 
darstellen müsste ich ihn erst in eine Fließkommazahl umwandeln, was 
verschwendete Rechenleistung wäre.
Könnte man nun im Tool einen Skalierungsfaktor angeben (*0,001) dann 
kann ich die Zahl einfach Übertragen, die Software stellt aber die 
Korrekte Spannung von 3,540V dar.

Hoffe das war verständlich, evtl ist das ja sinnvoll?

[Renixor (Gast)]

Seh ich auch so. Momentan rechne ich den ADC *4.883 also auch Kommazahl. 
Momentan nicht schlimm, da der nix anderes macht aber wäre natürlich 
einfacher und besser.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Basti schrieb:
> Könnte man nun im Tool einen Skalierungsfaktor angeben (*0,001) dann
> kann ich die Zahl einfach Übertragen, die Software stellt aber die
> Korrekte Spannung von 3,540V dar.

Ja, ein Skalierungsfaktor ist sinnvoll und wird bei der nächsten Version 
berücksichtigt.

[Basti (Gast)]

Albert M. schrieb:
> Ja, ein Skalierungsfaktor ist sinnvoll und wird bei der nächsten Version
> berücksichtigt.

Super, freut mich wenn ich was beitragen konnte :)

Eine weitere Idee wäre evtl eine Vorschau beim Einstellen des 
Instruments zwecks Größe und so. Damit man nicht immer auf Zuweisen+Show 
klicken muss, um dann festzustellen Farbe oder Größe sind noch nicht 
zufriedenstellen. Dann wieder zu Instrumente, das passende anwählen und 
ändern...

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Basti schrieb:
> Eine weitere Idee wäre evtl eine Vorschau beim Einstellen des
> Instruments zwecks Größe und so.

Muss ich mal sehen. Allerdings kann das aus Platzgründen bei sehr hohen 
oder sehr breiten Instrumenten schwierig werden. Ich probiers aber mal 
aus.

[Leonard S. (renixor)]

Also ich denke das ist nicht sooo wichtig, da man ja meist eh nur 1x 
einrichtet und das dann speichert. z.b. für mein kleines Photodioden 
Projekt hat sich 300x900 als "Standardgröße" herausgestellt. Ich denke 
es wird einfach viel Arbeit bleiben das einzurichten (wenn man fast 
alles benutzt) da wird man nicht drum rum kommen, deshalb gibts ja ne 
Speicherfunktion. Allerdings weis man mit der Zeit auch was gut ist und 
was nicht so..

MFG Renixor

[Abdul K. (ehydra)]

Nett. Eine Frage: Ich kann den Reiter (Momentanwert) nicht verschieben 
auf einer Skala. Ist das noch nicht drin? Die neue Position sollte ja an 
den MC geschickt werden.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Abdul K. schrieb:
> Nett. Eine Frage: Ich kann den Reiter (Momentanwert) nicht verschieben
> auf einer Skala. Ist das noch nicht drin? Die neue Position sollte ja an
> den MC geschickt werden.

Versteh ich jetzt nicht. Das sind ANZEIGE-Instrumente, mit denen wird 
nichts zum MC geschickt.
Regler-Elemente, Taster und Eingabeboxen um irgendwas zum MC zu schicken 
sind einer späteren Version vorbehalten.
Die einzige Möglichkeit zur Zeit was zum MC zu schicken ist über das 
integrierte Terminal.

Zuerst muss mal mit den Anzeige-Instrumenten alles perfekt sein. Dann 
schauen wir weiter :)

[Lutz M. (themroc)]

Hi Albert!

Ja, das klingt nach nem netten Projekt...

Is vlt. schon bisschen spät das noch zu erwähnen, aber das ganze 
GUI-Gedöns gibts fertig und ausführlichst getestet für lau (opensource), 
ist portabel (Linux, Windows, Mac, BSD, ...). Die Oberfläche lässt sich 
in paar Minuten mit

https://glade.gnome.org/

zusammenclicken und mit so gut wie jeder Programmiersprache mit Leben 
füllen. Nachteil: Standardmässig fehlt einiges, was auf ner virtuellen 
Frontplatte öfter mal gebracht wird, z.B. runde Potiknöppe oder diese 
alten Zeigerinstrumente. Da ist aber etliches im Netz zu finden und wenn 
wirklich mal was fehlt, lässt es sich sehr einfach programmieren und 
einbinden, weil GTK vorbildlich objektorientiert ist. Beispiel: 
https://developer.gnome.org/gtk-tutorial/2.22/x2310.html

[Abdul K. (ehydra)]

glade sieht für mich nur aus wie ein Template-Editor. Kann das noch 
mehr? Für die Anzeige von physikalischen Meßwerten brauch es ja doch 
noch etwas Logik im Hintergrund! Ich habs aber auch nur kurz überflogen.

Template-Editor gabs vor 20 Jahren schon auf dem Apple Newton und 
vermutlich schon früher, denn Apple greift meist nur günstige Strömungen 
anderer auf.


@Albert:
OK, die Sendefunktion gibts also noch nicht.
Ich muß aber nochmal drauf rumhacken, bevor es in die falsche Richtung 
läuft:
Willst du das Senden als weitere Anzeigeobjekte definieren oder integral 
in den bereits vorhandenen? Wie gesagt, der Anzeige-Leveller soll dem 
Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein. 
Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den 
Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird 
dann an den MC geschickt.
Im Prinzip könnte man so auch die Voreinstellungen realisieren. Also das 
Programm schickt diese Werte einmal beim Programmstart an den MC.

[Leonard S. (renixor)]

Zu Lutz M. Beitrag:

Hab mir das Ding mal runtergeladen:
Ist ein Installer -> Installiert unter dem Standard Pfad. Dann Installer 
geschlossen auf Desktop geguckt : NIX! In den Installationsordner 
(appdata/local/) rein: auch nix, erst im 'bin' Ordner wird man fündig. 
Also Programm gestartet, und mal versucht irgendwas auf die schnelle 
hinzubekommen. Fehlanzeige: Nach 15min hat ich das Bild im Anhang 
zustande gebracht und dann aufgegeben. Ich muss anmerken das die Buttons 
keinerlei Funktion aufweisen. Ich denke dieses Programm ist vieeeeeel zu 
komplex, man wird sehr viel Zeit brauchen um sich da zurecht zu Finden 
und eigentlich ist es am Thema vorbei. So wie ich das verstanden hab 
muss man da auch erst selbst irgendwas Programmieren damit die Buttons 
ne Funktion bekommen. Also ich ziehe diesem Programm die 
SerialComInstruments vor.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Lutz M. schrieb:
> GUI-Gedöns gibts fertig und ausführlichst getestet für lau (opensource),
> ist portabel (Linux, Windows, Mac, BSD, ...). Die Oberfläche lässt sich
> in paar Minuten mit
> https://glade.gnome.org/
> zusammenclicken und mit so gut wie jeder Programmiersprache mit Leben
> füllen.

Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi 
programmiere. Was soll ich da mit fremden Oberflächen-Templates? Das 
alles ist in Delphi mehr als genügend vorhanden.
Und im übrigen ist die Bedienoberfläche bei diesem Projekt das geringste 
aller Probleme.


Abdul K. schrieb:
> OK, die Sendefunktion gibts also noch nicht.
> Ich muß aber nochmal drauf rumhacken, bevor es in die falsche Richtung
> läuft:
>Wie gesagt, der Anzeige-Leveller soll dem
> Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein.
> Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den
> Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird
> dann an den MC geschickt.

Ein Einsteller der dem Messwert folgt ist nicht sinnvoll. Wenn Du den 
eingestellt hast, folgt er ja danach sofort wieder dem Messwert. Wie 
willst Du denn damit was einstellen und die vorgenommene Einstellung 
auch sehen?
Du kannst (wenn es denn mal implementiert ist) einen Regler mit der 
selben Skalierung nebem der Messwertanzeige plazieren und an diesem die 
Einstellung vornehmen. Dann siehst Du wenigsten was Du eingestellt hast.

[Abdul K. (ehydra)]

Wenns wirklich nur ein Template-Editor ist, dann müßtest du die Buttons 
DANACH mit Funktion (Programmcode) füllen. Das Template erzeugt einfach 
nur die GUI-Basiselemente, Anordnung, Default-Zustand usw. durch 
grafisches Geschubse. Irgendwo in dem Programm wirds ne Funktion zur 
Erstellung des fertigen Templates geben. Das ist dann der Rumpf deines 
Programms.

Delphi wird sowas genauso haben und Albert eben den eigentlichen Code 
einfügen.

[Abdul K. (ehydra)]

Albert M. schrieb:
>> Wie gesagt, der Anzeige-Leveller soll dem
>> Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein.
>> Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den
>> Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird
>> dann an den MC geschickt.
>
> Ein Einsteller der dem Messwert folgt ist nicht sinnvoll. Wenn Du den
> eingestellt hast, folgt er ja danach sofort wieder dem Messwert. Wie
> willst Du denn damit was einstellen und die vorgenommene Einstellung
> auch sehen?

Du meinst es ergibt sich ein Zustand, der nicht logisch ist?
Sehe ich anders. Der MC bekommt ja nur dann Strings gesendet, wenn ich 
was ändere. Änderungen sind aber nun nur:
1. Ich schiebe wie beschrieben den Leveller auf einen anderen Wert. Und 
lasse dort die Maus los.
2. Das Programm wird gestartet und überträgt alle Voreinstellungen an 
den MC.

Der Trigger, den du implementieren müßtest, ist das Loslassen der 
Maustaste.

Auf der anderen Seite haben wir den MC, auch der muß dem Zustand des 
Programms folgen können:
Sobald er einen String vom PC bekommt, übernimmt er diese Einstellung 
als Vorgabe (Das ist nicht der Meßwert). Letztlich überschreibt er nur 
den ersten Wert, der aus der Zeit stammt als das Programm auf dem PC 
startete und die Startwerte schickte.

Was nun wenn der PC sich nie oder nicht mehr meldet?
Dann sollte der MC autonom die Regelung aufrechterhalten. Das kann er, 
denn er hat die Startwerte vom PC und wenn die nicht kamen, eben die 
eigenen Startwerte aus seinem Flash.

Danach sendet der MC einfach weiter seine aktuellen Meßwerte.

> Du kannst (wenn es denn mal implementiert ist) einen Regler mit der
> selben Skalierung nebem der Messwertanzeige plazieren und an diesem die
> Einstellung vornehmen. Dann siehst Du wenigsten was Du eingestellt hast.

Da sind wir ja fast einer Meinung.

Damit man Vorgabe und Meßwert unterscheiden kann als Anwender, könnte 
man die Leveller mit unterschiedlicher Helligkeit zeichnen. Ich gehe mal 
davon aus, daß man die Farbe irgendwann selbst definieren kann.

Beim Heizkessel-Beispiel würden also beide Leveller solange übereinander 
liegen, solange es keine vorherige Voreinstellung gab (also z.B. der 
float ist gleich NAN oder NIL wars wohl in Pascal). Das heißt der 
Vorgabe-Leveller folgt immer den aktuellen Meßwert-Leveller mit. Sobald 
eine Vorgabe erfolgt ist (Eben in dem die Maus mal losgelassen wurde) 
bleibt der Vorgabe-Leveller stehen. Der Meßwert-Leveller wird ja nur vom 
MC in seiner Position bestimmt. Falls die Regelstrecke im MC-Part 
funktioniert, wird dieser sich also dem dem Vorgabe-Leveller immer 
weiter nähern. Bis dann bei voller Ausregelung der Vorgabe-Leveller 
hinterm Meßwert-Leveller optisch verschwindet.

Hört sich komplizierter an als es zu programmieren ist. Ich finde das 
deutlich eleganter als zwei Skalen nebeneinander auf einer eh 
beschränkten Monitorfläche.

[Leonard S. (renixor)]

Es gibt dafür ne ganz m.M.n elegante Lösung: Im ersten Post hier in dem 
Bild dort sind auch zwei Regler, die nicht einen sondern zwei Pfeile 
haben. Da nimmt man einen als schiebbaren Regler (edit: welcher auch 
deaktiviert werden kann) und der andere folgt dann ja. z.b der Rechte. 
Den schiebt man hoch, der µC erhält neue Werte und ändert so auch den 
Linken bis sie wieder auf gleichem Level währen. Sieht dazu bestimmt 
auch Cool aus ;)

MFG Renixor

[Abdul K. (ehydra)]

Das zweite Panel von rechts könnte sowas sein. Stimmt.

[Leonard S. (renixor)]

Genau das meinte ich :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Neue Version 0.23 verfügbar.

Änderungen:
- Zu jedem Instrument kann ein Skalierungsfaktor zugewiesen werden.

[Leonard S. (renixor)]

Funktioniert an sich, allerdings würde ich mit mehr als 1 
Nachkommastelle wünschen. Momentan geht nur 4,9 aber exakt wären es z.b 
4,883. Das Programm sollte auch damit noch Rechnen können. :)

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Leonard S. schrieb:
> Funktioniert an sich, allerdings würde ich mit mehr als 1
> Nachkommastelle wünschen. Momentan geht nur 4,9 aber exakt wären es z.b
> 4,883. Das Programm sollte auch damit noch Rechnen können. :)

Das funktioniert schon so wie es soll.
Für die Anzahl der Nachkommastellen gibt es die Eingabe
unter "Format Skala".
Versuch es da z.B. so:

##0.000 gibt 3 Nachkommastellen aus
##0     gibt keine Nachkommastelle aus

[Renixor (Gast)]

Nein, dass meinte ich nicht. Bei dem Feld "Skalierung" kann man nur 
Zahlen mit einer Nachkommastelle eingeben. Gibt man dort z.b 4,883 ein, 
rundet das Programm automatisch auf 4,9.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Ist korrigiert, anbei Version 0.23a

Änderungen:
- Zu jedem Instrument kann ein Skalierungsfaktor zugewiesen werden.
- Fehler in Zahlenformaten behoben

[Renixor (Gast)]

Super, kanns aber heute ich mehr testen :)
Gutes Nächtle,
Renixor

[Lutz M. (themroc)]

Albert M. schrieb:
> Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi
> programmiere.

Deshalb hab ich mit "Is vlt. schon bisschen spät das noch zu erwähnen, 
aber..." angefangen, weil ich nämlich gelesen hab, dass Du schon mit 
einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht 
mehr auf ein besseres umstellen möchtest.

[Leonard S. (renixor)]

Lutz M. schrieb:
> dass Du schon mit
> einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht
> mehr auf ein besseres umstellen möchtest.

Darüber lässt sich Streiten ;)

Komplexer != Besser

[Lutz M. (themroc)]

Abdul K. schrieb:
> Wenns wirklich nur ein Template-Editor ist, dann müßtest du die Buttons
> DANACH mit Funktion (Programmcode) füllen. Das Template erzeugt einfach
> nur die GUI-Basiselemente, Anordnung, Default-Zustand usw. durch
> grafisches Geschubse.

Korrekt. Nur die Bezeichnung "Template-Editor" find ich etwas komisch, 
nennen wirs doch lieber "GUI-Designer" oder so...

> Irgendwo in dem Programm wirds ne Funktion zur
> Erstellung des fertigen Templates geben. Das ist dann der Rumpf deines
> Programms.

So wars früher mal, inzwischen spuckt das Ding nur noch ne XML-Datei 
aus, die dann (wie gesagt, in praktisch jeder Programmiersprache) mit 
1 Befehl reingesaugt und umgesetzt werden kann.

> Delphi wird sowas genauso haben und Albert eben den eigentlichen Code
> einfügen.

Was bei Delphi/Kylix m.W. nicht dabei ist: die Sourcen vom GUI-Editor. 
Den würde ich nämlich hacken wollen, um das ganze überflüssige Zeugs 
raus- und fehlendes (z.B. LED-Anzeigen) reinzubauen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Lutz M. schrieb:
> Albert M. schrieb:
>> Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi
>> programmiere.
>
> Deshalb hab ich mit "Is vlt. schon bisschen spät das noch zu erwähnen,
> aber..." angefangen, weil ich nämlich gelesen hab, dass Du schon mit
> einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht
> mehr auf ein besseres umstellen möchtest.

Sorry, aber Du fällst für mich in die Kategorie "Ich will auch mal was 
in die Diskussion einwerfen".

Es ist das Tool für mich das Beste, in dem ich firm bin und das mir 
hilft die Aufgabe am schnellsten zu lösen.
Ich arbeite an meinem Projekt jetzt gerade mal 2 Wochen und das auch nur 
ab und an stundenweise. Mit den von Dir propagierten 
Oberflächentemplates wärst Du noch nicht mal ein Viertel soweit wie ich. 
Und wie willst Du mit Deinen Templetes die visuellen Instrumente 
erzeugen?
Alles ziemlicher Dummschwatz.

Und im übrigen solltest Du nicht über Programmiertools wie Delphi 
urteilen, von denen Du ganz offensichtlich nicht den geringsten Schimmer 
hast.

[Lutz M. (themroc)]

Leonard S. schrieb:
> Darüber lässt sich Streiten ;)
>
> Komplexer != Besser

Aber: Universeller = Besser ;)

[Leonard S. (renixor)]

Lutz M. schrieb:
> Aber: Universeller = Besser ;)

Nur was bringts einem, wenn man DIE Eierlegende-Woll-Milch-Sau hat, es 
aber Stunden dauert bis man auch nur zu einem kleinem Ergebnis kommt?

[Abdul K. (ehydra)]

Die schlichte Antwort ist, wieviel Stunden hats am Ende insgesamt 
gedauert.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Features der nächsten Version:

-  Redesign des User-Interface
   Verschieben und Grösseneinstellung mit der Mouse

-  Interaktion mit dem Mikrocontroller
   über zuweisbare Buttons, d.h. Befehle senden
   (später auch Schieberegler und Eingabefelder)

[Renixor (Gast)]

Schön. Wann kommt sie denn Vorraussichtlich raus ? :)

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Renixor
Schön, dass Du Dich noch für mein Projekt interessierst.
Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum 
eigentlichen Thema passende Posts aussen vorlässt.
Daher ist wohl die Veröffentlichung weiterer Versionen nicht so 
dringlich.

Was bei mir bereits alles funktioniert, aber noch nicht vollständig 
ausgetestet ist:
- Trendanzeige mit bis zu 4 Kanälen
- Drehzeigerinstrumente
- Schieberegler, Befehlsbuttons und Eingabefelder
- math. Formelparser für frei zuweisbare Funktionen
- PID-Regler (verlangt bisher jedoch zeitäquidistante Werte)
- diverse verschiebbare Teil-Hintergründe
  wie Umrandungen, Pfeile, Linien, Kessel
  und animierte Bitmaps (in Abhängigkeit vom Wertezustand)

Ob ich das allerdings noch veröffentliche weiss ich nicht, meine 
Motivation dazu wird ehrlich gesagt immer geringer.

[Leonard S. (renixor)]

Albert M. schrieb:
> @ Renixor
> Schön, dass Du Dich noch für mein Projekt interessierst.
> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum
> eigentlichen Thema passende Posts aussen vorlässt.
> Daher ist wohl die Veröffentlichung weiterer Versionen nicht so
> dringlich.

Naja, ich denke es gibt schon noch mehr Leute als mich, denen das 
gefällt, schau einfach mal den Thread durch..(Vorallem so Mittig/weiter 
oben sprechen sich doch einige FÜR die Idee aus.) ;) Außerdem wäre der 
Thread hier nicht so lang wie er jetzt ist(und das auch noch mit 
sinnvollen Beiträgen!), würde es niemanden Interessiern. Die 
Veröffentlichung/das Projekt ist natürlich komplett dir überlassen.

Albert M. schrieb:
> Was bei mir bereits alles funktioniert, aber noch nicht vollständig
> ausgetestet ist:
> - Trendanzeige mit bis zu 4 Kanälen
> - Drehzeigerinstrumente
> - Schieberegler, Befehlsbuttons und Eingabefelder
> - math. Formelparser für frei zuweisbare Funktionen
> - PID-Regler (verlangt bisher jedoch zeitäquidistante Werte)
> - diverse verschiebbare Teil-Hintergründe
>   wie Umrandungen, Pfeile, Linien, Kessel
>   und animierte Bitmaps (in Abhängigkeit vom Wertezustand)

Das ist ja schon wieder ne ganze Menge. Wenns ums Testen geht, kannste 
es mir auch gerne mal so schicken.

[Grafiksucher (Gast)]

Ich habe auch Interesse.

Bin aber leider mit meiner Testumgebung noch nicht so weit.

[Basti (Gast)]

Auch ich bin noch da, als stiller mitleser... ;)

[Leonard S. (renixor)]

Grafiksucher schrieb:
> Bin aber leider mit meiner Testumgebung noch nicht so weit.
Das ist ja das schöne daran: Man braucht nur nen µC und nen 
Pegelwandler, UART-Libs gibts im Internet oder einfach selber schreiben 
und dann noch die Funktion von mir (weiter oben), die man auch easy 
selber schreiben kann und ab gehts.. Da ich UART Header schon habe für 
z.b den Mega8 musste ich nur die Funktion schreiben und schon war meine 
'Testumgebung' fertig :)

[ErsterBeitrag (Gast)]

Ich finde dieses Projekt auch erste Sahne! Bitte mache weiter, das ist 
genau das was ich benötige. Leider bin ich noch beim Layouten meiner 
Hardware.

[Karl (Gast)]

[x] sehr beeindruckend und defeinitiv interessant
Das ist sowas wie INCA oder CANape in klein.

Kann man auch Parameter verstellen?

[Abdul K. (ehydra)]

Toll wäre es, wenn man die Anzeigeelemente einfach selber als Bitmaps 
hinterlegen kann. Du kopierst dann einfach diese Bitmaps übereinander. 
In die Länge ziehen ist ja auch kein Problem, damit man Balken bekommt. 
Wäre halt schön für den eigenen Style (Deine Elemente finde ich optisch 
überladen).

Das ist natürlich für dich nur unangemessene Kritik. Damit behalte ich 
also damit recht, das das Interesse deinerseits bald einschlafen wird.

Vielleicht hilft Geld. Dann aber muß es schon richtig fertig sein.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Abdul K. schrieb:
> Toll wäre es, wenn man die Anzeigeelemente einfach selber als Bitmaps
> hinterlegen kann. Du kopierst dann einfach diese Bitmaps übereinander.
> In die Länge ziehen ist ja auch kein Problem, damit man Balken bekommt.
> Wäre halt schön für den eigenen Style (Deine Elemente finde ich optisch
> überladen).

Steht ja schon bereits hier (wenn auch nicht weiter erklärt):

Albert M. schrieb:
> Was bei mir bereits alles funktioniert, aber noch nicht vollständig
> ausgetestet ist:
> - diverse verschiebbare Teil-Hintergründe

Abdul K. schrieb:
> Das ist natürlich für dich nur unangemessene Kritik. Damit behalte ich
> also damit recht, das das Interesse deinerseits bald einschlafen wird.

Nö, das ist keine unangemessene Kritik, da es sich im Gegensatz zu 
vielen anderen Beiträgen hier tatsächlich auf mein Projekt bezieht.
Und zu dem zweiten Satz sag ich jetzt mal garnichts ...

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Karl schrieb:
> [x] sehr beeindruckend und defeinitiv interessant
> Das ist sowas wie INCA oder CANape in klein.
> Kann man auch Parameter verstellen?

Lade Dir einfach die letzte Version runter und spiel damit. Für die 
Zeigerinstrumente lassen sich die wichtigsten Parameter verstellen.

Wenn Du aber damit die Kommunikation vom PC zu MC meinst, so kommt das 
in den nächsten Versionen.

[Karl (Gast)]

Meinte damit, dass man vom PC aus Parameter auf dem µC verstellen kann. 
Z.B. die Filterkonstante von einem PT1. Zur Laufzeit natürlich.

[Renixor (Gast)]

In der hier veröffentlichten Version ist das noch nicht möglich, aber 
Albert M. hat ja schon geschrieben, dass es in seiner schon geht. Schau 
einfach ein Stück weiter oben, da stehts.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Wie gesagt, kommt in den nächsten Versionen (auch als Eingabebox für 
numerische oder alphanumerische Werte).
Testen kannst Du das aber jetzt schon, indem Du im integrierten Terminal 
die Eingabebox benutzt und auf SendString klickst (impliziert, dass der 
Wert als String gesendet wird).

[Simon L. (dfgh)]

Albert M. schrieb:
> @ Renixor
> Schön, dass Du Dich noch für mein Projekt interessierst.
> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum
> eigentlichen Thema passende Posts aussen vorlässt.
> Daher ist wohl die Veröffentlichung weiterer Versionen nicht so
> dringlich.

> Ob ich das allerdings noch veröffentliche weiss ich nicht, meine
> Motivation dazu wird ehrlich gesagt immer geringer.

Bitte weitermachen!

Ich verfolge das Projekt ebenfalls sehr aufmerksam und finde es 
beachtlich, mit welcher Geschwindigkeit sich das hier entwickelt hat. In 
den meistens Threads hier wird sonst ewig diskutiert, wie man 
[Beliebiger Projektname] am besten realisiert, aber du sorgst dafür, 
dass auch mal etwas fertig wird!

[Dominic A. (neo123)]

Auf jeden Fall ein super Projekt.
Ich fände es praktisch wenn du noch einen kleinen Graphen integrieren 
könntest.

[Karl (Gast)]

Hab gerade mal probiert. Mangels Windows unter Linux+Wine.

Startet, allerdings lässt sich keine serielle Schnittstelle auswählen 
(ja, Wine emuliert die und das funktioniert mit anderen Programmen.)

Weiterhin bekomme ich nur die "Vertikal Meter" unter "instrumente" 
klickbar. Der Rest bleibt stumm.

Hast Du Interesse an Linux+Wine-Unterstützung?

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Simon L. schrieb:
> Ich verfolge das Projekt ebenfalls sehr aufmerksam und finde es
> beachtlich, mit welcher Geschwindigkeit sich das hier entwickelt hat. In
> den meistens Threads hier wird sonst ewig diskutiert, wie man
> [Beliebiger Projektname] am besten realisiert, aber du sorgst dafür,
> dass auch mal etwas fertig wird!

Als ich noch im Beruf stand habe ich gelernt Dinge zu organisieren und 
auf den Punkt zu bringen. Kannst ja hier mal schauen was ich so gemacht 
habe:
http://www.natur-mg.de/Myself.html
Damit habe ich es geschaft seit 1992 nicht mehr zu arbeiten. Ich glaube, 
damit ist auch meine Aversion gegen Labertaschen und Dummschwätzer 
verständlich. Alles was Du hier so siehst betreibe ich ab und an als 
Hobby.
Übrigens ich sehe, dass Du Amateurfunker bist. Damit liebäugele ich auch 
schon einige Zeit und ich glaube ich gehe das mit meinen 63 Jahren auch 
noch an :)
Und danke, dass Dir mein Projekt gefällt.

[Martin S. (sirnails)]

Simon L. schrieb:
>> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum
>> eigentlichen Thema passende Posts aussen vorlässt.

Nene, da gibts noch mehr :) Wir sind die stillen Mitleser. Aber momentan 
mangelt es an Zeit.

[Werner A. (homebrew)]

Martin Schwaikert schrieb:
> Simon L. schrieb:
>>> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum
>>> eigentlichen Thema passende Posts aussen vorlässt.
>
> Nene, da gibts noch mehr :) Wir sind die stillen Mitleser. Aber momentan
> mangelt es an Zeit.

Geht mir genauso. Ich lese auch mit und über lege schon, ob und wie ich 
es im nächsten Projekt nutze.
Mir gefällt das total gut, von daher: "Weiter so!"

[Lutz M. (themroc)]

Albert M. schrieb:

> ... ziemlicher Dummschwatz.

Jaja, scho recht...

Ich hab dann mal ein kleines Alternativprojekt angefangen:

Beitrag "Virtual uC Controlpanel"

Wenn Du in der Lage (und vor allem willens) bist, einfach mal sachlich 
zu diskutieren, könnten wir ja mal versuchen, uns auf ein gemeinsames 
Protokoll für die serielle Schnittstelle zu einigen. Das fänd ich schon 
schick, wenn sich ein uC ohne umprogrammierung mit verschiedenen 
Oberflächen fernsteuern liesse.

[Grafiksucher (Gast)]

Hallo,

ich habe gerade unter Windows 7 64-bit testen wollen und dabei bemerkt 
das die Menüpunkte im Menü "Datei" keinerlei Funktion haben.

Sobald man das Programm beendet sind bisher getätigte Einstellungen 
verschwunden.

Ist das so korrekt?

[Läubi .. (laeubi)]

Lutz M. schrieb:
> uns auf ein gemeinsames Protokoll

Man könnte den Code auch so auslegen, das er einfach verschiedene 
Protokolle unterstützt, z.B. per Plugin ;-)

[Alter F. (kupferstecher)]

Hallo Albert,

die Programmidee finde ich auch sehr gut! Es ist echt selbsterklärend 
(wenn man etwa weiß, was es kann) und übersichtlich.

Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass 
nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit). 
Die Schnittstelle wird erkannt, ob auch was ankommt, hab ich noch nicht 
getestet.


Was ich mir noch als weiteres Element vorstellen könnte ist ein 
Konsolenfenster, das man wie die Instrumente in die Anzeige legen kann, 
als Std-out quasi.
Protokoll könnte entsprechend so aussehen:
#100T"Fehler 1\n"<
T als Text-Identifier (z.B.)

Interressant wäre evtl. auch eine zweite Oberfläche, also "Show 1" und 
"Show 2"

Edit: Wenns rund läuft, wäre das Programm doch auch was fürs 
AVR-Tutorial

[Renixor (Gast)]

Alter Feind schrieb:
> Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass
> nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit).

Das ist kein "Problem" ;)
Weiter oben in den Changelogs ist ja beschrieben, dass diese Funktionen 
einfach noch nicht Implementiert sind. Kommen aber unter Umständen noch.

Albert M. schrieb:
> @ Renixor
> Schön, dass Du Dich noch für mein Projekt interessierst.
> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum
> eigentlichen Thema passende Posts aussen vorlässt.
> Daher ist wohl die Veröffentlichung weiterer Versionen nicht so
> dringlich.

Deshalb bin ich nicht 100% sicher ob da noch was kommt. Hoffe (und 
denke) ich aber schon, da es ja doch Interesse gibt.

MFG Renixor

[gatsby (Gast)]

Hallo an alle,

ich hoffe ebenfalls, daß du, Albert, noch an dem Threat weiterarbeitest.
Da ich zur Zeit an einer Motorradzündung rumprogrammiere, wäre es toll 
den Tacho und den Drehzahlmesser als Rundinstrument zu haben.
Und am Drehzahlmesser noch einen Schleppzeiger, der den Maximalwert für 
2 Sekunden hält (RTL Formel 1 lässt grüßen).
Zum Testen deines Programms habe ich ein kleines Arduino Programm 
geschrieben und es für die Allgemeinheit hier einmal angehängt.

Ich würde mich freuen, wenn es mit dem Programm weitergeht.

Viele Grüße
gatsby

[Leonard S. (renixor)]

gatsby schrieb:
> Zum Testen deines Programms habe ich ein kleines Arduino Programm
> geschrieben und es für die Allgemeinheit hier einmal angehängt

Schön. u.U kann man ja mal für "Noobs" im Programmieren eine kleine Art 
von Sammelung von Funktionen fürs setzten von Instrumenten in 
verschiedenen Sprachen erstellen. Wir hätten dann schon C und wenns dir 
möglich wäre dein Programm noch in ne handliche Funktion zu packen 
hätten wir auch Arduino.

[Grafiksucher (Gast)]

Renixor schrieb:
> Alter Feind schrieb:
>> Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass
>> nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit).
>
> Das ist kein "Problem" ;)
> Weiter oben in den Changelogs ist ja beschrieben, dass diese Funktionen
> einfach noch nicht Implementiert sind. Kommen aber unter Umständen noch.

Ok, sowohl unter Win7 32-bit als auch 64-bit haben alle Menüpunkte im 
Menü "Datei" noch keine Funktion.

Ich bin fälschlicherweise davon ausgegangen das wenigstens der Menüpunkt 
"Datei Beenden" funktionieren müsste. Das er das nicht tut stand 
zumindest bis jetzt noch nicht in diesem Thread.

Aber dennoch gibt es unter Windows 7 einen weiteren Bug. Man muss das 
Programm als Administrator ausführen. Tut man das nicht sind bei einem 
erneuten Start des Programms alle Daten weg.

[Leonard S. (renixor)]

Grafiksucher schrieb:
> Ich bin fälschlicherweise davon ausgegangen das wenigstens der Menüpunkt
> "Datei Beenden" funktionieren müsste. Das er das nicht tut stand
> zumindest bis jetzt noch nicht in diesem Thread.

Das stimmt ! Dachte ich auch, aber Albert hat wohl einfach diesen 
Menüpunkt schonmal erstellt, mehr auch nicht.

Grafiksucher schrieb:
> Aber dennoch gibt es unter Windows 7 einen weiteren Bug. Man muss das
> Programm als Administrator ausführen. Tut man das nicht sind bei einem
> erneuten Start des Programms alle Daten weg.

Interessant. Danke für diesen Hinweis. Habe bis jetzt immer alles neu 
eingerichtet :S Wusste das noch gar nicht :D

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Sorry, wenn ihr im Moment nicht viel von mir hört. Aber wenn ich allen 
antworte, verzettele ich mich nur. Ich lese aber mit und nehme die 
Hinweise auf.

Was die Admin-Rechte zum Ausführen des Programms angeht:
Wenn man das Programm in einem neu erstellten Ordner (NICHT unter 
C:/Programme) speichert und ausführt braucht es eigentlich keine 
Admin-Rechte. Die ganzen Programm-Daten werden als ini-File zur Zeit in 
C:\Users\Anwender\AppData\Local gespeichert, wozu es auch keine 
Admin-Rechte braucht.

[Leonard S. (renixor)]

Albert M. schrieb:
> Sorry, wenn ihr im Moment nicht viel von mir hört. Aber wenn ich allen
> antworte, verzettele ich mich nur. Ich lese aber mit und nehme die
> Hinweise auf.

Also gehts hier noch weiter mitm Programm ! (?)

MFG Renixor

[ecki007 (Gast)]

Ich wollte auch mitteilen dass ich an dem Projekt interessiert bin. ;-)

Gruß Eckard

[Rene A. (r_a)]

Hallo Albert,
sehr gute Arbeit Daumenhoch!!!
Hast Du schon mal über ne Loggingfunktion nachgedacht?
Sowas wie load/Save in txtDatei ; getrennt und im Programm 
rec/stop/play/rev/fwd...
Dann könntest auch unbeaufsichtigt die Daten aufnehmen und später auch 
in Excel oder so auswerten.

Grüße Rene

[Grafiksucher (Gast)]

Albert M. schrieb:
> Was die Admin-Rechte zum Ausführen des Programms angeht:
> Wenn man das Programm in einem neu erstellten Ordner (NICHT unter
> C:/Programme) speichert und ausführt braucht es eigentlich keine
> Admin-Rechte. Die ganzen Programm-Daten werden als ini-File zur Zeit in
> C:\Users\Anwender\AppData\Local gespeichert, wozu es auch keine
> Admin-Rechte braucht.

Ich hab das Programm eigentlich auf dem Desktop liegen.

Wenn man der Datei die Berechtigung "Jeder" mit Vollzugriff hinzufügt 
kann die Datei liegen wo sie will.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei neue Version SerialComInstruments V0.24

Änderungen:

-  Neue Instrumente (Taster) für die Kommunikation zum MC.
   Mit Click auf einen Taster wird die Instrumenten-Nummer #nn
   über die serielle Schnittstelle an den MC geschickt.
   (Diskussionswürdig hier ob die Information als String,
   wie jetzt, oder nur als einzelnes Byte (Werte z.Z. 70...73)
   gesendet werden soll. Im MC ist es ja als einzelnes Byte
   wesentlich einfach abzufragen.
   Nachteil auf dem LA nicht so schön.

-  Alle Instrumente (auch die Taster) können jetzt vollständig
   mit der Mouse in Postion, Höhe und Breite geändert werden.
   Es können auch Instrumente übereinander platziert werden, wie
   man oben im Bild sieht.
   Bedienung:
   Doppel-Click auf das Instrument, dann an den schwarzen
   Markierungspunkten ziehen (ist bischen frickelig, geht aber :)
   Nicht vergessen nach der Änderung eines Instrumentes mit der
   Mouse einmal auf den Hintergrund zu clicken, um den
   Editiermodus zu deaktivieren.

[Leonard S. (renixor)]

Ahhhhh.... Was ist das denn nu ?

//Edit: Hab das gefunden:


"Zitat von smart:
Wofür wird die Datei qtintf70.dll benötigt?
DIe Datei ist die QT-Bibliothek von Delphi 7.
Die Datei wird benötigt wenn dein Programm CLX verwendet und du es unter 
Windows laufen lassen willst."

Quelle: 
http://www.delphipraxis.net/46699-wofuer-wird-die-datei-qtintf70-dll-benoetigt.html

//EDIT 2: Läuft jetzt, musste die manuell noch runterladen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Mit welcher Version ist der Fehler aufgetreten?

[Leonard S. (renixor)]

Deiner Neusten.. gerade runtergeladen. Soll ich die .DLL mal anhängen ?

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Wahrscheinlich habe ich testeshalber irgendwelche Fremdkomponenten 
probiert und die in den Deklarationen anschliessend nicht mehr entfernt. 
Ich schau das mal in Ruhe durch.

[Abdul K. (ehydra)]

Nett. Rechter Mausclick auf Objekt öffnet Einstellungsdialog, wäre 
schön. Und dann natürlich ne Sperrfunktion irgendwo im Menü, damit 
Frauchen beim Einschalten des Boilers nicht alle Instrumente neu 
einsortiert...

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Leonard S
Also ich benutze keine CLX's in meiner Software. Und bei Abdul geht es 
ja. Kann ich mir jetzt auch keinen Reimdrauf machen.

@Abdul K
Der rechte MouseButton öffnet entweder die Instrumenten Seite oder bei 
den Tastern einen Beschriftungs-Dialog.

[Abdul K. (ehydra)]

Abdul hat die Lib, aber nicht jeder.

Rechter Mausclick geht. Muß mir vorher entgangen sein oder eine meiner 
Modifier-Tasten hing mal wieder.

[Grafiksucher (Gast)]

Albert M. schrieb:
> @ Leonard S
> Also ich benutze keine CLX's in meiner Software. Und bei Abdul geht es
> ja. Kann ich mir jetzt auch keinen Reimdrauf machen.

Ich habe leider den gleichen Fehler (Win 7 32-bit)

[Leonard S. (renixor)]

Ja, denke ich auch. Einfach dass man unter "Optionen" diesen Editier 
Mode komplett ausmachen kann... (@abdul)

Außerdem, Bugs ;) : Wenn man ein Vertikal Meter nimmt und es 
"umkrempelt", also es doppelklickt und den rechten äußern Punkt nach 
links über das Instrument drüber zieht, zeigt es nichts mehr an. (Hoffe 
das ist so verständlich)

Dann haben Buttons einen komischen Bug: Wenn man sie per Doppelklick 
auswählt und das wieder deaktiviern will, geht das nur wenn man in den 
Gelb umrandenten Bereich im Bild klickt. Sonst passiert nichts. (Nur bei 
mir so ? evntl. wegen der Bildschirmgröße (1920x1080 Programm auf 
Fullscreen))

Sonst ist aber alles gut und ich mag das neue System.. Irgendwie 
"handlicher".

MFG Renixor

[Leonard S. (renixor)]

Für alle die die .DLL nicht haben: im Anhang!

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei SerialComInstruments V0.24a

Bugs behoben:

-  Auf einigen PC's fehlende qtintf70.dll beigefügt.
   Wenn es Probleme gibt, diese DLL einfach in das
   Programmverzeichnis oder unter /Windows/System32 speichern.

-  Wenn rechter Instrumentenrand nach links über den linken
   Instr.-Rand gezogen wurde, war kein Zugriff mehr möglich

-  Beenden des Edit-Modus war nur im oberen linken Bereich
   durch Click auf den Hintergrund möglich

[Renixor (Gast)]

Super, kanns aber nicht mehr testen heute... Hab morgen Schule :D

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Hier mal eine Vorschau auf die nächste Version mit frei platzierbarer 
und in der Grösse veränderlichen Mini Trend Anzeige.
Eine umfangreiche Trendanzeige, ähnlich wie bei meiner Software 
SerialComGrapher (Beitrag "Daten von der seriellen Schnittstelle einfach darstellen"), 
kommt allerdings erst später.

Im übrigen habt ihr bei der Version 0.24a sicher schon bemerkt, dass 
jetzt ein Verschieben/Grössenveränderung der Instrumente mit 
Doppel-Click eingeleitet und auch wieder mit Doppel-Click beendet wird.

[Oscar K. (sieges)]

Hallo Albert,
einfach Klasse, was Du uns hier zur Verfügung stellst und ein Dankeschön 
dafür.
Bitte laß Dich nur von konstruktiver Kritik motivieren und nicht von 
destruktiver demotivieren
cheers
sieges

[Lutz M. (themroc)]

Läubi .. schrieb:
> Man könnte den Code auch so auslegen, das er einfach verschiedene
> Protokolle unterstützt, z.B. per Plugin ;-)

Richtig. Aber warum unnötige Komplexität einbauen, wenns auch einfacher 
ginge?

[Renixor (Gast)]

Albert M. schrieb:
> Bugs behoben:
>
> -  Auf einigen PC's fehlende qtintf70.dll beigefügt.
>    Wenn es Probleme gibt, diese DLL einfach in das
>    Programmverzeichnis oder unter /Windows/System32 speichern.
>
> -  Wenn rechter Instrumentenrand nach links über den linken
>    Instr.-Rand gezogen wurde, war kein Zugriff mehr möglich
>
> -  Beenden des Edit-Modus war nur im oberen linken Bereich
>    durch Click auf den Hintergrund möglich

Stimmt ;)

Oscar K. schrieb:
> Hallo Albert,
> einfach Klasse, was Du uns hier zur Verfügung stellst und ein Dankeschön
> dafür.
> Bitte laß Dich nur von konstruktiver Kritik motivieren und nicht von
> destruktiver demotivieren

Sehe ich genau so :)

Albert M. schrieb:
> Hier mal eine Vorschau auf die nächste Version mit frei platzierbarer
> und in der Grösse veränderlichen Mini Trend Anzeige.

Sieht schon mal ganz gut aus ;) Hab auch schon Test-Werte für die 
Anzeige.

Was ich mir in folgenden Versionen wünschen würde ist, dass man die 
Instrumente im Edit Mode auch mit den Pfeiltasten verschieben kann, mit 
der Maus kann man sie nicht perfekt Positionieren.

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Ein Beispiel für die Programmierung des ATMega Mikrocontrollers in Luna. 
Das Protokoll wird hier in eine Funktion verpackt.
Wenn der zu übertragenden Wert ein Integer oder Byte ist, sollte man das 
in der Funktion entsprechend deklarieren um den seriellen Bus und den MC 
weniger auszulasten. Oder eben passend zwei Funktionen für Integer/Byte 
und Floating Werte erstellen.
C oder Bascom Programmierer können das sinngemäss übernehmen.

avr.device = atmega328p
avr.clock = 16000000
avr.stack = 100
uart.baud = 115200
uart.Send.enable

Dim i, f as single

do                            ' Erzeugt Rampe (i) und Sinus (f)
  for i =0 to 6.28 step 0.02
    f = fsin(i) + 5
    print SendString(1,i);    ' Sendet an Instrument  1 den Wert i
    print SendString(90,f);   ' Sendet an Instrument 90 den Wert f
                              ' oder auch so:
    print SendString(1,i);SendString(90,f); 
    waitms 100
  next
loop



' Funktion erzeugt den kompletten Protokoll-String
function SendString(InstrNr as byte, MWert as single) as string
  return "#" + Str(InstrNr) + "M" + str(MWert) + "<"
endfunc

[Leonard S. (renixor)]

Ich war so frei (@Albert), die C Funktion und die Luna Funktion beide 
hier, der übersichtlichkeit halber, nochmal zu Posten.


(Hatte weiter oben den Fehler, dass nur Positive Werte geschick werden 
können, da MWert uint32_t war.)

C Funktion:

#include <stdlib.h>
void setInstrument(uint8_t InstrNr, int32_t MWert)
{
  unsigned char str_InstrNr[2];  //Einen 3 großen Buffer für die Nummer.
  itoa(InstrNr, str_InstrNr, 10);//(MaxWert von 255 -> [0][1][2])
  
  unsigned char str_MWert[10];//Einen 11 großen Buffer für den Wert.
  itoa(MWert, str_MWert, 10); //(11, da int32_t 10 Stellen hat plus das
                              //Minus als Vorzeichen)
  
  uart_sendstring("#");         //Die 'uart_sendstring()' Funktion muss 
  uart_sendstring(str_InstrNr); //selber deklariert werden oder es muss
  uart_sendstring("M");         //eine eigene Funktion genutzen werden!
  uart_sendstring(str_MWert);
  uart_sendstring("<");
}

Luna Funktion:

function setInstrument(InstrNr as byte, MWert as single) as string
  return "#" + Str(InstrNr) + "M" + str(MWert) + "<"
endfunc

Aufrufe gehen wie folgt:

In C:

int main(void)
{
    uint8_t Nr = 1;
    uint8_t Wert = 12345;
    while(1)
    {
        setInstrument(Nr, Wert);
    }
}

In Luna:

do                            ' Erzeugt Rampe (i) und Sinus (f)
  for i =0 to 6.28 step 0.02
    f = fsin(i) + 5
    print SendString(1,i);    ' Sendet an Instrument  1 den Wert i
    print SendString(90,f);   ' Sendet an Instrument 90 den Wert f
                              ' oder auch so:
    print SendString(1,i);SendString(90,f); 
    waitms 100
  next
loop

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei SerialComInstruments V0.25

Änderungen:

-  MiniTrend als Instrument #90 eingefügt.
   Mini Trend ist nur eine einfache Trend-Darstellung
   für langsamere Erfassung.
   Eine umfangreichere und schnellere Version (bis 8 Kanäle)
   und mehr Einstellmöglichkeiten kommt später.

-  diverse Bugs behoben

[Leonard S. (renixor)]

Guten Abend,

Also an sich finde ich die Trendanzeige sehr gut! Wie schon von dir 
geschrieben kann man MAXIMAL 10 Werte/s schicken, alle anderen werden 
ignoriert (siehe Bild "zuschnell.jpg"), dass musste ich auch feststellen 
( nur überflogen und nicht richtig gelesen... ;) ) Das andere Bild zeigt 
einen 24h Helligkeits Verlauf. Von Nachts um 24 Uhr bis zur nächsten 
Nacht 24 Uhr. Die Werte werden im Abstand von 210ms geschickt. (hohe 
Werte = Dunkel, niedrige = Hell) Man kann die Anzeige auch noch um den 
Faktor 100 verlangsamen (Time Scale). Ich denke, dass die Anzeige für 
Sensoren, die nur eine geringe Auslesefrequenz haben sehr gut geeignet 
ist, allerdings würde ich mir eine, zumindest grobe y-Achsen 
beschriftung wünschen. Sonst weiss man leider überhaupt nicht WAS das 
für Werte sind nur, nur dass sie sich unterscheiden. Ich habe in dieser 
Version noch keine Bugs gefunden :)

//EDIT: Leider ist bei den Bilder irgendetwas schief gelaufen, sehen 
komisch aus, das wesentliche ist aber erkennbar.

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei SerialComInstruments V0.25a

Änderungen:

-  Zum MiniTrend-Instrument rudimentäre Y-Achsenbeschriftung zugefügt.
   Weitergehender Ausbau bleibt dem 8-Kanal Trend-Instrument
   vorbehalten. Dies hat jedoch z.Z. keine Priorität.
   Event. gibt es aber bald zum MiniTrend einen 2. Kanal #91

Im übrigen habe ich das MiniTrend Instrument mal testeshalber
mit ca. 100 Werten/s beaufschlagt (siehe Bild und Testprogramm für Luna 
oben). Es gehen dabei keine Werte verloren. Es werden dabei höchsten, 
durch die niedrige Vorschubgeschwindigkeit der Grafik, Pixel mit 
weiteren Werten überschrieben, aber zu Signalabrissen in der Grafik 
kommt es dabei nicht.

[Benedikt K. (benek)]

Habe mal die neue Version an einem Helligkeitssensor (LDR) ausprobiert. 
Interssant ist hier, dass die Trendanzeige das Flackern (?) meiner 
Schreibtischlampe mit aufgezeichnet hat (siehe Anhang).

MfG Bene

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei neue Version SerialComInstruments V0.26

Änderungen:

-  LED-Panel mit 8 Led's, Instrumenten-Nummer #60

   Das 8 Kanal Led Panel (Led' 0 ...7) wird mit einem einzigen
   Byte angesprochen und stellt den Inhalt binär mit 8 bit
   (die Leds 0 bis 7) dar.
   Damit kann z.B. ein ganzer MC-Port dargestellt werden.

   Der Mikrocontroler schickt den Wert m  0...255 als String.
   Protokoll: : #60Mm<
   Beispiel:    #60M16<  schaltet Led 4 ein
                #60M255< schaltet alle Led's ein

   Ein Programmierbeispiel in Luna ist beigefügt. Der Code kann
   einfach für C oder Bascom als Vorlage dienen. Es zeigt das
   MC-Programm für obiges Bild (ohne die zwei Buttons).

   Bei der Verschiebung/Grössenänderung muss der Doppel-Click
   in der Nähe des Randes vom Panel erfolgen, da bei Click auf
   Led oder Text nicht reagiert werden kann.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei neue Version SerialComInstruments V0.26a

Korrektur:

-  Es wurde versehentlich die Version mit meinem Debug-Panel
   veröffentlicht :)

[Einhart P. (einhart)]

Vielen Dank Albert!
Was du da baust ist wirklich Klasse. Ich werde das gut für meine neue 
Heizungssteuerung gebrauchen können.

Gruß
Einhart

[Leonard S. (renixor)]

Hey, schöne Version.
Wie immer ein Bild von dem funktionierendem Instrument, in dem Fall die 
LED anzeige. Für diese Anzeige eignet sich es besonders, die Binär 
schreibweise zu verwenden, im AVR Studio geht das ja mit "0b00101010". 
Habe mal die Instruments Funktion auf eigene Header und Sourcefiles 
ausgelagert, da ich ein paar #define's gemacht habe und es doch größer 
ist und noch wird. Jetzt kann ich einfach jedes Element über seinen 
Namen ansprechen:

    setInstrument(LEDPANEL01, 0b01010101);

Damit erzeug man die Ausgabe auf dem Bild "leds.jpg". Andere Instrumente 
werden ähnlich angesprochen, einfach in "instruments.h" nach den defines 
gucken. Hab das mal angehängt.

/EDIT: Fast vergessen ;), wie immer klasse Arbeit Albert.
Das Projekt wächst.

MFG Renixor

[HAL2000 (Gast)]

super Arbeit!
Ich habe das Beispiel in Luna abgeändert, sodass die 
Speicherverwaltungs- und String-Bibliotheksfunktionen nicht eingebunden 
werden müssen (spart 1,1 kb), in diesem Zusammenhang möchte ich den 
Vorschlag machen den Messwert wahlweise als Festkommazahl senden zu 
können. Dann würde man sich auch die Floating-Point-Bibliothek sparen 
(1,3 kb).

'  Luna Beispiel :  SerialComInstruments 8 LED Panel (#60)
'  
avr.device = atmega328p
avr.clock = 20000000
avr.stack = 100
uart.baud = 115200
uart.Send.enable

dim i as byte

do
  for i =0 to 255 step 1
    SendString(1,i)
    SendString(90,i)
    SendString(60,i)
    waitms 100
  next
loop


' Funktion erzeugt den kompletten Protokoll-String
procedure SendString(InstrNr as byte, MWert as int32)
  print "#";str(InstrNr);"M";str(MWert);"<"
endproc

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

HAL2000 schrieb:
> in diesem Zusammenhang möchte ich den
> Vorschlag machen den Messwert wahlweise als Festkommazahl senden zu
> können.

Meinem Programm ist egal ob da Festkommazahl oder Floatingpoint kommt.
Du kannst somit die Funktion etwa so ändern (wobei ich nicht weis, was 
Luna da einbindet oder nicht):

procedure SendString(InstrNr as byte, MWert as byte)
  print "#";str(InstrNr);"M";str(MWert);"<"
endproc


Leonard S. schrieb:
> /EDIT: Fast vergessen ;), wie immer klasse Arbeit Albert.
> Das Projekt wächst.

Danke, dass Du so unermüdlich mitwirkst!

[Leonard S. (renixor)]

Albert M. schrieb:
> Danke, dass Du so unermüdlich mitwirkst!

Kein Ding ;)

Schönen Abend noch,
Renixor

[HAL2000 (Gast)]

entschuldige, mein Fehler, es wird ja dezimal ASCII übertragen, perfekt!

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Anbei neue Version SerialComInstruments V0.27

Änderungen

-  Neues Instrument Sollwertgeber mit der Instr.-Nr. #80
   Der Sollwertgeber sendet nach Änderung den eingestellten
   Wert über die serielle Schnittstelle an den Mikrocontroller.
   Bedienung:
   Doppel-Click wie immer für Verschieben/Grösse ändern.
   Mit der Mouse kann am Drehrad der Wert grob eingestellt werden.
   Feineinstellung mit gedrückter linker Moustaste und
   gleichzeitigem Drehen am Mousrad.
   Solange der Drehknopf des Sollwertsgebers rot leuchtet,
   wird der Wert noch nicht übernommen. Dies geschieht erst
   beim loslassen der Mousetaste.

   Das Sendeformat wird wie folgt erzeugt und als String gesendet:
   #80Mm<  wobei m = Sollwertgeberwert

   Wie ihr oben seht habe ich mal mit dem Logikanalyser getestet
   ob auch alles richtig rausgeht.

-  Diverse kleinere Bugs beseitigt.
-  Installationsanleitung beigefügt

Ich denke mal, dass man jetzt schon so langsam mit der Software
richtig was anstellen kann :)

[Renixor (Gast)]

Wow, das geht ja richtig schnell jetzt mit neuen Instrumenten. Muss 
jetzt aber zur Schule, meld mich heute Nachmittag mal und gucks mir dann 
an ;)

MFG Renixor

[Dieter H. (biker10)]

Hallo Albert,

verfolge Dein Projekt mit großem Interesse. Es gefällt mir sehr gut.

Ich teste gerade den Sollwertgeber mit der Instr.-Nr. #80.
Die Nachkommastellen des Sollwertes sind bei, Feineinstellung mit
dem Mausrad, abhängig vom "Anzeige Wert bis".

"Format Skala"     = ##0.000
"Anzeige Wert bis" =  99  die Feineinstellung ist dann 0,099, 0,198, 
0,297
"Anzeige Wert bis" = 100  die Feineinstellung ist dann 0,1    0,2,   0,3
"Anzeige Wert bis" = 101  die Feineinstellung ist dann 0,101, 0,202, 
0,303

D.h je nach Wert von "Anzeige Wert bis" ergibt sich eine andere 
Feineinstellung.
Ist es möglich ein weiteres Eingabefeld mit einem Wert für die 
Feineinstellung zu programmieren?

Bitte mach weiter so.

Gruß
Biker10

[Chris (Gast)]

Sieht sehr gut aus.
Ich haette einige Anregungen.
- HW Flusskontroller fuer die Serielle Schnittstelle
  Es gibt Projekte, wo man sowas hat, weil man Timings hat, welche nicht
  gestoert werden duerfen, bzw wo man auch keine verfuegbare rs232 hat.
  Dann werden alle x MS die Schnittstelle fuer 10ms eingeschaltet und 
wieder abgeschaltet.
- ID des uC, damit man nicht die falsche Aktion runtersendet.
  Es sollte eine irgendwelche Pruefung der uC Kennung und des Screens 
sein,
ev auch unterschiedliche Screens je nach subversionsunterschied.
- Bilder, z.B. Animated Gifs mit Transparenz und der uC waehlt dann ein
  Bild aus. Beispiel ware dann auch "TESTING" "PASS" "FAIL" "RECAL" 
"HIGH VOLTAGE" entsprechend angezeigt. Es kann aber auch ein Thermometer 
sein, welches hochgeht oder eine sonstige spezielle Anzeige. Am besten 
mit LZW Kompressionsunterstuetzung. Patente sind schon laenger 
ausgelaufen.
- einen EEprom dump Fenster um Sensordaten zu kalibrieren.
 Also ein Grid in einem separatem Fenster. Dort gibt es dann 4x einen
Button um dat0-3 zu laden und 4x Buttons um diese wieder zu speichern.
Wenn man den Button zur Laden der Config0 drueckt sendet der PC ein 
Befehl
runter.
Der uC antworted dann mit der Anzahl von row und cells und schickt die 
daten hoch. Gleichzeitig sollte auch die Mòglichkeit vorhanden sein, 
diese Daten abzuspeichern, zu laden und zu veraendern. Hex/dec Anzeige 
sollte umstellbar sein und ein Button die Werte runterzuladen. 4 Solcher 
configurationen sollten reichen. Beim runterladen sollte der uC die 
Laenge sowie eine ID bekommen, z.B. die ersten zwei Byte des Datensatzes 
und dann
sollter der uC die Laenge der Daten raufschicken, wie er sie haben will,
oder 0 fuer will keine Daten haben. Dies nur als Anregung, ich weiss das 
bereits ein Protokoll besteht.
- Ein Dll Interface, welches sich inmitten der seriellen Schnittstelle
und dem Programm einhaengen kann. Bitte keinen Unicode sondern 
PCHAR(ANSICHAR(..))
 Dies kann gemacht werden um ein anderes Protokoll zu fahren, oder auch 
um
 z.B. einen PID Regler fuer ein Reflow Ofen zu implementieren, wie auch 
ev.
ein Log zu erstellen, oder dieses wieder einzuspielen, oder auch fuer 
automatische Beriechsumschaltung usw.
- Eventuell ein DLL, welches eine Grafik bekommt, in der er was 
reinkopiert und einen Mousehandler wenn da was gedrueckt wurde. Auch 
sollte diese DLL gewisse Werte bekommen und eine Methode haben, um eine 
Neuzeichnung der Grafik zu forcieren. Damit kònnte die oben erwàhnte 
animated gif gemacht werden, bzw custom instrumente.

[Leonard S. (renixor)]

So, habs getestet:
Finde das Instrument ganz nett. Die Bedienung finde ich gut gelöst, man 
kann nämlich auch mit Rechtsklick auf den Knopf drücken und so bequem 
mit dem Mausrad die Feineinstellungen machen. Mit Rechtsklick kann man 
den Knopf NICHT drehen. Hab aber nen kleinen Bug gefunden: wenn man 
Rechtsklick macht, den Wert verändert(also Mausrad bewegt) wird der 
Knopf richtiger weise Rot, aber beim loslassen bleibt er Rot. Ansonsten 
denke ich auch, dass es gut wäre, wenn man den Feineinstellungswert 
selber festlegen könnte.

Ansonsten wirklich gut, anbei ein Bild mit einer "Nutzmöglichkeit" als 
Temperatur Regler. (Hat bei mir jetzt keine Funktion ;) )

MFG Renixor

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@Chris

Ich habe mir Deine Ideen angeschaut und finde sie interessant
Allerdings scheint mir, dass die meisten den Hobbybereich überschreiten 
und eher für den professionellen Einsatz Bedeutung haben.
Daher möchte ich noch einmal klarstellen:

Meine Software richtet sich an die Hobbbyisten, d.h. an Leute die kein 
Geld mit ihren Basteleien verdienen.
Ganz bewusst soll das kein Tool für den Profi sein oder in absehbarer 
Zeit werden. Hallo - wer macht denn kostenlose Software mit der dann 
andere ihr Geld verdienen?

Um genau diesen Profi-Einsatz zu vermeiden hat meine Software z.B. keine 
Hardware Flusskontrolle, keine Fehlerkorrektur für 
Datenübertragung/Protokoll, kein komplexes Protokoll usw. und ist auch 
sonst ganz gezielt fürs Hobby entwickelt.

Und glaube mir, ich weiss genau was auch die minimalste SCADA Software 
kostet. Ich war früher selber in der Messtechnik für Industrie und 
Wissenschaft tätig. Nicht dass ich mein Programm auch nur entfernt mit 
Profi-Tools vergleichen will, aber zwischen kostenlos und dem kleinsten 
Profi-Programm liegen mind. 4-stellig Euro-Beträge und dazwischen gibt 
es eigentlich kaum was.

Trotz allem finde ich einige Ideen von Dir auch fürs Hobby 
überlegenswert und Danke Dir für die vielen Vorschläge.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Dieter und Leonard

Schau mir mal an was sich da machen lässt.

[Didi S. (kokisan2000)]

Hallo Albert,

klasse Arbeit!!!

Ich teste Dein Programm gerade mal am flotten ARM Prozessor und dabei 
bekomme ich Schwierigkeiten mit der Abstimmung der oberen 
Geschwindigkeiten.
115200 bekomme ich noch super synchronosiert, 128000 und 256000 sind 
aber sehr unüblich. Aufgrund der am UART verbauten Quarze sind eher 
üblich:
110, 150, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 
230400, 460800, 921600

Mein ARM und Rechner machen mit Terminalprogrammen 921600 locker mit.

Darf ich Dich bitten oberhalb 115200 die drei üblichen Speeds 230400, 
460800, 921600 in Deinem Programm zur Auswahl zuzulassen. Ich teste das 
dann gerne aus.

Gruß
kokisan

[Chris (Gast)]

Hallo, es waren einfach nur "Anregungen" die mir dazu eingefallen und 
die
ich anmerken wollte, keine Wünsche oder Forderungen zwecks kommerziellem 
Einsatz. Weiterhin glaube ich daß HW Handshake mehr im Hobby Umfeld als
im professionellen Einsatz verwendung findet. Für professionellen 
Einsatz,
zur Verhinderung eines Bufferüberlaufes glaube ich nicht, daß hier bei
der Implementierung eine Gefahr besteht.

Andererseits sehe ich folgende Einsatzgebiete:
Reflow Ofen
Th

[Chris (Gast)]

Hallo, es waren einfach nur "Anregungen" die mir dazu eingefallen und 
die
ich anmerken wollte, keine Wünsche oder Forderungen zwecks kommerziellem 
Einsatz. Weiterhin glaube ich daß HW Handshake mehr im Hobby Umfeld als
im professionellen Einsatz Verwendung findet. Für professionellen 
Einsatz,
zur Verhinderung eines Bufferüberlaufes glaube ich nicht, daß hier bei
der Implementierung eine Gefahr besteht.

[Bernd N (Gast)]

Habe deine aktuelle Version ebenfalls getestet, sehr schön. Außer ein 
paar "kosmetischer" Fehler ist soweit alles ok.

Ich hätte noch einen Vorschlag zu den Instrumenten, denkst du daran auch 
7 Segment Anzeigen hinzuzufügen ?

Erst mal ein großes Lob für deine bisherige Arbeit.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Didi S. schrieb:
> 115200 bekomme ich noch super synchronosiert, 128000 und 256000 sind
> aber sehr unüblich. Aufgrund der am UART verbauten Quarze sind eher
> üblich:
> 110, 150, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200,
> 230400, 460800, 921600
> Mein ARM und Rechner machen mit Terminalprogrammen 921600 locker mit.
> Darf ich Dich bitten oberhalb 115200 die drei üblichen Speeds 230400,
> 460800, 921600 in Deinem Programm zur Auswahl zuzulassen. Ich teste das
> dann gerne aus.

Die gewünschten Baudraten bis 921600 kann ich implementieren. Ich habe 
bis  921600 Baud bereits getestet und es funktioniert ohne 
Datenverluste.
Ich habe mal veränderliche Werte mit dieser Datenrate ohne Pause 
zwischen den Datensätzen kontinuierlich auf die Instrumente geschickt. 
Die machen das alle mit, zu sehen ist aber dann nicht mehr viel, weil 
alles tierisch schnell abgeht :)
Zumindest zeigt es, dass in der Software noch viel Luft ist und ich mit 
der Auslastung nicht am Anschlag bin.


Bernd N schrieb:
> Ich hätte noch einen Vorschlag zu den Instrumenten, denkst du daran auch
> 7 Segment Anzeigen hinzuzufügen ?

Ich wollte eh noch ein Zahlendisplay erstellen, mal schauen was mit 
7-Segment geht (die Darstellungsart finde ich aber ziemlich hässlich).

[Martin S. (sirnails)]

Oder gar ein LCD? :)

[Chris (Gast)]

Darf ich anstelle 7 Segment ein 14 Segment oder ein configurierbares LCD
vorschlagen.

[physiker (Gast)]

Es gibt durchaus auch (einfache) freie SCADA-Systeme, z.B.:

http://pvbrowser.de

[Grafiksucher (Gast)]

Wie ist der Empfang von Nachrichten im µC eigentlich gedacht?

Wenn alles was von SerialInstruments kommt in einen Ringpuffer 
geschrieben wird und nach und nach abgearbeitet wird, wird es 
problematisch ein Befehl bzw. die Daten zu erkennen.

Hat da schon jemand was vorbereitet?

#81M25 könnte nach etwas Zeit ja noch zu #81M250 werden, oder #7 zu #71 
bzw. #72

Gruß

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Grafiksucher schrieb:
> Wie ist der Empfang von Nachrichten im µC eigentlich gedacht?
> Wenn alles was von SerialInstruments kommt in einen Ringpuffer
> geschrieben wird und nach und nach abgearbeitet wird, wird es
> problematisch ein Befehl bzw. die Daten zu erkennen.
> Hat da schon jemand was vorbereitet?
> #81M25 könnte nach etwas Zeit ja noch zu #81M250 werden, oder #7 zu #71
> bzw. #72

Da hast Du vielleicht das von mir vorgesehene Endezeichen < im Protokoll 
#nMm< übersehen? Damit ist klar definiert wann der Messwert zuende ist.

Beim Taster #70...#73 ist es eigentlich auch klar, weil n immer 
zweistellig sein muss. Ich werde abertrotzdem das Taster-Protokoll mit 
dem Endezeichen < erweitertn, damit das Protokoll überall einheitlich 
bleibt.
Also schicken die Taster dann demnächst #n<

Noch einheitlicher wäre das Protokoll-Kontrukt #70M1< für 
Schalterbetätigung, aber das halte ich für übertriebeb - oder?

[Grafiksucher (Gast)]

Albert M. schrieb:
> Da hast Du vielleicht das von mir vorgesehene Endezeichen < im Protokoll
> #nMm< übersehen? Damit ist klar definiert wann der Messwert zuende ist.

Erwischt. Ich hab's total übersehen. Danke.

Albert M. schrieb:
> Beim Taster #70...#73 ist es eigentlich auch klar, weil n immer
> zweistellig sein muss. Ich werde abertrotzdem das Taster-Protokoll mit
> dem Endezeichen < erweitertn, damit das Protokoll überall einheitlich
> bleibt.
> Also schicken die Taster dann demnächst #n<
>
> Noch einheitlicher wäre das Protokoll-Kontrukt #70M1< für
> Schalterbetätigung, aber das halte ich für übertriebeb - oder?

#71< ist undefiniert.
#71M1< ist definiert 1
#71M0< ist definiert 0

#71< könnte man lediglich für eine Aktion sehen. Aber nicht um einer 
Variable einen absoluten Wert zuzuweisen.

Ich meine ...
#71M1< #71M1< ist immer noch 1
#71M0< #71M0< ist immer noch 0
#71< #71< ergibt ?

Eventuell macht es sogar sinn es per Konfiguration festlegen zu können.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Die Gruppe #70...#73 sind ja Taster, keine Schalter. Daher ist es 
eigentlich sinnfrei da einen Wert übertragen zu wollen. Mit der 
Übertragung von z.B. #70< zeigt man ja nur an, dass der Taster 70 
betätigt wurde. Ich meine es reicht hinter der Tasternummer das < 
Endezeichen.

Im PC habe ich für die Differenzierung der Instrumente ein einfaches 
Kontrukt z.B. so:

case InstrumentNummer
  10..19 :  mach was für Analog Vertikal Meter mit der Instr.-Nummer
      60 :  mach was für 8 Led Panel
      90 :  mach was für Trend-Anzeige
end

Das dürfte sich sinngemäss auf den Mikrocontroler übertragen lassen.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Im übrigen glaube ich, dass ich das Ganze mal dokumentiere, so eine Art 
Gebrauchsanleitung und Protokollbeschreibung. Damit Neueinsteiger nicht 
den ganzen Thread durchlesen müssen, um sich die wichtigen Änderungen 
stückchenweise raus zu suchen.

[Didi S. (kokisan2000)]

Hallo Albert,

eigentlich ist es garnicht so sinnfrei beim Taster den Wert zu 
übertragen. Noch besser wäre es zwei Werte zu übertragen und zwar genau 
dann, wenn "getastet" wird.
Wenn ich Projekte µC mit Taster ausstatte benötige ich manchmal die 
Zeit, die ein Taster betätigt wurde, z.B. um eine Pumpe für wenige 
Sekunden arbeiten zu lassen, um Licht langsam auf oder ab zu dimmen. 
Denke bitte mal darüber nach, ob Du eine Möglichkeit für sinnvoll 
hältst, zwei Werte vom PC an den µC zu übertragen: wenn das Drücken 
startet und wenn wieder losgelassen wird. Auf Controller Seite kann man 
dann selber eintscheiden, welche Flanke (oder beide) Verwendung finden.

Gruß
kokisan

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

@ Didi S.

Da hast Du recht was eine erweiterte Tasterfunktion anbetrift.
Ich möchte die Überlegung aber zuerst mal zurückstellen, da in Kürze 
Schalterelemente dazukommen. Damit ist dann eigentlich genau das möglich 
was Du möchtest. Die Schalter müssen bei Änderung ja sowieso immer ihren 
Status (Ein/Aus) übertragen. Wenn das nicht reicht schauen wir mal 
weiter :)

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Vorschau auf die nächste Version.
Voraussichtliche Veröffentlichung Anfang nächster Woche.

[Renixor (Gast)]

Sieht gut aus.

[Alter F. (kupferstecher)]

Das Programm nimmt ja schon richtig Form an!

Ich hätte noch den Vorschlag, verschiedene Anzeigen zu einem Kanal 
zusammenzufassen, die dann per Drop-Down auswählbar sind. Einige 
Instrumente sind ja sowieso nur verschiedene Representationen, z.B. 
Vertikalmeter, Horizontalmeter, Balkenanzeige und 270°-Meter. Die 
Parameter sollten eigentlich auch die gleichen sein.
Der Drehknopf könnte unter einem Instrument Wertausgabe noch neben 
Vertikal- und Horizontal-Slider und einem numerischen Eingabefeld 
(vielleicht mit Sende-/Refreshtaste) Platz finden.
Das gleiche wäre dann auch für Schalter und Taster möglich, man könnte 
sich da ja auch ein gleiches Protokoll überlegen, also für den Taster 
beim Drücken #70M1< und beim Loslassen #70M0< (so hab ich auch Didi S. 
verstanden) und für den Schalter je nach Stellung #70M0< bzw. #70M1<.

Dadurch hätte man für die einzelnen Elemente mehr freie Kanäle. Ich weiß 
aber natürlich nicht, wie einfach oder schwierig das in deinem Programm 
umzusetzen ist.


Was ich mir auch noch wünschen würde, sind Einzel-LEDs. Gerne auch als 
Auswahlpunkt unter den bestehenden LED-Kanälen.


Zu den Tastern: Wenn man im normalen Modus (nicht doppelgeklicklt) mit 
der rechten Maustaste auf den Taster klickt, geht ja das Textfeld auf. 
Dabei werden leider die alten Texte verworfen. Schöner fände ich es, 
wenn es wie die anderen Konfigurationen im Instrumente-Menü eingestellt 
würde, auch wenn die Konfiguration insgesamt mehr Klicke benötigt. Das 
Programm wäre damit auch in sich konsistent.


Ich hoffe, meine Kommentare sind hilfreich! Insgesamt gefällt mir dein 
Projekt sehr gut!

Grüße

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

In der nächsten Version wird es zusätzlich zur 7-Segmentanzeige noch 
weitere Instrumente "Numerische Anzeige" gegen. Diese basieren auf einem 
einzigen Grundelement (Bild oben links), welches sich einstellbar wie 
gezeigt in der Erscheinungsform anpassen lässt, ähnlich der 
Vertikal-Meter.