Projekt: Virtuelle Instrumente an serielle Schnittstelle

[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.


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

Ist vorgesehen.

> 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.

Mal sehen wie ich das löse, wahrscheinlich bekommen auch die Taster ein 
eigenes Einstellpanel. Da man für jeden Taster dann sowieso auswählen 
müsste, ob eine Information für Drücken und Loslassen oder nur für 
Drücken gesendet wird.

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

Über Deine anderen Anregungen mache ich mir noch Gedanken.
Und ja, Deine Kommentare sind hilfreich, da man ja schnell betriebsblind 
für die eigene Software wird. Also Danke!

[Bernd N (Gast)]

Hallo Albert,

ich habe mir jetzt mal ein bischen mehr Zeit genommen und ein 
entsprechendes Gegenstück für einen MC geschrieben. Die Benutzung des 
Tasters kann nervig sein denn wenn man zu schnell drückt dann wechselt 
dieser in den, nennen wir es, Skalierungsmodus. Kannst du eine 
Möglichkeit schaffen ein Objekt, wenn es denn fertig skaliert und 
positioniert ist, zu verriegeln ? ich fände das für alle Instrumente 
sinnvoll.

Beim positionieren wäre ein "Grid" sinnvoll so das die Objekte leichter 
positioniert werden können (Magnet Funktion).

Ansonsten ganz ok, wann kommt die nächste Version ?

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

Anbei neue Version SerialComInstruments V0.28

mit Beispielprogramm für einen ATMega328p in Luna.
Lässt sich einfach nach C oder Bascom konvertieren.
Mit diesem Programm wurden die Instrumente im obigen
Bild betrieben.


V0.28 Change Log
-----------------

Baude Rate erweitert mit 230400, 460800 und 921600 Baud.

7-Segment-Display zugefügt mit Instrument Nummer #40.

Protokolländerung für Taster: #nnMm<
Wahlweise senden Taster jetzt nur bei Betätigen
oder auch bei Betätigen und Loslassen.
m ist bei Betätigen 1 und bei Loslassen 0.
nn steht für die Taster 70...73.

Rechts Click auf Taster-Instrumente öffnet jetzt das
Instrumente Konfigurations-Menue

Wenn die Schnittstelle aktiv ist, ist ein Doppel-Click
auf die Instrumente nicht mehr möglich.
Damit wird das versehentliche Senden von Commandos
über die Schnittstelle verhindert.

4 numerische Displays Zugefügt,
Instrumenten-Nummer #41..44.
Die Grösse der Displays wird durch die Fontgrösse der
Anzeige bestimmt. Um bei mehreren Displays gleiche
Grössenverhaltnisse zu haben, sollte man Schriftarten
mit festem Zeichenabstand, wie z.B. Courier New einsetzen,
jedoch keine Proportional-Schriften.

1 weiteres Instrument Sollwertgeber mit der Instr.-Nr. #81
zugefügt. Es sind jetzt also 2 verfügbar.

2 Backgroundbilder (Raster) als Positionierhilfe beigefügt.
RasterBackground1.png und RasterBackground2.png.
Die Raster wurden mit Microsoft Word erzeugt.
Das Bild mit der kleineren Dateigrösse (RasterBackground1)
verursacht weniger Hintergrund-Refresch während des
Verschiebens von Instrumenten. Ich werde für die nächste
Version ein Raster mit wesentlich kleinerer Dateigrösse
erzeugen, damit das Layout schneller refreshed.

[gatsby (Gast)]

Hallo an alle,

hier ein kleines Programm für den Arduino Duemilanove, das für das von 
Albert erstellte Instrumententableau (siehe obigen Threat) Daten 
liefert.

Nocheinmal vielen Dank an dich, Albert, für dein tolles Programm und 
deine ganze Arbeit. Ich hoffe, daß noch einige Funktionen hinzukommen.

Viele Grüße
gatsby

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

Anbei neue Version SerialComInstruments V0.28a


V0.28 Change Log
----------------

Dateiformat für Hintergrundbild ist jetzt "JPG".

Flackern des Hintergrundes / Hintergrundbildes
bei Verschieben/Grössenänderungen von
Instrumenten vollständig behoben.
Dazu gibt es unter dem Menue Show einen neuen
Eintrag "Edit Mode".
Edit Mode schaltet den Hintergrund-Farbverlauf
aus und ermöglich eine flackerfreie Plazierung
der Instrumente. Der Farbverlauf wird durch
"Connect Interface" wieder eingeschaltet.

[Bernd N (Gast)]

Hallo Albert

>> 4 numerische Displays Zugefügt,
>> Instrumenten-Nummer #41..44.
>> Die Grösse der Displays wird durch die Fontgrösse der
>> Anzeige bestimmt.

Bei diesen Instrumenten gibt es keine Font Auswahl und es wird nur eine 
Ziffer angezeigt.

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

Bernd N schrieb:
> Bei diesen Instrumenten gibt es keine Font Auswahl und es wird nur eine
> Ziffer angezeigt.

Zu Instrumnet 40:
Wenn Du als Gesamtstellen 4 und Nachkommastellen 3 eingibst, bekommst Du 
bei einem Wert vom z.B. 235 nur eine Ziffer, nämlich die 5.
Übrigens wird das Format erst bei Eintreffen von Werten aktiviert.
Zu einer 7-Segment-Anzeige wäre eine Fontauswahl wohl kontraproduktiv :)

Zu Instrumenten 41..44
Also bei mir kann man da zwei Fonts zu jedem Instrument auswählen.
Wenn Du hier nur eine Ziffer bekommst, stimmt was mit dem von Dir 
eingegebenen Formatstring z.B. ##0.00 nicht.

[Leonard S. (renixor)]

Abend,
Melde mich hier auch mal wieder zu Wort,
ich finde die Neuerungen gut, bis auf die 7-Segment Anzeige. ;)
Momentan hat die noch m.M.n. gar keinen richtigen Sinn. Sie kann bloß 
Zahlen darstellen, welche ist nicht ersichtlich... Ich denke, dafür 
gibts zwei Möglichkeiten das zu lösen:
Entweder man macht diese Einstellungen noch zu der Anzeige oder (was ich 
schöner finden würde), man macht sie zu einer der NUM-Displays, nur als 
Siebensegment. Die sehen einfach schöner aus. Auch habe ich das Prizip 
der Gesamtstellen/Nachkommastellen nicht auf anhiebt verstanden -> noch 
Optimierungsbedarf. Die anderen NUM-Anzeigen sind schön und der neue 
Slider ist auch gut. Anbei wie immmer ein Bild :)

MFG Renixor

[Bernd N (Gast)]

>> Zu Instrumenten 41..44
>> Also bei mir kann man da zwei Fonts zu jedem Instrument auswählen.

Wie der Screenshot zeigt hatte ich No 40 verwendet, da gibt es keine 
Font Auswahl. Macht ja nix, danke für den Hinweis.

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

Leonard S. schrieb:
> ich finde die Neuerungen gut, bis auf die 7-Segment Anzeige. ;)
> Momentan hat die noch m.M.n. gar keinen richtigen Sinn. Sie kann bloß
> Zahlen darstellen, welche ist nicht ersichtlich

Die 7-Segment Anzeige sollte zur Grossanzeige von Werten dienen und hat 
daher keine weiteren Einstellmöglichkeiten für Zusatztexte / 
Bezeichnungen.
Dafür sind ja die Instrumente 41..44 da.

[Abdul K. (ehydra)]

Das Programm läuft übrigens auch auf alten Windows, wenn man KernelEx 
installiert und Kombatibiltät dort auf WinXP SP2 setzt.

Nett.

Vielleicht den Redraw des Hintergrundbildes noch etwas optimieren. Warum 
nur JPG? Ist für Grafiken suboptimal.

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

Abdul K. schrieb:
> Das Programm läuft übrigens auch auf alten Windows, wenn man KernelEx
> installiert und Kombatibiltät dort auf WinXP SP2 setzt.

Das ist mit ein Grund warum ich in Delphi programmiere. Meine exe-Datei 
ist gerade 2 MB gross und mehr braucht man nicht. Von der 
Verarbeitungsgeschwindigkeit des Kompilats mal gar nicht zu reden.
Schau Dir da mal andere Programmiersprachen an, die hätten dem Anwender 
gleich 200 MB an benötigten Bibliotheken mit aufs Auge gedrückt. Und auf 
älteren Windows Versionen hat man dann trotzdem noch immer Ärger mit der 
Kompatibilität. Und mit irgendwelchen Interpretersprachen lässt sich so 
ein Projekt nicht mit der nötigen Verarbeitungsgeschwindigkeit stemmen.

> Vielleicht den Redraw des Hintergrundbildes noch etwas optimieren. Warum
> nur JPG? Ist für Grafiken suboptimal.

Die Hintergrundgrafiken können demnächst jpg oder png sein. War jetzt 
nur zu faul :)

[Abdul K. (ehydra)]

ja ja, weiß ich alles. Kann dir nur recht geben, aber wir werden einfach 
weniger und die Kids interessiert das nicht.

Wenn du die Gestaltung der Laderoutine für die Hintergrundbilder anders 
machst, brauch man vermutlich noch nicht einmal KernelEx. Bis dahin lief 
es nämlich auch ohne diesem.

Und wenn du das Projekt mit 7z komprimierst, ist es nochmal 30% kleiner.

Ich würde die DLL nur noch als Bemerkung zu einem Post hier verlinken. 
Oder lade sie doch einfach mit deinem Programm.

Noch kleiner kannst nur du es machen :-)

Gute Arbeit!

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

Hier eine Vorschau auf die nächste oder übernächste Version:

Ein neues Instrument als Trenddarstellung mit 2 (oder 4) Kanälen, das 
folgende Möglichkeiten bietet:

- Echtzeitmessung mittels Cursor innerhalb der Kurvendarstellung
- freie Skalierung der Y-Achsen
- auch während der Messung ältere Werte ansehen
- event. schnellere Aquisition als der vorhandene Mini-Trend
- Speicherung und Laden der Daten (Daten event. auch fremd nutzbar)
- Grafischer Ausdruck incl. Legende

Im Übrigen ist die z.Z. aktuelle Version 0.28a, siehe oben im Thread.

[Kupferstecher (Gast)]

Hallo Albert,

noch eine Idee: Wenn man in der Konfiguration bei jedem Instrument noch 
ein Feld "Wert weiterreichen" hätte, könnte man Instrumente in gewisser 
Weise verknüpfen. Z.B. einen aktuellen Wert per Vertikalmeter anzeigen 
und dann an die Trendanzeige weiterleiten. Genauso ein Sliderwert an den 
zweiten Kanal der Trendanzeige und schon hötte man einen 
Soll-/Ist-Vergleich auf einfache Weise. Die Implementierung sollte auch 
nicht so kompliziert sein, nehme ich an.

Viele Grüße

[Kupferstecher (Gast)]

Habs vielleicht nicht so verständlich formuliert:
Im Feld "Wert weiterreichen an" wird der Instrumentenkanal (kk) 
angegeben, daraus der String #kkMnn< generiert und intern auf den 
Instrumentenkanal gelegt.

[Grafiksucher (Gast)]

Hallo,

super Arbeit.

Bei der Mini-Trend-Anzeige ist mir aufgefallen das der Skalier-Faktor 
nicht gespeichert wird.

Die zuletzt verwendete COM-Schnittstelle wird nicht gespeichert. Man 
muss sie bei jedem Programmstart neu auswählen, wobei die Baudrate 
gespeichert wird.

Weiter so.

Gruß

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

Anbei neue Version SerialComInstruments V0.29

Change Log
----------

2 Instrumente AktivLabel zugefügt.
Instrumenten-Nummer #35..36.
Das Instrument AktivLabel zeigt Text an, der
vom Mikrocontroller gesendet wird.
Protokoll:  #nMm<
wobei n = Instrumenten-Nummer , m = Text
Aktiv Label führt einen Zeilenumbruch durch
wenn der Text zu lang ist. Dadurch ist es
möglich mehrere Textzeilen in einem
AktivLabel anzuzeigen.

Programm-Hilfe als pdf-Datei zugefügt.
Aufruf im Menue unter "Hilfe"

Skalierfaktor von MiniTrend Instr.90
wird jetzt gespeichert.

Diverse kleinere Bugs beseitigt.


Die Implementation das angekündigten umfangreichen Trend-Instruments 
wird etwas dauern. Daher habe ich noch schnell die obige Version 
eingeschoben.


@Kupferstecher
Dein Vorschlag ist mit erheblich mehr Aufwand verbunden als Du Dir 
vorstellst und daher vorerst nicht realisierbar.
Das was Du erreichen willst, nämlich die Darstellung des Sollwert und 
des Istwertes in der neuen Trenddarstellung, ist einfach zu erreichen:
Da der Sollwertgeber ja sowieso seinen Wert an den MC schickt, schickst 
Du den eben mit dem Istwert zurück. Das hat noch den Vorteil, dass Du 
damit erkennst, dass der Sollwert auch am MC angekommen ist ;)

@Grafiksucher
Der Fehler mit dem Skalierfaktor bei der Trendanzeige ist behoben.
Das problem mit der Speicherung der zuletzt benutzten Schnittstelle muss 
ich noch überdenken. Ist diese beim Neustart nicht mehr vorhanden, würde 
es jedesmal eine Fehlermeldung geben, die dann quittiert werden müsste. 
Die Frage ist - was ist lästiger?

[Martin S. (sirnails)]

Herrschaftszeiten hängst Du dich da rein :)

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

Martin Schwaikert schrieb:
> Herrschaftszeiten hängst Du dich da rein :)

Ich hab ja sonst nix zu tun, da ist das zur Herbst/Winterzeit gerade die 
richtige Beschäftigung damit der Kopf was zu arbeiten hat.

Im Frühling/Sommer habe ich dafür keine Lust, da gibt es dann andere 
Beschäftigungen z.B.:
http://www.fotocommunity.de/fotograf/ulrich-maassen/fotos/1508221

[Benedikt K. (benek)]

Albert M. schrieb:
> Ein neues Instrument als Trenddarstellung mit 2 (oder 4) Kanälen, das
> folgende Möglichkeiten bietet:

Ich freu mich schon drauf :). Danke für dein Engagement!

MfG Bene

[Grafiksucher (Gast)]

Albert M. schrieb:
> @Grafiksucher
> Der Fehler mit dem Skalierfaktor bei der Trendanzeige ist behoben.
> Das problem mit der Speicherung der zuletzt benutzten Schnittstelle muss
> ich noch überdenken. Ist diese beim Neustart nicht mehr vorhanden, würde
> es jedesmal eine Fehlermeldung geben, die dann quittiert werden müsste.
> Die Frage ist - was ist lästiger?

Für mich ist es lästiger jedes mal die Schnittstelle neu einstellen zu 
müssen. Die vorhandenen Schnittstellen ändern sich bei mir eigentlich 
nur wenn ich bewusst was daran ändere. Keine Ahnung wie es den anderen 
dabei geht.

Bei Terminalprogrammen wie z.B. hterm wird die Schnittstelle im Projekt 
mitgespeichert.

[Grafiksucher (Gast)]

Hab noch was gefunden:

Bei Instrument 80+81 Slider wird der Parameter "Anzeige Wert von" nicht 
gespeichert.

Nach Programm-Neustart ist auf der Konfigurationsseite das Häkchen für 
81 Slider entfernt obwohl das Instrument auf der Showseite angezeigt 
wird.

Vorschläge:

Ich finde den Initialwert der div. Instrumente 50% unglücklich gewählt, 
denn jedes Messgerät zeigt ohne Beschaltung eigentlich 0 an.

Eventuell könnte man als Instrumente auch noch einzelne LED's 
hinzufügen. Dabei könnten die Rot für 0, Gelb für noch kein Wert und 
Grün für 1 anzeigen. Eventuell kann man die Farbe auch in der 
Konfiguration hinterlegen. Die Beschriftung der LED's (SignalName und 
InstrumentenNr) könnte man über die Konfiguration eventuell ausblendbar 
machen.

Ansonsten ... Weiter so.

[Werner A. (homebrew)]

Sehr geil, jetzt muss ich doch mal mit meinem Project anfangen ;-)
Vielen Dank

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

Grafiksucher schrieb:
> Bei Instrument 80+81 Slider wird der Parameter "Anzeige Wert von" nicht
> gespeichert.

Funktioniert bei mir einwandfrei.
Lösche mal unter C:\Users\Anwender\AppData\Local
die Datei SerialComInstruments.ini
Da können schon mal von vorherigen Installationen Reste verbleiben.

> Nach Programm-Neustart ist auf der Konfigurationsseite das Häkchen für
> 81 Slider entfernt obwohl das Instrument auf der Showseite angezeigt
> wird.

Ist korrigiert.

> Ich finde den Initialwert der div. Instrumente 50% unglücklich gewählt,
> denn jedes Messgerät zeigt ohne Beschaltung eigentlich 0 an.

Habe ich geändert.

> Eventuell könnte man als Instrumente auch noch einzelne LED's
> hinzufügen.

Ist vorgesehen. Ich überlege nur noch wie man die zusammenfassen kann, 
sonst artet das mit den Instrumenten-Nummern schnell aus.

Und für die nächste Version gibt es einen Installer, der das Setup 
komplett übernimmt.

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

Anbei neue Version SerialComInstruments V0.29a


Change Log
----------

Liniengenerator erzeugt Postionierhilfen
grob und fein auf dem Hintergrund.
Es sind nun dafür keine externen Grafiken
mehr notwendig. Zu finden unter "Show".

Unter Menue Hilfe ist jetzt eine Programm-
Referenz als pdf-Datei aufrufbar.

Als Hintergrund können jetzt JPG oder PNG
Grafiken/Bilder geladen werden.

Aktuelle ComPort Nummer wird gespeichert.

Problem mit Slider #81 Häkchen behoben.

Instrumente haben jetz den Intitialwert 0.

Die Installation des Programms und aller
zugehörigen Dateien erfolgt jetzt über
einen Installer, der auch entsprechende
DeInstalltions-Routinen aufspielt.



Das ist jetzt die letzte Zwischenversion. Nun muss ich die Zeit
wirklich in die neue Trendanzeige investieren :)

[Grafiksucher (Gast)]

Albert M. schrieb:
> Anbei neue Version SerialComInstruments V0.29a

Kann es sein das es sich versehentlich um die Version 0.29 statt 0.29a 
handelt?

Es scheint als wäre keiner der Bugs behoben. Im Programm wird auch die 
Version 0.29 angezeigt.

[Grafiksucher (Gast)]

Albert M. schrieb:
> Grafiksucher schrieb:
>> Bei Instrument 80+81 Slider wird der Parameter "Anzeige Wert von" nicht
>> gespeichert.
>
> Funktioniert bei mir einwandfrei.
> Lösche mal unter C:\Users\Anwender\AppData\Local
> die Datei SerialComInstruments.ini
> Da können schon mal von vorherigen Installationen Reste verbleiben.

Anscheinend kann nur der Wert 0 nicht gespeichert werden, er ändert sich 
nach Programmneustart immer wieder auf 0,000001.

[gatsby (Gast)]

Hallo,

@Grafiksucher
Ich habe das Programm heruntergeladen und installiert. Bei mir zeigt die 
Info eindeutig "0.29a" an.
Die Version des Programms scheint daher OK zu sein.

Viele Grüße
gatsby

[Grafiksucher (Gast)]

Grafiksucher schrieb:
> Albert M. schrieb:
>> Anbei neue Version SerialComInstruments V0.29a
>
> Kann es sein das es sich versehentlich um die Version 0.29 statt 0.29a
> handelt?
>
> Es scheint als wäre keiner der Bugs behoben. Im Programm wird auch die
> Version 0.29 angezeigt.

gatsby schrieb:
> Hallo,
>
> @Grafiksucher
> Ich habe das Programm heruntergeladen und installiert. Bei mir zeigt die
> Info eindeutig "0.29a" an.
> Die Version des Programms scheint daher OK zu sein.
>
> Viele Grüße
> gatsby

Sorry mein Fehler. Vielen Dank

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

Einzel Led's

Um bei mehreren einzelnen Led's (in den nächsten Versionen) nicht für 
jedes eine Gerätenummer spendieren zu müssen, habe ich mir folgendes 
Protokoll ausgedacht.
Unter einer einzigen Gerätenummer sind die Led's einfach 
durchnummeriert. Für den Aus-Zustand wird nur die Led-Nummer übertragen, 
für den Ein-Zustand wird zur Led-Numm 100 addiert.
Das Protokoll sähe dann z.B. so aus (n = Geräte-Nummer):

#nM12<  für Led 12 aus
#nM112< für Led 12 ein

So lassen sich theoretisch mit einer Gerätenummer bis zu 99 Leds 
bedienen.
Was haltet ihr davon?

Übrigens habe ich noch eine Lösung für einen komfortablen 
Hintergrund-Designer gefunden, mit dem sich einfach technische 
Hintergrund-Layouts erstellen lassen auf denen die Instrumente (auch 
teiltransparent) plaziert werden können.

[Chris (Gast)]

Was haltest du von einer anderem Vorschlag:
#n.mMv< wo n die ID des Instruments ist, m ist die sub-id und v der 
Wert.

[biker10 (Gast)]

Einzel Led's

es wäre vielleicht besser von der Syntax bei EIN/AUS eine
einheitliche Stellenanzahl zu benutzen:


Erste Stelle:  1 = generell Ein
               0 = generell Aus

2+3 Stelle       = LED Nr

#nM112< für Led 12 ein
#nM012< für Led 12 aus


Gruß Dieter

[Renixor (Gast)]

Ich denke das Protokoll ist so schon gut. Jedenfalls auf µC Seite ist da 
keine Veränderung nötig. (Ich rede jetzt speziell von C) Also @Albert, 
wenn dass für dich auch gut umsetztbar ist, wäre ich stark für so eine 
Umsetzung.
Eignet sich halt besonders bei so vielen LED's...

[Grafiksucher (Gast)]

Albert M. schrieb:
> Um bei mehreren einzelnen Led's (in den nächsten Versionen) nicht für
> jedes eine Gerätenummer spendieren zu müssen, habe ich mir folgendes
> Protokoll ausgedacht.
> Unter einer einzigen Gerätenummer sind die Led's einfach
> durchnummeriert. Für den Aus-Zustand wird nur die Led-Nummer übertragen,
> für den Ein-Zustand wird zur Led-Numm 100 addiert.
> Das Protokoll sähe dann z.B. so aus (n = Geräte-Nummer):
>
> #nM12<  für Led 12 aus
> #nM112< für Led 12 ein
>
> So lassen sich theoretisch mit einer Gerätenummer bis zu 99 Leds
> bedienen.
> Was haltet ihr davon?

Ich würde eigentlich lieber bei Deinem bisherigen Protokoll bleiben, 
denn dann ist jedes Instrument gleich. Wer sagt denn das die 
Instrumentennummer nicht 3, 4 oder sogar 5-stellig sein darf?

Mann könnte auch die Instrumente dynamisch zur Programmlaufzeit erzeugen 
und die Instrumentennummer so fortlaufend vergeben oder frei 
konfigurierbar machen. Wenn sie frei konfigurierbar wäre könnte man auch 
mehrere Instrumente über eine Instrumentennummer vom µC her ansprechen.

Einen kleinen Bug hab ich noch gefunden. Der Skalier-Faktor von der 
Mini-Trend-Anzeige wird nicht mitgespeichert.

[Kupferstecher (Gast)]

Alberts Vorschlag mit Biker10s Erweiterung find ich gut! Wobei ich 
zuerst den Port und dann ein/aussetzen würde, einfach aus 
Lesbarkeitsgründen.
Wie werden Einstellungen gemacht? Oder gibt es eben einen Kanal grüne, 
einen mit roten und einen mit gelben LEDs?

Das AktivLabel gefällt mir sehr gut! Wenn du das noch mit 
Zeilenaufzeichnung (Speicher des vorigen Befehls)  und gesteuertem 
Zeilenumbruch (/n) machen könntest, hätte man eine Konsole.


Noch eine Sache: Wenn man das Verbindungskabel abzieht, geht das 
Programm in einen Fehlerzustand, wo nur noch ein Programmneustart hilft, 
wäre hier ein Softreset möglich?

[biker10 (Gast)]

1. Vorschlag Implementierung

Wie in deinem 1. Bild vom 9.10.2013 bereits dargestellt.
Die Skala in 3 Farb-Bereiche unterteilen die im Konfigurationsmenü des
Instrument frei einstellbar sind, sowohl Farbe als auch Anfang/Ende der 
Farbe.

Beispiel Temperaturmessung, die Skala hat den Anzeige Wert von 20 bis 60
  Farbe 1: von 20 bis 40    blau (Temperatur zu kalt)
  Farbe 2: von 40 bis 50    grün (Temperatur im Sollbereich)
  Farbe 3: von 50 bis 60    rot  (Temperatur zu hoch)

Vorteil: der Messwert kann visuell sofort eingeschätzt und zugeordnet 
werden.


2. Vorschlag Implementierung

Bezieht sich ebenfalls auf dein 1. Bild vom 9.10.2013.
Instrument #01 Vert. Meter

Dem Instrument#01 auf der Skala einen zweiten "Skala Zeiger" (Messwert)
mit eigener Farbe zuordnen.

#1.2M...<     Protokollvorschlag für den zweiten "Skala Zeiger"

Vorteil: sofortiger visueller Vergleich von zwei Messwerten
         und es muss kein zweites "Vert. Instrument" erzeugt und
         auf dem Schirm positioniert werden.

Gute Arbeit, weiter so.

Dieter

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

Anbei neue Version SerialComInstruments V0.3

Change Log
----------

FullTrend Mehrkanal-Linienschreiber
zugefügt. Zur Zeit sind 2 Kanäle
(51 und 52) aktiv benutzbar.
Mittels Mess-Cursor können die Signal-
verläufe in Realtime ausgemessen werden.
Der Vorschub ist einstellbar zwischen
10 Pixel/s und 1 Pixel/10min. Mehr
dazu in der Programm PDF-Hilfe.

Div. Bugs behoben


Ansonsten habe ich eure Vorschläge der letzen Tage notiert und schaue 
mal was sich verwirklichen lässt.


P.S. jetzt habe ich noch Bugs in der Beschriftung am neuen Instrument 
entdeckt (Einheits-Bezeichnungen und Hintergrundfarbe). Wird in der 
nächsten Version behoben.

[Renixor (Gast)]

@Kupferstecher

Also bei mir kann ich das Kabel einfach abziehen.... Passiert nix, außer 
das man keine Daten mehr bekommt. Wenn mans wieder einsteckt gehts halt 
ganz normal weiter.

MFG und Schönen Tag euch,
Renixor

[Leonard S. (renixor)]

Mittag zusammen,
Foto der Trend Anzeige anbei, mit echten Messwerten...
Hab auf die schnelle keine Bugs gefunden. (Außer die, die Albert schon 
im Changelog angegeben hat)
Sieht echt gut aus und ist auch sehr schön konfigurierbar.
Wieder eine super Erweiterung.

//EDIT: Channel 2 ist auch Aktiv, beide liegen aber scheinbar in 
einander, da beides die selben Werte sind nur mit anderen Skalen. Wenn 
man genau schaut sieht man den Grünen.

MFG,
Renixor

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

Ich habe noch einen Grafik-Bug bei der FullTrend Anzeige entdeckt:
Wenn der Messwert den eingestellten Wert von "Anzeige Wert von" 
unterschreitet, schiesst die Kurve nach oben und verleibt dort bis der 
Messwert die Einstellung von "Anzeige Wert von" wieder überschreitet. 
Dies ist ein Fehler in der zugekauften Delphi Grafik-Komponente und ich 
warte noch auf eine Reaktion des Komponentenherstellers.

Das Problem kann aber zunächst einfach umgangen werden, wenn man die 
Einstellung von "Anzeige Wert von" immer kleiner/gleich dem kleinsten zu 
erwartenden Messwert wählt, was in den meisten Fällen sowieso gemacht 
wird. Daher ist es wohl auch noch keinem aufgefallen :)

[Grafiksucher (Gast)]

Hallo,

bei meinen Tests, die ich Versuche so praxisnah wie möglich zu 
gestalten, habe ich folgendes Problem das sicher immer wieder auch bei 
anderen vorkommen wird.

Mein µC schickt mir 8 Temperaturwerte an die Instrumente 1-8. Als dann 
das Mini-Trend-Instrument hinzukam musste ich meinem µC beibringen einen 
der Temperaturwerte 2x zu schicken um ihn auch am Mini-Trend anzeigen zu 
können. Das ist zwar nicht tragisch aber der µC sendet dadurch Daten 
doppelt zum PC. Nun wo das neue Instrument Full-Trend verfügbar ist 
würde ich es gerne anstatt des Mini-Trend einsetzen. Dies ist wiederum 
nur möglich wenn die Firmware des µC geändert wird.

Ich fände es toll, wenn der µC Daten nur 1x zum PC senden muss auch wenn 
die Daten von mehreren Instrumenten angezeigt werden sollen und wenn man 
ein Instrument gegen ein anderes austauschen könnte ohne Änderungen am 
µC machen zu müssen.

Eventuell könnte man das realisieren, wenn die Daten nicht direkt an das 
Instrument geschickt werden würden sondern an einen Datenkanal und 
diesen Datenkanal trägt man dann am Instrument ein. So könnten mehrere 
Instrumente an einem Datenkanal hängen oder einfach ausgetauscht werden. 
Ich hoffe man versteht wie ich das meine.

Ansonsten bin ich wie immer begeistert. Weiter so.

Gruß

[Cyblord -. (cyblord)]

Grafiksucher schrieb:
> Ich fände es toll, wenn der µC Daten nur 1x zum PC senden muss auch wenn
> die Daten von mehreren Instrumenten angezeigt werden sollen und wenn man
> ein Instrument gegen ein anderes austauschen könnte ohne Änderungen am
> µC machen zu müssen.

Das macht mich schon die ganze Zeit an diesem Projekt stutzig. Gut dass 
es mal einem Anwender auffällt!

Laut dem Protokoll muss der Controller entscheiden welche Daten auf 
welchen Instrumenten angezeigt werden. Also der kleine 8-Bitter muss 
beim senden der Daten bereits wissen, welche grafischen Instrumente auf 
dem großen PC zu sehen sein sollen und welche nicht. Und vor allem, 
welche es gibt und welche nicht. So können keine neuen Instrumente 
hinzukommen, ohne dass der Controller das weiß und die Firmware geändert 
wird.

Das ist in meinen Augen eine komplette Fehlbesetzung der 
Zuständigkeiten. Der Controller sollte seine Daten in einen vorgegeben 
Format senden, das PC-Programm entscheided dann, via Konfiguration, wie 
es diese Daten grafisch anzeigt. Damit kann man dann natürlich auch 
diesselben Daten unterschiedlich anzeigen.

gruß cyblord

[Fred (Gast)]

cyblord ---- schrieb:
> Laut dem Protokoll muss der Controller entscheiden welche Daten auf
> welchen Instrumenten angezeigt werden. Also der kleine 8-Bitter muss
> beim senden der Daten bereits wissen, welche grafischen Instrumente auf
> dem großen PC zu sehen sein sollen und welche nicht. Und vor allem,
> welche es gibt und welche nicht. So können keine neuen Instrumente
> hinzukommen, ohne dass der Controller das weiß und die Firmware geändert
> wird.

Wäre es nicht eine tolle Möglichkeit, wenn der Controller seine Daten
in einem beliebigen Format sendet und das Programm durch Config bestimmt
wie das ganze auszusehen hat?

Dazu müsste dann aber vermutlich eine DLL vorgeschaltet werden oder
ein Parser der die Eingangsdaten gemäß Config in das eigene SCI Format
umsetzt.

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

Grafiksucher schrieb:
> Ich fände es toll, wenn der µC Daten nur 1x zum PC senden muss auch wenn
> die Daten von mehreren Instrumenten angezeigt werden sollen und wenn man
> ein Instrument gegen ein anderes austauschen könnte ohne Änderungen am
> µC machen zu müssen.

Ich hatte bereits die Möglichkeit zum Durchschleifen von Kanälen in die 
neue Version 0.31 integriert. Vorerst ist dies für die Vert.Meter 1 und 
2 möglich die sich auf die FullTrend Anzeige durchschalten lassen.
Ein Austausch von Instrumente ist event. später möglich, wahrscheinlich 
ist dies aber nur für fie reinen Analog-Instrumente möglich, da diese 
diese keine Protokollabweichung besitzen. Da brauche ich im Dispatcher 
nur die gewünschte Instrumenten-Nummer austauschen. Für Digital-Anzeigen 
mit spezieller Protokollbedeutung wird dies schwierig.

cyblord ---- schrieb:
> Das macht mich schon die ganze Zeit an diesem Projekt stutzig. Gut dass
> es mal einem Anwender auffällt!
> Laut dem Protokoll muss der Controller entscheiden welche Daten auf
> welchen Instrumenten angezeigt werden. Also der kleine 8-Bitter muss
> beim senden der Daten bereits wissen, welche grafischen Instrumente auf
> dem großen PC zu sehen sein sollen und welche nicht. Und vor allem,
> welche es gibt und welche nicht. So können keine neuen Instrumente
> hinzukommen, ohne dass der Controller das weiß und die Firmware geändert
> wird.
> Das ist in meinen Augen eine komplette Fehlbesetzung der
> Zuständigkeiten. Der Controller sollte seine Daten in einen vorgegeben
> Format senden, das PC-Programm entscheided dann, via Konfiguration, wie
> es diese Daten grafisch anzeigt. Damit kann man dann natürlich auch
> diesselben Daten unterschiedlich anzeigen.

Erstmal siehe meine Antwort an Grafiksucher. Damit wären schon mal 
Teilaspekte abgedeckt.
Dann möchte ich die Versions-Nummer 0.3 verweisen, dass da noch nicht 
alle möglichen Instrumente bekannt sein können, dürfte klar sein. Da 
musst Du eben abwarten.
Und das von Dir angedachte universelle Protokoll für alles (47) ist oben 
irgendwo im Thread schon genüsslich durchgekaut worden. Ich habe mich 
dagegen entschieden, weil so ein Universal-Protokoll letztlich 
unhandlich und kompliziert wird. Hast Du Dir schon mal "universelle" 
Protokolle für SCADA Systeme angeschaut? Ich glaube darauf hat hier 
niemand Lust.
Auch für Dich nochmal:
Dies ist ein Projekt für Bastler, dementsprechend einfach ist das 
Protokoll. Und ja, wenn sich was bei den Instrumenten ändert, muss man 
eben manchmal den MC umprogrammieren. Ich habe gehört, dass soll auch 
bei Industrie-Projekten vorkommen :)
Und das ganze wird von mir als Freeware zur Verfügung gestellt. Ich 
betreibe dies als Hobby nebenher und das Ergebnis ist für Hobbyisten. 
Ich habe nicht vor meine ganze Zeit darin zu verwenden. Also beib auf 
dem Teppich. Ich versuche möglichst die Wünsche von euch zu 
berücksichtigen, aber ein industrietaugliches Projekt wird und soll es 
nicht werden.
Und als letztes: Niemand muss meine Software einsetzen. Wenn Du dazu 
ebenso kostenlose Alternativen findest die alle Deine Wünsche 
berücksichtigen, benutze einfach diese.


Übrigens ist die neue Version 0.31 so weit fertig.
Change Log:

FullTrend Bezeichnungsfehler und
fehlende Speicherung von Einstellungen
behoben.

FullTrend kann jetzt die Messwerte von
Virt.Meter übernehmen. D.h. die Werte von
Virt.Meter werden optional zum FullTrend
durchgeschleift.
Durchreichen geht momentan mit Virt.Meter
1 und 2. Die Einstellung hierzu findet sich
im Konfigurationsmenue von FullTrend.

FullTrend Start jetzt über grüne Pfeil-Led.
Blinkt wenn gestartet.

8 Einzel Led's (demnächst mehr)
Protokoll #65Mm<
Wobei der String m aus 4 Stellen besteht:

1. Stelle:   0 = Led aus
             1 = Farbe 1 ein (beliebige Farbwahl)
             2 = Farbe 2 ein (beliebige Farbwahl)
             3 = Farbe 3 ein (beliebige Farbwahl)

2. Stelle:   0 = Led blinkt nicht
             1 = Led blinkt

3. + 4. Stelle geben die Led-Nummer an.

Beispiel für m:
0000 = Led0 aus
2107 = Led7 mit Farbe 2 ein und blinkt


Desweiteren denke ich über die Möglich der Anbindung ans Netzwerk nach. 
Damit könnte man dann auch den MC weiter entfernt laufen haben. Oder 
event. mehrere MC's an der Software betreiben.

[Gerhard W. (gerhard_w)]

Ich sag einfach mal Danke an Albert. Ich hab das Tool letztes Wochenende 
mal getestet und finde es jetzt schon sehr gelungen.

Hab auch noch überlegt, welche Funktionalität man noch gebrauchen 
könnte. Aber irgendwie konnte ich schon alles mit den vorhandenen 
Mitteln abbilden.
Die einzige Idee (mit Betonung auf "Idee"), die übrig blieb, war, daß je 
nach Kommandoeingang unterschiedliche Grafiken angezeigt werden können. 
Z.B. sendet der µC #99M1< und die Grafik "1" wird angezeigt.
Als Anwendung sehe ich hier Beispielsweise eine Ampel, eine 
Frostwarnung, ein Warnhinweis oder was weiß ich noch alles.

Ist wie gesagt nur ne Idee...


Gruß
Gerhard

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

Gerhard W. schrieb:
> Die einzige Idee (mit Betonung auf "Idee"), die übrig blieb, war, daß je
> nach Kommandoeingang unterschiedliche Grafiken angezeigt werden können.
> Z.B. sendet der µC #99M1< und die Grafik "1" wird angezeigt.

Es freut mich, dass Dir mein Programm gefällt.
Deine Idee habe ich notiert und werde sie wahrscheinlich denächst 
realisieren. Die Implementation ist einfach. Die Grafiken müssen dabei 
natürlich auf dem PC vorgehalten werden. Bewegte gif-Grafiken wären dann 
auch machbar.


Noch Fragen an alle:

Ist eine X/Y-Darstellung interessant? Dabei X und Y in linear oder log.
Vielleicht Für Bode Diagramme, Ortskurven oder ähnliches?

FFT, auch wenn die Erfassung ja relativ langsam ist, gibt es dafür 
Anwendungsfälle (ich habe sowas mal für Rundheitsmessungen an Kugeln 
gemacht). Oder ist das zu exotisch?

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

Anbei neue Version SerialComInstruments V0.31

Change Log
----------

FullTrend Bugs behoben.

FullTrend kann jetzt die Messwerte von
Virt.Meter übernehmen. D.h. die Werte von
Virt.Meter 1 und 2 werden optional zum
FullTrend Instrument durchgeschleift.

8 Einzel Led Instrumente zugefügt.
Die Led's lassen sich frei beschriften und die
3 Farbeinstellungen können frei gewählt werden.
Protokoll #65Mm< wobei der String m aus 4 Stellen besteht:
1. Stelle:   0 = Led aus
             1 = Farbe 1 ein
             2 = Farbe 2 ein
             3 = Farbe 3 ein
2. Stelle:   0 = Led blinkt nicht
             1 = Led blinkt
3. + 4. Stelle geben die Led-Nummer an.

Beispiel für m:
0000 = Led0 aus
2107 = Led7 mit Farbe 2 ein und blinkt


... und noch einen Bug gefunden:
Die neuen Led's sind versehentlich auf "Schalter-Mode" gesetzt,
so dass sie bei einem Click aus/ein schalten.
Wird in der nächsten Version behoben.

[Bernd N (Gast)]

Dobble soll sicher Double sein, der springt mich an :-)

>> Desweiteren denke ich über die Möglich der Anbindung ans Netzwerk nach.
>> Damit könnte man dann auch den MC weiter entfernt laufen haben. Oder
>> event. mehrere MC's an der Software betreiben.

Sehr gute Idee, freu mich darauf.

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

Für die nächste Version habe ich einen 8-stelligen Dip-Schalter mit der 
Gerätenummer #75 vorgesehen.

Features:

Kann aktiv vom Mikrocontroller abgefragt werden.
Der MC schickt #75M1< und der Dip-Schalter reagiert darauf mit dem 
Senden seines eingestellten Wertes als Byte(m), also mit #75Mm<.
Zusäzlich ist einstellbar, ob der Dip-Schalter auch nach Veränderung der 
Einstellung seinen Wert an den MC schickt.

[Renixor (Gast)]

Klingt interessant mit den Schaltern. Leider ists mi nicht möglich die 
zu Testen, da mein Max232 scheinbar den Geist aufgegeben hat. Der Pegel 
der Rx Leitung sackt bei Verbindungen auf ~1V ab....

Alle anderen Instrumente werde ich natürlich aber Testen ;)

 Mfg Renixor

[biker10 (Gast)]

Hallo Albert,

Danke für Deine Arbeit, das Programm wird immer funktionaler und ich 
schätze es sehr das du es der Allgemeinheit zur Verfügung stellst.

Grafiksucher schrieb:
> Eventuell könnte man das realisieren, wenn die Daten nicht direkt an das
> Instrument geschickt werden würden sondern an einen Datenkanal und
> diesen Datenkanal trägt man dann am Instrument ein. So könnten mehrere
> Instrumente an einem Datenkanal hängen oder einfach ausgetauscht werden.

Die Aussagen von Grafiksucher und cyblord haben einen gewissen Charme.

Es könnte eine Anzahl von (analogen) Datenkanälen eingeführt werden
an die der µC seine Daten sendet,
  z.B.:  #K1M...  bis  #K??M..,        (K = Kanal)

Bei den entsprechenden (analogen) Instrumenten könnte dann die Zuordnung 
zur Anzeige des Datenkanals erfolgen (wie jetzt schon in der Version 
0.31),
  z.B.:  bei Instrument #1,   Messwert Übernahme von   #K1
  z.B.:  bei Instrument #51,  Messwert Übernahme von   #K1
  z.B.:  bei Instrument #52,  Messwert Übernahme von   #K2

Die Zuordnung der (analogen) Messwerte zum Anzeige-Instrument würde dann 
nur durch Konfiguration in deinem Programm geschehen und nicht mehr im 
µC selbst.

Soweit ein paar weitere Gedanken zu diesem Thema.

Eine X/Y-Darstellung ist interessant, nach Möglichkeit mit der Auswahl 
linear oder log.

Gruß Dieter

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

@ Biker

biker10 schrieb:
> Die Aussagen von Grafiksucher und cyblord haben einen gewissen Charme.

Ich bestreite ja nicht das so ein Konzept optimal wäre.

Das Problem ist nur, dass ich als One-Man-Show das alles in annehmbarer 
Zeit zum Laufen bringen will (im Frühling und Sommer habe ich dafür 
keine Lust). Was ich hier in gerade mal 4 Wochen hinbekommen habe, wäre 
in der Industrie mind. ein Halbjahresjob für eine Abteilung. Wenn ich 
nur optimale Konzepte benutzen wollte, wäre ich noch bei der Konzeption 
und der jetzige Stand in vielleicht einem Jahr erreicht. Deshalb 
reagiere ich vielleicht auch ein wenig stinkig, wenn ich mit erhobenem 
Zeigefinger belehrt werde, wie es doch so viel besser geht (nicht von 
Dir).

Fakt ist, dass ich an der jetzigen Konzeption nichts Wesentliches ändern 
werde, bis alle Instrumente, die ich mir oder ihr euch so vorstellt, 
eingebunden sind.
Anschliessend denke ich dann gerne über eine verbesserte Konzeption 
nach.

Wäre ich allen bisher gemachten Vorschlägen nachgegangen (wer den ganzen 
Thread gelesen hat weiss was ich meine), würde hier nichts existieren 
und das Projekt wäre wie die 95% der anderen Projekte zerredet und 
schnell im Sand verlaufen. Deshalb entschuldigt bitte meinem sturen 
Kopf, aber der hat auch so seine Vorteile :)

[Abdul K. (ehydra)]

Ich finde diese Kritik nicht ganz zielführend. Es ist wichtig einen 
konkreten Milestone vor Augen zu haben und sich auf dem Weg dahin nicht 
in zu viele supertolle Detaillösungen zu verlieren. Genauso wichtig ist 
es aber auch, mindestens zwei Schritte voraus schon Ideen im Hinterkopf 
zu sammeln. Ansonsten kann es zu einer zu geschlossenen Lösung kommen, 
die dann schlicht gar nicht mehr weiterentwickelbar wird. Da die 
richtige Balance zu halten, zeichnet den wirklich erfahrenen Entwickler 
aus.

Also voran! Sieht schon gut aus.

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

Ich habe jetzt mal interessehalber die Latenz-Zeit (bei 115200 Baud) vom 
neuen Dip-Schalter gemessen. D.h. die Zeit vom Absenden der Anfrage des 
MC, der Verarbeitung im PC, bis zum vollständigen Ankommen der 
PC-Antwort am MC.

Also der MC schickt die Anfrage #75M1< und der PC antwortet oben im 
Beispiel mit #75M11<, der gerade erfassten Dip-Schalterstellung.

Es ergibt sich, wie oben im Bild zu sehen ist, eine ziemlich kurze 
Latenz-Zeit von nur 3,3 ms (schwankt allerdings bei mehreren Messungen 
so zwischen 2 ms und 4 ms).

Ebenfalls sieht man daran, dass die Verabeitungszeit für dieses 
Dip-Schalter-Instrument im PC ca. 2.2 ms dauert. Für andere Instrumenhte 
gehe ich mal im Mittel von 2 ms aus, da einige Instrumente wenig 
rechenintensiv sind.

[Martin S. (sirnails)]

Pah! Ich bin beeindruckt. Ob optimal oder nicht ist da erstmal egal.

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

Anbei neue Version SerialComInstruments V0.32

Change Log v0.32
----------

Dip-Schalter mit Instrument-Nr. #75 zugefügt.
Kann aktiv vom Mikrocontroller abgefragt werden.

Der MC schickt #75M1< und der Dip-Schalter reagiert
darauf mit dem Senden seines eingestellten Wertes
als Byte(m), also mit #75Mm<.

Zusäzlich ist einstellbar, ob der Dip-Schalter
bei Klick auf die '>' Schaltfläche seinen Wert
an den MC schicken soll.

Dip-Schalter 0 = low-bit
Dip-Schalter 7 = high-bit

Gemessene Latenz-Zeiten MC > PC > MC ca. 2-4 ms.

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

Hier eine Ansicht erstellt mit dem integrierten Background-Designer.
Wenn genügend Leute den interssant finden, werde ich den bald nach 
Überarbeitung freischalten. Das Grundgerüst für das Zeichentool ist 
soweit fertig wie ihr oben seht.
Erwartet bitte kein High-Tech Zeichentool. Aber ich denke für einfache 
Backgrounds reicht es. Alle Zeichnungs-Objekte haben jede Menge 
Properties zum einstellen, wie z.B. optionaler Text usw.

[chris_ (Gast)]

>Hab auch noch überlegt, welche Funktionalität man noch gebrauchen
>könnte. Aber irgendwie konnte ich schon alles mit den vorhandenen
>Mitteln abbilden.

Ein Textausgabemodul fehlt vielleicht noch. Der Mikrocontroller könnte 
ja Texte in verschiedene Fenster schreiben wollen. Also so was wie 
mehrere Terminal Fenster. Man könnte so was auf jeden Fall für 
Debug-Messages gebrauchen.

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

chris_ schrieb:
> Ein Textausgabemodul fehlt vielleicht noch. Der Mikrocontroller könnte
> ja Texte in verschiedene Fenster schreiben wollen. Also so was wie
> mehrere Terminal Fenster. Man könnte so was auf jeden Fall für
> Debug-Messages gebrauchen.

Kommt in der nächsten Version.
Eignet sich auch um Messwerte zu protokollieren usw.

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

Anbei neue Version SerialComInstruments V0.33

Change Log v0.33
----------------
AktivLabel TextBox Instrument #38 zugefügt.
Das Instrument AktivLabel TextBox zeigt Text an,
der vom Mikrocontroller gesendet wird.
Der Text/Textzeile sollte mit CRLF abgeschlossen werden.

Protokoll:   #nMm<
wobei        n = Instrumenten-Nummer (38)
             m = Text

Einstellungen sind nur an der Textbox selber möglich:

Lines     gibt die max. angezeigte Zeilenanzahl an.

C         löscht den Textbox-Inhalt

U / D     gibt die Einfügerichtung des Textes an.
          U  = aktueller Wert immer oben
          D  = aktueller Wert immer unten


Panel mit den 8-Led's überarbeitet.
Hat jetzt auch das neue Design mit Griff
rechts unten zum besseren Doppelklicken.

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

Ich mache gerade so einige Netzwerk Tests mit den entsprechenden Delphi 
Components.
Ergenis: Die Netzwerkeinbindung von SerialComInstruments dürfte relativ 
problemlos sein. Ich bräuchte nur von den seriellen Components auf die 
Netzwerk-Components umschalten, ohne weitere grosse Änderungen. Damit 
stände einer Fernübertragung nichts im Wege.

So liessen sich auch Messwerte von diversen Messorten (Clients) auf 
einer Darstellung vereinigen.

[biker10 (Gast)]

Hallo Albert,

zwei Bugs sind mir noch aufgefallen.

Instrument #65, Einzelne LED:
  Die Änderung der Farben wird nicht abgespeichert.
  Die Änderung des "Name" wird nicht abgespeichert.

Instrument #38, TextBox:
  Einfügerichtung des Textes,   D  = aktueller Wert immer unten,
Texte werden nach Erreichen der "Lines"-Anzahl nicht nach oben geschoben 
bzw. auch nicht mehr upgedatet.


Hast du vorgesehen die Einstellungen der Instrumente mit
  "Load Project" und
  "Save Project as"
zu aktivieren?

Gruß Dieter

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

biker10 schrieb:
> zwei Bugs sind mir noch aufgefallen.

Werden in der nächsten Version korrigiert.

Ausserdem wird zur nächsten Version der fummelige Doppelklick zum 
Verschieben und Grössenändern der Instrumente entfallen und durch ein 
neues komfortables Editierhandling ersetzt. Das jetzige Handling hat 
mich selbst genervt :)
Die Instrumente zeigen dann beim Bewegen Ausrichtlinien zu anderen 
Instrumenten oder können wahlweise am Hintergrundraster einrasten.

[Martin S. (panik)]

Super geiles Projekt. Mir fallen schon etliche Anwendungen ein.
Genau sowas habe ich mir schon immer gewünscht.

Danke Danke Danke und alle Daumen hoch :-)

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

Anbei neue Version SerialComInstruments V0.4a
(bitte nur diese Version benutzen)


Change Log v0.4a
----------------
Diverse Bugs bei Led- und Textbox-Instrumenten behoben.


Neuer Modus zum Bewegen und Grössenänderung von Instrumenten
ersetzt den bisherigen Doppel-Klick:

Die Instrumente und Ihre Inhalte werden nun mit
Identifikationslinien umrahmt.
Einige Instrumente bestehen aus mehreren Teilen (Komposit), welche
auch gerahmt werden. Wichtig für diese Version der Software sind
jedoch ausschliesslich die äusseren Rahmen der Instrumente.

Klicken Sie am Besten im untersten rechten Bereich des Instrumentes
um dieses zu aktivieren.
Das Instrument zeigt nun eine pinke Umrandung.
Nun können sie es verschieben oder in der Grösse ändern.
Die Instrumente rasten am gewählten Raster ein.

Sollten Sie versehentlich innere Bereiche eines Instrumentes
verschoben haben, schliessen Sie das Programm nach erfolgter Editierung 
und öffnen Sie es wieder. Die inneren Bereiche befinden sich jetzt
wieder am ursprünlichen Platz.

P.S.
Um die Instrumete unabhängig vom Raster zu bewegen/ändern können auf der 
PC-Tastatur die Pfeiltasten in Verbindung mit Shift und Crtl(strg) 
Tasten benutzt werden.

[biker10 (Gast)]

Hallo Albert,

die Instrumente lassen sich jetzt wirklich gut positionieren/ausrichten,
fühlt sich viel besser an!!

Folgendes ist mir noch aufgefallen.

Instrument #65, Einzelne LED:
wird bei "LED 0" unter "Name" ein Text eingetragen, so erscheint dieser 
Text auch unter der "LED  5".

Instrument #75, Dip-Schalter  und  Instrument #38, TextBox:
sind beide aktiviert (Haken) und werden angezeigt,
nach Beenden des Programm und erneutem Aufruf werden die beiden 
Instrumente immer noch angezeigt aber die Haken sind gelöscht.
Wird jetzt der Haken am Instrument #75 angeklickt wird das Instrument 
#38 anschließend unter Show nicht mehr angezeigt.

Da ist noch eine Wechselwirkung zwischen diesen beiden Instrumenten 
vorhanden.

Gruß Dieter

[gatsby (Gast)]

Hallo,

Diese Bugs sind mir noch aufgefallen.

Instrument #65, Einzelne LED:
  Die LED lassen sich mit z.B. #65M0000, #65M0001 ... nicht ausschalten
  Die LED 65-0 ist im Rahmen verschoben (siehe Screen04.png)

Instrument #38 zeigt keinen Text mehr an. In V0.33 ging das (siehe 
Screen033.png) noch.

Hier ein Instrumententableau, das zumindest ein von allen bisher zur 
Verfügung stehenden Instrumente enthält. Wer sich das Tableau nicht 
selbst erstellen möchte, kann sich die Datei SerialComInstruments.ini 
einfach in das Verzeichnis c:\Users\Anwender\AppData\Local kopieren. Die 
Datei  SerialComInstruments.ini ist mit der Version V0.4 erstellt.

Und schliesslich noch ein kleines Programm für den Arduino Duemilanove, 
das alle Instrumente des Tableau bedient.

Viel Spass
gatsby

[gatsby (Gast)]

Hallo nochmal,

hier die oben erwähnte *.ini Datei als Text Datei

Viele Grüße
gatsby

[Renixor (Gast)]

Also der neue Editier Mode ist ja mal Klasse.
Viel besser als das rumgeschiebe und auch genauer.
Es ist auch Interessant, dass man innerhalb der Instrumente die Texte 
etc. ausrichten kann.

Werde gleich mal weiter Testen.

MFG Renixor

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

gatsby schrieb:
> > Diese Bugs sind mir noch aufgefallen.
> Instrument #65, Einzelne LED:
>   Die LED lassen sich mit z.B. #65M0000, #65M0001 ... nicht ausschalten

Geht bei mir ohne Probleme. Bitte noch mal überprüfen.
Im übrigen ist mir das auch schon passiert, da hatte ich das "<" Zeichen 
am Ende des Kommandos vergessen.
Aha, in Deinem beigefügten Arduino-Programm scheint ein Fehler zu sein:
              SendString(65,3001);     // Instrument #65 Single LED AUS
              SendString(65,2002);     // Instrument #65 Single LED AUS
Bei "AUS" muss an 1. Stelle eine "0" stehen, Du hast da "3" bezw. "2".


>   Die LED 65-0 ist im Rahmen verschoben (siehe Screen04.png)

Dann hast Du sie im Edit Mode verschoben. Wie oben beschrieben einfach 
Programm aus- und wieder einschalten, dann ist alles am richtigen Platz.

Renixor schrieb:
> Es ist auch Interessant, dass man innerhalb der Instrumente die Texte
> etc. ausrichten kann.

Das Feature ist nicht freigegeben. Du kannst Sie zwar im Edit Mode 
verschieben, aber das ist nicht persistent. Siehe Antwort an Gatsby :)


Es freut mich, dass euch der neue Editier Modus gefällt.
Alle sonstigen Bugs werden in der nächsten Version behoben.

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

gatsby schrieb:
> Instrument #38 zeigt keinen Text mehr an. In V0.33 ging das (siehe
> Screen033.png) noch.

Text an #38 funktioniert bei mir auch problemlos.
Du nimmst in Deinem Arduino-Programm:
    SendText(38,inputString);  // Instrument #38 Text Anzeige
Ich will da jetzt nicht alles in Deinem programm nachsehen, habe von 
Arduino auch nicht viel Ahnung, aber ist in inputString auch das "<" 
Abschlusszeichen am Ende enthalten? Sonst passiert da nix.

[gatsby (Gast)]

Hallo Albert,

danke für deine schnelle Antwort.
Du hattest recht, daß das Ausschalten der Single LED funktioniert. Der 
Befehl z.B. #65M0000<, #65M0001< im Arduino funktionerte nicht richtig.
Beim Befehl

z.B.   SendString(65,0003);     // Instrument #65-3 Single LED AUS

werden die führenden Nullen unterdrückt.
Mit dem Befehl

z.B. SendText(65,"0003");     // Instrument #65-3 Single LED AUS

funktioniert es.

Auch die Positionierung der LED im Rahmen von Instrument #65 lässt sich 
durch den Neustart des Programms korrigieren.
Ebenso funktioniert die Textausgabe in Instrument #38.
Ich hatte nur das Häkchen bei ".. Klick auf Schaltfläche > senden" 
vergessen.
Hier nun noch einmal das korrigierte und uneingeschränkt laufende 
Programm.

Alles wird gut
gatsby

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

Anbei neue Version SerialComInstruments V0.41a

Bitte auch hier wieder nur die a-Version benutzen !

Change Log v0.41a
-----------------

2 neue Intrumente Vertikal Slider (#82 und #83) als
Sollwertgeber zugefügt. Bedienung:
Mit der Mouse den Regler grob einstellen, während bei gedrückter
linker Mousetaste das Mouserad als Feineinstellung dient.
Der eingestellte Wert wird bei Loslassen der Mousetaste
über die Schnittstelle an den MC geschickt.
Protokoll:  #nMm<  wobei n = Instr.Nr. und m = der eingestellte Wert

5 Frames (Instr.-Nr. #24...#28) als grafische Umrandung von
Instrumentengruppen zugefügt. Die Hintergrundfarbe der Frames ist
frei wählbar. Im Menue "Optionen" kann eingestellt werden ob
die Frames mit runden Ecken oder rechteckig erscheinen.

Zusätzlicher Schaltfläche "TL"  (TL = Top Left) unter
"Instruments" bei den Buttons "Werte zuweisen".
Bei Betätigung werden dem Instrument die eingestellten Werte
zugewiesen und es wird bei der Aktivierung zur besseren
Auffindbarkeit in der linken oberen Ecke positioniert.
Ausgenommen sind die Einzel-Led's (#65) und
die Aktiv Label Textbox (#38), diese sind bei der ersten
Aktivierung am linken Rand positioniert.

Menu-System überarbeitet und Schnellzugriff-Buttons für
den Online- und Edit-Modus zugefügt.
Die zusätzliche Leiste ist unter "Show / Button-Leiste" abschaltbar.

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

Als nächstes wollte ich ein X-Y Scope-Instrument implementieren.
Zu gebrauchen z.B. für Bode Diagramm / Frequenzgang-Darstellung, 
Bauelemente Kennlinien-Darstellung usw. Die Achsen wahlweise linear oder 
logarithmisch.
Update-Geschwindigkei so schnell es die Schnittstelle zulässt (wären 
beim jetzigen Protokoll und 115200 Baud so max. 250 Datenpaare/s). 
Voraussetzung es wird währenddessen sonst nichts übertragen :)

Oder habt ihr prioritätsmässig andere Wünsche?

[gatsby (Gast)]

Hallo Albert,

ich würde mir eher die einfachen Dinge wünschen
- 270Grad Instrumente (ev. mit Schleppzeiger und Schleppzeiger bleibt 
für 2sec auf maximalwert)
- horizontal Instrumente
- speichern und laden von Projekten

Den X-Y Schreiber würde ich eher hinten einreihen, als Bonbon sozusagen.

Ist natürlich nur ein Vorschlag
gatsby

[biker10 (Gast)]

Hallo Albert,

die neuen Instrumente Vertikal Slider (#82 und #83) lassen sich gut 
bedienen.
Vielleicht besteht die Möglichkeit die 4 Slider als Schieberegler oder 
als Rundinstrument individuell auszuwählen.


Zwischen den Rundinstrumenten und den Schiebereglern bestehen noch 
Unterschiede.
Instrumment #80:
Anzeige (und serielle Übertragung) max 1 Dezimalstelle möglich.

Instrumment #82:
Anzeige (und serielle Übertragung) max 2 Dezimalstellen möglich, siehe 
1.PNG.
"Anzeige Einheit" wird hier als "Anzeige Format" im Display des 
Instrument benutzt,
 als Anzeige Einheit wird immer "%" angezeigt, siehe 1.PNG + 2.PNG.


Vorschlag neues Instrument:
4 numerische Eingabefelder, min 3 Dezimalstellen (im Nachkommabereich 
können die Werte feinfühliger eingegeben werden als mit den Slidern),
  z.B für PID Regler: SollWert, P-Wert, I-Wert und D-Wert
Die Werte können dann wie mit Instrument #75 ">" an dem MC übertragen 
werden.

Ich hoffe, das ich es verständlich beschrieben habe.

Dieter

[gatsby (Gast)]

Hallo Albert,

wie wäre es, das oben gezeigte Eingabe Instrument zu haben?
Wie mit einem Handy könnte man Ziffern, Buchstaben und Sonderzeichen 
eingeben.

Viele Grüße
gatsby

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

gatsby schrieb:
 - 270Grad Instrumente (ev. mit Schleppzeiger und Schleppzeiger bleibt
> für 2sec auf maximalwert)
> - horizontal Instrumente

Kommt in den nächsten 14 Tagen

biker10 schrieb:
> Vorschlag neues Instrument:
> 4 numerische Eingabefelder, min 3 Dezimalstellen (im Nachkommabereich
> können die Werte feinfühliger eingegeben werden als mit den Slidern),
>   z.B für PID Regler: SollWert, P-Wert, I-Wert und D-Wert
> Die Werte können dann wie mit Instrument #75 ">" an dem MC übertragen
> werden.

Wie wär es mit so einer PID-Console, nur als Beispiel?
Bei Klick auf Edit-Felder öffnet sich optional ein 
Eingabe-Rechner-Display.
Wahrscheinlich reicht dabei auch nur das Ist-Wert Display. Der Soll-Wert 
steht ja eh in der Eingabebox.

Ansonsten werden die gefundenen Bugs mit der nächsten Version 
korrigiert.

Übrigens ist das X-Y Instrument bereits zu 90% fertig. Das kommt dann in 
der nächsten Version mit der PID-Console :)
Ich habe damit mal eine Frequenzgang-Analyse eines Schwingkreises 
gemacht:
Mein Rigol 1022 Fkt-Generator auf Sweep (100 kHz bis 2 MHz). Die X-Achse 
auf obige Sweep-Werte skaliert und die Y-Werte über MC-ADC gemessen. Ob 
die Frequenz-Zuordnung 100% korrekt ist muss ich noch überprüfen.

[biker10 (Gast)]

Hallo Albert,

ich schwanke hin und her zwischen einer reinen "PID Console" und 
allgemeinen numerischen Eingabe Instrumenten.

Eigentlich sind ja bis auf die "numerischen Eingaben" alle Instrumente 
vorhanden um sich eine eigene PID Console zusammenzustellen.

Bin auf jeden Fall gespannt wie deine Lösung aussieht.

Dieter

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

biker10 schrieb:
> ich schwanke hin und her zwischen einer reinen "PID Console" und
> allgemeinen numerischen Eingabe Instrumenten.
> Eigentlich sind ja bis auf die "numerischen Eingaben" alle Instrumente
> vorhanden um sich eine eigene PID Console zusammenzustellen.

Dann ist es wohl sinnvoll zusätzlich zur PID-Console noch eine 
allgemeine Num/Text-Eingabe Console zu erstellen.

Zum kommenden X-Y Graph habe ich die Funktionalität um einen Counter 
erweitert (siehe Bild). Hintergrund:
Um Frequenzgänge anzuzeigen lässt sich z.B. ein DDS mittels der vom 
Counter gesendeten Werte ansteuern. Der Count-Wert bestimmt die 
jeweilige Stelle auf der X-Achse. Mit dem ADC des MC misst man das 
Ergebnis am Messobjekt und schickt es zum Y-Kanal des X-Y Graph 
Instrumentes. Mit Delay verzögert man das Abschicken des nächsten 
Count-Wertes um die eingestellte Zeit. Damit berücksichtigt man z.B. die 
Einschwingzeit des Messobjektes. Die Delay-Zeit bestimmt sich ab dem 
Eintreffen des jeweils letzten Messwertes.
Mittels des Counters hat man dann immer eine 100% genaue 
Frequenz-Zuordnung. Gestartet wird der Counter direkt am X-Y Graph 
Instrument.

Meint ihr, das der Counter sinnvoll ist?
Denn eigentlich könnte das auch der MC selbst erledigen :)

[Messer (Gast)]

Mann,
das wird ja echt gut. Hochachtung für Dein Können!

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

gatsby schrieb:
> wie wäre es, das oben gezeigte Eingabe Instrument zu haben?
> Wie mit einem Handy könnte man Ziffern, Buchstaben und Sonderzeichen
> eingeben.

Wie wäre es denn damit als Eingabe-Console (Bild oben)?
Ersetzt vollständig die PC-Tastatur mit allen Funktionen, d.h. die 
PC-Tastatur könnte man ganz entfernen und nur mit der Mouse arbeiten.
Habe ich fertig in der Schublade :)

Die Frage für eine allgemeine Text/Num Eingabe ist allerdings: Wie soll 
die sinnig gekennzeichnet werden?
Denn irgendwie muss das ja zugeordnet werden. Vielleicht eine dedizierte 
Instrumenten-Nummer #n für die Console und der MC muss dann selbst 
entscheiden wie das Gesendete zu interpretieren ist? Dann kann jeder 
damit anstellen was ermöchte.

[biker10 (Gast)]

Hallo Albert,

eine Möglichkeit für eine Text/Num Eingabe wäre:

TextFeld--NumFeld
Sw        ##0.000
Kp        ##0.000
Ki        ##0.000
Kd        ##0.000
Xx        ##0.000

z.B. entspricht:
Sw = Sollwert
Kp = Proportionalbeiwert
Ki = Integrierbeiwert
Kd = Differenzierbeiwert
Xx = beliebige Bezeichnung durch den Anwender

Der zu sendende Wert an den MC würde sich dann zusammensetzen aus 
"TextFeld + NumFeld + CR(LF)".
Der MC kann aus dem Empfangenen Datenstrom mit der Kennung (Sw, Kp, Ki, 
Kd, Xx) eine entsprechende Zuordnung der Daten durchführen.

Wenn allerdings das "TextFeld" leer ist dann soll nur "NumFeld + CR(LF)" 
an den MC gesendet werden.

Gruß
Dieter

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

Test mit dem XY-Graph Instrument. Auf X-Kanal sin(x*3) und auf Y-Kanal 
sin(x) vom MC gesendet ergibt als Graph eine schöne Lissajous-Figur.


@ Biker10
Bis jetzt ist ja das Protokoll noch ziemlich konsistent geblieben und 
das möchte ich eigentlich beibehalten. Mit mehreren Werten zu einer 
Geräte-Nummer wie bei Deinem Vorschlag wäre das dahin.
Eher würde ich es deswegen so machen:

#n0Mm0<  wobei: n0 Kanal-Nr. z.B. 300 und m0 = Sollwert
#n1Mm1<  wobei: n1 Kanal-Nr. z.B. 301 und m1 = Kp
#n2Mm2<  wobei: n2 Kanal-Nr. z.B. 302 und m2 = Ki
#n3Mm3<  wobei: n3 Kanal-Nr. z.B. 303 und m3 = Kd

Dann könnte man event. einstellen ob man nach einmaliger kompletter 
Übertragung der Parameter anschliessend z.B. nur noch den Sollwert bei 
Änderung alleine überträgt.

[biker10 (Gast)]

Hallo Albert,

ich kann deine Bedenken bezüglich des Protokoll verstehen.
Es sollte jedoch bedacht werden das der Datenwert der zum MC gesendet
wird vom MC so einfach wie möglich zu dekodieren sein sollte.

Es wäre vielleicht vorteilhaft wenn jeder Parameter Wert einzeln
übertragen werden könnte (z.B in der Optimierungsphase um die
einzelnen Parameter noch richtig an die Gegebenheiten anzupassen).

Dieter

[Stiller (Gast)]

Lieber Albert M.
Ich finde das echt beeindruckend was du da in recht kurzer Zeit auf die 
Beine gebracht hast.
Viel mehr noch Imponiert mir zudem deine Einstellung  frei nach dem 
Motto:
„Es gibt nichts Gutes es sei den man tut es“
Ich habe auf dieser Internetseite schon so viele gute Ideen sterben 
sehen  - da kommt normalerweise auf eine positive Kritik zwanzig Ideen 
wie man das doch alles besser machen könnte oder wieso die Idee an sich 
schon völlig daneben sei.
Es ist echt cool das du dich durch so was nicht beeinflussen läst und 
einfach dein Ding durchziehst.
Das bisherige Ergebnis gibt dir eindeutig recht.

DANKE VON EINEM DER VIELEN STILLEN BEOBACHTERN !

[chris_ (Gast)]

Hallo Albert,

schönes Projekt. Vielleicht brauchst Du noch eine Idee für eine 
Erweiterung. Ich hatte in meiner Python-Implementierung noch eine 
Zusatzfunktion angedacht. Es ist sehr nützlich, wenn es auch Kanäle 
gibt, mit denen der MC eine oder mehrere Dateien schreiben kann. Die 
Textfenster sind sehr nützlich für Debug-Ausgaben, aber manchmal möchte 
man auch automatisiert Daten loggen. Dort könnte man sich vorstellen, 
dass man statt in das Textfenster in eine Datei schreibt. Oder Das man 
sogar automatisiert vom MC aus Dateien zum Schreiben öffnen kann und 
dann in die jeweilige Datei die Daten "piped".
So könnte z.B. der Controller jeden Tag eine neue Datei für den 
gemessenen Tagestemperaturverlauf schreiben.

Gruß,
chris_

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

Oben seht ihr eine Vorschau auf die Instrumente der kommenden neuen 
Version.

PID-Visualisierung
Zeigt Soll und Ist-Wert an, wobei, wie dargestellt die Ist-Achse mittels 
der Einstellungen gezoomt werden kann. Im unteren Bereich kann man 4 
Darstellungsseiten des Instrumentes umschalten auf Parameter-Eingabe für 
PID, linker/rechter-Graph und Show. Unter den Graphen wird die aktuelle 
Regeldifferenz angezeigt. Das Instrument lässt sich auf der PID-Seite 
auch ohne graphische Darstellung verwenden. Dabei werden nur die 
PID-Parameter zum MC geschickt, auch wahlweise einzeln, ohne dass der MC 
den Ist-Wert zurücksenden muss. Zur Klarstellung: Das Instrument führt 
keine PID-Berechnungen durch, sondern dient nur zur Parametrisierung für 
die Berechnungen auf dem MC.

XY-Graph
Freie Darstellung von Graphen in einem parametrisierbaren 
XY-Koordinatensystem. Bei Klick auf Start wird der Inhalt der Graphic 
gelöscht und auf Werte vom MC gewartet. Auch der MC kann durch Senden 
von "-999999" den Inhalt der Graphic löschen (habe ich gewählt um kein 
neues Protokoll einführen zu müssen). Es werden die Instrumenten-Nummern 
58 und 59 benutzt.

Virtuelles Keyboard
Mit dem Virtuellen Keyboard (Instr.-Nr. 99) lassen sich beliebige 
Informationen an den MC senden. Da könnt ihr euch z.B. auch ein eigenes 
Protokoll für ausdenken. Das Keyboard lässt sich auch auf die 
Eingabe-Zeile minimiert darstellen.
Protokoll  #99Mm   wobei m = Text oder euer Protokoll

[Kupferstecher (Gast)]

Das geht ja wies Katzen machen~~
Ein paar Tage hab ich den Thread nicht verfolgt und schon gibts soviele 
Neuheiten.


Gatsby hat es schon gesagt, er würde sich "eher die einfachen Dinge 
wünschen". Ich denke auch, dass es jetzt an der Zeit wäre, an den 
Feinschliff zu gehen, bevor immer neue Funktionalitäten einbaut werden. 
Feinschliff heißt für mich, die grundlegenden Instrumente nochmal 
anzuschauen, dass sie von der Bedienlogik zusammenpassen (z.B. 
AktivLabel lässt sich der Text und die Farbe auswählen, für die Konsole 
war das bei der V0.4 nicht möglich), die noch fehlenden Darstellungen 
Vertikal/Horizontalslider und die Horizontal/Vertikalanzeigen umzusetzen 
und evtl. Konzepte zur vereinfachten Bedienung einfließen zu lassen. So 
könnte für Tasten und Slider eine Shortcut-Liste verwendet werden.


Die numerische Eingabe halte ich auch für wichtig, wobei ich es schön 
fände, wenn man das Tastenfeld in den Einstellungen abwählen könnte (PC 
oder Tablet-Modus), da es doch viel Platz braucht und bei Benutzung mit 
Tastatur eher störend wäre. Wie schon weiter oben geschrieben, würde mir 
eine Sende-/Updateschaltfläche gefallen.
Bzgl. dem Thema numerische oder alphanumerische Eingabe: Die numerische 
könnte in den Sliderkanälen integriert werden (nur alternative 
Darstellung), während ein (einzelner) alphanummerische Kanal seperat 
belegt sein könnte.

Den PID-Regler halte ich fast für überladen, wobei er mich auch nicht 
stören würde:-)


Die einfache Bedienbarkeit, ein klares Protokoll und Funktionalität ohne 
riesen Grundkonfiguration, denke ich, steht doch im Mittelpunkt.

Viele Grüße
Kupferstecher

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

Na gut, die alphanumerische Tastatur fällt dann weg und wird ersetzt 
durch eine einfache Text Eingabezeile. Die PID-Console kommt dann ohne 
Zeiger-Grafiken nur als Texteingabe-Console für die PID-Paranmeter.

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

Ich bin mit den Tests des neuen XY-Graph Instrumentes jetzt langsam 
durch. Oben ein Beispiel was man damit so alles anstellen kann. Es zeigt 
eine Analyse eines LC-Gliedes, wobei der MC die Frequenz (X-Achse) 
jeweils vorgibt (z.B. an einen DDS), dann die resultierende Spannung am 
LC-Kreis misst. Die Beiden Werte werden an die X-Achse und Y-Achse des 
XY-Graph Instrumentes geschickt.
Weitere Anwendungs-Ideen:  Motor-Kennlinien, Bauelemente-Kennlinien usw.
Für X- und Y- Achse gibt es einen Skalierungsfaktor. Beide können 
unabhängig von einander linear oder logarithmisch dargestellt werden.
Der Messwertwert für die Y-Achse kann zusätzlich noch 1xLog, 10xLog oder 
20xLog dargestellt werden (z.B. für dB Anzeige).

[Franz (Gast)]

Hallo,
eine Frage, läuft das auch unter Linux oder nur über Windows?

[Dominic A. (neo123)]

Wirklich Lobenswert wie du voran kommst!

Was ich noch toll fände wäre ein Zeitstempel. Man könnte ja z.B die Unix 
Zeit übertragen und dann wird er von deinem Programm direkt umgerechnet 
und angezeigt.
Wäre aufjeden Fall sehr praktisch.

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

Franz schrieb:
> eine Frage, läuft das auch unter Linux oder nur über Windows?

Nur unter Windows. Unter Linux kannst Du es ja mal mit Wine versuchen. 
Würde mich auch interessieren ob es mit dieser Virtualisierung geht.

Dominic A. schrieb:
> Was ich noch toll fände wäre ein Zeitstempel. Man könnte ja z.B die Unix
> Zeit übertragen und dann wird er von deinem Programm direkt umgerechnet
> und angezeigt.

Oder auch umgekehrt. Die aktuelle PC Zeit zum MC übertragen. Mal 
schauen.

Im übrigen geht es nächste Woche mit neuen Versionen weiter.

[Minthol (Gast)]

Ich habe die com unter Wine- Linux Mint (MAYA) nicht zum laufen gebracht 
auch nicht mit - ln -s /dev/ttyUSB0 com1 im /dosdevices  Der Rest geht 
wohl bringt dann aber keinen Sinn. Bin aber auch kein Linux Freak. Würde 
mich interessieren welche lib/Komponente due für die serielle com 
verwendest.
gruß

[Hermann (Gast)]

Hi Albert,
ich habe Deinen Beitrg mit Interesse verfolgt, da ich schon einige 
Anwendungen im Kopf habe: vielen Dank an Dich - wirklich super! Leider 
komme ich noch nicht zum Testen, und ich verliere durch die Länge des 
Threads den Überblick, ob meine zukünftigen Anforderungen bereits 
erfüllt sind.
Ich habe 3 unterschiedliche Anwendungen, die ich mit Deinen virtuellen 
Instrumenten ausrüsten möchte:
1. Eine umfangreiche Prozesssteuerung mit vielen Pumpen, Motorventilen, 
Temperaturen und Betriebszuständen. Sie hat jetzt viele LEDs in einem 
Harware-Anlagenbild und ein getrenntes Display für Temperaturen usw..
Hier würde der jetzige Zustand Deiner Darstellung schon gut passen. 
Schön wären aber mehrere Prozessbilder mit unterschiedlichen Inhalten, 
die man wahlweise darstellen kann, z.B. für Service-Infos.
Wie macht man das? Laufen einfach mehrere Versionen Deines Programms und 
jedes stellt nur die Objekte dar, die es vorgesehen hat?
2. Eine Akku-Lade- und Entlade-Überwachung. Ich speichere jetzt die 
Daten im RAM und sende sie auf Anforderung an ein Terminal-Programm in 
einem Format, das ich direkt in Excel einlesen kann.
Auch hier passen Deine virtuellen Instrumente sehr gut. Hier 
interessiert mich zusätzlich eine Speicherung der Daten zur späteren 
Darstellung und zur Archivierung der Kennlinie.
3. Meine Heizungssteuerung. Ich habe eine Holzheizung mit 
Pufferspeicher, den ich nur alle paar Tage befeuere.
Hier ist nur in Ausnahmefällen eine Online-Darstellung interessant. Zur 
Abstimmung der Regelparameter und zur Analyse ungewollter Reaktionen 
würde eine Online-Darstellung mit der jetzigen Version gut passen. Aber 
wenn es schwieriger wird, muss ich die Daten auf unterschiedliche Weise 
analysieren, d.h. später die vorhandenen Daten mehrfach auswerten.
Zusätzlich ist eine Langzeitdarstellung interessant. Hier würde ich die 
Daten wieder im RAM speichern und bei Bedarf zum PC schicken, da der 
Rechner nicht tagelang laufen soll.

Mir ist in allen 3 Fällen eine Archivierung der Daten wichtig. Also eine 
Speicherung in einem Textfile, das ich später zur Darstellung 
wiederverwenden kann. Diese spätere Darstellung sollte dann in 
unterschiedlichen Instrumenten möglich sein, d.h. Analyse der Daten 
mehrfach auf unterschiedliche Art.
Beim Schreiben kommt mir die Idee, grundsätzlich mit einem 
Terminalprogramm aufzuzeichnen und dieses Textfile wieder mit dem 
Terminalprog. auszugeben. Das Textfile kann ich dann beliebig seichern 
und evtl. auch editieren. Aber wie bekomme ich es zum virt. Instrument 
gelinkt. Ich möchte ja nicht mit 2 PCs arbeiten.?
Die vorhandenen Instrumente sind - glaube ich - ausreichend. Es sind 
wohl etliche Zusammenstellungen, die ich immer wieder brauche. D.h. die 
Speicherungen der Darstellung ist sicherlich möglich?!

Wahrscheinlich hast Du schon eine Idee, oder es geht bereits. 
Hoffentlich sind meine Anforderungen nicht zu exotisch! Wenn ja, vergiss 
meine Anforderungen. Ich würde mir dann mit einem Visual-Basic-Programm 
helfen, mit dem ich die gespeicherten Daten irgend wie zum Virt. 
Instrument bringe.

Auf jeden Fall schon mal vielen Dank für Dein Super-Programm

Grüße Hermann

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

Minthol schrieb:
> Ich habe die com unter Wine- Linux Mint (MAYA) nicht zum laufen gebracht
> auch nicht mit - ln -s /dev/ttyUSB0 com1 im /dosdevices  Der Rest geht
> wohl bringt dann aber keinen Sinn. Bin aber auch kein Linux Freak.

Also ich habe von Linux überhaupt keine Ahnung. Pinzipiell müsste es 
aber unter Wine gehen. Vielleicht findet sich ja ein Linux Könner der es 
rausfindet.


Hermann schrieb:
> Hi Albert, ...

zu 1)
Eine Mehrfach-Intantisierung des Programms verhindere ich zur Zeit. Zwei 
oder mehrere Intanzen gehen aber. Ob die auf den gleichen seriellen Port 
arbeiten können bezweifel ich mal - allerdings habe ich da noch nichts 
probiert. Ich lasse in der nächsten Version mal mehrere Instanzen zu, 
dann könnt ihr das mal testen und mir berichten.

Eine unterschiedliche Instrumenten-Darstellung auf mehreren wählbaren 
Seiten ist für Später vorgesehen. Irgendwann werde ich ein komplettes 
Re-Design der Software machen. Ich habe ja inzwischen durch die Arbeit 
an der Software auch neue Erkentnisse erlangt, die ich einfliessen 
lassen möchte :)

zu 2)
Eine Speicherung und Laden der Daten ist momentan bei den Instrumenten 
funktionsfähig, die per se bereits eine Historie zeigen, also die 
Trend-Instrumente und dem X-Y Graph. Das grosse Trend-Instrument ist für 
bis zu 8 Kanäle ausgelegt. Allerdings habe ich diese, wie auch andere 
Funktionalitäten, zur Zeit aus bestimmten Gründen nicht freigegeben.

zu 3)
Siehe Punkt 2. Die Speicherung der Daten erfolgt als Textfile mit 
einstellbaren Delimiter, sowie zusätzlich mit einem internen Format. Das 
interne Format wird benutzt um die Daten wieder in das Trend-Instrument 
zurück zu lesen.

[Hermann (Gast)]

Das macht ja schon einen guten Eindruck. Unterschiedliche Darstellungen 
auf mehreren Seiten halte ich für besser als mehrere Instanzen.

Zur Speicherung der Daten habe ich mir eigentlich vorgestellt, dass die 
Daten alternativ aus einem Textfile anstatt aus der seriellen 
Schnittstelle gelesen werden. Dann ist die Archivierung gelöst und die 
Darstellung ist genauso wie online. Außer der Historie sind auch die 
anderen Daten (Parameter usw.) zur Vollständigkeit interessant. Man kann 
die Daten dann auch in Ruhe auf andere Art darstellen. Wie die Daten in 
das Textfile kommen, ist erst mal nicht so wichtig, da ein 
Terminalprogramm immer gehen wird. Ich würde den seriellen Datenstrom 
ohne Änderung direkt in das Textfile schreiben.
Das wird alles gut!
Vielen Dank
Hermann

[Chris (Gast)]

Linux:
Man sollote entsprechende symlinks in ~/.wine/dosdevices. setzen.

 cd ~/.wine/dosdevices
 ls -l
insgesamt 0
lrwxrwxrwx 1 user user 10 2008-04-13 14:18 c: -> ../drive_c
> sudo ln -s /dev/ttyS0 com1
[sudo] password for localhost:
> sudo ln -s /dev/ttyS1 com2
> ls -l
insgesamt 0
lrwxrwxrwx 1 user user 10 2008-04-13 14:18 c: -> ../drive_c
lrwxrwxrwx 1 root root 10 2009-04-19 18:46 com1 -> /dev/ttyS0
lrwxrwxrwx 1 root root 10 2009-04-19 18:46 com2 -> /dev/ttyS1


User sollte die Berechtigung zu den seriellen haben, z.B. ueber die 
Gruppe tty oder ansonsten einfach zum Testen das Programm als root 
starten wenn
man den Ersteller traut.
Im Beispiel waren dies echte Serielle, fuer usb sollte man die 
entsprechenden Links anpassen, sowie auch fuer das verwendete Linux 
system.

[Minthol (Gast)]

Vielen Dank Cris,
ich hatte wie vorher ja schon beschrieben com1 mit

ln -s /dev/ttyUSB0 com1

zugewiesen und auch die Userberechtigung für tty gegeben.
Entscheiden war dein letzter Satz

Chris schrieb:
> Im Beispiel waren dies echte Serielle, fuer usb sollte man die
> entsprechenden Links anpassen, sowie auch fuer das verwendete Linux
> system.

Mein Mint ist ja ein Ubuntu-Derivat und da heißt die Gruppe jetzt 
dialout.

Nach:

sudo usermod -aG dialout meinusername

und einem Neustart funktioniert es jetzt auch mit den USB zu seriell 
Adaptern.
Danke

[Franz (Gast)]

Ich wollte das Programm auf einen Respberry laufen lassen. Der läuft ja 
mit einer Linux-Distribution, das auf Debian basierende Raspbian. 
Raspberry, weil das Teil ja nur 3,5W verbraucht und bei mir dann im 
Dauerbetrieb laufen soll.

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

Anbei neue Version SerialComInstruments V0.42

Change Log
----------

Neues Instrument XY-Graph, Instrument-Nr. #58 und #59.
Wobei #58 = X-Kanal und #59 = Y-Kanal.
Die beiden Werte für den X- und Y-Kanal müssen direkt
hintereinander vom MC geschickt werden. Erst nach Eintreffen
des zweiten Wertes wird die Grafik upgedatet.
Mit Betätigen des Start-Buttons wird ein Start-Kommando an
dem MC geschickt.
Protokoll:  #58M1<
Danach wartet das XY-Graph Instrument auf Werte.
Die Auswertung des Start-Kommandos im MC ist optional, da
nach Betätigung des Start-Buttons immer alle ankommenden
Werte dargestellt werden.
Der Inhalt von XY-Graph wird durch Klick auf "CLR" gelöscht.
Auch vom MC aus kann der Inhalt von XY-Graph gelöscht werden:
Kommando:  #58M-9999999<
Die Achsendarstellung ist linear oder logarithmisch.
Die Skalierung der Y-Werte kann zusätzlich als log, 10xlog
oder 20xlog für dB-Anzeige erfolgen.


Neues Instrument Input Box, Instrument-Nr. #99.
Die Input Box öffnet sich mit Klick auf den
Button "InputBox" (Button-Leiste).
Die Input Box erscheint immer am unteren linken Rand
des Programmfensters und kann nicht verschoben werden.
Der eingegebene Text wird an den MC gesendet.
Protokoll:  #99Mm<   wobei m = Text

[BASCOM MWS (Gast)]

Was haltet ihr von einem FFT-Instrument?

Ich habe mal einen Test mit einer 2048 Punkte FFT gemacht.
Siehe Beispiel im Anhang.

Da SerialComInstrument bis zu 1000 Samples/s verkraftet könnte das Sinn 
machen.

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

SerialCommInstruments kann mehr als 50.000 Samples pro Sekunde (intern 
ohne serielle Schnittstelle) verarbeiten, natürlich rechnerabhängig. Die 
Frage ist ob an FFT Interesse vorhanden ist. Ich hatte weiter oben das 
Thema ja schon mal angesprochen, es ist aber ohne Resonanz geblieben.
Anscheinend ist die Nachfrage hier ja ziemlich abgeflaut, so dass ich 
zuerst mal vornehmlich Instrumente und Erweiterungen entwerfe, die 
meinen eigenen Bedürfnissen entsprechen. Dafür wäre FFT interessant, die 
schnelle Komponente dafür habe ich.

[Messer (Gast)]

Hallo,
wie sende ich mit Terminal Wagenrücklauf und Zeilenvorschub, ich meine 
<cr> und <lf>?

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

Messer schrieb:
> wie sende ich mit Terminal Wagenrücklauf und Zeilenvorschub, ich meine
> <cr> und <lf>?

In SerialComInstruments ist als Endezeichen < festgelegt. Benutze das 
und frage im MC danach ab.
Welchen Grund gibt es, dass Du unbedingt CRLF brauchst?
Solltest Du dafür ein gutes Argument haben, werde ich das in der 
nächsten Version beim Terminal als Option verfügbar machen. In die neue 
TextBox gehört das definitiv nicht.

[Messer (Gast)]

Zum Testen der Datenübertragung ist ein (wie hier integrierter) 
Terminalemulator sehr hilfreich. CR und/oder LF dem String anzuhängen 
würde Input# in Bascom zufrieden stellen.

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

Messer schrieb:
> Zum Testen der Datenübertragung ist ein (wie hier integrierter)
> Terminalemulator sehr hilfreich. CR und/oder LF dem String anzuhängen
> würde Input# in Bascom zufrieden stellen.

OK, ist als Option im Terminal für die nächste Version vorgesehen.


Anbei noch ein kleiner Test was mit dem neuen XY-Display ausser 
Kennlinien, Bode Diagramme, Spektrumanzeige usw. noch so geht:
Einsatz als schnelles Signal-Display mit bis zu 800 Samples/s bei 115200 
baud. Siehe Bild und Demo-Code in Luna oben (Die Überschrift FFT im Bild 
stimmt natürlich nicht :). Der Code zeigt auch für C oder Bascom wie 
einfach die Anzeige zu bedienen ist.

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

Anbei neue Version SerialComInstruments V0.42a

Change Log v0.42a
-----------------

Im Terminal optionales Zufügen von CR/LF
zum Senden eines Strings.
Terminal überarbeitet.

Diverse Bug Fixes.

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

Ich habe jetzt für das XY-Display Instrument die optionale FFT-Funktion 
fast fertig. Nur die Skalierung der X (Frequenz) Achse braucht noch ein 
Tuning und einige Überlegung.
Das Bild zeigt eine 2048 Punkte FFT, angewandt auf ein Sinussignal von 
40 Hz welches vom ADC eines ATMega 168 gesampelt wird. Die Darstellung 
ist wahlweise logarithmisch (wie im Bild) oder linear.
Die FFT ist einstellbar von 64 bis 4096 Punkte und für das FFT-Fenster 
gibt es diverse Standard-Einstellungen (Rectangular, Hamming, Blackman 
usw.).
Die Bezeichnung der Y-Achse ist im Bild nicht korrekt :)

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

Anbei neue Version SerialComInstruments V0.43

Change Log v0.43
----------------

FFT-Option für XY-Display Instrument implementiert.
Wenn im XY-Display nur die FFT-Ansicht gewünscht ist,
braucht aus Geschwindigkeitsgründen nur der Kanal #59
übertragen zu werden.
Protokoll:  #59Mm<    wobei m = Messwert

Damit die X-Achse (Frequenz) richtig skaliert wird,
muss die im MC verwendete Sample-Rate in Samples/s
eingegeben werden.

Die Anzahl der FFT-Punkte kann von 64 bis 4096 gewählt
werden. Moderne PC's benötigen für 4096 Punkte weniger
als 0,5 ms, so dass die Rechnerauslastung durch die FFT
gering bleibt.

Diverse FFT-Windows, wie Rectangle, Hamming, Blackman
usw. sind verfügbar.
Die Achsen können unabhängig voneinander linear oder
logarithmisch skaliert werden.



Die obigen Bilder wurden mit einem ATMega 168 mit einem 22,1184 MHz 
Baudratenquartz, einer Übertragungsrate von 460800 Baud und einer 
Sample-Rate von 2225 Samples/s erzeugt. Als Signalspeisung diente ein 
Rigol DG1022 Funktionsgenerator. Die Bilder zeigen eine Modulation des 
100Hz Signals mit 300 Hz.
Die Frequenzachse lässt sich spreizen um Details sehen zu können, wie 
ein weiteres Bild zeigt.
Bitte keine Kommentare zum Übertakten des ATMega, fürs Hobby ist das für 
mich OK :)
Oben findet ihr auch noch das zugehörige Luna Programm.

Sollte jemand bei der FFT mehr als 4096 Punkte benötigen, so ist das 
kein Problem. Bis zu 65536 Punkte wären machbar (natürlich muss man dann 
etwas warten bis die Werte eingelesen sind :)

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

Leider ist eine alte Hilfe Datei ins Projekt gerutscht.

Hier die Version mit passender Hilfe und alternativ die Hilfe allein 
(PDF-Datei, einfach in den Programmordner einfügen).

[Leonard S. (renixor)]

Hallo zusammen,

hab mich nun auch mal mit der neuen Version auseinander gesetzt.
Ich muß wirklich sagen, es ist toll, was aus diesem Projekt geworden 
ist...
Grafische GUI's lassen sich durch Neuerungen wie das Raster innerhalb 
von Minuten erzeugen.(für die im Bild hab ich 5min gebraucht)
Werde, wenn ich mal Zeit habe die ganzen Instrumente mit Werten füttern.
Was, meiner Meinung nach aber wirklich wichtig ist und leider die ganze 
Zeit aussenvor gelassen wurde ist die "Projekt Speichern | Projekt 
Laden" Funktion.

Ansonsten wirklich Klasse ;)

MFG Renixor

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

Anbei neue Version SerialComInstruments V0.44


Change Log v0.44
----------------

Neues Instrument PID-Console, Instrument-Nr. #30
Die PID-Console erlaubt die graph. Anzeige von
Ist-/Soll-Wert und der Regel-Differenz von einem
auf dem MC ausgeführen PID-Regler.
Die Regelparameter Kp, Ki, Kp und der Sollwert
können von der PID-Console, auch einzeln, zum MC
gesendet werden. Die Übertragung der Parameter
zum MC ist optional, die Anzeige ist davon
unabhängig.

Protokoll Ist-Wert vom MC zum PC:
  #30Mm<   wobei m = Ist-Wert

Protokoll PID-Parameter vom PC zum MC:
  für Kp:        #301Mm<   wobei m = Kp
  für Ki:        #302Mm<   wobei m = Ki
  für Kd:        #303Mm<   wobei m = Kd
  für Sollwert:  #304Mm<   wobei m = Sollwert

[Oscar K. (sieges)]

Mensch Albert, so früh schon oder noch am Wirken ?
Toll dein Programm !!
Zwischen den Jahren, werde ich mal mein EKG dranhängen.
Bestimmt träumst Du jetzt gerade von neuen Ideen ;-)
Nochmals Klasse deine Software.
cheers

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

Oscar K. schrieb:
> Mensch Albert, so früh schon oder noch am Wirken ?
> Toll dein Programm !!

Die Zeiten sind bei mir normal. Ich war schon immer ein Nachtmensch. 
Meine Liebste hat sich dran gewöhnt :) Und danke, dass Dir meine 
Software gefällt.

Leonard S. schrieb:
> Was, meiner Meinung nach aber wirklich wichtig ist und leider die ganze
> Zeit aussenvor gelassen wurde ist die "Projekt Speichern | Projekt
> Laden" Funktion.

Weiter oben hatte ich ja schon mal geschrieben, dass es dafür bestimmte 
Gründe gibt. Aber es geht Dir ja auch z.Z. das Projekt nicht verloren, 
da es automatisch beim Beenden in ein ini-File gespeichert und beim 
Start wieder geladen wird. Es ist halt noch nicht das Speichern/Laden 
unter einem bestimmten Namen freigegeben (betrifft auch die Trendanzeige 
und das XY-Display/FFT). Wenn es Dir jetzt ganz wichtig ist, benenne 
einfach jeweils das ini-File um. Ist eben was umständlich, aber hilft 
Dir vielleicht.
Das Gleiche gilt ausserdem für die Menue-Punkte 
Start/Stop/Play-Recording, mit dem sich der serielle Datenstream direkt 
von der Schnittstelle aufzeichnen und wieder abspielen lässt.
Ebenso betrifft das den integrierten Grafik-Background-Designer, den ich 
oben schon mal vorgestellt hatte (231 Klicks auf das Bild). Es hat sich 
aber kein Mensch dafür interessiert - so what.

[Uninteressierter (Gast)]

Ist Bedarf für ein Scope-Instrument mit bis zu 70.000 Samples/s ?

Ich habe mal einen Test gemacht und bekomme bei 921600 baud und 
Übertragung von einem Byte die oben genannte Samplerate vom ATMega168 
über die serielle Schnittstelle auf ein Test-Scope-Instrument. Es 
erfolgte dabei 1s Messung dann Anzeige (Alle werte anzuzeigen dauert 
nochmal ca. 0,5s). Die Auflösung von einem Byte entspricht dabei den 
gängigen Digital-Oszilloscopen. Die Werte werden dabei im ATMega nur von 
0 bis 255 hochgezählt, stammen also nicht vom ADC. Ob der ADC das packt 
müsste man noch testen. Wie bekannt takte ich meinen ATMega168-20 ja mit 
22,118400 MHz :). Welche ADC-Rate schafft ihr so bei Auflösung von 1 
Byte?

Wie auch immer, die X-Achse kann dabei nicht durch einen Timer im PC 
skaliert werden, da diese zu ungenau sind. D.h. es müsste die Samplerate 
vom MC dazu benutzt werden.

[Martin S. (sirnails)]

70kS/s ist doch mal ein ganz schöner Wert. Selbst wenn er nur die 28kS/s 
packen würde, würde das sogar für Audio reichen :)

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

Zuerst mal einen Gruss an den Uninteressierten Plagiator :)

@ Martin Schwaikert
Dafür müsste ja das bisherige Protokoll verlassen werden, weil nur das 
Daten-Byte/Word über die Schnittstelle gehen darf.
Ich schaue mir das über die Tage mal an.
Aber ich vermute, dass nur bei einem ATXMega die AD-Wandlung schnell 
genug ist. Mit normalen ATMega's wird das nicht gehen.

Doch zuerst wünsche ich euch schöne Weihnachtstage!

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

Martin Schwaikert schrieb:
> 70kS/s ist doch mal ein ganz schöner Wert. Selbst wenn er nur die 28kS/s
> packen würde, würde das sogar für Audio reichen :)

Ich habe jetzt mal im Datenblatt vom ATMega168/328 geschaut und 
festgestellt, dass dieser bei der Wandlung anstatt 10Bit auch 8Bit 
anbietet wenn man nur ADCH ausliest. Die max. Samplerate ist dabei 
76.9kSPS.
Damit könnte man dann die angesprochene Übertragung mit nur einem Byte 
machen und würde wohl auch sicher über 50kSampes/s bei der Übertragung 
an ein eventuelles neues FastScope Instrument kommen. Die Auflösung 
entspräche dann einem Digital-Oszilloscope, was sicherlich vielen 
reichen würde?

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

Meine heutigen Tests für schnelle Erfassung zeigen folgendes Bild:

Controller      Clock      baud      Auflösung   max. Samplerate/s
                                                 incl.Transfer > PC
--------------------------------------------------------------------
ATMega168-20    22118400   460800    8 bit       30000
ATMega328       16000000   115200    8 bit        6000

Das sieht doch schon mal gar nicht so schlecht aus.
Damit könnte man z.B. eine Oszi-Funktion mit Software-Trigger 
integrieren. Bei einer Darstellungsbreite von 1000 Pixeln (1 Sample = 1 
Pixel) und 8 bit ergäbe das eine Updaterate von max. 20 Frames/s bezw. 5 
Frames/s. Bei 500 Pixeln entsprechend die doppelte Framerate.

Interesse?

[Gerhard W. (gerhard_w)]

Albert M. schrieb:
> Interesse?

ja klar, aber wäre das nicht eher ein eigenständiges Programm?

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

Ich habe für die schnelle Erfassung einen neuen Thread aufgemacht:

Beitrag "Neues MiniProjekt: SerialComScope"

Hier wird das neue Mini-Projekt SerialComScope vorgestellt.

[Dieter P. (low_pow)]

>Nur unter Windows. Unter Linux kannst Du es ja mal mit Wine versuchen.
>Würde mich auch interessieren ob es mit dieser Virtualisierung geht.


SerialComInstruments Test-Version 0.44

Unter Linux / Wine, default ist XP gesetzt


Installation: Ja  ( pfad wie vorgegeben verwendet)
Programm startet nach Installation auch, wenn Häckchen
Links Unten auf nicht starten gesetzt wird (nicht so wichtig).

Einige Instrumente angeordnet.
Grosse Instrumente wie PID, XY Graph, Full Trend
sind wohl nur an einer Stelle mit der Maus greifbar.

Dig.Display #65 ist immer Häckchen gesetzt.

Problem mit Fehlermeldung:
Wenn XY Graph #59 gedrückt wird und dann Zuweisen+Show
gibt es Zugriffsverletzung bei ..
Drückt man nochmal Zuweisen+Show, dann könnte es sein
dass die Fehlermeldung hinter dem Programmfenster ist,
der Rahmen ist dann grau.
Für XY werden #58 und #59 verwendet, ein zweites
XY hätte wohl #60 #61.
#58 und #59 haben den Text Mini Trend unter dem Mauszeiger.

Wird das Fenster mit Normal View vergrössert, geht es mit nochmal
Normal View nicht auf die vorherige Grösse zurück.

Bei Wine Software, Anwendungen ist SerialComInstruments
als Name gelistet, Herausgeber und Version fehlen.

Deinstallation Ja

Einlesen / Ausgabe von Daten wegen fehlender Geräte nicht getestet.

Zu Linux oder Wine kann ich nicht viel weiter schreiben,
da gibt es viele Möglichkeiten.Es wäre wohl sinnvoll, ein kleines
Linux mit Wine und wenig anderem zu machen.

Unter "echtem" Windows habe ich nicht ausprobiert.
Es soll nichts als Kritik gesehen werden, das Programm ist
so wie es ist.

Anhang 3 Bilder

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

Dieter P. schrieb:
> Grosse Instrumente wie PID, XY Graph, Full Trend
> sind wohl nur an einer Stelle mit der Maus greifbar.

Ja, immer ganz unten, das ist auch in der Hilfe so beschrieben.

> Dig.Display #65 ist immer Häckchen gesetzt.

Richtig. Wenn Du da weiter klickst, weist Du auch warum :)

> Problem mit Fehlermeldung:
> Wenn XY Graph #59 gedrückt wird und dann Zuweisen+Show
> gibt es Zugriffsverletzung bei ..

Funktioniert bei mir, werde es aber überprüfen.

> #58 und #59 haben den Text Mini Trend unter dem Mauszeiger.

Wird korrigiert.

> Wird das Fenster mit Normal View vergrössert, geht es mit nochmal
> Normal View nicht auf die vorherige Grösse zurück.

Hatte ich auch nicht so vorgesehen, ist aber eine gute Idee.

> Bei Wine Software, Anwendungen ist SerialComInstruments
> als Name gelistet, Herausgeber und Version fehlen.

Hatte ich aus Faulheit noch nicht bei den Compiler-Einstellungen 
eingetragen. Werde ich jetzt aber nachholen.

Danke für den Test!

[biker10 (Gast)]

Hallo,

ich beschäftige mich gerade mit der PID-Console unter Bascom,
dabei würden folgende Punkte die Dekodierung im MC vereinfachen.

Ein CR an den PID-Parameter Sendestring anhängen,
- unabhängig ob 1 oder mehrere PID-Parameter gesendet werden,
- der Sendestring kann dann als "ein" String im MC bis CR eingelesen und
  mit dem Endezeichen <  in die entsprechenden Parameter unterteilt
  werden.

Statt eines Komma im Parameter einen Punkt senden, #302M9,6<   #302M9.6<
- erleichtert die Umwandlung vom Sende-String (obiges Beispiel 9.6) in
  eine Zahl durch Val().

Die PID-Parameter mit 2 Nachkommastellen, Eingeben/Senden.

Wie dekodierst du die PID-Parameter im MC?

Allgemein:
die Version im GUI hinter SerialComInstruments anzeigen!

Gruß Dieter

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

biker10 schrieb:
> Ein CR an den PID-Parameter Sendestring anhängen,
> - unabhängig ob 1 oder mehrere PID-Parameter gesendet werden,
> - der Sendestring kann dann als "ein" String im MC bis CR eingelesen und
>   mit dem Endezeichen <  in die entsprechenden Parameter unterteilt
>   werden.

Werde ich als Option in der nächsten Version implementieren.

> Statt eines Komma im Parameter einen Punkt senden, #302M9,6<   #302M9.6<
> - erleichtert die Umwandlung vom Sende-String (obiges Beispiel 9.6) in
>   eine Zahl durch Val().

Ich denke mal das Komma sollte hier generell durch einen Punkt ersetzt 
werden.

> Die PID-Parameter mit 2 Nachkommastellen, Eingeben/Senden.

Nachkommastellen dann wählbar.

Gruss
Ulrich A.

[Thomas F. (igel)]

Melde mich jetzt auch mal, da ich eine solche Software wie die hier von 
Albert schon seit längerem suche.
Deshalb habe ich jetzt mal die V0.44 installiert.
Ich habe jetzt mit 9600, 19200 und 38400 baud gesendet. Im Terminal sehe 
ich die Daten auch, jedoch bewegen sich die zugehörigen Instrumente 
nicht.

Habe ich etwas missverstanden und die Instrumente sind noch gar nicht 
"scharf" geschalten?

Thomas

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

Alle Instrumente sind "scharf" geschaltet :)

Welche Instrumente benutzt Du (event. mal ein Bild davon)?
Wie sehen die Messwert-Strings aus (event. mal Bild vom Terminal).
Vielleicht hast Du ja hinter den Messwerten das < Zeichen vergessen?
Sind die aktivierten Instrumente richtig skaliert?
Ansonsten sagt meine Glaskugel nicht mehr . . .

[Thomas F. (igel)]

Hier mal ein paar Bilder.
Inzwischen habe ich es auf zwei Rechnern getestet, einmal win XP und 
einmal Win7. Ich erhalte als Anzeige immer nur die Eins.

Thomas

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

Also, ich habe das jetzt gerade noch mal mit V0.44 getestet (Win7).
Alles läuft bei mir einwandfrei. Auch bei anderen Anwendern läuft es ja.

Anhand Deiner Bilder kann ich keinen Fehler entdecken, sieht alles 
normal aus. Danach müsste es funktionieren.

Vielleicht kommt ja über die Schnittstelle etwas, was da nicht 
hingehört. Im Terminal werden ja nur die darstellbaren Zeichen 
angezeigt.

[Martin S. (sirnails)]

Albert M. schrieb:
> Vielleicht kommt ja über die Schnittstelle etwas, was da nicht
> hingehört. Im Terminal werden ja nur die darstellbaren Zeichen
> angezeigt.

Da hätte ich gleich eine Idee für die nächste Version: Eine 
Fehlerzähler, wenn ungültige Daten geschickt werden :)

[Thomas F. (igel)]

Hallo Albert, Danke für deinen Tipp:

Offensichtlich kommt irgendein Steuerzeichen mit. Im Log-File meines 
Terminalprogramms sehe ich nach dem M ein (DC4).

Jetzt muss ich mal suchen wo das herkommt.

Thomas

[Thomas F. (igel)]

So, ich habe den Fehler bei mir gefunden: Es lag an einer falsch 
programmierten Unterdrückung von vorangestellten Nullen beim Ausgeben 
von Stringzahlen. Dort wurde ein Steuerzeichen eingeschoben.

Jetzt gehts und ich bin natürlich schon auf die nächste Version 
gespannt, da ich die Software gleich fürs nächste Bastelprojekt 
einsetzen will.

Thomas

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

Was haltet ihr von der Möglichkeit zur Definition und Animation eigener 
bewegter Objekte als neues Instrument. So eine Art Mini Processing 
(siehe auch: www.processing.org).

Das neue Instrument ist dann der Canvas für Objekte wie Linien, Kreise, 
Rechtecke oder auch komplexerer Gebilde, die vom Mikrocontroller erzeugt 
und bewegt werden können.
Würde sich bestimmt gut zur Visualisierung von vielen vom MC gesteuerten 
Vorgängen eignen.

Zur Zeit arbeite ich noch an der neuen Version 0.45 :)

[chris_ (Gast)]

Das näher sich langsam meinem Vorschlag von oben an:
>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.

[chris_ (Gast)]

Bzw. der direkten Möglichkeit, vom MC aus zu zeichnen:

cls : clear screen
plot x y : plot a point at x,y. Example: plot 100 200
color <color> : set the color for the next drawing. Example: color red
pos x y : set the position for the next drawing. Example: pos 100 150
line x y : plot a line from the last position to x,y. Example: line 200 
300
print <string> : print a string at the current position. Example: print 
hello world
w2file <string> : writes the string to a file ( usefull for data logging 
)

von http://hobby-roboter.de/forum/viewtopic.php?f=4&t=139

[biker10 (Gast)]

Hallo Albert,

was hast du denn alles für die Version 0.45 vorgesehen?

Es ist leider ein bisschen ruhig geworden um dein Programm!
Einige Leser haben sich ja noch entsprechende Programmänderungen/ 
Erweiterungen gewünscht.
Machst du weiter mit dem Projekt?
Ich, und vielleicht noch viele stille mitlesende, würde mich freuen
über dein nächstes Update.

Viele Grüße
biker10

[gatsby (Gast)]

Hallo Albert,

ich komme wieder auf meine Antwort vom 22.11.2013 zurück

>ich würde mir eher die einfachen Dinge wünschen
>- 270Grad Instrumente (ev. mit Schleppzeiger und Schleppzeiger bleibt
>  für 2sec auf maximalwert)
>- horizontal Instrumente
>- speichern und laden von Projekten

Ich finde dein Programm absolut Spitze und benutze es zur Darstellung 
von Soll-und Istwerten bei meiner Zündung.
Durch die immer neuen Funktionen gerät das Programm immer mehr zu einer 
"eierlegenden Wollmilchsau". Dadurch büsst es meiner Meinung nach die 
übersichtliche einfache Bedienung und die übersichtliche Datenstruktur 
der Datentelegramme ein. Meiner Meinung nach besteht die Gefahr, dass es 
zu
zu unübersichtlich und zu schwerfällig wird.

Ist natürlich nur ein Vorschlag und meine Meinung
gatsby

[Kryptoenergie (Gast)]

Hallo Albert,

leider ist es ja sehr ruhig geworden.

Bislang hab ich Dein Projekt nur als stiller Mitleser verfolgt und jede 
neue Version direkt ausprobiert.

Die Frage ist jedoch, wohin der Weg in Zukunft geht?

Wie so oft, bei sehr guten Ideen, schläft es irgendwann ein.

Bislang kenne ich nur Bezahlversionen wie LABVIEW oder ProfiLab.

Um aber mal schnelle gute Ergebnisse zu bekommen, kam mir Dein Programm 
gerade recht.

Arbeitest Du noch daran, oder ist es auf Eis gelegt?

Ich schließe mich da auch mal einigen Vorrednern an, und denke, bevor 
das Programm mit immer neuen "speziellen" Funktionen ausgestattet wird, 
solltest Du Dich vielleicht darauf konzentrieren, die vorhandenen zu 
perfektionieren.
Hierzu gehört z.B. das Speichern und Laden.
In meinen Augen ist dies eine der elementarsten Funktionen einer 
Software, die auf Dauer Bestand haben soll.
Derzeit kann man dies nur über Umwege realisieren.

Aber wie eingangs erwähnt, erfreue ich mich über eine neue Version.

Schönen Gruß

[gatsby (Gast)]

Hallo Albert,

als dein Project begann war ich skeptisch, ob es nicht in endlosen 
theortischen Diskussionen endet wie so viele Projekte hier.
Ich war dann erstaunt und positiv überrascht, dass doch sehr bald ein 
funktionierendes, überschaubares Programm entstand mit dem man arbeiten 
konnte.
Klar, es fehlte noch dies und das, aber zum Testen war alles vorhanden.
Dann wurden immer neue Funktionen dazugepackt, die bestehenden 
Möglichkeiten aber nicht bzw. nur mehr oder weniger weiter ausgebaut.
Ich hätte mir eine Vielzahl unterschiedlichster Anzeige Instrumente 
gewünscht, so wie diese, die in deinem allerersten Threat dargestellt 
wurden.
Das Ergebnis ist nun in den Ansätzen ein tolles Programm geworden, aber 
auf halbem Wege steckengeblieben und somit das Ziel nicht erreicht.

Schade drum.

Ich finde das Programm dennoch nützlich und toll und werde es weiterhin 
nutzen.

gatsby

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

An die Vorredner:

Was die Speichern- und Lade-Funktionalität für das Programm selbst und 
einige Instrumente angeht, habe ich schon mehrfach darauf hingewiesen, 
dass diese bereits funktionsfähig, aber nicht freigegeben ist. Der 
Hintergrund: Mehrfach bekam ich Anfragen von Firmen, die diese 
Funktionen benötigten. Meine Software ist aber ausdrücklich nicht für 
den gewerblichen Einsatz, darauf wird auch im Programm und der Doku 
hingewiesen. Daher bleiben diese Funktionen vorerst gesperrt.

Zur Zeit habe ich weder Lust noch Motivation für dieses Projekt. Das mag 
sich auch wieder ändern.
Da sich eh nur eine handvoll Leute interessiert, abzulesen an meinen 
diversen Fragen für Erweiterungen, auf die ich eigentlich nie wirklich 
mehr als eine Antwort bekam und der sonstigen spärlichen Resonanz, habe 
ich meine Prioritäten erst mal auf meine anderen Hobbies verlagert.