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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Mit welcher Version ist der Fehler aufgetreten?
Deiner Neusten.. gerade runtergeladen. Soll ich die .DLL mal anhängen ?
Wahrscheinlich habe ich testeshalber irgendwelche Fremdkomponenten probiert und die in den Deklarationen anschliessend nicht mehr entfernt. Ich schau das mal in Ruhe durch.
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...
@ 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 hat die Lib, aber nicht jeder. Rechter Mausclick geht. Muß mir vorher entgangen sein oder eine meiner Modifier-Tasten hing mal wieder.
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)
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
:
Bearbeitet durch User
Für alle die die .DLL nicht haben: im Anhang! MFG Renixor
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
Super, kanns aber nicht mehr testen heute... Hab morgen Schule :D MFG Renixor
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.
:
Bearbeitet durch User
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
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?
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
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.
1 | avr.device = atmega328p |
2 | avr.clock = 16000000 |
3 | avr.stack = 100 |
4 | uart.baud = 115200 |
5 | uart.Send.enable |
6 | |
7 | Dim i, f as single |
8 | |
9 | do ' Erzeugt Rampe (i) und Sinus (f) |
10 | for i =0 to 6.28 step 0.02 |
11 | f = fsin(i) + 5 |
12 | print SendString(1,i); ' Sendet an Instrument 1 den Wert i |
13 | print SendString(90,f); ' Sendet an Instrument 90 den Wert f |
14 | ' oder auch so: |
15 | print SendString(1,i);SendString(90,f); |
16 | waitms 100 |
17 | next |
18 | loop |
19 | |
20 | |
21 | |
22 | ' Funktion erzeugt den kompletten Protokoll-String |
23 | function SendString(InstrNr as byte, MWert as single) as string |
24 | return "#" + Str(InstrNr) + "M" + str(MWert) + "<" |
25 | endfunc |
:
Bearbeitet durch User
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:
1 | #include <stdlib.h> |
2 | void setInstrument(uint8_t InstrNr, int32_t MWert) |
3 | {
|
4 | unsigned char str_InstrNr[2]; //Einen 3 großen Buffer für die Nummer. |
5 | itoa(InstrNr, str_InstrNr, 10);//(MaxWert von 255 -> [0][1][2]) |
6 | |
7 | unsigned char str_MWert[10];//Einen 11 großen Buffer für den Wert. |
8 | itoa(MWert, str_MWert, 10); //(11, da int32_t 10 Stellen hat plus das |
9 | //Minus als Vorzeichen)
|
10 | |
11 | uart_sendstring("#"); //Die 'uart_sendstring()' Funktion muss |
12 | uart_sendstring(str_InstrNr); //selber deklariert werden oder es muss |
13 | uart_sendstring("M"); //eine eigene Funktion genutzen werden! |
14 | uart_sendstring(str_MWert); |
15 | uart_sendstring("<"); |
16 | }
|
Luna Funktion:
1 | function setInstrument(InstrNr as byte, MWert as single) as string |
2 | return "#" + Str(InstrNr) + "M" + str(MWert) + "<" |
3 | endfunc
|
Aufrufe gehen wie folgt: In C:
1 | int main(void) |
2 | {
|
3 | uint8_t Nr = 1; |
4 | uint8_t Wert = 12345; |
5 | while(1) |
6 | {
|
7 | setInstrument(Nr, Wert); |
8 | }
|
9 | }
|
In Luna:
1 | do ' Erzeugt Rampe (i) und Sinus (f) |
2 | for i =0 to 6.28 step 0.02 |
3 | f = fsin(i) + 5 |
4 | print SendString(1,i); ' Sendet an Instrument 1 den Wert i |
5 | print SendString(90,f); ' Sendet an Instrument 90 den Wert f |
6 | ' oder auch so: |
7 | print SendString(1,i);SendString(90,f); |
8 | waitms 100 |
9 | next
|
10 | loop
|
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments V0.26a Korrektur: - Es wurde versehentlich die Version mit meinem Debug-Panel veröffentlicht :)
:
Bearbeitet durch User
Vielen Dank Albert! Was du da baust ist wirklich Klasse. Ich werde das gut für meine neue Heizungssteuerung gebrauchen können. Gruß Einhart
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:
1 | 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
:
Bearbeitet durch User
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).
1 | ' Luna Beispiel : SerialComInstruments 8 LED Panel (#60) |
2 | '
|
3 | avr.device = atmega328p |
4 | avr.clock = 20000000 |
5 | avr.stack = 100 |
6 | uart.baud = 115200 |
7 | uart.Send.enable |
8 | |
9 | dim i as byte |
10 | |
11 | do
|
12 | for i =0 to 255 step 1 |
13 | SendString(1,i) |
14 | SendString(90,i) |
15 | SendString(60,i) |
16 | waitms 100 |
17 | next
|
18 | loop
|
19 | |
20 | |
21 | ' Funktion erzeugt den kompletten Protokoll-String |
22 | procedure SendString(InstrNr as byte, MWert as int32) |
23 | print "#";str(InstrNr);"M";str(MWert);"<" |
24 | endproc
|
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!
Albert M. schrieb: > Danke, dass Du so unermüdlich mitwirkst! Kein Ding ;) Schönen Abend noch, Renixor
entschuldige, mein Fehler, es wird ja dezimal ASCII übertragen, perfekt!
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 :)
:
Bearbeitet durch User
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
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
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.
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
@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.
:
Bearbeitet durch User
@ Dieter und Leonard Schau mir mal an was sich da machen lässt.
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
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
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.
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.
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).
:
Bearbeitet durch User
Darf ich anstelle 7 Segment ein 14 Segment oder ein configurierbares LCD vorschlagen.
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ß
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?
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
@ 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 :)
Vorschau auf die nächste Version. Voraussichtliche Veröffentlichung Anfang nächster Woche.
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
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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 ?
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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
>> 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.
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.
:
Bearbeitet durch User
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.
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 :)
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!
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.
:
Bearbeitet durch User
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
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.
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ß
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?
:
Bearbeitet durch User
Herrschaftszeiten hängst Du dich da rein :)
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
:
Bearbeitet durch User
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
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.
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.
Sehr geil, jetzt muss ich doch mal mit meinem Project anfangen ;-) Vielen Dank
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.
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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.
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.
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 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
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.
:
Bearbeitet durch User
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.
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
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...
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.
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?
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
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.
:
Bearbeitet durch User
@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
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
:
Bearbeitet durch User
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 :)
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ß
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
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.
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
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
@ 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 :)
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Pah! Ich bin beeindruckt. Ob optimal oder nicht ist da erstmal egal.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
>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.
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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.
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 :-)
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.
:
Bearbeitet durch User
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
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
Hallo nochmal, hier die oben erwähnte *.ini Datei als Text Datei Viele Grüße gatsby
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
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
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
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
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.
:
Bearbeitet durch User
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
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 :)
:
Bearbeitet durch User
Mann, das wird ja echt gut. Hochachtung für Dein Können!
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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
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 !
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_
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
:
Bearbeitet durch User
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
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.
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).
:
Bearbeitet durch User
Hallo, eine Frage, läuft das auch unter Linux oder nur über Windows?
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.
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.
:
Bearbeitet durch User
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ß
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
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.
:
Bearbeitet durch User
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
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.
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
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.
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
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Hallo, wie sende ich mit Terminal Wagenrücklauf und Zeilenvorschub, ich meine <cr> und <lf>?
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
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 :)
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
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
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.
:
Bearbeitet durch User
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.
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 :)
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!
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
Ich habe für die schnelle Erfassung einen neuen Thread aufgemacht: Beitrag "Neues MiniProjekt: SerialComScope" Hier wird das neue Mini-Projekt SerialComScope vorgestellt.
>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
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!
:
Bearbeitet durch User
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
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.
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
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 . . .
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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 :)
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
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
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 :)
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.
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
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
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
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ß
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.