Für die kommenden Wintertage suche ich noch eine Beschäftigung und möchte mir ein Tool zur Visualisierung von Microkontroller Daten anhand von virtuellen Instrumenten erstellen. Wie so etwas aussehen könnte habe ich mal anhand des beigefügten Bildes skizziert. Prinzip: Der MC sendet Daten in einem festgelgten Format an den PC (Windows) und meine Software stellt die dekodierten Daten an den zugewiesenen Instrumenten dar. Sowas gibt es zwar schon als Payware, ich kenne aber bisher keine Freeware die sowas macht. Aber da lass ich mich auch eines Besseren belehren. Wenn euch das Projekt interessiert, könnt ihr gerne eure Ideen beisteuern. Allerdings sollte es nicht ausufern und überschaubar bleiben. Siehe auch meine bisherigen Freeware Projekte hier im Forum: Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden" Beitrag "Daten von der seriellen Schnittstelle einfach darstellen"
Angehängte Dateien:
-
SerialComInstruments.jpg
200 KB
:
Verschoben durch Admin
Albert M. schrieb: > Sowas gibt es zwar schon als Payware, ich > kenne aber bisher keine Freeware die sowas macht. Hoffen wir mal, dass nicht morgen einer kommt, der deinen Job fuer lau macht.
Ohh, bevor ich zum Strom kam, war ich bei der Software - und da hat man sofort einen Haufen an Ideen. Du scheinst ja recht fit zu sein - deine bisherigen Sachen sehen sehr gut aus; funktional, wie auch die Optik! Wieviel Zeit planst Du denn ein? Ich hätte da schon eine "kleine" Idee, aber das macht natürlich auch nur Sinn, wenn man entsprechend viel Entwicklungsarbeit investieren möchte.
@Quack Das musst Du mir jetzt mal erklären. Welchen Job und was für lau? Falls Du es wirklich nicht verstehst: Das wird eine Freeware.
:
Bearbeitet durch User
... schöne Grafik (und aus Erfahrung weiß ich, dass das eine Heidenarbeit ist, so etwas so zu programmieren, dass es gut aussieht, weitgehend konfigurierbar ist und dann auch noch fehlerfrei arbeitet) Doch, sowas, denke ich, können wohl viele brauchen. Ein Programm, mit dem man sich ein Frontend auf einfache Art und Weise zusammenklicken kann.
Martin Schwaikert schrieb: > Wieviel Zeit planst Du denn ein? Ich hätte da schon eine "kleine" Idee, > aber das macht natürlich auch nur Sinn, wenn man entsprechend viel > Entwicklungsarbeit investieren möchte. Für mein Projekt SerialComGrapher habe ich alles zusammengerechnet ca. 14 volle Tage investiert. Für das neue Projekt wird wohl ungefähr die selbe Zeit oder etwas mehr rauskommen, natürlich über einige Monate verteilt.
Ich hab jetzt den anderes Projekt nicht im Detail studiert. Was ich mir wünschen würde, währen Elemente, denen ich mit einer eingebbaren Formel irgendwelche einfache Logik unterjubeln kann. zb. Ein LED-Anzeigeelement. Mit einer Formel kann ich ich zb bestimmen, dass die LED bei einem angebundenen Messwert von 287 einschalten soll und darunter ausschalten. Wobei ich in diesem Fall das eben nicht mit einem Schwellwert erledigt sehen möchte, sondern dass ich tatsächlich (ähnlich wie bei Excel) einen kleinen Formelparser dahinter liegen habe, mit dem ich auch Werte zuerst verknüpfen kann, die mglw. aus einer Datenbank kommen etc. Wenn du sowas sowieso schon im Angebot hast, dann will ich nichts gesagt haben.
:
Bearbeitet durch User
Karl Heinz Buchegger schrieb: > ... schöne Grafik > (und aus Erfahrung weiß ich, dass das eine Heidenarbeit ist, so etwas so > zu programmieren, dass es gut aussieht, weitgehend konfigurierbar ist > und dann auch noch fehlerfrei arbeitet) > > Doch, sowas, denke ich, können wohl viele brauchen. Ein Programm, mit > dem man sich ein Frontend auf einfache Art und Weise zusammenklicken > kann. So gross ist der Arbeitsaufwand auch nicht. Ich programmiere in Delphi und habe für die virtuellen Instrumente fertige Delphi-Componenten. Daher bleibt "nur" der Aufwand für die Dekodierung und Verteilung des Datenstromes und die Logic für die freie Platzierung der Instrumente.
Also das erste, was mir in diesem Zusammenhang gefallen würde, wären n Instrumente, die frei anzuordnen sind, sodass man etwas "Grafik" hineinbringen kann. Die Elemente könnten dann über Datenquellen angeschlossen werden, wobei eine Datenquelle ein Objekt ist, dass aus dem Com-Datenstrom generiert wird, und z.B. alle Pakete beinhaltet, die mit 0x25 anfangen. Also in etwa: Der Prozessor schickt 0x01 0x05 0x02 0x10, das ganze wird dann dekodiert und auf Instrument 1 (0x01) der Wert 5 angezeigt, auf 0x02 der Wert 16. Im Grunde ein stark abgespecktes Labview.
@ Martin Schwaikert Genau so habe ich mir das vorgestellt.
Albert M. schrieb: > Prinzip: Der MC sendet Daten in einem festgelgten Format... O je, Steinzeit-Ideen. Was passiert, wenn du was Neues brauchst? Oder wenn du neben der Visualisierung auch noch ne Kommunikation brauchst? Denk dir lieber ein flexibles Protokoll für die serielle Schnittstelle (oder VCP über USB) aus. So eines, wo man ohne Mühe die Synchronisation wiederfindet, falls der Nachwuchs mal über die Strippe gestolpert ist und was einigermaßen beliebig erweiterbar ist. Ein Beispiel von vielen: NMEA Albert M. schrieb: > Ich programmiere in Delphi HA! noch einer. Da sind wir ja schon zwei in diesem Forum... W.S.
Hi >> Ich programmiere in Delphi >HA! noch einer. Da sind wir ja schon zwei in diesem Forum... Drei. MfG Spess
W.S. schrieb: > Albert M. schrieb: >> Prinzip: Der MC sendet Daten in einem festgelgten Format... > > O je, Steinzeit-Ideen. Was passiert, wenn du was Neues brauchst? Oder > wenn du neben der Visualisierung auch noch ne Kommunikation brauchst? > > Denk dir lieber ein flexibles Protokoll für die serielle Schnittstelle > (oder VCP über USB) aus. So eines, wo man ohne Mühe die Synchronisation > wiederfindet, falls der Nachwuchs mal über die Strippe gestolpert ist > und was einigermaßen beliebig erweiterbar ist. Meine Aussage bezieht sich auf einen festgelegten Präfix als Kennzeichnung für die einzelnen Instrumente, meinetwegen A bis Z oder wie auch immer. Zuerst wird es mal nur Einbahnstrasse sein, MC > PC. Danach könnte man auch die andere Richtung PC < MC ins Auge fassen, was ja wahrscheinlich sinnig ist. Aufgeblähte Protokolle sind meines Erachtens nicht unbedingt notwendig. Es reicht ein Start- und Endezeichen für einen kompletten Zyklus aus. Damit wird auch die Synchronisation nach Übertragungsabruch problemlos wiedergefunden. Je einfacher umso besser, z.B. so (die Zahlen stehen für Messwerte): Start A24536 B45378 C83643 Ende oder Start Z93643 C74352 K73844 A73843 Ende Das bekommt im MC auch jeder Hobbybastler hin. Oder wo siehst Du darin ein Problem?
:
Bearbeitet durch User
es muss ein Master-Slave Protokol sein, der Pc ist der Master. Dann muss es ueber einen (logischen) Bus laufen, dh die Geraete muessen adressiert sein, sonst sind sie ja nicht unterscheidbar. Ich wuerd dynamische Adressierung vorziehen. Also muessen folgende Standard Commands implementiert sein. -Devicedescriptor , als binary und als text, damit man erkennt, was fuer ein Device -Userdescriptor, als binary und als text - damit kann man identische einheiten unterscheiden kann. - Adressierungsmechanismus, neue Geraete werden gefunden und adressiert vorzugsweise : - Das Benutzermenu als Baumstruktur wird vom Device geliefert. fuer schnelle Geschichten: - Gemeinsamen Referenzclock auf den Bus - gemeinsamen Trigger auf dem Bus Ich mach solches Zeug in Hardware und aufm Pc mit Delphi
hoppla ! schrieb: > es muss ein Master-Slave Protokol sein, der Pc ist der Master. Dann muss > es ueber einen (logischen) Bus laufen, dh die Geraete muessen adressiert > sein, sonst sind sie ja nicht unterscheidbar. Ich wuerd dynamische > Adressierung vorziehen. Also muessen folgende Standard Commands > implementiert sein. > -Devicedescriptor , als binary und als text, damit man erkennt, was fuer > ein Device > -Userdescriptor, als binary und als text - damit kann man identische > einheiten unterscheiden kann. > - Adressierungsmechanismus, neue Geraete werden gefunden und adressiert > vorzugsweise : > - Das Benutzermenu als Baumstruktur wird vom Device geliefert. > fuer schnelle Geschichten: > - Gemeinsamen Referenzclock auf den Bus > - gemeinsamen Trigger auf dem Bus Nö - das ist unnötig Aufwendig. Was meinst Du denn wie viele virtuelle Instrumente ich anbiete oder wieviele überhaupt sinnvoll sind? Mehr als 10 bis 15 sind das nicht, wenn überhaupt. Schau mal auf meinen Screenshot und denk Dir noch einige dazu. Als Bezeichner reichen da die Buchstaben A bis Z aus und alle Instrumente (Kanäle / Messdatenquellen) sind damit unterscheidbar. Deine Master Slave Problematik sehe ich auch nicht: Der MC schickt was oder der PC schickt was. Da braucht man über Master oder Slave nicht nachdenken und eine gemeinsame Referenzclock auf dem Bus wird auch nicht benötigt. Es fängt schon an wie bei meinem vorigen Projekt SerialComGrapher. Alles wird viel zu kompliziert gesehen und Bedenken getragen. Keep it simple! Das ist KEIN Projekt für die Industrie und hat auch nicht den Anspruch, sondern für Bastler die ihre Messdaten einfach visuell darstellen wollen ohne komplizierte Protokolle für dem Microkontroller programmieren zu müssen.
:
Bearbeitet durch User
Ich bin schon sehr gespannt auf dein Projekt. Habe auch schon öfters nach so einer Software gesucht. Werde das aufjedenfall ausprobieren wenn es fertig ist. Schön wäre es wenn die Instrummente frei Verschiebar wären. Zudem wäre auch die Komunikation von PC > MC praktisch. So wäre es ganz schön wenn man z.B. ein Paar Virtuelle Schalter hatt. Eine eingebaute Screenshot Funktion wäre auch ganz Praktisch. So das man einfach ein Bild machen kann von seinen Messwerten. Evt. auch die aufzeichnung von Werten wäre gut. Die man dan nacher z.B. nach Excel expotieren kann, für anwendungen wie nen Datenloger z.B. Ich hoffe ich denke jetzt nicht schonwieder viel zu Kompliziert.
Angehängte Dateien:
-
285197.jpg
43 KB
...als anregung fuer die GUI: im DMX feld benutze ich die opensource software Q Light Controller http://qlc.sourceforge.net/ (MacOS X, Linux, Win32) damit kann man z.b. lineare regler, buttons etc.. recht einfach "zusammenklicken". vielleicht sind diese routinen fuer das projekt hier auch brauchbar? gruss, -- randy
Ja, Bezeichner A-Z sind genuegend. Aber wie kommen die ins Geraet ? Erstens muessen die im Geraet gespeichert sein, und zweiten aussen am Geraet sichtbar. Dann moechte man vielleicht zwei, drei identische Geraete ansteuern. Die brauchen also verschiedene Bezeichner. Auch aussen sichtbar. Dann moechte man zu einem laufenden System noch eins hinzufuegen, ohne alles neu booten zu muessen. Oder eines auswechseln. Jedes Geraet hat seine eigene Schnittstelle am PC ? Kann man machen. Dann hat man einen Tisch voll gestaffelter USB Hubs und an jedem einen USB-to-Serial. Und wenn man dann ein Neues einsteckt, muessen alle neue im PC numeriert werden. Das macht der PC zwar von selbst, die laufende Messung ist aber kaputt. Besser waere alle Geraete an einem Bus laufen zu lassen, der Hot-plug kann, ohne Aufstand. Vielleicht verschwinden ein paar Messwerte, aber die Messung muss nicht abgebrochen werden. Sobald man einen Bus hat kann nicht jeder Teilnehmer etwas plappern. Und so weiter. Der Witz daran ist, es ist eher guenstiger als jedem seine eigene Schnittstelle am PC zu geben.
Nur zur allgemeinen Information: Eine LabVIEW Studentenversion gibts für ca. 20 Euro, alternativ beim Buch "Einführung in LabVIEW" dabei oder ganz einfach in der nächsten Uni-Bibliothek.
Markus R. schrieb: > Nur zur allgemeinen Information: Eine LabVIEW Studentenversion > gibts für > ca. 20 Euro, alternativ beim Buch "Einführung in LabVIEW" dabei oder > ganz einfach in der nächsten Uni-Bibliothek. Jap, das ist schon richtig. Aber nicht jeder hat Lust auf Labview und außerdem ist das COM-Getue mit Labview auch nicht unbedingt der größte Spaß. Vor allen Dingen, dass es riesen Probleme mit nicht geschlossenen COM-Verbindungen gibt.
Aaaahhhhh ... Labview. Extrem unpraktisch. Klotzig aufm Rechner und unheimlich invasiv. Labview laesst eine ganze Menge Prozesse aufm Rechner laufen, auch wenn das dazugehoerige Programm gar nicht laeuft. Und die sind schwer wieder loszuwerden. Labview ist also quasi als Virus anzusehen. Nebenbei hat man keine Kontrolle ueber den Ablauf des Geschehens.
Wen die $25 nicht stoeren, kann sich ja mal MakerPlot ansehen.
./. schrieb: > Wen die $25 nicht stoeren, kann sich ja mal MakerPlot ansehen. Wen die 50.000 Euro nicht stören, kann sich ja mal nen gebrauchten Porsche ansehen. Ist zwar auch ganz nett, tut hier aber ebensowenig zur Sache.
Ich würde heute keine Desktoplösung für diesen Zweck mehr neu anfangen zu Programmieren. Vielmehr würde ich die virtuellen Instrumente in html/javascript bauen und per Ajax die Daten von einem selbst geschriebenen Webserver holen der gleichzeitig auch die Kommunikation mit der Sensorhardware und das Logging abwickelt. Das kann man als portablen Code für alle gängigen Betriebssysteme schreiben. Da auf der Serverseite die GUI entfällt ist das wesentlich entspannter zu programmieren. Als Client dient dann nur noch ein beliebiger Webbrowser. Der Server kann z.B. auf einer Fritzbox o.ä. laufen, ne serielle Schnittstelle gibts da denke ich. Der große Vorteil von so einer Lösung ist, dass jedes Handy und Tablett als Frontend verwendet werden kann. Zu irgendwas müssen die Geräte von heute ja in 2 Jahren noch nützlich sein wenn man sich gerade das übernächste neue angeschaft hat. Wenn sich für so ein Konzept Mitstreiter finden würden, wäre ich dabei. Das ganze noch mit Plugins für unterschiedliche Sensorquellen (CAN, Ethernet, SPI...) und ein WebLabView wäre geboren. Als Programmiersprache käme aber nur sowas in Frage was sich auch gut von Windows uber Linux(x86 und Arm)sowie Osx portieren lässt. Da hier auch Zugriffe auf die Hardware eine Rolle spielen bleibt fast nur C/C++ übrig.
Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in vielerlei Hinsicht auch noch unsagbar langsam.
Hardwarezugriffe ? Nee. Braucht's nicht. Ein einzelnes Serialport genuegt. Dieses Serialport kann auch Ethernet, Bluetooth, WLan sein. Denn Javascript/Ajax, kann auch Serial/Hardwarezugriffe Zugriffe machen. Eine Frage der Library. Vergesst das mal. Immer mit diesem C/C++...
Hoppla ! schrieb: > Ja, Bezeichner A-Z sind genuegend. Aber wie kommen die ins Geraet ? > Erstens muessen die im Geraet gespeichert sein, und zweiten aussen am > Geraet sichtbar. Dann moechte man vielleicht zwei, drei identische > Geraete ansteuern. Die brauchen also verschiedene Bezeichner. Auch > aussen sichtbar. > Dann moechte man zu einem laufenden System noch eins hinzufuegen, ohne > alles neu booten zu muessen. Oder eines auswechseln. > > Jedes Geraet hat seine eigene Schnittstelle am PC ? Kann man machen. > Dann hat man einen Tisch voll gestaffelter USB Hubs und an jedem einen > USB-to-Serial. Und wenn man dann ein Neues einsteckt, muessen alle neue > im PC numeriert werden. Das macht der PC zwar von selbst, die laufende > Messung ist aber kaputt. Besser waere alle Geraete an einem Bus laufen > zu lassen, der Hot-plug kann, ohne Aufstand. Vielleicht verschwinden ein > paar Messwerte, aber die Messung muss nicht abgebrochen werden. Sobald > man einen Bus hat kann nicht jeder Teilnehmer etwas plappern. Und so > weiter. > Der Witz daran ist, es ist eher guenstiger als jedem seine eigene > Schnittstelle am PC zu geben. Ich glaube Du hast mein Konzepz noch immer nicht verstanden :) Es gibt da keine physischen Geräte in die Bezeichner hinein müssten. Noch gibt es gestaffelte USB-Hubs und mehrere Schnittstellen. Nochmal für Dich: Du hast EIN Mikrocontroller-Board mit analogen und digitalen Ein-/Ausgängen. Das schickt dem PC über EINEN USB/Seriell-Wandler Daten von den Ein-/Ausgängen über ein simples Protokoll. Ab und an schickt auch der PC mal (wenige) Daten zum MC-Board, z.B. Schalter in der GUI betätigt. Die "Instrumente" sind nichts anderes als die bildliche Darstellung in der GUI am PC, die den einzelnen analogen und gitalen I/O des MC zugeordnet werden.
obscurity schrieb: > Ich würde heute keine Desktoplösung für diesen Zweck mehr neu anfangen > zu Programmieren. Vielmehr würde ich die virtuellen Instrumente in > html/javascript bauen und per Ajax die Daten von einem selbst > geschriebenen Webserver holen der gleichzeitig auch die Kommunikation > mit der Sensorhardware und das Logging abwickelt. Das kann man als > portablen Code für alle gängigen Betriebssysteme schreiben. Da auf der > Serverseite die GUI entfällt ist das wesentlich entspannter zu > programmieren. Als Client dient dann nur noch ein beliebiger Webbrowser. > Der Server kann z.B. auf einer Fritzbox o.ä. laufen, ne serielle > Schnittstelle gibts da denke ich. > Der große Vorteil von so einer Lösung ist, dass jedes Handy und Tablett > als Frontend verwendet werden kann. Zu irgendwas müssen die Geräte von > heute ja in 2 Jahren noch nützlich sein wenn man sich gerade das > übernächste neue angeschaft hat. > Wenn sich für so ein Konzept Mitstreiter finden würden, wäre ich dabei. > Das ganze noch mit Plugins für unterschiedliche Sensorquellen (CAN, > Ethernet, SPI...) und ein WebLabView wäre geboren. Als > Programmiersprache käme aber nur sowas in Frage was sich auch gut von > Windows uber Linux(x86 und Arm)sowie Osx portieren lässt. Da hier auch > Zugriffe auf die Hardware eine Rolle spielen bleibt fast nur C/C++ > übrig. Deine Überlegungen in Ehren, da mag man mal so machen, aber ich glaube Du unterschätzt den Aufwand für Deine Lösung gewaltig. Du sparst nichts an Aufwand, indem Du das Ganze in Richtung Webserver verschiebst. Du verschiebst das GUI nur eine Instanz weiter. Das GUI ist der extreme Aufwand, da Du dann nicht auf fertige Tools für die virtuellen Instrumente zurückgreifen kannst. Hast Du eine Ahnung wieviel Mann-Monate es benötigt um nur einen Satz ansehnlicher virtueller Instrumente zu erstellen mit jeweils hunderten von Properties? So ein Projekt ist als One-Man Show nicht zu stemmen.
Cooles, Projekt! Schau mal, es gibt schon ein etabliertes Protokoll, Firmware und PC Software, darauf könntest Du aufbauen: http://firmata.org/wiki/Main_Page Eine tollere, konfigurierbare Oberfläche fänden bestimmt viele Leute gut, firmware für weitere Controllerfamilien auch.
Aha. Sorry. Das hab ich schon lange. Fuer ein neues Device klopp ich mir auf die schnelle jeweils ein GUI mit meinen Delphi Komponenten zusammen. Meine Komponenten: vom System : Button, Memo, Slider, Progress bar, .. eigene Komponenten: -XY Graph, mit reelen und komplexen Datentypen, fuer log, loglog und anderer Anzeige. -diverse online bearbeitungsfunktionalitaeten der Daten -Loggerfunktionalitaet -Prozessueberwachung, zB Abschalten und Restarten -.. Das bisherige ist nicht so schwierig. Ich hab alles an einem Bus. Mit einem Controllerservice, sodass mehrere unabhaengige GUIs auf mehrere Devices am Bus zugreifen koennen. Routing des Serialports ueber Sockets, sodass das GUI nicht aufm lokalen Rechner sein muss. Fuer Tablets wuerd ich gerne mal ein Bluetooth interface bauen. Also mit Bluetooth auf den seriellen Bus. Und fuer schnellere Devides fehlt mir noch der Synch & Trigger auf dem Bus.
Martin Schwaikert schrieb: > Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz > auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in > vielerlei Hinsicht auch noch unsagbar langsam. Falls du da meine Vorschlag meinst, kann ich nur sagen sagen: Schuß nicht gehört. Im Moment betreibe ich meine Heizungs- und Haussteuerung auf diese Art und Weise. Der komplette statisch gelinkte Server besteht aus einer einzigen Datei und ist ca. 180kb bzw. 780kb mit ssl gross. Der macht die komplette CAN-Kommunikation mit meinen Hausnetz, das Logging der Daten und den http/https-Server der die Daten als auch den html/js-Teil bereitstellt. Das passt auch ganz entspannt auf einen Rasperry. Ich bin hier aber weit davon entfernt eine Diskussion darüber los zu treten zu wollen. Jeder soll es so machen wie er will. Und die Klappe halten wenn man von was keine Ahnung hat. Hoppla ! schrieb: > Denn Javascript/Ajax, kann auch Serial/Hardwarezugriffe Im Browser? Scherzkeks! Und dieses unsägliche NodeJs ist das letzte mit dem ich sowas auf der Serverseite schreiben würde. Die ganzen C++ Hasser sind aber die die das geil finden.
Hoppla ! schrieb: > Aha. Sorry. Das hab ich schon lange. Fuer ein neues Device klopp ich mir > auf die schnelle jeweils ein GUI mit meinen Delphi Komponenten zusammen. > Meine Komponenten: > vom System : > Button, Memo, Slider, Progress bar, .. > eigene Komponenten: > -XY Graph, mit reelen und komplexen Datentypen, fuer log, loglog und > anderer Anzeige. > -diverse online bearbeitungsfunktionalitaeten der Daten > -Loggerfunktionalitaet > -Prozessueberwachung, zB Abschalten und Restarten > > Das bisherige ist nicht so schwierig. > Ich hab alles an einem Bus. Mit einem Controllerservice, sodass mehrere > unabhaengige GUIs auf mehrere Devices am Bus zugreifen koennen. Routing > des Serialports ueber Sockets, sodass das GUI nicht aufm lokalen Rechner > sein muss. > Fuer Tablets wuerd ich gerne mal ein Bluetooth interface bauen. Also mit > Bluetooth auf den seriellen Bus. Und fuer schnellere Devides fehlt mir > noch der Synch & Trigger auf dem Bus. Super, wenn Du das schon alles hast, stell es uns hier einfach zur Verfügung und ich brauche mir die Mühe das Rad neu zu erfinden nicht mehr machen. Bin mal gespannt auf Deine Software!
:
Bearbeitet durch User
Ich werfe mal folgenden Link in den Raum: http://www.mitov.com/products/instrumentlab#overview Vor Jahren gab es das mal kostenfrei für Delphi 7 und war ganz nett zu benutzen. Keine Ahnung wie es heute ist.
Albert M. schrieb: > Du verschiebst das GUI nur eine Instanz weiter. Das GUI ist > der extreme Aufwand, da Du dann nicht auf fertige Tools für die > virtuellen Instrumente zurückgreifen kannst. Hast Du eine Ahnung wieviel > Mann-Monate es benötigt um nur einen Satz ansehnlicher virtueller > Instrumente zu erstellen mit jeweils hunderten von Properties? > So ein Projekt ist als One-Man Show nicht zu stemmen. Das ist mir schon klar. Ich habe das für mich auch nur soweit gemacht wie ich es brauche. Nicht mehr und nicht weniger. Allerdings gibt es mit html5 einen Standard den es für GUIs auf den verschiedenen Systemen leider nicht gibt. Und auf den Systemen muss nichts installiert sein ausser einem überall vorhandenen Browser. Mit was macht man denn eine GUI die auf allen Rechnern, Handy und Tabletts läuft? Mir fällt da leider nichts ein was auch nur im Ansatz überall laufen würde. Delfi ist in dieser Beziehung das letzte.
obscurity schrieb: > Das ist mir schon klar. Ich habe das für mich auch nur soweit gemacht > wie ich es brauche. Nicht mehr und nicht weniger. Allerdings gibt es mit > html5 einen Standard den es für GUIs auf den verschiedenen Systemen > leider nicht gibt. Und auf den Systemen muss nichts installiert sein > ausser einem überall vorhandenen Browser. Mit was macht man denn eine > GUI die auf allen Rechnern, Handy und Tabletts läuft? Mir fällt da > leider nichts ein was auch nur im Ansatz überall laufen würde. Delfi ist > in dieser Beziehung das letzte. Sorry, aber das geht mir zu weit an meinem Thema vorbei. Ich erstelle eine Software für den PC unter Windows. Da interessieren mich Webbrowser-Lösungen für Tabletts und Handys eher wenig. Du kannst ja dafür einen eigenen Thread aufmachen. Und was in Delphi geht bist Du auch nicht auf dem neuesten Stand. Geh mal auf die Embarcadero Seite :)
HennesB schrieb: > Ich werfe mal folgenden Link in den Raum: > http://www.mitov.com/products/instrumentlab#overview > Vor Jahren gab es das mal kostenfrei für Delphi 7 und war ganz nett zu > benutzen. Keine Ahnung wie es heute ist. Danke für den Hinweis. Ja Mitov kenne ich schon lange. Ist super aber mir zu teuer. Die wollen 150 Euro, mit Source Code 510 Euro. Eine freie Version gibt es da wohl nicht mehr.
:
Bearbeitet durch User
Schau dir mal uCProbe an, macht inn Prinzip das was du willst, und gibt es auch für verschiedene Prozessoren. http://micrium.com/tools/ucprobe/trial/ Für Studi´s und Non-Profit ist es wohl kostenlos, ich habe da mal ein OS von denen gekauft, da war es auch dabei. Ist auf jedenfall eines der besten was ich da kenne, da ist das Protokoll und die GUI schon fertig. Super zum Debuggen von embedded SW. mfg Armin
obscurity schrieb: > Martin Schwaikert schrieb: >> Hey das klingt ja fast nach Windows 7. Verbraucht unendlich viel Platz >> auf der Festplatte, kann auch nicht mehr als Windows XP und ist dabei in >> vielerlei Hinsicht auch noch unsagbar langsam. > > Falls du da meine Vorschlag meinst, kann ich nur sagen sagen: Schuß > nicht gehört. Obach Bürschle, sonst ziag'ad Dir'd Ohrawatschla lang! > Im Moment betreibe ich meine Heizungs- und Haussteuerung > auf diese Art und Weise. Der komplette statisch gelinkte Server besteht > aus einer einzigen Datei und ist ca. 180kb bzw. 780kb mit ssl gross. Der > macht die komplette CAN-Kommunikation mit meinen Hausnetz, das Logging > der Daten und den http/https-Server der die Daten als auch den > html/js-Teil bereitstellt. Das passt auch ganz entspannt auf einen > Rasperry. Yea, muss ich jetzt auch noch eine Heizung mit dran hängen, um ein paar Werte über die serielle Schnittstelle zu übertragen? Was Du vorschlägst mag mit Sicherheit technisch interessant sein, und in Deiner Umgebung gut funktionieren, ist hier aber totale Übertötung!
Armin Klose schrieb: > Schau dir mal uCProbe an, macht inn Prinzip das was du willst, und gibt > es auch für verschiedene Prozessoren. > http://micrium.com/tools/ucprobe/trial/ > Für Studi´s und Non-Profit ist es wohl kostenlos, ich habe da mal ein OS > von denen gekauft, da war es auch dabei. Ist auf jedenfall eines der > besten was ich da kenne, da ist das Protokoll und die GUI schon fertig. > Super zum Debuggen von embedded SW. Da gibt es nur eine Trail, lauffähig 45 Tage und ansonsten verraten die alle Preise nur auf Anfrage, was vermuten lässt, dass die Software wohl im 4 stelligen Euro Bereich liegt. Ansonsten sieht es ja nicht schlecht aus.
:
Bearbeitet durch User
Martin Schwaikert schrieb: > Yea, muss ich jetzt auch noch eine Heizung mit dran hängen, um ein paar > Werte über die serielle Schnittstelle zu übertragen? Sag ich doch, du hast nichts verstanden. Es ging nicht darum um ein paar Werte über die serielle Schnittstelle zu übertragen. Es ging darum die zu Loggen und zu Visualisieren. Und mein Vorschlag war das in einen Serverteil und eine GUI die im Browser läuft zu teilen um damit universeller zu sein. Wenn beides auf der selben Maschine läuft ist es vergleichbar mit einer nativen Applikation. Man hat aber die Option den Server auf beliebiger Hardware laufen zu lassen und die verschiedenen anderen Geräte als Frontend zu verwenden. Bei mir läuft der Serverteil auf einem NAS der sowieso an ist und als Interface wird ein einfaches CAN-USB-Interface verwendet. Der Rasperry war nur als Möglichkeit genannt. Was deine sinnlosen Kommentare damit zu tun haben erschließt sich mir nicht.
Albert M. schrieb: > Für die kommenden Wintertage suche ich noch eine Beschäftigung und > möchte mir ein Tool zur Visualisierung von Microkontroller Daten anhand > von virtuellen Instrumenten erstellen. Wie so etwas aussehen könnte habe > ich mal anhand des beigefügten Bildes skizziert. > Prinzip: Der MC sendet Daten in einem festgelgten Format an den PC > (Windows) und meine Software stellt die dekodierten Daten an den > zugewiesenen Instrumenten dar. Sowas gibt es zwar schon als Payware, ich > kenne aber bisher keine Freeware die sowas macht. Aber da lass ich mich > auch eines Besseren belehren. > Wenn euch das Projekt interessiert, könnt ihr gerne eure Ideen > beisteuern. Allerdings sollte es nicht ausufern und überschaubar > bleiben. > > Siehe auch meine bisherigen Freeware Projekte hier im Forum: > Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden" > Beitrag "Daten von der seriellen Schnittstelle einfach darstellen" Hallo Albert, klingt nach einem spannenden Projekt! Wünsch dir viel Ausdauer und Erfolg bei deinem Vorhaben - kenne mich persönlich nicht mit der Materie aus, aber vielleicht hilft dir diese Infoseite (grad ergooglet) : http://serielleschnittstelle.com/
Ist ja echt putzig :)
Angehängte Dateien:
-
SerialComInstruments_01.jpg
380 KB -
SerialComInstruments_02.jpg
250 KB
Ich habe mal übers Wochenende was gebastelt. Was bereits funktioniert: - Erzeugen, Darstellen und Verschieben per Mouse von Instrumenten Die Instrumente können in der Grösse verändert und beliebig gemischt werden. Die Parameter können auch nachträglich editiert werden. Alle in den Check-Boxen markierten Instrumente werden angezeigt. - Zuordnung von Kanälen(Instrumenten): Alle möglichen Instrumente haben eine feste Kennung, wie z.B. #05 (siehe Bild 2). Vom Mikrocontroller werden die Werte als Strings dann im folgenden Format gesendet: '#KanalNr'Messwert, . . . . . ,'#KanalNr'Messwert'CRLF - Die Trend Anzeige kann bis zu 4 Kanäle darstellen - Mit Virtuellen Kanälen können Berechnungen durchführt werden und diese dann einem Instrument zugeordnet werden. - Es gibt Rückmelde Kanäle (Gruppe #80) die Informationen vom PC zum Mikrokontroller schicken können.
:
Bearbeitet durch User
Mir gefallen deine drei Projekte und vor allem deine Arbeitseinstellung betreffend Effektivität. Weiter so! Das scheint brauchbare Tools zu ergeben.
Ein paar möglicherweise interessante Links: http://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments http://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture http://sigrok.org/wiki/Main_Page Letztere könnte dir beim Interpreterscheiben helfen (sources zum nachschaun)... 73
Angehängte Dateien:
-
SerialComInstruments_03.jpg
480 KB -
SerialComInstruments_04.jpg
240 KB
@ Abdul > Mir gefallen deine drei Projekte und vor allem deine Arbeitseinstellung > betreffend Effektivität. Weiter so! Das scheint brauchbare Tools zu > ergeben. Danke ! @ Hans Wilhelm Danke für die Links Wilhelm. Mein "Protokoll" habe ich allerdings bewusst so simpel gehalten, das der "Interpreter" nur den jeweilig vom MC gesendeten String in die einzelnen Bestandteile aufdröseln muss, was sehr einfach ist. Die extrahierten Substrings (Instrument Nummer und Messwert) werden dann an die einzelnen Instrumente passend verteilt. Dafür ist nun wirklich keine hohe Programmierkunst notwendig. Das ganze Projekt ist eher eine reine Fleissarbeit. Ansonsten habe ich noch mal Prinzipbilder eingefügt was so alles an Darstellung möglich ist :)
:
Bearbeitet durch User
Hi, wirklich ein sehr coole Projekt, die UI Elemente sehen recht schick aus! Kleine Anmerkung, wenn ich darf, falls du das mal irgendwann etwas flexibler ausbauen möchtest... z.B. könnte man die Logik(Funktionalität) des Instruments von der UI lösen. Man könnte z.B. sowas wie interfaces oder templates für z.B. Kippschalter, Taster, Lineare Anzeigen, Lampen, Drehknöpfe usw. erstellen, diese mit dem Nötigsten an Logik ausstatten und dann dem Endanwender selbst überlassen wie er das Element visuell gestaltet, indem er seine eigene "Klasse" ableitet oder vorhandene vervollständigt oder überschreibt. Wie ein Baukastensystem aus dem man sich das Nötigste raussucht und damit das Instrument aufbaut, aber die Freiheit hat jedes Teil des Instruments individuell in Visualisierung und Funktionalität zu gestalten, wenn man mag. Dazu evtl. noch die Möglichkeit eine Art "Theme" z.B. als xml Datei oder ähnliches zu laden was Grundlegendes wie z.B. Hintergrundfarbe etc. generell festlegt. Das ganze "Werk" dann noch schön als .Net assembly und bis morgen und ich bin glücklich ;-) VG GrobiG
Hallo Albert, schöne Idee, ich habe schon deinen SerialComGrapher im Einsatz. Freu mich schon deine 1ste Version zu testen. Lg, Bernd
GrobiG schrieb: > Kleine Anmerkung, wenn ich darf, falls du das mal irgendwann etwas > flexibler ausbauen möchtest... z.B. könnte man die Logik(Funktionalität) > des Instruments von der UI lösen. Man könnte z.B. sowas wie interfaces > oder templates für z.B. Kippschalter, Taster, Lineare Anzeigen, Lampen, > Drehknöpfe usw. erstellen, diese mit dem Nötigsten an Logik ausstatten > und dann dem Endanwender selbst überlassen wie er das Element visuell > gestaltet, indem er seine eigene "Klasse" ableitet oder vorhandene > vervollständigt oder überschreibt. Der Aufwand hierfür entspricht in etwa fast dem Gesamtaufwand des vorgesehen Projektes. Das ist mir zu viel. Davon abgesehen mache ich viele Properties der Instrumente zugänglich, die das Aussehen verändern. Also warte mal ab was da kommt :) > Das ganze "Werk" dann noch schön als .Net assembly und bis morgen und > ich bin glücklich ;-) Was meinst Du warum ich in Delphi programmiere? Um das Endprodukt unabhängig von DLL's, Net Framework's und dem ganzen sonstigen Microsoft-Käse zu halten. Die fertige Distributable besteht einzig aus einer EXE-Datei. Und es werden keine Registry-Einträge benutzt, nur eine Ini-Datei wird geschrieben. Damit ist mein Programm von Hause aus auf allen Windows Versionen sofort lauffähig. Du kennst doch bestimmt inzwischen meine Devise: KEEP IT SIMPLE - Weil das Projekt in absehbarer Zeit fertig werden soll - Weil der Anwender es auch ohne Handbuch verstehen soll
:
Bearbeitet durch User
Das GUI Konzept ist soweit fertig und mit der ersten Instrumentengruppe "Vertikal Meter" funktionsfähig (siehe angehängtes Programm). Ihr könnt es ja mal testen :) Die Bedienung ist einfach: - Auf "Instrumente" klicken - Klick auf gewünschte Instrumentenbezeichnung z.B #01 - Rechts können nun die Instrument Eigenschaften eingegeben werden - Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen - Links die darzustellenden Instrumente in der Checkbox aktivieren - Die Einstellungen mit"Instrumente Status zuweisen" übernehmen - Auf "Show" klicken - Die Instrumente mit der Mouse an die gewünschte Stelle platzieren Für die Instrumente eignet sich als Standardgrösse Breite = 130 und Höhe = 400, als Skala Steps =5 und Skala Substeps = 2. Für Instrument Name und Einheit die gewünschten Bezeichnungen als Text eingeben. Die ini Datei wird zur Zeit in C:\Users\Anwender\AppData\Local geschrieben. Der Ordner und Dateiname wird aber später frei wählbar sein, da in der ini die kompletten Einstellungen des jeweils aktuellen Projektes gespeichert sind. Damit lässt sich also das individuelle Projekt dann speichern und wieder laden.
:
Bearbeitet durch User
Angehängte Dateien:
-
test.png
150 KB
>> "Vertikal Meter" funktionsfähig
Man kann ein Anzeigeinstrument erzeugen aber ich denke da verbirgt sich
noch keine weitere Funktionalität dahinter. Eine Schnittstelle kann ich
nicht zuweisen, ein Wert wird schon angezeigt wo auch immer der her
kommt. Screenshot anbei.
@ Bernd N Genau, habe ich auch nirgends behauptet: Albert M. schrieb: > Das GUI Konzept ist soweit fertig Und der angezeigte Wert hat überhaupt keine Bedeutung. Wie gesagt es geht hier zuerst mal NUR um das GUI Konzept der Instrumente. Das Andere kommt in den nächsten Tagen :) Hast Du keine Steps und Substeps zugewiesen?
:
Bearbeitet durch User
ok,
>> Hast Du keine Steps und Substeps zugewiesen?
Nein, funktioniert aber, gerade ausprobiert.
Ich dachte schon es wäre ein seltsamer Grafikfehler in den Komponenten. Als nächstes kommt die Schnittstelle dran, damit man das Ganze auf prinzipielle Funktionsfähigkeit testen kann. Und danach die anderen Instrumentarten.
Albert M. schrieb: > Meine Aussage bezieht sich auf einen festgelegten Präfix als > Kennzeichnung für die einzelnen Instrumente, meinetwegen A bis Z oder > wie auch immer. Mir kommt das schon ein bissel SEHR zu eng vor. Wirklich, ich meine es ernst: Denk lieber JETZT nochmal gründlich über ein gutes Protokoll nach, das sich auch dann noch kompatibel erweitern läßt, wenn bereits die ersten Anwendungen damit laufen. BTW: Für was für Update-Geschwindigkeiten hast du das Ganze denn so vorgesehen? Deine (wie mir scheint) doch eher textlastige Übertragung sieht eher nach "langsam" aus. Immerhin muß ja die Firmware im µC jeweils darauf abgestimmt sein. Weswegen ich das schreibe? Nun, ich hatte vor Jahren mich schwarz geärgert über die Software zum damaligen "Funkamateur-Netzwerktester", weil diese ausgesprochen unflexibel war (und immer noch ist). Ich hatte mir damals was Eigenes dazu ausgedacht und herausgekommen ist ein Protokoll, mit dem ich quasi gleichzeitig: - mehrkanalig mit einstellbarer Bitbreite wobbeln kann - Kommandos vom PC zum µC schicken kann (mit Echo zwecks Kontrolle oder wenn mal ein Terminalprogramm dran hängt) - Geräte-Kennwerte vom µC zum PC senden kann - eine IR-fernbedienung via Wobbler zum PC durchgeschleift wird, damit man auf dem Basteltisch nicht ne Tastatur rumfliegen haben muß Mittlerweile verwende ich dieses Protokoll auch woanders, es macht sich ganz gut. Auf der PC-Seite benutze ich im Delphi-Programm einen dedizierten Thread, der das gesamte I/O erledigt und dabei die verschiedenen Ströme (Org-Datenverkehr, Wobbeldatenverkehr, Fernbedienungsverkehr usw. auseinandernimmt, so daß er eigentliche Oberflächenkram sich damit nicht befassen muß. Wahrscheinlich paßt mein Entwurf zu deinem Vorhaben nur mit einigem "Umschliff", aber eines weiß ich: Wenn man sowas nicht vorher sich gut überlegt und genau niederschreibt, dann kommt man später ganz gewaltig ins Stolpern. Ach ja, nochwas: Für so einen Datenverkehr auf nem seriellen Kanal braucht es nicht zu sein, daß alles im Klartext vorliegt. Damit vergeigt man sich bloß ne Menge Möglichkeiten. W.S.
W.S. schrieb: > BTW: Für was für Update-Geschwindigkeiten hast du das Ganze denn so > vorgesehen? Deine (wie mir scheint) doch eher textlastige Übertragung > sieht eher nach "langsam" aus. Immerhin muß ja die Firmware im µC > jeweils darauf abgestimmt sein. Bei den Instrumenten, ausser der Trendanzeige, macht eine hohe Updategeschwindigkeit naturgemäss keinerlei Sinn. Ich denke mal so max. 5-10 Updates pro Sekunde reichen da voll aus. Bei der Trendanzeige darf es ruhig etwas mehr sein. Meine vorläufige Protokoll-Idee sieht erst mal so aus: #x Instrument Nummer A Analog-Kennung D Digital-Kennung danach der Messwert als Beispiel mal so: #1A80,52#2A5#3D0#29A6,30#5A10CRLF Man kann vom MC alle Instrumente in einem Durchlauf bedienen oder aber z.B. die Trendanzeige zwischendurch öfter mit Daten beaufschlagen. Danke für Deine Ideen, die für Deinen Fall bestimmt Gold wert waren. Aber ich will hier keine Eierlegendewollmilchsau kreieren, noch möchte ich die nächsten Monate nur an dieser Software verbringen. Und ich denke für die meisten Hobbybastler wird meine Lösung sicherlich ausreichen. Die Profis mögen sich eigene Programme erstellen oder kaufen. Nochmal: Keep it Simple. Das fängt beim Protokoll an. Da dieses Stringorientiert ist, kann man da schnell auch mal reinschauen mit dem Logic-Analyser oder Terminal-Programm und sieht in Klartext was da so vom MC kommt. Das geht mit Binary nicht mehr, obwohl das natürlich auf der Schnittstelle schneller wäre. Aber Schnelligkeit ist hier nun mal überhaupt nicht gefragt.
:
Bearbeitet durch User
Nochmal zum Protokoll: Das Protokoll ist einfach und hat jetzt folgende Parameter: X - Identifier für neuen Messwert n - gewünschte Instrumenten Nummer A - Identifier für Analogwert D - Identifier für Digitalwert m - Messwert S - Start eines Datensatzes E - Ende eines Datensatzes CRLF - als Ende Zeichen #13#10 für die Schnittstelle Ein Datensatz kann dann z.B. so aussehen: SXnAmXnAmXnDmE oder auch nur so: SXnAmE und sähe mit wirlichen Werten z.B. so aus: SX1A24,67X25A12,2X31D0E Das kann von jedem Microcontroller einfach als String geschickt werden und lässt sich einfach mit jedem Terminalprogramm oder LogicAnalyzer betrachten. Die Datenstrings können beliebig gemischt an den Pc übertragen werden, eine bestimmte Reihenfolge muss nicht eingehalten werden. Diese Struktur gewährleistet bei mir eine sehr schnelle Verarbeitung bei der Stringaufdröselung und beim anschliessenden Dispatcher. Eine spätere Erweiterung ist einfach möglich, insbesondere da meine Delphi Komponenten für die serielle Schnittstelle eine zusätzliche universelle DataPaket Verwaltung hat.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComInstruments_06.jpg
260 KB -
SerialComInstruments_05.jpg
280 KB -
SerialComInstruments_08.jpg
280 KB
Das Projekt macht gute Fortschritte und ich hoffe nächste Woche die erste funktionsfähige Version vorstellen zu können. Ich habe noch ein Terminal für die serielle Schnittstelle integriert, um sehen zu können was da so auf der Schnittstelle ankommt oder um Befehle zum MC zu schicken. Ich denke mal das die Funktion für Basteleien hilfreich ist:)
:
Bearbeitet durch User
Und so einen Anzeigepfeil am Thermometer kann ich dann tracken und die Position wo ich den hinziehe, wird an den uC zurückgeschickt (optional)? Dann noch die Möglichkeit ein Hintergrundbild anzulegen und die Instrumente festzunageln und fertig ist die Steuerzentrale für was auch immer. Schön.
Abdul K. schrieb: > Und so einen Anzeigepfeil am Thermometer kann ich dann tracken und die > Position wo ich den hinziehe, wird an den uC zurückgeschickt (optional)? Für die Kommunikation vom PC in Richtung MC wird es Schieberegler, numerische Eingabefelder und Taster/Schalter und Ereignisse geben. > Dann noch die Möglichkeit ein Hintergrundbild anzulegen und die > Instrumente festzunageln und fertig ist die Steuerzentrale für was auch > immer. Schön. Ein frei wählbares Hintergrundbild (im PNG-Format) ist vorgesehen. Man kann sich somit ein Prozessbild zeichnen und die Instrumente darauf setzen. Dafür bekommen die Instrumente noch zusätzliche Eigenschaften, wie z.B. ohne Umrandung, Transparent usw.
Und 3... 2... 1... fertig ist die eierlegende Wollmilchsau :)
Martin Schwaikert schrieb: > Und 3... 2... 1... fertig ist die eierlegende Wollmilchsau :) War zwar zuerst nicht so gedacht, da aber nach bereits 11 Tagen, davon vielleicht 6 Programmiertage, das Ganze im Prinzip funktionsfähig ist (alles läuft bei mir , incl. Schnittstelle), kann man sich ja mal Gedanken über einen Ausbau machen.
:
Bearbeitet durch User
Joe G. schrieb: > Ein Blick auf diese Software lohnt auch: > http://www.abacom-online.de/html/profilab-expert.html Die Darstellungsart die man da sieht (Verknüpfung der Instrumente anhand von Linien) könnte patentrechtlich Probleme nach sich ziehen. Ich weiss aus eigener Erfahrung wovon ich da rede. Ein grosser US-amerikanischer Hersteller von Messtechnik und Messtechnik-Software hält ein grosses Paket von Patenten, bezogen auf die Darstellung von Messtechnik und versteht da nicht viel Spass. Das kann gutgehen, solange man denen nicht gross in die Quere kommt, muss es aber nicht.
:
Bearbeitet durch User
Albert M. schrieb: > Das kann gutgehen, solange man denen nicht > gross in die Quere kommt, muss es aber nicht. Softwarepatente gehören eh abgeschafft. Worin besteht denn bitte eine "erfinderische Leistung", wenn ich mir ein umstricheltes Kästchen patentiere?
@Martin Schwaikert Das ist auch meine Meinung, leider ist es aber so. Wobei nicht das "Kästchen" ansich patentiert ist, sonder die Verbindung von Kästen mit eigener Funktionalität und die Darstellung des Signalflüsses zwischen diesen Kästchen. Wie gesagt ein heikles Thema, das schon 2 mal ganz böse geendet hat.
:
Bearbeitet durch User
Albert M. schrieb: > Aber ich will hier keine Eierlegendewollmilchsau kreieren, noch möchte > ich die nächsten Monate nur an dieser Software verbringen. OK, schon klar. Mir ist nur beim Lesen eingefallen, daß du ja eventuell später mal sowas wie eine grafische Anzeige (also Oszi-Bild, Kurvendarstellung oder so) haben möchtest - und für sowas braucht man schon ein bissel Bandbreite auf der Seriellen. Nur als Anregung (unterste Stufe aus meiner Protokoll-Definition): 00h .. 0Fh = Bereich für Steuerzeichen (CR, LF usw.) 10h .. 1Fh = Bereich für Meßpunkt-Infobytes (synchronisieren von Blöcken) 20h .. 5Fh = Bereich für Klartext aller Art 60h .. 6Fh = Bereich für Kurvenprotokoll-Infos 70h .. 7Fh = spezifisch je nach Kurvenprotokoll 80h .. FFh = binäre Meßwerte. Bedeutung je nach Art des aktuellen Kurvenprotokolles. Im Prinzip ist das sogar jetzt schon mit deinen Vorstellungen kompatibel, solange bei dir die Kleinbuchstaben und alles >0x7F nicht im Text vorkommen. Albert M. schrieb: > SXnAmXnAmXnDmE oder auch nur so: SXnAmE Hmm.. Naja, kann man alles so machen, ich hab aber dazu noch nen Vorschlag: Du programmierst geradeaus und eher doch aus PC-Sicht als aus µC-Sicht. Albert M. schrieb: > X - Identifier für neuen Messwert > n - gewünschte Instrumenten Nummer > A - Identifier für Analogwert > D - Identifier für Digitalwert > m - Messwert > S - Start eines Datensatzes > E - Ende eines Datensatzes > CRLF - als Ende Zeichen #13#10 für die Schnittstelle Deshalb hast du ne Menge eigentlich überflüssiger Steuer- und Ende-Kenner und damit ne Menge Zeugs, was sich der jeweilige Empfänger zum Dekodieren merken muß. Finde ich so nicht günstig. Dreh das ganze doch um, etwa so: 123K4711.0815A92K1D was bedeutet das: K selsktiert ein Gerät A liefert nen Analogwert D liefert nen Digitalwert Also ünersetzt sich obiges zu - selektiere Gerät 123 - gib dem Gerät den Analogwert 4711.0815 - selektiere Gerät 92 - gib dem Gerät den Digitalwert 1 Die Dekodier-Regel dafür ist extrem simpel: kommt eine Ziffer (oder ein Dezimalpunkt) dann wird das unmittelbar zu einer Zahl zusammengesetzt. Einen String oder einen führenden Buchstaben braucht sich niemand zu merken. Kommt ein Buchstabe, dann beendet er die zuvor übertragene Zahl und löst die zugehörige Aktion aus, also z.B. eines der Geräte auswählen, wo nachfolgende Infos hingehen sollen, oder eine Analog- oder Digital-Info an das selektierte Gerät geben oder je nach anderen Buchstaben irgendwelche anderen Aktionen auslösen. Dabei löscht jeder Buchstabe nach seiner Abarbeitung die zuvor übertragene Zahl. Das hat den Vorteil, daß du kein Rahmen-Protokoll brauchst, also dein S oder E nebst CR-LF sind überflüssig. Ebenso kannst du bei Bedarf unendlich viele (auch unterschiedliche) Infos an dasselbe Gerät übertragen, ohne es jedesmal wieder auswählen zu müssen. Die übertragenen Kommandos sind also atomar und damit nicht an irgendwelche einengenden Rahmenbedingungen gebunden. Damit ist das Protokoll offen für Erweiterungen aller Art. W.S.
@ W.S. Danke für die Info über Dein Protokoll, sehr interssante Lösung. Mein Pakethandler(fertige Delphi-Komponente) erlaubt es mir das alles sehr zu vereinfachen. Der erzeugt aus einem Datenfluss durch Angabe von Start und Endzeichen den Sub-String zwischen Start und Ende. Das ermöglicht es mir ohnen riesen Protokoll ein einfaches Extrahieren der ankommenden Daten. Mein Protoll konnte ich jetzt noch mehr abspecken: - CRLF sind jetzt überflüssig wie bei Dir - Senden eines oder mehrer Messwerte mit: #IMw; wobei #=Startkennung, I=Instrumenten-Nummer M=Kennung für Messwert, w=Messwert, ;=Endennung Das lässt sich beliebig anderandergefügt oder auch einzeln senden. Durch die Instrumenten-Nummer ist die Funktionalität eindeutig in beide Datenflussrichtungen gekennzeichnet. Die Instrumenten-Nummer kennzeichnet automatisch ob der empfangene oder gesendete Wert numerisch oder alphanumerisch ist. Das Protokoll lässt sich einfach erweitern, indem ich in weiteren Pakethandlern andere Start - und Endekennungen angebe.
:
Bearbeitet durch User
Noch ne Anregung in Bezug auf Protokolle: Man könnte auch die Syntax von SPICE übernehmen. Das mag zwar komisch klingen, aber so wie ich es momentan ohne jetzt tiefe philosophische Gedanken umherschweifen gelassen zu haben, sehe, könnte das klappen. Der Vorteil ist schlicht, daß man nicht noch eine Syntax lernen muß. In ferner Zukunft wäre vielleicht eine Anbindung an ein SPICE möglich mit einem Helper-Programm. Das was an physikalischen Daten geliefert wird, würde so zu einer fertigen Simulationslandschaft... Schau es dir einfach mal an. Wichtiger ist mir aber eine funktionsfähige Software in naher Zukunft. Egal was du als Protokoll festlegst. Man verliert ja auch leicht die Lust an sowas und dann ist es nur wieder eine halbfertige Baustelle, die niemanden nützt außer Staub und Zeit aufgewirbelt zu haben :-) Ich bin nicht ganz unvorbelastet, da ich mal an einem Projekt zur Prozeßsteuerung mitarbeitete. Sozusagen als Betatester. Die Sache war aber auf dem Mac und ist lange gestorben. Kann mich noch an die Diskussionen erinnern, wie man den Signalfluß in Software gegossen kriegt und das alles in Echtzeitanforderung. Und wir hatten Linien zwischen den Boxen ;-)
Albert M. schrieb: > Der erzeugt aus einem Datenfluss durch Angabe von > Start und Endzeichen den Sub-String zwischen Start und Ende. Jajaja doch. Tokenizer gibt's wie Sand am Meer. Aber du hast PAKETE - das isses. Du hast keine atomaren Aktionen und damit hast du immer, immer immer!! wieder die Not, Strings hereinzuholen und Substrings zu bilden und obendrein ne ausgiebige Fehlerbehandlung, weil eben deine Daten im Paket daherkommen und nicht in einzelnen Brocken. Im PC mit seinen riesigen Ressourcen ist das nur ne simple Fleißaufgabe, aber du mußt ja auch derartige Info-Pakete (oder eben Atome) vom PC zum µC schicken und dort wird es dann eng. Schließlich soll die Kommunikation ja nicht den µC voll ausbuchen und für den Rest, nämlich die eigentliche Funktionalität, nur den Katzentisch lassen. Abdul K. schrieb: > Das mag zwar komisch klingen,.. ähemm.. naja isses auch. Irgendwelche Spice-Notationen sind nicht für nen bidirektionalen Datenverkehr zwischen zwei völlig unterschiedlichen Geräten gedacht. Was dir vorschwebt, ist also ne andere Baustelle. Ansonsten gibt es bei dem hier andiskutierten Projekt keine "noch ne Sprache" auswendig zu lernen. Das einzige, was es geben MUSS, ist die Korrespondenz zwischen einem Stück Programm im µC und einem grafischen Element auf dem Bildschirm des PC. Das muß jeweils aus einem "Guß" sein und folglich wohl am besten aus einer Hand kommen. Wie das aussieht mit verschiedenen µC Sorten und auf denen mit nach außen gleichgesichtigen Programmelementen, das wäre eine der vielen sofort aufkommenden Folgefragen. Insofern hat jedes Entwurfsdetail an der jetzigen Stelle mit Sicherheit schwerwiegende Folgen. W.S.
Du interessierst dich nur für deinen Ansatz. Das akzeptiere ich, mehr aber auch nicht. Die SPICE-Syntax gibt einiges her: Vthermometer max=42 min=35 level=36,8 als Beispiel. Wäre vollkommen SPICE-kompatibel und den Inhalt brauche ich wohl nicht weiter zu erklären. Das könnte ein Thermometer sein, was sich der µC nun für den Benutzer wünscht. Oder als Alarmmeldung aufpoppt. Nicht das ich SPICE toll fände, aber ich lernte die Vorteile durch schnöde tägliche Arbeit kennen.
:
Bearbeitet durch User
W.S. schrieb: > Aber du hast PAKETE - das isses. > Du hast keine atomaren Aktionen und damit hast du immer, immer immer!! > wieder die Not, Strings hereinzuholen und Substrings zu bilden und > obendrein ne ausgiebige Fehlerbehandlung, weil eben deine Daten im Paket > daherkommen und nicht in einzelnen Brocken. Das erledigt, wie bereits gesagt, mein Pakethandler zu 90% intern. Der Rest sind Peanuts. Fehlerbehandlung wird keine durchgeführt, weil das erstens kein Industrieprojekt ist und zweitens meine Test mit 115200 Baud und vielen aktivierten Instrumenten keinerlei Fehler im Datenstrom ergeben haben. Wenn dann doch mal unwahrscheinlicherweise ein Fehler auf der Schnittstelle sein sollte, wird entweder der Messwert nicht weitergereicht, weil z.B. die Kennung falsch ist oder eben einmal ein falscher Wert angezeigt. So what, das ist ein Projekt für Hobbyisten und wer das nicht akzeptiert, braucht es ja nicht nutzen. Das Protokoll werde ich auf keinen Fall weiter aufblähen. Ich bleibe bei meinem Konzept das Ganze so einfach und funktional wie möglich zu halten, sowie nur Strings und keine Binärwerte über die Schnittstelle zu schicken. W.S. schrieb: > aber du mußt ja auch > derartige Info-Pakete (oder eben Atome) vom PC zum µC schicken und dort > wird es dann eng. Schließlich soll die Kommunikation ja nicht den µC > voll ausbuchen und für den Rest, nämlich die eigentliche Funktionalität, > nur den Katzentisch lassen. Die Kommunikation vom PC zum MC läuft genau so ab wie umgekehrt. Anhand der Instrumenten-Nummer weiss der PC von welchem Element die Daten kommen. Ein "Instrument" kann dabei durchaus auch ein Taster, Schalter oder Eingabefeld sein. Also so: # Instr.-Nr M Messwert; Damit dürfte die MC Seite nicht ungewöhnlich belastet sein, insbesondere auch deshalb, weil diese Datenrichtung ja nur einen Bruchteil der Zeit in Anspruch nimmt. Man ist ja am PC nicht andauernd mit Eingaben für den MC beschäftigt.
:
Bearbeitet durch User
Albert M. schrieb: > Das erledigt, wie bereits gesagt, mein Pakethandler zu 90% intern. OK, sieh es bitte so: sowohl Abdul's als auch meine Beiträge zum Thema sind Vorschläge, eben Vorschläge. Aber mal ne andere Frage: Hast du diesen Pakethandler auch schon für die µC-Seite und wenn, für welche Prozessorfamilien? W.S.
W.S. schrieb: > Aber mal ne andere Frage: Hast du diesen Pakethandler auch schon für die > µC-Seite und wenn, für welche Prozessorfamilien? > > W.S. Der Pakethandler gehört zu den Delphi-Components für die serielle Schnittstelle.
Lasst doch den Albert. Er zieht ja nur sein Ding durch. Dabei gab's sicher viel zu lernen. Der Rest kommt ein anderes Mal. Egal.
--chloro schrieb: > Lasst doch den Albert. Er zieht ja nur sein Ding durch. Dabei gab's > sicher viel zu lernen. Der Rest kommt ein anderes Mal. Egal. Lass Ihn doch sein Ding machen! Eine Menge Leute haben sicher Bedarf an grafischen Sachen, ohne die Cracks in Sachen Java Scrpt, CGI oder so zu sein. Von daher... Ich habe mir den ganzen Faden interessenhalber duchgelesen und ich frage mich, wozu ich im Protokoll eigentlich eine Kennung A und D brauche... Entweder ein Instrument ist digital oder analog, oder? Anhand der Instrumentennummer weiss ich ja, wer was ist... Ich habe mich seit gewisser Quälereien mit einem Turbo-Pascal 7 nie wieder mit Abkömmlingen der Fa. Borland befasst, aber es scheint mir für Einsteigerzwecke ist diese Lösung schon sehr gut geraten! Und mehr soll sie wohl auch nicht sein... Klar gibt es immer was zu bemängeln, aber braucht man das wirklich? Muss es immer ein z.B. ein CRC32 sein, oder reicht nicht auch ein einfaches XOR (like xmodem) um zu wissen, das was schief gegangen ist ? Just my 3 Cents. Gruss aus Peking Elux
>Muss es immer ein z.B. ein CRC32 sein, oder reicht nicht auch ein einfaches XOR
(like xmodem) um zu wissen, das was schief gegangen ist ?
Das ist immer eine Frage gegen was eine Pruefsumme denn schuetzen soll.
Ein CRC16 zB schuetzt 2^16 bit (= 8kByte) gegen Einzelbitfehler. Ein
CRC32 schuetzt 2^32bit = 500MByte gegen Einzelbitfehler.
Ein XOR ist vielleicht auch gut...
Man kann einmal ein gutes Protokoll fuer alle kommenden Applikationen
implemetieren, oder sich eben langsam dorthin bewegen. Die Fuersprecher
eines guten Protokolles waren einfach schon dort.
Eigentlich geht das Ganze etwas weiter. Man kann ein Protokoll einem
Kontext folgen lassen, oder eben auf kontextlos optimieren. Kontextlos
bedeutet ein Command und seine Antwort beziehen sich auf keine
Vorgeschichte, sind in sich abgeschlossen und haben keinen versteckten
Zustand.
zB auslesen eines Loggers :
mit Zustand/Kontext
-ReadHeader
-ReadNext
-ReadNext
-ReadNext
-..
ohne Zustand/Kontext
-ReadHeader -> pointer
-ReadRecord(1) bezuegl pointer
-ReadRecord(2) bezuegl pointer
-ReadRecord(3) bezuegl pointer
-ReadRecord(4) bezuegl pointer
..
Wenn man im ersten Fall einen Block verliert ist der Rest fuer die
Tonne.
Welche Felder in einem Protokoll bringen was fuer Vorteile? Eigentlich trivial, wenn man's schon mal gehoert hat. -Header zeigt wo die Meldung beginnt, falls man denn mal ein Zeichen verloren hat. Oder den Anfang des Blockes verpasst hat. -Laenge zeigt wie lange die Meldung ist. Was verschieden lange Meldungen erlaubt. -Command code erlaubt als Selektor verschiedene Funktionalitaet auszuloesen. -Adressierung erlaubt verschiedene Endgeraete zu unterscheiden -Escape Sequenz schuetzt den Header, falls man in minimaler Zeit neu synchronisieren moechte/muss. -Checksumme ausgefuehrt als CRC, XOR, oder irgendwas. Gibt eine Indikation in die Zuverlaessigkeit der Daten -Ack/Nack Soll man Befehle implizite Antwort beantworten oder nicht?
Reiner O. schrieb: > Ich habe mir den ganzen Faden interessenhalber duchgelesen und ich frage > mich, wozu ich im Protokoll eigentlich eine Kennung A und D brauche... Es ist doch toll, wenn man Analoganzeigen auch für digitale Aufgaben nutzen kann. Bei Digitial ist 1 gleichzeitig auch Messbereichsendwert.
Angehängte Dateien:
-
SerialComInstruments_10.jpg
380 KB
Hier gibt es eine erste Testversion mit bis zu 10 Vertikal-Analog-Metern. Weitere Instrumente folgen. Bedienung: - Auf "Instrumente" klicken - Klick auf gewünschte Instrumentenbezeichnung z.B #01 - Rechts können nun die Instrument Eigenschaften eingegeben werden - Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen - Links die darzustellenden Instrumente in der Checkbox aktivieren - Die Einstellungen mit"Instrumente Status zuweisen" übernehmen - Auf "Show" klicken - Die Instrumente mit der Mouse an die gewünschte Stelle platzieren Die Einstellung der Schnittstelle nicht vergessen. Die Schnittstelle kann noch nicht an den MC senden, empfangen geht mit bis zu 115200 Baud. Das aktuelle Protokoll ist unter Schnittstelle erklärt. Für die Instrumente eignet sich als Standardgrösse z.B. Breite = 130 und Höhe = 400, als Skala Steps =5 und Skala Substeps = 2. Für Instrument Name und Einheit die gewünschten Bezeichnungen als Text eingeben. Die ini-Datei wird zur Zeit in C:\Users\Anwender\AppData\Local geschrieben. Der Ordner und Dateiname wird aber später frei wählbar sein, da in der ini die kompletten Einstellungen des jeweils aktuellen Projektes gespeichert sind. Damit lässt sich also das individuelle Projekt dann speichern und wieder laden. Zum schnellen Test und Beispiel für 8 Instrumente habe ich noch ein Bascom Programm angehängt.
:
Bearbeitet durch User
Das Instrument wird nicht groß, sondern bleibt so ein kleiner Knopf. Durchschaue die Einstellerei nicht wirklich. Naja, warten wir auf die nächste Version. Die Fenster werden übrigens auch nicht automatisch am gegebenen Bildschirm begrenzt/skaliert. Und die ini-Datei bitte einfach im Projektordner suchen lassen.
@Abdul K. Da brauchst Du nicht auf die nächste Version warten, sondern Dich nur an meine obige Kurzanleitung halten, dann werden die Instrumente auch so wie Du möchtest :) Und nicht vergessen: - Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen
:
Bearbeitet durch User
Angehängte Dateien:
-
Haufen.png
16 KB
Sorry, bevor ich frage probier ich es mindestens 3x aus und variiere es auch mal wenn ich nicht weiterkomme. Offensichtlich kennst du mich noch nicht lange. Und ich habe es gerade nochmal exakt probiert. Das sieht dann so aus. Das "- Die Einstellungen mit dem Button "Instrument Werte zuweisen bestätigen" heißt wohl "Instrument #1 Werte zuweisen", oder? Ne Konfigurationsdatei zum Selbereditieren würde mir reichen. Es sind auch noch andere Unstimmigkeiten in deiner Beschreibung. Z.B. warum soll ich ein Instrument extra aktivieren, wenn es bereits beim Öffnen des Fenster aktiv ist? Irgendwie reden wir aneinander vorbei. Hat das jemand anders auf Anhieb zum Laufen gebracht?
... und hier auch noch was zum Programm testen mit Luna Ich glaube das Protokoll ist so simpel, dass jeder damit sofort zurecht kommt. Das dürfte in C genau so einfach sein wie in Bascom oder Luna.
Abdul K. schrieb: > Und ich habe es gerade nochmal exakt probiert. Das sieht dann so aus. Das zeigt, dass Du dem Instrument die Werte entweder nicht zugewiesen hast oder keine sinnigen Einträge in Höhe und Breite vorgenommen hast. Ich habe dazu oben extra als Beispiel Standardwerte angegeben. > Das "- Die Einstellungen mit dem Button "Instrument Werte zuweisen > bestätigen" heißt wohl "Instrument #1 Werte zuweisen", oder? Die linken Buttons #01 ... #10 aktivieren auf der rechten Seite die Einstellungen für das zugehörige Instrument und zeigen die bereits zugewiesenen Werte. > Es sind auch noch andere Unstimmigkeiten in deiner Beschreibung. Z.B. > warum soll ich ein Instrument extra aktivieren, wenn es bereits beim > Öffnen des Fenster aktiv ist? Das brauchst Du nicht. Der Button "Instrumenten Status zuweisen" braucht Du nur drücken wenn sich Veränderungen ergeben habe, entweder Instrumente zugefügt oder abgeschaltet. > Irgendwie reden wir aneinander vorbei. Hat das jemand anders auf Anhieb > zum Laufen gebracht? Ja
:
Bearbeitet durch User
Angehängte Dateien:
-
TestMessung_mVolt.png
150 KB
So, hab es ausprobiert. Max Anzeige ist wohl 3 Stellig, ansonsten funktioniert es. Kannst du das auf 4 Stellen erweitern ? Danke.
OK, dann gehts. Dachte beim Sehen da du bereits Werte eingetragen hattest, die kann ich einfach übernehmen. Nur war die Fenstergröße viel zu klein eingestellt. Danke.
Pfeil draggen geht aber nicht. Noch nicht drin?
ich hoffe das es keinen stört aber ich lege den Finger nochmal in die Laview-Wunde. zur Ehrenrettung muss man sagen das Programme wie Step 7, Rockwell automation usw. in sachen unterprogramme und Hintergrundprozesse nicht besser sind! Eine so mächtige Software benötigt auch Rechenleistung. zum Thema Visa - Serieller Treiber, was soll jetzt daran schwierig sein??? 1. konfigurieren 2. Lesen oder Schreiben 3. Fehler auswerten das sind 4 Blöcke, 10 Konstanten und ein paar verbindungen!! dafür gibts jedemenge Beispiele im Netz, sogar bei NI selbst. Wer meint das Labview selbst den Rechner zu sehr belastet kann sich, auch mit einer Studenten oder Demo Version, eine Autarke exe Datei erzeugen! wir haben so in der Schule einen Mega32 als Messkarte benutzt über... genau... RS232! nicht falsch verstehen, hatte mal was ähnliches mit Java gemacht (nicht in dem Umfang) und bin von solchen Projekten immer wieder fasziniert! ich werde den Threat aufjedenfall weiterhin folgen! gr matze
Bernd N schrieb: > So, hab es ausprobiert. Max Anzeige ist wohl 3 Stellig, ansonsten > funktioniert es. Kannst du das auf 4 Stellen erweitern ? Danke. Kein Problem, Fehler gefunden :) In der nächsten Version stellt sich das numerische Anzeigenfenster automatisch auf die vom Anzeige Format String vorgegebene Grösse ein. Für z.B. 4-stellige Anzeige dann Format String ###0 eingeben.
matze schrieb: > ich hoffe das es keinen stört aber ich lege den Finger nochmal in die > Laview-Wunde. > > zur Ehrenrettung muss man sagen das Programme wie Step 7, Rockwell > automation usw. in sachen unterprogramme und Hintergrundprozesse nicht > besser sind! Eine so mächtige Software benötigt auch Rechenleistung. > Naja. Die Software an der ich beteiligt war, lief auf einem Mac anno 1996 ohne ihn voll auszulasten, mit einem Batterie-Teststand. Heute laufen die PCs 10x schneller oder mehr. Man konnte problemlos in Echtzeit den Ablauf verändern, Icons rumschieben usw. Also kein Argument. Ich weiß auch nicht was Labview so aufwändig rechnet. Firmen wie TI benutzen es ja für ihre Demos und ich bekomme da immer das Kotzen wenn ich nur daran denke sowas runterladen zu müssen. Labview ist wirklich irre langsam.
Angehängte Dateien:
-
test.JPG
28 KB
Guten Abend/Nacht erstmal ;) @albertm Hab eben mal dein Programm ausgetestet und ein kleines C Programm/ Ne Funktion für das Protokoll geschrieben. (Hier, falls es jmd gebrauchen kann. (Sollte selbsterklärend sein))
1 | #include <stdlib.h> |
2 | void setInstrument(uint8_t nr, uint32_t wert) |
3 | {
|
4 | unsigned char str_nr[5]; |
5 | itoa(nr, str_nr, 10); |
6 | |
7 | unsigned char str_wert[14]; |
8 | itoa(wert, str_wert, 10); |
9 | |
10 | uart_sendstring("#"); |
11 | uart_sendstring(str_nr); |
12 | uart_sendstring("M"); |
13 | uart_sendstring(str_wert); |
14 | uart_sendstring("<"); |
15 | }
|
Zuerst einmal: Tolles Projekt! Werde das mal weiter verfolgen, wird bestimmt toll :) Während ich bissel gedebuggt hab sind mir 2 kleine Bugs/Nervige Dinge in deinem Programm aufgefallen: 1. Wenn man das Programm frisch startet ist es bei mir so, dass als COM-Port schon die Nr. 2 ausgewählt ist (bei "Schnittstelle"), ich aber mit einem Fehler Nr. 2 nicht connecten kann ( Denke Fehler Nr.2 ist "COM-Port nicht vorhanden" o.Ä) bei einem Blick auf "Terminal" zeigt sich das in Wahrheit noch COM-Port 10 ausgewählt ist! Beheben lässt sich dies durch erneutes klicken auf COM 2 bei "Schnittstelle". 2. Während des Debuggens von der String Übertragung vom µC habe ich dein Terminal genutzt, bin aber nach kurzer Zeit zurück zu Putty, da es bei deinem unpraktisch ist, dass die Zeile einfach weitergeht und nicht bei Bildschirm-/Fensterende umbricht. 3. Ein Instrument, dessen Einstellungen nicht verändert wurden, man sondern nach dem Aktivieren einfach nur auf "#0n" und dann "[...] Wert zuweisen" drückt, übernimmt es diese Standardwerte nicht und bleib ohne Skala. Das alles dürfte sich schnell beseitigen lassen. Ansonsten finde ich es echt gut ! :) Auch die "Eingewöhnungszeit" war total kurz, innerhalb von ein paar Minuten versteht man wie du dir das gedacht hast.. Zu dem Protokoll: Ich denke es ist so sehr einfach gehalten und so effektiv . Es ist leicht zu verstehen. Alles in allem ein wirklich nettes Projekt. Das war's von mir soweit, werde auch die nächsten Versionen testen! MFG Renixor
@Renixor Danke für Dein konstruktives Interesse! Die Behebung der Fehler ist in Arbeit. Da ist ja mal einer dem mein Protokoll gefällt :)
Albert M. schrieb: > @Renixor > > Danke für Dein konstruktives Interesse! > Die Behebung der Fehler ist in Arbeit. > > Da ist ja mal einer dem mein Protokoll gefällt :) So ists ja nicht ;) Glaube es gibt nochn paar mehr denen das Gefällt. Viel Spaß bei der Fehlerbehebung ;), Renixor
Angehängte Dateien:
-
test.JPG
120 KB
So habe gerade mal ein bisschen weiter getestet. Mir sind keine weiteren Fehler (außer dem schon angesprochenen Problem mit den 4-stelligen Zahlen. Anbei ein Bild von allen 10 Instrumenten, mit Zufallszahlen vom µC. Hab auch mal die maximale mögliche BAUD ausprobiert. Bei meinem verwendeten Mega8 mit 8MHz liegt sie bei 56000. Funktioniert mit der Geschwindigkeit auch noch einwandfrei. Das wars dann erstmal mit Testen bis zur nächsten Version! :) MFG Renixor
Vor einiger Zeit habe ich mich auch mit euerem Thema befasst. Meiner Meinung nach ist es am Besten, wenn man vom Mikrocontroller aus die graphischen Elemente platzieren kann. Das heist, die Konfiguration der GUI soll im MC stecken. Der Vorteil ist, dass dann das MC-Programm immer zur GUI passt. Ein sehr nützliches GUI-Element ist auch eines, bei dem der MC einfach Punkte oder Linien zeichnen kann. Das kann man verwenden, falls gerade kein passendes, vorgefertigtes Element GUI-Element vorhanden ist. Hier habe ich das Prinzip in einem Python Script umgesetzt: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=139 Damit ich es schnell implementieren konnte und das Prinzip gut verdeutlicht wird, habe ich Klartextkommandos verwendet. Dadurch ist die Datenübertragung natürlich entsprechend langsam. Das solte man in einer entgültigen Version natürlich verbessern.
Angehängte Dateien:
-
fbootgui.PNG
46 KB
Dein Programm gefällt mir sehr gut. Genau so etwas fehlt mir häufig. Einen eigenen Ansatz hatte ich auch mal. (Siehe angehängten Screenshot) Da war mir wichtig: - mehrere Balkendiagramme zu haben um mehrere AD Kanäle zu vergleichen zu können - Beliebige Zahlen in Anzeigen darzustellen (Umschaltbares Zahlenformat) - Buttons, welches einen einstellbaren Wert senden. - Ein Mini Terminal um alles ankommende darzustellen (Debugging) Dein Programm geht in die gleiche Richtung, nur mit deutlich mehr Software Know How. Ich bin auf das Ergebnis gespannt. VG! Se Edit: Nur im Gegensatz zu meinem Vorredner würde ich so wenig wie möglich im µC machen lassen. Wenn die Einstellungen im Programm speicherbar sind kann man sich Projektspezifisch die Gui ablegen.
:
Bearbeitet durch User
chris_ schrieb: > Meiner Meinung nach ist es am Besten, wenn man vom Mikrocontroller aus > die graphischen Elemente platzieren kann. Das heist, die Konfiguration > der GUI soll im MC stecken. Der Vorteil ist, dass dann das MC-Programm > immer zur GUI passt. Da muss ich dir widersprechen und s-engel beipflichten. :) Ich denke auch, man braucht nicht den µC unnötig zu belasten und ihn die ganzen Elemente platzieren lassen. Ich würde es so machen wie in dem Projekt auch schon angedeutet: Datei->Projekt Speichern/Laden. Dann z.b. die Projekt-Datei aufm Desktop mit entsprechendem Name und gut is. Dann öffnet man die einfach und hat alles. chris_ schrieb: > Ein sehr nützliches GUI-Element ist auch eines, bei dem der MC einfach > Punkte oder Linien zeichnen kann. Das kann man verwenden, falls gerade > kein passendes, vorgefertigtes Element GUI-Element vorhanden ist. Ich bin mir nicht sicher ob ich das richtig verstanden habe, aber meinst du nicht einen einfachen Graph? Habe auch kurz dein Python Script angeguckt. Aber dort ist das ja auch nur im Grunde ein Graph und der ist hier ja schon im ersten Post drin. ( Bild )
Das eine schließt das andere nicht aus. Und ich hatte bereits dafür ein Beispiel gebracht: Alarmmeldung.
Warum sollte der uC bei einer Alarmmeldung die Instrumente setzen? Erwarten würde ich sowas wie z.b. ne Füllstandsanzeige und wenns überläuft setzt der uC einfach ein LED Instrument... Müsstest nochmal erklären was du meinst :) MFG Renixor
Der Ansatz mit den selbstanzeigenden Instrumenten ist passend fuer ein unbestimmte Vielfalt und ebenfalls unbestimme Entwicklungsrichtung dieser Geraete, die unter immer demselben GUI sich selbst anzeigen sollen. Dh man sollte da auf einen hinreichend verbreiteten Standard setzen. zB Python. Wir haben das auch mal probiert und haben Javascript und AJAX verwendet. Anzeige war dann der Internetbrowser. Das ging. Jedes Device hatte die konstanten Elemente seiner Anzeige in einem 500kByte AT45DB041D Flash. Dieses Flash wurde dann fuer jeden refresh der Anzeige abgespult und die passenden Messwerte wurden dann in den Stream eingefuegt, sodass der Browser das dann umsetzen konnte. Floatingpoint Berechnung zur Skalierung der Messwerte wurden dann per Javascript auf dem Browser gerechnet. Ein abgehobenes Projekt, nett zum Ueberlegen, sehr aufwendig zum Implementieren.
@Plod Vergiss Phyton für so ein Projekt wie meines. Phyton ist gegenüber Delphi schnarchlangsam und könnte die schnellen Abläufe nicht handeln. Ich habe hier Tests laufen mit 115200 Baud und 50 Instrumenten. Wie willst Du das "realtime-mässig" in Phyton handeln? Nix für Ungut, aber das ist Wunschdenken. Bis dass Du mir das Gegenteil beweist. Dein Ansatz mit den selbstanzeigenden Instrumenten vom MC aus ist genau so abwegig. Willst Du freiwillig damit noch wesentlich mehr Daten über die Schnittstelle schaufeln und den MC übermässig auslasten? Und was machst Du, wenn Du z.B. nur einen anderen Monitor mit kleinerer/grösserer Auflösung am PC hast. Schreibst Du dann Deine MC Firmware neu? Hört sich alles ziemlich nach Elfenbeinturm an. Wie auch immer, mein Projekt ist inzwischen gut weiter gediehen: - Fehler beseitigt - weitere Instrumenten Eigenschaften, wie z.B. transparent, ohne Rahmen usw. - Hintergrundbild (z.B. Prozess-Schema) kann eingefügt werden
:
Bearbeitet durch User
Albert M. schrieb: > Wie auch immer, mein Projekt ist inzwischen gut weiter gediehen: > - Fehler beseitigt > - weitere Instrumenten Eigenschaften, > wie z.B. transparent, ohne Rahmen usw. > - Hintergrundbild (z.B. Prozess-Schema) kann eingefügt werden Schön zu hören :) MFG Renixor
Angehängte Dateien:
-
SerialComInstruments_11.jpg
310 KB
Hier mal ein Beispiel mit Hintergrunbild, zwar noch nicht ganz perfekt, aber sieht doch gut aus. Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen. Das hab ich mal investiert :) In einem beliebigen Vektor-Zeichenprogramm dann damit ein Prozessbild gezeichnet und als Hintergrundbild geladen. Darauf dann die Instrumente vom Programm auf transparent gestellt und plaziert. Das Ganze soll nur zeigen was man mit meiner Software so alles anstellen kann. Macht mir selber richtig Spass.
:
Bearbeitet durch User
Angehängte Dateien:
-
test.JPG
68 KB
Abend zusammen, Ich habe mal eben das Programm in ein kleines "Projekt" eingebunden: Mein Mega8 mit ner Photodiode, die mitm Widerstand nen Spannungsteiler bilden und an ADC0 geht. Funktioniert klasse und man sieht SEHR schön den Zusammenhang der ADC Werte und der ADC-Spannung. Die Werte im Bild sind bei normaler Zimmerbeleuchtung und gehen bei Dunkelheit in Richtung 5V. Ganz nette Sache ;) Albert M. schrieb: > Hier mal ein Beispiel mit Hintergrunbild, zwar noch nicht ganz perfekt, > aber sieht doch gut aus. > Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen. > Das hab ich mal investiert :) Sieht zwar noch nicht perfekt aus, aber schon ganz gut ;) Ist natürlich vieeel schöner so als.
>Wir haben das auch mal probiert und haben Javascript und AJAX verwendet. >Anzeige war dann der Internetbrowser. @Plod Die Version mit Internetbrowser finde ich sehr gut, weil man dann nur einen Server braucht und die Anzeige auch über das Internet visualiseren kann. Ich hatte die Idde auch schon, aber ich hätte nicht gewusst, wie man dynamische Vorgänge darstellen kann.
Albert, niemand will dir dein gelungenes Projekt zerreden. Das sind einfach nur Gedankengänge, die man vielleicht mal umsetzen kann oder eben nicht realisiert werden. Die wurden ja auch schon x-mal woanders durchgekaut. Jeder hat so seine Erfahrungen und Träume. Mach es einfach fertig und nimm kleinere Ideen mit auf. Dann wird das ne super Sache und eigentlich weiß ich nicht, wieso sowas nicht schon von jemand anders in Angriff genommen wurde. Auch wenn ich dafür gerade keine Anwendung habe. Eine kommt bestimmt. Teiltransparente Hintergründe/Vordergründe wären übrigens toll in fast allen Programmen. Mir ist genauso unverständlich, warum das nicht generell verwendet wird. Zumal es Windoof seit XP standardmäßig unterstützt. Die Anwendungen sind vielfältig, z.B.: - Diagramme aus Datenblatt zum Vergleich mit selbergeschriebenen SPICE-Modell hinterlegen und Parameter dann justieren. - Fertiges Layout oder Maßzeichnung eines Gehäuses hinter ein Layout einer Platine legen und Bauelemente passend platzieren. Komischerweise findet man diese Funktion nur sehr selten und oft nur umständlich realisiert.
Wow ich muss sagen, ich bin wirklich begeistert von deiner Arbeit! Werde die Software demnächst mal Ausprobieren. Was ich persönlich noch spannend fände, die Projekte als eigentstänige .exe Dateien exportieren zu können. MfG Bene
Benedikt K. schrieb: > Was ich persönlich noch spannend fände, die Projekte als eigentstänige > .exe Dateien exportieren zu können. Das geht jetzt schon. Du gibst die exe- und ini-Files, sowie event. das Hintergrundbild mit. Die installierst Du irgendwo anders und alles läuft sofort :)
:
Bearbeitet durch User
Angehängte Dateien:
-
56000BAUD.JPG
190 KB -
19200BAUD.JPG
190 KB -
ohneProgramm.JPG
190 KB
Ich muss leider jetzt auch nochmal ein Problem berichten: Haben das Programm mal so im Hintergrund laufen lassen (mit meinem kleinen Photodioden Projekt) und dann weiterprogrammiert. Wunder ich mich irgendwann warum das denn so ruckelt. Programm ausgemacht -> läuft wieder flüssig. Das Programm kann scheinbar mit der hohen Baudrate nicht umgehen. Die Bilder sagen wahrscheinlich einiges... Mein ATMega8 schickt ~ 20 Werte/s. Mit einer BAUD von (wieder) 19200 ist es dann "normal", zwar immer noch ~20% Auslastung aber das ist in Ordnung. Hoffe das hat einen Programmierfehler Hintergrund... :) MFG Renixor
@ Leonard S. Deine Programmversion hatte noch Probleme. Mit meiner aktuellen Version liegt die Prozessorauslastung des PC bei kontinuierlicher Übertragung mit 115200 Baud und 5 Instrumenten bei 3%.
Das ist ja Super ! ;) Dann ist ja alles in Butter..
Habs gerade mal mit dem Logic-Analyzer angeschaut. Zur Zeit schaffe ich mit einem ATMega328 und 115200 Baud durchschnittlich 700 Messwerte/s (incl. Protokol). Die stellt meine Software ohne ohne zu mucken dar.
:
Bearbeitet durch User
Das klingt ja gut :) Glaube man braucht selten 700 Werte/s ;)
Leonard S. schrieb: > Das klingt ja gut :) Glaube man braucht selten 700 Werte/s ;) Es komm ja noch eine Trendanzeige hinzu, die darf dann was schneller beaufschlagt werden :) Aber im Prinzip hast Du recht, mit zu hoher Updaterate lastet man nur den MC zu stark aus. Da muss man eben abwägen. Ich wollte nur mal schauen was mit meinem Protokoll so geht. Beschränkt man die Messwerte auf Integer, kommt man locker über 1000 Messwerte/s.
Ja sehe ich genau so. Bei mir würden auch 10 Werte/s reichen und das ist ja wenig... Kommt immer aufs Projekt an. EDIT: Wann glaubst du kommt die nächste Version raus ? ;)
:
Bearbeitet durch User
Leonard S. schrieb: > EDIT: Wann glaubst du kommt die nächste Version raus ? ;) Ich hoffe diese Woche noch, kanns aber nicht versprechen.
Angehängte Dateien:
-
SerialComInstruments_12.jpg
590 KB
Nochmal was mit dem Hintergrundbild rumgespielt. Dabei hat sich rausgestellt, dass die Instrumenten-Darstellung weitere Eigenschaften braucht, insbesondere bei den Zusatztexten und Schriftfarbe. Das Ergebnis sieht jetzt wie oben aus.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComInstruments_20.jpg
360 KB -
SerialComInstruments_21.jpg
250 KB
Hier gibt es die Version 0.22 zum Testen. Erstaunlich was Delphi bei dem doch inzwischen schon umfangreicherem Projekt für kleine exe-Dateien zaubert. Nach Entpacken nur ca. 1,3 MB.
:
Bearbeitet durch User
Angehängte Dateien:
-
terminal.jpg
170 KB -
neueAnzeige.jpg
76 KB
Ich habe natürlich ;) gerade eben getestet, Ergebnis:
Ich habe nur ein kleines Problem gefunden :D, und zwar ist es mir nicht
möglich die substeps einzustellen. Wenn ich sie änder und auf
"zuweisen+Show" klicke passiert gar nix. Sieht man auch oben im Bild
"neueAnzeige.jpg", bei #1 stehen die substeps auf 5, bei #2 auf 2. Bei
beidem habe nicht ich die Werte gemacht, sie waren einfach da.
Ansonsten: Wirklich klasse Arbeit! Man kann jetzt alles schön gestalten
und mit dem Hintergrundbild sieht man direkt was wofür ist. Das
Hintergrundbild hab ich nicht getestet, da ich kein passendes hatte.
Alle anderen Fehler wurden behoben und das Terminal ("terminal.jpg") ist
auch gut lesbar.
Ich denke das Projekt wird was!
MFG Renixor
//EDIT: Fast vergessen, dabei ist das ja so wichtig: Wie du gesagt hast,
Prozessor-Auslastung bei ~3%: Als wär dein Programm gar nicht da :). Bin
jetzt auch zurück zur 56000 BAUD. Klappt wunderbar.
:
Bearbeitet durch User
Albert M. schrieb: > Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen. Wo hast die denn runtergeladen?
Grafiksucher schrieb: > Albert M. schrieb: >> Die ganzen Grafikelement kann man sich für 5,95 Euro im Web runterladen. > Wo hast die denn runtergeladen? http://www.iconshow.de/shop/show_product.php?products_id=137 und hier kann man sich online eine Hintergrundschematik erstellen. Anschliessend kopieren oder Screenshot, in png umwandeln und in mein Programm laden: http://www.engineeringtoolbox.com/p-id-drawing-d_1639.html und hier gibt es ein passendes gratis DrwaingTool als Starteredition: http://www.serif.com/int/de/freedownloads/free-graphic-design-software/ Damit habe ich mein Hintergrundbild erzeugt. Leonard S. schrieb: > Ich habe nur ein kleines Problem gefunden :D, und zwar ist es mir nicht > möglich die substeps einzustellen. Wenn ich sie änder und auf > "zuweisen+Show" klicke passiert gar nix. Danke für's Testen. Fehler ist behoben. Korrigierte Programmversion anbei :)
:
Bearbeitet durch User
WoW, dass ging ja schnell :) Getestet und funktioniert. Alles gut jetzt denke ich :) Freue mich schon auf die nächsten Instrumente ;) MFG Renixor
Angehängte Dateien:
-
SerialComInstruments_22.jpg
370 KB
Was haltet ihr von der Implementation einer Realtime 3-D Anzeige? 3 von einander anhängige Messwerte können so dargestellt werden. Das ganze lässt sich mit der Mouse drehen und von allen Seiten betrachten. Oder geht da jetzt der Spieltrieb mit mir durch :) Funktionsfähige Demo wie so was aussehen könnte anbei.
:
Bearbeitet durch User
Mhh einen gute Frage. So auf Anhieb fällt mir nichts wirklich ein wofür man das gebrauchen könnte. Höchstens sowas wie ein Regensensor, der den Niederschlag auf einer bestimmten Fläche so anzeigt.. Albert M. schrieb: > 3 von einander anhängige Messwerte können so dargestellt werden. Dann wäre das doch nur ein einzelner Punkt im Koordinaten System !? Also müsste der µC mehre Koordinaten setzten. Ich denke das ist dann doch schon eher Spielerei ;) MFG Renixor
Außerdem müsste man dann ein eigenes Protokoll für das Modell einführen. So ala #px100y250z300< könnten man einen Punkt setzten.(beispiel)
Renixor schrieb: > Außerdem müsste man dann ein eigenes Protokoll für das Modell einführen. > So ala #px100y250z300< könnten man einen Punkt setzten.(beispiel) Nein - wieso denn? Das 3-D Instrument bekommt 3 freie Kanäle zugewiesen, z.B. #70, #71, #72. Das ist schon alles und zeigt wie flexibel mein simples Protokoll ist :)
:
Bearbeitet durch User
Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8) Und angenommen #70 == X #71 == Y #72 == Z Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32. Verstehe noch nicht ganz wie das gehen soll
Renixor schrieb: > Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8) > Und angenommen #70 == X #71 == Y #72 == Z > Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32. > Verstehe noch nicht ganz wie das gehen soll Richtig angefangen, falsch gefolgert. Die drei Kanäle repräsentieren die XYZ-Koordinaten. Dass der Prozessor dann auch diese drei Punkte schicken muss, ist ja keine Frage des Anzeigeprogramms, sondern der Firmware :)
Renixor schrieb: > Ja aber wenn man z.b. 3 Punkte hat P(12|24|32) P'(1|9|16) P''(32|16|8) > Und angenommen #70 == X #71 == Y #72 == Z > Dann müsste ja #70 3 Werte gleichzeitig haben, nämlich 12,1,32. > Verstehe noch nicht ganz wie das gehen soll Denk noch mal drüber nach. Die Kanäle #70, #71, #72 representieren doch bereits den kompletten Datensatz. Also: Du schickst jeweils EINEN Messwert an die drei Kanäle. X > #70, Y > #71, und Z nach #72. Dann wird intern die 3-D Grafik upgedatet. Fertig.
Albert M. schrieb: > Denk noch mal drüber nach. Die Kanäle #70, #71, #72 representieren doch > bereits den kompletten Datensatz. Also: > Du schickst jeweils EINEN Messwert an die drei Kanäle. X > #70, Y > #71, > und Z nach #72. Dann wird intern die 3-D Grafik upgedatet. Fertig. Bin ich gerade zu Doof dafür?! Die drei Kanäle haben dann nur einen Wert -> ein Punkt. Also muss man mehrere Punkte schicken. Also hat dann jeder Kanal mehere Werte.
Renixor schrieb: > Also muss man mehrere Punkte schicken. Also hat dann jeder Kanal mehere > Werte. Klar, für ein Diagramm braucht es natürlich x*y*z Datensätze.
Habs nun verstanden :) Hast Recht: Funktioniert so mit den Kanälen. Also an sich ein Nice-to-have aber nicht zwingend notwendig. MFG Renixor
Super Projekt, hat potential uns sieht echt genial aus... Mir fällt gerade noch eine kleine Idee ein, bin mir nur nicht sicher ob das sinnvoll wäre: Bei einer MC Berechnung haben ich den Wert 3540 welcher eine Spannung oÄ. repräsentiert (zB. 3,540V). Diese Zahl ist aber nicht der Endwert, mit dem wird weitergerechnet. Will ich diesen Wert nun aber korrekt darstellen müsste ich ihn erst in eine Fließkommazahl umwandeln, was verschwendete Rechenleistung wäre. Könnte man nun im Tool einen Skalierungsfaktor angeben (*0,001) dann kann ich die Zahl einfach Übertragen, die Software stellt aber die Korrekte Spannung von 3,540V dar. Hoffe das war verständlich, evtl ist das ja sinnvoll?
Seh ich auch so. Momentan rechne ich den ADC *4.883 also auch Kommazahl. Momentan nicht schlimm, da der nix anderes macht aber wäre natürlich einfacher und besser.
Basti schrieb: > Könnte man nun im Tool einen Skalierungsfaktor angeben (*0,001) dann > kann ich die Zahl einfach Übertragen, die Software stellt aber die > Korrekte Spannung von 3,540V dar. Ja, ein Skalierungsfaktor ist sinnvoll und wird bei der nächsten Version berücksichtigt.
Albert M. schrieb: > Ja, ein Skalierungsfaktor ist sinnvoll und wird bei der nächsten Version > berücksichtigt. Super, freut mich wenn ich was beitragen konnte :) Eine weitere Idee wäre evtl eine Vorschau beim Einstellen des Instruments zwecks Größe und so. Damit man nicht immer auf Zuweisen+Show klicken muss, um dann festzustellen Farbe oder Größe sind noch nicht zufriedenstellen. Dann wieder zu Instrumente, das passende anwählen und ändern...
Basti schrieb: > Eine weitere Idee wäre evtl eine Vorschau beim Einstellen des > Instruments zwecks Größe und so. Muss ich mal sehen. Allerdings kann das aus Platzgründen bei sehr hohen oder sehr breiten Instrumenten schwierig werden. Ich probiers aber mal aus.
Also ich denke das ist nicht sooo wichtig, da man ja meist eh nur 1x einrichtet und das dann speichert. z.b. für mein kleines Photodioden Projekt hat sich 300x900 als "Standardgröße" herausgestellt. Ich denke es wird einfach viel Arbeit bleiben das einzurichten (wenn man fast alles benutzt) da wird man nicht drum rum kommen, deshalb gibts ja ne Speicherfunktion. Allerdings weis man mit der Zeit auch was gut ist und was nicht so.. MFG Renixor
Nett. Eine Frage: Ich kann den Reiter (Momentanwert) nicht verschieben auf einer Skala. Ist das noch nicht drin? Die neue Position sollte ja an den MC geschickt werden.
Abdul K. schrieb: > Nett. Eine Frage: Ich kann den Reiter (Momentanwert) nicht verschieben > auf einer Skala. Ist das noch nicht drin? Die neue Position sollte ja an > den MC geschickt werden. Versteh ich jetzt nicht. Das sind ANZEIGE-Instrumente, mit denen wird nichts zum MC geschickt. Regler-Elemente, Taster und Eingabeboxen um irgendwas zum MC zu schicken sind einer späteren Version vorbehalten. Die einzige Möglichkeit zur Zeit was zum MC zu schicken ist über das integrierte Terminal. Zuerst muss mal mit den Anzeige-Instrumenten alles perfekt sein. Dann schauen wir weiter :)
:
Bearbeitet durch User
Hi Albert! Ja, das klingt nach nem netten Projekt... Is vlt. schon bisschen spät das noch zu erwähnen, aber das ganze GUI-Gedöns gibts fertig und ausführlichst getestet für lau (opensource), ist portabel (Linux, Windows, Mac, BSD, ...). Die Oberfläche lässt sich in paar Minuten mit https://glade.gnome.org/ zusammenclicken und mit so gut wie jeder Programmiersprache mit Leben füllen. Nachteil: Standardmässig fehlt einiges, was auf ner virtuellen Frontplatte öfter mal gebracht wird, z.B. runde Potiknöppe oder diese alten Zeigerinstrumente. Da ist aber etliches im Netz zu finden und wenn wirklich mal was fehlt, lässt es sich sehr einfach programmieren und einbinden, weil GTK vorbildlich objektorientiert ist. Beispiel: https://developer.gnome.org/gtk-tutorial/2.22/x2310.html
glade sieht für mich nur aus wie ein Template-Editor. Kann das noch mehr? Für die Anzeige von physikalischen Meßwerten brauch es ja doch noch etwas Logik im Hintergrund! Ich habs aber auch nur kurz überflogen. Template-Editor gabs vor 20 Jahren schon auf dem Apple Newton und vermutlich schon früher, denn Apple greift meist nur günstige Strömungen anderer auf. @Albert: OK, die Sendefunktion gibts also noch nicht. Ich muß aber nochmal drauf rumhacken, bevor es in die falsche Richtung läuft: Willst du das Senden als weitere Anzeigeobjekte definieren oder integral in den bereits vorhandenen? Wie gesagt, der Anzeige-Leveller soll dem Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein. Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird dann an den MC geschickt. Im Prinzip könnte man so auch die Voreinstellungen realisieren. Also das Programm schickt diese Werte einmal beim Programmstart an den MC.
Angehängte Dateien:
-
test.JPG
140 KB
Zu Lutz M. Beitrag: Hab mir das Ding mal runtergeladen: Ist ein Installer -> Installiert unter dem Standard Pfad. Dann Installer geschlossen auf Desktop geguckt : NIX! In den Installationsordner (appdata/local/) rein: auch nix, erst im 'bin' Ordner wird man fündig. Also Programm gestartet, und mal versucht irgendwas auf die schnelle hinzubekommen. Fehlanzeige: Nach 15min hat ich das Bild im Anhang zustande gebracht und dann aufgegeben. Ich muss anmerken das die Buttons keinerlei Funktion aufweisen. Ich denke dieses Programm ist vieeeeeel zu komplex, man wird sehr viel Zeit brauchen um sich da zurecht zu Finden und eigentlich ist es am Thema vorbei. So wie ich das verstanden hab muss man da auch erst selbst irgendwas Programmieren damit die Buttons ne Funktion bekommen. Also ich ziehe diesem Programm die SerialComInstruments vor.
:
Bearbeitet durch User
Lutz M. schrieb: > GUI-Gedöns gibts fertig und ausführlichst getestet für lau (opensource), > ist portabel (Linux, Windows, Mac, BSD, ...). Die Oberfläche lässt sich > in paar Minuten mit > https://glade.gnome.org/ > zusammenclicken und mit so gut wie jeder Programmiersprache mit Leben > füllen. Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi programmiere. Was soll ich da mit fremden Oberflächen-Templates? Das alles ist in Delphi mehr als genügend vorhanden. Und im übrigen ist die Bedienoberfläche bei diesem Projekt das geringste aller Probleme. Abdul K. schrieb: > OK, die Sendefunktion gibts also noch nicht. > Ich muß aber nochmal drauf rumhacken, bevor es in die falsche Richtung > läuft: >Wie gesagt, der Anzeige-Leveller soll dem > Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein. > Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den > Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird > dann an den MC geschickt. Ein Einsteller der dem Messwert folgt ist nicht sinnvoll. Wenn Du den eingestellt hast, folgt er ja danach sofort wieder dem Messwert. Wie willst Du denn damit was einstellen und die vorgenommene Einstellung auch sehen? Du kannst (wenn es denn mal implementiert ist) einen Regler mit der selben Skalierung nebem der Messwertanzeige plazieren und an diesem die Einstellung vornehmen. Dann siehst Du wenigsten was Du eingestellt hast.
Wenns wirklich nur ein Template-Editor ist, dann müßtest du die Buttons DANACH mit Funktion (Programmcode) füllen. Das Template erzeugt einfach nur die GUI-Basiselemente, Anordnung, Default-Zustand usw. durch grafisches Geschubse. Irgendwo in dem Programm wirds ne Funktion zur Erstellung des fertigen Templates geben. Das ist dann der Rumpf deines Programms. Delphi wird sowas genauso haben und Albert eben den eigentlichen Code einfügen.
Albert M. schrieb: >> Wie gesagt, der Anzeige-Leveller soll dem >> Meßwert folgen und (mir wegen optional aktivierbar) auch dragbar sein. >> Zeigt der Heizkessel z.B. 80°C Wassertemperatur an, dann möchte ich den >> Zeiger einfach mit der Maus auf 60°C ziehen können und dieser Wert wird >> dann an den MC geschickt. > > Ein Einsteller der dem Messwert folgt ist nicht sinnvoll. Wenn Du den > eingestellt hast, folgt er ja danach sofort wieder dem Messwert. Wie > willst Du denn damit was einstellen und die vorgenommene Einstellung > auch sehen? Du meinst es ergibt sich ein Zustand, der nicht logisch ist? Sehe ich anders. Der MC bekommt ja nur dann Strings gesendet, wenn ich was ändere. Änderungen sind aber nun nur: 1. Ich schiebe wie beschrieben den Leveller auf einen anderen Wert. Und lasse dort die Maus los. 2. Das Programm wird gestartet und überträgt alle Voreinstellungen an den MC. Der Trigger, den du implementieren müßtest, ist das Loslassen der Maustaste. Auf der anderen Seite haben wir den MC, auch der muß dem Zustand des Programms folgen können: Sobald er einen String vom PC bekommt, übernimmt er diese Einstellung als Vorgabe (Das ist nicht der Meßwert). Letztlich überschreibt er nur den ersten Wert, der aus der Zeit stammt als das Programm auf dem PC startete und die Startwerte schickte. Was nun wenn der PC sich nie oder nicht mehr meldet? Dann sollte der MC autonom die Regelung aufrechterhalten. Das kann er, denn er hat die Startwerte vom PC und wenn die nicht kamen, eben die eigenen Startwerte aus seinem Flash. Danach sendet der MC einfach weiter seine aktuellen Meßwerte. > Du kannst (wenn es denn mal implementiert ist) einen Regler mit der > selben Skalierung nebem der Messwertanzeige plazieren und an diesem die > Einstellung vornehmen. Dann siehst Du wenigsten was Du eingestellt hast. Da sind wir ja fast einer Meinung. Damit man Vorgabe und Meßwert unterscheiden kann als Anwender, könnte man die Leveller mit unterschiedlicher Helligkeit zeichnen. Ich gehe mal davon aus, daß man die Farbe irgendwann selbst definieren kann. Beim Heizkessel-Beispiel würden also beide Leveller solange übereinander liegen, solange es keine vorherige Voreinstellung gab (also z.B. der float ist gleich NAN oder NIL wars wohl in Pascal). Das heißt der Vorgabe-Leveller folgt immer den aktuellen Meßwert-Leveller mit. Sobald eine Vorgabe erfolgt ist (Eben in dem die Maus mal losgelassen wurde) bleibt der Vorgabe-Leveller stehen. Der Meßwert-Leveller wird ja nur vom MC in seiner Position bestimmt. Falls die Regelstrecke im MC-Part funktioniert, wird dieser sich also dem dem Vorgabe-Leveller immer weiter nähern. Bis dann bei voller Ausregelung der Vorgabe-Leveller hinterm Meßwert-Leveller optisch verschwindet. Hört sich komplizierter an als es zu programmieren ist. Ich finde das deutlich eleganter als zwei Skalen nebeneinander auf einer eh beschränkten Monitorfläche.
Es gibt dafür ne ganz m.M.n elegante Lösung: Im ersten Post hier in dem Bild dort sind auch zwei Regler, die nicht einen sondern zwei Pfeile haben. Da nimmt man einen als schiebbaren Regler (edit: welcher auch deaktiviert werden kann) und der andere folgt dann ja. z.b der Rechte. Den schiebt man hoch, der µC erhält neue Werte und ändert so auch den Linken bis sie wieder auf gleichem Level währen. Sieht dazu bestimmt auch Cool aus ;) MFG Renixor
:
Bearbeitet durch User
Das zweite Panel von rechts könnte sowas sein. Stimmt.
Neue Version 0.23 verfügbar. Änderungen: - Zu jedem Instrument kann ein Skalierungsfaktor zugewiesen werden.
:
Bearbeitet durch User
Funktioniert an sich, allerdings würde ich mit mehr als 1 Nachkommastelle wünschen. Momentan geht nur 4,9 aber exakt wären es z.b 4,883. Das Programm sollte auch damit noch Rechnen können. :) MFG Renixor
Leonard S. schrieb: > Funktioniert an sich, allerdings würde ich mit mehr als 1 > Nachkommastelle wünschen. Momentan geht nur 4,9 aber exakt wären es z.b > 4,883. Das Programm sollte auch damit noch Rechnen können. :) Das funktioniert schon so wie es soll. Für die Anzahl der Nachkommastellen gibt es die Eingabe unter "Format Skala". Versuch es da z.B. so: ##0.000 gibt 3 Nachkommastellen aus ##0 gibt keine Nachkommastelle aus
:
Bearbeitet durch User
Nein, dass meinte ich nicht. Bei dem Feld "Skalierung" kann man nur Zahlen mit einer Nachkommastelle eingeben. Gibt man dort z.b 4,883 ein, rundet das Programm automatisch auf 4,9.
Ist korrigiert, anbei Version 0.23a Änderungen: - Zu jedem Instrument kann ein Skalierungsfaktor zugewiesen werden. - Fehler in Zahlenformaten behoben
Super, kanns aber heute ich mehr testen :) Gutes Nächtle, Renixor
Albert M. schrieb: > Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi > programmiere. Deshalb hab ich mit "Is vlt. schon bisschen spät das noch zu erwähnen, aber..." angefangen, weil ich nämlich gelesen hab, dass Du schon mit einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht mehr auf ein besseres umstellen möchtest.
Lutz M. schrieb: > dass Du schon mit > einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht > mehr auf ein besseres umstellen möchtest. Darüber lässt sich Streiten ;) Komplexer != Besser
Abdul K. schrieb: > Wenns wirklich nur ein Template-Editor ist, dann müßtest du die Buttons > DANACH mit Funktion (Programmcode) füllen. Das Template erzeugt einfach > nur die GUI-Basiselemente, Anordnung, Default-Zustand usw. durch > grafisches Geschubse. Korrekt. Nur die Bezeichnung "Template-Editor" find ich etwas komisch, nennen wirs doch lieber "GUI-Designer" oder so... > Irgendwo in dem Programm wirds ne Funktion zur > Erstellung des fertigen Templates geben. Das ist dann der Rumpf deines > Programms. So wars früher mal, inzwischen spuckt das Ding nur noch ne XML-Datei aus, die dann (wie gesagt, in praktisch jeder Programmiersprache) mit 1 Befehl reingesaugt und umgesetzt werden kann. > Delphi wird sowas genauso haben und Albert eben den eigentlichen Code > einfügen. Was bei Delphi/Kylix m.W. nicht dabei ist: die Sourcen vom GUI-Editor. Den würde ich nämlich hacken wollen, um das ganze überflüssige Zeugs raus- und fehlendes (z.B. LED-Anzeigen) reinzubauen.
Lutz M. schrieb: > Albert M. schrieb: >> Wenn Du mitgelesen hättest, wäre Dir aufgefallen, dass ich in Delphi >> programmiere. > > Deshalb hab ich mit "Is vlt. schon bisschen spät das noch zu erwähnen, > aber..." angefangen, weil ich nämlich gelesen hab, dass Du schon mit > einem weniger guten Werkzeug losgelegt hast und jetzt vermutlich nicht > mehr auf ein besseres umstellen möchtest. Sorry, aber Du fällst für mich in die Kategorie "Ich will auch mal was in die Diskussion einwerfen". Es ist das Tool für mich das Beste, in dem ich firm bin und das mir hilft die Aufgabe am schnellsten zu lösen. Ich arbeite an meinem Projekt jetzt gerade mal 2 Wochen und das auch nur ab und an stundenweise. Mit den von Dir propagierten Oberflächentemplates wärst Du noch nicht mal ein Viertel soweit wie ich. Und wie willst Du mit Deinen Templetes die visuellen Instrumente erzeugen? Alles ziemlicher Dummschwatz. Und im übrigen solltest Du nicht über Programmiertools wie Delphi urteilen, von denen Du ganz offensichtlich nicht den geringsten Schimmer hast.
Leonard S. schrieb: > Darüber lässt sich Streiten ;) > > Komplexer != Besser Aber: Universeller = Besser ;)
Lutz M. schrieb: > Aber: Universeller = Besser ;) Nur was bringts einem, wenn man DIE Eierlegende-Woll-Milch-Sau hat, es aber Stunden dauert bis man auch nur zu einem kleinem Ergebnis kommt?
Die schlichte Antwort ist, wieviel Stunden hats am Ende insgesamt gedauert.
Features der nächsten Version: - Redesign des User-Interface Verschieben und Grösseneinstellung mit der Mouse - Interaktion mit dem Mikrocontroller über zuweisbare Buttons, d.h. Befehle senden (später auch Schieberegler und Eingabefelder)
Schön. Wann kommt sie denn Vorraussichtlich raus ? :) MFG Renixor
@ Renixor Schön, dass Du Dich noch für mein Projekt interessierst. Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum eigentlichen Thema passende Posts aussen vorlässt. Daher ist wohl die Veröffentlichung weiterer Versionen nicht so dringlich. Was bei mir bereits alles funktioniert, aber noch nicht vollständig ausgetestet ist: - Trendanzeige mit bis zu 4 Kanälen - Drehzeigerinstrumente - Schieberegler, Befehlsbuttons und Eingabefelder - math. Formelparser für frei zuweisbare Funktionen - PID-Regler (verlangt bisher jedoch zeitäquidistante Werte) - diverse verschiebbare Teil-Hintergründe wie Umrandungen, Pfeile, Linien, Kessel und animierte Bitmaps (in Abhängigkeit vom Wertezustand) Ob ich das allerdings noch veröffentliche weiss ich nicht, meine Motivation dazu wird ehrlich gesagt immer geringer.
Albert M. schrieb: > @ Renixor > Schön, dass Du Dich noch für mein Projekt interessierst. > Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum > eigentlichen Thema passende Posts aussen vorlässt. > Daher ist wohl die Veröffentlichung weiterer Versionen nicht so > dringlich. Naja, ich denke es gibt schon noch mehr Leute als mich, denen das gefällt, schau einfach mal den Thread durch..(Vorallem so Mittig/weiter oben sprechen sich doch einige FÜR die Idee aus.) ;) Außerdem wäre der Thread hier nicht so lang wie er jetzt ist(und das auch noch mit sinnvollen Beiträgen!), würde es niemanden Interessiern. Die Veröffentlichung/das Projekt ist natürlich komplett dir überlassen. Albert M. schrieb: > Was bei mir bereits alles funktioniert, aber noch nicht vollständig > ausgetestet ist: > - Trendanzeige mit bis zu 4 Kanälen > - Drehzeigerinstrumente > - Schieberegler, Befehlsbuttons und Eingabefelder > - math. Formelparser für frei zuweisbare Funktionen > - PID-Regler (verlangt bisher jedoch zeitäquidistante Werte) > - diverse verschiebbare Teil-Hintergründe > wie Umrandungen, Pfeile, Linien, Kessel > und animierte Bitmaps (in Abhängigkeit vom Wertezustand) Das ist ja schon wieder ne ganze Menge. Wenns ums Testen geht, kannste es mir auch gerne mal so schicken.
Ich habe auch Interesse. Bin aber leider mit meiner Testumgebung noch nicht so weit.
Auch ich bin noch da, als stiller mitleser... ;)
Grafiksucher schrieb: > Bin aber leider mit meiner Testumgebung noch nicht so weit. Das ist ja das schöne daran: Man braucht nur nen µC und nen Pegelwandler, UART-Libs gibts im Internet oder einfach selber schreiben und dann noch die Funktion von mir (weiter oben), die man auch easy selber schreiben kann und ab gehts.. Da ich UART Header schon habe für z.b den Mega8 musste ich nur die Funktion schreiben und schon war meine 'Testumgebung' fertig :)
Ich finde dieses Projekt auch erste Sahne! Bitte mache weiter, das ist genau das was ich benötige. Leider bin ich noch beim Layouten meiner Hardware.
[x] sehr beeindruckend und defeinitiv interessant Das ist sowas wie INCA oder CANape in klein. Kann man auch Parameter verstellen?
Toll wäre es, wenn man die Anzeigeelemente einfach selber als Bitmaps hinterlegen kann. Du kopierst dann einfach diese Bitmaps übereinander. In die Länge ziehen ist ja auch kein Problem, damit man Balken bekommt. Wäre halt schön für den eigenen Style (Deine Elemente finde ich optisch überladen). Das ist natürlich für dich nur unangemessene Kritik. Damit behalte ich also damit recht, das das Interesse deinerseits bald einschlafen wird. Vielleicht hilft Geld. Dann aber muß es schon richtig fertig sein.
Abdul K. schrieb: > Toll wäre es, wenn man die Anzeigeelemente einfach selber als Bitmaps > hinterlegen kann. Du kopierst dann einfach diese Bitmaps übereinander. > In die Länge ziehen ist ja auch kein Problem, damit man Balken bekommt. > Wäre halt schön für den eigenen Style (Deine Elemente finde ich optisch > überladen). Steht ja schon bereits hier (wenn auch nicht weiter erklärt): Albert M. schrieb: > Was bei mir bereits alles funktioniert, aber noch nicht vollständig > ausgetestet ist: > - diverse verschiebbare Teil-Hintergründe Abdul K. schrieb: > Das ist natürlich für dich nur unangemessene Kritik. Damit behalte ich > also damit recht, das das Interesse deinerseits bald einschlafen wird. Nö, das ist keine unangemessene Kritik, da es sich im Gegensatz zu vielen anderen Beiträgen hier tatsächlich auf mein Projekt bezieht. Und zu dem zweiten Satz sag ich jetzt mal garnichts ...
:
Bearbeitet durch User
Karl schrieb: > [x] sehr beeindruckend und defeinitiv interessant > Das ist sowas wie INCA oder CANape in klein. > Kann man auch Parameter verstellen? Lade Dir einfach die letzte Version runter und spiel damit. Für die Zeigerinstrumente lassen sich die wichtigsten Parameter verstellen. Wenn Du aber damit die Kommunikation vom PC zu MC meinst, so kommt das in den nächsten Versionen.
Meinte damit, dass man vom PC aus Parameter auf dem µC verstellen kann. Z.B. die Filterkonstante von einem PT1. Zur Laufzeit natürlich.
In der hier veröffentlichten Version ist das noch nicht möglich, aber Albert M. hat ja schon geschrieben, dass es in seiner schon geht. Schau einfach ein Stück weiter oben, da stehts.
Wie gesagt, kommt in den nächsten Versionen (auch als Eingabebox für numerische oder alphanumerische Werte). Testen kannst Du das aber jetzt schon, indem Du im integrierten Terminal die Eingabebox benutzt und auf SendString klickst (impliziert, dass der Wert als String gesendet wird).
Albert M. schrieb: > @ Renixor > Schön, dass Du Dich noch für mein Projekt interessierst. > Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum > eigentlichen Thema passende Posts aussen vorlässt. > Daher ist wohl die Veröffentlichung weiterer Versionen nicht so > dringlich. > Ob ich das allerdings noch veröffentliche weiss ich nicht, meine > Motivation dazu wird ehrlich gesagt immer geringer. Bitte weitermachen! Ich verfolge das Projekt ebenfalls sehr aufmerksam und finde es beachtlich, mit welcher Geschwindigkeit sich das hier entwickelt hat. In den meistens Threads hier wird sonst ewig diskutiert, wie man [Beliebiger Projektname] am besten realisiert, aber du sorgst dafür, dass auch mal etwas fertig wird!
Auf jeden Fall ein super Projekt. Ich fände es praktisch wenn du noch einen kleinen Graphen integrieren könntest.
Hab gerade mal probiert. Mangels Windows unter Linux+Wine. Startet, allerdings lässt sich keine serielle Schnittstelle auswählen (ja, Wine emuliert die und das funktioniert mit anderen Programmen.) Weiterhin bekomme ich nur die "Vertikal Meter" unter "instrumente" klickbar. Der Rest bleibt stumm. Hast Du Interesse an Linux+Wine-Unterstützung?
Simon L. schrieb: > Ich verfolge das Projekt ebenfalls sehr aufmerksam und finde es > beachtlich, mit welcher Geschwindigkeit sich das hier entwickelt hat. In > den meistens Threads hier wird sonst ewig diskutiert, wie man > [Beliebiger Projektname] am besten realisiert, aber du sorgst dafür, > dass auch mal etwas fertig wird! Als ich noch im Beruf stand habe ich gelernt Dinge zu organisieren und auf den Punkt zu bringen. Kannst ja hier mal schauen was ich so gemacht habe: http://www.natur-mg.de/Myself.html Damit habe ich es geschaft seit 1992 nicht mehr zu arbeiten. Ich glaube, damit ist auch meine Aversion gegen Labertaschen und Dummschwätzer verständlich. Alles was Du hier so siehst betreibe ich ab und an als Hobby. Übrigens ich sehe, dass Du Amateurfunker bist. Damit liebäugele ich auch schon einige Zeit und ich glaube ich gehe das mit meinen 63 Jahren auch noch an :) Und danke, dass Dir mein Projekt gefällt.
:
Bearbeitet durch User
Simon L. schrieb: >> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum >> eigentlichen Thema passende Posts aussen vorlässt. Nene, da gibts noch mehr :) Wir sind die stillen Mitleser. Aber momentan mangelt es an Zeit.
Martin Schwaikert schrieb: > Simon L. schrieb: >>> Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum >>> eigentlichen Thema passende Posts aussen vorlässt. > > Nene, da gibts noch mehr :) Wir sind die stillen Mitleser. Aber momentan > mangelt es an Zeit. Geht mir genauso. Ich lese auch mit und über lege schon, ob und wie ich es im nächsten Projekt nutze. Mir gefällt das total gut, von daher: "Weiter so!"
Albert M. schrieb: > ... ziemlicher Dummschwatz. Jaja, scho recht... Ich hab dann mal ein kleines Alternativprojekt angefangen: Beitrag "Virtual uC Controlpanel" Wenn Du in der Lage (und vor allem willens) bist, einfach mal sachlich zu diskutieren, könnten wir ja mal versuchen, uns auf ein gemeinsames Protokoll für die serielle Schnittstelle zu einigen. Das fänd ich schon schick, wenn sich ein uC ohne umprogrammierung mit verschiedenen Oberflächen fernsteuern liesse.
:
Bearbeitet durch User
Hallo, ich habe gerade unter Windows 7 64-bit testen wollen und dabei bemerkt das die Menüpunkte im Menü "Datei" keinerlei Funktion haben. Sobald man das Programm beendet sind bisher getätigte Einstellungen verschwunden. Ist das so korrekt?
Lutz M. schrieb: > uns auf ein gemeinsames Protokoll Man könnte den Code auch so auslegen, das er einfach verschiedene Protokolle unterstützt, z.B. per Plugin ;-)
:
Bearbeitet durch User
Hallo Albert, die Programmidee finde ich auch sehr gut! Es ist echt selbsterklärend (wenn man etwa weiß, was es kann) und übersichtlich. Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit). Die Schnittstelle wird erkannt, ob auch was ankommt, hab ich noch nicht getestet. Was ich mir noch als weiteres Element vorstellen könnte ist ein Konsolenfenster, das man wie die Instrumente in die Anzeige legen kann, als Std-out quasi. Protokoll könnte entsprechend so aussehen: #100T"Fehler 1\n"< T als Text-Identifier (z.B.) Interressant wäre evtl. auch eine zweite Oberfläche, also "Show 1" und "Show 2" Edit: Wenns rund läuft, wäre das Programm doch auch was fürs AVR-Tutorial
:
Bearbeitet durch User
Alter Feind schrieb: > Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass > nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit). Das ist kein "Problem" ;) Weiter oben in den Changelogs ist ja beschrieben, dass diese Funktionen einfach noch nicht Implementiert sind. Kommen aber unter Umständen noch. Albert M. schrieb: > @ Renixor > Schön, dass Du Dich noch für mein Projekt interessierst. > Anscheinend bist Du aber der Einzige, wenn man mal die nicht zum > eigentlichen Thema passende Posts aussen vorlässt. > Daher ist wohl die Veröffentlichung weiterer Versionen nicht so > dringlich. Deshalb bin ich nicht 100% sicher ob da noch was kommt. Hoffe (und denke) ich aber schon, da es ja doch Interesse gibt. MFG Renixor
Hallo an alle, ich hoffe ebenfalls, daß du, Albert, noch an dem Threat weiterarbeitest. Da ich zur Zeit an einer Motorradzündung rumprogrammiere, wäre es toll den Tacho und den Drehzahlmesser als Rundinstrument zu haben. Und am Drehzahlmesser noch einen Schleppzeiger, der den Maximalwert für 2 Sekunden hält (RTL Formel 1 lässt grüßen). Zum Testen deines Programms habe ich ein kleines Arduino Programm geschrieben und es für die Allgemeinheit hier einmal angehängt. Ich würde mich freuen, wenn es mit dem Programm weitergeht. Viele Grüße gatsby
gatsby schrieb: > Zum Testen deines Programms habe ich ein kleines Arduino Programm > geschrieben und es für die Allgemeinheit hier einmal angehängt Schön. u.U kann man ja mal für "Noobs" im Programmieren eine kleine Art von Sammelung von Funktionen fürs setzten von Instrumenten in verschiedenen Sprachen erstellen. Wir hätten dann schon C und wenns dir möglich wäre dein Programm noch in ne handliche Funktion zu packen hätten wir auch Arduino.
Renixor schrieb: > Alter Feind schrieb: >> Das zuvor geschilderte Problem mit "Projekt Laden/Speichern" und dass >> nur Vertikalmeter auswählbar sind, besteht bei mir auch (Win7, 64bit). > > Das ist kein "Problem" ;) > Weiter oben in den Changelogs ist ja beschrieben, dass diese Funktionen > einfach noch nicht Implementiert sind. Kommen aber unter Umständen noch. Ok, sowohl unter Win7 32-bit als auch 64-bit haben alle Menüpunkte im Menü "Datei" noch keine Funktion. Ich bin fälschlicherweise davon ausgegangen das wenigstens der Menüpunkt "Datei Beenden" funktionieren müsste. Das er das nicht tut stand zumindest bis jetzt noch nicht in diesem Thread. Aber dennoch gibt es unter Windows 7 einen weiteren Bug. Man muss das Programm als Administrator ausführen. Tut man das nicht sind bei einem erneuten Start des Programms alle Daten weg.
Grafiksucher schrieb: > Ich bin fälschlicherweise davon ausgegangen das wenigstens der Menüpunkt > "Datei Beenden" funktionieren müsste. Das er das nicht tut stand > zumindest bis jetzt noch nicht in diesem Thread. Das stimmt ! Dachte ich auch, aber Albert hat wohl einfach diesen Menüpunkt schonmal erstellt, mehr auch nicht. Grafiksucher schrieb: > Aber dennoch gibt es unter Windows 7 einen weiteren Bug. Man muss das > Programm als Administrator ausführen. Tut man das nicht sind bei einem > erneuten Start des Programms alle Daten weg. Interessant. Danke für diesen Hinweis. Habe bis jetzt immer alles neu eingerichtet :S Wusste das noch gar nicht :D MFG Renixor
Sorry, wenn ihr im Moment nicht viel von mir hört. Aber wenn ich allen antworte, verzettele ich mich nur. Ich lese aber mit und nehme die Hinweise auf. Was die Admin-Rechte zum Ausführen des Programms angeht: Wenn man das Programm in einem neu erstellten Ordner (NICHT unter C:/Programme) speichert und ausführt braucht es eigentlich keine Admin-Rechte. Die ganzen Programm-Daten werden als ini-File zur Zeit in C:\Users\Anwender\AppData\Local gespeichert, wozu es auch keine Admin-Rechte braucht.
Albert M. schrieb: > Sorry, wenn ihr im Moment nicht viel von mir hört. Aber wenn ich allen > antworte, verzettele ich mich nur. Ich lese aber mit und nehme die > Hinweise auf. Also gehts hier noch weiter mitm Programm ! (?) MFG Renixor
Ich wollte auch mitteilen dass ich an dem Projekt interessiert bin. ;-) Gruß Eckard
Hallo Albert, sehr gute Arbeit Daumenhoch!!! Hast Du schon mal über ne Loggingfunktion nachgedacht? Sowas wie load/Save in txtDatei ; getrennt und im Programm rec/stop/play/rev/fwd... Dann könntest auch unbeaufsichtigt die Daten aufnehmen und später auch in Excel oder so auswerten. Grüße Rene
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.
Angehängte Dateien:
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
Angehängte Dateien:
-
watdas.JPG
23 KB
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)
Angehängte Dateien:
-
bild.JPG
120 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
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
Angehängte Dateien:
-
grafik.JPG
65 KB -
zuschnell.JPG
38 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
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
Angehängte Dateien:
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
Angehängte Dateien:
-
leds.JPG
12 KB
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!
Angehängte Dateien:
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.
Angehängte Dateien:
-
neu.JPG
14 KB
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 :)
Angehängte Dateien:
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
Angehängte Dateien:
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
Angehängte Dateien:
-
SerialInstruments.png
50 KB
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 ?
Angehängte Dateien:
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
Angehängte Dateien:
-
instr40.JPG
71 KB
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
Angehängte Dateien:
-
test.JPG
34 KB
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!
Angehängte Dateien:
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?
Angehängte Dateien:
-
Vorschlag1_2.PNG
19 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
-
Trend.JPG
88 KB
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
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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
Angehängte Dateien:
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.
Angehängte Dateien:
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
Angehängte Dateien:
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
Angehängte Dateien:
-
Screen04.png
71 KB -
Screen033.png
77 KB
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
Angehängte Dateien:
-
Screen04.png
72 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
-
HandyTasten.png
16 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
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!
Angehängte Dateien:
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
Angehängte Dateien:
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_
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
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.
Angehängte Dateien:
-
FFT_fuer_Version_0.43.jpg
180 KB
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
Angehängte Dateien:
-
FFT2_fuer_Version_0.43.jpg
290 KB -
FFT3_fuer_Version_0.43.jpg
240 KB -
FFT4_fuer_Version_0.43.jpg
250 KB
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
Angehängte Dateien:
-
Neue_Version.JPG
180 KB
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
Angehängte Dateien:
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.
Angehängte Dateien:
-
Bild_1.png
190 KB -
Bild_2.png
24 KB -
Bild_err.png
44 KB
>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
Angehängte Dateien:
-
instruments.jpg
27 KB -
terminal.jpg
66 KB -
config.jpg
70 KB
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.
Albert M. schrieb: > 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. Wo ist das Problem? Wenn du das so schreibst und der gewerbliche macht es trotzdem dann ist das sein Problem. Egal was du einbaust. Er kann es ja nicht erwerben. > > Zur Zeit habe ich weder Lust noch Motivation für dieses Projekt. Das mag > sich auch wieder ändern. Die Autoren von Logview haben das ihre Software als Donationware veröffentlicht. Vielleicht ist es ja auch für dich eine Möglichkeit. > Da sich eh nur eine handvoll Leute interessiert, Also ich finde das was du machst richtig Klasse, verfolge das auch aber man kann nicht alles auf einmal machen. > 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, Die kannst du hier nur an den downloads sehen. Die sind doch ganz ordentlich. > habe > ich meine Prioritäten erst mal auf meine anderen Hobbies verlagert. Schade
Das Internet ist wie die meisten modernen Medien hauptsächlich ein Monolog mit lauter lautlos mithörenden Agenten drumherum ;-) Du weißt nie wieviele Leute sich dafür wirklich interessieren. Die Downloadzahlen und deine erwhnten Firmenanfragen geben dir aber Hinweise. Ich sehe auch kein Problem für dieses Programm pro Nutzer 10 Euronen zu verlangen und auch zu bekommen. Würde ich auch zahlen, wenn ich es bräuchte. Das würde ich bei den erwarteten Stückzahlen gleich netto 10 Euro/h setzen. Ist doch nicht schlecht. Du stößt mit dieser Software in eine klaffende Lücke.
Hallo Albert, ich wäre ebenfalls bereit für eine Programmversion mit erweiterten Funktionen einige Euronen aufzuwenden. Wie ich schon mehrfach betonte, mit vielen unterschiedlichen Instrumenten und Sollwerteingaben, auf dem jetzigen Stand des Programms und ohne es noch weiter mit Zusatzfunktionen zu überladen. Viele Grüße gatsby
Hallo Albert, was ist denn der Grund für die mangelnde Motivation gerade? Liegt es daran, dass deine Vorschläge für Neuerungen nicht so auf Resonanz gestoßen sind? Du hast das Processing angesprochen, ich beispielsweise habe gar nicht darüber nachgedacht, ob es sinnvoll wäre oder nicht, da ich eine saubere Zwischenversion als höheres Ziel sehe. Warum: Irgendwann ist doch das Pulver verschossen und zu dem Zeitpunkt wäre es schön, wenn man schon was in der Hand hat. Leider war das jetzt wohl der Fall, bevor die erste runde Version rausgekommen ist. Wenn der Grund ist, dass dus nicht kommerziell eingesetzt sehen willst, dann lass halt die Speichernfunktion draußen und schalte sie nur bei lizensierten Versionen frei. Nur als Vorschlag. Auf jeden Fall wäre es Schade, wenn es beim bisherigen bleiben sollte. Kupferstecher
Da der Frühling naht, zitiere ich jetzt einfach mal aus meiner Antwort irgendwo ganz oben im Thread: Albert M. schrieb: > 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
Das kenne ich auch. Am Anfang ist man fasziniert von einer Idee und macht sich an die Umsetzung. Wenn man dann gesehen hat, dass es klappt, vergeht meistens das Interesse und man wendet sich wieder neuen, interessanten Ideen zu. Der Lohn für einen Open-Source Programmierer ist ja die Aufmerksamkeit der anderen. Oft entsteht auch eine gewisse Anspruchshaltung der Anderen, die neue Features verlangen, obwohl sie nichts dafür bezahlen. Und 10 Euro für ein Programm zu zahlen, dessen Programmiere anderswo 50 Euro die Stunde verdient, lohnt sich auch nicht.
Hallo Albert Fruehlingsmuedigkeit ? Ist doch viel zu früh ! Habe gestern deine Version 0.44 ausprobiert: MIR GEFAELLT SIE ! Ich konnte in kürzester Zeit x Instrumente positionieren Optisch sehr gelungen….alles wirksam. Bitte mache weiter …Du hast ja schon alles vorbereitet für ein käufliches Produkt. Es fehlt nur noch der Preis. Teile uns BITTE mit wie und wo zu haben,''as is'' mit Freischaltung einiger Zusatzfunktionen,die Du ja schon getestet hattest. Das wäre echter Fruehling !
Naja, wenn du alles in Geld aufwiegst, bleibt dir am Ende nichts! Daran ändert das Informationszeitalter auch nichts wesentliches. In meiner letzten Physikstunde erläuterte ich die 7 SI-Einheiten. Dann fiel mir auf, huch da fehlt doch was! Genau, das "Bit" als Einheit der Information. Also sind es doch 8 Einheiten. Wie kann man so eine Erfahrung mit Geld aufwiegen? Allerdings hat sich der Ton doch schon recht stark geändert, wenn ich mir so den ersten Post durchlese. Damals war keine Rede von kommerziell. In einem Nebensatz aber steht ja: Ich verkaufte meine Firma, die ich durch meine Fähigkeit alles auf den Punkt zu bringen, erfolgreich führte. Und das offensichtlich gewinnbringend und nun lebt er als Privatier mit solider Finanzausstattung. Vielleicht auch nicht, dann würden die letzten Posts deutlichen Gewinn an Sinn ergeben. Wir haben hier jedenfalls 273Kelvin, alle Pflanzen und fast Tiere sind auf Winter. Selbst Nadelbäume wachsen nur über 5°C. Warten wir auf den nächsten Winter...
Hi, hier, etwas südlicher blühen heute VergissMeinNichte,weisse Primelchen und Sträucher,gelb ! Ich kann Albert sehr gut verstehen: wenn das Spielzeug einmal funktioniert verliert es an Reiz…mir geht es genau so. Man hat das geschaffen,was man wollte,man fühlt sich bestätigt und das Interesse am Spiel tendiert Richtung Boden.Willst Du uns traurig machen ? Aber so wie das Programm aufgebaut ist zeigt doch, dass im Hinterkopf nicht der Gedanke lauerte ''aufzugeben'' Deshalb,komm zurück ins Forum, die Insekten schlafen noch etwas.. Albert wanted !
>> 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. Das hast du leider nie angefangen. Es gab durchaus Feedback aber du bist da auch ein echter Eigenbrödler :-) Dann mal sehen wenn die Lust wieder da ist.
also, ich kann Albert gut verstehen. Man kann für Geld eben nicht alles kaufen! Geld ist nicht alles! Was Albert bis jetzt da gebaut hat ist schon beträchtlich und ich ziehe meinen Hut davor, nicht nur davor sondern auch vor seiner Einstellung dem Ganzen gegenüber, könnte von mir sein! Leider kann man nie sicher sein, dass sich hier nicht auch kommerzielle herumtreiben die einen Nutzen aus dem hier veröffentlichen ziehen wollen. Chapeau Albert Gruß Klaus
Vielen Dank für dieses Programm, ist echt super geeignet, um mal schnell ein paar Debug-Ausgaben bei z.B. einem Sensormesswert grafisch schön visualisieren zu können! Hat mir viel Zeit erspart & ermöglicht meine Algorithmen für einen ADXL345 Beschleunigungssensor gut anzupassen! Als Verbesserungsvorschlag, was auch einige andere Programme nicht auf die Reihe bringen, wäre es toll, wenn es nicht abstürtzt bei einem Abstecken/Absturz des USB<->Seriell-Wandlers. Desweiteren wäre es toll, wenn man bei Änderungen von Parametern nicht immer Zuweisen & Show drücken müsste bzw. es einen Zuweisen-Button gäbe! Beste Grüße, Stefan
super Programm, dass ich schon lange gesucht habe, leider bin ich jetzt erst darauf gestossen. bitte weitermachen denn es sind sicher viele die alles nur mitlesen und mit jeder Erweiterung zufriedener werden. lg l-hase
Ich habs heute mal getestet und fand deutlich entspannter als ein flitzendes Terminalfenster zu beobachten. Schöne Sache, schnell dass passende zusammengestellt, Software für den MC ist ja auch sehr einfach. Aber wenn ich die Einstellungen nicht speichern kann und jedes Mal neu erstellen müsste macht es die Sache für mich ziemlich sinnfrei. Ok, für ein oder 2 Instrumente mag das ja noch angehen. Ich weiss nicht, wie es euch geht, aber ich arbeite immer an mehreren Sachen quasi parallel. Dann gibts da mal Pausen, andere Ideen/Erweiterungen kommen später, was anderes ist gerade dringender, irgendwelch Bauteile oder neue Platinen fehlen noch usw. Natürlich steht es jedem frei, seine Software so anzubieten wie er will, noch dazu, wenn sie kostenlos ist. Ich kann sie so nicht brauchen, schade.
>> Aber wenn ich die Einstellungen nicht speichern kann
Das sollte eigentlich der Fall sein, die Parameter werden in der
SerialComInstruments.ini gespeichert.
Ja, der jeweils letzte Stand. Und dann fängt man womöglich an, die jeweils umzubenennen?? (Wenn es denn überhaupt so funktionieren würde) Wenn es als Demoversion so gemacht wäre, um die Software dann bei Gefallen verkaufen zu können, hätte ich ja Verständnis für. Aber eine Kaufversion soll es ja wohl sowieso nicht geben, oder doch? Na egal, der Ansatz ist gut, aber mit Absicht bis zur Unbrauchbarkeit kastriert. Wo der Sinn bei der Aktion liegt habe ich auch nicht verstanden. Deinstalliert und fertig.
Vielleicht könnte Albert M. die Instrumente bzw. Funktionalität als 32 Bit DLL bereitstellen. Somit könnte man in der Sprache, die man benutzt, diese einbinden. Projektseitig könnte man dann diverse Einstellungen selber speichern.
Albert M. schrieb: > 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. > Jo, dann ist es eben so. Was das alles wiederum mit gewerblichem Einsatz zu tun hat, verstehe ich immer noch nicht.
H.Joachim Seifert schrieb: > Ich habs heute mal getestet und fand deutlich entspannter als ein > flitzendes Terminalfenster zu beobachten. Schöne Sache, schnell dass > passende zusammengestellt, Software für den MC ist ja auch sehr einfach. H.Joachim Seifert schrieb: > Na egal, der Ansatz ist gut, aber mit Absicht bis zur Unbrauchbarkeit > kastriert. Wo der Sinn bei der Aktion liegt habe ich auch nicht > verstanden. > Deinstalliert und fertig. Super - und nun? frickelst Du nun wieder mit deinem "flitzendes Terminalfenster"? Wir können doch froh sein, dass es so was gibt, wenn auch Speicher/Lade-Funktionen fehlen. Als Freeware findest Du nichts vergleichbares und als Payware must Du gleich richtig was auf den Tisch legen. Also was machst Du hier den coolen Hermann?
Mach ich doch gar nicht. Ich finde die ganze Sache ziemlich gut, aber so eben für mich nutzlos. I.a. komme ich auch mit wenigen anzuzeigenden Parametern aus, dafür reicht auch ein Terminalprogramm, noch dazu, da die Software eh in Teilstücken geschrieben und getestet wird. Komfortabler wäre es gewesen, das direkt in das Projekt mit einzubinden und alle möglichen Zustände sozusagen online zu sehen. Aber doch nicht, wenn ich jedesmal ne halbe Stunde brauche, um wieder zu sehen, was ich sehen will. Ist irgendwie so, wie wenn dir jemand einen ganz tollen Hammer schenkt mit dem man ganz toll nageln kann. Aber wenn du in Brettchen B statt A nageln willst, musst du dir erst jedesmal wieder einen neuen Stiel schnitzen. Ist ja nur meine persönliche Meinung. Es steht jedem frei, dass so zu machen wie er will. Es steht aber jedem frei, es so zu akzeptieren und zu nutzen oder eben nicht. Ich würde es gerne nutzen ob gegen Geld oder gerne auch ohne. Aber mit diesen Einschränkungen werde ich es eben nicht tun, weil der Aufwand den Nutzen für mich übersteigt.
H.Joachim Seifert schrieb: > Aber doch nicht, > wenn ich jedesmal ne halbe Stunde brauche, um wieder zu sehen, was ich > sehen will. Das braucht bei mir noch keine 30 Sekunden. Ich speichere mir jeweils für das entsprechende Projekt die SerialComInstruments.ini unter meinem Projekt-Name ab. Wenn ich das Projekt wieder mal brauche wird die ini-Datei wieder mit dem Origal-Name umbenannt. Ja, das ist ein Behelf, aber einer der nur wenige Sekunden dauert. Wenn Du die minimale Zeit nicht aufwenden willst, ist Dir auch nicht zu helfen.
Das habe ich zugegebener Weise nicht versucht. Aber wenn es so einfach möglich ist - umso unsinniger die Einschränkung, dass es auf "normalem" Weg nicht vorgesehen ist - also nicht gewollt ist. Laut eigener Aussage vorhanden aber nicht freigegeben. Ich versteh einfach die Denke hinter dem ganzen nicht. -richtig freigeben will er nicht -verkaufen/lizensieren will er nicht Was will er eigentlich? Die Wurst hinhalten, aber nicht geben? Ich mag sowas einfach nicht. Klare Ansagen sind mir lieber.
H.Joachim Seifert schrieb: > -richtig freigeben will er nicht > -verkaufen/lizensieren will er nicht > > Was will er eigentlich? Die Wurst hinhalten, aber nicht geben? Hat er doch am Anfang geschrieben, Wintermonate und Zeitvertreib. Kann man akzeptieren. Kann aber auch sein das er eine Library genutzt die nicht frei ist und er gar nicht anders kann. Wer weiß.
Auf meinem Rechner kann ich die 270°-Zeigerinstrumente nicht per Häckchen aktivieren. Ist das in der Software noch nicht drin oder liegt es an meinem Rechner?
Thomas Forster schrieb: > Auf meinem Rechner kann ich die 270°-Zeigerinstrumente nicht per > Häckchen aktivieren. Ist das in der Software noch nicht drin oder liegt > es an meinem Rechner? Dein Rechner ist schon in Ordnung. Die 270er Instrumente sind wohl noch nicht implementiert.
Wer arbeitet mit dem Programm in der neuesten 0.44 Version? Was macht ihr damit? Könnt ihr vielleicht mal Screenshots usw. posten? Würde mich sehr interessieren ob es wirklich so einfach zu handhaben ist.
Angehängte Dateien:
-
Warmwasser.png
31 KB
leider geht es bei diesem Programm zur Zeit nicht weiter, wenn das Hintergrundbild steht ist es leicht zu handhaben, leider gehen noch einige Instrumente ab. l-hase
vergessen die Instrumente sind nicht drauf, ist keine Hardcopy sind 1 Taster, 1 Sollth u. 1 Istth Anzeige drauf
Angehängte Dateien:
-
aaaBild1.jpg
310 KB
Hier eine Console für eine Pumpenprüfung. War in super kurzer Zeit designed und auf dem MC programmiert. Schade dass die Abspeicherung noch nicht freigegeben ist. Aber ich behelfe mich vorerst mit einem Screenshot der Ergebnisse. Die Software ist einfach cool.
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.44a Change Log v0.44a ---------------- Diverse Fehler in PID-Console behoben. Send Parameter in PID-Console zugefügt: Add CR: fügt Carriage Return (Asc 13) zu Add LF: fügt Line Feed (Asc 10) zu Dezimal as Point: ändert den Dezimal-Separator von Komma in Punkt (zur einfacheren Bearbeitung im MC). Fehler beim Aufruf des XY-Displays behoben. Bei dem schlechten Wetter hatte ich mal wieder Lust weiter zu basteln :)
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments V0.45 Change Log v0.45 ---------------- Projekte speichern/laden implementiert. Komplette Projekte können jetzt mit allen Einstellungen unter einem beliebigen Namen gespeichert und wieder geladen werden. Das Auto-Speichern/Laden entfällt damit. Die Schnittstellen-Parameter werden, ebenso wie die Bildschirm-Position, mit gespeichert. In der PID-Console wird jetzt der Sollwert mit einer Nachkommastelle angezeigt. Ich bin jetzt euren Wünschen nachgekommen und habe das lang ersehnte Projekt speichern und laden freigegeben. Dafür wurden die Analog Vertikal-Meter auf 4 Stück reduziert. Irgendwie will ich, wie ihr wisst, den Gebrauch der Software für den gewerblichen Einsatz limitieren. Ich denke mal ihr könnt damit leben :)
:
Bearbeitet durch User
Sehr schön (Daumen hoch), werde ich mir gleich nochmal runterladen.
Anbei neue Version SerialComInstruments V0.45a Change Log v0.45a ----------------- Versehentlich war die Autospeicherung beim Beenden des Programms noch aktiviert, so dass Änderungen, die noch nach einem Speichern gemacht wurden die gespeicherte Konfiguration beim Programmende überschrieben haben. Die Autospeicherung beim Beenden des Programms ist jetzt deaktiviert. Change Log v0.45 ---------------- Projekte speichern/laden implementiert. Komplette Projekte können jetzt mit allen Einstellungen unter einem beliebigen Namen gespeichert und wieder geladen werden.
:
Bearbeitet durch User
Hallo Albert, Ich bin grade erst über dein Projekt gestolpert. Ich habe es selber noch nicht ausprobiert, werde ich aber demnächst einmal machen. Ich drück dir im vorhinein schonmal mein vollsten Respekt dazu aus und danke dir schonmal für deine ganze arbeit die du damit hast.
super, verwende dein Programm schon für die Heizungssteuerung u.e. Pholtaikanlage. wäre es möglich z.B. Stufenschalterinstr. 102, Zeitschaltfensterinstr. anzubauen ? kannst du vielleicht auch die Instr.Nr. 9 u. 10 freigeben, dtto noch eine wie Nr. 65 hoffentlich willst du das auch einfügen. bin ein Hobbyelektr. lg l-hase
hallo Albert bei mir zeigt das Instrument Nr, 44 den 3 fachen Wert an, Software 0.44 oder liegt der Fehler bei mir obwohl bei den Instr. 40-43 die Werte richtig angezeigt werden. lg l-hase
l-hase schrieb: > bei mir zeigt das Instrument Nr, 44 den 3 fachen Wert an, > Software 0.44 Habe es gerade getestet. Der Fehler liegt wohl bei Dir. Schau mal nach ob der zugewiesene Skalierungsfaktor stimmt. l-hase schrieb: > wäre es möglich z.B. Stufenschalterinstr. 102, Zeitschaltfensterinstr. > anzubauen ? > kannst du vielleicht auch die Instr.Nr. 9 u. 10 freigeben, > dtto noch eine wie Nr. 65 Das Analog-Slider Instrument lässt sich auf Stufenschalter adaptieren. Noch ein Instrument#65 wäre eine ziemliche Fleissarbeit. Ein Zeitschaltinstrument wirft ziemlich viele grundsätzliche Fragen auf, wenn es über die Einschaltdauer des PC's wieder reentrant sein soll. Das lässt sich alles machen, der Stufenschlter wäre das einfachste. Allerdings wollte ich ja vor Mitte Herbst nichts machen. Nur wegen des zeitweise schlechten Wetters hatte ich wieder Lust was zu machen. Also ich kann Dir nicht versprechen, dass es vor Herbst was wird, hängt ganz vom Wetter ab :)
Sorry, war da gerade unter meinem anderen Nick drin, aber ich denke das ist OK :)
hallo Albert der Hinweis mit dem Skalierungsfaktor war richtig warum sind in der neuen Version die Nr. 05 bis 08 gesperrt ? könnten die Nr.von 44 bis 48 erweitert werden ? in der neuen Version kann ich die alte (0.44) nicht laden od.was ist falsch? trotzdem wünsche ich dir nur schönes Wetter, wirst schon manchmal Abwechslung brauchen. l-hase
Hallo Albert, super Projekt. Absolut TOP. Eigentlich gibt es nichts zu bemängeln, und trotzdem hab ich etwas gefunden. Die absolute Inkostistenz in der Sprache. Auch wenn es ein "Hobby-Projekt" ist, mach es entweder in englisch oder in deutsch. Dieser Misch-Masch in deiner Software, ist auf deutsch gesagt fürn ARSCH. Für mich als Programmierer sieht es eher so aus, als würdest Du einfach nur irgendwelche Fragmente zusammenwürfeln, als dass Du wirklich was geschaffen hast. Du hast selber den Anspruch, dass es nicht komerziell genutzt wird, aber wer mit kommerziellem Gedanken sollte seine Zeit damit verschwenden, wenn Du Dir selbst noch nicht einmal mit der Sprache einig bist. Nettes Projekt für jemanden den das nicht interessiert, aber von Hause aus kommerziell nicht nutzbar. Also alleine deswegen schonmal kein Grund Funktionen zu reglementieren die für "Hobbynutzer" interessnt sind. Das Du kein "professiononeller" Programmierer bist hast bewiesen. Aber einfach irgendwas zusammenzuklicken und dann in den Raum zu stellen, Du wünsch keine kommerzielle Nutzung ist eine Frechheit. Schönen Gruß
@ Bumblebee Ordne und struktuiere erst mal ausgiebig Deine Gedanken, ehe Du hier Deinen Käse absonderst.
:
Bearbeitet durch User
Angehängte Dateien:
-
PID-Param_1.PNG
7 KB -
PID-Param_2.PNG
3,2 KB
Hallo Albert, es hat mich sehr gefreut, dass dein Projekt noch lebt und du einige gewünschte Änderungen vorgenommen hast. Zur PID-Console habe ich noch zwei Änderungswünsche: 1. Eingabe und Senden der PID-Parameter mit zwei Nachkommastellen 2. weitere Auswahl <CR,LF> senden: nur einmal am Ende des gesamten PID-Parameter "String" oder wie jetzt implementiert nach jedem einzelnen PID-Parameter. Zu Punkt 2., je nach Empfangsroutine im MC können die gesendeten PID-Parameter als Gesamt-String oder als einzelne Strings interpretiert und ausgewertet werden, ohne das die bestehende MC-Routine geändert werden müsste. Anbei zwei Bilder wie <CR,LF> aktuell gesendet werden. Danke Gruß biker10
biker10 schrieb: > Zur PID-Console habe ich noch zwei Änderungswünsche Kein Problem, die Änderungen werden in der nächsten Sub-Version implementiert. Gruß Ulrich Albert
Moin, sag mal, kann man mit deiner Entwicklungsumgebung ohne größeren Umstand auch eine Linux-Version aus dem Teil machen? Das wäre richtig cool. ;-) /Hannes
Bezüglich der cerebralen Diarrhoe von Bumblebee, fällt mir nur Folgendes ein: http://www7.pic-upload.de/28.03.14/exmri3j81hic.gif
Albert M. schrieb: > Ordne und struktuiere erst mal ausgiebig Deine Gedanken, ehe Du hier > Deinen Käse absonderst. Danke für das Kompliment Albert. Aber meine Gedankenwelt ist eigentlich noch ganz in Ordnung. Ich sehe es gelassen. Denn Kritik ist scheinbar nicht gewollt hier. Wo ist denn das Problem? Mach es auf Deutsch oder Englisch. Aber doch nicht komplett durcheinander. Allein schon ein Button "Zuweisen+Show" ??? Auch die Bezeichnungen der Instrumente und Schalter ist nicht konsistent. Mal Deutsch, mal Englisch. Wenn man programmieren kann, dann ist doch eine multilinguale Programmoberfläche das geringste Problem. Albert M. schrieb: > So gross ist der Arbeitsaufwand auch nicht. Ich programmiere in Delphi > und habe für die virtuellen Instrumente fertige Delphi-Componenten. > Daher bleibt "nur" der Aufwand für die Dekodierung und Verteilung des > Datenstromes und die Logic für die freie Platzierung der Instrumente. Wenn man aber gar nicht soviel selber macht, sondern nur vorgefertigte Komponenten benutzt, dann kann dies schon schwieriger sein. Simpel schrieb: > Bezüglich der cerebralen Diarrhoe von Bumblebee, fällt mir nur Folgendes > ein: Und was Dein Problem ist, erschließt sich mir gerade überhaupt nicht. Aber Hauptsache mal irgendwas losgeworden, oder?
Blub schrieb: > Don't feed the Bumblebee Man kann ja zu jeder Sache verschiedene Ansichten haben, aber das Bumblebee's Kritik nicht ganz unberechtig ist, sollte auch mit minimalem geistigen Horizont erkennbar sein. lg Heiner
Hi Albert Da gabs mal von der Firma Wilke eine Produktreihe mit tollen Delphi- Componenten für Anzeige und Steuerung. Sowas suchte ich schon länger. Du hast das hier möglich gemacht. Damit kann man ja schon mal paar Dinge ausprobieren und/oder eine eigene Schaltung steuern und regeln. Vielen Dank
@Moderatoren: verschiebt doch bitte den Thread zu "Projekte & Code"
Angehängte Dateien:
-
Bild_Segelwinde_01a.jpg
290 KB
Hier mal ein Beispiel was man mit den Komponenten in meiner Software so alles auf die Schnelle verwirklichen kann. Eine Realtime Überwachung eines von einer Segelwinde hochgezogenen Segelflugzeugs. Das Programm habe ich für einen Segelflugplatz im Süddeutschen Raum erstellt. Funktionsweise: Der Sender im Flugzeug sendet beim Hochziehen des Seglers den Luftstaudruck, umgerechnet in km/h an den Empfänger am Boden (Airspeed). Über eine serielle Schnittstelle werden die Daten zum Programm übertragen. Hier werden sie grafisch und numerisch für den Windenführer dargestellt, der mit diesen Informationen die Windengeschwindigkeit passend einstellt. Einige Zeit nach dem Ausklinken des Zugseils am Segelflieger wird die Aufzeichnung gestoppt und die angefallenen Daten mit Flugzeugkennung und Uhrzeit zur Dokumentation in ein File geschrieben. Das Bild zeigt das Programm mit meinen Testdaten. Die realen Daten haben natürlich einen anderen Verlauf.
:
Bearbeitet durch User
Hiho, trotz dem Rumgemaule von Einigen hier, deren Leben einfach zu langweilig geworden ist und diese nicht einmal selbst auf die Idee gekommen sind (Neid? Inkompetenz?) so ein Tool zu realisieren, möchte ich an den Programmierer zu dieser Arbeit gratulieren. Sicher, diese Software wird den einen oder anderen Bug haben. Wer einen findet, darf ihn behalten oder meldet es ordentlich dem Entwickler und prollt hier nicht so dämlich rum. Ist doch lächerlich und fernab von geistiger Reife. @Albert: Alter Nachbar aus MG ... verregnete Grüße aus KR. Sehe ich das richtig, das ich nur 4 mal das Instrument #41 (42-44) einbinden kann und wenn ich 8 brauche einfach mal Pech gehabt habe? Könnte man dies irgendwie abändern? Gruß Fusel
Hi Albert bei Instrument 60 (Leds) sind beim Neustart des Programms die zugeordneten Namen wieder weg, wieder nur noch Led1 ..Led8 ??? finde dein Programm sehr gut, leider sind bei der neuen Version nor noch Instrumente 1-4 vorhanden. könnte man z.B bei den Tastern nicht eine Zusatznummer (a...)mitgeben damit man mehr gl.Instrumente hat ? lg l-hase
Fusel schrieb: > Hiho, > > trotz dem Rumgemaule von Einigen hier, deren Leben einfach zu langweilig > geworden ist und diese nicht einmal selbst auf die Idee gekommen sind > (Neid? Inkompetenz?) so ein Tool zu realisieren, möchte ich an den > Programmierer zu dieser Arbeit gratulieren. > Sicher, diese Software wird den einen oder anderen Bug haben. Wer einen > findet, darf ihn behalten oder meldet es ordentlich dem Entwickler und > prollt hier nicht so dämlich rum. Ist doch lächerlich und fernab von > geistiger Reife. > > @Albert: > Alter Nachbar aus MG ... verregnete Grüße aus KR. > Sehe ich das richtig, das ich nur 4 mal das Instrument #41 (42-44) > einbinden kann und wenn ich 8 brauche einfach mal Pech gehabt habe? > Könnte man dies irgendwie abändern? > > Gruß > Fusel Hallo Fusel, ich maule nicht rum, sondern sag wie es ist. Auf die Idee selber kommen? Warum? Es gibt unendlich viele Tools, die das bereits zu Genüge ermöglichen. Ich programmiere beruflich seit gut 15 Jahren. Mit nativen C, C++, VB, C# und LabVIEW. Ich komme noch aus Zeiten als wir nur DOS kannten und uns auch mit der Hardware auseinander setzen mussten. Soviel zum Rumgemaule. Oder noch eine Frage? Und Deine Frage ist doch schon beantwortet: >Albert: >Ich bin jetzt euren Wünschen nachgekommen und habe das lang ersehnte >Projekt speichern und laden freigegeben. Dafür wurden die Analog >Vertikal-Meter auf 4 Stück reduziert. Irgendwie will ich, wie ihr wisst, >den Gebrauch der Software für den gewerblichen Einsatz limitieren. Ich >denke mal ihr könnt damit leben :) Du willst 8 Instrumente für Lau? Dann lies auch mal mehr als einen Kommentar zurück.... Oder noch viel besser: Mach Sie Dir doch einfach selber !
Bumblebee schrieb: > Hallo Fusel, > ich maule nicht rum, sondern sag wie es ist. > Auf die Idee selber kommen? > Warum? > Es gibt unendlich viele Tools, die das bereits zu Genüge ermöglichen. Dann verwende DU doch die Tools und komme wieder wenn DU hier was Vergleichbares der Allgemeinheit zur Verfügung stellen kannst. Offensichtlich bin ich bisher der Einzige der das auch durchgezogen hat. > Ich programmiere beruflich seit gut 15 Jahren. Mit nativen C, C++, VB, > C# und LabVIEW. > Ich komme noch aus Zeiten als wir nur DOS kannten und uns auch mit der > Hardware auseinander setzen mussten. Das sagt über Deine Qualifikation so gut wie nichts aus. Ich kenne genügend dumpfbatzige "langjährige Programmierer" mit grosser Klappe. > Soviel zum Rumgemaule. Oder noch eine Frage? Schulmeisterhaft beklagst Du hier (siehe Deine Beiträge oben) die Mischung von deutschen und englischen Bezeichnungen in meiner Software. Benutze doch einfach was anderes. Ich werde es so belassen wie es ist, auch wenn Du noch so heulst. Höchstens lasse ich mich breitschlagen "Interface" in "Zwischengesicht" einzudeutschen. Das wäre doch dann ganz in Deinem Sinne. > Du willst 8 Instrumente für Lau? > > Dann lies auch mal mehr als einen Kommentar zurück.... Wenn Du dabei auf die Modifikation des Programms für den Segel-Flugplatz anspielst, das habe ich als alter Motorflieger für die süddeutschen Kollegen für lau aus Spass an der Freud gemacht. Aber eigentlich geht Dich das gar nichts an. Stänkerer wie Dich Bumblebee habe ich noch nie abgekonnt. Weitere Reaktion wirst Du von mir hier keine mehr erhalten.
:
Bearbeitet durch User
l-hase schrieb: > bei Instrument 60 (Leds) sind beim Neustart des Programms die > zugeordneten Namen wieder weg, wieder nur noch Led1 ..Led8 ??? Ist bereits korrigiert und kommt in der nächsten Version > leider sind bei der neuen Version nor noch > Instrumente 1-4 vorhanden. Werde ich im Herbst überdenken :) > könnte man z.B bei den Tastern nicht eine Zusatznummer (a...)mitgeben > damit man mehr gl.Instrumente hat ? Mal schauen. Du kannst ja solange die Zusatznummer mit im zuordbaren Text für die Schalter angeben. Fusel schrieb: > Sehe ich das richtig, das ich nur 4 mal das Instrument #41 (42-44) > einbinden kann und wenn ich 8 brauche einfach mal Pech gehabt habe? > Könnte man dies irgendwie abändern? Im Moment sind es leider halt nur 4. Klar kann man das Ändern. Da mache ich mir im Herbst Gedanken drüber. Johannes S. schrieb: > sag mal, kann man mit deiner Entwicklungsumgebung ohne größeren Umstand > auch eine Linux-Version aus dem Teil machen? Das wäre richtig cool. ;-) Weiter oben findest Du Beiträge von Usern die das Programm auf Linux unter Wine ans Laufen bekommen haben. Eine native Linux-Version kann ich nicht erstellen.
:
Bearbeitet durch User
Moin, @Bumblebee: Nice. Wie Du hier argumentierst und die Arbeit anderer Leute bewertest bzw. schlechtredest. Solche Leute mag ich. *Ironie=off* Bumblebee schrieb: > Auf die Idee selber kommen? > Warum? > Es gibt unendlich viele Tools, die das bereits zu Genüge ermöglichen. > Ich programmiere beruflich seit gut 15 Jahren. Mit nativen C, C++, VB, > C# und LabVIEW. Gesunde Einstellung. Warum sollte man das auch? Es gibt nun einmal einige Leute, die nicht allzu viele Programmiersprachen beherrschen und auch weder die Zeit noch die Möglichkeiten haben, sich derartiges Fachwissen anzueignen. Diese sind dann schlichtweg froh und auch dankbar, wenn sich Leute wie Albert hinsetzen und etwas "zusammenschustern", was irgendwie helfen kann, eigene und private Projekte zu realisieren. Da tangiert es periphär, ob der Quellcode nun in 7 verschiedenen Sprachen verfasst und mit Hilfe anderer Tools erstellt wurde. Ich beherrsche so viele Sprachen nicht und bin nicht in der Lage, mir etwas derartiges zusammen zu scripten. Du? Ja? Dann troll hier nicht so unqualifiziert herum und mach es besser! Und bis dahin solltest Du mal an Deiner Sozialkompetenz und Deiner kognitiven Psychohygiene arbeiten, welche scheinbar in den letzten 15 Jahren auf der Strecke geblieben sind. Bumblebee schrieb: > Du willst 8 Instrumente für Lau? > > Dann lies auch mal mehr als einen Kommentar zurück.... In der Tat habe ich so viel weiter nicht zurückgelesen. Der Grund dafür sind leider so unqualifizierte Kommentare wie Deiner, welche mit konstruktiver Kritik leider nichts zu tun haben. Diese drücken die Stimmung, verlängern den Thread sinnlos und erschweren die Informationsfindung erheblich. @Albert: Ich nehme anderweitig mit Dir Kontakt auf. Ich muss hier leider feststellen, das es viel zu viele Forentrolle gibt, die kein Reallife mehr haben und immer wieder zwanghaft nach irgendwas zu suchen, wo sie ihre Unzufriedenheit in deren eigenem Leben durch gekonnt-unqualifizierte Äusserungen kompensieren können.
Wer so eine Software kommerziell nutzen will, kann sich an dieser Diskussion beteiligen: Beitrag "Virtuelle Instrumente an serielle Schnittstelle (kommerziell)" Mit freundlichen Grüßen Chris
Wer seine Software öffentlich vorstellt, sollte auch Kritik vertragen können. Eine diffamierung von Postern, rein aus dem Umstand heraus dass sie Kritik äußern ist kein besonders guter Stil. Die meisten Kritikpunkte stimmen nunmal inhaltlich. Ob der Ton immer besonders nett ist, sei dahingestellt, aber wir sind hier ja auch nicht beim Kindergeburtstag. Niemand hat einen Anspruch immer nur Lob zu kassieren nur weil er was veröffentlicht. Das gibts nur bei Mama.
Auch wenn die Zukunft der Haus&Hof-MSR vielleicht doch eher webbasiert ist statt einen 24h PC in Beschlag zu nehmen- von diesem Projekt bin ich trotzdem begeistert. Ich plane den Einsatz als zweite, lokale GUI für meine Haussteuerung und werde mich hier mal einarbeiten. Also zunächst ein Dankeschön auch von mir- und hoffentlich verläuft dieser Herbst für den Programmautor wie der letzte ;-) Interessant auch in dieser Diskussion wieder zu sehen, wie wenig mancher Profi von "keep it simple" hält (oder versteht?). Statt dessen heißt es nur flexibler,flexibler,flexibler = komplizierter, komplizierter, komplizierter. Zum Glück hat Albert aber dieses Programm für den Hobbyisten designt, auch wenn das manchem (kommerziellen) Profi hier offensichtlich nicht paßt. Anders ist es wohl nicht zu verstehen, daß diese Entscheidung als "Frechheit" bezeichnet wird- was eigentlich für sich genommen nichts anderes ist. Vorbildlich auch, das Programm selbst möglichst kompakt und simpel einsetzbar zu machen. Obwohl offensichtlich letztlich doch kein Weg um eine Installationsroutine und zusätzliche leidige DLL-Dateien herumführt. Das dürfte aber nicht Alberts Fehler sondern eher einer grundsätzlichen Designschwäche von Windows geschuldet sein. Sollte sich zukünftig doch ein Weg zurück zu einer einzigen .exe finden lassen würde ich das sehr begrüßen. Ein Wort noch zum Sprachmix. Das ist höchstens eine Geschmacksfrage. Es ist in Alberts Programm nämlich auch nicht anders wie im wahren Leben. Das Englische gewinnt eben zunehmend an Einfluß. Und wer nicht wahrhaben will daß die Entwicklung über kurz oder lang global zu einer Weltsprache führt (und führen muß) kann sich ja gerne was anderes wünschen ;-)
Anbei neue Version SerialComInstruments V0.45b Change Log v0.45b ----------------- Instrument#60 LED's Bug behoben: LED-Bezeichnungen wurden nicht korrekt abgespeichert. Instrument#30 PID Bug behoben: Werte wurden nicht korrekt zum MC übertragen wenn noch ein Eingabefeld den Focus hatte. Num. Anzeige des Ist-Wertes jetzt 3 Nachkommastellen. Num. Anzeige des Soll-Wertes jetzt 2 Nachkommastellen. Datenübetragung der PID-Parameter zum MC jetzt mit bis zu 5 Nachkommastellen. Moby schrieb: > .... das Programm selbst möglichst kompakt und simpel > einsetzbar zu machen. Obwohl offensichtlich letztlich doch kein Weg um > eine Installationsroutine und zusätzliche leidige DLL-Dateien > herumführt. Die beigefügte DLL-Datei ist nicht auf allen PC's notwendig. Versuch es mal ohne. Das Installations-Programm ist auch nicht unbedingt nötig, macht das Installieren und Deinstallieren aber komfortabel. Unbedingt nötig sind eigentlich nur das EXE-File (Programm) und wenn gebraucht, das PDF-Hilfe File.
:
Bearbeitet durch User
Fusel schrieb: > . > > @Albert: > Ich nehme anderweitig mit Dir Kontakt auf. Ich muss hier leider > feststellen, das es viel zu viele Forentrolle gibt, die kein Reallife > mehr haben und immer wieder zwanghaft nach irgendwas zu suchen, wo sie > ihre Unzufriedenheit in deren eigenem Leben durch > gekonnt-unqualifizierte Äusserungen kompensieren können. 1. ich finde das Projekt super, gute Arbeit! 2. Ich höre jetzt auch auf dem Thread zu folgen, weil mir das rumgenöle zu dumm wird. Es ist langweilig mehr dumme Egodiskussion zu lesen als schönes zum Projekt.
Na wenn allein schon ein kritischer Beitrag ausreicht, dann ist Euch auch nicht mehr zu helfen. Ich habe nie gesagt, dass das Programm grundsätzlich schlecht ist. Es ging lediglich um die Inkosistenz der Sprache innerhalb der Software, bezogen auf die Aussagen zur kommerziellen Nutzung und der dit einhergehenden Begrenzung an Funktionen. Nur weil man lesen kann, bedeutet dies hier noch lange nicht, dass man auch den Sinn einer Aussage versteht. Aber schön wie man hier dargestellt wird. Juckt mich aber nicht. Denn alle Nachredner sollten erst mal vor der eigenen Tür kehren. Viel Spaß weiterhin.
Angehängte Dateien:
-
Voltaik.png
78 KB -
Heizung.png
280 KB
möchte meine ersten 2 Projekte mit dieser Software vorstellen vielleicht kann ich damit andere auch ansporen. l-hase
Albert M. schrieb: > Höchstens lasse ich mich breitschlagen > "Interface" in "Zwischengesicht" einzudeutschen Hallo Albert, ich denke mal, dass dies nun doch eher ironisch gemeint war. Aber zumindest hat es mich dann doch zum Lachen gebracht. Solche Übersetzungen braucht kein Mensch.....Aber die korrekte Überstzung "Schnittstelle" hätte gereicht. :-) Ich stelle nochmal klar: Ich respektiere Deine Arbeit und das was Du hier vollbracht hast. Für den Hobby- und Heimnanwender. Wie auch schon in meinem erste Post gesagt. Auch wenn mir nicht alles gefällt. Moby schrieb: > Ein Wort noch zum Sprachmix. Das ist höchstens eine Geschmacksfrage. Es > ist in Alberts Programm nämlich auch nicht anders wie im wahren Leben. > Das Englische gewinnt eben zunehmend an Einfluß. Und genau das meine ich doch. Das es nicht aufzuhalten ist. Ganz klar. Aber warum muss man es dann konsequent so vermischen? Vor allem wenn man es doch selber in der Hand hat? Vielleicht habe ich es etwas überzogen, aber manchmal muss man das auch. Wischi-Waschi ist nicht mein Ding. Mit Deinem Post ist doch der Nagel auf dem Kopf getroffen! Dieser Anglizismus kotzt mich auf deutsch gesagt an. Nicht mehr und nicht weniger. Und genau hier setzt mein Post an. Kommerziell ist dann doch eher das englische interessant. Als 0815 Hobbynutzer, der sich gern mal schnell was hinzaubert, sollte es aber klar und konsistent sein. So sehe ich das. Ich schreibe täglich Software, allerdings eher etwas speziell und kundenorientiert. Und immer wieder ist die Sprache genau ein Punkt im Lastenheft. Am Besten mit universeller Sprachumschaltung. Man weiß ja nie wo die Software mal laufen wird, und kann sich ja auch ändern. Heute in good old Germany, morgen in irgendeinem chinesichen Hinterhof und Übermorgen in Osteuropa. Aber wir sind hier halt in dem guten alten Deutschland, und dann mag ich es halt auch gerne in deutsch. Das ist alles. Und alles in dem Programm lässt sich sauber übersetzen. Man muss ja auch mal dran denken, dass es vielleicht User gibt, die nicht aller Sprachen mächtig sind, aber trotzdem technikinteressiert sind. Aber letzen Endes muss es jeder selber wissen. Ist ja auch nur meine Meinung: Gute Software aus gutem deutschen Hause ist auch komplett in deutsch. Naja. Jetzt könnt Ihr mich wieder anfeinden. Viel Spaß.
Anbei neue Version SerialComInstruments V0.45c Change Log v0.45c ----------------- Hintergrundbilder werden nun auch mit zum Projekt abgespeichert. Durch den neuen zusätzlichen Eintrag in der jeweiligen Projektdatei sollten zur ordungsgemässen Funktion alle Projekte einmalig neu abgespeichert werden. Bitte beachten: Es wird nur ein Verweis zur Bild-Datei gespeichert, nicht die Bild-Datei selbst. Damit also das Hintergrundbild später geladen werden kann, darf die Bild-Datei nicht vom ursprünglichen Ort entfernt werden.
:
Bearbeitet durch User
Da das nicht so gute Wetter zur Zeit meine Bastellaune aktiviert, bin ich dabei ein neues Instrument zu entwickeln. Dabei handelt es sich um eine in der Grösse skalierbare/verschiebbare Zeichenoberfläche. Die bisherigen implementierten Befehle sind: ClearGraphic, GraphicSize, ShowGraphic, PenColor, PlotPoint, MoveTo, PlotTo, PlotLine, PlotRectangle, FillRectangle, PlotCircle, ShowText. Das Format ist: § Command Data < Z.B. sieht der vom Mikrocontroller zu sendende Befehl um eine Linie zu zeichnen so aus: § PL x1 ; y1 ; x2 ; y2 < z.B.: §PL100;50;247;72< Die sich ergebenden neuen Möglichkeiten sind vielfältig und reichen von der Realtime-Darstellung sich bewegender Vorgänge (animiertes Prozess-Bild, es lassen sich Objekte z.B. hin und her bewegen) bis hin zur Kreation eines neuen speziellen Anzeige-Instruments. Vielleicht fällt euch ja noch was dazu ein.
:
Bearbeitet durch User
Angehängte Dateien:
-
sci-error.jpg
66 KB
Für die Anbindung wird von mir eine serielle Bluetooth-Schnittstelle verwendet. Zuweilen erhalte ich leider einen Zugriffsfehler, obwohl der Gerätemanager die Schnittstelle als funktionierend ansieht. Ein Neustart des Programms behebt das Problem.
Moby schrieb: > Ein Neustart > des Programms behebt das Problem. ... und auch einer der nächsten Aktivierungsversuche. Wenn über die Schnittstelle während ihrer Aktivierung schon Daten ankommen kann dieser Fehler entstehen. Eventuell könnte das Programm für solche Fälle ein paar Aktivierungsversuche intern veranlassen.
Albert M. schrieb: > ClearGraphic, GraphicSize, ShowGraphic, PenColor, PlotPoint, MoveTo, > PlotTo, PlotLine, PlotRectangle, FillRectangle, PlotCircle, ShowText. > Sehr schön. Erinnere dich an meinen Vorschlag Stichwort SPICE :-) > Vielleicht fällt euch ja noch was dazu ein. Vielleicht eine Abfragemöglichkeit für den uC, was für eine Programmversion gerade läuft mit den maximalen Fensterkoordinaten. Bei uns im Südosten ist das Wetter gut. Gottseidank auch nicht zu heiß.
Albert M. schrieb: > bin > ich dabei ein neues Instrument zu entwickeln. Mir wären zunächst mal ein paar ordentliche, normale, einzelne Schalter recht. Und auf jeden Fall ein paar mehr Taster. Das mit den angezeigten Instrumentennummern ist auch nicht sehr schön. Kann man die zumindest im normalen NoEdit Betriebsmodus nicht mal ausblenden? Im Edit-Modus sollte man die markierten Instrumente über die rechte Maustaste konfigurieren und mit DEL einfach löschen können. Das entsprechende Instruments-Fenster wirkt auch ziemlich durcheinander gewürfelt. Sollte mal sortiert und die Funktionen sollten besser auseinandergehalten werden. Weiterhin könnte das Programm seine Bereitschaft und vielleicht ein paar Status-Infos dem MC auch selbstständig mitteilen. OK, genug gemeckert. Bin ja auch so schon überglücklich mit diesem kostenlosen Angebot ;-)
Moby schrieb: > Für die Anbindung wird von mir eine serielle Bluetooth-Schnittstelle > verwendet. Zuweilen erhalte ich leider einen Zugriffsfehler Moby schrieb: > Wenn über die Schnittstelle während ihrer Aktivierung schon Daten > ankommen kann dieser Fehler entstehen. Anscheinend ist das ein Problem von Windows, da es auch bei anderen Programmen/Geräten ab und an auftritt. Man hat diesen Effekt auch z.B. beim ATMEL MKII USB Programmer oder beim Anschuss von Arduino Boards usw. Damit muss man wohl leben. Mit bereits über die Schnittstelle ankommenden Daten hat das nichts zu tun. Ich kann hier mit 115200 baud Daten senden und die Schnittstelle aktivieren. Das geht ohne Fehler. Abdul K. schrieb: > Vielleicht eine Abfragemöglichkeit für den uC, was für eine > Programmversion gerade läuft mit den maximalen Fensterkoordinaten Lässt sich machen. Darius M. schrieb: > Mir wären zunächst mal . . . Ich gebe Dir soweit in allen Punkten Recht. Mir gefällt die teilweise Inkonsistenz bei den Instrumenten und der Programmoberfläche/Bedienung auch nicht. Eventuell schreibe ich ab Herbst die komplette Software von Grunde auf neu. Vielleicht ändere ich dann die Programmlogik auch dahin, dass die Verteilung der Messwerte auf bestimmte Instrumente erst über die Bedienoberfläche im PC erfolgt (siehe im Thread ziemlich oben). Das ist in dieser Version aus Zeitgründen, das Programm ist ja in nur wenigen Wochen enstanden, nicht erfolgt. Am Daten-Protokoll würde sich dadurch nicht viel ändern: Protokoll jetzt: #nMm< wobei n = Instrument-Nummer Protokoll später: #nMm< wobei n = MC-Daten-Kanal In der Bedienoberflächer der neu angedachten Version könnte man dann entscheiden, welcher MC-Daten-Kanal auf welche Instrumente verteilt wird. Damit wären auch Mehrfach-Zuweisungen besser möglich. Mit der neuen Programmlogik/Protokoll wäre es auch einfacher, nicht nur selbst programmierte Mikrocontroller anzuschliessen, sonder irgendwelche Geräte, die ihre Daten seriell ausgeben, zu adaptieren. Das würde nur leichte Umkonfiguration in den internen Protokoll-Routinen benötigen.
:
Bearbeitet durch User
Angehängte Dateien:
-
sci-error.jpg
33 KB
Albert M. schrieb: > Mit bereits über die Schnittstelle > ankommenden Daten hat das nichts zu tun. Der Zusammenhang ist bei mir recht eindeutig: Ohne (bei mir sekündliche) Daten gelingt die Initialisierung fast immer. Mit nur manchmal. So wäre es wirklich praktisch, könnte der MC die Programm-Bereitschaft (mit erfolgreich geöffneter) Schnittstelle detektieren und dann erst seinen Datenversand starten. Die "NormalView" weist noch einen kleinen Fehler auf. Das Aktiv-Label wird, zumindest mit 4 Zeilen, in der Darstellung abgeschnitten (siehe Bild). Beim Abspeichern des Projekts wird die kleine praktische Texteingabebox #99 leider nicht mitgesichert. Albert M. schrieb: > könnte man dann > entscheiden, welcher MC-Daten-Kanal auf welche Instrumente verteilt > wird. Eine sehr gute Idee. Über die Kanalanzahl kannst Du ja dann weiter die beabsichtigte Limitierung auf 'Hobby' durchsetzen und ermöglichst trotzdem, von diesem oder jenem Instrument ein paar mehr zur Verfügung zu haben ;-)
@ Moby In der nächsten Version werden folgende Änderungen vorgenommen: Nach erfolgreicher Aktivierung der Schnittstelle sendet das Programm optional wahlweise ein #OK< oder #OK<CR oder #OK<CRLF als Statusmeldung an den Mikrocontroller. Die Einstellung findet man unter "Optionen". Beim Abspeichern des Projekts wird die Texteingabebox #99 mitgesichert. Moby schrieb: > Die "NormalView" weist noch einen kleinen Fehler auf. Das Aktiv-Label > wird, zumindest mit 4 Zeilen, in der Darstellung abgeschnitten (siehe > Bild). Die "NormalView" ist eigentlich nur eine willkürliche Festlegung der Fenstergrösse auf ein Standardmass und ordnet die Instrumente nicht automatisch neu an. D.h. Du musst das Aktiv-Label im Edit-Mode so platzieren dass es passt.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.45d Change Log v0.45d ----------------- Nach erfolgreicher Aktivierung der Schnittstelle sendet das Programm optional ein #OK< oder #OK<CR oder #OK<CRLF als Statusmeldung an den Mikrocontroller. Die Einstellung findet man unter "Interface". Beim Abspeichern des Projekts wird die Texteingabebox #99 mitgesichert.
Mach den String doch konfigurierbar eben als String. Die Linuxer möchten bestimmt ihr LF noch, dann würde es auf allen gängigen Plattformen laufen.
Albert M. schrieb: > Die "NormalView" ist eigentlich nur eine willkürliche Festlegung der > Fenstergrösse auf ein Standardmass Ja, richtig. Ich dachte zunächst, die Fenstergröße würde sich dem Inhalt anpassen. Nun wäre es natürlich praktisch, Normal-View wäre auch identisch mit der Fenstergröße beim Programm öffnen (und vielleicht fix einstellbar)! So könnte man die Gestaltung der Oberfläche daran anpassen. Wenn nun auch noch gleich beim Programmstart das letztgeladene Projekt gestartet würde... Besten Dank für die schnelle Realisierung der Aktivierungs-Statusmeldung! Daraufhin kann dann der MC anfangen zu senden. Ein kurzes OFF in der Textbox (oder natürlich mit einem der kostbaren Taster ;) schaltet die Dauersendung dann wieder ab. Da fällt mir ein, eigentlich könnte das auch eine Statusmeldung bei Programmbeendigung besorgen! Abdul K. schrieb: > Bei uns im Südosten ist das Wetter gut. Gottseidank auch nicht zu heiß. Kann ich bestätigen ;) Gruß aus Lkr. AÖ!
Moby schrieb: > So könnte man die Gestaltung der Oberfläche daran > anpassen. Ich seh gerade mit aktuellem Programm /.ini wird das Layout ja richtig abgespeichert. Bliebe also nur noch der Punkt mit dem Projekt-Autoload.
Martin Schwaikert schrieb: > ./. schrieb: >> Wen die $25 nicht stoeren, kann sich ja mal MakerPlot ansehen. > > Wen die 50.000 Euro nicht stören, kann sich ja mal nen gebrauchten > Porsche ansehen. Ist zwar auch ganz nett, tut hier aber ebensowenig zur > Sache. @Martin Nun gehörst du definitiv auch zu meinen "Lesenswerten". Aber zum Projekt: Wenn es open source wird, hat es gewaltige Vorteile gegenüber allen anderen Möglichkeiten. Leider kann ich da nicht händisch mitwirken, weil das mindestens drei Nummern zu groß für mich ist, aber ich würde mich sehr darüber freuen und zusätzlich sicher wieder so einiges lernen. Schon mal hier vielen Dank von mir an den TO!
Hier mal ein Entwicklungs Snapshot des neuen Zeichenoberfläche Instruments als Video. Der Link: http://youtu.be/f9ffNbZoO5U Alles was auf der Zeichenoberfläches zu sehen ist wurde vom Mikrocontroller (Arduino Uno programmiert mit LunaAVR) generiert und an den PC geschickt. Die Übertragungsgeschwindigkeit beträgt hier 115200 baud. Das Ganze belegt den Flash zu 9% und das SRAM mit 4,8%. Das Luna Programm habe ich mal zur Info beigefügt. Es erhebt keinen Anspruch auf Schönheit oder Optimierung, eben Quick&Dirty für einen schnellen Test. Die vorläufige Befehlsliste sieht so aus: Clear Grafik § CG < Pen Color § PC n < Brush Color § BC n < Brush Style § BT n < Plot Point § PP x ; y < MoveTo § MT x ; y < LineTo § LT x ; y < Plot Line § PL x1 ; y1 ; x2 ; y2 < Plot Rectangle § PR x1 ; y1 ; x2 ; y2 < Fill Rectangle § FR x1 ; y1 ; x2 ; y2 < Plot Circle § CP x ; y ; r < Plot Text § PT x ; y ; Size ; Text < Mal sehen wann es soweit für das Release ist. Da gibt es noch so einiges dran zu werkeln, beim Textbackground angefangen :) P.S. Keine Ahnung warum Firefox beim Aufruf der obigen Textdatei so ein sonderbares Zeichen jedesmal vor einem § einfügt. Das gehört da nicht hin. Ladet euch die Datei einfach mit "Ziel speichern unter", dann ist es OK.
:
Bearbeitet durch User
Originelle Idee. Ich könnte mir als Einsatzscenario das Zeichnen von aktuellen Kurvenbildern vorstellen.
Albert M. schrieb: > P.S. Keine Ahnung warum Firefox beim Aufruf der obigen Textdatei so ein > sonderbares Zeichen jedesmal vor einem § einfügt. Das gehört da nicht > hin. Ladet euch die Datei einfach mit "Ziel speichern unter", dann ist > es OK. Firefox zeigt die Textdatei als Nicht-Unicode-Text an, du hast das aber mit UTF-8 geschrieben. Wenn man die Anzeige im Firefox manuell auf Unicode umstellt, sieht es auch im Firefox ok aus. /Hannes
>Alles was auf der Zeichenoberfläches zu sehen ist wurde vom >Mikrocontroller (Arduino Uno programmiert mit LunaAVR) generiert und an >den PC geschickt. Hallo Albert, schöne Software. Es freut mich auch, dass es jetzt Zeichenfunktionen wie von mir vorgeschlagen gibt: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Gruß, chris_
Albert M. schrieb: > Nach erfolgreicher Aktivierung der Schnittstelle > sendet das Programm optional ein > #OK< oder #OK<CR oder #OK<CRLF In V0.45d momentan nur selten. Meist erhält man beim Online-Schalten CR LF C O N N, und das unabhängig von der Einstellung und ob überhaupt aktiviert. Leider wird die Einstellung auch nicht im Projekt gespeichert.
Moby schrieb: > erhält man beim Online-Schalten CR LF C O N N ... und ich sehe gerade beim Online-Schalten kommt noch sehr viel mehr, was da nicht kommen sollte. Lese das gerade in einen 16 Byte Ringbuffer ein.
Angehängte Dateien:
-
SendOnInterfaceStart1.jpg
470 KB -
SendOnInterfaceStart2.jpg
480 KB -
SendOnInterfaceStart3.jpg
490 KB
Moby schrieb: > In V0.45d momentan nur selten. > Meist erhält man beim Online-Schalten CR LF C O N N, > und das unabhängig von der Einstellung und ob überhaupt > aktiviert. Dann stimmt wohl was an Deiner Schnittstelle nicht. Bei mir werden #OK< ,#OK<CR oder #OK<CRLF immer korrekt übertragen. Die Einstellungen stimmen auch. (Siehe auch Bilder oben, Test bei 115200 baud) Moby schrieb: > Leider wird die Einstellung auch nicht im > Projekt gespeichert. Hatte ich vergessen, kommt in der nächsten Version.
:
Bearbeitet durch User
Albert M. schrieb: > Dann stimmt wohl was an Deiner Schnittstelle nicht. Dann bin ich einigermaßen ratlos. Denn sämtliche Instrumentencodes werden korrekt übertragen. Und in der Vielzahl an Bytes, die ich beim Onlineschalten erhalte, finden sich auch nur "plausible" Ascii-Zeichen <80H.
Angehängte Dateien:
-
SendOnInterfaceStart4.jpg
84 KB -
SendOnInterfaceStart5.jpg
96 KB
Vielleich verschluckt sich ja Deine Empfangsroutine daran, dass beim aktivieren der Schnittstelle diese 2 mal auf Null gezogen wird und erst danach das #OK< gesendet wird (siehe Bilder oben). Das Nullziehen lässt sich allerdings nicht vermeiden. Mein Logic-Analyzer interpretiert das Nullziehen jeweils als 0xF0 (240).
:
Bearbeitet durch User
Hallo Albert, bitte laß Dich von mir an diesem heißen Tag nicht dauernd an den PC nötigen ;) Möglicherweise ist dieses wie auch das Problem mit dem zuweilen scheiternden Online-Start auf Eigenarten meiner seriellen Bluetooth-Anbindung zurückzuführen. Demnächst werde ich mal den Puffer vergrößern und die genaue Bytefolge beim Starten in voller Länge posten, vielleicht kannst Du daraus noch was erkennen. Ich verwende auf MC Seite einen (nicht weiter konfigurierten) 19200er BTM220, auf PC-Seite einen BT-Stick. Wie gesagt, alles andere klappt soweit und ist mir schon mal von großem Nutzen!
Das neue Paint-Instrument #56 macht gute Fortschritte. In das Paint-Instrument (Grösse skalierbar) lässt sich vom Mikrocontroller in Realtime zeichnen und es kann somit als Ersatz für ein Grafik-Display am MC fungieren. Auf das Paint-Instrument lassen sich auch die bereits vorhandenen Instrumente platzieren, so dass man komplexe interaktive Oberflächen gestalten kann. Es stehen aktuell die folgenden Commandos zur Verfügung: Clear Graphic § CG < Set Graphic Size (opt.) § SG x1 ; y1 < Pen Color § PC n < (zulässig n 0 bis 8) Brush Color § BC n < (zulässig n 0 bis 8) Brush Style § BT n < (zulässig n 0 bis 3) Plot Point § PP x ; y < MoveTo § MT x ; y < LineTo § LT x ; y < Plot Line § PL x1 ; y1 ; x2 ; y2 < Plot Rectangle § PR x1 ; y1 ; x2 ; y2 < Fill Rectangle § FR x1 ; y1 ; x2 ; y2 < Plot Circle § CP x ; y ; r < FloodFill § FF y ; Y < Plot Text § PT x ; y ; Text < Text Size § TS n < (zulässig n 7 bis 42) Die Farben sind so zugeordnet: 0=weiss 1=schwarz 2=rot 3=blau 4=grün 5=gelb 6=grau 7=hellgrün 8=hellblau Brush Style: 0=bsClear 1=bsSolid 2=bsCross 3=bsDiagCross Ein Befehl um eine Line zu zeichnen sieht dann z.B. so aus: §PL100;50;200;75< wobei die Konstanten natürlich durch Variablen ersetzt werden können. Die aktuelle Grösse der Zeichenfläche wird unten im Paint-Instrument angezeigt. Zusätzlich kann optional vom MC aus die Grösse der Zeichenfläche festgelegt werden mit: Set Grafik Size § SG x ; y < Der MikroController kann optional die aktuelle Grösse der Zeichenfläche abfragen. Nach Senden von #56M1< vom MC an den PC schickt dieser die Grösse als #56Mx,y< zurück. Als Parameter für das Paint-Instrument sind nur 0 und positive Integer-Werte erlaubt. Der Koordinaten-Ursprung 0,0 liegt unten links. Die Skalierung bezieht sich auf Bildschirm-Pixel. Der PaintBox Inhalt kann über einen unten befindlichen Clear-Button manuell gelöscht werden. Vielleicht habe ich ja noch was Nützliches vergessen?
:
Bearbeitet durch User
Moby schrieb: > die genaue Bytefolge beim Starten in voller Länge posten CR LF C O N N E C T LEERZ. LEERZ. ' 0 0 0 2 - 7 2 - C 9 0 E 9 7 ' CR LF ' CR LF Gegen Ende variiert das ein bischen, meist ein paar 30H und 20H mehr, oder (in seltenen Fällen) tatsächlich dann noch #OK< wie eingestellt. Egal. Geschenkt. Eigentlich ist noch viel wichtiger, daß die Verbindung auf Dauer steht, wenn sie steht. Albert M. schrieb: > Der PaintBox Inhalt kann über einen unten befindlichen Clear-Button > manuell gelöscht werden. > > Vielleicht habe ich ja noch was Nützliches vergessen? Also für meine Begriffe und ohne Testmöglichkeit schaut das schon recht rund aus. Für statische Inhalte wär evt. noch eine Grafik nützlich, die man der Zeichenfläche hinterlegen könnte! So wie überhaupt kleine einfügbare Grafiken und Schriften das Projektfenster auch sehr bereichern könnten ;)
Moby schrieb: >> die genaue Bytefolge beim Starten in voller Länge posten > CR LF C O N N E C T LEERZ. LEERZ. ' 0 0 0 2 > - 7 2 - C 9 0 E 9 7 ' CR LF ' CR LF > Gegen Ende variiert das ein bischen, meist ein paar 30H und 20H mehr, > oder (in seltenen Fällen) tatsächlich dann noch #OK< wie eingestellt. Das ist definitiv kein Problem meiner Software, sondern Deiner Bluetooth Adapter. Da kann ich Dir leider auch nicht weiterhelfen.
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.46 Video dazu: http://youtu.be/-MDE-uhb8tQ Change Log v0.46 ---------------- Neues Paint-Instrument #56 In das Paint-Instrument kann vom Mikrocontroller in Realtime gezeichnet werden. Dafür stehen aktuell die folgenden Kommandos zur Verfügung: Graphic Clear § GC < Pen Color (Stiftfarbe) § PC n < (zulässig n 0 bis 9) Brush Color (Füllfarbe) § BC n < (zulässig n 0 bis 9) Brush Style (Füllmuster) § BS n < (zulässig n 0 bis 3) Plot Point § PP x ; y < MoveTo § MT x ; y < LineTo § LT x ; y < Plot Line § PL x1 ; y1 ; x2 ; y2 < Plot Rectangle § PR x1 ; y1 ; x2 ; y2 < Fill Rectangle § FR x1 ; y1 ; x2 ; y2 < Plot Circle § CP x ; y ; r ; 0 < Plot Text § PT x ; y ; Text < Text Size § TS n < (zulässig n 7 bis 42) optional: Set Graphic Size § GS x1 ; y1 < [noch nicht implementiert] Set Graphic Position § GP x1 ; y1 < [noch nicht implementiert] Die Farben sind so zugeordnet: 0=weiss 1=schwarz 2=rot 3=blau 4=grün 5=gelb 6=grau 7=hellgrün 8=hellblau 9=hellgrau Brush Style: 0=bsClear 1=bsSolid 2=bsCross 3=bsDiagCross Ein Befehl um eine Line zu zeichnen sieht dann z.B. so aus: §PL100;50;200;75< wobei die Konstanten natürlich durch Variablen ersetzt werden können. Die aktuelle Grösse der Zeichenfläche wird unten im Paint-Instrument angezeigt. Als Parameter für das Paint-Instrument sind nur 0 und positive Integer-Werte erlaubt. Der Koordinaten-Ursprung 0,0 liegt unten links. Die Skalierung bezieht sich auf Bildschirm-Pixel. Der PaintBox Inhalt kann über einen unten befindlichen Button manuell gelöscht werden. Es sind bisher nur die hier angegeben Features implentiert. Das Manual/Hilfe zeigt bereits geplante zusätzliche Möglichkeiten. Weitere Änderungen: ------------------- Die opt. Schnittstellen-Einstellungen (Send Interface Status) werden nun zum aktuellen Projekt gespeichert. Neuer Programm-Parameter "Fenster immer im Vordergrund" kann unter "Optionen" eingestellt werden. Nützlich um z.B. die Grafik im Paint-Instrument zu schützen. Durch die neuen zusätzlichenen Einträge in der ini-Datei sollten zur ordungsgemässen Funktion alle gespeicherten Projekte mit den neuen Einstellungen nochmals abgespeichert werden.
:
Bearbeitet durch User
Angehängte Dateien:
-
sci.jpg
180 KB -
sci-error.jpg
12 KB -
sci-error1.jpg
17 KB
Nachdem man mit Alberts Programm unverhofft schnell zu einer Windows-GUI für sein MC-System kommen kann will ich hier mal schnell mein aktuelles Provisorium zeigen (MC-Seite noch nicht fertig); zur Anregung und für ein paar kurze Anmerkungen. Von der Größe her ist es an die im Programm definierte Normal-View definierte Fenstergröße angepaßt und in aller Regel erscheint das Projekt auch so wie abgespeichert. Manchmal fehlt (oder verrutscht) unten die Text-Eingabe Box, was durch kurzes Neuaufrufen des Instruments in der Buttonleiste aber schnell korrigiert ist. Zu den oben links verwendeten LED-, 7Segment, Taster- und DIP-Schalter Instrumenten sind mir bislang noch keine Besonderheiten aufgefallen. Die vier hübschen bunten numerischen Displays können leider leider keine negativen Werte anzeigen, was ich aber für die Außentemperatur bräuchte... Läßt sich das noch hinbiegen und ein Minus Zeichen mit einbauen? Hat im Command-Textstring noch nicht die erhoffte Wirkung... Beim Start der beiden Slider rechts daneben erscheinen beim Start die Reglergriffe nicht, erst beim ersten Hineinklicken. Feature oder kleiner optischer Fehler? Die grüne Mini-Trendanzeige funktioniert glücklicherweise , und anders als in der Beschreibung angegeben, auch mit TimeScale > 100, so daß auch ein 24h Rückblick gelingt. Manchmal werden die Anzeige-Wert Grenzen nicht mit abgespeichert bzw. resetten sich auf die Voreinstellung. Überhaupt wär es schön, könnte man diese via MC einstellen um den abgedeckten Messwert-Bereich etwas variieren zu können, ohne an "optischer Auflösung" zu verlieren. Auch ein paar mehr Kanäle wären nicht schlecht, die Full-Trend Instrumente sind mir da schon zu groß. Mangels Anzahl an einzelnen Textanzeigen habe ich meinen großen Haufen an Messwerten (umschaltbar) in das blaue Aktiv-Label rechts verfrachtet. Wenn man ein bischen mit Fontgröße und gesamter Zeichenzahl spielt klappt das auch ganz gut. Den Zeilenumbruch organisiert das Instrument zwar auch selbst, es war hier aber besser, manuell mit CRLF nachzuhelfen. Seit V0.46 hab ich aber irgendwie das Problem, daß die Textausrichtung partout nicht dauerhaft speicherbar ist !? Eine weiteres blaues Aktiv-Label unten links dient als Debug-Anzeige zur Überwachung eines Speicherbereichs. Dessen Startadresse und weitere Text-Kommandos an den MC lassen sich wunderbar über die Input-Box darunter absetzen. Die Aktiv-Label Textbox daneben (fehlt als Bookmark in der Hilfe-PDF) stellt Meldungen aller Art dar- anders als im PDF angegeben sollte/kann man hier aber auf Zeilenvorschub Code verzichten. Was ich mir für die Zukunft an Instrumenten wünschen würde sind auf jeden Fall ein paar mehr Taster, ggf auch Schalter (mit LED-Status?). Albert M. schrieb: > Das ist definitiv kein Problem meiner Software, sondern Deiner Bluetooth > Adapter. Sicher. Was diesen ominösen CONNECT String betrifft scheint das was BT-typisches beim Herstellen der Verbindung zu sein. Auch ein Stickwechsel brachte diesbezüglich keine Änderung. Hingegen klappt das Herstellen der Verbindung nun viel öfter. Allerdings, nach vielstündigem Programmlauf (V0.45d) stoppt die Anzeige- und beim Neuverbinden bzw. Programmbeenden erscheinen neue Fehlermeldungen... Da werde ich wohl noch ein wenig mit verschiedenen BT Adaptern experimentieren müssen ;-( OK Albert, danke soweit, nach der schönsten Zeit des Jahres gehts für mich im Juli mit dem Testen/Optimieren weiter! Moby
Angehängte Dateien:
-
aNumDisplay.jpg
30 KB
@Moby Danke für den ausführlichen Testbericht. Moby schrieb: > Die vier hübschen bunten numerischen Displays können leider leider keine > negativen Werte anzeigen, was ich aber für die Außentemperatur > bräuchte... Läßt sich das noch hinbiegen und ein Minus Zeichen mit > einbauen? Hat im Command-Textstring noch nicht die erhoffte Wirkung... Bitte bedenke, dass der notwendige Format-String bei der Instrument-Definition auch das Vorzeichen als Stelle sieht. Z.B. für Temperaturen von -99,0 bis 99,0 Grad sollte der so aussehen: ##0.0 also 3 Stellen vor dem Komma, wobei die erste Stelle dann das Minus-Zeichen ist (siehe Beispielbild mit ###0.0 und zugehörigen LunaAVR-Programm oben). Alle anderen Punkte muss ich mir mal in Ruhe ansehen :)
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.46a Change Log v0.46a ----------------- Neues Instrument#78 Stufenschalter Protokoll: #nMm< wobei n = 78 und m = Wert Datenrichtung: vom PC zum MC Im Unterschied zum Slider Rund Instrument können hier nur Werte in festen Schaltstellungen eingestellt werden. Die Anzahl der Schaltstellungen ist wählbar. Das Stufenschalter Instrument schickt bei Änderung den eingestellten Wert an den Mikrocontroller. Mit der Mouse kann am Drehrad der Wert eingestellt werden. Solange der Drehknopf des Stufenschalters rot leuchtet, wird der Wert noch nicht gesendet. Dies geschieht erst beim Loslassen der Mousetaste. Change Log v0.46 ---------------- Es gibt jetzt ein Paint-Instrument (PaintBox) #56. In das Paint-Instrument kann vom Mikrocontroller in Realtime gezeichnet werden. http://www.youtube.com/watch?v=-MDE-uhb8tQ&feature=youtu.be
:
Bearbeitet durch User
Angehängte Dateien:
-
Nullmodem_com0com.jpg
110 KB
SerialComInstruments ganz einfach testen ---------------------------------------- Ladet euch unter http://sourceforge.net/projects/com0com/ den "Null-modem emulator" com0com runter und installiert diesen. Während der Installation die Anfragen wegen nicht signierter Treiber einfach akzeptieren. Die Installation dauert etwas, nicht vorzeitig abbrechen. Beim Aufruf von com0com wird eine Brücke (Nullmodem) zwischen zwei virtuellen ComPorts erstellt, z.B. Com13 und Com14. Stellt in SerialComInstruments den ComPort auf 13 und in einem Terminal-Programm (HTerm, Termite usw) den ComPort auf 14. Nun könnst ihr händisch die Kommandos eingeben und zu SerialComInstruments schicken oder von dort Daten empfangen ohne einen Mikrocontroller angeschlossen zu haben. Damit erspart man sich in der Testphase das dauernde Umprogrammieren des Mikrocontrollers.
:
Bearbeitet durch User
Hallo Herr Albert M. Herzlichen Dank für Ihre Arbeit. Bei größeren Projekten ist es sehr hilfreich den Überblick zu bewahren. Ich habe mit Hilfe der Version 0,44 einen Druckerzeuger gebaut und programmiert. Er kann Drücke im Bereich -0,8 bis 2 Bar erzeugen. Ohne Ihr Programm wäre es mir sehr schwer gefallen dies zu realisieren. Danke auch für die Möglickeit der Speicherung, hier wird die Arbeit stark beschleunigt. MFG Schnik
Anbei eine virtualisierte, portable Version des letzten Build SerialComInstruments V0.46a Alle benötigten Zusatz-Files, wie Help-PDF, Doku, DLL usw. befinden sich innerhalb der virtualisierten exe-Datei und werden bei der Ausführung NICHT auf die Festplatte entpackt oder irgendwo sonst gespeichert. Die File-Emulation geschieht ausschliesslich im PC-RAM-Speicher. Die exe-Datei ist in einem beliebigen Ordner, auch direkt vom Desktop, sofort ausführbar (den Ordner Windows/Programme sollte man meiden). Wenn das einem von euch nützlich ist, dann bitte melden.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.46b Change Log v0.46b ----------------- Im Paint Instrument ist jetzt optional ein Hintergrundbild/Zeichnung ladbar. Der Datei-Verweis auf das Hintergrundbild wird mit zum Projekt abgespeichert. Über das Hintergrundbild kann in Realtime vom MC gezeichnet werden, wobei der Inhalt des Hintergrundbildes nicht zerstört wird. Im Bild oben werden die farbigen vertikalen Balken jeweils auf das Rohrleitungs-Hintergrundbild gezeichnet.
:
Bearbeitet durch User
Das ist schon Hammer, was du da so kurz hintereinander raus haust. Vielen Dank dafür!
Angehängte Dateien:
-
Navi01.jpg
98 KB
Vorschau auf neues Navi-Instrument zur Datenanzeige von den entsprechenden Sensoren. Hierzu auch ein Video: http://youtu.be/Eiktfdpeg0Q
Einen alternativen Download meiner diversen Software Projekte gibt es ab jetzt hier auf meiner neuen Web-Präsenz: http://www.SerialComInstruments.com Ist noch im Aufbau, aber bereits funktionsfähig.
:
Bearbeitet durch User
Hier scheint es ein Konkurrenzprojekt zu geben: http://hackaday.com/2014/06/21/meet-the-widgeduino/#more-124858
Neue Version SerialComInstruments V0.46c Change Log v0.46c ----------------- Neuer Menue-Punkt "Neues Projekt". Löscht alle selektierten Instrumente und setzt alle Optionen auf Standard-Werte zurück. Das Paint Instrument kann nun vom Mikrocontroller positioniert und in der Grösse verändert werden mit § GP x1 ; y1 ; x2 ; y2 < ( Beispiel: §GP300;50;500;400< ) wobei x1 ; y1 Position obere linke Ecke des Instruments x2 ; y2 Breite + Höhe des Paint Instrument Displays Ursprung 0 ; 0 ist links oben auf der Show Oberfläche Der Download ist auf meiner Website verfügbar: http://www.serialcominstruments.com/
Albert M. schrieb: > Einen alternativen Download meiner diversen Software Projekte Also zukünftig nix mehr alternativ: Albert M. schrieb: > Neue Version SerialComInstruments V0.46c > > Der Download ist auf meiner Website verfügbar: > http://www.serialcominstruments.com/ ?
Version SerialComInstruments V0.46c Change Log / neue Features siehe im Thread oben. Um automatisch eine Information über neue Versionen zu bekommen, ist es sinnvoll, sich auf meiner Webseite unter Downloads einzutragen: http://www.serialcominstruments.com/ Irgendwann innerhalb der nächsten Monate wird der Download neuer Versionen nur noch über meine Webseite verfügbar sein. Informationen über Neuigkeiten wird es hier aber natürlich weiter geben.
:
Bearbeitet durch User
Damit hast du dann den Status eines ebay-Links! (Nichts gegen deine großzügige Arbeit. Das ist ein anderes Thema)
Angehängte Dateien:
-
Bild_zum_Video.jpg
160 KB
Und hier mal ein neues Video von SerialComInstruments v0.46c: http://youtu.be/ulQhq3CBnFE Webseite: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Welche Datenrate akzeptieren Deine Instrumente?
@Messer Die meisten Instrumente akzeptieren eine Datenrate von bis zu 100.000 Samples/s oder mehr. Das nützt Dir aber nichts, weil Du diese Rate nicht über die serielle Schnittstelle bekommst, da die Daten ja noch in ein Protokoll verpackt sind und als String geschickt werden. Dann hängt das Ganze natürlich auch noch von der Leistung Deines PC's ab. 2.000 bis 3.000 Samples/s über die Schnittstelle sind aber normalerweise machbar, bei Optimierung oder bei Test über eine com0com Verbindung (siehe im Thread weiter oben) bis zu 10.000. Sinnvoll sind hohe Datenraten allerdings nur für das XY-Graph / FFT-Instrument und das Paint-Instrument. Die beiden Trend Instrumente haben einen langsamen Vorschub für die Darstellung von Vorgängen im Zentel-Sekunden bis Stunden/Tage Bereich. Informationen über das Protokoll und die Instrumente findest Du im Manual hier: http://www.serialcominstruments.com/SerialComInstruments%20Doku.pdf Wenn Du nur einen oder 2 schnelle Kanäle brauchst, ist vielleicht mein anderes Programm SerialComGrapher was für Dich: http://www.serialcominstruments.com/serial.php Ich bastele noch an einem neuen Programm (schnelles Scope) mit reiner Binär-Datenübertragung über die serielle Schnittstelle. Das erreicht bei meinen Tests bis zu 30.000 Samples/s in der Übertragung und Darstellung. Das Projekt ist aber z.Z. auf Eis gelegt. Vielleicht krame ich das im Herbst wieder raus :)
:
Bearbeitet durch User
Danke, Albert für die Info. "Ich bastele noch an einem neuen Programm (schnelles Scope) mit reiner Binär-Datenübertragung über die serielle Schnittstelle." Das wäre super. Ich hoffe, die Blätter fallen frühzeitig in diesem Jahr :).
Albert M. schrieb: > Bitte bedenke, dass der notwendige Format-String bei der > Instrument-Definition auch das Vorzeichen als Stelle sieht. Ja danke für den Hinweis. Nun zeigt sich auch das Minuszeichen. Das numerische Display zeigt übrigens etwas irritierend 1,0 an wenn der Command-String Anzeigewert (auf MC-Seite uninitialisiert) noch keine Ascii-Zahlenwerte, sondern nur 0 enthält. Hier wärs besser es reagiert darauf einfach nicht.
Anbei neue Version SerialComInstruments V0.47 Change Log v0.47 ---------------- Erweiterung des XY Instrument #58 / #59 mit Fast Y-t Anzeige. Schnelle Scope-Modus Anzeige bis zu 5.000 Samples/s. Max. Anzahl Samples 1.000.000 Die X-Achse ist dabei in Samples/Pixel skaliert. Erweiterung des XY Instrument #58 / #59 mit Pan/Zoom. Die Anzeige kann jetzt gezoomt, sowie horizontal und vertikal verschoben werden. Der Stufenschalter #78 kann optional vom Mikrocontroller gestellt werden. Er ist somit altenativ auch Anzeige. Der Sendebefehl hierzu: #78Mn< wobei n = Schalterstellung Überarbeitung des User Interface / Edit Mode Es werden jetzt zur Vereinfachung beim Click auf ein Instrument nur noch die Umrisse, nicht aber die event. darin enthaltenen Componenten markiert. Danke, dass sich so viele auf meiner Homepage eingetragen haben. Die autom. Benachrichtigung über neue Versionen dauert noch etwas, da ich noch mit meinem Provider klären muss, ob Bulk-Mails gestattet werden. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, auch die neue 0.47 enthält leider noch das lästige Resetten der Wertvorgaben beim Minitrend und das Nichtabspeichern der Textausrichtung beim Aktiv-Label. Ist das ein größeres Problem? Ansonsten find ichs natürlich prima daß die Entwicklung auch im Sommer weitergeht ;)
@Moby Die Bugs werden in der nächsten Version korrigiert. Moby schrieb: > Ansonsten find ichs natürlich prima daß die Entwicklung auch im Sommer > weitergeht ;) Das schlechte Wetter zur Zeit steigert die Motivation :)
Hallo Albert M. wir habe das Beste Wetter in FFM - Ironman.de. VG Uwe
Albert M. schrieb: > Erweiterung des XY Instrument #58 / #59 mit Fast Y-t Anzeige. > Schnelle Scope-Modus Anzeige bis zu 5.000 Samples/s. > Max. Anzahl Samples 1.000.000 Die ca. 5.000 Samples/s wurden mit einem ATMega 168-20 übertaktet mit 22,118400 MHz und 460800 Baud von mir gemessen. Ich habe noch diverse Bugs gefunden. Eine korrigierte Version kommt schnellstens.
:
Bearbeitet durch User
Angehängte Dateien:
-
Bild_v047a.jpg
82 KB
Anbei neue Version SerialComInstruments V0.47a Change Log v0.47a ----------------- Alignment-Fehler bei Active Labels #35 #36 behoben. Ladefehler beim Mini-Trend Instrument behoben. Diverse Fehler im X-Y Y-t FFT Instrument behoben. Hilfe/Manual überarbeitet.
Albert M. schrieb: > Alignment-Fehler bei Active Labels #35 #36 behoben. > Ladefehler beim Mini-Trend Instrument behoben. Danke! Funktioniert!
Albert M. schrieb: >> Erweiterung des XY Instrument #58 / #59 mit Fast Y-t Anzeige. >> Schnelle Scope-Modus Anzeige bis zu 5.000 Samples/s. >> Max. Anzahl Samples 1.000.000 > > Die ca. 5.000 Samples/s wurden mit einem ATMega 168-20 übertaktet mit > 22,118400 MHz und 460800 Baud von mir gemessen. Mit einem Arduino Uno (16 MHz Quarz) und Einstellung auf 500.000 Baud schafft man ca. 3.200 Samples/s. Habs gerade mal getestet.
Vorschlag: Mausklick "Instrument" für die Standard-Fenstergröße: Sendet Mausposition relativ zu Ecke bei Klick in Hintergrund(bild)bereich. Auf einen Schlag mehr als genug Eingabetaster ;-)
Angehängte Dateien:
-
SCI_EventLoger.jpg
44 KB
Was haltet ihr von einem neuen Instrument "Ereignis Logger"? Ich würde dafür den Kanal #86 (Start: #86M1< , Stop: #86M0< )vorsehen. Die Zeiten und Datum werden von der PC-Uhr abgeleitet, die Differenzzeit zwischen Ein und Aus von einem High-Precission Timer im Programm, der nicht vom Windows Timer abhängig ist und in einem eigenem Task läuft. Die Anzeigegenauigkeit der Zeitdifferenz ergibt sich aus folgender Überlegung: Die Genauigkeit des High Precission Timers liegt bei 1/1000s und spielt bei den weiteren Betrachtungen keine Rolle. Die Übertragungszeiten der Entsprechenden Kommandos vom MC zum PC betragen ca. 1,5 bis 2 ms incl. Verarbeitung im PC bei 115200 baud). Allerdings sind diese 1,5 ms kein konstanter Wert, ebensowenig die Zeit bis zur nächsten Übertragung, sondern abhängig von der PC-Auslastung und PC-Interrupts für andere Windows Tasks. Nach meinen Tests erreicht man bei einer gewünschten Genauigkeit von 0,01 Sekunden im Allgemeinen mehr als 99,99% korrekte Werte, aber ab und an eben Ausrutscher bis zu 0,5 Sekunden. Deshalb ist die Frage, ob man die Zeitdifferenzauswertung im Millisekunden Bereich nicht besser dem MC überlässt und sich hier auf die Differenzanzeige in h:min:s beschränkt.
:
Bearbeitet durch User
Berechnungen von Zeitdifferenzen aller Art bleiben besser in der Hand des MC, der das mit seinen Timern genauer erledigen kann. Für die Anzeige von Ereignissen steht bereits eine Textbox zur Verfügung. Für meinen Geschmack verzettelst Du Dich etwas, wenn Du nun mit "PC Serviceaufgaben" (Ermittlung von Zeitdifferenzen, demnächst vielleicht ganzen Berechnungen) eine neue Baustelle aufmachst, die mit der eigentlichen Intention des Programms = Visualisieren von MC I/O Daten mit ansprechenden Instrumenten nicht viel zu tun hat. Aber bei der Programmentwicklung ist ja oft die Tendenz zu beobachten, daß Software lieber mit immer neuen Features aufgebläht wird anstatt erstmal die Grundfunktionalität zu perfektionieren ;-) Bitte nicht bös verstehen, soll nur eine konstruktive Kritik sein!
Angehängte Dateien:
Vorschau auf die nächste Version: Es ist unter anderem ein Visual Designer für die Vertikal Meter Instrumente implementiert. Mit Click auf den "Test Settings" Button werden die Einstellungung in das Beispiel-Instrument zur Voransicht übernommen. Das vereinfacht die Konfiguration erheblich, da die Einstellungen nun ohne dauerndes Hin- und Herschalten zwischen den Seiten betrachtet werden können. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ich finde die Idee mit dem "Ereignis Logger" sehr gut, auch wenn ich das Instrument klassisch als Stoppuhr bezeichnen würde. Wie lange braucht das Schreiben auf SD-Karte, wie lange braucht der Akku bis er voll ist. Auf dem Controller zu implementieren ist das recht aufwendig und die Funktionalität wird oft nur für die Entwicklung, nicht für die Anwendung benötigt. Ich würde die Funktion so wählen: #86M0< Start/Reset #86M1< Stopp/Zwischenzeit Ausgabe: Reset 00:00:00.00 (14:24:32 10.07.2014) Stopp 00:00:00.12 (14:24:32 10.07.2014) Stopp 00:00:01.22 (14:24:33 10.07.2014) Reset 00:00:00.00 (14:24:45 10.07.2014) Stopp 00:00:09.56 (14:24:55 10.07.2014) Es spricht ja nichts dagegen, auf einen Startpunkt mehrere Stoppzeiten zu liefern. Auch interessant könnte noch sein, Stopp-Marken mitzuschicken, also #86M1< liefert Stopp 1, #86M3< liefert Stopp 3. So könnte man zwischen Ereignissen unterschieden. Ausgabe: Reset 00:00:00.00 (14:24:32 10.07.2014) Stopp 2 00:00:00.12 (14:24:32 10.07.2014) Stopp 1 00:00:01.22 (14:24:33 10.07.2014) Stopp 2 00:00:09.56 (14:24:55 10.07.2014) Grüße Tommi
Ich stimme da den Argumenten von Tommi für ein Timer Instrument zu. Also kommt ein neues Instrument #86 Stop Watch / Time Event Logger. Vorläufige Befehle für Timer Channels n (1 und 2): Stop all Ch. #86M00< Stop, im Log anzeigen Reset/Start all Ch. #86M01< Alle Ch. auf Null, Start, anzeigen Show all Ch. #86M02< Akt. Wert aller Ch. anzeigen Stop Ch. n #86Mn0< Ch. n im Log nicht mehr anzeigen Reset/Start Ch. n #86Mn1< Ch. n auf Null, Start, anzeigen Show Channel n #86Mn2< Akt. Wert Ch. n anzeigen Show Event n #86M9n< Anzeige "Event n" Die Anzeigen im Log erfolgen immer mit dem Timer-Wert und der aktuellen Zeit. Das Show Event dient als zusätzliche Markierungsmöglichkeit. Eventuell kommen noch an das Instrument Checkboxen zur Auswahl welche Channels ins Log übernommen werden. Ob die Anzeige eine Auflösung von 10 ms oder 100 ms zeigt weiss ich noch nicht. Wie gesagt, mein Timer ist auf 1 ms genau, aber die Probleme habe ich ja bereits oben beschrieben. Mal schauen...
:
Bearbeitet durch User
Hier noch eine kleine Fehlermeldung und eine funktionellen Erweiterung: Die Textbox #38 speichert im Projekt zwar die Zeilen, aber nicht die Einfügerichtung. Instrumente, die nicht selber Daten bei ihrer Bedienung senden (Textbox, Aktiv-Label, LEDs) könnten bei Mausklick darauf (optional) ihre Kennung an den MC senden damit dieser damit ggf. was sinnvolles anstellen kann!
Angehängte Dateien:
Hier mal so einige Ergebnisse mit dem neuen Timer/Stop Watch Instrument. Das neue Instrument soll und kann die internen MC Timer nicht ersetzen, sondern bietet eine einfache, schnelle Möglichkeit etwas längere Vorgänge auf dem MC zu vermessen ohne die MC-Timer zu benötigen. Testverfahren: Auf dem MC wurde ein Delay mit 50 ms kontinuierlich vermessen. Die Genauigkeit der Messung beträgt immer ca. 5 ms, unabhängig von der Messdauer. Ab und an gibt es Ausrutscher wenn der PC mit höher priorisierten Task beschäftigt ist. Das kommt allerdings recht selten vor. Das Bild (2) zeigt eine Messung mit Reset/Start und Show Command. Das Bild (3) eine Messung mit Start/Reset und darauf folgender Schleife mit Show, wobei die Auflaufenden Messzeiten hier zusätzlich nummeriert und akkumuliert werden. Ein abgespeckter kurzer MC-Befehlssatz "> Kanal Befehl <"ist für die beiden Timer-Kanäle und den Event-Kanal völlig ausreichend: Ch1 Reset/Start: >11< CH1 Show >12< Ch2 Reset/Start: >21< CH2 Show >22< Event n >9n< Die Messzeiten können zwischen 10ms und einigen Tagen betragen. Zusätzlich ist zum schnellen groben Test für längere Vorgänge eine manuelle Zeitmessung über die beiden Start und Show Buttons vorgesehen. Das Ganze habe ich übers Wochenende mit einem ziemlich alten PC getestet. Am Montag versuche ich das mal auf meinem eigenem schnellen PC. Mal sehen ob sich da noch Unterschiede in der Genauigkeit ergeben.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.48 http://www.serialcominstruments.com/ Change Log v0.48 ---------------- Neues Instrument #86 StopWatch / TimeLog. Das neue Instrument soll und kann die internen MC Timer nicht ersetzen, sondern bietet eine einfache, schnelle Möglichkeit etwas längere Vorgänge auf dem MC zu vermessen ohne die MC-Timer zu benötigen. Die Messgenauigkeit beträgt ca. 5 ms, die Messzeiten können bis zu einigen Tagen betragen. Fehlmessungen um die 100 ms können allerdings dann auftreten, wenn der PC mit höher priorisierten Task beschäftigt ist. Der MC-Befehlssatz "> Kanal Befehl < sieht so aus: Ch1 Reset/Start: >11< Setzt Zähler und Zeit auf zurück. CH1 Show >12< Zeigt die Zeit an und inkrementiert danach den Zähler. Bei succesiven Aufrufen werden die Zeiten akumuliert. Event n >9n< Vermerkt das Event n incl. Zeit im Log. Auf der TimeView Seite des Instruments kann der Timer auch manuell über die Start- und Show-Buttons als Stopuhr benutzt werden. Visual Designer für Vertikal Meter Instrumente implementiert. Vereinfacht die Konfiguration erheblich, da die Einstellungen jetzt direkt anhand des Beispiel Instrumentes betrachtet werden können. Baudrateneinstellung um 250.000 und 500.000 Baud erweitert. Diese Baudraten können bei einem 16 MHz Quarz (z.B. Arduino) zusätzlich benutzt werden. Beim Full Trend Instrument gibt es eine neue Eigenschaft "Thick". Ist dieses Feld markiert, werden die Linien der Kurvenverläufe in doppelter Breite angezeigt. Alle Trend- und XY-Instrumente haben jetzt einen einheitlichen weissen Hintergrund. Dies kann aber teiweise geändert werden. Fehler behoben: Aktiv Status von Instrument #52 wird gespeichert. Textbox #38 speichert die Einfügerichtung.
:
Bearbeitet durch User
Angehängte Dateien:
Was haltet ihr von einem neuen realtime Video-Instrument? Funktionen: - Erkennt autom. eine USB-Webcam - Stellt eine Scene in Realtime dar - Speichert auf Befehl vom MC ein Bild - Speichert bei Click auf Button ein Bild - In der Grösse skalierbar - Speichert optional alles als Video im AVI-Format Das Bild oben zeigt einen erfolgreichen Test. Bei dem beschissenen Wetter kommen einem die kuriosesten Ideen :) Zu der neuen Version 0.48 im Beitrag oben: StopWatch_Beispiel.txt zeigt natürlich das Vorgehen OHNE Akkumulation, sorry für die falsche Betitelung im Code.
:
Bearbeitet durch User
Noch ein paar weitere Vorschläge, Albert! - PC spielt ein bestimmtes Lied - PC scannt ein Dokument ein - PC zeigt ein Bild an - PC fragt Mails ab - PC druckt etwas - PC browst im Internet - PC schickt ein Fax - PC kalkuliert und rechnet aus - PC speichert Dokumente - PC tut noch dies und das Mag nicht schwarzmalen, aber irgendwann laufen MC- und PC System 24h funktionell zwangsweise im Verbund und es stellt sich die Frage, warum der PC dann nicht gleich selbst -alles- übernimmt :-)
@ Moby So wie Du meine Ideen ins lächerliche ziehen möchtest zeigt nur die Dir fehlende Vorstellungskraft. Ich bin froh, dass mir mit meinen 64 Jahren die Ideen und Visionen noch nicht abhanden gekommen sind. Die Einsatzmöglichkeiten für ein Video-Instrument, welches über einen MC gesteuert wird halte ich ich für vielfältig: Dokumentation eines Versuches, event. auch in extremer Nahansicht, in dem die entscheidenden Augenblicke auch automatisch als Bild festgehalten werden. Erstellung einer Zeitraffer-Doku über das Versuchs-Geschehen. Erfassung von Zustandsänderungen mit Rückmeldung an den MC. Und so weiter. Du wolltest schon das vorige Instrument torpedieren und fährst nun damit fort. Such Dir doch einfach eine andere Software wenn Dir meine nicht gefällt. Wirst allerdings schwerlich was vergleichbares kostenloses finden.
Instrumente torpedieren? Entschuldigung,na so will ich jetzt bestimmt nicht verstanden werden. Es steht Dir natürlich frei zu programmieren was Dir mit 64 in den Sinn kommt- mal sehen in welchem Schweizer Taschenmesser das noch endet :-) Hab doch auch schon ganz andere Worte für Dein Programm gefunden. Mittlerweile hab ich V0.47a "produktiv" im Einsatz. Sie enthält das allerallernötigste, wenn auch an allen Ecken und Enden limitiert. Mir wäre eine Bezahlversion mittlerweile lieber, die mit einigen Begrenzungen aufräumt und niemand mit dem unguten Gefühl zurückläßt, Deine umfangreiche Arbeit für lau zu verwenden. OK- nun ist es aber das Mindeste, Deine Motivation nicht weiter mit allzukritischen Bemerkungen zu torpedieren (hier paßt das Wort wohl).
Albert M. schrieb: > Was haltet ihr von einem neuen realtime Video-Instrument? Albert du bist einfach super. Vorschlag meinerseits: Wenn Neider, Hasser dich umringen dann denk an Götz von Berlichingen ;-). P.S. Kannst du dir vorstellen das ganze unter Open Source zu veröffentlichen?
@ Moby Sorry, ich hab da vielleicht ein wenig überreagiert :) Der Rächer der Transistormorde schrieb: > Kannst du dir vorstellen das ganze unter Open Source zu veröffentlichen? Nein. In der Software stecken einige zugekaufte spezielle Delphi Components (Mathe, Grafik usw) im Wert von über 2000 Euro, die ich mal für meine privaten Projekte beschafft habe. Teilweise sind diese nur bei der von mir verwendeten Delphi 7 Prof. Version verwendbar. Für die Delphianer hier: Ich besitze zwar auch eine neue Delphi XE Version, die ist mir aber zu aufgebläht und unhandlich. Am effektivsten geht das Coden immer noch mit dem ollen Delphi 7. Neue Instrumente schaffe ich damit meistens in wenigen Stunden.
:
Bearbeitet durch User
Mögen Dir die nützlichen Ideen nicht ausgehen, Albert. Daß man auch mit 64 noch große Programme schreiben kann stimmt mich mit gleichem Hobby einigermaßen hoffnungsfroh :-)
Habe das Gefühl hier sind ganz schön viele "alte Säcke". Anfangs dachte ich immer ich gehöre zu den Ältesten hier. Aber mittlerweile sehe ich, dass viele in meinem Alter sind und hier durchaus noch viel ältere werkeln. Übrigens, auch von mir, toll gemacht alles!
Es müßten doch viel mehr alte Säcke hier sein als Junge. Die Geburtenstarken Jahrgänge sind nun um die 50 und die Kinderrate pro Frau ist momentan bei 1,4. Also tippe ich mal drauf, daß der Berg bei ca. 40 ist.
Nutz jemand dieses Programm mit einem Arduino Leonardo oder Micro? Ich sehe im Arduino Serial Monitor die erwarteten Zeichenfolgen "#40MWert<". In HTerm kommen diese erst nachdem DTR gesendet/gesetzt wurde. Mit SerialComInstruments ist mir bisweilen noch kein Erfolg gegönnt. Evtl. kann mir jemand auf die Sprünge helfen. @Albert: Ist es eventuell möglich im Interface die Funktion "DTR setzen" einzubauen?
Eisi schrieb: > Nutz jemand dieses Programm mit einem Arduino Leonardo oder Micro? Ich teste die Software immer mit einem Arduino Uno oder Nano, die ich meist mit Luna programmiere. > Ich sehe im Arduino Serial Monitor die erwarteten Zeichenfolgen > "#40MWert<". > In HTerm kommen diese erst nachdem DTR gesendet/gesetzt wurde. In HTerm kommt bei mir von den Arduinos immer alles sofort. Schau Dir auch mal weiter oben im Thread das Problem von Thomas Forster an. Der hatte unbemerkt ein nicht darstellbares Steuerzeichen (DC4) in den Befehlsstrings eingemogelt. Vielleicht ist das bei Dir auch ähnlich der Fall. Auch HTerm stellt anscheinend nicht wirklich alle Zeichen korrekt dar. Das von mir für das Paint-Instrument benutzte § kann HTerm seltsamerweise nicht anzeigen. Eisi schrieb: > Ist es eventuell möglich im Interface die Funktion "DTR setzen" > einzubauen? Da die DTR Leitung ja physikalisch nicht benutzt wird, möchte ich im ComPort DTR auch nicht setzen. Man weiss nicht welche blöden Nebeneffekte ausgelöst werden. Da es bei mir und allen anderen Anwendern ja problemlos funktioniert, tippe ich bei Dir auf andere Ursachen.
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments V0.48a http://www.serialcominstruments.com/ Change Log v0.48a ----------------- User-Interface Skalierungsfehler behoben. Bei Einstellungen der Bildschirm-Textgrösse in Windows/Systemeinstellungen auf 100% / 125% / 150% wurden verschiedene Instrumente nicht richtig skaliert oder teilweise beschnitten.
:
Bearbeitet durch User
Hallo Zusammen, da ich gerade ein wenig mit den SirialComInstruments herumspiele, hier ein kleines Template für einen Arduino Uno:
1 | // Zeichnen einer Sinuskurve mit SerialComInstruments |
2 | |
3 | void setup() |
4 | {
|
5 | Serial.begin(9600); |
6 | } |
7 | |
8 | // Senden eines Telegramms an den PC |
9 | void sendInt2Instrument(float MWert,byte InstrNr) |
10 | {
|
11 | Serial.print('#');
|
12 | Serial.print(InstrNr); |
13 | Serial.print('M');
|
14 | Serial.print(MWert); |
15 | Serial.print('<');
|
16 | } |
17 | |
18 | #define MINITREND 90 |
19 | #define POINTSPERSINWAVE 100 |
20 | #define AMPLITUDE 50 |
21 | #define OFFSET 50 |
22 | |
23 | void loop() |
24 | {
|
25 | static float t=0; |
26 | sendInt2Instrument(AMPLITUDE*sin(2*PI/POINTSPERSINWAVE*t)+OFFSET,MINITREND); |
27 | t++; |
28 | Serial.println(""); // CR
|
29 | delay(100); |
30 | } |
chris_ schrieb: > Serial.print('#'); > Serial.print(InstrNr); > Serial.print('M'); > Serial.print(MWert); > Serial.print('<'); Ich habe von den Sprachkonventionen beim Arduino eigentlich keine Ahnung, aber das kann man doch sicher in eine Zeile verpacken. Etwa so? Serial.print('#');(InstrNr);('M');(MWert);('<'); chris_ schrieb: > Serial.println(""); // CR Diese Zeile ist nicht notwendig und wird vom Command Processor ignoriert. Als Ende-Zeichen für einen Befehl reicht das "<" aus-
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.48b http://www.serialcominstruments.com/ Change Log v0.48b ----------------- Neues Instrument #87 Trigger. Hiermit ist es möglich in einstellbaren Intervallen von 50 ms bis zu 24 Std kontinuierlich eine Benachrichtigung an den MC in Form der Zeichenkette #T zu senden. An die Zeichen #T kann optional CR und/oder LF angehängt werden. Die eingegebenen Werte müssen mit dem SET-Button bestätigt werden. Mittels des Test-Buttons wird #T jeweils nur einmalig beim Click gesendet.
:
Bearbeitet durch User
Albert M. schrieb: > Neues Instrument #87 Trigger. Damit kann dann die Benachrichtigung bei Verbindungsherstellung (die im Falle von Bluetooth-Connects ohnehin nicht richtig funktioniert) wunderbar ersetzt werden und der MC weiß jetzt jederzeit, wann bzw. daß seine GUI zu bedienen ist. Diese Art Instrumente müsste man (für diesen Einsatzfall) nur noch auf 'unsichtbar' schalten können.
Moby schrieb: > Damit kann dann die Benachrichtigung bei Verbindungsherstellung (die im > Falle von Bluetooth-Connects ohnehin nicht richtig funktioniert) Du erweckst hier den Anschein als hätte meine Software generell mit Bluetooth Adaptern Probleme. Wenn Du den von Dir benutzten Adapter nicht sauber funktionsfähig bekommst, so liegt das am verwendeten Adapter oder an Dir. Meine Software ist nach aussen nichts anderes als ein simples Terminal. Das heisst sie nimmt wie jedes beliebige Terminal-Programm Daten über die serielle Schnittstelle entgegen. Wenn dein Bluetooth Teil da zickt und die Daten korrupt sind, solltest Du das Problem wo anders suchen (siehe auch Deine Beiträge dazu oben im Thread).
:
Bearbeitet durch User
Albert M. schrieb: > Wenn dein Bluetooth Teil > da zickt Mittlerweile habe ich vier verschiedene ausprobiert und es zeigt sich was die Verbindungsherstellung betrifft stets das gleiche Bild: Der Status-String kommt nicht sauber an. Das muß ja nichts mit dem Programm zu tun haben sondern könnte auf irgendwelche Besonderheiten bei der Herstellung serieller Bluetooth-Verbindungen zurückgehen. Vielleicht ist noch ein anderer Anwender in der gleichen Situation und kann dazu was rückmelden.
@ Moby Ich könnte ja mal testeshalber in der nächten Version einen Delay für die Status Übertragung einbauen. Will heissen, nach Aktivierung der Schnittstelle in SerialComInstruments wird eine bestimmte Zeit (einstellbar 10 bis 500 ms) gewartet bevor der Status-String gesendet wird. Vielleicht hilft das? Vorab würde ich Dir eine so geänderte Version zum Test auch per Mail schicken. Wenn Interesse melde Dich über meine Email-Adresse (findest Du im Program unter Hilfe/Info).
:
Bearbeitet durch User
Albert M. schrieb: > Vielleicht hilft das? Das wäre zu probieren, ist für mich aber spätestens seit dem neuesten Instrument kein vordringliches Problem mehr. Interessant wäre trotzdem, welche Erfahrungen da andere Anwender machen! Auf jeden Fall können verschiedene Sticks recht unterschiedlich "zicken". Mein aktueller "Hama Nano-Bluetooth-USB-Adapter Version 2.1 + EDR Class2" garantiert immerhin jetzt durchgehend störungsfreien Betrieb ;-)
Albert M. schrieb: > Wenn Du den von Dir benutzten Adapter nicht > sauber funktionsfähig bekommst, so liegt das am verwendeten Adapter oder > an Dir Nun stellt sich raus: weder - noch! Noch gar nicht gedacht hatte ich an den 3.Akteur: Das verwendete BTM220 auf MC-Seite! Nach intensivem Testen einer neuen Version von Alberts Programm mit hundertfachem On/Offlineschalten der Verbindung kam es jetzt wieder zu den weiter oben gezeigten Fehlermeldungen: Der serielle BT-Port auf Dauer nicht mehr ansprechbar, obwohl laut Gerätemanager funktionierend. In der Vergangenheit ging es dann -irgendwann, irgendwie- wieder: mit neuem BT-Stick, nach kurzem Deaktivieren, Ausstecken, Booten, einfach abwarten... Heute aber nach kurzem Power-OFF auf MC/BT Seite: Problem spontan gelöst. Nun liegt natürlich genauso die Vermutung nahe, daß das verwendete BTM220 auch für den Datensalat bei Verbindungsherstellung verantwortlich zeichnet. Das Modul wird unkonfiguriert kontinuierlich via DMA mit Daten befeuert, was von den beobachteten Phänomenen abgesehen eigentlich auch prima und auf Dauer funktioniert.
Anbei neue Version SerialComInstruments V0.48c http://www.serialcominstruments.com/ Change Log v0.48c ----------------- Änderung im Meue "Interface". Unter "Send Interface Status" kann eine Delay-Zeit von 5 ms bis zu 500 ms für das Senden der Status-Information an den MC eingestellt werden. Dies kann event. hilfreich für den Betrieb mit z.B. Bluetooth-Adaptern usw. sein. Änderung beim Trigger Instrument: Der zum MC gesendete String ist jetzt zur Vereinheitlichung von #T auf #T< geändert. Div. Bugs behoben: Instr #58/#59 X-Y-Graph wurde nicht mehr angezeigt. Weitere User-Interface Skalierungsfehler behoben für Windows Anzeigen-Einstellungen auf 100% / 125% / 150%. Fehler beim Umschalten Edit/Run-Mode.
:
Bearbeitet durch User
Hallo Albert, ich habe mir die neueste Version geladen und experimentiere nun fleißig. Allerdings habe ich ein paar "Bugs". 1: Befinde ich mich in "Instruments" und wähle z.B. Instrument 1. Dann kann ich alle Parameter einstellen und klicke sodann auf "Werte zuweisen". Danach ist aber der komplette rechte Frame einfach nur noch weiß. 2: Ich befinde mich im Edit-Mode. Dann gehe ich zu "Instruments" und ändere etwas. Nach einem Klick auf "Zuweisen und Show" bin ich nun nicht mehr im Edit-Mode. Warum? Liegt es an meinem Rechner?
Kryptoenergie schrieb: > Befinde ich mich in "Instruments" und wähle z.B. Instrument 1. > Dann kann ich alle Parameter einstellen und klicke sodann auf "Werte > zuweisen". > Danach ist aber der komplette rechte Frame einfach nur noch weiß. Das ist schon richtig so. Mit "Zuweisen" ist ja Deine Eingabe der Parameter für dieses Instrument abgeschlossen. Jetzt kannst Du ein anderes Instrument für die Parametrisierung wählen. Oder eben mit "Zuweisen und Show" die Werte übernehmen und zur "Show" Seite wechseln. Allerdings sollte das rechte Frame nicht weiss sondern grau werden; wird demnächst geändert(bei mir ist es grau). Kryptoenergie schrieb: > Ich befinde mich im Edit-Mode. > Dann gehe ich zu "Instruments" und ändere etwas. > Nach einem Klick auf "Zuweisen und Show" bin ich nun nicht mehr im > Edit-Mode. > Warum? Sobald man vom der "Show" Seite zu einer anderen Seite wechselt, wird grundsätzlich der Edit-Mode beendet. Gruss Ulrich Albert
Verbesserungsvorschlag für die #99 Texteingabebox: Absenden der Eingabe via Entertaste! Der Button wäre damit im Prinzip überflüssig.
Moby schrieb: > Verbesserungsvorschlag für die #99 Texteingabebox: > Absenden der Eingabe via Entertaste! Der Button wäre damit im Prinzip > überflüssig. Für die nächste Version war für die Textbox#99 bereits vorgesehen: Senden als "#99Mtext<" und alternativ freie Eingabe mit: "text"
Hier mal ein Beispiel-Programm für einen ATMega 328, geschrieben in LunaAVR, für die Kommunikation zwischen MC (Arduino) und SerialComInstruments.
:
Bearbeitet durch User
Anbei eine korrigierte Version SerialCom2a.
Hallo Albert, Alternative zum LunaAVR Programm. Anbei ein Bascom Beispiel Programm (eines von mehreren Möglichkeiten) um die gesendeten Instrumenten(Daten) vom PC auf dem MC zu dekodieren. Die Daten werden per Interrupt mit dem UART eingelesen, bei Bedarf muss die Länge des Empfang-String angepasst werden. Gruß biker10
Ich würde ja die Daten der von einem Trend Instrument gemalten Kurven in einer Datei aufzeichnen, um sie mit anderer Software auszuwerten. Weiss jemand wie das geht?
Hallo Albert! Ich bin von deinem Programm begeistert. Ich bezeichne mich durchaus noch als Anfänger, habe es aber innerhalb einer viertel Stunde hinbekommen, mir Daten vom µC anzuzeigen und ihm welche zu schicken. Einfach nur genial. Alles echt einfach gehalten. Großes Kompliment an dich. Ich werde für dein Programm sicher noch viele Verwendungsideen finden, ich werde es gespannt mitverfolgen, wie es weiter geht und wenn ich eine Idee für eine Neuerung habe, schreib ich sie hier rein. Dennis
Alberts kreative Schaffenspause habe ich mal genutzt, um die Möglichkeiten des Programms auf seiner seriellen Leitung zum eigenen MC-System etwas mit externer Software zu "erweitern". Auf der Agenda: Mehr Eingabe-Buttons und die Verbindung zu mobilen Android/iOS Geräten. Bis zu 100 zusätzliche Eingabetaster auf der seriellen Leitung bietet das mindestens ebenso simpel benutzbare "Serial Buttons". Etwas anspruchsvoller ist es dann schon, den Output auf die Leitung von SerialComInstruments zu bekommen. Da Windows serielle Ports dummerweise nicht für mehrere Programme gleichzeitig öffnet, werden serielle Portssplitter bzw.Portsharer nötig. Kostenlose Möglichkeiten bieten hierzu zum Beispiel das com0com/hub4com Projekt oder der "Virtual Serial Ports Emulator" in der 32-Bit Version. Daß die ganze Angelegenheit nicht unbedingt trivial ist zeigen die Schwierigkeiten, die auftauchen, wenn die Ansprüche weiter steigen: Bei seriellen Bluetooth-Anschlüssen und modernen 64-Bit Windowsversionen wird die Luft leider zusehens dünner. Das Feld beherrscht dann nur noch Kaufsoftware, deren Preis schon anzeigt, daß sich die Macher der exklusiven Funktionalität bewußt sind. Eltima und Fabulatech Serial Port Splitter heißen die beiden hervorstechenden Kandidaten. Als Lieferant für serielle Steuerstrings drängt sich seitens Android/iOS die App von netio.davideickhoff.de geradezu auf. Damit lassen sich elegant praktische Bedien- und Anzeigeoberflächen für die eigene Steuerung gestalten. Auf PC-Seite ist dann nur noch die Umsetzung von TCP->COM Port vonnöten, die z.B. der kostenlose "HW Virtual Serial Port" bewerkstelligt. Im Rahmen eines "Complex Bundle" bei Eltima wird dieser Port neben den anzulegenden virtuellen Ports für SCI und SB ins Routing zum MC-Steuerungs COM-Port einbezogen (Fabulatech scheiterte an dieser Aufgabe). Fortan füttern 3 serielle Quellen auf einer Leitung die eigene MC-Steuerung. Bootfest.
:
Bearbeitet durch User
Hi Moby AVR, Du schreibst: >genutzt, um die Möglichkeiten des Programms auf seiner seriellen Leitung zum >eigenen MC-System etwas mit externer Software zu "erweitern"." Hast Du da etwas konkretes zum Herunterladen? Bzgl. der gleichzeitigen Nutzung eines Com-Ports mittels zweier Programme bei Win7 64bit habe ich dieses kostenlose gefunden: "GpsGate Client for Windows" http://gpsgate.com/download Das funktioniert nicht nur für GPS-Anwendungen...
Ha, Freude verflogen. GPSgate funktionierte einmal, nun lässt es sich nicht erneut starten (auch nach neuem Boot nicht).
War mein Fehler. Man muss einen Icon in der Taskleiste anklicken, dann geht es.
Messer schrieb: > Das funktioniert ... nur mit drahtgebundenen Com-Ports oder auch mit (vielen) beliebigen anderen im System vorhandenen virtuellen Ports? In beide Richtungen? Auch unter Win8? Danke für den Tipp. Kannst Du mal genauer beschreiben wie/womit Du das Programm einsetzt? Die von mir zitierte Software lässt sich relativ schnell im Web finden.
Uneingeschränkt funktionsfähig ist offensichtlich nur die kostenpflichtige Standardlizenz, wie http://gpsgate.com/purchase/gpsgate_express_license vergleichend zeigt. Immerhin- ein günstiger Einstieg, wenn denn alles so wie beschrieben funktioniert !?
Moby AVR schrieb im Beitrag #3782687: > Immerhin- ein günstiger Einstieg, wenn denn alles so wie beschrieben > funktioniert !? Ja, funktioniert wie beschrieben. Man muss aber abwarten wie es nach der 14-tage Testphase weitergeht, denn offensichtlich läuft so lange die Vollversion. Aber laut Beschreibung sollte das was bei mir jetzt geht auch in der Freeware-Version so bestehen bleiben: Habe einen BT-Stick als Com19, an den schliesse ich die virtuellen Ports 10 und 12 an und kann beide gleichzeitig benutzen. Andererseits ist auch die Vollversion deutlich billiger als die beiden anderen genannten. Was netio.davideickhoff.de eigentlich macht (machen kann) erschloss sich mir aus der webseite nicht... Daher die Frage nach einem konkreten Beispiel.
Messer schrieb: > Habe einen BT-Stick als Com19, an den schliesse ich die virtuellen Ports > 10 und 12 an und kann beide gleichzeitig benutzen. Dann Toi toi toi daß für Dich alles auch weiter so funktioniert! Die Kaufversion dürfte zumindest fällig werden, da nach Ablauf der Testphase "Virtual port as input" wegfällt, die für SerialComInstruments ja nötig ist. Ähnliches gilt wohl für die Bluetooth-Funktionalität, die mögliche Anzahl virtueller Ports und die Boot-Festigkeit via "Run as a service". Messer schrieb: > Was netio.davideickhoff.de eigentlich macht ... ist, die den Bedienelementen (Buttons, Schalter, Labels) hinterlegten, frei definierbaren Strings bei Anklicken über WLAN zu versenden und ggf. auch eine Rückantwort (Messwerte) in der selbstgestalteten App-Oberfläche anzuzeigen. Die erhaltenen Daten muß man PC-seitig dann nur noch auf den Com-Port bringen (z.B. via "HW Virtual Serial Port"). Probiers mal ob das auch geht. Was dann noch fehlt ist ein erfolgreicher Test unter Win8- erst dann komm ich selbst mit dem Kauf der Eltima-Software in Zweifel ;-)
:
Bearbeitet durch User
Ich kann nur ein grosses Lob aussprechen, mit der Hoffnung, dass Alberts kreatíve Phase bald wieder belebt wird und der Feinschliff fortgesetzt wird. Übrigens, ich habe die Bildergalerie auch angeschaut: genial, ein Augenschmaus!
So ein Programm habe ich schon lange gesucht. Einfach, leicht zu lernen und zu bedienen. Ich werde versuchen, damit eine Pumpensteuerung mit Arduino Uno zu visualisieren und bei Forschungsprojekten mit NMR-Spektrometern einzusetzen. Da ich auch Funkamateur bin, suche ich schon lange so etwas um eine Oberfläche für einen simplen Networkanalyzer zu realisieren. Mal sehen, was ich so hinbekomme. Vielen Dank lieber Albert für diese ausgezeichnete Software und weiterhin viel Erfolg damit. Michael, DH3KC
Sand schrieb: > Ich kann nur ein grosses Lob aussprechen, mit der Hoffnung, dass > Alberts kreatíve Phase bald wieder belebt wird Nun ist erst mal ein anderes Projekt dran. Albert hatte sowieso nur die letzten kalten Winterabende zugesagt und dann doch bis in den Sommer hinein dran gearbeitet. Also Geduld, wird schon wieder was kommen, siehe Albert M. schrieb: > Für die nächste Version war ... bereits vorgesehen... Zumal der nächste Winter naht ;-) Und für neue sinnvolle Funktionalitäten gibts ohnehin noch genug Luft nach oben.
Hi, wie kann ich mehrere identische Instrumente (zum Daten senden) erzeugen? Ich brauche viele Slider Nr. 83. Danke.
Moby schrieb: > Und für neue sinnvolle Funktionalitäten gibts ohnehin noch genug Luft > nach oben. So eine sinnvolle Funktionalität wäre meines Erachtens eine doppelte frei skalierbare Skala an den vertikalen Instrumenten mit einem Zeiger, wobei z.B. die rechte und die linke ein frei wählbares Format aufweisen könnte. So könnte man mit einem Blick sofort den vom µP produzierten Wert und den zugeordneten Wert in einer physikalischen Einheit ablesen. Als Nebeneffekt kommt hinzu, dass man im Programm keine Umrechnungen vornehmen muss.
Pit schrieb: > Ich brauche viele Slider Ja, an Ideen, Wünschen und Ansprüchen herrscht nie Mangel ;-) Genau zwei vertikale Slider (#82,#83) sind aber die nackte Realität. Sand schrieb: > wäre > könnte Schaun wir mal, wann und wie die Entwicklung überhaupt weitergeht. Ist ja alles auch eine ziemliche Arbeit. In der Zwischenzeit kann man sich aber mit dem Erreichten durchaus arrangieren- ich würde auf das Programm auch so wie es jetzt ist nicht mehr verzichten wollen!
Verstehe ich Recht, das es mit dem Programm - so, wie es jetzt ist - nur moeglich ist, auf 4 "Kanaelen" zu senden - mit 4 verschiedenen Instrumenten? Ich hatte gehofft, dass ich nur zu bloed bin, das Programm zu bedienen. Gibt es Alternativen fuer ein GUI, welches es erlaubt, viele verschiedene Parameter zu senden?
Pit schrieb: > Verstehe ich Recht, das es mit dem Programm - so, wie es jetzt ist - nur > moeglich ist, auf 4 "Kanaelen" zu senden - mit 4 verschiedenen > Instrumenten?> > Ich hatte gehofft, dass ich nur zu bloed bin, das Programm zu bedienen. > Gibt es Alternativen fuer ein GUI, welches es erlaubt, viele > verschiedene Parameter zu senden? Klar gibt es so einige Alternativen. Kannst Du alle so zwischen 2000 und 5000 Euro günstig kaufen. Stichwort Scada. Dann gibt es auch ne Alternativen um die 200 Euro. Den wirren Käse möchtest Du aber wahrscheinlich nicht konfigurieren und bedienen. Oder bastel Dir was mit LabView. ist allerdings das selbe was den wirren Käse betrifft. Warte doch mal ab was noch kommt. Wenn Du nicht warten willst, musst Du zahlen, siehe oben. Das Meckern kannst Du lassen: Einem geschenkten Gaul schaut man nicht ins Maul.
Alternate schrieb: >> Gibt es Alternativen fuer ein GUI, welches es erlaubt, viele >> verschiedene Parameter zu senden? ... oder schreib Dir das, meinetwegen in VisualBasic oder Phyton, selber. Viele Parameter senden wirst Du ja damit wohl noch gebacken bekommen.
Pit schrieb: > Verstehe ich Recht, das es mit dem Programm - so, wie es jetzt ist > - nur moeglich ist, auf 4 "Kanaelen" zu senden - mit 4 verschiedenen > Instrumenten? Nein. Du kannst genau sovielen Instrumenten serielle Strings lt. Protokoll senden wie eben Instrumente in Deinem Projekt ebensolche empfangen können. Und bekommst alle seriellen Strings jener Instrumente, die welche zurückschicken können. Fixe Kanäle gibts da nicht.
Nach Lektuere der Handbuchs, weiss ich nur von den Instrumenten 80-83, welche eine Zahl senden koennen. Offensichtlich kann ich jedes "Sendeinstrument" im Programm nur einmal verwenden. Jedenfalls habe ich auch im Protokoll keinen Hinweis auf einen Instrument Index gefunden. Nur Instrument Nummer + dazugehoeriger Wert. Habe ich etwas uebersehen? Ich braeuchte ca. 20 moeglichst identische Slider. Klar kann man das auch selbst schreiben, ich dachte nur, dass ist ein ziemliches Standardproblem, welches moeglicherweise schon zig Mal von anderen geloest wurde. Das Rad muss ja auch nicht jedes Mal neu erfunden werden, wenn jemand irgendwohin will...
Pit schrieb:
> Ich braeuchte ca. 20 moeglichst identische Slider.
Dann nimm einen, zB. #80 und den Mäuseklavier. Damit kannst du den
Slider im µP Programm adressieren, zuordnen und da hast du 256 Stück.
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.48d Change Log v0.48d ----------------- Änderungen am Trigger-Instrument #87: Mit dem periodischen Triggersignal kann zusätzlich ein Zahlen-Parameter gesendet werden (Eingabebox "P-Set"). Zulässig ist hier eine Integer-Zahl im Bereich -999999 bis +999999. Dieses Feature eignet sich besonders beim Testen von Mikrocontroller Projekten, na ja, bei mir wenigstens :) Alle Optionalen Parameter können über die entsprechenden Checkboxen Param, LF und CR zum Senden gewählt werden. Mittels des Test-Buttons wird #T + Param + LF + CR< jeweils beim Click einmalig zum Test gesendet. Bugs behoben: Taster #70...#73 Position wurde nicht korrekt gespeichert. Das 2. Bild Oben zeigt alle zur Zeit verfügbaren Instrumente. Gruss Ulrich Albert Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ich habe den PID Regler ausprobiert und festgestellt, dass die Sollwert-Anzeige über die PID Parametereinstellung nicht funktioniert. Eine Wertzuweisung wird ausschließlich durch Instrumenten-Vorkonfiguierung übernommen. Der rote Sollwertzeiger schrumpft nach einer Weile zum mickrigen Pünktchen zusammen.
Das ist kein PID-Regler, sondern eine PID-Console. Der PID-Regler läuft auf Deinem MC.
Du hast recht, aber es ändert nichts an der Tatsache. Ich kann die Sollwertanzeige nicht beeinflussen durch Parameter-Eingabe. OS W7 32 Bit
Im Meue "Instrumente" lässt sich die Sollwertangabe einwandfrei einstellen. Aber direkt am Instrument unter "PID-Param" auf der "Show" Seite geht es tatsächlich nicht. Behelfe Dich einfach mit der Einstellung auf der "Instrument" Seite, solange das nicht korrigiert ist.
So habe ich auch gedacht und gemacht. Übrigens, der Sollwert wird zum MC gesendet, und auf andere Weise lässt sich einwandfrei darstellen.
Der obige Fehler mit dem PID-Sollwert wird in der nächsten Version korrigiert. Sollten sonst noch Wünsche für die kommende Version da sein, bitte melden.
Hallo Albert, mein Wunsch wäre eine weitere Kanalaktivierung im Instrument #51--#54 Gruß Sand PS. warum kann ich eine -auf einem anderen PC erstellte- und importierte .ini Datei nicht laden?
Guten Abend Albert, noch offnene Wünsche meinerseits: - Absenden der Eingaben in der #99er Textbox via Enter-Taste - vom MC parametrierbarer (oder automatisch verschobener) angezeigter Messbereich im Minitrend Instrument für größeren Messbereichsumfang bei stets optimaler Anzeige-Auflösung - Mauskoordinaten (oder gröber Gitterstandort) senden (relativ zum Programmfenster-Ursprung) bei Klick in alle passiven Anzeigeinstrumente und ungenutzten Flächen. Grüsse, Moby
Danke für die Rückmeldungen. Sand schrieb: > warum kann ich eine -auf einem anderen PC erstellte- und importierte > .ini Datei nicht laden? Keine Ahnung, bei mir geht es. Wie sehen denn bei Dir die Fehlermeldungen aus? Das Einzige was ich mir jetzt vorstellen kann, dass es Probleme mit verschieden grossen Monitoren gibt, weil ja in der ini-Datei die Koordinaten der Instrumente und die Fenster-Koordinaten des Programms (Position auf dem Monitor) gespeichert werden. Dies dürfte allerding das Laden der ini-Datei keinesfalls behindern. Ansonsten werden keine systemrelevanten Daten in der ini-Datei mitgeführt.
Hallo Albert, Ich bekomme nicht mal Fehlermeldung . Die dollargrüne Fläche bleibt unverändert. Zugegeben, die Bildschirmgröße ist unterschiedlich. Ich habe auch versucht in der .ini Datei die Bildschirmgröße anzupassen - vergeblich. Ich werde aber weitere Versuche unternehmen. Der Fehler liegt mit Sicherheit bei mir. Gruss Sand
Sand schrieb: > Ich bekomme nicht mal Fehlermeldung . Die dollargrüne Fläche bleibt > unverändert. Ich habe jetzt die Fehler-Ursache entdeckt: In der ini-Datei wird als Header aller Objektbeschreibungen/Properties jeweils der benutzte Dateipfad mitgeführt, z.B.: [FormMain\D:\_TestAll.INI\Instr81_BevelOuter\Offset] Jetzt ist das Problem, dass dieser Header von einer speziellen Delphi Komponente (die ich nicht ändern kann) jeweils vor die Instrumente-Properties gesetzt wird. Diese Komponente erzeugt das komplette ini-File für alle Instrumente soweit automatisch. Auf die Schnelle kann ich daran nichts ändern. Kurzfristige Abhilfe: Speichere deinen Konfiguration (ini-Datei) unter z.B. c:\iniDaten\ und richte das selbe Verzeichnis auf deinem 2. PC ein und kopiere die ini-Datei dort hin. Ich hoffe das hilft Dir erst mal weiter. Den Fehler hatte ich zuerst nicht bemerkt, weil ich auf meinen PC's bereits die gleichen Verzeichnisse benutzt hatte.
:
Bearbeitet durch User
Ich konnte nun doch schneller als erwartet das Konfigurations(ini)-File Problem lösen. Ab der nächsten Version ist das ini-File portabel und führt demnach nicht mehr die Drive- und File-Namen als Header für die Instrumenten mit. Allerdings: Das neue ini-File Format ist nicht mit der alten Version kompatibel, d.h. es können keine alten ini-Files mehr geladen werden.
Das ist Support! ich mache schon mal Screenshots um die Portierung zu erleichtern :-)
Anbei neue Version SerialComInstruments V0.48e Change Log v0.48e ----------------- ini-File: Gespeicherte Konfigurations(ini)-Files jetzt portabel. Allerdings: Das neue ini-File Format ist nicht mit der alten Version kompatibel, d.h. es können keine ini-Files mit dem alten Format mehr geladen werden. PID-Instrument: Eingegebener Sollwert wird jetzt richtig in die Anzeige übernommen. Input-Box Instrument: Der eingegebene Text kann optional auch mit der Enter/Return-Taste gesendet werden.
Albert M. schrieb: > es können keine ini-Files mit dem alten Format mehr geladen werden D.h. bestehende Projekte müssen mit der aktuellen Version komplett neu erstellt werden? Vielen Dank Sand ;-)
Moby schrieb: > D.h. bestehende Projekte müssen mit der aktuellen Version komplett neu > erstellt werden? Vielen Dank Sand ;-) Ja ist nun mal so. Alternativ könntest Du z.B. mit einem Texteditor mittels Suchen&Ersetzen die Dateihinweise in den zu rettenden ini-Files entfernen. Beispiel: Aus [FormMain\D:\BeispielInstrument.INI\Instr44_FontValue\Style] wird [FormMain\Instr44_FontValue\Style] Also suchen nach \D:\BeispielInstrument.INI\ und ersetzen durch \
Kein großes Problem, Albert. Wenn es denn die Sache robuster & zukunftsfester macht... Danke für den Workaround Tipp.
Habe Problem mit dem Serial Communication Inetrface: Es sind nur Com Ports bis 20 auswählbar, mein Arduino UNO verwendet aber Com Port 41 ! Daher kann ich das nich "connecten". Gruss Kalle
mausi_mick schrieb: > Es sind nur Com Ports bis 20 auswählbar, mein Arduino UNO verwendet aber > Com Port 41 ! Dann änder im GeräteManager den Port auf irgendwas bis 20. Sollten die Ports als belegt erscheinen, aber nicht benutzt sein, einfach überschreiben und Windows Fehlermeldung ignorieren. Ansonsten mal selbst die Initiative ergreifen und Google fragen "belegte com ports freigeben", da wird einem geholfen.
Wem die Möglichkeiten der schon erwähnten Freeware SerialButtons nicht ausreichen, dem kann ich das kostenpflichtige Tool N-Button empfehlen: Attraktive und funktionell vielseitig konfigurierbare Taster, Schalter u.v.m. frei platzierbar auf dem Desktop.
Hallo Albert! Super Projekt. Ich spiele gerade mit den Instrumenten herum und hab es auch schon geschafft dass meine µC - Haussteuerung auf Basis Atmel 644 mit deinen Tools Kontakt aufnimmt. Soweit so gut. Ich kann also schon den Status einzelner Ausgänge am PC anzeigen und auch über die Taster oder das INPUT- Feld schalten. Nur jetzt kommt mein Problem. :-) Ich habe ca. 70 Ausgänge und rund 90 Eingänge und mir sind nach anfänglicher Freude über dieses tolle Tool und die einfache Umsetzung jetzt die Instrumente ausgegangen :-) Also meine Frage: Wie kann ich am effizientesten den Status der ca. 70 Ausgänge anzeigen? Am liebsten wären mir so 70 LED - Instrumente die ich dann auf einem Hintergrundbild das das Stockwerk darstellt verteilen könnte. Nur leider kann man keine zusätzlichen LED - Instrumente erzeugen oder doch? Hat da jemand eine fantasievolle Idee dazu. LG iwiki
Hallo Iwiki, leider existieren gewisse Beschränkungen, was die Instrumentenanzahl betrifft, aber trotzdem könntest du mal die Instrumente #35 und #36 benutzen für dein Vorhaben. So etwa eine Zustand- oder Statusliste. Viel Erfolg sand
Hallo Sand! Danke für den Tipp. Hatte ich mir schon angesehen die beiden Instrumente. Wenn Text dann würde ich #38 nehmen und in der ersten Zeile die Verbrauchernummer und in der 2. Zeile mit 00 oder 01 den Status anzeigen. Aber Nummern sind schwer zu merken. Vor allem wenn's so viele sind. Es geht hier um Verbraucher in Räumen, meistens Lichter, die ich gerne selbsterklärend anordnen möchte. Mit ist schon klar dass das hier kein Wunschkonzert ist aber vielleicht hat ein einer von euch das schon mal auf ähnliche Weise verwendet und eine gute Idee entwickelt. LG
Hallo Iwiki, mit #35 ; #36 ist kein Problem Daten mit dem zugehörigen Text empfangen. In einem Schub Text und Daten senden vom µP. LG sand
Ich habe das Projekt gerade eben erst entdeckt. Gibt es dafür auch schon einen Datenschreiber für grafische Darstellung(Linien) für bis zu 16 Eingangssignale? also vom A/D Wandler des controllers?
Hallo Albert habe Dein geniales Projekt eben erst entdeckt. Existiert eine loop-back Möglichkeit um das GUI ohne externe HW zu testen? Gruss Mike
Nein, dafür ist das alles doch zu einfach, um einen Debugger haben zu müssen.
Mike Köppel schrieb: > Hallo Albert habe Dein geniales Projekt eben erst entdeckt. > Existiert eine loop-back Möglichkeit um das GUI ohne externe HW zu > testen? Ja gibt es. Schau mal auf meiner Webseite bei FAQ zu SerialComInstruments: http://www.serialcominstruments.com/faqinstr.html Unter "Wie kann ich mein Projekt auch ohne angeschlossenen Mikrocontroller testen?" findest Du eine Anleitung wie es geht. Stichwort "Null-modem emulator" com0com. Gruss Ulrich Albert
:
Bearbeitet durch User
Albert M. schrieb: > 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. Ist denn in dieser Richtung noch etwas zu erwarten?
Ja
Angehängte Dateien:
-
Multiple_In_out_Display.jpg
120 KB
Hier mal ein Denkanstoss für alle die sich über zu wenig Ein-Ausgangs Darstellungsmöglichkeiten beklagen (siehe Bild oben). Einfach realisiert mit Instrument 35 und 36. Gruss Ulrich Albert http://www.serialcominstruments.com/
Angehängte Dateien:
-
sci.jpg
190 KB
Hallo Albert, beklagen möchte ich mich nicht, aber festhalten daß ich es schade finde, bei der an und für sich wunderbaren Programmidee, intuitiven Realisierung und vielseitigen Verwendbarkeit so sehr bei selbst einfachen Instrumenten (z.B. LEDs, Taster) beschränkt zu sein. Das ist natürlich Deine Entscheidung, ich freue mich auch so über das Programm (Danke!) und ich habe mich auch mit Zusatzsoftware auf die Situation eingerichtet. Anbei mal ein neues Bild vom aktuellen Entwicklungsstand zur Anregung! Gruß Moby
Hallo, ich mache gerade die ersten Schritte mit deinen Programm. Sieht ja sehr viel versprechend aus. Allerdings habe ich ein kleines Problem: Bei manchen Instrumenten (zB 51) kann man im edit-Mode die Instrumente nicht verschieben. Getesten auf XP und WIN7. Gibt es da einen Trick oder ist es noch ein bug? Habe die 0.48e von weiter oben im Forum, da ich leider von der Webseite keine Version zugeschickt bekam.
:
Bearbeitet durch User
Rainer M. schrieb: > Allerdings habe ich ein kleines Problem: Bei manchen Instrumenten (zB > 51) kann man im edit-Mode die Instrumente nicht verschieben. Getesten > auf XP und WIN7. Sieh mal ganz unten auf Instr 51. Da steht "On Edit move here". Also im Edit Mode immer ganz unten im Rahmen zum Bewegen anfassen. Gilt eigentlich für alle Instrumente. Rainer M. schrieb: > Habe die 0.48e von > weiter oben im Forum, da ich leider von der Webseite keine Version > zugeschickt bekam. Die Konditionen für eine Version per Email sind auf meiner Webseite ziemlich klar definiert. Schau jetzt mal Deine email-Adresse an, sorry an solche email Adressen versende ich nichts.
:
Bearbeitet durch User
Moby schrieb: > so sehr bei selbst > einfachen Instrumenten (z.B. LEDs, Taster) beschränkt zu sein. Wenn ich soweit mit meiner CNC Software fertig bin, geht es mit SerialComInstruments weiter.
Was ist an meiner Emailadresse nicht in Ordnung? Das ist nun schon seit 15 Jahren meine Firmenmail und bisher hatte noch niemand damit Schwierigkeiten. Die Domain ist sogar auf mich persönlich registriert, also weder anonym noch 10 min. oder wegwerf Ersatzweise habe ich noch Gmail, aber da schreibst du ja, dass du nichts hinschicken willst. Also welche Provider sind genehm?
Rainer M. schrieb: > Was ist an meiner Emailadresse nicht in Ordnung? > Das ist nun schon seit 15 Jahren meine Firmenmail und bisher hatte noch > niemand damit Schwierigkeiten. Die Domain ist sogar auf mich persönlich > registriert, also weder anonym noch 10 min. oder wegwerf > Ersatzweise habe ich noch Gmail, aber da schreibst du ja, dass du nichts > hinschicken willst. > Also welche Provider sind genehm? Dein pampiges Geschreibe kannst Du Dir stecken. An eine email die in Abwandlung zu Deiner " n@goldküste.de " lautet versende ich nichts. Punkt. Was ist für Dich auf meiner Webseite eigentlich nicht vertändlich: " Es wird ausschliesslich auf Accounts der bekannten grossen Mail-Anbietern reagiert, exotische Adressen, Adressen die keinen plausiblen Namen beinhalten, sowie 10 Minuten Accounts werden ebenso ignoriert wie die unten angegebenen Mail-Provider. " " Stellen Sie sicher, dass Ihr Mail-Anbieter in Zip-Files eingebettete exe-Dateien, sowie eine Grösse des Mail-Anhangs bis zu 5 MB akzeptiert. Folgende Mail-Provider erlauben keine Zip-Files mit includierten exe-Dateien: Do Not Use: gmail , googlemail , University-Server Verwenden Sie in diesem Fall unbedingt einen anderen Mail-Provider."
:
Bearbeitet durch User
um das hier nicht weiter ausarten zu lassen, verzichte ich dann eben auf die zusendung der software und drücke ausdrücklich meinen dank dafür aus, dass sie kostenlos zur Verfügung gestellt wird. Ich bin in diesem Forum recht wenig unterwegs, und schreibend so gut wie gar nicht. Dabei wird es wohl bleiben.
Albert M. schrieb: > geht es mit > SerialComInstruments weiter Prima! Da kommt wieder Spannung auf ;-)
Anregung zur Bereitstellung der Daten zur Visualisierung, wenn die Geschwindigkeit keine grosse Rolle spielt : Ich steuere mit einem Atmega mit Netzwerkanschluss eine Poolanlage. Zur Visualisierung der Daten (Temperaturen, Druck, Wind, Solarheizung, etc) spiele ich gerade etwas mit dem Programm herum. Oftmals, wie in meinem Fall auch, hat zwar der mc Netzwerkanschluss, aber es liegt keine serielle Strippe zum PC. Ich habe nun einen kleinen "Vermittler" gebaut, ein Arduino UNO mit Netzwerkshield, der seriell am PC hängt. Der fragt die Daten beim Haupt-mc per TCP alle paar Sekunden ab (dauert bei mir 130ms) und bigt sie auf der seriellen aus, wovon wiederum das SerialComInstruments sie nimmt und darstellt. Der umgekehrte Weg ist auch machbar, damit Steuerbefehle abgesetzt werden können, habe ich aber (noch?) nicht implementiert, da ich dies über eine html Oberfläche mache. Alternative wäre natürlich auch, einen Com-Server an den mc zu hängen. P.S. geht evtl. der ausgegraute Eintrag "Netzwerk" im Interface Menü auch in diese Richtung?
Rainer M. schrieb: > P.S. geht evtl. der ausgegraute Eintrag "Netzwerk" im Interface Menü > auch in diese Richtung? Genau. UDP ist bei mir bereits funktionsfähig, aber noch nicht freigegeben.
D.h., das Programm lauscht auf einem Port auf UDP-Pakete anstatt auf der Com und alles läuft? das wäre ja fast der helle Wahnsinn. Dann bräuchts nur noch ne Androidversion und man könnte sich ein Tablet als Steuerstand an die Wandhängen ;-) Eine Frage noch bezüglich Vert.Meter. Ich wollte einen Wasser(fehl)stand (pos. float) anzeigen mit 0 oben und 10 unten. Das Instrument macht zwar die Skala richtig aber das dreieck zeigt den Wert nicht an. Am Instrument oben digital wird der wert korrekt angezeigt. Mache ich da was verkehrt? Mit negativer Skala und Multiplikationsfaktor -1 klappts. Positiv nicht
:
Bearbeitet durch User
Rainer M. schrieb: > D.h., das Programm lauscht auf einem Port auf UDP-Pakete anstatt auf der > Com und alles läuft? Ja. Rainer M. schrieb: > Eine Frage noch bezüglich Vert.Meter. Ich wollte einen Wasser(fehl)stand > (pos. float) anzeigen mit 0 oben und 10 unten. Das Instrument macht zwar > die Skala richtig aber das dreieck zeigt den Wert nicht an. Am > Instrument oben digital wird der wert korrekt angezeigt. Mache ich da > was verkehrt? Da schau ich Morgen mal nach :)
@Rainer M Oben im Instrument sind IMMER die grösseren/positiveren Werte. Für Dich heisst dass Anzeige Wert von : -10 Anzeigewert bis : 0 Nun zeigt das Instrument oben 0 und unten -10 an, was für Deinen Wasser-Fehlstand ja passt. Jetzt kannst Du mit der Einstellung des Skalierungsfaktor auf 1 vom Microkontroller negative Werte senden oder eben mit Skalierungsfaktor -1 positive Werte.
:
Bearbeitet durch User
Ich glaube mein Edit vom Post und deine Antwort haben sich überschnitten. Ich habe gerade mal das ganze mit einem seriellen Device-Server angeschlossen, funktioniert wie es gedacht war. Allerdings macht die serielle nur 9600, höher gibt es Salat. Aber das ist eine andere Baustelle. Mir ist da noch eine Sache in den Sinn gekommen, die viellleicht als zukünftiges "Instrument" interessant sein könnte: Es wird eine extern eingebundene Bitmap (phg, gif, gif animiert, auf jeden Fall was mit transparentem Hintergrund) als Instrument dargestellt, und der übergebene Wert wählt die Bitmap aus. So könnte man Stellungen von Ventilen und Flussrichtungen in Leitungen etc. grafisch darstellen. Das Hintergrundbild enthält sozusagen das Schema, und die Bitmaps überlagern bzw. ergänzen das ganze. Oder denke ich da schon zu sehr an "professionelle" Visualisierungen?
Rainer M. schrieb: > Mir ist da noch eine Sache in den Sinn gekommen, die viellleicht als > zukünftiges "Instrument" interessant sein könnte: > > Es wird eine extern eingebundene Bitmap (phg, gif, gif animiert, auf > jeden Fall was mit transparentem Hintergrund) als Instrument > dargestellt, und der übergebene Wert wählt die Bitmap aus. Da solltest Du Dich mal mit dem Paint-Instrument #56 befassen. Damit kannst Du vom Mikrocontroller aus beliebige Instrumente nach Deinen Vorstellungen erzeugen oder bewegte Graphiken usw. Schau Dir dazu mal als Beispiel dieses Video an: https://www.youtube.com/watch?v=-MDE-uhb8tQ Zusätzlich kannst Du in das Paint-Instrument einen fixen Hintergrund (Instrument) als Bild laden. Dann wäre darin nur noch der vom MC gezeichnete Zeiger hin und her zu bewegen.
:
Bearbeitet durch User
Das hatte ich mir schon angesehen. da ist doch relativ viel Datenverkehr im Spiel und wenn der mc nicht direkt per seriell dranhängt, könnte das problematisch werden. Ich dachte da eher an so Spielereien wie sich bewegende Pfeile im stylisierten Wasserrohr per animated gif, und Hähne, die dann eben für jede Stellung ein PNG haben. Oder ein blinkender Motor, wenn ein fehler vorliegt, etc. Aber wie gesagt, sind im Prinzip nur Spielereinen und Spinnereinen. Obwohl ich es mir nicht sonderlich kompliziert vorstelle, verglichen mit manch anderem Instrument.
Nochmal zurück zu der UDP Sache: Wenn also das Programm auf einem UDP Port lauscht, kann man dann von verschiedenen mc Daten hinschicken, die dann gemeinsam angezeigt werden ? Ggf. sogar mit NAT übers Internet?
Rainer M. schrieb: > Wenn also das Programm auf einem UDP (TCP) Port lauscht ... lässt es sich dann einrichten daß gleichzeitig auch weiterhin Daten einer seriellen Schnittstelle entgegengenommen werden?
Bestimmt. Ist reine Softwaresache. Und bei einem so versierten Programmierer kannst du davon ausgehen, das es möglich sein wird.
Für verschiedene MCs müssten die Instrumentencodes erweitert werden. Am besten natürlich in einer Art und Weise, daß bestehender Code nicht großartig umgeschrieben werden muß ;-( Bislang geht das Programm ja nur von einem Zulieferer aus. Interessant ist auch die Gegenrichtung. Kommandos aus der Texteingabebox gehen dann wohin? Via Netzwerk eingehende Daten sollten auch an die serielle Schnittstelle weiterleitbar sein- so denn da die eigentliche Steuerung dranhängt und Kommandozulieferer zum Beispiel ein Tablett/Smartphone ist.
Dann fängt es aber an für ein Hobbyprojekt zu kompliziert und umfangreich zu werden. Und wer so was professionell braucht, der soll sich für Geld sowas erstellen lassen wo das alles geht.
Klar wirds umso komplizierter, je mehr da dranhängt. Ist jetzt auch nicht vordringlich. Ich wär wiegesagt schon mit ein paar mehr Schaltern und LEDs glücklich ;-)
Ich bekomme bei den Slidern 82 und 83 beim Verstellen öfter die Meldung "Ein deaktiviertes oder unsichtbares Fenster kann nicht den Fokus erhalten" und er lässt sich nicht einstellen. Bug oder Fehlbedienung?
@ Rainer M. Das ist ein Bug. Unter welchen Umständen genau kannst Du den reproduzieren?
Lässt sich nicht reproduzieren. Wenn der Fehler kommt, mach ich das Programm zu und wieder auf, dann geht es meistens. Wenn er auftritt, dann bisher immer ab Programmstart. Wenns mal geht, dann gehts
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments V0.48f Change Log v0.48f ----------------- Unter Hilfe gibt es den neuen Menue-Eintrag: "Check for new Version" Neues Programm-Icon Da die Weiterentwicklung bald wieder anläuft, ist es für die Anwender sinnvoll sich diese Version zu installieren, um mit der neuen Check-Funktion auf dem Laufenden zu bleiben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Ich möchte dir ein weiteres mal ein großes Danke für dieses wirklich nützliche Tool sagen. Ich benutze es gerade wieder auf einem ATXMega-Testboard, um einen Gyro und ACC-Sensor auszulesen(MPU6050). Später plane ich mit diesen ausgelesenen Werten den PID-Regler zu füttern, um die Parameter für genau diesen zu ermitteln. Dennis
@Dennis Hört man immer wieder gern :)
Hallo Ich habe neulich das Projekt gefunden und gleich geladen. Jetzt habe ich es probieren wollen Die Installation läuft ohne Fehler durch. Nach den Start und der Auswahl einer Funktion mit entsprechender Einstellung sehe ich nach betätigen vom "Show+Zuweisen" Button nur einen leeren Bildschirm Was ist noch falsch oder muss ich noch Irgendwelche Hilfsprogramme laden? Der Fehler tritt bei mir auf einem W7 und WXP Rechner auf.
fredfromflett schrieb: > Nach den Start und der Auswahl einer Funktion mit entsprechender > Einstellung sehe ich nach betätigen vom "Show+Zuweisen" Button nur einen Es kann bei geringauflösenden Bildschirmen sein, dass das Instrument im nicht sichtbaren Bereich liegt. Betätige mal den Button TL (Top Left), damit wird das gewählte Instrument in die linke obere Ecke des Bildschirms plaziert. Anschliessend kannst Du es dann an eine beliebige Stelle schieben.
Gerade Getestet Programm im Vollbildmodus TL Taste gedrückt aber keine Reaktion Hat noch jemand eine Idee? Danke
Es werden nur die Instrumente angezeigt, welche auch in der Instrumenten-Übersicht markiert sind. Ist nichts markiert, bleibt des Show-Fenster leer.
Danke ich habe es jetzt hingekriegt es hat an den fehlenden "Hacken" gelegen. Ich glaub ich werde alt. Danke für das tolle Programm Gruß aus der Mitte von NDS fredfromflett
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.49 Change Log v0.49 ---------------- 2 weitere Analog-Instrumente #05 und #06. MiniTrend Instrument jetzt mit 2 Kanälen. Im Gegensatz zum FullTrend Instrument ist die Skalierung hier für beide Kanäle gleich. Gruss Ulrich Albert http://www.serialcominstruments.com/
Danke Albert, kann man gut gebrauchen. Beste Grüsse sand
sand schrieb: > Danke Albert, > kann man gut gebrauchen. Freut mich :) Neuerungen SerialComInstruments für das nächste Release: Spezielle Anpassungen für die bidirektionale Kommunikation mit SerialComMeasurement: siehe hier: http://www.serialcominstruments.com/measurement.php - direkte Programmierung über internes Terminal - Zusätzliche/modifizierte Start/Stop Buttons - usw. In SerialComMeasurement wird es spezielle Befehle z.B. für die Ausgabe mit passender Syntax für SerialComInstruments geben. Damit ist es dann möglich in wenigen Minuten ein komplettes Mess/Steuersystem ohne grosse Programmierung aufzusetzen.
Hallo Albert, wäre es möglich, bei dem X-Y Display (Nr. 58-59) den aktuellen Messwert durch ein Kreuz oder Punkt (in Farbe) an der Kennlinie darzustellen? Beste Grüsse sand
sand schrieb: > wäre es möglich, bei dem X-Y Display (Nr. 58-59) den aktuellen Messwert > durch ein Kreuz oder Punkt (in Farbe) an der Kennlinie darzustellen? Habe ich notiert.
freut mich dass es wieder Erweiterungen gibt.
frage: Instr. 87 Trigger schickt keinen Parameter sonst oK
frage: Instr. 56 Paint wäre es möglich dass man die Pixeldaten bei
der
Mausbewegung sieht für die Koordinaten ?
frage: Instr. 51/52 wäre es möglich die empfangenen Daten als
Datei
zu speichern ?
und Danke für deine freiwillige Arbeit für uns Hobbisten
lg Anton
@ labelohase (Anton) ist notiert. Für SerialComMeasurement http://www.serialcominstruments.com/measurement.php wird es in SerialComInstruments weitere Anpassungen geben: Das interne Terminal wird angepasst, auf der Seite gibt es einen Texteditor um Befehlsfolgen für SerialComMeasurement zu schreiben und direkt auf den ATMega/Arduino zu laden. Die Befehlsfolgen können als Text-Datei unter eigenem Namen auf dem PC gespeichert und wieder geladen werden. Das Arbeiten mit SerialComMeasurement in Verbindung mit SerialComInstruments macht mir selber richtig Spass :) Schon mit 2 Befehlszeilen macht man Messungen und zeigt diese auf einem Instrument an. Das funktioniert jetzt bereits mit dem internen Terminal. Beispiel: #c11=ai2m4 Kanal 11 ist gleich Analog Input 2, 4x gemittelt #sc01=c11 Serial Out für Instrument 01 gleich Kanal 11 Einfacher kann man nicht mal eben messen. Oder den ATmega PortD auf dem SerialComInstruments Led-Instrument 60 anzuzeigen: #c11=rpd Kanal 11 ist gleich Read Port D #sc60=c11 Serial Out für Instrument 60 gleich Kanal 11 Gruss Ulrich Albert
:
Bearbeitet durch User
Angehängte Dateien:
Hier eine Vorschau auf die Integration des ATMega/Arduino Command Uploader und Editor für SerialComMeasurement im Terminal-Fenster wie oben angekündigt. http://www.serialcominstruments.com/measurement.php
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments V0.49a SerialComInstruments Change Log ------------------------------- v0.49a ------ Instrument Full Trend #51/52 Die dargestellten Messwerte/Graphen (auch die im nicht sichtbaren Bereich) können nun unter beliebigem Namen gespeichert und wieder geladen werden. (Buttons Save/Load auf dem Instrument) Instrument XY-Graph #58/59 Für die XY Darstellung kann über das Aktivieren der Checkbox "M" eine kleine Raute als Marker zum jeweiligen Messpunkt dargestellt werden. Instrument Paintbox #56 Im Run-Mode wird die XY-Position der Mouse innerhalb der Box angezeigt. Im Edit-Mode wird die XY-Grösse der Zeichenfläche angezeigt. Erweiterungen für SerialComMeasurement: Das interne Terminal hat jetzt einen zusätzlichen Texteditor. Dieser ermöglicht das Schreiben/Editieren, Speichern und Laden von Befehlsfolgen für SerialComMeasurement. Mittels Upload Button können die Befehle dann direkt auf einen ATMega/Arduino geladen werden. Gruss Ulrich Albert http://www.serialcominstruments.com/instrument.php
:
Bearbeitet durch User
Hallo Albert Danke für die Änderungen bei den Instrumenten 56 und 51-52 liegt er Fehler bei Instr. 87 bei mir ? (Parameter mitsenden) nochmals vielen Dank lg Anton
labelohase schrieb: > Fehler bei Instr. 87 bei mir ? (Parameter mitsenden) Stimmt, der Parameter wird z.Z. nur beim Test und an falscher Position im String gesendet. Wird in der nächsten Version behoben.
:
Bearbeitet durch User
Hi chris_, chris_ schrieb: > Ich hatte die Idde auch schon, aber ich hätte nicht gewusst, wie man > dynamische Vorgänge darstellen kann. Mit Ajax oder WebSockets. HTH, Karl
Hallo Albert, Albert M. schrieb: > Vergiss Phyton für so ein Projekt wie meines. > Phyton ist gegenüber Delphi schnarchlangsam und könnte die schnellen > Abläufe nicht handeln. Ich habe hier Tests laufen mit 115200 Baud und 50 > Instrumenten. Wie willst Du das "realtime-mässig" in Phyton handeln? Nix > für Ungut, aber das ist Wunschdenken. Bis dass Du mir das Gegenteil > beweist. Python macht hier völlig problemlos bis zu 3,5MBaud (in Worten: 3.500.000 Baud), und zwar auf einem ollen Raspberry Pi mit 700 MHz. Mehr habe ich nicht getestet, weil der FTDI232RL-Chip laut Hersteller ohnehin nicht mehr als 3MBaud abkann. Deine popeligen 115kBaud macht Python also jedenfalls im Tiefschlaf, und für kleine Projektchen wie dieses wäre es perfekt geeignet. Liebe Grüße, Karl
Hallo Albert, Albert M. schrieb: > Ich arbeite an meinem Projekt jetzt gerade mal 2 Wochen und das auch nur > ab und an stundenweise. Mit den von Dir propagierten > Oberflächentemplates wärst Du noch nicht mal ein Viertel soweit wie ich. > Und wie willst Du mit Deinen Templetes die visuellen Instrumente > erzeugen? > Alles ziemlicher Dummschwatz. Deine Überheblichkeit ist unglaublich. > Und im übrigen solltest Du nicht über Programmiertools wie Delphi > urteilen, von denen Du ganz offensichtlich nicht den geringsten Schimmer > hast. Es wäre wünschenswert, wenn Du Dich an Deine eigenen Empfehlungen halten würdest, insbesondere an diese. Dann hättest Du Dir und uns nämlich den letzten Dummschwatz-Absatz ebenso wie den Unsinn über das angeblich so "schnarchlahme" Python einfach mal erspart, hm? Ist ja schön und gut, daß Du wenigstens Delphi kannst. Aber professionelle UI-Designer werden mit ihrem Werkzeug -- sei es Visual Studio, QtCreator, Glade oder ein anderes Tool -- mit Sicherheit mindestens genau so schnell sein wie Du und mindestens ebenso gute Ergebnisse erzielen. Sonst hätte Delphi sich nämlich längst am Markt etabliert -- hat es aber nicht. Insofern: laß' mal die Luft 'raus und steig von Deinem hohen Roß. Sonst fühlt sich hinterher noch jemand herausgefordert... ;-) Liebe Grüße, Karl
Karl Käfer schrieb: > Sonst > fühlt sich hinterher noch jemand herausgefordert... ;-) Na dann mach mal... Man kann zu gewissen Aussagen Alberts ja stehen wie man will, im Kern geht es hier aber um das Programm SerialComInstruments. Und damit um eine konkrete, sehr nützliche Visualisierungs-Lösung, die es in dieser einfachen und kostenlosen Form schlicht noch nicht gab. 'Karl Käfer' steht da eher für vielerlei akademisch-theoretische Diskurse, die sich aber leider in keinem praktischen, vorzeigbaren Ergebnis äußern.
Moby, da bin ich mal bei dir. Selbst wenn er vielleicht(!) eine gewisse Arroganz an den Tag legen sollte (nicht meine Meinung), so kann er sich das aber erlauben. Wie schnell er die Sachen raus haut, unglaublich. Leider habe ich den Faden völlig verloren und weiß nicht was ich mit der Software so recht anstellen sollte. Da bin ich wohl nicht so weit wie ihr.
Karl Käfer schrieb: > Deine popeligen 115kBaud macht Python also jedenfalls im Tiefschlaf Wenn Du den Text mit Verstand gelesen hättest, wäre Dir aufgefallen, dass nicht die mit Phyton möglichen Übertragungraten, sondern die Vearbeitungsgeschwindigkeit in Phyton allgemein gemeint war. Und es bleibt dabei: Verglichen mit Delphi ist Phyton schnarchlangsam. > und für kleine Projektchen wie dieses wäre es (Phyton) perfekt geeignet. > Deine Überheblichkeit ist unglaublich. Mit diesser Äusserung disqualifizierst Du Dich selbst. Dann zeigt doch mal, dummschwätzen kann jeder. Die Überheblichkeit liegt da sichtbar auf Deiner Seite. Karl Käfer schrieb: > professionelle UI-Designer werden mit ihrem Werkzeug -- sei es Visual > Studio, QtCreator, Glade oder ein anderes Tool -- mit Sicherheit > mindestens genau so schnell sein wie Du Was soll das Geschwätze? Habe ich irgendwo gesagt ich wäre der schnellste und andere würden ihr bevorzugtes Werkzeug nicht beherschen? Karl Käfer schrieb: > Sonst hätte Delphi sich nämlich längst am Markt > etabliert -- hat es aber nicht. Wovon meinst Du lebt Embarcadero? Für Dich der Link zum schlau machen: https://www.embarcadero.com/de/products/rad-studio Karl Käfer schrieb: > Insofern: laß' mal die Luft 'raus und steig von Deinem hohen Roß. Sonst > fühlt sich hinterher noch jemand herausgefordert... ;-) Da bin ich ja mal gespannt. Aber da wird NICHTS Vorzeigbares kommen. Was bist Du eigentlich für ein frustierter Typ? Liest hier den inzwischen hunderte Posts langen Thread Zeile für Zeile durch, pickst irgendwas raus und fängst an zu pöbeln. Langsam nehmen die Stänkerer und Spinner, die nichts Konstruktives beisteuern und die das eigentliche Thema nicht die Bohne interessiert, sondern nur ihren Frust ablassen, im MC Net überhand. Deshalb habe ich schon mein Projekt SerialComMeasurement hier beendet und führe es nur noch auf meiner Homepage weiter. Das werde ich auch für dieses und die anderen Projekte in Betracht ziehen oder die Entwicklung gänzlich einstellen und lieber mit meinen 65 Jahren den Tag geniessen. Und zum Thema Tag geniessen finden die Stänkerer zum weiteren Frusten hier was über mich zum Nachmachen: http://www.natur-mg.de/Myself.html Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo F., F. F. schrieb: > Selbst wenn er vielleicht(!) eine gewisse Arroganz an den Tag legen > sollte (nicht meine Meinung), so kann er sich das aber erlauben. > Wie schnell er die Sachen raus haut, unglaublich. Wenn man vorgefertigte Widgets und ein RAD-Werkzeug hat, ist das nicht sonderlich schwierig. Vor allem, wenn man die Widgets schon aus einem früheren Projekt sehr gut kennt. Das ist die ganze Idee von RAD. ;) Liebe Grüße, Karl
Angehängte Dateien:
-
Albert0.png
110 KB
Hallo Albert, Albert M. schrieb: > Karl Käfer schrieb: >> Deine popeligen 115kBaud macht Python also jedenfalls im Tiefschlaf > > Wenn Du den Text mit Verstand gelesen hättest, wäre Dir aufgefallen, > dass nicht die mit Phyton möglichen Übertragungraten, sondern die > Vearbeitungsgeschwindigkeit in Phyton allgemein gemeint war. > Und es bleibt dabei: Verglichen mit Delphi ist Phyton schnarchlangsam. Erstens: Du hast die Baudrate erwähnt, nicht ich. Zweitens: es heißt "Python". Wie die Schlange, weißt Du. Drittens: Python ist bei Weitem nicht so "schnarchlahm", wie Du glaubst. In dynamischen Tätigkeitsfeldern wie der Datenanalyse ist Python dank so ausgefeilter Module wie numpy, scipy und Pandas, sowie in der Generierung von Reports etwa mit Matplotlib ausgesprochen beliebt in Bereichen, wo es um extrem schnelle, flexible Datenverarbeitung geht. Um nochmal auf Dein Baudraten-Beispiel zurückzukommen: Du hast behauptet, Python könne keine 115kBaud verarbeiten, während ich bewiesen habe, daß 3.5MBaud für Python auf einem popeligen 700-MHz-SBC nicht nur überhaupt kein Problem sind, sondern Python sich noch langweilt. Deine großkotzige Aussage ist damit sehr eindeutig widerlegt. Andererseits ist es nicht ganz falsch, zu behaupten, Python sei langsam im Vergleich mit kompilierten Sprachen. Ganz richtig ist es aber auch nicht. Und schneller als der Dämel, der vor dem Rechner sitzt, ist es allemal. Du faselst hier auch von "Datenmengen". Über 'ne serielle Schnettstille? Datenmengen? Da kann ich wirklich nur lachen. >> und für kleine Projektchen wie dieses wäre es (Phyton) perfekt geeignet. > > Mit diesser Äusserung disqualifizierst Du Dich selbst. Ach ja? Warum denn? > Dann zeigt doch mal, Aber gerne. > dummschwätzen kann jeder. Da muß ich mich auf Dein kompetentes Urteil verlassen, damit kennst Du Dich offensichtlich besser aus als ich. > Karl Käfer schrieb: >> professionelle UI-Designer werden mit ihrem Werkzeug -- sei es Visual >> Studio, QtCreator, Glade oder ein anderes Tool -- mit Sicherheit >> mindestens genau so schnell sein wie Du > > Was soll das Geschwätze? Habe ich irgendwo gesagt ich wäre der > schnellste und andere würden ihr bevorzugtes Werkzeug nicht beherschen? Ja, ziemlich genau das hast Du behauptet. Der Trick bei den guten anderen ist übrigens nicht, daß sie ihre Tools beherrschen. Deren Trick ist, daß sie viele Tools beherrschen und daraus ihr Tool ausgewählt haben. > Karl Käfer schrieb: >> Sonst hätte Delphi sich nämlich längst am Markt >> etabliert -- hat es aber nicht. > > Wovon meinst Du lebt Embarcadero? Jedenfalls nicht von Delphi. > Karl Käfer schrieb: >> Insofern: laß' mal die Luft 'raus und steig von Deinem hohen Roß. Sonst >> fühlt sich hinterher noch jemand herausgefordert... ;-) > > Da bin ich ja mal gespannt. Aber da wird NICHTS Vorzeigbares kommen. Guckstu mit Auge in Anhang. 2,6 Stunden. Wenn Du willst, tröter ich die Serielle und das AJAX-Gedöns noch dran. > Was bist Du eigentlich für ein frustierter Typ? Liest hier den > inzwischen hunderte Posts langen Thread Zeile für Zeile durch, pickst > irgendwas raus und fängst an zu pöbeln. Genau: Du nennst mich einen "Stänkerer und Spinner" und wirfst mir dabei vor, ich würde "pöbeln". Nee, ist klar. Aber sonst geht es Dir hoffentlich noch ganz knusper, ne? > Langsam nehmen die Stänkerer und Spinner, die nichts Konstruktives > beisteuern und die das eigentliche Thema nicht die Bohne interessiert, > sondern nur ihren Frust ablassen, im MC Net überhand. Eigentlich ist es genau das, was mir bei Deinen Beiträgen so auf den Keks gegangen ist, daß ich mal gegenhalten wollte. Wer Python als schnarchlahm bezeichnet und einen modernen, plattformunabhängigen Client-Server-Ansatz verwirft, kann kein kompetenter Entwickler sein. Und war es auch nichtmal in den blöden Achtzigern. > Deshalb habe ich schon mein Projekt SerialComMeasurement hier beendet > und führe es nur noch auf meiner Homepage weiter. Das werde ich auch für > dieses und die anderen Projekte in Betracht ziehen oder die Entwicklung > gänzlich einstellen und lieber mit meinen 65 Jahren den Tag geniessen. > > Und zum Thema Tag geniessen finden die Stänkerer zum weiteren Frusten > hier was über mich zum Nachmachen: > http://www.natur-mg.de/Myself.html Das ist ausgesprochen witzig, weil ich zwar gute zwanzig Jahre jünger bin als Du, aber seit etwa derselben Zeit nicht mehr für den Lebensunterhalt arbeiten muß. Trotzdem arbeite ich aber immer noch in der professionellen Softwareentwicklung, weil mir das Spaß macht und ich mit ganz wunderbaren Menschen zusammenarbyten darf. ;-) Liebe Grüße, Karl
Da hat es aber einer echt nötig gehabt, "gegenzuhalten". Und dann: Sercomm 0.0.1. Richtig. Auf genau diesem Flipchart-Niveau ist der ganze Beitrag. Wenn dieses interpreterabhängige Datengewusel "modern" sein soll dann lob ich mir tausendfach die einfache Windows-Exe, die Albert anbietet. Von deren einfacher und trotzdem sehr vielseitigen Funktionalität ganz abgesehen. Ich hoffe Albert M. lässt sich von diesem an SerialComInstruments völlig desinteressierten Geiferer nicht unnötig provozieren.
Albert, Karl und Moby, könnt ihr hier nicht mal einen Punkt setzten! Es reicht doch! Albert macht ne ganze Menge und das freiwillig, für jeden zugängig. Allein die Tatsache sollte reichen. Ich hatte mal mit Arduino angefangen. Da wird auch viel zusammen geklickt. Na und? Ich konnte aber nach drei Monaten ein fertiges Projekt, mit Feuchte und Temperaturmessung herstellen. Dann hatte ich mit C angefangen, wollte das lernen, habe das auch zum Teil schon etwas gekonnt. Nun machte ich zwischendurch den Jagdschein und dann kam der Unfall von meinem Sohn. Das hatte mich schon, sicher auch, weil mein Vater in dieser Woche des Bangens starb. Gerade fing ich wieder an und konnte mich konzentrieren, da starb mein Sohn. So völlig unerwartet und von eine auf die andere Minute. Ich schreibe das hier nur, weil es wirklich andere Dinge gibt, über die man streiten kann, aber ganz sicher nicht über das hier. Albert hat seine Eigenheiten und er ist der Schöpfer des Projektes und als Schöpfer darf man alles mit seiner Schöpfung machen. Dem C++ Thread konnte ich später schon nicht mehr folgen und hier lese ich noch, aber diese ewigen Eitelkeiten machen so viel kaputt. Also, bitte kommt wieder zum Thema zurück!
Hallo, vielen Dank für das sehr tolle Projekt und die unterhaltsamen Einlagen gegen Ende. Albert hat recht: Der Ton macht die Musik! Kark Käfer hat auch recht: Das gilt auch für Albert! Schade, dass der Albert jetzt beleidigt ist und sein Projekt nur noch auf seiner eigenen Webseite weiterführt. Allerdings hat das den Vorteil, dass er dort alle 'Dummschwätzer' viel besser unter Kontrolle hat. Eins ist sicher der Rainer M. bleibt Dir treu! Tolles Projekt, weiter so Albert! Gruß Kurt
Es heißt doch, leben und leben lassen. Darunter verstehe ich, dass auch jeder machen kann was er möchte, wie er es möchte, und für wen er es möchte. Diejenigen, denen das nicht passt, können ja einfach die Klappe halten. alles andere verstehe ich in diesem Zusammenhang als Rumgetrolle. Der Ausdruck Troll trifft es in diesem Fall ziemlich gut, finde ich, weil jemand, der mit dem Projekt und dem Threat an sich überhaupt nichts zu tun hat, hat es geschafft hat, Unfrieden zu säen und dem anderen die Freude am Hobby oder zumindest am Forum schreiben zu verderben. Leider kann ich den Thema dann nicht mehr treu bleiben, da ich ja von Albert leider nichts an meine E-Mail Adresse geschickt bekomme. Das ist sehr schade. Vielen Dank Karl Käfer. Und übrigens, wenn man schon trollt, sollte man sich auch unter Klarnamen zu erkennen geben und sich zumindest anmelden.
:
Bearbeitet durch User
Rainer M. schrieb: > Und übrigens, wenn man schon trollt, sollte man sich auch unter > Klarnamen zu erkennen geben und sich zumindest anmelden. Schreibt hier was von Anmelden und Klarnamen und nutzt selber einen Account mit 15! Posts, die er wahrscheinlich alle hier im Thread verbraten hat. Ein echter (Schein)Heiliger! Grüße an Albert! Weiter so! Peter M.
Genau so ist es. und das hat auch seinen Grund. schreibst du Behnisch, hast du deine Ruhe, und wirst auch nicht angegriffen. Es gibt andere Foren, wo es anders zugeht. und in diesem Thread habe ich auch nur geschrieben, weil es anfänglich mit Albert gewisse Probleme wegen meiner E-Mail-Adresse gab und ich das Projekt aber doch sehr interessant finde.
Karl Käfer schrieb: > Albert M. schrieb: >> Vergiss Phyton für so ein Projekt wie meines. >> Phyton ist gegenüber Delphi schnarchlangsam und könnte die schnellen >> Abläufe nicht handeln. Ich habe hier Tests laufen mit 115200 Baud und 50 >> Instrumenten. Wie willst Du das "realtime-mässig" in Phyton handeln? Dass mit schnarchlangsam nicht die die 115200 Baud gemeint waren, sondern das Handling von 50 Instrumenten, erkennt man schon daran dass 115200 Baud und wesentlich mehr auch vom ollen BASIC und sonstigen Interpreter-Sprachen ohne weiteres geboten werden. Ich habe Testläufe mit direkter Datenübergabe unter Umgehung der Schnittstelle gemacht und dabei die Instrumente(ca. 40 Channels) mit Werten beaufschlagt, also mit kompletter Anzeige (2 Instrumente können prinzipbedingt nicht mithalten). Dabei erreiche ich eine Zykluszeit von 2 us = 500.000/s. Wenn man berücksichtigt, dass manche Instrumente einer komplexen Ansteuerung bedürfen und wie viele Parameter jedesmal zu überprüfen sind, incl. aller notwendigen Skalierungen, so erkennt auch ein Unbedarfter, das diese Geschwindigkeit mit einer Sprache wie Python nicht erreicht werden kann. Und was will Du jetzt mit Deinem obigen Python Progrämmchem und den paar Instrumenten beweisen? Ich glaube Dir ist die Komplexität und die vielen Fallstricke der Aufgabenstellung nicht wirklich bewust. Meine Software hat nicht ohne Grund weit über 10.000 Zeilen Code. Wenn Du meinst. Du könnstet mal eben einen vergleichbaren Clone mit Python erschaffen, so wird Dir dies nicht gelingen. Im übrigen habe ich keine Lust mehr dies weiter mit Dir zu diskutieren.
Rainer M. schrieb: > Leider kann ich den Thema dann nicht mehr treu bleiben, da ich ja von > Albert leider nichts an meine E-Mail Adresse geschickt bekomme. Das ist > sehr schade. Hallo Rainer, seit dem ich die Online Überprüfung auf neue Versionen im Programm eingeführt habe, bekommt niemand mehr die Software als e-Mail. Der Download-Link auf meiner Homepage führt jedoch sofort auf die jeweils neueste Version der Software hier im Forum. Ob ich dass wieder ändere kann ich noch nicht sagen :) Gruss Ulrich Albert
:
Bearbeitet durch User
Albert M. schrieb: > Karl Käfer schrieb: >> Albert M. schrieb: >>> Vergiss Phyton für so ein Projekt wie meines. >>> Phyton ist gegenüber Delphi schnarchlangsam und könnte die schnellen >>> Abläufe nicht handeln. Ich habe hier Tests laufen mit 115200 Baud und 50 >>> Instrumenten. Wie willst Du das "realtime-mässig" in Phyton handeln? > > Dass mit schnarchlangsam nicht die die 115200 Baud gemeint waren, > sondern das Handling von 50 Instrumenten, erkennt man schon daran dass > 115200 Baud und wesentlich mehr auch vom ollen BASIC und sonstigen > Interpreter-Sprachen ohne weiteres geboten werden. > > Ich habe Testläufe mit direkter Datenübergabe unter Umgehung der > Schnittstelle gemacht und dabei die Instrumente(ca. 40 Channels) mit > Werten beaufschlagt, also mit kompletter Anzeige (2 Instrumente können > prinzipbedingt nicht mithalten). Dabei erreiche ich eine Zykluszeit von > 2 us = 500.000/s. > Wenn man berücksichtigt, dass manche Instrumente einer komplexen > Ansteuerung bedürfen und wie viele Parameter jedesmal zu überprüfen > sind, incl. aller notwendigen Skalierungen, so erkennt auch ein > Unbedarfter, das diese Geschwindigkeit mit einer Sprache wie Python > nicht erreicht werden kann. > Mein Gott wir haben 2015 und da willst du einen heutigen üblichen PC mit 50 Instrumenten und 115kBaud auslasten egal mit welcher Software das geschrieben wurde kopfschüttelt Ich habe vor 14 Jahren für eine Firma gearbeitet und da haben wir eine 50m lange Maschine, die eine Halle füllt visualisiert und gesteuert und die Daten kamen über CAN wurden in VME-Racks konzentriert und dann über ein 100MBit Netzwerk an den PC übertragen. Programiersprache war C++, Betriebssysem Windows NT und später XP Embedded. Aber auch eine Java Prototyp für die GUI lief ruckelfrei. > Und was will Du jetzt mit Deinem obigen Python Progrämmchem und den paar > Instrumenten beweisen? Ich glaube Dir ist die Komplexität und die vielen > Fallstricke der Aufgabenstellung nicht wirklich bewust. Nochmal kopfschüttelt > Meine Software > hat nicht ohne Grund weit über 10.000 Zeilen Code. Wenn Du meinst. Du > könnstet mal eben einen vergleichbaren Clone mit Python erschaffen, so > wird Dir dies nicht gelingen. Da der Quellcode nicht bekannt ist kann man die Effektivität deines Quellcodes ja nicht beurteilen. Und nein ich möchte ihm auch nicht haben und mich da durchwurschteln. > Im übrigen habe ich keine Lust mehr dies weiter mit Dir zu diskutieren. Du machst hier im Forum für dich und deine Webseite Werbung und da musst du auch Kritik vertragen können. Mach auf deiner Webseite ein eigenes Forum auf und gut ist. Dann brauchst du auch nicht mehr über die Moderatoren hier zu schimpfen.
> nicht mithalten). Dabei erreiche ich eine Zykluszeit von > 2 us = 500.000/s. 2μs für was? Die Werte in die Controls verteilen? Das ist ganz wichtig, wenn Windows dann locker das 1000-fache braucht, um die auch anzuzeigen. Und der Monitor vielleicht nur auch 60 Zyklen / Sekunde kommt. Ganz zu schweigen von den optischen Sensoren der Figur vor dem Bildschirm. Also zur Visualisierung Bracht man das schonmal nicht. Um ob es Sinn macht, einen PID-Regler auf dem Pc laufen zu haben und Sensor und Aktor per Seriell auf dem μC? Für schnelles nicht und langsames braucht kein 500kcycles. Das wird jetzt sicher von A.M. wieder entsprechend kommentiert, aber hier ist ein Diskussionsforum und keine Beweihräucherungsanstalt.
Herrlich. Jetzt kommen die ganzen Neider dieses erfolgreichen Projekts aus dem Boden gekrochen und versuchen auf der technischen Schiene zu diskreditieren. Zeigt doch was besseres! Alles andere überzeugt nicht. Carl D. schrieb: >ob es Sinn macht ... entscheidet der Anwender dieses Programms.
Versuch erst mal meinen Text zu verstehen, ehe du "Gotteslästerung" schreist. Es ging um die Frage wie schnell eine Darstellung von Windoows überhaupt durchgeführt wird. Ob ich in der Zeit den Meßwert 1 oder 1000 mal verändert habe, tut nichts zur Sache. Ich sehe immer nur einen davon, auch wenn ich glauben würde sie alle zu sehen.
:
Bearbeitet durch User
Carl D. schrieb: > Versuch erst mal meinen Text zu verstehen, ehe du > "Gotteslästerung" > schreist. Und nimm Du erstmal die Anwender dieses Programms ernst, die Sinn und Zweck dessen Einsatzes in aller Regel für sich selbst entscheiden können und dazu keiner Belehrung durch selbsternannte Experten bedürfen, die diese Software nicht einsetzen. Technik/Sourcen zu diskutieren war nie Zweck des Angebots und man kann Albert nur zu der weisen Entscheidung beglückwünschen, den Quelltext unter Verschluß zu halten.
@ Hans-Georg Lehnard (h-g-l) Du musst auch schön im Kontext bleiben. Es ging um den Vergleich Python zu Delphi. Carl D. schrieb: > 2μs für was? Die Werte in die Controls verteilen? > Das ist ganz wichtig, wenn Windows dann locker das 1000-fache braucht, > um die auch anzuzeigen. Und der Monitor vielleicht nur auch 60 Zyklen / > Sekunde kommt. So so, Windows braucht Deiner Meinung das 1000-fache für die Anzeige? In welchem Film bist Du denn? Es war nur ein Speed Test. Ob das Ergebnis etwas über die Sinnhaftigkeit für die Anzeigen ausagt - Nein, wurde von mir auch nirgendwo behauptet. So schnell kann niemand zuschauen und wie von Dir schon richtig erkannt der Monitor das nicht anzeigen. Carl D. schrieb: > Um ob es Sinn macht, einen PID-Regler auf dem Pc laufen zu haben > und Sensor und Aktor per Seriell auf dem μC? Noch so ein Schwätzer ohne Ahnung. Wo bitte läuft in meiner Software ein PID-Regler? Hättest Du nur wenigstens das Manual gelesen. Aber ich kläre Dich gerne auf: Dieses Instrument ist ein Frontend zum Einstellen der Parameter für einen PID-Regler der auf dem Mikrocontroller läuft. Moby schrieb: > Technik/Sourcen zu diskutieren war nie > Zweck des Angebots und man kann Albert nur zu der weisen Entscheidung > beglückwünschen, den Quelltext unter Verschluß zu halten. In meiner Software SerialComCNC laufen seit einigen Versionen aus diesem Grunde grosse Programmteile in einer virtuellen Maschine und die Exe wird mit Obfuscation gegen Disassemblen geschützt. Dies werde ich auch für SerialComInstruments überdenken. Aber das sind nur Interna, die den Anwender nicht wirklich zu interessieren brauchen. Es werden sich aber hier wieder einige berufen fühlen auch das zu kommentieren. > Herrlich. Jetzt kommen die ganzen Neider dieses erfolgreichen Projekts > aus dem Boden gekrochen und versuchen auf der technischen Schiene zu > diskreditieren. Zeigt doch was besseres! Alles andere überzeugt nicht. Eben. Es ist hier immer das Gleiche. Wie schon gesagt, ich wiederhole es gerne nochmal: "Langsam nehmen die Stänkerer und Spinner, die nichts Konstruktives beisteuern und die das eigentliche Thema nicht die Bohne interessiert, sondern nur ihren Frust ablassen, im MC Net überhand."
:
Bearbeitet durch User
Albert M. schrieb: > @ Hans-Georg Lehnard (h-g-l) > > Du musst auch schön im Kontext bleiben. Es ging um den Vergleich Python > zu Delphi. > Der Kontext ist ein einigermaßen aktueller Rechner auf dem die Software läuft und da ist bei deinen angegebenen Anforderungen die Sprache völlig wurscht in der das Programm geschrieben wurde. Von daher ist es witzlos Delphi und Phython zu vergleichen weil beide deine Anforderungen bei weitem erfüllen wie viele andere Sprachen auch. Und es geht hier nicht darum irgendwen herunter zu machen, sondern nur um Richtigstellungen von falschen Informationen und genau das hat auch schon Karl Käfer gemacht. Es lesen ja nicht nur Fans von dir hier mit und das ist ein offenes Forum.
@ Hans-Georg Lehnard (h-g-l) Hier sind im Laufe der Zeit schon 3 Projekt-Clons von SerialComInstruments unter verschiedenen Programmiersprachen mit heren Ansprüchen gestartet und bald darauf kläglich gescheitert. Alle wollten es besser machen. Aber keiner kam auf die Idee es mit dem langsamen Python auch nur zu versuchen. Vor dem Ersten der nicht nur dummschwätzt, sondern mal ein vergleichbares Projekt zeigt zieh ich den Hut. Hans-Georg L. schrieb: > Es lesen ja nicht nur Fans von dir hier mit > und das ist ein offenes Forum. Och weisst Du, dass ist hier für mich wie eine Tüte Popcorn aufmachen und Entertainment haben :)
:
Bearbeitet durch User
Hallo Albert, Albert M. schrieb: > Im übrigen habe ich keine Lust mehr dies weiter mit Dir zu diskutieren. Ja, so hab' ich mir das vorgestellt: erst gibst Du den Rabiaten und bügelst alle, die andere Implementierungsvorschläge machen, maximal herablassend und arrogant ab, und sobald Dir jemand widerspricht, bist Du plötzlich das arme, zarte und natürlich vollkommen unschuldige Mimöschen. Dabei ist die Sache eigentlich einfach: wenn Du gar so zart besaitet bist, solltest Du Dich einfach von vorneherein etwas zurückhaltender äußern. Denn wie schon unsere Mütter wußten: wie man in den Wald hineinruft, so schallt es wieder heraus. Liebe Grüße, Karl
Wieder so ein Popcorn Beitrag. Lieber Karl Käfer, deine Meinung und Geheule interessiert mich einen feuchten Kehricht. Ist das so schwer zu verstehen?
:
Bearbeitet durch User
Hi F., F. F. schrieb: > Das hatte mich schon, sicher > auch, weil mein Vater in dieser Woche des Bangens starb. Gerade fing ich > wieder an und konnte mich konzentrieren, da starb mein Sohn. So völlig > unerwartet und von eine auf die andere Minute. Ach Du Schreck! Mein Beileid! > Albert hat seine Eigenheiten und er ist der Schöpfer des Projektes und > als Schöpfer darf man alles mit seiner Schöpfung machen. Keine Frage, das bestreitet ja auch niemand. Aber das gibt ihm trotzdem nicht das Recht, andere zu bepöbeln. Liebe Grüße, Karl
Karl Käfer schrieb: > nicht das Recht, andere zu bepöbeln Stimmt, die eigenen Vorschläge zu komplexen, ach so modernen PythonAjaxNumpyScipyPandas-ClientServer Ansätzen wurden hier nicht berücksichtigt, werden gar in besonders fieser Weise mißachtet! Das kann man schon mal als Bepöbeln, maximale Herablassung und Arroganz in den falschen Hals kriegen. Was für eine Niedertracht. Bei soviel unermesslichem Leid, soviel zu erduldender Inkompetenz hier im Forum scheint es im Leben des Herrn mit den giftigen lieben Grüßen dann wohl doch nicht so sonnig herzugehen.
Wieder ein Thread für die Don Quijotes dieses Forums. Ich verstehe nicht ganz, wie eine Diskusion über technische Fakten zu derartigen Antworten wie von A.M. und M. kommen kann. Ich werd mir das nicht mehr antun.
Carl D. schrieb: > Ich werd mir das nicht mehr > antun. Du hättest Dir insbesondere erst mal das Manual antun und Dich mit dem Programm vor irgendwelchen Kommentaren beschäftigen sollen.
Albert M. schrieb: > Carl D. schrieb: >> Um ob es Sinn macht, einen PID-Regler auf dem Pc laufen zu haben >> und Sensor und Aktor per Seriell auf dem μC? > > Noch so ein Schwätzer ohne Ahnung. > Wo bitte läuft in meiner Software ein PID-Regler? > Hättest Du nur wenigstens das Manual gelesen. Aber ich kläre Dich gerne > auf: Dieses Instrument ist ein Frontend zum Einstellen der Parameter für > einen PID-Regler der auf dem Mikrocontroller läuft. Unverbesserlich!
Albert M. schrieb: > deine Meinung und Geheule interessiert mich einen > feuchten Kehricht. Ich frag mich, ob Du auch etwas Schreiben kannst, ohne unter die Gürtellinie zu gehen?
Klaus schrieb: > Unverbesserlich! Nö. Das ginge noch viel deutlicher auszudrücken. Dieter schrieb: > Ich frag mich, ob Du auch etwas Schreiben kannst, ohne unter die > Gürtellinie zu gehen? Und ich frage mich, wo bei Dir die Gürtellinie anfängt...
Hallo! :-) So jetzt finde ich reicht es.... Ich habe über längere Zeit nach einer Lösung gesucht die Verbindung zwischen meiner Haussteuerung auf Basis Atmel 644 und meine Server im Keller herzustellen. Es gibt unzählige Lösungen im Netz die alle auf ihre Weise gut sein mögen (Kann und möchte ich nicht beurteilen)um so etwas zu realisieren. Die Meisten die ich gefunden haben setzen allerdings Programmierkenntnisse voraus die bei mir leider nur sehr sehr begrenzt vorhanden sind (Schade über mich). Die hier von Albert entwickelt Lösung war die einzige die ich mehr oder weniger auf Anhieb umsetzen konnte und sie funktioniert seither einwandfrei. An dieser Stelle vielen Dank :-) Natürlich habe auch ich Wünsche was anders sein könnte. Die ein oder andere Erweiterung wäre schön. Und vermutlich hätte selbst ich das ein oder andere anders gemacht ( wenn ich es könnte ). Aber jedenfalls respektiere ich die Leistung von Albert und freue mich darüber dass sie frei zur Verfügung steht. :-) Nachmals vielen Dank dafür.... So und nun zu dem was ich eigentlich los werden möchte... Natürlich hat jeder das Recht seine Meinung zu sagen und vermutlich kann man das auf mehr oder weniger nette Weise tun. Und es ist unbestritten dass es auch andere Möglichkeiten gibt so etwas zu realisieren ( Viele Wege führen nach Rom.. mehr oder weniger holprig.. und auf jedem Weg liegt der ein oder andere Stein... ) Aber es wäre äußerst schade wenn dieser eine Weg deshalb zur Sackgasse würde. Es würde mich sehr freuen wenn sich alle ein wenig besinnen und aus dieser "Ich bin der Beste" Diskussion eine Sachliche werden würde die vielleicht dann sogar zu einem in der ein oder anderen Richtung verbesserten Projekt führen würde. Es wäre doch viel schöner gemeinsam etwas zu schaffen anstatt sich gegenseitig niederzumachen. :-) in diesem Sinne noch einen schönen Sonntag (Wer eine Fehler findet darf ihn Behalten) (Wer mit dem was ich von mir gebe nicht zufrieden ist darf es gern ignorieren)
Wer hier aufmerksam mitliest wird folgendes feststellen: Es gibt 3 Sorten von Postern: 1. Diese sind an dem Projekt interessiert, stellen dazu Fragen, die auch immer von mir beantwortet werden. Oder sie möchten eine Erweiterung, die ich ebenfalls, wenn realisierbar, meist ziemlich schnell in die folgende Programmversion einbaue. Von diesen Leuten kamen viele gute Ideen. 2. Diese schlagen Erweiterungen / Änderungen vor, die entweder nicht realisierbar sind, oder die ich nicht realisieren will. Nach einem Nein von mir, dass sie nicht verstehen wollen, beharren sie weiter auf ihren Vorstellungen (z.B. irgendwelchen Ajax dupi supi Kram) und müllen den Thread damit zu. Von diesen Kandidaten werde ich dann gerne als arrogant oder sonstwas bezeichnet. 3. Diese Sorte ist auschliesslich an Stänkern und Unfrieden stiften interessiert, keinesfalls auch nur ansatzweise an der Software. Beispiel-Kandidaten findet man genügend unter den letzten Beiträgen oben. Und nun wundern sich die Leute aus Kategorie 2 und 3 scheinheilig, dass ihnen der Wind ins Gesicht bläst? Ich habe es schon mal irgendwo geschrieben: Hätte ich alle Vorschläge jedesmal ellenlang diskutiert, stände die Software jetzt noch im Planungsstadium. Es geht nicht anders, einer gibt die Marchrichtung vor, in diesem Fall bei meiner Software ich. Wer das nicht akzeptiert muss ja nicht mitmachen. Wer es doch macht um zu stören, braucht sich nicht wundern wenn er sein Fett abbekommt. In diesem Sinne Ulrich Albert
:
Bearbeitet durch User
@Albert Volle Zustimmung. Man wundert sich nur noch über die grenzenlosen "Vollpensions"-Ansprüche derer, die in deinem Freeware-Projekt auf undankbarste Weise nach vermeintlichen Mäkeln und Lücken suchen. Ob die sich im Klaren sind, wieviel Mannstunden du mit diesem, über Jahre perfektionierten Werkzeug bereitwillig zur freien Verfügung stellst, darf bezweifelt werden. Aber massloses Fordern und unverschämtes Anspruchsdenken gegenüber freiwilligen Gebern, scheint ja auf vielen gesellschaftlichen Ebenen inzwischen zum neuen ethischen Mainstream zu gehören und durchaus als salonfähig etabliert zu werden. Selbst die offenherzigsten Geber sollten sich alle solangsam auf ein notorisches Dauer-Schamgefühl einstellen, da sie den aggressiv fordernden Erwartungen der Nehmer, die sich an ihrer Freigiebigkeit entzünden, nirgendwo mehr gerecht werden können... so scheint es mir.
Albert M. schrieb: > 2. Diese schlagen Erweiterungen / Änderungen vor, die entweder nicht > realisierbar sind, oder die ich nicht realisieren will. Für Leute mit Wünschen aus dieser Kategorie und höheren Ansprüchen hat sich vor kurzem eine 50€-Alternative eröffnet, die ich hier mal kurz als Tipp loswerden möchte: Das 2014er Labview als Home-Editon! Eine serielle Schnittstelle ist damit schnell ausgewertet, insbesondere aber bietet es aber ein Universum an unbeschränkten Möglichkeiten zur Datenanzeige, -eingabe, -umwandlung, -abspeicherung und -weiterleitung.
Angehängte Dateien:
Hier eine Vorschau auf eine Print Funktion für das Full-Trend Instrument #51/52. Hat zur Zeit noch einige Tücken, aber ich denke mal, dass es in der nächsten Version kommt. Es kann der komplette Aufzeichnungszeitraum oder nur Ausschnitte davon ausgedruckt werden. Ebenso überdenke ich eine Print Funktion für das XY-YT-FFT-Instrument #58/59.
:
Bearbeitet durch User
Albert: Danke dass du trotz aller neg. Postings trotzdem weiter machst, ich glaube damit spreche ich für alle Hobby- troniker. bei manche Posting glaubt man die wollen nur dass du mit dem Projekt aufhörst. lg Anton
Hallo Albert, Albert M. schrieb: > Wer hier aufmerksam mitliest wird folgendes feststellen: Es gibt 3 > Sorten von Postern: > [...] > 2. Diese schlagen Erweiterungen / Änderungen vor, die entweder nicht > realisierbar sind, oder die ich nicht realisieren will. Nach einem Nein > von mir, dass sie nicht verstehen wollen, beharren sie weiter auf ihren > Vorstellungen (z.B. irgendwelchen Ajax dupi supi Kram) und müllen den > Thread damit zu. Von diesen Kandidaten werde ich dann gerne als arrogant > oder sonstwas bezeichnet. Das dürfte ursächlich daran liegen, daß Du jeden Vorschlag, der Dir nicht in den Kram paßt, mit persönlichen Angriffen und verbalen Ausfällen wie "Dummschwatz", "schnarchlahm" etc. abbügelst. Sowas fordert Widerspruch natürlich erst recht heraus. Denn wie man in den Wald hineinruft, ... > Ich habe es schon mal irgendwo geschrieben: > Hätte ich alle Vorschläge jedesmal ellenlang diskutiert, stände die > Software jetzt noch im Planungsstadium. Man kann solche Vorschläge auch höflich, aber bestimmt ablehnen, ohne die Vorschlagenden gleich als unfähig und "Schwätzer" zu beleidigen und ihre Ideen als dämlich abzutun. Mit einem Mindestmaß an Benimm und Respekt im Umgang mit anderen Menschen hättest Du Dir, diesem Thread, und allen an Deiner Software Interessierten all das erspart. Das würde übrigens auch viel souveräner wirken als das kindische "Dummschwatz"-Gekeife. Im Übrigen habe ich jetzt spaßeshalber mal 50 Anzeigen (in Deinem Jargon: "virtuelle Instrumente") auf meine Seite gepackt und von dem ollen RasPi mit 460kBaud über AJAX mit Zufallsdaten beschickt, und sieh da: das geht mit Python so flott, daß man die Anzeigen gar nicht mehr lesen kann. Guten Popcorn-Appetit noch. ;-) Liebe Grüße, Karl
Hallo labelohase, labelohase schrieb: > Danke dass du trotz aller neg. Postings trotzdem weiter machst, > ich glaube damit spreche ich für alle Hobby- troniker. > > bei manche Posting glaubt man die wollen nur dass du mit dem > Projekt aufhörst. Da kann ich natürlich nur für mich sprechen, aber ich will keinesfalls, daß Albert mit dem Projekt aufhört. Offensichtlich gibt es ja eine Reihe Leute, die seine Software brauchen und benutzen können. Ich würde mir nur wünschen, daß er mit den ständigen Pöbeleien aufhören würde -- auch wenn er nur andere bepöbelt hat, und nicht mich. Liebe Grüße, Karl
Albert M. schrieb: > Hier eine Vorschau auf ... Hallo Albert, kannst Du auch schon eine Vorschau auf die weitere Zukunft geben oder gibt es dafür keinen konkreten Plan- und aktuelle Features entstehen frei nach Lust und Laune? Das wäre natürlich sehr interessant um etwas abschätzen zu können, inwieweit Dein Programm individuelle Erweiterungswünsche auch in Zukunft wird abdecken können. Die Ansteuerung des Frontends mag einfach sein, bedeutet aber trotzdem gewisse Investitionen auf Controllerseite, die sich natürlich nicht irgendwann in einer Sackgasse wiederfinden wollen :-)
Moby A. schrieb: > Hallo Albert, kannst Du auch schon eine Vorschau auf die weitere Zukunft > geben oder gibt es dafür keinen konkreten Plan- und aktuelle Features > entstehen frei nach Lust und Laune? Das wäre natürlich sehr interessant > um etwas abschätzen zu können, inwieweit Dein Programm individuelle > Erweiterungswünsche auch in Zukunft wird abdecken können. Die > Ansteuerung des Frontends mag einfach sein, bedeutet aber trotzdem > gewisse Investitionen auf Controllerseite, die sich natürlich nicht > irgendwann in einer Sackgasse wiederfinden wollen :-) Wie Du weisst, ist das ein reines Hobby Projekt aus Spass an der Freud. Eine Garantie auf irgendwas kannst Du daher nicht erwarten. Es ist einfach so: Heute und Morgen hab ich Lust was zu machen, Übermorgen oder lange Zeit dann gar nicht. Oder vielleicht verlier ich auch Morgen schon die Motivation überhaupt noch was zu programmieren. Und wenn ich was mache, dann meist das was mich gerade interessiert. Was das in Zukunft sein wird kann ich nicht voraussehen. Ich will mich selber nicht mit irgendwelchen längerfristigen Milestones unter Druck zu setzen. Wenn Du damit nicht leben kannst, musst Du auf kommerzielle Produkte zurückgreifen (LabView oder sonst was); das ist nicht böse gemeint, sondern ein ernst zu nehmender Hinweis. Was in meinen privaten Versionen bereits seit langer Zeit funktioniert, ist z.B. die Konnektivität über Netzwerk (UDP). Ob ich das veröffentliche weiss ich noch nicht. Daselbe trift auf SerialComMeasurement zu, welches inzwischen mit allen veröffentlichten Features wunderbar arbeitet und mir eine grosse Hilfe beim Basteln ist.
:
Bearbeitet durch User
Alles klar, Albert. Dann bleibt zu hoffen, daß Du den Spaß an diesem Hobbyprojekt im Interesse vieler Anwender mit Controller-Steuerungen und mehr oder weniger kleinem PC Visualisierungs-Bedarf so schnell nicht verlierst. Für meinen Teil ist die -verständliche- Unsicherheit nun zuviel des Guten und ich werde andere (programmierbare) Frontend-Alternativen ins Auge fassen und umsetzen. Bis dahin wird mir Dein Programm mit meiner gegenwärtigen Haussteuerungs-Oberfläche noch eine Weile gute Dienste leisten. Vielen Dank für Deine Mühe, Dir ist eine Software mit echten Alleinstellungsmerkmalen gelungen.
Moby A. schrieb: > und ich werde andere (programmierbare) Frontend-Alternativen ins > Auge fassen und umsetzen. Es wäre schön, wenn Du dann ab und zu mal über die Erfahrungen damit berichtest. Das würde nicht nur mich, sondern bestimmt auch andere hier interessieren.
:
Bearbeitet durch User
Mich! Ich weiß eigentlich gar nicht so genau was man wie damit macht.
Wenn es soweit ist gerne. Ich weiß, Du hast im Hinterkopf: Sooo einfach wirds nicht werden ;-)
Die UDP Version tät mich schon interessieren.
Moby A. schrieb: > Ich weiß, Du hast im Hinterkopf: Sooo einfach > wirds nicht werden ;-) Ich wollte ja eigentlich nichts dazu sagen: LabView ist ein langer Kampf und sehr gewöhnungsbedürftig. Es müllt den PC zu und hinterlässt da Relikte die Du nicht mehr so leicht los wirst. Wie auch immer, wenn man es nach Monaten gut beherrscht, kann man schöne Dinge damit machen. Einige lieben es, viele fluchen nur. Jeder muss da seine eigenen Erfahrungen machen und aus diesem Grunde ist auch SerialComInstruments entstanden. Daher interessieren mich auch Erfahrungsberichte zu LabView aus Deiner Hobbyisten-Sicht.
:
Bearbeitet durch User
Übrigens gibt es hier weitere Infos zu SerialComMeasurement: http://www.serialcominstruments.com/measurement.php Das spielt inzwischen auch recht gut mit SerialComInstruments zusammen.
Dieser Beitrag ist weder sinnlos noch soll er es in Zukunft bleiben lassen. Wenn man keine Ahnung hat, um was es geht, sollte sich vielleicht vorher mal den Thread durchlesen bevor man einen unqualifizierten Post loslässt, den keiner lesen will noch interessiert. Ich hab nun deswegen extra eine Benachrichtigung bekommen und meine Zeit wegen DIR vergeudet.
Mein vorheriger Beitrag bezog sich auf einen Post, der vom Moderator bereits gelöscht wurde. Da ich meinen Beitrag weder bearbeiten noch löschen kann, schreibe ich das hier zur Klarstellung. Der Mod kann aber auch meine beiden Beiträge löschen.
Anbei neue Version SerialComInstruments v0.49a Maintenance Release v0.49b Change Log ------------------------------------- Instrument Trigger #87 Protokoll: #TP< Fehler bein Senden des optionalen Parameters P behoben. Es wird beim Trigger Event "#TP<" an den MC gesendet, wobei P=Integer Terminal-Fenster überarbeitet. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Kann ich eigentlich mit dieser Software die Daten von meinem Tischmultimeter über einen Seriell/USB Wandler darstellen? Was muss ich lesen, um das so einzurichten, wenn das klappen sollte? Komme nämlich schon lange nicht mehr mit. :-(
:
Bearbeitet durch User
Im Prinzip schon. Kommt aber darauf an, was dein Multimeter an Daten so rausschmeisst. Hast du einen Link zur Beschreibung?
Rainer M. schrieb: > Im Prinzip schon. Kommt aber darauf an, was dein Multimeter an Daten so > rausschmeisst. > > Hast du einen Link zur Beschreibung? Jau! Ist ein DM3051. http://www.batronix.com/pdf/Rigol/UserGuide/DM3000_UserGuide_EN.pdf
:
Bearbeitet durch User
Auf die schnelle finde ich nichts über das Datenformat, wie die RS232 die Daten ausspuckt. Wenn du das an den PC anschliesst und mit einem Terminal wie z.B. Putty die Daten empfängst, wie sehen die aus?
:
Bearbeitet durch User
Das muss ich mal gucken. Werde das aber erst am Wochenende schaffen. Ab morgen will ich wieder arbeiten gehen. Ich war nun lange genug zu Hause. Gleich muss ich noch meinen Kundendienstwagen fit machen und mal die 100000 Mails abrufen und lesen, die in den sechs Wochen sicher aufgelaufen sind.
F. F. schrieb: > Kann ich eigentlich mit dieser Software die Daten von meinem > Tischmultimeter über einen Seriell/USB Wandler darstellen? F. F. schrieb: > Jau! Ist ein DM3051. SerialComInstruments ist konzipiert für den Betrieb mit frei programmierbaren Mikrocontrollern, die in der Lage sind das erwartete Datenformat zu erzeugen (siehe auch im Manual): #nnMm< wobei # =Startkennung, nn =Instrumentnummer, M =Messwertkennung, m =Messwert(Int, Float, Text) < =Endekennung Beispiele: #51M3.6543< sende an Instr.51 den Wert 3.6543 #38MHallo< sende an Instr.38 den Text "Hallo" Dieses Datenformat kann dein DM3051 nicht erzeugen. Vielleicht ermögliche ich es in einer zukünfigen Version (fast) beliebige serielle Datenströme zu lesen und entsprechend von Vorgaben in einem speziellen Menue die Werte bestimmten Instrumenten zuzuweisen. Das ist aber ein weites Feld :)
:
Bearbeitet durch User
In den nächsten Tagen werde ich mal eine einfache Funktion zum Auslesen von einem Tischmultimetern und ähnlichen Quellen implementieren. Das Datenformat wäre dann einfach: Messwert + CR Die Umstellung vom SerialComInstruments Standardformat und Zuweisung zu einem Instrument würde dann direkt auf der Interface-Page erfolgen. Allerdings habe ich mal vergeblich versucht ein billiges Tischmultimeter über dessen RS232 Buchse mit einem kleinen China Serial/USB Modul auszulesen. Wahrscheinlich waren die Pegel nicht kompatibel, ich hatte aber damals keine Lust das weiter zu ergründen.
:
Bearbeitet durch User
Ich hätte eher daran gedacht, einen Mikrokontroller dazwischen zu schalten, der seriell einliest und die Messwerte im richtigen Format weitergibt.
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.49c
Change Log v0.49c
-----------------
Neues Protokoll für z.B. Betrieb mit einem Tischmultimeter usw.
Dies ist ein einfaches 1-kanaliges Protokoll:
mCRLF wobei m = Messwert als String
CR = Carriage Return (#13)
LF = Line Feed (#10)
Das Protokoll wird im Interface-Fenster gewählt, in dem auch das
gewünschte zugehörige Instrument eingestellt wird (siehe Bild oben).
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Na Albert, dann muss ich mich da wohl mal rein arbeiten. Denn die Rigolsoftware funktioniert auch nicht so richtig.
Das ging aber fix. Ist die UDP Version auch schon etwas gediehen?
Rainer M. schrieb: > Ist die UDP Version auch schon etwas gediehen? Netzwerk/LAN-Konnektivität: Wie schon oben irgendwo geschrieben läuft bei mir UDP. Allerdins ist das eine Rohfassung nur als UDP-Empfang. Am UDP Senden muss ich noch etwas werkeln. Wenn Dir UDP-Empfang zur Zeit zum Testen etwas nutzt, kann ich so eine Vorab-Version hier veröffentlichen. Zum "nur Visualisieren" reicht das ja aus.
:
Bearbeitet durch User
Visualisieren würde schon reichen. Im Moment z.B. sendet ein Server alle x Sekunden Daten per Broadcast, und per WIFI angebundene Display stellen sie dar. Da könnte ich dann im entsprechenden Format die Daten mitschicken und auf jedem PC schön grafisch darstellen, ohne eine serielle Verbindung zu haben. Die habe ich im Moment nur auf meinem Bastel-PC. Später könnte ich mir einen RPI mit 7" Display und Win10 vorstellen, der auf dem Sideboard im Wohnzimmer steht ;-)
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.49d Change Log v0.49d ----------------- LAN UDP Connection - Experimental Only Einstellung für Local Port zu finden unter Interface. Bei Aktivierung lauscht das Programm auf eingehende UDP Pakete auf dem angegebenen Port. Es sollten Portadressen über 6000 verwendet werden, ich verwende 6001. Senden über UDP ist noch nicht fertig implementiert. An der Formatierung der SerialComInstruments Befehls-Strings ändert sich nichts. An statt über die serielle Schnittstelle werden diese einfach vom MC über UDP gesendet. Die UDP Problematik, das eintreffende Pakete ab und an mal nicht der ursprünglichen Sendereihenfolge entsprechen, wird als bekannt vorausgesetzt. Bei mir konnte ich das allerdings im Testbetrieb noch nicht feststellen. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Danke. Werde es so bald als möglich probieren und berichten
UDP / LAN Modus Das Mini-Trend Instrument #90/#91 funktioniert im UDP Betrieb nicht, das Full Trend Instrument und alle anderen arbeiten aber problemlos. Der Fehler wird in der nächsten Version behoben.
Nun kann man also bereits von mehreren uCs aus über Ethernet UDP-Packete an den selben UDP-Port schicken?
Lars R. schrieb: > Nun kann man also bereits von mehreren uCs aus über Ethernet UDP-Packete > an den selben UDP-Port schicken? Kann ich hier mangels Hardware nicht testen. Aber Versuch macht klug. DU kannst es ja mal probieren und berichten, würde mich interessieren. Meine Testmöglichkeiten beschränken sich z.Z. auf das Freeware Terminal Programm "Hercules Setup Utility" um über UDP zu senden/empfangen, welches gleichzeitig auf meinem Entwicklungs-PC läuft. Also nicht so ganz ideal :)
:
Bearbeitet durch User
Das muss gehen. ich mach das schon mit einem Display, das mit einem ESP8266 am Netz hängt. Und Windows macht das bestimmt nicht schlechter.
Albert M. schrieb: > Kann ich hier mangels Hardware nicht testen. Ich habe nun noch ein vergessenes W5100 Ethernet Shield für Arduino gefunden. Da gibt es nun doch reale Hardware zum UDP-Testen :)
Lars R. schrieb: > Nun kann man also bereits von mehreren uCs aus über Ethernet > UDP-Packete > an den selben UDP-Port schicken? Habe es probiert, wie bereits angenommen, es geht.
Angehängte Dateien:
Die komplette LAN Integration über UDP macht gute Fortschritte, oben ein Bild des aktuellen UDP Interfaces. Mit Klick auf den Button "Bind To Local Adress" wird optional automatisch die gefundene locale IP-Adresse in das Eingabefeld eingetragen. Das Senden über UDP für die entsprechende Instrumente wie Taster usw ist auch soweit funktionsfähig. Wer nur das Empfangen der Daten über UDP testen möchte, kann das bereits mit der letzten Programm-Version probieren.
:
Bearbeitet durch User
Für das Senden vom PC an mehrere uC sehe ich 3 Möglichkeiten: A. Jeder uC wird vom PC aus über eine eigene IP-Adresse/UDP angesteuert B. Es wird Broadcast/UDP gesendet. Im Protokoll wird mitgeteilt, welcher uC angesprochen wird. Der uC prüft, ob das Paket für ihn ist. C. Es wird Broadcast/UDP gesendet. Im Protokoll wird mitgeteilt, welcher Taster gemeint ist und jeder uC prüft, ob er diesen Taster hat. (Wie kann man dann allerdings Serial-Measurement-Programme an verschiedene uCs verteilen?... Man könnte sie einzeln am Comport programmieren, falls das Programm im uC-Flash gespeichert wird) Der Nachteil von Variante A ist, dass viele Netzwerksockets genutzt werden. Eine Umsetzung auf ein anderes Protokoll, beispielsweise CAN ist aufwendiger. Bei Variante B oder C kann man einfacher auf andere Protokolle umsetzen und man kann auch einfach über einen COM mehrere uCs ansteuern. Der Datenstrom vom PC muss dann nur aufgeteilt werden. Variante B und C belasten das Netzwerk stärker. Bei Verwendung von Variante B kann man Variante A auch wie folgt realisieren: Im Virtualinstruments wird die lokale IP-Adresse (127.0.0.0/1) und ein bestimmer UDP-Port eingetragen. Dort lauscht ein einfaches Programm, dass die UDP-Packete auf die verschiedenen (externen) IP-Adressen aufteilt. Ebenso könnte ein UART-WIFI am COMport die selbe Aufgabe übernehmen. Man kann auch Variante C mit einem solchen Hilfsprogramm realisieren, sodass dann nur die uC-IPs die UDP-Packete bekommen und nicht alle Ethernet-Geräte. Alternativ könte man ohne ein solches Programm bei Performance-Problemen den besagten UDP-Port im Wireless-Router nur für die uC-IPs freigeben. Variante C verzeugt vermutlich am wenigsten Implementierungaufwand im VirtualInstruments. Allerdings muss der Datenstrom immer an alle uCs und man kann die uCs selbst nicht ansprechen.
Danke für den Beitrag Lars. Nach meinen Überlegungen sehe ich dazu folgendes: Ist nur ein MC am LAN ist kann die Port-Adresse angegeben und Broadcast ausgeschaltet werden. Allerdings gibt es auch MC LAN-Adapter die keine Möglichkeit zur Einstellung einer Portadresse haben, was zu Problemen führt und nur durch die Aktivierung von Broadcast behoben werden kann. Bei Betrieb mit mehreren MC's muss Broadcast für den Sendebetrieb eingeschaltet sein. Für den reinen Empfangsbetrieb (SerialComInstruments lauscht nur) dürfte es weiter keine Zuordnungsprobleme geben. Für den Sende+Empfangsbetrieb ist für die erste Implementation nur die Zuordnung über die verwendete Instrumenten-Nummer möglich (z.B. Taster#70 zu MC1 usw) ohne die Befehlssyntax zu verändern. Daher gibt es demnächst unter anderem zusätzliche Taster. Über Sonderfälle mache ich mir noch Gedanken, eventuell ist dann irgendwann doch eine Änderung der Befehlssyntax/Einstellungen notwendig. Was den Netztraffic bezüglich Broadcast betrifft so ist dieser absolut zu vernachlässigen, wenn man bedenkt wie oft z.B. das Ereignis "Taster gedrückt" auftritt. Deine Frage zu SerialComMeasurement relativiert sich insoweit, dass ich dies nicht öffentlich zur Verfügung stelle. Wer den Thread dazu gelesen hat weiss warum.
:
Bearbeitet durch User
Albert M. schrieb: > Was den Netztraffic bezüglich Broadcast betrifft so ist dieser absolut > zu vernachlässigen, wenn man bedenkt wie oft z.B. das Ereignis "Taster > gedrückt" auftritt. Zu der Ansicht neige ich auch. > Deine Frage zu SerialComMeasurement relativiert sich insoweit, dass ich > dies nicht öffentlich zur Verfügung stelle. Schon ok. Ich bezog mich ebenfalls nur auf das Protokoll. > Für den Sende+Empfangsbetrieb ist für die erste Implementation nur die > Zuordnung über die verwendete Instrumenten-Nummer möglich (z.B. > Taster#70 zu MC1 usw) ohne die Befehlssyntax zu verändern. Abgesehen von der Programmierung der SerialComMeasurement-uCs ist eine solche Zuordnung nach meinem Verständnis nicht zwingend: Es ist ja letztlich "egal", welcher uC auf "Taster#70" reagiert. Es könnten auch mehrere uCs darauf reagieren. Beispielsweise schaltet ein uC Lampe1 und der zweite schaltet Lampe 2 in 10Meter Entfernung. Meiner Ansicht nach ist die Zuordungsthematik nur in Kombination mit der Progammierung meherer SerialComMeasurement-uCs zwingend. Für den Ethernetfall könnte man statt dem Broadcast auch gezielt einzelne IPs/UDPs ansteuern, insofern die Ethernet-UART-Komponenten das unterstützen. Dazu muss ja lediglich in Virtualinstruments zwischen Boradcast und einer speziellen IP umgestellt werden, um dann für die Programmierung einzelne uCs anzusteuern.
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.49e Change Log v0.49e ----------------- Experimental Only - Ich bitte um Rückmeldungen :) Folgende Änderungen betreffen den LAN UDP Betrieb: - Jetzt alle UDP-Interface Einstellungen verfügbar. - Automatischer Eintrag der localen Adresse über Button "Bind To Local IP". - Senden für alle Taster-Instrumente #70 bis #75 freigeben. - Generell sollte beim UDP-Betrieb mit MC's Broadcast aktiviert sein, dies ergibt die wenigsten Probleme. - Eine UDP Dokumentation ist im Manual noch nicht verfügbar. - Fehler bei Instrument #90/#91 bei UDP Betrieb behoben. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.5 Change Log v0.5 --------------- LAN UDP Mode - Es sind jetzt alle Instrumente auch mit UDP betriebsbereit (Empfangen/Senden). - Programmoberfläche angepasst. Fehler behoben: - Es wurde unabhängig von der Einstellung immer als Broadcast gesendet. Exe Distribution geändert. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments v0.5a Change Log v0.5a ---------------- Gravierenden Fehler im LAN UDP Mode behoben: - es wurde fälschlicherweise immer die autom. ermittelte erste locale IP verwendet und die händisch eingetragene locale IP-Adresse ignoriert. Sorry, wenn einer da schon verzweifelt rumgebastelt hat, ich habe das auch erst nach Anschluss eines Arduino W5100 Ethernet Shield und Überprüfung mit Wireshark bemerkt. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hat eigentlich schon jemand das Programm auf einem Gerät mit Touchscreen ausprobiert? Kann man da wie vom Handy/Tablett gewohnt, die Knöpfe drücken und die Slider verschieben?
Anbei neue Version SerialComInstruments v0.5b Change Log v0.5b ---------------- Weiteres Taster-Instrument #74 zugefügt. Fehler behoben (#70..#73): - Taster-Instrumente Ereignis Mouse-Up wurde für UDP nicht ausgewertet (Mouse-Down funktionierte). http://www.serialcominstruments.com/
:
Bearbeitet durch User
Rainer M. schrieb: > Hat eigentlich schon jemand das Programm auf einem Gerät mit Touchscreen > ausprobiert? Ja, grad eben, Windows 10 Rechner mit 19" Touch > Kann man da wie vom Handy/Tablett gewohnt, die Knöpfe drücken und die > Slider verschieben? Ja, funktioniert gut.
Hallo Albert, das Hintergrundbild skaliert mit der Fenstergrösse. Somit sind die Instrumente nicht mehr an der vorgesehenen Stelle im Hintergrundbild. Lässt sicch das ändern? Eine weitere Frage: Kann man das Programm irgendwie konfigurieren, dass es beim Start automatisch die letzte verwendete ini lädt und sofort die Messwerte anzeigt? So dass man es direkt in den Autostart einbinden kann.
Rainer M. schrieb: > das Hintergrundbild skaliert mit der Fenstergrösse. Somit sind die > Instrumente nicht mehr an der vorgesehenen Stelle im Hintergrundbild. > Lässt sicch das ändern? So oder so musst Du Dich bei einem Hintergrundbild auf eine feste Fenstergrösse beschränken. Bei einer Grössenänderung des Fensters skaliert entweder der Hintergrund und die Instrumentenpositionen stimmen nicht mehr oder bei nicht skaliertem Bild hast Du Leerflächen um das Bild, bezw. beschneidest es. Aber egal, ich werde eine Option "skaliert/nicht skaliert" in der nächsten Version einfügen. Für die passende Bildgrösse ist dann jeder selbst verantwortlich. Rainer M. schrieb: > Kann man das Programm irgendwie konfigurieren, dass es beim Start > automatisch die letzte verwendete ini lädt und sofort die Messwerte > anzeigt? So dass man es direkt in den Autostart einbinden kann. Werde ich mal drüber nachdenken. Das ist allerdings eine aufwendigere Aktion, da alle Schnittstellenparameter gespeichert und geladen werden und noch weitere Implikationen bedacht werden müssen. Für die nächste Version kann ich das noch nicht versprechen.
:
Bearbeitet durch User
Albert M. schrieb: > Rainer M. schrieb: >> Kann man das Programm irgendwie konfigurieren, dass es beim Start >> automatisch die letzte verwendete ini lädt und sofort die Messwerte >> anzeigt? So dass man es direkt in den Autostart einbinden kann. > > Werde ich mal drüber nachdenken. Das ist allerdings eine aufwendigere > Aktion, da alle Schnittstellenparameter gespeichert und geladen werden > und noch weitere Implikationen bedacht werden müssen. Für die nächste > Version kann ich das noch nicht versprechen. Eilt nicht, noch gibt es ja Win10 nicht für den Raspberry;-)
Rainer M. schrieb: > Kann man das Programm irgendwie konfigurieren, dass es beim Start > automatisch die letzte verwendete ini lädt und sofort die Messwerte > anzeigt? So dass man es direkt in den Autostart einbinden kann. +1 > Eilt nicht, noch gibt es ja Win10 nicht für den Raspberry;-) Ist das wegen dem Simley ein Scherz? Diese exe wird jedenfalls aus mehreren Gründen nicht auf dem Raspberry mit Win10 laufen.
Im übrigen prüft die Software ob in einer virtuellen Umgebung gearbeitet oder mit irgendwelchen Hackertools zugegriffen wird usw. In allen diesen Fällen bricht das Programm sofort oder zufallsgesteuert später ab. Teile des Programms laufen intern in einer virtuellen Umgebung und die exe ist gescrambelt und nicht re-engineerbar. Da beisst sich der Durchschnitts-Hacker die Zähne aus :)
Nein, kein Scherz. Begründete Hoffnung, die ja zuletzt stirbt. Aber du klärst mich bestimmt auf. Edit: Mein Post hat sich mit dem von Albert überschnitten. D.h, die SOftware überprüft auf Win10 PI und läuft dann?
:
Bearbeitet durch User
Rainer M. schrieb: > Edit: Mein Post hat sich mit dem von Albert überschnitten. > D.h, die SOftware überprüft auf Win10 PI und läuft dann? Von Raspi habe ich keine Ahnung und kann daher dazu nichts sagen. Mein Post oben bezieht sich nur auf den Schutz gegen Re-Engineering und Änderung der Software durch Andere.
z.B.: Diese Exe läuft nur auf x86- und x64-CPUs.
:
Bearbeitet durch User
Es sei denn Albert ist so nett und crosscompilt dann für den Win10 PI. Hoffnung habe ich ja. Allerdings durch nichts begründet. Deswegen ja Hoffnung.
Rainer M. schrieb: > Es sei denn Albert ist so nett und crosscompilt dann für den Win10 PI. Und mit welchem Compiler soll das funktionieren? Auf den Betrieb in einer virtuellen Umgebebung hätte ich am ehesten getippt. Aber wie Albert nun sagt, soll oder darf man es da nicht laufen lassen. Edit: Man kann auch für Linux kompilieren und dann nur das Binary herausgeben. Das liefe dann beispielsweise eben nur mit einer ganz bestimmten Raspbian-Version. Aber bereits hier ist die Frage, ganz unabhängig vom Willen Alberts, ob das mit dem existierenden Programmcode mit überschaubarem Aufwand möglich ist (graphische Elemente, GUI) https://de.wikipedia.org/wiki/Lazarus_%28Entwicklungsumgebung%29
:
Bearbeitet durch User
Lars R. schrieb: > Auf den Betrieb in einer virtuellen Umgebebung hätte ich am ehesten > getippt. Aber wie Albert nun sagt, soll oder darf man es da nicht laufen > lassen. Der Hintergrund dazu ist, dass viele Hackertools die Software während des Hacks in einer virtuellen Umgebung benötigen. Das wird in meinem Programm erfolgreich unterbunden.
Lars R. schrieb: > Rainer M. schrieb: > Und mit welchem Compiler soll das funktionieren? > Da sind meine bescheidenen Kenntnisse zu Ende. Aber ich nehme an, es wird mit einem für PI Win10 optimierten Crosscompiler mit gescrambelter und nicht re-engineerbarer Ausgabe gemacht werden. Weiteres dafür musst du bei Microsoft anfragen ;-)
Lars R. schrieb: > Man kann auch für Linux kompilieren und dann nur das Binary > herausgeben. Das liefe dann beispielsweise eben nur mit einer ganz > bestimmten Raspbian-Version. Aber bereits hier ist die Frage, ganz > unabhängig vom Willen Alberts, ob das mit dem existierenden Programmcode > mit überschaubarem Aufwand möglich ist (graphische Elemente, GUI) Irgendwo ganz weit oben habe ich dazu schon mal was geschrieben. Die Software wird mit Delphi 7 Prof. erstellt. Benötigt dafür werden zum Teil recht kostspielige Komponenten, die für neuere Delphi Versionen wieder gekauft/upgedated werden müssten oder die es z.B. für Lazarus erst garnicht gibt. Da es sich dabei um einen 4-stelligen Betrag handeln würde, habe ich dazu für meine Just-For-Fun Software keine Lust. Demnach wird es kein Crosscompiling geben.
:
Bearbeitet durch User
Frage definitiv beantwortet. Also kein PI, sondern ein Win10 Tablett. Da läuft es dann hoffentlich. Wenn nicht, dann halt ein MiniPC mit Touch Bildschirm aud die Wohnzimmerkommode. Hauptsache hoher WAF ;)
Albert M. schrieb: > Die Software wird mit Delphi 7 Prof. erstellt. Benötigt dafür werden zum > Teil recht kostspielige Komponenten, die für neuere Delphi Versionen > wieder gekauft/upgedated werden müssten oder die es z.B. für Lazarus > erst garnicht gibt. Da es sich dabei um einen 4-stelligen Betrag handeln > würde, habe ich dazu für meine Just-For-Fun Software keine Lust. Demnach > wird es kein Crosscompiling geben. Das verstehe ich natürlich. Aber weiter oben schreibst Du: Albert M. schrieb: > Im übrigen prüft die Software ob in einer virtuellen Umgebung gearbeitet > oder mit irgendwelchen Hackertools zugegriffen wird usw. In allen diesen > Fällen bricht das Programm sofort oder zufallsgesteuert später ab. Teile > des Programms laufen intern in einer virtuellen Umgebung und die exe ist > gescrambelt und nicht re-engineerbar. Da beisst sich der > Durchschnitts-Hacker die Zähne aus :) ...und das verstehe ich nun wirklich beim besten Willen nicht. Nach den Querelen in diesem Thread kann ich bis zu einem gewissen Punkt nachvollziehen, daß Du nicht möchtest, daß die Querulanten Deinen Code auseinandernehmen oder stehlen. Aber wovor hast Du denn so große Angst? Daß jemand ein fünf(!) MB großes Binary disassembliert, analysiert und nachbaut? Andererseit schließt Du durch Deine Schutzmaßnahmen all jene Linux- und Mac-Nutzer, die Dein Programm gerne in einer Windows-VM benutzen wollen, kategorisch aus. Warum eigentlich?
Fairerweise sind wir informiert. Ob es vielleicht mit wine (kein Emulator) läuft, hatte scheinbar mangels Interesse hier auch noch niemand ausführlich getestet. Es gibt genügend Nutzer, die sich über die Windows-Version freuen.
:
Bearbeitet durch User
Lutz M. schrieb: > Was bei Delphi/Kylix m.W. nicht dabei ist: die Sourcen vom GUI-Editor. > Den würde ich nämlich hacken wollen, um das ganze überflüssige Zeugs > raus- und fehlendes (z.B. LED-Anzeigen) reinzubauen. Die C/C++ Jünger glauben wohl, das dieses Sprachkonstrukt der Weisheit letzter Schluß ist, bloß weil ein Großteil mit C programmiert und alles was an neueren Programmiersprachen nachkommt schon sehr C-lastig ist. Wenn etwas viel benutzt wird dann bedeutet dies nicht gleichzeitig, das es auch gut ist. Oftmals hat es historische Gründe, daß sich eine Sache stark verbreitet hat und viele nicht bereit sind im Nachgang einen anderen Weg zu beschreiten. Kann ich ja auch nachvollziehen wenn man ein großes Projekt hat, daß man da nicht einfach alles über den Haufen schmeißt. Dein Post zeigt wieder mal typisches C-Programmiererverhalten. Du hast Null Ahnung von Delphi. Das die Sourcen von GUI Editor bei der fertig kompilierten Exe nicht dabei sind ist doch völlig normal. Im Projekt selbst gibt es selbstverständlich eine entsprechende Datei. Des Weiteren kann man in Delphi selbstverständlich auch das GUI zur Laufzeit ändern und selbiges in einer Datei (auch XML) ablegen, sofern dies der Schöpfer des Programmes vorgesehen hat. Was nutzt es Dir irgendwelches Zeugs rein oder raus zu bauen, wenn Du es danach im Programm nicht ansprechen kannst. Um z.B. auf die nachträglich eingebaute LED zugreifen zu können müßte man schon noch eine passende Logik im Programm hinterlegen. Mit Handauflegen funktioniert es leider noch nicht. Ich finde Alberts Arbeit eine respektable Leistung und wer meint es besser machen zu können, soll's einfach mal vormachen. Gruß Twinsetter
Für Einsteiger in SerialComInstruments habe ich ein kurzes Video erstellt: Video HowTo for beginners: https://youtu.be/gjrAIWrVBIM Gruss Ulrich Albert
Angehängte Dateien:
Wer ist an der Darstellung statistischer Daten interessiert. Ein neues Instrument dafür würde ähnlich wie im Bild oben sein. Die Darstellung erfogt als Box und Whisker Plot. Ausserdem währe eine Print-Möglichkeit vorgesehen. Angezeigt werden jeweils optional in Realtime: - minimum - maximum - mean - median - 10-percentile: 10 percent of all data are below this value - 1st quartile: 1 quarter of the data is less than this threshold - 3rd quartile: 3 quarters of the data are less than the 3rd quartile - 90-percentile: 90 percent of the data are below this threshold Anwendungsfälle gibt es dafür eigentlich viele. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Albert, könnte man das nicht verwenden, um Messwertausreisser zu analysieren und damit auf die Qualität der Sensoren/Verkabelung/Einstrahlung zu schliessen und selbige verbessern?
Albert M. schrieb: > Wer ist an der Darstellung statistischer Daten interessiert. Rainer M. schrieb: > könnte man das nicht verwenden, um Messwertausreisser zu analysieren und > damit auf die Qualität der Sensoren/Verkabelung/Einstrahlung zu > schliessen und selbige verbessern? Genau für solche Dinge, wie auch A/D-Wandler Überprüfungen, Test von Sensoren usw.
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.6 v0.6 Change Log --------------- Neues Compass / Flight Instrument #92 (für Kompass- und Neigungswinkel-Sensoren) Die Werte werden von den Analog-Instrumenten 01...03 abgeleitet. Der Wert für den Sollkurs wird an 92 gesendet. 01 = Course, sinnvolle Werte 0...360 Grad 02 = Pitch, sinnvolle Werte -50 ....+50 Grad 03 = Roll, sinnvolle Werte -50 ....+50 Grad 92 = Sollkurs, sinnvolle Werte 0...360 Grad (roter Pfeil) Protokoll: #nMm< wobei n = 1...3 und 92, sowie m=Messwert Datenrichtung: vom MC zum PC Verschiebbar: ja, mit Mouse Grössenänderung: ja, mit Mouse Der zusätzlich angezeigte Wert Dev (Deviation) zeigt die Abweichung des tatsächlichen Kurses (Course) vom Sollkurs. Weitere Änderungen (unter Options, betrift das Fenster "Show"): Background Image: wahlweise skaliert/stretch oder unskaliert Background Farbe: wahlweise Gradient oder normal Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Anbei neue Version SerialComInstruments v0.6a v0.6a Change Log ---------------- Fehler in der num. Werte-Anzeige und Formatierung folgender Instrumente behoben: - Slider Rund Instrument - Slider Vertikal Instrument - PID Instrument Der editierbare Formatierungs-String (Beispiel ###0.0) wurde nicht korrekt ausgewertet und angezeigt. Gruss Ulrich Albert http://www.serialcominstruments.com/
Rainer M. schrieb: > Was macht den das Statistik Modul? Hat ja weiter hier kaum einen interssiert. Daher ist die Statistik nun in abgespeckter Form nur in SerialComGrapher implementiert: https://www.mikrocontroller.net/attachment/269029/SerialComGrapher_Bild10.png
:
Bearbeitet durch User
Schade. Ich hätte schon mal gerne verschiedene billig Sensoren getestet. Muss ich mir halt selbst mal was programmieren :-(
Rainer M. schrieb: > Schade. Ich hätte schon mal gerne verschiedene billig Sensoren getestet. > Muss ich mir halt selbst mal was programmieren :-( Und warum benutzt Du nicht SerialComGrapher mit der neuen Statistik Funktion dafür? http://www.serialcominstruments.com/serial.php
Hallo Albert, mir ist aufgefallen, das ab V0.5 die Instrumente #38 und #75 werden nicht mehr abgespeichert. Gruss und Dank sand
Anbei neue Version SerialComInstruments v0.6b v0.6b Change Log ---------------- Fehler behoben: Die Instrumente #38 und #75 wurden nicht im ini-File gespeichert.
Hallo Albert, noch eine Bemerkung, das Terminalfenster ist nicht groß genug lange Zeilen darzustellen, bzw. der Zeilenumbruch arbeitet nicht korrekt. Gruß sand
Hallo Albert, Vorschlag für eine Erweiterung, eine Kombination aus den Instrumenten #30 PID-Parameter zum Senden und dem Terminal Fenster zum Empfang. Eine Anzahl von Sende-Fenstern für frei wählbare Parameter die zum MC gesendet werden. Ein Beispiel: Es könnten (in der Testphase) die Timer-Register vom MC extern umprogrammiert werden. "TCCR0A,01100011" "TCCR0B,00001010" "OCR0A,127" "OCR0B,120" "Timsk0,00000110" "TCCR1A,10110000" "TCCR1B,B00010001" "OCR1A,1600" "OCR1B,4800" "ICR1,8000" "Timsk1,00000110" Sende-Fenster: ca 12, einzeln anwählbar zum Senden Parameter-Länge: max 80Zeichen Empfang-Fenster: wie Terminal Fenster Mit mehreren Sende-Fenstern können die Parameter stehen bleiben und müssen nicht immer wieder überschrieben werden. Gruß biker10
Angehängte Dateien:
Dieter H. schrieb: > Vorschlag für eine Erweiterung, eine Kombination aus den Instrumenten > #30 PID-Parameter zum Senden und dem Terminal Fenster zum Empfang. Das ist mir zu aufwändig. Ich biete aber als Alternative folgendes neues Instrument, auch als Ersatz für fehlende Buttons, in der nächsten Version an: Send Predefined Commands Eine editierbare Liste mit frei belegbaren beliebigen alphanumerischen Kommandos und deren Beschreibung. Die Auswahl-Liste kann beliebig lang sein. Bei Klick auf "Send" wird das Kommando über die Schnittstelle zum Mikrocontroller übertragen. Die Liste wird optional bei "Save Projekt as" mit ins ini-File gespeichert. Die Bilder oben zeigen ein fiktives Beispiel. Event. kommt noch als opt. wählbarer Delimiter/Endezeichen CR (asc13) hinzu.
:
Bearbeitet durch User
Angehängte Dateien:
-
Bild1.PNG
9,6 KB
Hallo Albert, das ist für meine Vorstellung zu umständlich. Wie im Bild1 zu sehen möchte ich quasi online die Bits der Register setzen und an den MC senden. Das entsprechende Register lasse ich mir zur Kontrolle auf dem Terminal wieder anzeigen. Mit einem LA oder Oszi kann ich das Ergebnis der Registeränderung sofort auf dem MC sehen. Im Prinzip funktioniert es mit dem Terminal. Aber, es fehlen dem Terminal mehrere Sendefenster für mehrere Sende Parameter. Das Sende Fenster mit dem Register Parameter sollte nach dem Senden nicht gelöscht werden. Gruß biker10
Hallo Albert, tolles Programm. Bin gerade dabei, mich einzuarbeiten. Habe auch schon einen Bug gefunden? Bei Version 0.6b ist das Häkchen bei "Dig.Display #65" immer gesetzt und läßt sich auch nicht entfernen, angezeigt wird aber nichts. Woran liegt das? Und folgende Frage: gibt es command line parameter? Wäre z.B. schön, wenn man dem Programmaufruf gleich ein Projektfile mitgeben könnte, und das Programm startet dann schon mit den Instrumenten. Und dem >>Das Sende Fenster mit dem Register Parameter sollte nach dem Senden >>nicht gelöscht werden. schließe ich mich an, bzw. man könnte eine Option einbauen, mit der gelöscht/nicht gelöscht wird (Häkchen). Danke für deine Arbeit! Günter
Dieter H. schrieb: > Im Prinzip funktioniert es mit dem Terminal. > Aber, es fehlen dem Terminal mehrere Sendefenster für mehrere Sende > Parameter. Event. könnte ich die Funktionalität des neuen Instruments "Send Predefined Commands" auch ins Terminalfenster einbauen, damit würden mehrere Sendefenster (die ich nicht implementieren will) überflüssig. Günter R. schrieb: > Habe auch schon > einen Bug gefunden? Bei Version 0.6b ist das Häkchen bei "Dig.Display > #65" immer gesetzt und läßt sich auch nicht entfernen, angezeigt wird > aber nichts. Woran liegt das? Kein Bug, das Häkchen bei #65 ist immer gesetzt. Die LEDs können auf der Parameterseite (Klick auf Button #65) einzeln aktiviert und konfiguriert werden.
Angehängte Dateien:
Vorschau für die nächste Version: Neue Funktion im Terminal Fenster: "Send Predefined Commands" Hier können in einer editierbaren und sortierbaren Liste oft benutzte beliebige Kommandos für Testzwecke incl. Kommentar eingetragen und gesendet werden. Ist unter Terminal das Häkchen bei CRLF gesetzt, so wird CR+LF beim Senden an das Kommando angehängt. Die Listeneinträge werden beim Speichern gesichert. Die gleiche Funktionalität wird auch als zusätzliches Instrument kommen.
:
Bearbeitet durch User
Hallo Albert, ich hatte kürzlich nach Command-Line-Parametern gefragt. Gibt es welche? Kann man da ein Projektfile angeben, sodaß dieses gleich mit dem Programm gestartet wird? Mit der Version 0.6b habe ich unter Win XP SP1 Probleme; manche Instrumente (z.B. DIP-Schalter, PID, LED-Anzeige), lassen sich (im Edit-Mode) nicht verschieben, nur leicht in der Größe verändern. Liegt das an meinem WinXP? Im Handbuch finde ich übrigens keine Seitenzahlen; wäre nicht schlecht, um sich auf eine bestimmte Stelle dort zu beziehen. Ich habe gelesen, daß es beim Beenden nun kein automat. Update des geladenen Projekt-Files mehr gibt. Aber evt. wäre eine Warnung beim Beenden, daß etwas verändert wurde (wie bei anderen Windows-Programmen) nicht schlecht. Und dies dann evt. auch, wenn gar kein Projekt-File gespeichert wurde; solche Warnungen könnte man in einem Konfig-Window auch abschaltbar machen (ich weiß: jede Menge Arbeit ... muß ja nicht gleich geschehen). Die Setup-Installation beschränkt sich, wenn ich das richtig beobachtet habe, im Entpacken des exe-Files und Kopieren in ein Directory; daß jede Menge DLL's über den ganzen PC und in die Registry verstreut werden (wie bei anderen Windows-Programmen) findet hier wohl nicht statt; sehe ich das richtig? D.h. eine evt. Deinstallation könnte man auch händisch durch Löschen des Directories, in dem die Dateien landen, durchführen? Dann könnte man dazu evt. auch einen kurzen Hinweis im Handbuch geben, das beruhigt Leute wie mich, die nicht gerne neue Software installieren, aus der Sorge, man bekommt sie nicht mehr vollständig vom System runter. Ich setze große Stücke auf dieses Programm, auf das ich erst vorgestern gestoßen bin, will aber viele (private) uC-Projekte mit dieser Visualisierung ausstatten, daher meine Anregungen (kommen noch mehr, wenn erwünscht). Günter
Günter R. schrieb: > ich hatte kürzlich nach Command-Line-Parametern gefragt. Gibt es welche? > Kann man da ein Projektfile angeben, sodaß dieses gleich mit dem > Programm gestartet wird? Kann ich eventuel einbauen. Günter R. schrieb: > Mit der Version 0.6b habe ich unter Win XP SP1 Probleme; manche > Instrumente (z.B. DIP-Schalter, PID, LED-Anzeige), lassen sich (im > Edit-Mode) nicht verschieben, nur leicht in der Größe verändern. Liegt > das an meinem WinXP? Alle Instrumente lassen sich auch unter WinXP verschieben. Wie im Manual beschrieben, die Instrumente zum Verschieben möglichst ganz unten rechts (in der Leiste wenn eine vorhanden) mit der Mouse bewegen. Günter R. schrieb: > Im Handbuch finde ich übrigens keine Seitenzahlen; Siehe Manual 1. Seite: "Zur Navigation in diesem Dokument schalten Sie bitte die Lesezeichen in Ihrem PDF-Viewer ein." Moderne PDF Viewer zeigen dann die detailierte Kapitelübersicht in Baumstruktur an. Seitenzahlen werde ich nicht einführen. Günter R. schrieb: > Ich habe gelesen, daß es beim Beenden nun kein automat. Update des > geladenen Projekt-Files mehr gibt... Dazu werde ich mir nochmal Gedanken machen. Günter R. schrieb: > Die Setup-Installation beschränkt sich, wenn ich das richtig beobachtet > habe, im Entpacken des exe-Files und Kopieren in ein Directory; daß jede > Menge DLL's über den ganzen PC und in die Registry verstreut werden (wie > bei anderen Windows-Programmen) findet hier wohl nicht statt; sehe ich > das richtig? D.h. eine evt. Deinstallation könnte man auch händisch > durch Löschen des Directories ... Es wird beim Setup aus Kompatibilitätsgründen zu älteren Win Versionen nur eine dll Datei ins gewählte Programmverzeichnis geschrieben. Das händische Deinstallieren mittels Löschen des Programmverzeichnisses sollte man jedoch unterlassen, da sonst Artefakte wie Destop Icon, Startmenue Einträge usw. zurückbleiben. Daher immer die mitinstallierte Deinstallations-exe starten.
:
Bearbeitet durch User
Hallo Albert, habe noch etwas an SerialComInstruments probiert. Tolles Programm. Dennoch fallen mir einige Dinge auf; diese möchte ich dir mitteilen. - Bei Projekt-Files werden die COM-Parameter, also COM-Port und Baudrate, offensichtlich nicht mit abgespeichert. Das ist nicht so praktisch, würde ich noch einbauen. - Wenn ich auf meinem XP-Rechner das Programm starte (dann ist ja zunächst noch kein Projekt-File aktiv), dann ist das Programmfenster überbreit. Du hast wohl einen besser aufgelösten Bildschirm als ich. Da wäre es praktisch, wenn in einem allgemeinen Ini-File (so eines gibt es offgensichtlich irgendwo, denn das Programm merkt sich, wo ich das letzte Projekt-File abgelegt habe) die letzte Programmfenstergröße und -position abgespeichert wäre, und diese sollte bei Ptrogrammstart wieder geladen werden, dann passiert das oben beschriebene nicht mehr (bzw. nur beim ersten Mal). - Nebenbei: evt. wäre es praktisch, den Projektfiles eine andre Extension zu geben, z.B. "*.ssc", falls das noch nicht belegt ist (da müßte man etwas suchen). Wenn dann noch die Kommandozeilen-Option zum Laden eines Projekt-Files zusammen mit dem Programmstart möglich wäre, könnte man, wie bei anderen Windows-Programmen, einfach auf ein Projektfile doppelklicken, und dein Programm würde sich öffnen mit geladenem Projekt, so wie bei Word und Co.. Das wäre doch toll. - Das Bewegen der Instrumente habe ich jetzt auch kapiert. Manche kann man in der Mitte anfassen, aber andere muß man in der schraffierten Fläche unten rechts anfassen. - Die Input-Box wird immer an die gleiche Stelle plaziert bei Aktivierung. Da würde ich im Projektfile (im Hauptspeicher) deren letzte Position speichern und bei erneuter Aktivierung diese wieder an die vorherige Position plazieren, statt an die feste Position links unten. So gibts natürlich jede Menge Kleinigleiten, was zu verbessern wäre; das oben beschriebene läuft alles unter "User Interface"; dem würde ich einiges Gewicht geben. Aber alles nur Vorschläge. Ich bringe weitere, wenn sie dich interessieren. Viele Grüße Günter
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.6c v0.6c Change Log ---------------- Neue Funktion im Terminal Fenster: "Send Predefined Commands" Hier können in einer editierbaren und sortierbaren Liste oft benutzte beliebige Kommandos incl. Kommentar eingetragen werden und gesendet werden. Es sind beliebig viele Einträge möglich. Die Syntax zur Eintragung: Kommentar | Kommando (wobei das Zeichen | die Tastatur-Eingabe AltGr < ist [asc124]). Ist unter Terminal das Häkchen bei CRLF gesetzt, so wird CR+LF beim Senden an das Kommando angehängt. Die Listeneinträge werden beim Speichern gesichert. Fehler im Terminal bei Zeilenumbruch behoben. Uploader für SerialComMeasurement muss unter Options aktiviert werden. Neue Funktion Command Line Parameters Es ist nun der Aufruf des Programms in der Form "Filename Parameter" möglich, wobei der Parameter der File-Name eines vorhandenen ini-Files (Prgm Einstellungen) ist. Beispiel für die Windows Commando Zeile: C:\SerialCommInstruments 3\SerialComInstruments.exe D:\Versuch 1.INI Die Funktionalität "Send Predefined Commands" kommt in der nächsten Version auch als eigenständiges zusätzliches Instrument. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, toll, daß du jetzt die Command Line Funktion integriert hast - herzlichen Dank! Falls du daran denkst, gelegentlich auch folgenden Vorschlag anzugehen, habe ich dazu noch eine Ergnzung: Günter R. schrieb: > - Wenn ich auf meinem XP-Rechner das Programm starte (dann ist ja > zunächst noch kein Projekt-File aktiv), dann ist das Programmfenster > überbreit. Du hast wohl einen besser aufgelösten Bildschirm als ich. Da > wäre es praktisch, wenn in einem allgemeinen Ini-File (so eines gibt es > offgensichtlich irgendwo, denn das Programm merkt sich, wo ich das > letzte Projekt-File abgelegt habe) die letzte Programmfenstergröße und > -position abgespeichert wäre, und diese sollte bei Ptrogrammstart wieder > geladen werden, dann passiert das oben beschriebene nicht mehr (bzw. nur > beim ersten Mal). An der gleichen Stelle könnte man auch den Comport und die Baudrate ablegen; also diese Daten (Programmfenstergröße + Position + Komunikationsparameter) aus dem letzten geladenen Projekt ins allgemeine Ini-File übernehmen und beim erneuten Programmstart restaurieren; falls dann noch ein Projektfile geladen wird (entweder über Command line oder später explizit), überschreiben dessen Daten halt die vom Ini-File. Günter
Hallo Albert, habe die neue Version mal gestartet (noch nicht getestet) und stelle fest, daß das Fenster jetzt kleiner ist als früher - kommt mir sehr entgegen. Herzlichen Dank! Mir ist jetzt aber aufgefallen, daß die Kommunikationsparameter (Comport + Baudrate) nirgendwo gespeichert wird, also auch nicht im Projekt. Das ist nicht so praktisch. Daher empfehle ich, dort diese Parameter aufzunehmen, aber sie darüber hinaus auch in einem allg. Ini-File zu speichern (siehe frühere Beiträge). Danke nochmals. Günter
Hallo Albert, ich teste gerade die Version 0.6C mit dem Terminal Fenster. Für vorgefertigte Kommandos ist das eine gute und flexible Möglichkeit Daten an den MC zu senden. Zwei Änderungs Wünsche: Terminalfenster auf 80 Zeichen verbreitern Schriftgröße im Terminal verkleinern (Font wählbar) Gruß biker10
Dieter H. schrieb: > Zwei Änderungs Wünsche: > Terminalfenster auf 80 Zeichen verbreitern > Schriftgröße im Terminal verkleinern (Font wählbar) Das Terminal habe ich überarbeitet: Fenster wahlweise 40 / 80 Zeichen. Schriftgröße und Font (nur für Terminal geeignete Schriften) wählbar. Echo Funktion zugefügt (in roter Schriftfarbe).
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.7 v0.7 Change Log ---------------- Neues Instrument #93: Send Predefined Commands - Es können in einer editierbaren und sortierbaren Liste oft benutzte beliebige, frei definierbare Kommandos incl. Kommentar eingetragen und über die serielle Schnittstelle gesendet werden. (LAN/UDP Übertragung folgt in der nächsten Version) - Die Syntax zur Eintragung: Kommentar | Kommando (wobei das Zeichen | die Tastatur-Eingabe AltGr < ist [asc124]. - Ist das Häkchen bei CRLF gesetzt, wird CR+LF beim Senden angehängt. - Die Listeneinträge werden beim Speichern gesichert. Terminal überarbeitet - Fenster wahlweise 40 / 80 Zeichen. - Schriftgröße und Font wählbar. - Echo Funktion zugefügt (mit roter Textfarbe im Terminal-Fenster). Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, ich habe gerade versucht, die neue Version 0.7 zu installieren, auf einem älteren WinXP-Rechner, aber sofort erschien die Meldung "Die Anwendung konnte nicht gestartet werden, weil DebugDel.DLL nicht gefunden wurde. ...". Bei vorherigen Versionen funktionierte alles. Bedeutet das, daß ab sofort WinXP nicht mehr unterstützt wird? Habe auch etwas mit dem Ini-File "SerialComInstruments.ini" experimentiert. Auf meinem XP-System (mit der Version 0.6c) wird der Pfad "C:\Users\Anwender\AppData\Local\" erstellt und das Ini-File dort angesiedelt; ist ja Win7-Philosophie, zu XP-Zeiten gabs diesen Pfad nicht, dort stehen Ini-Files u.a. unter "C:\Windows", soweit überhaupt Ini-Files verwendet werden und nicht die Registry. Aber funktioniert ja im Prinzip. Ich denke, auch Windows entscheidet irgendwie, wohin Ini-Files gespeichert werden, oder gibst du den Pfad festverdrahtet vor? Nun hatte ich das Ini-File mal probeweise gelöscht und wollte sehen, ob das Programm ein neues anlegt. Tut es aber nicht (mehr), ist irgendwie beleidigt. Egal wie und mit welcher Version (0.6b, 0.6c) gelingt es nicht mehr, ein Ini-File zu bekommen. Woran mag das liegen? An meinem antiquierten PC vielleicht?
Anbei neue Version SerialComInstruments v0.7a v0.7a Change Log ---------------- Sorry, versehentlich wurden in der Version 0.7 meine Debug Tools mit kompiliert, damit war diese Version ohne die zugehörige DLL nicht lauffähig. Der Fehler wurde behoben, Debug Tools entfernt. Günter R. schrieb: > Habe auch etwas mit dem Ini-File "SerialComInstruments.ini" > experimentiert. > > Ich denke, auch Windows entscheidet irgendwie, wohin > Ini-Files gespeichert werden, oder gibst du den Pfad festverdrahtet vor? Die ini Files werden unter dem Namen und Pfad gespeichert, der unter "Save Project as" angegeben wird. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, herzlichen Dank für die schnelle Reaktion! Betreffs des Ini-Files reden wir vielleicht von verschiedenen Dingen. In der Begleitdatei "Install Info.txt" im Install-File steht doch u.a.: "Alle relevanten Werte und Einstellungen des Programms werden bei Programmende als SerialComInstruments.ini Datei unter C:\Users\Anwender\AppData\Local gespeichert. Sollte es zu unerwarteten Effekten kommen, können Sie diese ini-Datei löschen. Das Löschen der ini-Datei empfiehlt sich eventuell auch vor dem Aufspielen neuer Programm-Versionen. Das Programm selbst darf dabei nicht geöffnet sein." Auf diese Datei "SerialComInstruments.ini" beziehe ich mich hier; das ist für mich das eigentliche Ini-File, wie es auch andere Windows-Programme beim Beenden speichern und das sicherstellt, daß sich ein neu gestartetes Programm wieder so darstellt, wie es letztens verlassen wurde, und das ohne Zutun des benutzers, insbesondere, ohne daß er "Save as" gemacht hat. Mit "Save as" hingegen werden doch Projekt-Files gespeichert (und mit "Load" geladen"); diese enthalten natürlich ebenfalls fast alle Einstellungen, die auch im "SerialComInstruments.ini" stehen (sollen), aber die Projektfiles werden ja nur auf explizites Handeln des Benutzers hin geschrieben, und an einen Ort, den er bestimmt; das ist bei normalen Ini-Files üblicherweise aber nicht so, die stehen an definiertem Ort (eben z.B. unter " C:\Users\Anwender\AppData\Local"). Und hier habe ich festgestellt (bis inkl. Version 6.c - an der neuen habe ich das noch nicht testen können), daß keine "SerialComInstruments.ini" mehr geschrieben wurde. Könntest du da bitte nochmals draufschauen? Würde das Programm eine Fehlermeldung ausgeben, wenn es ihm nicht gelänge, ein solches Ini-File zu schreiben, etwa in der Art "SerialComInstruments.ini konnte nicht geschrieben werden!"? Und nochmals die Anregung: Magst du mal darüber nachdenken, den Projektfiles eine andere Endung als "ini" zu geben? Denn Projektfiles sind m.E. keine Ini-Files, sondern eben Projekt-Files. Und damit ergäbe sich auch die Möglichkeit, duch Doppelklick darauf das Ganze zu starten, wie bei anderen Windows-Programmen wie z.B. Word und Kollegen (durch Einbau der Command-Line-Parameter hast du doch den größten Teil der Arbeit schon gemacht - fehlt nur noch ein kleines Stück, die andere Extension). Das wäre doch m.E. ein Riesenvorteil. Die Benutzer haben die Projektfiles sehr schnell umbenannt, wenn das käme. Wie gesagt: ich setze große Stücke auf dieses Projekt, will viele uC-Projekte mit dieser Visualisierung ausstatten, daher reite ich auf diesen "Komfortdingen" so rum. Und nochmals vielen Dank für diese großartige Arbeit. Günter
@ Günter R. Aus Versehen steht in der Begleitdatei "Install Info.txt" noch eine uralte Beschreibung. Diese habe ich nun upgedated. Also bleibt es bei meiner Aussage von meinem vorigen Post: Die ini-Files werden unter dem Namen und Pfad gespeichert, der unter "Save Project as" angegeben wird. Vorerst werde ich die ini-Files nicht umbenennen, dazu besteht meiner Meinung nach kein aktueller Handlungsbedarf. Da Du auf diesen Dingen (Command Line Parameter und ini Files) nun seit gefühlten 100 Beiträgen so rumreitest, drängt sich mir eher der Eindruck auf, dass Du die Software in eine professionelle Umgebung einbinden willst. Ich empfehle Dir, wenn es so sein sollte, dringend das Lesen der rechtlichen Hinweise. Ansonsten ist das ini-File Thema für mich jetzt erst mal abgeschlossen und ich werde nicht mehr weiter darauf eingehen. Es wurde schon genug dazu geschrieben.
Bin immer mehr begeistert von dem Programm. Also das Starten mit als Parameter übergebenen Projektdatei ist ein grosser Schritt in der Benutzerfreundlichkeit. Wenn jetzt noch die UDP Parameter und die aktuelle Datenquelle (Serial/UDP) und der Programmstatus (edit Mode/Run Mode) mit abgespeichert werden würden, könnte man es klasse in den Autostart einbinden.
Rainer M. schrieb: > Wenn jetzt noch die UDP Parameter und die aktuelle Datenquelle > (Serial/UDP) und der Programmstatus (edit Mode/Run Mode) mit > abgespeichert werden würden, könnte man es klasse in den Autostart > einbinden. LAN/UDP Parameter speichern ist kein Problem und Autostart damit auch nicht. Aber für die serielle Com Schnittstelle sieht das aus folgendem Grund anders aus: Ungefähr ein Drittel meiner diversen Arduino Boards und Serial/USB-Wandler initieren die Com-Schnittstelle beim Einschalten des PCs nicht immer korrekt. Da hilft dann nur USB-Kabel ziehen und wieder einstecken. Autostart würde da wenig Sinn machen, weil man sich nicht drauf verlassen könnte.
Albert M. schrieb: > Rainer M. schrieb: >> Wenn jetzt noch die UDP Parameter und die aktuelle Datenquelle >> (Serial/UDP) und der Programmstatus (edit Mode/Run Mode) mit >> abgespeichert werden würden, könnte man es klasse in den Autostart >> einbinden. > > LAN/UDP Parameter speichern ist kein Problem und Autostart damit auch > nicht. Heisst das, es ist bereits implementiert und ich finde es nur nicht oder meinst du, dias zu implementieren ist kein Problem? > > Aber für die serielle Com Schnittstelle sieht das aus folgendem Grund > anders aus: > Ungefähr ein Drittel meiner diversen Arduino Boards und > Serial/USB-Wandler initieren die Com-Schnittstelle beim Einschalten des > PCs nicht immer korrekt. Da hilft dann nur USB-Kabel ziehen und wieder > einstecken. Autostart würde da wenig Sinn machen, weil man sich nicht > drauf verlassen könnte. Bei den Arduinos geht es noch, die haben wenigstens immer den gleichen ComPort. Aber div. Serial/USB Wandler meinen, sich um den gleichen Port streiten zu müssen. Ich benutze das Programm momentann hauptsächlich mit UDP, um meinen Pool zu visualisieren.
Rainer M. schrieb: > Heisst das, es ist bereits implementiert und ich finde es nur nicht oder > meinst du, dias zu implementieren ist kein Problem? LAN/UDP Parameter mit im Projekt-File zu speichern ist kein Problem :) Habe ich schon für die nächste oder übernächste Version vorgemerkt.
Angehängte Dateien:
-
Bild2.PNG
10 KB
Hallo Albert, das Terminal in der Version V07.a ist mit der Font Auswahl und der Fensterbreite mit 80 Stellen gut gelungen. Anmerkung 1 dazu: könnte auf die Auswahl 40 oder 80 Stellen Fensterbreite nicht ganz verzichtet werden und das Fenster ist immer 80 Stellen breit. Anmerkung 2: Die Eingabe im Send Fenster (siehe Bild2) wird nach jedem Sende Vorgang gelöscht. In der Testphase ist das aber eher hinderlich. Ist es möglich den Sende Parameter stehen zu lassen? Gruß biker10
Dieter H. schrieb: > könnte auf die Auswahl 40 oder 80 Stellen Fensterbreite nicht ganz > verzichtet werden und das Fenster ist immer 80 Stellen breit. Wenn viele Daten ohne CR/LF kommen, wird es bei Zeilenumbruch erst nach 80 Zeichen schnell schwierig zu lesen. Ich belasse es zumindest vorerst mal bei wahlweise Zeilenumbruch nach 40 oder 80 Zeichen. Dieter H. schrieb: > Die Eingabe im Send Fenster (siehe Bild2) wird nach jedem Sende > Vorgang gelöscht. > In der Testphase ist das aber eher hinderlich. > Ist es möglich den Sende Parameter stehen zu lassen? Werde ich für die nächste Version vormerken. Eventuel wahlweise unter "Optionen" einstellbar.
Hallo Albert, ich bins nochmal. Deine rechtlichen Hinweise halte ich zu 100% ein. Ich gebe Dir mein Ehrenwort, daß ich noch nie daran dachte und auch nicht daran denken werde, Dein Programm in irgendeiner professionellen Umgebung einzubinden (eine solche habe ich garnicht). Ich denke ausschließlich an eine hobbymäßige Verwendung, aktuell z.B. bei meiner Heizungssteuerung (Temperatur-Logging der Solaranlage und Boilerladung), oder bei anderen Steuerungsprojekten rings in und um mein Haus. Da ich mich schon lange hobbymäßig mit uC-Projekten befasse (meistens, aber nicht nur, AVR's), ist schon viel zusammen gekommen; vieles enthält ein LCD-Display, aber fast alles enthält auch eine RS232. Da ist es naheliegend, deren Software so zu erweitern, daß Dein Datenprotokoll eingebaut wird und eine Visualisierung möglich wird, von der ich vor 2 Wochen noch nicht mal träumen konnte. Daher meine Freude, Begeisterung und mein Engagement. Ich wollte lediglich mithelfen, das Programm zu verbessern, und mehr als Anregungen aus meinem Erfahrungsschatz zu geben, ist ja nicht möglich. Da ich auch mit Delphi arbeite, bin ich mit den Themen, die ich ansprach, sehr gut vertraut. Diese wollte ich in die Waagschale werfen. Aber dazu jetzt kein Wort mehr, versprochen. Ich werde also das Projekt weiterhin beobachten und freue mich auf gelegentlich neue Versionen. Nochmals Danke für Deine Arbeit! Gruß, Günter Nebenbei: Es waren bisher insgesamt 7 Postings von mir (das hier ist das 8., wenn ich richtig gezählt habe).
Günter R. schrieb: > Ich wollte lediglich mithelfen, das Programm zu verbessern Hallo Günter, danke für Deine Hinweise zum Programm, die sind natürlich auch weiterhin, ebenso wie Fragen, willkommen. Normalerweise reicht aber ein einmaliger Hinweis zu einer Funktion. Du kannst davon ausgehen, dass ich mir alle Anregungen notiere und wenn notwendig auch hier diskutiere. Wann, ob und in welcher Reihenfolge die dann umgesetzt werden, hängt vom Wetter, meiner Laune und Motivation ab :) Wundere Dich also nicht, wenn auch mal wochenlang Funkstille ist, wie bei Hobby-Projekten üblich.
:
Bearbeitet durch User
Hallo, bin heute auf dieses Projekt gestoßen und muss erst mal ein großes Lob los werden. Habe schnell mal einen einfachen Versuch gestartet, aber leider klappt der nicht. Als Instrument habe ich das Vert.Meter #02 aktiviert. Im "Terminal" Fenster kommen meine seriellen Daten so an, wie ich es programmiert habe. z.B. #02M35> Das Instrument reagiert aber leider nicht. Habe leider Tomaten auf den Augen, ich finde den Fehler nicht. Sorry. Bin für jeden Tip dankbar
Climber schrieb: > Im "Terminal" Fenster kommen meine seriellen Daten so an, wie ich es > programmiert habe. > z.B. #02M35> > > Das Instrument reagiert aber leider nicht. > Habe leider Tomaten auf den Augen, ich finde den Fehler nicht. dreh mal das ">" rum: "<" :)
Ups, das gibts doch nicht. grrrrrhh. Tausend mal geschaut und tausend mal nichts aufgefallen. Jetzt gehts, wie so oft lag das Problem vor dem Bildschirm. Vielen Dank nochmal.
Hallo Albert, ich habe eine kleine Proxxon-Fräse umgebaut um ein bisserl mit CNC-Maschinen zu üben. Der Umbau ist dort http://www.herberts-n-projekt.de/basteleien-1/cnc-umbau-proxxon-mf70/ beschrieben. Im Arduino werkelt die grbl v0.9 aktuellste Version. Beim Einsatz von serialcomcnc (aktuellste Version) kommt über USB (als Com6) eine Verbindung zum Arduino zustande, jedoch flattern dann die TX/RX-LEDs auf dem Arduino nur noch und nach ca. 30-60 Sekunden kommt der Abbruch wegen schweren Kommunikationsfehlern. Wenn ich den Universal-G-Code-Sender https://github.com/winder/Universal-G-Code-Sender einsetze, kann ich die Maschine steuern. Die Einstellungen für den Port Com6 sind identisch. Es gibt keine Kommunikationsabbrüche. Ich kann auch mit dem eingebauten Kommunikationsinterface ähnlich einem Telnet-Cleint mit dem Arduino kommunizieren. Gibt es bei seriacomcnc unter Win10 etwas besonderes zu beachten? Danke für Info Gruss Thomas
Sorry, habe das falsche Forum erwischt. Frage gehört zu Beitrag "Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
Hallo Albert, jetzt bin ich auch so weit UDP nutzen zu können. Funktioniert einwandfrei. Nochmals Danke für das Programm, und Frohe Weihnachten wünscht sand
Ich habe jetzt mal wieder etwas weiter gemacht bei meiner Schwimmbad Steuerung und Visualisierung mit SerialcomInstruments . Ich will das ja letztendlich auf einem Tablett darsrellen. Das kommt der Sache schon recht nahe: https://youtu.be/KUn4ay-QjOM
Hallo Rainer, das ist sehr interessant, was du da machst. Wie bringst du denn das Programm auf ein Tablet? Was für ein Tablet ist das denn? Ein Windows-Tablet? Und wie kommen die Daten dorthin? Übers Netzwerk (WLAN)? Günter
Ist ein Ipad und mit Wlan angebunden. Ohne Tricks geht es aber nicht. Man kann per Touch sogar die Slider bewegen und Tasten drücken. Ich habe auf einem Windowsserver, der 24/7 läuft, eine VM laufen, die SerialcomInstruments im Vollbilddarstellung zeigt. Dann verbinde ich mich mit dem Ipad per RDP Programm auf die virtuelle Maschine und vergrössere die Darstellung gerade soweit, dass man die Windows Titelzeile und das Menü nicht mehr sieht. Das wars dann schon. Wichtig ist halt, dass es im Wohnzimmer wichtig aussieht ;)
:
Bearbeitet durch User
Angehängte Dateien:
-
Solarlog.PNG
37 KB
Ich hatte mir für meine kleine Solaranlage einen Logger mit FRAM gebaut (eigentlich nur, um nachträglich die täglichen Daten sehen zu können). Mich dann an das Programm erinnert und die Sachen mit ausgegeben. Schön wäre es, wenn Schnittstelle und Schnittstellenparameter mit im ini-file gespeichert wären. Oder bei den seriellen Ports zumindest nur die zur Auswahl gestellt werden, die auch tatsächlich im System vorhanden sind, muss immer erst scrollen, um an meinen COM1 zu kommen. Der default-Wert von 50 für die Digitalanzeigen macht für mich auch keinen Sinn - kann man das irgendwo ändern? Letztes Manko: Leerzeichen in der Beschriftung werden gnadenlos geschluckt (beim Estellen klappt das noch mit dann gleicher Instrumentenbreite), lädt man es wieder sind die Breiten alle verschieden.
Hoffentlich nur vorübergehend. Albert ist derjenige der wirklich brauchbare Programme hier zur Verfügung gestellt hat. Nochmals Dank und Lob dafür. sand
Ja leider! Hab ihn vor n paar Wochen mal angemailt und nach den Bedingungen für einen Einsatz in der Firma gefragt, aber leider bis heute keine Antwort. Hans
XCP fällt mir dazu ein, das ist ein simples Memory-Mapping. Da kann man dann dem µC ne Nachricht schicken mit "Gib mir mal Wert an Speicherstelle 0xFFAB" und der schickt dann über UART genau den Wert zu. Menschenlesbare Form wird über A2L Textdokumente hergestellt. Auf diese Art und Weise werden im Automobilbau die Parameter am Motorenprüfstand abgefragt und eingegeben.
Hallo Albert, Instrument #93 unter UDP ohne Funktion. Meldung: Die Schnittstelle ist nicht aktiviert. Ist es so gewollt?
Sascha schrieb: > XCP fällt mir dazu ein, das ist ein simples Memory-Mapping. > Da kann man dann dem µC ne Nachricht schicken mit "Gib mir mal Wert an > Speicherstelle 0xFFAB" und der schickt dann über UART genau den Wert zu. > Menschenlesbare Form wird über A2L Textdokumente hergestellt. > Auf diese Art und Weise werden im Automobilbau die Parameter am > Motorenprüfstand abgefragt und eingegeben. Kannst Du einfach mit Instrument #93 (Send Predefined Cmds) realisieren: Senden mit Instrument #93 oder InputBox #99. Empfangen mit Instrument #35, 36 oder #38. sand schrieb: > Instrument #93 unter UDP ohne Funktion. > Meldung: Die Schnittstelle ist nicht aktiviert. > Ist es so gewollt? Habe ich übersehen. Wird in der nächsten Version korrigiert.
:
Bearbeitet durch User
Hallo Albert, Instrument #87 Trigger kann man nicht abspeichern. Gruß sand
Anbei neue Version SerialComInstruments v0.8 v0.8 Change Log ---------------- 2 weitere Analog-Instrumente #07 und #08 zugefügt. - Damit gibt es jetzt insgesamt 8 Analog-Displays Instrument #87: Trigger Instrument - Es werden jetzt alle Parameter gespeichert Instrument #93: Send Predefined Commands - Funktioniert nun mit UDP und Seriell - CheckBox CRLF wird mit gespeichert Terminal - "Send Predefined Commands" nur für Com aktiviert. UDP ist hier nicht möglich. - Der gespeicherte Command-Set ist unabhängig vom Instrument#93. Numerische Displays #41 bis #44 - Default Wert für numerische Displays jetzt 0 Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, danke für die Version für die Community.
Hallo Albert, besten Dank für v0.8 aber v0.8 im Gegensatz zu v.0.7a lässt keine funktionsfähige Installation zu. Meldung: keine Rückmeldung Win7 Ult._32 Gruß sand
Hallo Albert, auch von mir ein herzliches Dankeschön für die neue Version und insbesondere dafür, daß Du an dem Projekt weiterarbeitest. Bei mir funktioniert die V. 08 (unter WinXP). Im Options-Fenster fiel mir heute erstmals die Checkbox für "SerialComMeasurement Uploader" auf und das rechte Fenster dazu im Terminal, wenn der Haken gesetzt ist. Weiß nicht, ob das früher auch schon da war. Was kann man damit denn machen? Wohin wird etwas "upgeloaded"? Wenn man "Save File" macht, wird eine *.SCM-Datei mit dem Fensterinhalt erstellt. Auf Deiner Webseite steht auch ein Hinweis auf "SerialComMeasurement", aber sonst keine Details. Beim Testen der Dreh- und Schiebe-Slider (#80/81 und #82/83) fiel mir auf, daß diese zwar durch Anpacken mit der Maus sehr gut einstellbar sind, aber die im Handbuch erwähnte Feineinstellmöglichkeit durch Drücken und Festhalten der linken Maustaste und Drehen am Mausrad funktioniert nicht immer und wenn, dann nur für einige Umdrehungen, dann bewegt sich nichts mehr. Mag das an meinem WinXP liegen? Rechtsklick mit der Maus auf beispielsweise die Instrumente #80, #81, #01 aktiviert das Instruments-Fenster (aber erst beim Loslassen der Maustaste, nicht schon beim Drücken), aber dies geschieht nicht beispielsweise bei Instrument #82 (dort wird nur der Schiebeknopf rot, sonst passiert nichts). Ist das so gewollt? Gruß, Günter
Günter R. schrieb: > Im Options-Fenster fiel mir heute erstmals die Checkbox für > "SerialComMeasurement Uploader" auf und das rechte Fenster dazu im > Terminal, wenn der Haken gesetzt ist. Weiß nicht, ob das früher auch > schon da war. Die Option bezieht sich auf das Projekt SerialComMeasurement: Beitrag "Projekt: SerialComMeasurement" und: http://www.serialcominstruments.com/measurement.php Nachdem ich im obigen Thread angefeindet wurde, habe ich zum Thread nichts weiter beigetragen und das Projekt für mich und einige enge Bekannte nicht öffentlich erfolgreich zu Ende geführt. Sorry, daher kannst Du mit dieser Option nichts anfangen. Günter R. schrieb: > Beim Testen der Dreh- und Schiebe-Slider ... Die meisten Instrumente sind zugekaufte Delphi Komponenten an denen ich nichts am Mouse-Verhalten ändern kann. Ich sehe mir die angeführten Punkte aber noch mal an. sand schrieb: > aber v0.8 im Gegensatz zu v.0.7a lässt keine funktionsfähige > Installation zu. > Meldung: keine Rückmeldung > Win7 Ult._32 Die Software wird unter Windows 7 Professional 32 bit entwickelt, daher müsste sie auf Deinem System eigentlich laufen. Möglichst nicht im Programm-Ordner installieren, um irgendwelche Rechtekonflikte zu vermeiden.
:
Bearbeitet durch User
Ohne drängeln zu wollen: gibts irgendeinen Grund, die Anschlusseinstellungen nicht mit im jeweiligen ini-file zu speichern?
H.Joachim S. schrieb: > Ohne drängeln zu wollen: gibts irgendeinen Grund, die > Anschlusseinstellungen nicht mit im jeweiligen ini-file zu speichern? Bei meinem Projekt SerialComCNC gab es Probleme bei der automatischen Erkennung der aktiven Serial-Ports unter bestimmten Win10 Versionen. Daher habe ich da alternativ eine Port-Liste wie bei SerialComInstruments eingeführt. Damit gibt es keine Win10 Probleme. Ich wollte etwas Zeit vergehen lassen um weitere Reaktionen auf die Win10 Problematik ab zu warten. In der nächsten oder übernächsten SerialComInstruments Version wird es vieleicht eine Erkennung der aktiven Ports und alternativ dazu die Port-Liste geben. Ausserdem die Speicherung der aktuellen Com- und UDP-Port Parameter zum jeweiligen Projekt.
:
Bearbeitet durch User
Hallo Albert, was ich bis jetzt festgestellt habe, im UDP Modus keine Funktion von Nr.#56 Paint und Fehlermeldung kommt bei der Betätigung des Mausklaviers Nr.#75 Senden fehlgeschlagen. Funktion ist aber da. Gruß sand
Von mir aus können auch gerne alle möglichen Ports in der Liste bleiben, das stört mich weniger. In meinem Fall hängt der Logger z.B. immer an COM1. Idealfall für mich wäre: -Programm starten -Load Projekt (z.B. Solarlog.ini) Und im ini-file steht dann auch: -benutze COM1 (oder welchen auch immer) -baudrate 57600 (oder eben irgendeine andere) -connect (ok, darüber kann man reden, ob es sinnvoll ist) D.h. mit load project ist alles erledigt, direkt online.
Dieser Meinung von Joachim möchte ich mich anschließen. Auch ich benutze i.d.R. COM1 (oder auch mal COM2) und eine feste Baudrate, und die Idee, SerComInstruments nach Programmstart ggf. sofort loslegen zu lassen, finde ich auch sehr gut; gepaart mit einem Projektfile als Kommandozeilenparameter (Feature ist ja schon realisiert) könnte die Anwendung dann durch Doppelklick auf ein Desktop-Icon, das man anlegen könnte, sofort gestartet werden. Dazu könnte man im Interface-Fenster (dieses verstehe ich auch als Einstellungen-Menü) einen zusätzlichen Haken einbauen, mit dem man bestimmen kann, ob nach Programmstart ggf. sofort Connect gemacht wird (und das auch im Projektfile speichern). Gruß, Günter
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.8a v0.8a Change Log ---------------- Com Interface Parameter - Com Port und Baudrate werden zum Projekt gespeichert. - Ist die CheckBox "Auto Connect" im Interface Fenster markiert, wird beim Laden des Projektes automatisch die Com Schnittstelle aktiviert. Gruss Ulrich Albert http://www.serialcominstruments.com/
Klasse, werde ich morgen testen. Aber ich denke das funktioniert. Noch was für den Hinterkopf, eilt auch überhaupt nicht - wie wärs mit was Akustischem? Schon ein kleines Beep a la 0x07/BEL fände ich nützlich.
Super, funktioniert. Gerade in Verbindung mit der Kommandozeilenoption - ein Doppelklick und das Ding läuft. Komfortabler geht es nicht.
Hallo Albert, V08.a unter UDP Nr.87 Trigger kann man testen, aber der Schalter für Kontinuität ohne Funktion. CheckBox "Auto Connect" für UDP wäre auch genial :-) Danke und Gruß sand
Hallo Albert, perfekt! Funktioniert super. Herzlichen Dank. Was akustische Signale angeht: da sollte man zurückhaltend sein. Mich nervt solches Gepiepse tierisch. Akustische Signale werden von mir bei einer Windows-Neuinstallation immer als allererstes abgestellt. Wenn sie kämen, dann bitte mit einem Haken abschaltbar. Ich bräuchte sie nicht. Günter
Was heisst denn mit Häkchen abstellbar? Da könnte es ein Instrument "Beeper" geben, baut man dazu oder nicht. Natürlich sollte nicht alle naselang was rumtönen. Nützlich für besondere Ereignisse, Alarme etc. wo man dann vielleicht mal direkt einen Blick drauf werfen sollte.
Oder Akustische Signale evt. als neues Instrument. Könnte vielleicht doch nützlich sein, um Aufmerksamkeit zu holen (da habe ich vielleicht vorschnell gegen diese Idee opponiert - sorry).
Hallo Joachim, warst schneller. Ja, du hast recht, das könnte sinnvoll sein.
H.Joachim S. schrieb: > Da könnte es ein Instrument "Beeper" geben, baut man dazu oder nicht. > Natürlich sollte nicht alle naselang was rumtönen. > Nützlich für besondere Ereignisse, Alarme etc. wo man dann vielleicht > mal direkt einen Blick drauf werfen sollte. Etwa so: Instrument zum Abspielen von wav-Files über die Soundkarte. - bis zu 99 verschiedene wav-Files - Kommando dafür: #89Mwpxx< wobei 89 : Instrument-Nummer w : Wiederholrate 1=einmalig 2=kontinuierlich bis manuell deaktiviert 0=deaktivieren des Modus 2, also Ton aus p : Pause 0 bis 9s, aktiv wenn w=2 xx : wav-File Nummer 01 bis 99 Wav-File kann sich ja jeder einfach selbst mit seinem Headset-Mikro oder aus dem unerschöpflichen Web Fundus selbst erstellen. Was passieren soll wenn z.B. mehrere Waves auf einmal ausgelöst werden weiss ich noch nicht. Event. Warteschlange/Fifo oder sowas. Dafür müsste man das Ende des jeweils vorigen Waves erkennen. Mal sehen.
:
Bearbeitet durch User
Das wäre ja schon wieder die allumfassende Lösung - ist die Frage wieviel Arbeit das für dich macht? Mir würde auch das VisualBasic beep völlig genügen.
Das Projekt wird ja doch langsam zum Wunschkonzert, im wahrsten Sinn des Wortes ;-)
Hallo Albert, V08.a Mehrmalige Installationsversuch jetzt auf einem Laptop (Lenovo/Vista) auch fehlgeschlagen. Meldung: Anwendungsfehler/ Exception EOutOf Memory in Modul SerialComInstruments.exe bei 0F6DF340 Das Programm kann man nur durch Process beenden schließen. V0.7a lässt sich ohne Probleme installieren. Gruss sand
sand schrieb: > Mehrmalige Installationsversuch jetzt auf einem Laptop (Lenovo/Vista) > auch fehlgeschlagen. Ich kann dein Problem leider nicht nachvollziehen, was zur Fehlerbehebung unabdingbar ist. Jedes Release wird bei mir immer auf 3 verschiedenen PCs mit unterschiedlichen Windows Versionen (XP und Win7) getestet.
Hallo Albert, interessant ist dabei, auf dem W7 Desktop Rechner kann ich neues Projekt erstellen, es funktioniert, aber beim abspeichern Absturz. Ebenso beim Projekt laden und bei diverse Hilfe Sachen. Gruss Sand
Leider ist auch bei mir keine Installation der Version 0.8a möglich. Sowol auf meinem Laptop als auch auf dem Desktop. Nicht mal das Setup läßt sich mit dem Taskmanager beenden. Auf beiden Rechnern läuft Windows7. Ansonsten Großen DANK für das tolle Programm!!!!
Die beigefügte Version ist für alle bei denen die Installation oder Ausführung der Version 0.8a Probleme macht. Ich konnte auch nach Installation auf nunmehr 7 verschiedenen PCs keine Fehlfunktion provozieren. Änderungen in der Installation sind daher von mir nur als Test zu verstehen. Beigefügt ist ausserdem ein hash-File zur Checksum Überprüfung des Installationsfiles "Setup SerialComInstruments.exe" um sicher zu stellen, dass das Laden von Mikrocontroller.net die Datei nicht korrumpiert hat. Die dazu passende Checksum Software könnt ihr euch unter dem beigeführten Link bei CHIP runter laden. Nach Installation der Checksum Software einfach das hash-File doppelklicken.
:
Bearbeitet durch User
Danke Albert, es funktioniert! Gruss sand
Erste Testergebnisse: nur auf UDP bezogen! Nr.75 beim Senden mit > Meldung: Warnung #75 Senden fehlgeschlagen, Funktion ist aber vorhanden Nr.56 Ohne Funktion Nr.87 Schalter ohne Funktion Test funktioniert zuerst, dann ohne Funktion
Angehängte Dateien:
Anbei neue Version SerialComInstruments v0.8b
v0.8b Change Log
----------------
Wav Player Instrument #89 (invisible)
- zum mc-gesteuerten Abspielen von wav-Files über die Soundkarte.
- bis zu 100 verschiedene wav-Files
- Kommando: #89Mxx<
wobei xx : wav-File Nummer 00 bis 99
Beispiel File: 03.wav
mit #89M03< wird dann das wav-File im PC gestartet.
- Wav-File kann man einfach z.B. mit seinem Headset-Mikro
und Audacity selbst erstellen oder aus dem Web kopieren.
- Die wav-Files müssen im Installations-Ordner im
Unterverzeichnis wav gespeichert sein.
- Es gibt einige Beispiel wav-Files im wav-Ordner.
UDP Interface Parameter
- Alle UDP Parameter werden zum Projekt gespeichert.
- Ist die CheckBox "Auto Connect" im UDP Interface Fenster markiert,
wird beim Laden des Projektes automatisch die LAN Schnittstelle
aktiviert (siehe Bild oben).
Paint Instrument #56
- Nun auch mit UDP funktionsfähig
Trigger Instrument #87
- Fehler behoben. UDP fähig.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Guten Abend Albert, perfekte Arbeit. Hochachtung als Lob von mir. Gruss sand PS. Die Warnmeldung bei der Betätigung ">" Nr.75 ist noch da. Nur als Schönheitsfehler.
Momentan teste ich die Implementation eines integrierten mathematischen Expression Parser. Der Anwender kann hier beliebig komplexe Formeln eingeben. Damit können auf einen oder zwischen mehreren Kanälen realtime Berechnungen mit Ausgabe auf einen Ergebnis-Kanal durchgeführt werden. Der Parser arbeitet nicht wie üblich als Interpreter, sondern die Formel wird sofort nach Eingabe autom. kompiliert und das Compilat von SerialComInstruments verwendet. Es zeigte sich, dass auch bei ziemlich komplexen Formeln ein Durchsatz von mehr als 200.000 pro Sekunde erreicht wird. Damit wird also die Arbeitsgeschwindigkeit von SerialComInstruments nicht beeinträchtigt. Das Compilat kann zur Wiederverwendung gespeichert werden. Als Mathematik steht zur Verfügung: +, -, *, /, SQR, SIN, COS, SINH, COSH, TAN, ATAN, COTAN, EXP, LN, LOG, SQRT, ABS, SIGN, TRUNC, CEIL, FLOOR, RND, RANDOM, INTPOW, POW, LOGN, MIN, MAX, IF, sowie beliebig tiefe Klammerebenen. Es lassen sich anwenderspezifische Variablen definieren. Da die vollständige Implementation in SerialComInstruments relativ aufwändig ist, lohnt es sich nur bei genügend Interesse.
:
Bearbeitet durch User
Meine Interesse ist geweckt.
Frage: 1. Der Ergebnis-Kanal wird TX-fähig gestaltet?
2. Anzahl der Variablen?
Gruss
sand
Klingt gut, aber mir fällt im Moment nichts ein, wofür ich das brauchen könnte. Sprich - für mich ist das ganze eine komfortable Visualisierung sowohl in der Entwicklungs- als auch Anwendungsphase. Wofür nachträgliche Berechnungen aus Teilergebnissen? Entweder brauche ich die Ergebnisse in meinem System, dann muss sie eh der MC berechnen (wo nach Tx-Kanal gefragt wird: einen Teil auslagern und das ganze ist nur mit PC lauffähig??) oder ich brauch sie nicht, dann muss sie auch der PC nicht berechnen.
Heute fiel mir folgendes auf: Bei "Predefined Commands" #93 werden ja die Commands in einem separaten Text-File mit der Endung "*.tx1" und dem Dateinamen gleich Projektnamen abgelegt. Startet man SerComInst ganz normal und lädt dann im Programm das Projektfile mit "Load", so ist alles okay und die Predefined Commands sind da. Startet man jedoch SerComInst mit dem Projektfile als Kommandozeilenparameter, so fehlen danach die Predefined Commands; man kann sie herholen, indem man nochmals "Load" mit dem gleichen Projektfile macht. Ich gehe mal davon aus, daß bei "Load" innerhalb des Programms die "*.tx1"-Datei mit geladen wird, daß diese aber außen vor gelassen wird beim Laden des Projekts über den Kommandozeilenarameter. Entsprechendes gilt für die Predefines Commands innerhalb des Terminal-Fensters; diese werden in "*.tx2" abgelegt; da ist es auch so. Gruß, Günter
Das neue Wav-Instrument #89 ist übrigens ganz klasse, funktioniert perfekt.
Zum Expression Parser: Verstehe ich dessen Funktion richtig so, daß man eine Formel eingeben kann, die z.B. zwei Variablen enthält, und man sendet dann vom uC her die Inhalte (= Werte) der Variablen als neue Instrumenten-Werte, und dann wird die Formel berechnet und das Ergebnis wird über ein wählbares Instrument angezeigt? Wenn es nur eine Variable gibt, kann ja gleich berechnet und angezeigt werden; wenn es jedoch mehrere Variablen sind, muß man ja erstmal alle Werte senden, bevor ausgewertet werden sollte, und dann erst wird angezeigt. Wie mag das gesteuert werden? Durch eine Art "Exec"-Befehl? Insgesamt schon ein interessantes Feature. Damit könnte in meiner Heizungsanwendung möglicherweise ein Mittelwert zw. mehreren Temperaturquellen ermittelt und angezeigt werden, oder der Maximalwert von mehreren Werten? Somit also Auswertung der Daten mehr im Visualisierungsprogramm als im uC?
Schaut euch mal mein (Konkurrenz-) Projekt an: www.mikrocontroller.net/topic/388750 Eingänge können dort als Formeln angegeben werden mit freier Zuordnung der Eingangskanäle. "Instrumente" können in beliebiger Anzahl plaziert werden. Es ist der gleichzeitige Betrieb mehrerer Schnittstellen (COM und UDP) möglich. Grüße
Anbei neue Version SerialComInstruments v0.8c v0.8c Change Log ---------------- Predefined Commands - Ladefehler bei Start des Programms über die Kommando-Zeile behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Irgendwie mögen meine Windows7 32 Bitversionen die Installationsdatei nicht - Einziger Lichtblick -> mit Windows10 64 Bitt klappts!
Est Est E. schrieb: > Schaut euch mal mein (Konkurrenz-) Projekt an Ich nehme das jetzt mal sportlich. Innerhalb von 8 Stunden habe ich bereits die selbe Funktionalität wie in Deinem Programm komplett neu als Machbarkeitsstudie entwickelt. Es wird also ein vollkommen neues SerialComInstruments Version 4 geben. Alle Vorteile der wesentlich ausgereifteren Instrumente von SerialComInstruments und aller sonstiger Features bleiben erhalten: - Vollkommen neu entwickelte professionelle Oberfläche - Beliebig viele Instrumente, erweiterte komfortable Plazierungseigenschaften - Mehrere COM und UDP Schnittstellen - Die Eingangskanäle können auf beliebige Instrumente gemappt werden - Umfangreiche anwenderdefinierbare Mathematik mit beliebigen verschachtelten Klammerebenen - Weitere neue Features wie: - Optionale Verlagerung von Mikrocontroller Logic/Funktionalität ins Programm - Erstellen von interaktiven Prozess-Schaubildern - Ortskurven-Darstellung und vieles mehr Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Konkurrenz belebt das Geschäft ;-) Das kann man hier ganz gut sehen. Wenn ich im Moment mehr Zeit hätte, würde ich auch mitmachen. Es fehlt noch eine Platform übergreifende Version, die auch auf Linux läuft. Java wäre geeignet ... Aber im Gegensatz zu Delphi, Lazarus oder Python scheitert es dort schon an der Anbindung der seriellen Schnittstelle: Beitrag "Re: Java serielle Schnittstelle mit JSSC"
chris_ schrieb: > würde ich auch mitmachen. Es fehlt noch eine Platform übergreifende > Version, die auch auf Linux läuft. Was spricht gegen FPC/Lazarus?
Johannes S. schrieb: > Was spricht gegen FPC/Lazarus? Generell nichts. Allerdings stösst das Fehlen von professionellen Instrumenten aber bitter auf. Das sieht man den in Lazarus selbst erstellten Instrumenten dann auch an. Oder wenn man z.B. in ComVisu(siehe Thread von Est Est Est) mehrmals mit der rechten Mousetaste die Grafik verschiebt ergeben sich stets krumme Skalierungswerte. Und das ist nicht mal so eben korrigiert. Um kurz das Gegenbeispiel zu sehen, lade Dir mal mein SerialComGrapher runter und verschiebe oder zoome da mal die Grafik. Dann weisst Du was ich meine. Wenn man solche gekauften Instrumente Komponenten wie ich sie verwende in Lazarus selbst programmiert, würde die Entwicklung kein Ende nehmen. Daher bleibe ich bei Delphi :)
:
Bearbeitet durch User
Die Pan/Zoom Möglichkeiten in Deinem "First Impression Time Diagramm" zum SerialComInstruments4 sind natürlich allererste Sahne und purer Luxus ;-) Von einer gezielten Sprungmöglichkeit auf der Zeitachse abgesehen bleibt da glaub ich kein Wunsch mehr offen... Wie wird es denn mit der Kompatibilität zu den alten Instrumentencodes ausschauen?
:
Bearbeitet durch User
Darf die Hoffnung bestehen bleiben, dass du auch die Freunde der anderen seriellen Datenübertragung - der zu GRBL - weiterhin mit interessanten neuen Features beglücken wirst, lieber Ullrich ? Vielen Dank von einem sehr zufriedenen Nutzer dafür.
:
Bearbeitet durch User
Hardy F. schrieb: > Darf die Hoffnung bestehen bleiben, dass du auch die Freunde der anderen > seriellen Datenübertragung - der zu GRBL - weiterhin mit interessanten > neuen Features beglücken wirst Ja - als nächstes werden in SerialComCNC die EasyJob Funktionen zu Ende entwickelt und freigegeben.
Klasse, das ist wohl das worauf alle schon sehnsüchtig warten... Viel Erfolg beim programmieren.
Angehängte Dateien:
Anbei Demo-Programm des Realtime Formel Parsers für SerialComInstruments 4. Der Anwender kann hier beliebig komplexe Formeln eingeben. Die eingegebene Formel wird sofort nach Eingabe autom. kompiliert. Die Formel kann auch während der laufenden Anzeige geändert werden. Als Mathematik steht zur Verfügung: +, -, *, /, SQR, SIN, COS, SINH, COSH, TAN, ATAN, COTAN, EXP, LN, LOG, SQRT, ABS, SIGN, TRUNC, CEIL, FLOOR, RND, RANDOM, INTPOW, POW, LOGN, MIN, MAX, IF, sowie beliebig tiefe Klammerebenen. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Perfekt! Sehnsucht auf Endergebnis steigt und steigt und....steigt. Gruss sand
sand schrieb: > Perfekt! wäre es wenn die Moby A. schrieb: > Kompatibilität zu den alten Instrumentencodes gegeben ist. Und noch eine zweite Frage: Gibt es irgendwelche "Laufzeitbeschränkungen" für dieses Programm? Wird es solche geben? Das wurde soeben im "Konkurrenz"-Thread vermutet... ;-(
Moby A. schrieb: > Wie wird es denn mit der Kompatibilität zu den alten Instrumentencodes > ausschauen? Soweit dies möglich ist. Da die Zuordnung der Daten zu den Instrumenten beliebig ist, schickt man seine Daten nun nicht mehr mit einer Instrumenten-Nummer, sonder als Kanalnummer: #cccXm< wobei ccc=Kanalnummer, X=OperationsIdentifier, m=Messwert Ob für X der bisherige M-Messwertidentifier erhalten bleibt, wird man sehen. Die Kanalnummer kann im Programm-Setup einem beliebigen (zu den Daten passenden) Instrument zugeordnet werden. Moby A. schrieb: > Gibt es irgendwelche > "Laufzeitbeschränkungen" für dieses Programm? Wird es solche geben? Das > wurde soeben im "Konkurrenz"-Thread vermutet... ;-( Ja, wie zur Zeit auch. Daran wird sich auch zuerst mal nichts ändern. Die zeitliche Begrenzung der aktuellen Version beträgt, wie auch für weitere Versionen, jeweils 1 Jahr vom Veröffentlichsdatum. Wenn Du immer eine einigermassen aktuelle Version benutzt dürfte das kein Problem sein. Falls ich das Projekt mal beende, werde ich als letzte Version das Zeitlimit aufheben. Siehe dazu auch ab diesem Beitrag: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
:
Bearbeitet durch User
Albert M. schrieb: > Ja, wie zur Zeit auch. Daran wird sich auch zuerst mal nichts ändern. > Die zeitliche Begrenzung der aktuellen Version beträgt, wie auch für > weitere Versionen, jeweils 1 Jahr vom Veröffentlichsdatum. Wenn Du immer > eine einigermassen aktuelle Version benutzt dürfte das kein Problem > sein. Falls ich das Projekt mal beende, werde ich als letzte Version das > Zeitlimit aufheben. Gott gebe dir immer Gesundheit und Wohlergehen, damit dir niemals im Leben was passiert ! So wird dich deine hervorragende Software ein Jahr überleben.
Albert M. schrieb: > Daran wird sich auch zuerst mal nichts ändern. Ein offenes Wort: Ich finde es ausgesprochen schade, daß Deine ausgeprägte Liebe zu vielfältigen Beschränkungen wohl auch mit einer neuen SerialComInstruments Version kein Ende findet. Die kann jetzt funktionell bieten was sie will, so gut kann sie gar nicht werden daß diese Form der Gängelung für mich kein absolutes No-Go wäre. Echt schade. Du entwertest mit diesen Bestrebungen ein ganzes Stück weit Deine eigenen erbrachten Programmierleistungen. Denke bei Deiner nächsten Beschwerde über mangelndes Interesse und Würdigung auch daran. Versetze Dich in die Lage des Anwenders: Der muß in die proprietäre MC Ansteuerung eines solchen Programms auch einiges investieren und möchte diese Arbeit durch nichts in Frage gestellt sehen. Kostenlos hin oder her. Aber vielleicht überlegst Du Dir das noch anders. Anregen möchte ich an dieser Stelle -nochmal- eine unbeschränkte Kaufversion. Da bin ich der erste Besteller. Versprochen. So werde ich weiter auf die unbeschränkte Laufzeit meiner gegenwärtig eingesetzten 0.48c hoffen- und an Alternativen werkeln.
:
Bearbeitet durch User
Mir war diese zeitliche Beschränkung nicht bewußt. Wo stand denn etwas darüber? Okay, bin erst im letzten Spätjahr auf dieses Projekt aufmerksam geworden. Seit den letzten Updates (Kommandozeilenparameter und Speicherung der Kommunikationsparameter im Projektfile) ist das Programm richtig klasse, aber diese Beschränkung relativiert dies um einiges, wie Moby richtig schreibt. Ein Jahr ist schnell vorbei. Wenn dann der "Bildschirm dunkel bleibt" (bildlich gesprochen), ist das nicht schön. Ich wäre auch bereit, für das Programm zu bezahlen, es gefällt mir sehr gut und die Leistung von Albert ist enorm und ich danke ihm dafür.
Angehängte Dateien:
Hier eine Vorschau auf die neue Version 4. Es gibt viele neue Instrumente. Jedes Instrument kann beliebig oft eingestellt werden. Die Eingangskanäle können auf beliebige Instrumente gemappt werden. Die Instrumente lassen sich auf verschiedenen Pages/Displays verteilen (z.Z. 3 Pages event. mehr), zwischen denen während des Betriebs umgeschaltet werden kann. Über die zeitliche Beschränkung mache ich mir in den nächsten Wochen noch mal Gedanken :)
:
Bearbeitet durch User
Albert M. schrieb: > Über die zeitliche Beschränkung mache ich mir in den nächsten Wochen > noch mal Gedanken :) Das ist schön :-)
Einhart P. schrieb: > Albert M. schrieb: >> Über die zeitliche Beschränkung mache ich mir in den nächsten Wochen >> noch mal Gedanken :) > > Das ist schön :-) Ich finds lustig wie sich hier alle dem wirren unfreundlichen Kontrollfreak anbiedern, weil sie sein Progrämmchen wollen. Und der Albert kann so seine Kontrolle ausleben. Hat was von SM.
nur mal so schrieb: > Cyblord -. schrieb: >> Ich finds lustig > > und ich dich für den Allerletzten. Oh Sorry, hab ich deinen Meister beleidigt?
Solche Bemerkungen wie von Cyblord finde ich auch heftig daneben. Immerhin hat er die meisten Sonderwünsche und Verbesserungsvorschläge sukkzessive einfliessen lassen. Manche scheinen ein generelles Problem damit zu haben, dass andere tatsächlich ein ausgereiftes Projekt auf die Reihe kriegen und es bereitwillig zur Verfügung stellen. Auch wenn nicht jedes vermeintliche Haar in der Suppe auf Kommando umgehend entfernt wird... Was Albert hier an Aufwand und Leistung für die Allgemeinheit und dazu noch für ummi eingebracht hat, verdient in jedem Fall Respekt und Anerkennung.
Da schliesse ich mich den Worten von Simpel kommentarlos an. Sogar mit meinem richtigen und registrierten Nick!
cyblord, der Neid schwitzt Dir ja aus allen Poren!
Angehängte Dateien:
-
meldung.png
22 KB
Hallo Albert, dein Programm ist wirklich Klasse und verdient höchste Anerkennung. Habe es für meine Brausteuerung konfiguriert und es arbeitet perfekt. Nun habe ich aber noch eine reproduzierbare Fehlermeldung beim Ausdruck der Full-Trend-Anzeige #51 und #52. Ich drucke auf einen PDF-Drucker, was auch in anderen Anwendungen einwandfrei funktioniert, nur leider hier nicht. Wo ich schon einmal dabei bin, habe ich noch eine Bitte bzw. Anregung. Ich arbeite mit dem UDP-Protokoll und sende dem Arduino einen String aus dem er Rasttemperaturen, Rastzeiten und den Zeitpunkt für die Hopfengaben extrahiert. Ich sende diesen String über das Instrument #93. Da es jeweils ein recht langer String ist, wäre es schön wenn es in #93 noch die Möglichkeit gebe, diese Strings von der Festplatte zu laden. Der absolute Hammer wäre natürlich gleich eine Schnittstelle zu einer Datenbank, z.B. SqLite oder Mysql. Lass Dich bitte durch manche blöden Kommentare hier nicht entmutigen! Ich freue mich schon auf diese nächste Version Deiner Superware. Gruß Lothar
Angehängte Dateien:
Mit der neuen Version geht es gut voran. Oben eine Vorschau vom Design Mode und die bereits verfügbaren Analog Instrumente im Auswahl-Tool. Das Programm ist bereits an den Schnittstellen, mit den gezeigten Instrumenten, beliebigen Kanal-Zuordnungen, Projekt-Speichern/Laden, Design- und Run-Mode voll funktionsfähig. Danke für die Unterstützung. Eure Anregungen und Fehlermeldungen nehme ich immer auf, auch wenn ich nicht auf alles antworte. Gruss Ulrich Albert
:
Bearbeitet durch User
Albert M. schrieb: > Mit der neuen Version geht es gut voran ... und das für die geneigte Anhängerschar bis in den frühen Morgen! Kompliment für den unermüdlichen Einsatz. Die analogen Instrumente sehen ja hübsch aus, allerdings liefert dieser nostalgische Flair ziemlich wenig Info für den Platzbedarf, so daß mir der (unbekannte) Rest der Palette wesentlich interessanter erscheint. Ausgenommen ist das anschauliche Behälterstands-Instrument- mit hoffentlich aktualisiertem grafischen Füllstand! Wenn Du nun schon so konkretes technologisches Instrumentarium lieferst wären auch noch Ventile, Motoren, Lüfter usw. interessant. Mit dem Siemens-PCS, mit dem ich täglich zu tun habe, lassen sich ja ganze Konstruktionslandschaften aus diversen Grundelementen erschaffen- ich nehme aber an, die Rolle des Hintergrundbilds lässt Du erst mal weiter unangetastet...
:
Bearbeitet durch User
Moby A. schrieb: > Wenn Du nun schon so konkretes technologisches > Instrumentarium lieferst wären auch noch Ventile, Motoren, Lüfter usw. > interessant. Es wird Building Blocks mit transparentem Hintergrund geben, wie z.B Linien, Kreuzungen, Rahmen, Ventile, animierte Elemente, Custom-Elemente usw. Davon lassen sich beliebig viele Erzeugen. Das bisher dafür verwendete optionale Hintergrundbild bleibt zusätzlich erhalten und wird auf alle weitern Darstellungs-Seiten (z.Z. 3) eingeführt. Im Übrigen ist die neue Version kein Ummodeln der alten Version, sondern eine komplette Neuentwicklung mit der ich am 25.02. begonnen habe. Die Neuentwicklung wurde durch das vollständige Ändern der Datenstrukturen notwendig. Siehe auch hier: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle"
:
Bearbeitet durch User
Angehängte Dateien:
Für das oben angesprochene Drawing Tool für SerialComInstruments 4 gibt es von mir vorgefertigte transparente Gif-Bilder in verschiedenen Grössen. Jeder kann einfach seine eigenen zufügen. Was man damit ein wenigen Minuten machen kann zeigen die beigefühten Bilder. Gruss Ulrich Albert
:
Bearbeitet durch User
Ulrich, sehen richtig geil aus, deine Instrumente.
Dämpfungs-Faktor für alle Analog-Instrumente. Im neuen SerialCominstruments 4 habe alle Instrumente jetzt eine optionale Dämpfung. Wählbar Low-Pass oder Linear mit einstellbarem Faktor. Zusätzlich gibt es erweiterte Einstellmöglichkeiten für alle Instrumente.
Super!!! Wie im wahren Leben. Gruss sand
Angehängte Dateien:
-
RundInstrument.png
3,8 KB -
RundInstrument1.png
3,1 KB
... und neue Rund-Instrumente. Wie immer Background-Farbe und Transparenz wählbar.
:
Bearbeitet durch User
Was Konkurrenz nicht alles möglich macht. Jetzt fehlt nur noch die Sache mit der OpenSource.
Angehängte Dateien:
Mask-Instrument in SerialComInstruments 4 Es gibt ein weiteres neues Instrument bei dem der Anwender den Inhalt durch Einfügen eigener Grafiken selbst bestimmt. Beispiele für das Ergebnis und Besipiele für vom Anwender zu erstellende Basis-Grafiken als Maske sieht man oben. Der maximale Füllverlauf ist immer vom untersten zum obersten roten Pixel mit 0 bis 100 skaliert. Ein Eingabe für einen Umrechnungsfaktor vom Messwert wird auf dem Zuordnungspanel angeboten. Es sind auch wagerechte Füllverläufe machbar. Natürlich können auch von dieser Instrumentenart beliebig viele und verschiedene angezeigt werden. Gruss Ulrich Albert
:
Bearbeitet durch User
Und ich bin auch schon äußerst gespannt auf das Programm.
Angehängte Dateien:
-
SCI4_Test_Display1.png
42 KB -
SCI4_Test_Display2.png
29 KB -
SCI4_Test_Display3.png
35 KB
Anbei ein Einblick in das SerialComInstruments 4 als Test-Version. Es gibt bereits eine Auswahl an Analog-Instrumenten und Drawing Tools. Vorgefertigte Drawing Tools sind im Programm-Ordner unter BackgroundPictures. Die Projekt-Speicher/Laden Funktionen sind noch Rudimentär. Ebenso sind noch nicht alle Einstell-Optionen verfügbar und das Haupt-Menue ist erst teilweise belegt. Es lassen sich beliebig viele (bis zu 1000) Instrumente oder Drawing-Tools auf zur Zeit bis zu 3 Display-Seiten platzieren. Bedienung eigentlich selbsterklärend, ansonsten: Instrument löschen mit Mouse-Rechtsklick. Einstellfenster für Instrument öffnen mit Mouse-Linksklick (geht nur im Run-Modus). Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo, gibt es mittlerweile einen 16fach x/y Schreiber? Sowas suche ich nämlich noch :-)
Kim S. schrieb: > gibt es mittlerweile einen 16fach x/y Schreiber? Nein, wird es auch nicht geben. Nochmal zu der neuen Version 4: Die Befehls-Syntax ist geblieben. Es wird jetzt jedoch bei dem zu sendenden Messwert nicht mehr das Instrument mit seiner Nummer angesprochen, sondern der Messwert wird mit einem Kanal zwischen 1 und 999 gekennzeichnet. Dieser Kanal wird erst in SerialComInstruments4 einem oder mehreren Instrumenten zugeordnet. Syntax: #kkMm< oder #kkkMmm< wobei kk/kkk = Kanal-Nummer 1..99 / 1..999 m = Messwert Gruss Ulrich Albert
:
Bearbeitet durch User
Die Instrumente funktionieren auf Anhieb über COM. UDP ist vermutlich noch nicht freigegeben. Bemerkung: 1. Bei Fontänderung Skala kommt Fehlermeldung "Ungültige Typumwandlung" (trotzdem wird akzeptiert) 2. Fontänderung Name ohne Funktion. 3. Skalenlängen von Vertikal Meter und Temp. Meter stimmen nicht überein. Gruss sand PS. Es wird mächtig und gewaltig :-)
Angehängte Dateien:
-
SCI4_Test_FlexMeter.png
27 KB -
SCI4_TestGenerator.png
31 KB
Anbei eine neue Test-Version SerialComInstruments 4 Neue Features (siehe Bilder oben): - FlexMeter Instrument mit fliessender Skala - Testsignal Generator (unter Haupt-Menue Generator) Erzeugt Sinus, Sinus mit überlagertem Rauschen und Rampe mit Zyluszeiten von 1 ms, 10 ms, 100 ms und 1000 ms. Es können mehrere Signale gleichzeitig erzeugt werden. Funktionen: Start, Stop, Settings - Dämpfungsfaktor für alle Analog-Instrumente Linear oder Low-Pass (0,1 ... 10) Habe gerade festgestellt, dass die Eingabe des Skalierungsfaktor noch nicht funktioniert. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Programm hat auf Anhieb mit der seriellen Schnittstelle funktioniert. Toll! Habe die Generator-Funktion getestet. Funktioniert gut, aber was bewirken die Haken bei CH1/2/3? Habe den Eindruck, sie sind wirkungslos.
Günter R. schrieb: > was bewirken die Haken bei CH1/2/3? Habe den Eindruck Hast mich erwischt :) Alles 3 Signale werden immer gleichzeitig erzeugt, die Hakenkontrols werden wieder entfernt.
Beim Testen stört jetzt etwas, wie früher, daß COM-Port und Baudrate nicht mitgesichert werden. Könntest du das noch wieder einbauen?
Die eingestellte Dämpfung soll dann für alle Instrumente gelten?
sand schrieb: > Die eingestellte Dämpfung soll dann für alle Instrumente gelten? Bug > Nein, nur für das jeweilige Instrument. Wird geändert. sand schrieb: > Der Flex Meter ist ein Augenschmaus! Das ist der Grund warum ich möglichst professionelle käufliche Instrumente verwende. Müsste ich die alle selber entwickeln, würde ich erst garnicht anfangen.
Angehängte Dateien:
-
SCI4_Test_Tanks.png
35 KB
Anbei eine neue Test-Version SerialComInstruments 4 Neues Tank Instrument Die Form ist wählbar: Tank, Rechteck, Trichter Der Dämpfungsfaktor (0,1 .. 10) ist jetzt für jedes Analog-Instrument getrennt einstellbar. Projekt Speichern/Laden Jedes Projekt wird in einem eigenem Ordner gespeichert. Beim Speichern erstellt man einen neuen Ordner mit passendem Namen. Beim Laden wird das Projekt über diesen Ordnernamen aufgerufen. Günter R. schrieb: > COM-Port und Baudrate > nicht mitgesichert werden. Könntest du das noch wieder einbauen? Ja, kommt noch. Ebenso alle sonstigen Features der alten Version. Das Ganze ist ein Haufen Arbeit :) Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, die Kanalzuweisung für Tank Instrumente ist im Gegensatz zu anderen problematisch. Der Name wird auch nicht angezeigt.
Angehängte Dateien:
-
SCI4_Test_.png
33 KB
Anbei eine neue Test-Version SerialComInstruments 4 LAN / UDP integriert Neues Design-Instrument Rahmen. Neues Design-Instrument Text-Label. - Syntax für Input-Box: Fontgrösse(8..48) Komma Text Die Design-Instrumente können nur im Design-Mode wieder entfernt werden. ComPort und UDP Einstellungen werden zum Projekt gespeichert. Fehler beim Dämpfungsfaktor bei Tank-Instrument behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Wow Albert, das sieht toll aus. :-) Man müsste nur mehr Zeit für die eigenen Projekte habe.
Finde ich gut, das mit dem Rahmen umfasste Gruppe sozusagen fixiert wird. (kein Zugriff im Normalbetrieb) Die Kanalzuordnung für Tank-Instrumente ist weiterhin problematisch. Zuordnung ändert sich willkürlich, lässt kein Korrektur zu.
sand schrieb: > Finde ich gut, das mit dem Rahmen umfasste Gruppe sozusagen fixiert > wird. (kein Zugriff im Normalbetrieb) Das ist eher ein nicht erwünschtes Verhalten, bedingt durch die Erstellungsreihenfolge. Es wird 2 zusätzliche Buttons Front und Background geben. Damit kann die Sichbarkeitsreihenfolge für jedes Instrument nachträglich geändert werden. sand schrieb: > Die Kanalzuordnung für Tank-Instrumente ist weiterhin problematisch. > Zuordnung ändert sich willkürlich, lässt kein Korrektur zu. Kann ich bei mir nicht nachvollziehen. Ist das reproduzierbar? Wenn ja, wie genau.
:
Bearbeitet durch User
Angehängte Dateien:
-
Test.PNG
33 KB
Auf dem Bild von links nach rechts sind vier Kanäle zugeordnet. Nacheinander zB. bei Fontänderung haben alle, die Kanalzuordnung von dritten Instrument übernommen. Ich kann nicht mehr ändern. Keine Möglichkeit mehr für neue Kanalabspeicherung. Die untere Flex-Meter arbeiten einwandfrei. Nur die obere Tankanzeigen spinnen. Es wiederholt sich fortlaufend.
sand schrieb: > Nur die obere Tankanzeigen spinnen. Es wiederholt > sich fortlaufend. Ich konnte das Fehlverhalten der Tanks jetzt nachvollziehen. Beim FlexMeter Instrument fehlt übrigens noch ein Einstellparameter. Eine neue Version gibt es nächste Woche.
:
Bearbeitet durch User
Albert M. schrieb: > Falls ich das Projekt mal beende, werde ich als letzte Version das > Zeitlimit aufheben. Sorry das ich mich einmische. Das Programm ist wirklich erste Sahne, sozusagen world liga und vielen vielen Dank dafür. Den Einsatz weiß ich wohl zu schätzen. Man sieht das es von einem Profi kommt (der wohl unter NI etwas anderes als Nicaragua versteht). Auch an den Tools (Delphi Virt-Instruments Enigma) ... Aber mal Hand aufs Herz, was hast du vor Albert? Nochmal einsteigen und die Community als Beta Tester verwenden? Gesetz dem Fall, wäre das fair? Das Programm würde ich gern für meinen Schreibtisch nutzen. Zum messen, ganz für mich in meiner kleinen 2 1/2 Mann Firma und intern. Ist das Ok? Was mache ich aber nächstes Jahr wenn ich mich daran gewöhnt habe. Jedes mal updaten und ein Risiko eingehen?
Albert M. schrieb: > Ja, wie zur Zeit auch. Daran wird sich auch zuerst mal nichts ändern. > Die zeitliche Begrenzung der aktuellen Version beträgt, wie auch für > weitere Versionen, jeweils 1 Jahr vom Veröffentlichsdatum. Wenn Du immer > eine einigermassen aktuelle Version benutzt dürfte das kein Problem > sein. Falls ich das Projekt mal beende, werde ich als letzte Version das > Zeitlimit aufheben. Und damit ist das Projekt für mich uninteressant geworden. Ich bin von Anfang an dabei und lese hier fleißig mit. Aber ein Programm zu nutzen, dass nur nach einem Jahr nicht mehr funktioniert, ist für mich kompletter Unsinn. Man richtet sich ein, hat keinen unerheblichen Aufwand um es sinnvoll zu nutzen, und dann wird es von jetzt auf gleich wertlos. Und nicht nur das Programm, sondern auch meine eigene Entwicklung. Nichts für ungut. Ich kann aus Entwicklersicht das Vorgehen verstehen, aber aus Anwendersicht leider nicht. Selbst das angestaubteste Labview läuft auch nach 10 Jahren noch. Alles was man braucht ist die Runtime dafür. Vom Funktionsumfang kann es mitnichten weniger (sondern noch viel mehr) und ist selbst für Einsteiger gut geeignet, weil man sehr schnell auf einen grünen Zweig kommt. UND: Es läuft ohne Beschränkung solange die Runtime läuft. Und da ist eher das Betriebssystem das Problem, als die Software selbst.
Martin S. schrieb: > Selbst das angestaubteste Labview läuft auch nach 10 Jahren noch. Alles > was man braucht ist die Runtime dafür. Vom Funktionsumfang kann es > mitnichten weniger (sondern noch viel mehr) und ist selbst für > Einsteiger gut geeignet, weil man sehr schnell auf einen grünen Zweig > kommt. UND: Es läuft ohne Beschränkung solange die Runtime läuft. Martin, warum brinst Du so einen unangemessenen Vergleich und verschweigst was Labview kostet, nämlich zwischen 1000 und 6000 Euro. Damit in der Runtime-Version was von Dir Erstelltes läuft, musst Du erst mal Labview gekauft und das Projekt für die Runtine-Version erstellt haben. Ausserdem solltest Du Dir nach obiger Aussage schon die Frage gefallen lassen, warum Du überhaupt meine Software benutzt. Martin S. schrieb: > Aber ein Programm zu nutzen, > dass nur nach einem Jahr nicht mehr funktioniert ... > Ich kann aus Entwicklersicht das Vorgehen verstehen Solange die Programme noch potentiell fehlerbehaftet sind, wird die Beschränkung auf 1 Jahr Laufzeit, jeweils ab neuestem Release-Datum bestehen bleiben. Ich will nicht, dass noch nach Jahren verbuggte Programme von mir im Umlauf sind. Im übrigen ist auch meine Software SerialComCNC nach gleichem Muster zeitlimitiert. Das hat aber die wenigsten gestört. Aktuelle Download-Stand über 1800 seit Ende letzten Jahres. Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Dazu sind die Downloads bei SerialComInstruments eher kläglich und ich führe es nur weil ich es selber bei meinen Basteleien benutze und aus Spass an der Freud weiter. Jens M. schrieb: > Aber mal Hand aufs Herz, was hast du vor Albert? Nochmal einsteigen und > die Community als Beta Tester verwenden? Gesetz dem Fall, wäre das fair? Dazu habe ich ja schon genug geschrieben. Warum sollte ich für ein Paar Euro ein Gewerbe anmelden mit dem ganzen Rattenschwanz dahinter? Das habe ich alles hinter mir und ich bin froh, dass ich seit 1992 nicht mehr arbeiten brauchte. Jetzt im Rentenalter werde ich sicher nicht wieder damit anfangen. Da gehe ich lieber gemütlich in mein Cafe oder meinen sonstigen Hobbies nach. Langsam ist es mir zu mühselig, mich andauernd für eine kostenlose Software rechtfertigen zu müssen. Take it or leave it.
:
Bearbeitet durch User
Moin,Moin. Durch Zufall bin hier auf das Projekt gestoßen. Hut ab für das was da auf die Beine gestellt wurde. Ich würde die Software durchaus nutzen, da sie schnell und einfach in ein Projekt (nur privat) einzubinden ist. Ich habe auch keine Probleme mit Freeware aber: Eine Laufzeitbeschränkung von 1 Jahr ohne jeglichen Hinweis darauf, das ist ein NoGo.
Moin Ulrich, Bitte nimm es nicht übel aber so schön deine Programme sind - auch für mich bleibt nur die Option 2: Albert M. schrieb: > Take it or leave it. Auch ich habe die SerialComCNC 'runtergeladen und getestet. Da war aber die Zeitbeschränkung noch nicht bekannt. Es ist dein Projekt; du kannst es halten wie du willst. Gruß aus dem westlichen Niedersachsen Einhart
Um ehrlich zu sein, verstehe ich nicht diese Leute hier. Die bekommen ein Geschenk, und sie sind mal sogar dazu zu faul ein Update zu machen und jammern, winseln wie ein kleines Kind wenn der Lutscher alle ist. Dazu noch ihre üble levantinische Mentalität. Von zu Hause aus sind die meisten sogar dazu unfähig, konstruktive Fragen zu stellen oder Besserungsvorschläge zu unterbreiten. Leute es ist ein Geschenk für euch und seid froh überhaupt mitmachen zu dürfen. Da kommen noch hinzu die kleinkarierte möchtegernemeingrossesgeschäft damit machen Typen und lechzen nach Zugabe. Es kommt bei mir manchmal zum Reflux wenn ich die Kommentare lese. Albert, was du machst ist Super. sand
Ja, so ist es leider. Die zum Projekt bisher NICHTS beigetragen haben stellen Ansprüche. So what.
Was sollte denn der Beitrag anderer zu einem "Alles meins"-Projekt sein? Neue Anforderungen sind falsch, Hinterfragen Bestehendes ist falsch, zumindest solange, bis es ein Konkurrenzprojekt gibt, dann gibt es plötzlich die bisherigen Unverschämtheiten.
Also ich weiss nicht, warum da noch immer drüber gemeckert wird. Es ist so und fertig. Wem es nicht passt, kann ja was anderes benutzen. Die Version 4 sieht ja recht vielversprechend aus, das hätte ich mir ja nicht träumen lassen, dass es doch mal in diese Richtung geht. Nun aber zum eigentlichen Thema. Ich komme nun seit längerem mal wider dazu, mich mit meiner Poolsteuerung zu beschäftigen, die Saison geht ja bald los. Hab aktuell die 0.8 drauf. Mit dem Instrument 82 stelle ich die Hysterese/bzw.Wert ein, ab welchem Wert Wasser gepumpt wird (z.B. 10 mm). Das klappt auch, nur wenn das Programm gestartet wird, steht der Regler auf 0 mm und nicht auf dem aktuellen Wertaus der Steuerung. Gibt es einen Befehl, mit dem ich den Regler vom uC auf die 10 mm "einstellen" kann?
Bastler schrieb: > Neue Anforderungen sind falsch, Hinterfragen Bestehendes ist falsch Wie kommst Du auf diese Aussage? Es wurden von mir fast alle Anwenderwünsche integriert. Bastler schrieb: > dann gibt es plötzlich die bisherigen Unverschämtheiten. Die da wären? Offensichtlich stänkern wieder wie immer die rum, die das Programm eh nicht nutzen. @Rainer M. Ich schau mal nach was sich machen lässt.
:
Bearbeitet durch User
Rainer M. schrieb: Mit dem Instrument 82 stelle ich die Hysterese/bzw.Wert ein, ab welchem Wert Wasser gepumpt wird (z.B. 10 mm). Das klappt auch, nur wenn das Programm gestartet wird, steht der Regler auf 0 mm und nicht auf dem aktuellen Wertaus der Steuerung. Gibt es einen Befehl, mit dem ich den Regler vom uC auf die 10 mm "einstellen" kann? Du solltest eine feste Vorgabesollwert für den Wasserstand programmieren und mit dem Instrument 82 je nach Bedarf per Hand einen Korrekturwert dazu addieren.Eine zusätzliche Variable löst dann das Problem. sand
Ein Problem habe ich nicht damit, es ist nur kosmetischer Natur. Mein Vorgabewert ist 280, zu dem ich ein Offset addiere, der vom 82er Instrument kommt, z.B. 5. D.h. sobald der Distanzsensor mahr als 285 mm bis zur Wasseroberfläche misst, wird hochgepumpt bis er wieder 280 oder weniger misst. Der Wert 285 wird im Eeprom abgespeichert. Nach Stromausfall funktioniert alles einwandfrei weiter, nur das 82er steht eben auf 0 und nicht auf 5. Bewegt man es z.B. auf 6, wird der Sollwert korrekt auf 286 geändert und das Instrument steht wieder richtig in Bezug auf Sollwert. Direkt nach dem Neustart steht es sber wie gesagt auf 0, ein reiner Schönheitsfehler, daher mein Post. P.S.: Ist schon abzuschätzen, wann die 4er Version soweit ist?
:
Bearbeitet durch User
Rainer M. schrieb: > Ist schon abzuschätzen, wann die 4er Version soweit ist? Die Version 4 ist komplett neu geschrieben. Alle Instrumente werden hier dynamisch erzeugt, das bedingt mehr Aufwand bei der Erzeugung und Verwaltung. Welche Instrumente benutzt Du bisher? Vielleicht kann ich die bevorzugt integrieren. Allerdings kann die Funktionalität einiger Instrumente vom Bisherigen abweichen (z.B. LED), andere werde ich vorerst nicht integrieren (z.B. Paint-Instrument), weil sie anscheinend kaum benutzt werden.
Benutzen tue ich momentan: Vertikal Meter Dig DisplayLED #60 Taster Switch Num Display Aktiv Label Slider Wunschkonzert Die Analoganzeigen wie bereits in Ver.4 Dig DisplayLED #60 Viel mehr Taster Switch Viel mehr Num Display Aktiv Label nicht so wichtig, wenn mehr von den anderen Slider (mit Wert setzen, wie im Post weiter oben) Toll wären noch, wenn man die Taster Switch mit farbiger LED hätte Normale Labels für statischen Text
Noch was, der udp remote host ist zwar in der ini abgespeichert, wird aber nicht geladen
Albert M. schrieb: > Martin S. schrieb: >> Selbst das angestaubteste Labview läuft auch nach 10 Jahren noch. Alles >> was man braucht ist die Runtime dafür. Vom Funktionsumfang kann es >> mitnichten weniger (sondern noch viel mehr) und ist selbst für >> Einsteiger gut geeignet, weil man sehr schnell auf einen grünen Zweig >> kommt. UND: Es läuft ohne Beschränkung solange die Runtime läuft. > > Martin, warum brinst Du so einen unangemessenen Vergleich und > verschweigst was Labview kostet, nämlich zwischen 1000 und 6000 Euro. > Damit in der Runtime-Version was von Dir Erstelltes läuft, musst Du erst > mal Labview gekauft und das Projekt für die Runtine-Version erstellt > haben. > Ausserdem solltest Du Dir nach obiger Aussage schon die Frage gefallen > lassen, warum Du überhaupt meine Software benutzt. Du hast schon recht, und ich will Deine Arbeit nicht diskreditieren. Aber Du solltest halt auch nicht vergessen, dass es eine Kehrseite der Medallie gibt. Mehr habe ich nicht gesagt. Ich habe mir als Student die Version https://www.conrad.de/de/national-instruments-labview-student-edition-de-software-fuer-windows-und-mac-1152098.html geholt. Und gegen die Einblendung mit der Studentenversion gibt es tricks. Natürlich ist das eine eine sehr teure Software. NI sind gierige ... naja, lassen wir das. Aber es ist nunmal eine Alternative. Und es gibt auch des öfteren mal alte Lizenzen für ca. 90 Euro zu kaufen. Für den Hobbyanwender reicht die Version 8 schon voll und ganz aus. > Martin S. schrieb: >> Aber ein Programm zu nutzen, >> dass nur nach einem Jahr nicht mehr funktioniert ... >> Ich kann aus Entwicklersicht das Vorgehen verstehen > > Solange die Programme noch potentiell fehlerbehaftet sind, wird die > Beschränkung auf 1 Jahr Laufzeit, jeweils ab neuestem Release-Datum > bestehen bleiben. Ich will nicht, dass noch nach Jahren verbuggte > Programme von mir im Umlauf sind. Aber wo ist da DEIN Problem? Wie gesagt - den Entwicklergedanken verstehe ich. Aber wer eine alte Version einsetzt, der ist selbst schuld. Daran ändert auch eine Laufzeitbeschränkung nichts. > Im übrigen ist auch meine Software SerialComCNC nach gleichem Muster > zeitlimitiert. Das hat aber die wenigsten gestört. Aktuelle > Download-Stand über 1800 seit Ende letzten Jahres. > Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit > ATMega" > Dazu sind die Downloads bei SerialComInstruments eher kläglich und ich > führe es nur weil ich es selber bei meinen Basteleien benutze und aus > Spass an der Freud weiter. Ich kenne Deine Downloadzahlen nicht. Und mir ist das auch ehrlich gesagt egal. Ich bin ein Anwender, sehe es gibt ein Produkt, das kostenlos tut, was andere nur teuer können, und bin erstmal begeistert. Nur wenn halt dann irgendwann die Ernüchterung kommt, dann ist das sehr ärgerlich. Und das wirst Du schlichtweg einfach verstehen müssen. Natürlich kannst Du tun und lassen, was Du willst. Du kannst wegen mir auch eine Beschränkung auf 1 Tag einführen, oder einen DRM-Schutz einbauen, der online die Lizenz prüft. Nur dann ist das halt für mich und für viele andere der Punkt, an dem es nicht mehr weiter geht. Und wenn man nichteinmal das sagen darf ... > Jens M. schrieb: > Take it or leave it. Dann halt letzteres.
Rainer M. schrieb: > Dig DisplayLED #60 Eine neue Multi-Mode LED ist bereits integriert. - Rund, Rechteck, Pfeil(oben, unten, rechts, links) - Mode kann auch vom MC aus geändert werden Rainer M. schrieb: > Viel mehr Taster Switch Ich bastele gerade an einem Multi-Mode Schalter/Taster mit integrierter LED. - wahlweise Schalter oder Taster - Status LED in der Grösse variabel und mit Optionen: - Farbwechsel sofort bei Betätigung (Schalter und Taster) - Farbwechsel erst nach Rückmeldung vom MC (Schalter) z.B.: Grau(Off), Gelb(Gedrückt), Grün(vom MC bestätigt) Rainer M. schrieb: > Viel mehr Num Display Alle Instrumente können in der Version 4 beliebig oft platziert werden. Rainer M. schrieb: > udp remote host ist zwar in der ini abgespeichert, wird > aber nicht geladen Wird geändert. Gruss Ulrich Albert
:
Bearbeitet durch User
Albert M. schrieb: > Über die zeitliche Beschränkung mache ich mir in den nächsten Wochen > noch mal Gedanken :) Um die Diskussion darüber zumindest ein wenig abzumildern, erhöhe ich erst mal die Beschränkung auf 2 Jahre ab jeweiligem Release Datum (wie bei SerialComCNC). Ansonsten lasst mir, wie oben geschrieben, Zeit darüber nachzudenken.
Albert M. schrieb: > Um die Diskussion darüber zumindest ein wenig abzumildern, erhöhe ich > erst mal die Beschränkung auf 2 Jahre ab jeweiligem Release Datum (wie > bei SerialComCNC). Ansonsten lasst mir, wie oben geschrieben, Zeit > darüber nachzudenken. Das ist prima. Vielen Dank. Ich habe jetzt mein 1-Wire-Thermometer auf 4 Kanäle erweitert, sodaß ich jetzt alle relevanten Temperaturen meines Heizraumes loggen bzw. visualisieren kann. Daher bin ich viel am Testen. Schön wäre jetzt noch - nachdem Du die COM-Parameter im Projektfile ablegst, was schon viel hilft - wenn der Kommandozeilenparameter zum Projektfile-Laden/Starten wieder käme, so wie früher, mit der Option, daß die COM-Schnittstelle gleich nach dem Starten bzw. Laden aktiv ist und somit das Programm sofort loslegt. Damit wäre fast wieder der infrastrukturelle Stand der alten Version erreicht. Das wäre klasse.
Angehängte Dateien:
-
SCI4_Test2_.png
31 KB
Anbei eine neue Test-Version SerialComInstruments 4 (Expiration Date 15.03.2018) Neues multifunktionales LED Instrument - Design: Rund, Rechteckig, Pfeil(oben, unten, rechts, links) - Led Grösse und Text einstellbar - Led Position (Jeweils vom Text: links, rechts, oben, unten) - Vom MikroController steuerbar. Syntax: #kMfdm< #, M, < = Delimiter k = Kanal-Nummer (1 bis 3 stellig) f = Farbe (0=grau, 1=gelb, 2= grün, 3=rot) d = Design (0=rund, 1=rechteck, 2=oben, 3=unten, 4=rechts, 5=links) m = Mode (0=statisch, 1=blinkend) Zur Farbänderung reicht es nur Parameter f zu senden. FlexMeter Instrument - zusätzlicher Parameter StepsShow zugefügt Com-Terminal integriert. Diverse Bugs behoben. Günter R. schrieb: > wenn der Kommandozeilenparameter zum > Projektfile-Laden/Starten wieder käme Kommt demnächst. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ulrich, das sieht alles sehr geil aus. Habe gerade mal ein bisschen im Manual gelesen. Das ist recht einfach. Werde da sicher bald auch mal drauf zugreifen. Nur so am Rande, ganz tolle Makrofotografie. Sehr, sehr schöne Bilder. Meine Ex hatte mir die Fotografie vermiest, aber deine Fotos motivieren mich mal im Wald "ohne Waffe" zu schießen.
Angehängte Dateien:
-
SCI4_Test2a_.png
27 KB
Was man mit den Led- und Design-Instrumenten so machen kann (Bild oben). F. F. schrieb: > Nur so am Rande, ganz tolle Makrofotografie. Freut mich, dass Dir meine Insekten Makros gefallen. Aber ohne Stativ, Makros-Schlitten und viel Geduld geht da nichts. Wer sich sonst noch dafür interessiert: http://www.fotocommunity.de/fotograf/ulrich-maassen/fotos/1508221
:
Bearbeitet durch User
Angehängte Dateien:
-
SCI4_Test3_.png
26 KB
Anbei eine neue Test-Version SerialComInstruments 4 (Expiration Date 15.03.2018) Neues Schalter / Taster Instrument - Mode: Schalter oder Taster - Grösse änderbar - Integrierte LED - LED On Color wählbar - LED Höhe einstellbar - Text, Position und Font einstellbar - Schickt bei Klick an den MikroController (COM/LAN): #kMs< #, M, < = Delimiter k = Kanal-Nummer (1 bis 3 stellig) s = Status (0=Aus, 1=Ein) - Demnächst optional mit Bestätigung vom MC: Der MC bestätigt dem Empfang durch LED-Farbänderung. Beispiel: Taster gedrückt gelb, MC bestätigt grün Menue Hilfe - Es wird eine vorläufige Hilfe im PDF-Format aufgerufen. Wichtig: Einstell-Parameter Fenster wird jetzt über Doppelklick auf das Instrument geöffnet. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
sand schrieb: > Ich kann die Taster nicht zum Funktionieren zwingen. Was genau funktioniert nicht? Bei mir funktionieren die einwandfrei.
Durch Terminalkommando kann ich einen Taster nachahmen, Terminal zeigt auch Rückmeldung an, der Taster selbst hat kein Funktion.
Hallo Albert, heute sind mir noch ein paar Ideen für Dein Programm eingefallen: Albert M. schrieb: > Anbei eine neue Test-Version SerialComInstruments 4 > (Expiration Date 15.03.2018) 1) Unter "Help/Info" könntest Du doch eine Info-Box einbauen, in der Deine Copyright-Daten stehen sowie das Expiration Date; dann wäre das für die jeweilige Version immer gut dokumentiert. 2) Wenn man ein Projekt lädt, wäre es schön, wenn dieser Projekt-Name oben in der blauen Programmheaderzeile angezeigt werden würde, ähnlich wie bei Textprogrammen wie Word, wo auch oben der Dokumentname steht. 3) Im File-Menü könnten die Save-Einträge "Save" und "Save as ..." stehen; das "Save as ..." könnte dann Dein heutiges "Save" ersetzen, und das neue "Save" würde einfach das bereits geladene Projekt dort updaten, von woher es geladen wurde. Wurde noch kein Projekt geladen, dann würde "Save" auf "Save as ..." verzweigen, so wie bei Textprogrammen auch. 4) Und zum Schluß noch eine Idee für ein neues Instrument (nicht so wichtig, aber evt. interessant auch für andere): Ein Betriebsstundenzähler. Der könnte durch einen Befehl wie "#kM1<" gestartet und mit "#kM0<" gestoppt werden. Damit könnte ich bei meiner Heizungssteuerung z.B. die Kessel-Laufzeit und die Solarladezeit messen. Und ganz weit vorgedacht: eine Option dazu, um z.B. zu Mitternacht, falls das Programm dann läuft, diese Werte in eine Log-Datei schreiben zu lassen, wobei wahlweise der Betriebsstundenzähler dann auf Null gesetzt wird, sodaß Tageswerte erfaßt und geloggt werden. Nur mal so ne Idee ... Und gerade fällt mir noch eines ein: Einfach ein Zähler, der durch einen Befehl inkrementiert wird. Damit könnten Vorgänge gezählt werden, beispielsweise auch, wie oft ein anderes Instrument einen Meßwert bekommt. Dazu müßte man einfach dem Zähler die gleiche Kanalnummer zuweisen wie einem anderen Instrument, und schon würden dessen Ansteuerungen gezählt werden, ohne weiteres Zutun (den Meßwert würde der Zähler einfach ignorieren). Daran sieht man auch schon, wie toll die neue Kanalnummerngeschichte seit V 4 ist. Das ist super! Gruß, Günter
sand schrieb: > Durch Terminalkommando kann ich einen Taster nachahmen, Terminal zeigt > auch Rückmeldung an, der Taster selbst hat kein Funktion. Wie oben beschrieben sind die Schalter/Taster Instrumente unidirektional, nämlich nur vom Schalter zur Schnittstelle. Es wird immer die Info über die Schalterbetätigung zum MC gesendet, aber z.Z. kann man nicht vom MC irgendwas zum Schalter senden.
:
Bearbeitet durch User
Günter R. schrieb: > heute sind mir noch ein paar Ideen für Dein Programm eingefallen: Danke für Deine Anregungen. Die werde ich soweit wie möglich umsetzen. Ich habe eine simple Trend Mini-Anzeige als Aufsatz für z.B. die Analog-Instrumente soweit fertig. Das kommt jetzt als nächstes.
:
Bearbeitet durch User
Albert schrieb: >Wie oben beschrieben sind die Schalter/Taster Instrumente >unidirektional, nämlich nur vom Schalter zur Schnittstelle. Es wird >immer die Info über die Schalterbetätigung zum MC gesendet, aber z.Z. >kann man nicht vom MC irgendwas zum Schalter senden. Das ist mir klar, ich wollte darauf hinweisen, das Schalterbetätigung vom Programm nicht erfasst wird, und unter eine "Terminalmaskierung" gesendete "Taster" funktioniert. Beispiel:#50M1< wie ein Taster kodiert ist, wird vom Terminal gesendet und vom Programm angenommen und aufgearbeitet (mit Rückmeldung des Sendestrings) #50M1< sollte vom Taster gesendet sein, aber kommt nichts im µC an.
Bei mir funktionieren die Taster/Schalter korrekt. Getestet mit Packetsender und 2tem PC
Angehängte Dateien:
-
Test_Taster.PNG
17 KB
sand schrieb: > Beispiel:#50M1< wie ein Taster kodiert ist, wird vom Terminal gesendet > und vom Programm angenommen und aufgearbeitet (mit Rückmeldung des > Sendestrings) > #50M1< sollte vom Taster gesendet sein, aber kommt nichts im µC an. Der Taster sendet bei Betätigung seinen Status an den MC (siehe Bild oben mit Kanal 23, LA-Messung am MC). Macht also genau das was er soll. Du kannst nichts vom Terminal oder MC zum Taster senden. Oder reden wir irgendwie aneinander vorbei?
Ich will vom Taster zum µC senden. Im Terminal sehe ich aber eine Rückmeldung wenn ein Kommando im µC ankommt und akzeptiert wird. Da der Taster kein Reaktion bewirkt, habe ich die Gegenprobe gemacht und mit dem Terminal auch Tasterbefehle gesendet zum µC, welche funktionieren. Ich werde jetzt das Programm neu Installieren.
Nicht vergessen nach der Kanaleinstellung oder Übernahme der Grundeinstellungen den Save-Button zu drücken. Sonst ist das gewählte Instrument nur optisch da. D.h. jedes neue Instrument muss durch "Save" initalisiert werden.
Wenn man das Projekt abspeichert, so speichern sich die letzten Meßdaten mit (bzw. die optische Darstellung auf dem Instrument); wird das Projekt später wieder geladen, dann stehen die Instrumente so, wie sie zuvor verlassen wurden. Das hat mich schon manchmal verwirrt, da ich mich über die angezeigten Werte gewundert hatte, dabei hat mein uC noch garnichts gesendet gehabt, und seine Werte wären jetzt ganz andere als die zunächst angezeigten. Wäre es nicht besser, die Instrumente immer bei Null starten zu lassen, wenn das Projekt geladen wird?
Günter R. schrieb: > Wäre es nicht besser, die Instrumente immer bei Null starten zu lassen, > wenn das Projekt geladen wird? Wird in einer der nächsten Releases geändert.
Das Programm neu installiert. Ohne positives Ergebnis. UDP Probe durchgeführt, mit Packet Sender Tasterbefehle gesendet, Datenfluss hin und zurück mit Wireshark kontrolliert, funktioniert einwandfrei. Vom Programm her ist die Lage nicht so rosig. Wireshark zeigt kein Datenverkehr Richtung µC wenn der Taster betätigt wird. Genauso wie bei COM Verbindung. Bin ich ratlos aber nicht hoffnungslos:-)
Jetzt habe ich alle Taster deinstalliert und danach neu aufgelegt. Gleiche Einstellungen wie vorher. Genauso abgespeichert. Und es funktioniert!!! :-) UDP und COM Diesmal bei Neuauflegung kamen nicht die übliche Fehlermeldungen über schon vergebenen Instrumentennummer. Die Instrumentennummer sollte an die Anzahl installierte Geräte angepasst sein. Scheinbar die deinstallierte Geräte spucken in die Suppe.
Noch was aufgefallen. Beim Laden oder Speichern ist der Ordner SerialComInstruments4 doppelt vorhanden, scheinbar gleichwertig. Im Win Explorer ist nur einfach vorhanden.
sand schrieb: > Beim Laden oder Speichern ist der Ordner SerialComInstruments4 doppelt > vorhanden Vielleicht hast Du mal vergessen die beigefügte Deinstallations UnInstall.Exe zu benutzen.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei eine neue Test-Version SerialComInstruments 4 (Expiration Date 16.03.2018) Neues Simple Graph Instrument - Dient als einfachste Trend-Anzeige ohne Beschriftungen. - Beliebig oft platzierbar. - Vorschub wählbar (sehr schnell bis extrem langsam). - Eine Null-Linie ist frei positionierbar. - Protokoll: #kMm< wobei k=Kanal (1...999) und m=Messwert Da dieses Instrument aus Geschwindigkeitsgründen nur Integer Zahlen akzeptiert, wurde ein Messwert-Multiplikator zugefügt. Damit dürfen die gesendeten Messwerte beliebige Fliesskomma-Zahlen sein. Beispiel: Man möchte eine Darstellung von Messwerten im Bereich von 0 bis 1. Hierfür bietet sich ein Multiplikator von 100 an. Dabei muss dann natürlich der Maximum Wert auf 100 eingestellt werden. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ich habe festgestellt das die Tastereinstellungen werden (jedenfalls bei mir) nicht gespeichert. Bei jeder Neueröffnung des Programmes sind die Taster wirkungslos. Nachdem die gelöscht werden und danach neu installiert, mit gleichen Einstellungen, funktionieren die wieder ohne Probleme. Jetzt kommt die Abspeicherung. Danach wird das Programm geschlossen. Nach Neueröffnung fängt das Spiel von vorne an. Die schon früher erwähntes Problem - Ordner beim Laden und Speichern doppelt vorhanden, trotz komplette Ausradierung des Programmes mit Deinstall und Ordnerlöschung danach - bleibt nach Neuinstallation weiterhin aktuell. Andere Instrumente funktionieren bestens.
Bemerkenswert ist noch, das ein Ordner benannt wie SerialComInstruments4 der andere wie serialcominstruments4
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 07 (Expiration Date 17.03.2018) Bug "Schalter-Instrument nach Projekt-Laden ohne Wirkung" behoben. Diverse andere Bugs behoben. Die Build/Versions Nummer kann unter Menue/Help/Info eingesehen werden Die nur für alte Windows-Systeme benötigte Datei qtintf70.dll wurde aus dem Installations-Package entfernt. Wer damit Probleme bekommt, bitte melden. sand schrieb: > Bemerkenswert ist noch, das ein Ordner benannt wie SerialComInstruments4 > der andere wie serialcominstruments4 Es werden alle Ordner nur einmalig erstellt. Allerdings mag es sein, dass Windows da seine eigenen Spielchen treibt. Ich lasse unter Win7 in c:\SerialComInstruments4 installieren. Damit gibt es keine Probleme. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Der Ordner wird ja nicht zweimal erstellt, sondern nur in 2 verschiedenen Schreibweisen im "Öffnen"-Fenster angezeigt.
Danke Albert, Die Abspeicherung funktioniert jetzt. Kleine Unannehmlichkeit, das - wie bei mir eben jetzt - etwa 15 mal habe ich versucht ein Text-Label neu erschaffen bis endlich eine freie Instrumentennummer Güte zeigte. Auf dem Schirm habe ich aber weniger Objekte. Gruss sand
Rainer M. schrieb: >Der Ordner wird ja nicht zweimal erstellt, sondern nur in 2 >verschiedenen Schreibweisen im "Öffnen"-Fenster angezeigt. auch im "Speichern" Fenster
sand schrieb: > Rainer M. schrieb: >>Der Ordner wird ja nicht zweimal erstellt, sondern nur in 2 >>verschiedenen Schreibweisen im "Öffnen"-Fenster angezeigt. > auch im "Speichern" Fenster Tritt bei mir nicht auf, daher schwierig den Grund fest zu machen. Existieren diese Doubletten auch im Windows Explorer oder sind die nur in SerialComInstrumets Save/Load Dialog-Boxen zu sehen? sand schrieb: > versucht ein Text-Label neu erschaffen ... Wurde behoben.
:
Bearbeitet durch User
Nur in SerialComInstrumets Save/Load Dialog-Boxen zu sehen Windows Explorer zeigt korrekt nur einen, den Installations-Ordner an.
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 08 Die Save/Load Componenten sind komplett ausgetausch. Ich hoffe, dass bei euch das seltsame Verhalten nun nicht mehr auftritt. Löschen von Instrumenten mittels rechter Mouse-Taste beschränkt sich auf den Run-Modus. Anzeige des aktuellen Projektes nach Speichern/Laden in der oberen Fenster-Leiste. Diverse Bugs beseitigt.
Es wurden weitere Bugs korrigiert: Simple Graph löste bei Änderung auf kleine Abmasse einen Run-Time Error aus. HighSpeedTimer Priorität erhöht um Aussetzer beim Generator-Betrieb durch User Aktionen zu vermindern. Das Rahmen Instrument kann nun in den Vorder-/Hintergund gesetzt werden.
:
Bearbeitet durch User
Was haltet ihr von einem Math/Logik Instrument/Funktions-Block? Angedachte Funktionsweise: Eingänge: 1 oder mehrere Kanäle Interne Verarbeitung: Logik-, math. Funktionen, Min/Max, Datenreduktion etc. Ausgang: 1 Kanal, der wieder als virtueller neuer Messwert in die Verarbeitung eingespeist wird. Damit liessen sich komplexe Strukturen und Verarbeitungsmöglichkeiten erzeugen. Wetter ist eh schlecht, da probiere ich das übers Wochenende mal aus :) Gruss Ulrich Albert
:
Bearbeitet durch User
Albert schrieb:
>Was haltet ihr von einem Math/Logik Instrument/Funktions-Block?
Ich bin dafür!
Frage: alle Instrumente können jetzt in den Vorder-/Hintergund gesetzt
werden?
sand
Albert M. schrieb: > Was haltet ihr von einem Math/Logik Instrument/Funktions-Block Sehr viel !! Volgendes Beispiel wäre denkbar: Über ein Kanal wird das Ein und Ausschalten des Brenners erfasst. Dieses Signal wird dann mit einem "Time-Stamp" versehen. Über einen Parameter (Liter pro Zeit) kann dann auf der Tankanzeige der Ölverbrauch dargestellt werden. (mache ich momentan manuell mit Exel Sheet) Hier noch ein BUG: Bei dem digitalen Aktuator der z.B. mit "ON" beschriftet ist, muss ich auf die Led clicken um in einzuschalten -> wiederspricht der Logik - müsste umgekehrt sein -> auf ON clicken und dann geht die Led an. Beim Taster verhält es sich genauso. Grüsse Latschensepp aus Hintertupfing
Albert M. schrieb: > Was haltet ihr von einem Math/Logik Instrument/Funktions-Block? Davon halte ich sehr viel. Damit wird SerComInst ein richtiges Auswertungsprogramm, nicht nur Visualisierung. Es sollte dann auch Möglichkeiten geben, berechnete Werte zu einem uC zu senden; wann gesendet wird bzw. wodurch, müßte man dann noch überlegen (entweder eine Art Polling vom uC, oder Kriterien bestimmen, wann SerComInst sie sendet, oder noch besser beides).
Albert M. schrieb: > Die nur für alte Windows-Systeme benötigte Datei qtintf70.dll > wurde aus dem Installations-Package entfernt. > Wer damit Probleme bekommt, bitte melden. Ich würde das Programm auch auf einem alten WinXP-Rechner laufen lassen; habe mal die DLL aus einer vorherigen Installation gesichert. Würde es für einen Betrieb unter WinXP genügen, wenn man nach der normalen Installation einer neuen Version von SerComInst einfach diese gesicherte DLL in das Install-Directory (C:\SerialComInstruments) manuell reinkopiert? Diese DLL ändert sich ja wohl nicht mehr, ist ja, wenn ichs richtig sehe, eine uralte Datei?
Albert M. schrieb: > Wetter ist eh schlecht, da probiere ich das übers Wochenende mal aus Falls das Wetter länger schlecht bleibt und dir langweilig wird :) Wäre es denkbar bei den Rundinstrumenten nur die Zeiger zu liefern (am besten gerendert) und jeder kann sich seine eigene Scala dazu platzieren? (so käme ich endlich zu meiner Breitling Uhr ;) Grüsse Latschensepp aus Hintertupfing
Ich habe jetzt die neue Version installiert, aber das Rahmen-Instrument kann nicht in den Vorder oder Hintergund gesetzt werden. Deckt weiterhin unzugänglich die darunterliegende Objekte ab.
Albert M. schrieb: > Was haltet ihr von einem Math/Logik Instrument/Funktions-Block? Wäre es nicht besser, zuerst die Grundfuntionalitäten zu machen und die Bugs zu bereinigen, dass man seine Projekte auf das neue Format umstellen kann und danach erst die Luxusdinger einbaut? Rahmen in Hintergrund geht bei mir auch nicht. Im Laden Dialog wird immer noch das SerialComInstruments4 Verzeichnis 2 mal angezeigt. Wie kann ich das aktuelle Projekt per Kommandozeile laden? Frage: Ohne jetzt auf einen bestimmten Einsatzzweck abzuzielen, aber wäre es möglich, wenn ich verschiedene uC an verschiedenen Orten (nicht über LAN verbunden) habe: 1. Anzeige von Werten? Sollte gehen, da ja alles was auf dem UDP reinkommt, angezeigt wird, wenn es nicht an lokale IP gebunden ist. 2. Senden von Befehlen? Per broadcast im lokalen Netz, aber wie erreiche ich verschiedene "Aussenposten" übers Internet?
:
Bearbeitet durch User
Günter R. schrieb: > Diese DLL ändert sich ja wohl nicht mehr, ist ja, wenn ichs > richtig sehe, eine uralte Datei? Die war mal nötig für die allerersten Versionen und ist als Nostalgie drin geblieben. Wenn Du sie tatsächlich brauchst, einfach in den Programmordner kopieren. Sepp aus Hintertupfing schrieb: > Wäre es denkbar bei den Rundinstrumenten nur die Zeiger zu liefern > (am besten gerendert) und jeder kann sich seine eigene Scala dazu > platzieren? Sowas wäre als horizontal/vertikal Instrument möglich, aber nicht bei rund. Ich habe eine frei konfigurierbare Skala (auch transparent), die man z.B. neben einem Balkendiagramm platzieren kann. sand schrieb: > Ich habe jetzt die neue Version installiert, aber das Rahmen-Instrument > kann > nicht in den Vorder oder Hintergund gesetzt werden. Deckt weiterhin > unzugänglich die darunterliegende Objekte ab. Das kommt ja auch erst in der nächsten Version. Rainer M. schrieb: > Im Laden Dialog wird > immer noch das SerialComInstruments4 Verzeichnis 2 mal angezeigt. Da weiss ich jetzt erst mal auch nicht weiter da ich das Verhalten bei mir nicht reproduzieren kann. Rainer M. schrieb: > Wäre es nicht besser, zuerst die Grundfuntionalitäten zu machen und die > Bugs zu bereinigen, dass man seine Projekte auf das neue Format > umstellen kann und danach erst die Luxusdinger einbaut? Hm, ja. Aber da mogelt sich der Spieltrieb schon mal in den Vordergrund :) Rainer M. schrieb: > wäre es möglich, wenn ich verschiedene uC an verschiedenen Orten (nicht > über LAN verbunden) habe: > 1. Anzeige von Werten? Sollte gehen, da ja alles was auf dem UDP > reinkommt, angezeigt wird, wenn es nicht an lokale IP gebunden ist. Müsste gehen. Rainer M. schrieb: > 2. Senden von Befehlen? Per broadcast im lokalen Netz, aber wie erreiche > ich verschiedene "Aussenposten" übers Internet? Habe ich mir noch keine Gedanken drüber gemacht. Ich bin jetzt kein WLAN Experte. Vielleicht kann jemand was dazu sagen?
:
Bearbeitet durch User
Albert M. schrieb: > >> 2. Senden von Befehlen? Per broadcast im lokalen Netz, aber wie erreiche >> ich verschiedene "Aussenposten" übers Internet? > > Habe ich mir noch keine Gedanken drüber gemacht. Ich bin jetzt kein WLAN > Experte. Vielleicht kann jemand was dazu sagen? Die einzige Möglichkeit, die mir einfällt, wäre ein optionales Feld zur Angabe einer url bei den Dingern, die was an den uC schicken. Oder man definiert auch hier "Ziele", die man dann bei den Instrumenten auswählen kann. Besser für die Wartbarkeit.
:
Bearbeitet durch User
Rainer M. schrieb: >>> 2. Senden von Befehlen? Per broadcast im lokalen Netz, aber wie erreiche >>> ich verschiedene "Aussenposten" übers Internet? Ich kann mich erinnern, dass das mal bei mir funktioniert hat. Ich meine da No-Ip oder einen ähnlichen Dienst benutzt und auf meinem Router eine passende Weiterleitung eingerichtet zu haben. Einzelheiten bekomme ich jetzt aber nicht mehr zusammen.
:
Bearbeitet durch User
Heute kam mir noch eine Idee. Die Instrumente sind ja nicht mit ihrer Instrumentennummer und dem ihnen zugeordneten Kanal beschriftet, nur mit dem Namen, den der Benutzer ja verändern kann. Wäre es nicht nützlich, wenn es am unteren Fensterrand eine Statuszeile gäbe, in der ein Tooltip angezeigt wird, wenn man mit der Maus über ein Instrument streift? Etwa so wie bei den Menüsystemen, bei denen für Buttons deren Bedeutung/Funktion als Tooltip angezeigt wird. Zusätzlich evt. im Help-Menü eine Auflistung der Instrumente mit Typ, Instrumentennummer und zugeordnetem Kanal, und evt. so, daß man sie ausschneiden und dann drucken kann (durch Einfügen in einem Ascii-Editor).
Albert M. schrieb: > Neues Simple Graph Instrument > - Dient als einfachste Trend-Anzeige ohne Beschriftungen. > - Beliebig oft platzierbar. > - Vorschub wählbar (sehr schnell bis extrem langsam). Wie sind die Einheiten? Sekunden oder Millisekunden? Könntest Du das in der nächsten Version ins Einstellfenster mit reinschreiben? Und was bedeuten die "UpdateSteps"? Ist das ein zusätzlicher Teiler oder ein Darstellungs-Variator? Ansonsten funktioniert das Instrument sehr gut, abgesehen davon, daß ich 5 mal klicken mußte, bis eine freie Instrumentennummer gefunden wurde (aber das wurde ja oben schon mal angesprochen).
Albert M. schrieb: > Wichtig: > Einstell-Parameter Fenster wird jetzt über Doppelklick > auf das Instrument geöffnet. Das ist so für neu ins Projekt gezogene Instrumente. Aber diejenigen, die vorher schon da waren (wenn ich ein schon länger bestehendes Projekt geladen habe und dort jetzt hinzufüge), werden weiterhin mit Einfachklick geöffnet. Kann es sein, daß früher anders im Projektfile abgelegt wurde und die älteren/neueren Instrumente unterschiedlich angesprochen werden?
Günter R. schrieb: > Wie sind die Einheiten? Sekunden oder Millisekunden? Könntest Du das in > der nächsten Version ins Einstellfenster mit reinschreiben? Und was > bedeuten die "UpdateSteps"? Wie beschrieben: Albert M. schrieb: > Neues Simple Graph Instrument > - Dient als einfachste Trend-Anzeige ohne Beschriftungen Zur Orientierung: Update Rate pro Sekunde = 100/Interval Update Time Steps = Multiplik. Pixel Vorschub Damit ergeben sich (bei Update Steps = 1) folgende Werte: Interval = 1 ca. 100 Pixel Vorschub pro Sekunde 10 10 100 1 1000 1 Pixel Vorschub pro 10 Sekunden Kann ich in der nächsten Version auch in der Software umrechnen, anstatt Eingabe Interval dann Eingabe Pixel Vorschub pro Sekunde. Aber wie oben gesagt, dieses Instrument bleibt die einfachste Trend-Anzeige OHNE Beschriftungen, gedacht als Mini Anzeige zum Aufsatz On Top für andere Instrumente. Umfangreiche grosse Trendanzeigen mit ausführlichen Beschriftungen kommen demnächst. Günter R. schrieb: > Das ist so für neu ins Projekt gezogene Instrumente. Aber diejenigen, > die vorher schon da waren (wenn ich ein schon länger bestehendes Projekt > geladen habe und dort jetzt hinzufüge), werden weiterhin mit > Einfachklick geöffnet.> > Kann es sein, daß früher anders im Projektfile abgelegt wurde und die > älteren/neueren Instrumente unterschiedlich angesprochen werden? Die Software ist Alpha Stadium und noch nicht für den Produktiv-Einsatz geeignet. Es können sich viele Dinge noch laufend grundlegend ändern. Dazu gehört auch das Abspeichern/Laden eines Projektes. Bekommen Instrumente neue Eigenschaften, so sind ältere Projektfiles meistens nicht mehr zu gebrauchen. Günter R. schrieb: > Ansonsten funktioniert das Instrument sehr gut, > abgesehen davon, daß ich 5 mal klicken mußte, bis eine freie > Instrumentennummer gefunden wurde Leider kann ich das hier noch nicht reproduzieren. Abgeshen davon werden intern keine freien Nummern gesucht, sondern ein Instrument wird dynamisch erst beim Klick in der Tool-Box erzeugt und bekommt dann eine Nummer wie folgt: Nummer = (Anzahl bereits erzeugter Instrumente)+1 In späteren Versionen wird das noch optimiert, indem auch Nummern zwischenzeitlich gelöschter Instrumente verwendet werden.
:
Bearbeitet durch User
Albert M. schrieb: > Nummer wie folgt: Nummer = (Anzahl bereits erzeugter Instrumente)+1 > In späteren Versionen wird das noch optimiert, indem auch Nummern > zwischenzeitlich gelöschter Instrumente verwendet werden. Okay, damit wird das Verhalten verständlich. Denn in meinem Projekt beginnen die Instrumentennummern bei 5 (vorher hatte ich rumgespielt und geholt und gelöscht). Vielleicht würde folgender Algorithmus das Problem lösen (gibt sicher auch andere bzw. noch bessere): Nummer = (Anzahl bereits erzeugter Instrumente)+1; while (AlreadyUsed(Nummer)) { Inc(Nummer); } Damit wird die nächste freie Instrumentennummer gesucht. Wie man Lücken füllt, könnte man separat überlegen; das ist nur mal eine schnelle Lösung ("quick & dirty").
Angehängte Dateien:
-
MovingScala.png
17 KB -
MovingScala2.png
25 KB
Nochmal zum SimpleGraph Instrument und dessen nicht vorhandenen Skala. Wer für dieses Instrument unbedingt eine Skala/Messwertanzeige möchte, kann folgendes probieren: Eine coole Moving-Anzeige kann man einem SimpleGraph z.B. einfach mit einem FlexMeter Instrument im Transparent-Modus zufügen, sie Bild oben. Die Schriftgrösse dabei möglichst klein wählen, damit es optisch passt.
:
Bearbeitet durch User
Angehängte Dateien:
-
Screenshot1.png
120 KB
Heute Nacht habe ich mal das Programm mit dem SimpleGraph an meiner Heizungsanlage laufen lassen; da kann man wunderbar das Verhalten des Kessels und der Boilerladung sehen; über die Nacht kühlt der Boiler etwas aus, weil er dann nicht nachgeladen wird und das Heizen runtergefahren ist und die Heizzyklen somit verlängert sind. Um 6.00 Uhr startet das Boilerladen und die Heizzyklen werden wieder kürzer, bis der Boiler wieder seine Tagestemperatur erreicht hat, dann verlängern sich die Heizzyklen wieder. Die Boilertemperatur ist wegen der Integerdarstellung nur sehr grobstufig dargestellt; Versuche, den Multiplikator auf 10 zu setzen, hatten immer einen Programmabsturz zur Folge. Wie könnte ich das vermeiden?
Günter R. schrieb: > Versuche, den Multiplikator auf 10 zu setzen, > hatten immer einen Programmabsturz zur Folge. Das hängt mit dem schon beschriebenen Bug bei der Verkleinerung des Instruments zusammen und wird in der nächsten Version behoben.
Angehängte Dateien:
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 09
Trend Instrument zugefügt.
- 1 bis 4 Analog Kanäle
- Linenbreite und Farbe einzeln wählbar
- Achsen getrennt skalierbar und zuschaltbar
- Maximale Record-Anzahl 100.000 je nach PC RAM auch erheblich mehr
- Interval einstellbar von 0,1 bis 600 Sekunden
- Wichtig:
Start/Stop über COM Button/Led links oben.
Die Messwerte dürfen die Min/Max Werte-Einstellung
nicht übersteigen.
- Folgende Erweiterungen in den kommenden Releases:
Speichern, Laden, Drucken, Bewegen in der kompletten Aufzeichnung.
Ein FastTrend Instrument für hohe Erfassungsraten und volle
Pan/Zoom Möglichkeiten ist in Vorbereitung
Uhr mit Sekundenzeiger unter Design-Instruments zugefügt.
Bei Klick auf das Rahmen-Instrument kann gewählt werden, ob es im
Vorder- oder Hintergrund angezeigt wird. Wenn im Hintergrund, bleiben
alle Instrumente im Rahmen klickbar.
HighSpeedTimer Priorität erhöht, um Aussetzer beim Generator-Betrieb
durch User Aktionen zu vermindern.
Bug im Simple Graph Instrument behoben: Bei Verkleinerung wurde unter
bestimmten Umständen ein Run-Time Error ausgelöst.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, die neue Trendanzeige ist ganz super! Das ist ein schönes Ostergeschenk, das Du uns da gemacht hast. Sehr herzlichen Dank! Ich bin gerade schon am Testen (wieder an meiner Heizungsanlage). In Deinem Vorschaubild sind sehr schön die Zeitmarken zu sehen; bei mir sehe ich solche (noch) nicht, es läuft aber auch erst seit 15 Minuten. Kommen die Zeitmarken evt. erst dann ins Bild, wenn die Aufzeichnung weit genug fortgeschritten ist? Meine Update-Rate (bzw. die Rate, mit der das 1-Wire-Thermometer seine 4 Werte sendet) ist ca. 20 Sekunden, also sehr langsam. Ich habe "Intervall" jetzt mal probeweise auf "10 Sek." eingestellt. Da erscheint schon eine schöne Linie. Ist es mit dem Sampling so, daß die Trendanzeige, wenn der Intervallzeitpunkt zur Anzeige gekommen ist, den jeweils letzten empfangenen Wert vom COM-Port anzeigt und davor angekommene ingnoriert (kann ja eigentlich nicht anders sein)? Das hieße in meinem obigen Fall, daß immer zweimal der gleiche Wert angezeigt wird, da meine Daten so langsam eintrudeln. Und wie ist das Starten der Anzeige mit dem COM-Button zu verstehen? Startet die Anzeige, wenn COM grün wird (durch Anklicken) und stoppt, wenn COM inaktiv ist? (Dann würden natürlich auch die Trendmeter nicht aktualisiert werden).
Angehängte Dateien:
-
Screenshot4.png
110 KB
Günter R. schrieb: > Kommen die Zeitmarken evt. erst dann ins Bild, wenn die Aufzeichnung > weit genug fortgeschritten ist? Diese Frage hat sich schon selbst beantwortet: es ist so (ein bißchen Geduld hätte mir geholfen ...)
Hi, wenn du die Rundinstrumente jetzt noch so hinbekommst wie deine "Design Uhr" dann Hut ab. (ich gebe die Hoffnung auf meine Breitling Uhr noch nicht ganz auf ;-)
Ich habe noch einen Fehler beim Laden eines Projektes in dem Trend Instrumente verwendet werden entdeckt. Jedes Trend Instrument belegt immer 4 Instrumenten Nummern, leider kommt da beim Projekt-Laden was durcheinander. Auch werden manchmal willkürlich Farbzuordnungen vertauscht. Nach Ostern gibt es dazu die Korrektur. Günter R. schrieb: > Ist es mit dem Sampling so, daß die Trendanzeige, wenn der > Intervallzeitpunkt zur Anzeige gekommen ist, den jeweils letzten > empfangenen Wert vom COM-Port anzeigt und davor angekommene ingnoriert > (kann ja eigentlich nicht anders sein)? Es werden alle ankommenden Werte vom Com Port immer an alle Instrumente geleitet, also auch an Trend. Die Intervalzeit von Trend bestimmt das Vorrücken auf dem Display. Wenn Werte zwischen den Intervall-Zeitpunkten ankommen, werden alle diese Werte beim Auftreten des Intervallzeitpunktes angezeigt, natürlich genau auf der X-Stelle des Intervallpunktes. Beispiel: Es kommen die Werte 30, 10 und 50 zwischen den Intervallpunkten an, dann wird zum Intervalzeitpunkt eine vertikale Linie von 10 nach 50 gezeichnet. Somit gehen damit nicht alle Werte verloren, man sieht damit zumindest die Maxima und Minima der zwischen den Intervallen aufgetretenen Werte. Übrigens wird die laufende Anzeige mit Leerraum unterbrochen, wenn die Intervallzeit während der Erfassung geändert wird, um die Diskontinuität in der Anzeigensklalierung zu markieren.
:
Bearbeitet durch User
Sepp aus Hintertupfing schrieb: > ich gebe die Hoffnung auf meine Breitling Uhr noch nicht ganz auf ;- Die kannst Du Dir jetzt schon zurecht zimmern :) Die Clock ist transparent, also kannst du ein Breitling Design Bild mit dem Lines-Instrument laden und darüber die Clock platzieren.
Angehängte Dateien:
Ein Auslastungstest zeigt sehr gute Werte. Die durchschnittliche Zeit für das Anzeigen der Instrumente im Bild oben beträgt für einen Messwert-Zyklus nur 14 µs (siehe Anzeige links unten). Der benutzte PC: i7 Prozessor und Win7. Es kommen 1000 Messwerte pro Sekunde an. Damit bleibt viel Zeit auch für kommende umfangreichere Operationen.
:
Bearbeitet durch User
Angehängte Dateien:
Hi an alle. Ich habe jetzt mal versuchsweise auf die 4er Version umgestellt. Ist ja schon fast alles da, was ich brauche. Kein vergleich zu vorher. Folgende Punkte sind mir aufgefallen, die zu verbessern wären: - Schalter/Taster: Man sollte die LED im Taster genauso ansteuern können, wie die anderen LED. Man kann dazu sogar den gleichen Kanal nehmen. Wenn man als Taster Konfiguriert hat und im unteren Bereich klickt, wird 0 statt 1 ausgegeben. -Vertikalmeter: Skalierungsfaktor geht noch nicht (bräuchte -1). Skala kann man bei vorhandenem Instrument nicht umstellen, dass oben 0 und unten -100 ist. Bei neuen geht es. Ideal wäre es auch, wenn man den Skalenzeiger und den Hintergrund ansteuern könnte, wie eine LED. Bsw. bei Alarmwerten rot blinkend. -Instrument #82 fehlt noch, mit Möglichkeit, den Regler vom uC aus zu stellen ;-)
:
Bearbeitet durch User
@Rainer M.: Wie bekommst Du denn die Screenshots mit so kleinen Dateigrößen hin? Meine sind viermal so groß.
Im png Format. Hab Dropbox so eingestellt, dass ein Schreenshot automatisch gespeichert wird. Dann hab ich es einfacher, sie hochzuladen.
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 10 Maintenance Release Fehler beim Laden eines Projektes behoben. Beim Trend-Instrument werden die Kanäle nun richtig zugewiesen. Alle anderen oben angesprochenen Verbesserungswünsche kommen in der nächsten Woche. Auf meinen Web-Seiten wurde die neue Version 4 mit dem jeweilig aktuellem Release eingefügt. Der Release-Check innerhalb des Programm kommt mit der nächsten Version. Ich wünsche euch frohe Ostertage! Gruss Ulrich Albert http://www.serialcominstruments.com/
Angehängte Dateien:
Nochmal ein Timing Test für einen Anzeigenzyklus: Nach Ausschalten der Compiler I/O Prüfung ergibt sich im Programm ein Zeitbedarf für das Updaten der Instrumentenwerte (obiges Bild) von nur 22 µs pro Zyklus. Desweiteren ist mir noch ein Bug aufgefallen: Bei nachträglicher Platzierung von mehr als einem Trend Instrument gibt es bei allen weiteren Trend Instrumenten unter Umständen manchmal keine Anzeige. Notlösung: Anzeige Starten mit COM links oben Aus/Einschalten. Ich arbeite dran.
:
Bearbeitet durch User
Albert M. schrieb: > Bei nachträglicher Platzierung von mehr als einem Trend Instrument gibt > es bei allen weiteren Trend Instrumenten unter Umständen manchmal keine > Anzeige. Ja, so etwas habe ich gerade eben festgestellt; ich habe - auf 2 Registerkarten - insgesamt 4 Trend-Instrumente laufen; beim ersten, das aber schon längere Zeit da ist, sehe ich nur einen waagrechten Strich. Habe jetzt mal COM aus/eingeschaltet. >- Wichtig: > Start/Stop über COM Button/Led links oben. > Die Messwerte dürfen die Min/Max Werte-Einstellung > nicht übersteigen. Was passiert denn, wenn die Meßwerte doch größer sind? Stürzt das Programm dann ab? Das habe ich allerdings nicht beobachtet. Oder könnte die waagrechte Linie mit einer Bereichsüberschreitung zu tun haben?
Günter R. schrieb: > Was passiert denn, wenn die Meßwerte doch größer sind? Stürzt das > Programm dann ab? Nein, stürzt nicht ab :) Die von mir benutzte Componente zeigt dann ein irreguläres Verhalten indem bei Überschreiten des Anzeigerahmens (Y Min/Max-Werte) die Linien fälschlicherweise mitten durch das Display gezeichnet werden. Ich werde da später eine eigene Bereichsüberprüfung einbauen und alle Werte die die Anzeigenskalierung überschreiten einfach auf Max bezw. Min setzen. Für das Starten/Stoppen aller SimpleGraph und Trend-Instrumente werde ich mir noch was sinnvolles einfallen lassen.
:
Bearbeitet durch User
Günter R. schrieb: > ich habe - auf 2 > Registerkarten - insgesamt 4 Trend-Instrumente laufen; beim ersten, das > aber schon längere Zeit da ist, sehe ich nur einen waagrechten Strich. > Habe jetzt mal COM aus/eingeschaltet. Ich habe jetzt mal dieses "eingefrorere" Trend-Instrument gelöscht und neu erstellt - jetzt funktioniert es wieder einwandfrei. Es ist wohl - wie du schon mehrfach erwähnt hast - problematisch, mit früheren Versionen erstellt Projekte in neuen Versionen zu laden und auszuführen. Sollte man Projekte bei neuen Programmversionen immer neu erstellen? Ich habe gesehen, daß in den Projekt-Ordnern einige ini-Files Binärcode enthalten. Ist das Programmcode? Das würde erklären, warum sich damals "alte" Instrumente noch mit Einfach-Klick konfigurieren ließen, wogegen neuere Instrumente gleichen Typs (die erst in der neuen Progrtammversion hinzugefügt wurden) einen Doppelklick benötigten (ich spreche hier vom Temp-Meter, nicht Trend).
Günter R. schrieb: > Es ist wohl - wie du schon mehrfach erwähnt hast - problematisch, mit > früheren Versionen erstellt Projekte in neuen Versionen zu laden und > auszuführen. Sollte man Projekte bei neuen Programmversionen immer neu > erstellen? Solange die Software noch im Alpha Stadium ist ja (siehe unten). Günter R. schrieb: > Ich habe gesehen, daß in den Projekt-Ordnern einige ini-Files Binärcode > enthalten. Ist das Programmcode? Nein, das ist die Komplette Instrumentenstruktur der jeweiligen Darstellungsseite. Das ist auch der Grund, warum man bei neuen Programmversionen nicht die alten Konfigurationsdaten laden sollte. >Das würde erklären, warum sich damals > "alte" Instrumente noch mit Einfach-Klick konfigurieren ließen, wogegen > neuere Instrumente gleichen Typs (die erst in der neuen Progrtammversion > hinzugefügt wurden) einen Doppelklick benötigten (ich spreche hier vom > Temp-Meter, nicht Trend). Das sind so Dinge die sich im Alpha Stadium ändern können. Generell wird nun mit Doppelklick konfiguriert, Ausnahme die Trend Instrumente SimpleGraph und Trend, welche bereits auf Einfach-Klick reagieren. Da ich die Software von Grunde auf neu geschrieben habe und vom alten Code so gut wie nichts verwenden konnte, bin ich froh dass bis dato nur so wenige Ungereimtheiten und Fehler aufgetreten sind. Ich freue mich, dass wenigstens einige kontinuierlich Bug Reports geben.
:
Bearbeitet durch User
l-hase schrieb: > möchte meine ersten 2 Projekte mit dieser Software vorstellen > vielleicht kann ich damit andere auch ansporen. > > l-hase Hi, wie kann man so schöne Bildchen zeichnen, wie deine Leitungen? welchen SW benutzt du?
fms schrieb: > wie kann man so schöne Bildchen zeichnen, wie deine Leitungen? welchen > SW benutzt du? Die sind mit einem Freeware Icon-Editor erstellt. Icon Editor deshalb, weil man da in ein Raster zeichnen und damit die Linien exakt positionieren kann. Warscheinlich geht das auch mit anderen Draw Programmen, aber das war für mich die einfachste Lösung. Das Bild dann mit transparentem Hintergrund im gif-Format speichern, z.B. mit IrfanView. Frag mich jetzt nicht wie der Icon-Editor heisst, da ich über die Ostertage nicht am meinem eigenem PC sitze. Oder meinst Du die Rohr-Leitungen die bei der alten Programmversion als Hintergrundbild gezeigt wurden? Das sind aus einem gekauften Set (ich glaube die haben so ca. 15 Euro gekostet).
:
Bearbeitet durch User
Ja, die Rohrleitungen und Anschlüsse. laß mich wissen, welche SW das ist. Ansonsten schöne Osterfeiertage.
FM S. schrieb: > Ja, die Rohrleitungen und Anschlüsse. > laß mich wissen, welche SW das ist. Die gibt es hier für 5,95 Euro. Icons Pipes. http://www.iconshow.de/shop/show_product.php?cPath=60&products_id=137 Und die hier für die Hausautomation sehen auch gut aus: http://www.iconshow.de/shop/show_product.php?cPath=60&products_id=168 War lange nicht mehr auf der Seite. Da werde ich nochmal was kaufen und zwar den Icon Design Pack und die Hausautomation: http://www.iconshow.de/shop/show_product.php?cPath=59&products_id=184 Wenn es mehrere interessiert, würde ich die Rohrleitungen und die Hausautomation als zusätzliche Designs in SerialComInstruments 4 integrieren.
:
Bearbeitet durch User
Albert M. schrieb: > Wenn es mehrere interessiert, würde ich die Rohrleitungen und die > Hausautomation als zusätzliche Designs in SerialComInstruments 4 > integrieren. Hallo Albert, wenn ich mir diese "ICON Seiten" so anschaue da kann man ja so richtig gamsig werden. Wie sieht das mit der Lizensierung aus ? die Dinger kosten ja was. Müssen wir als "Endkunden" da zusätzlich was abdrücken? Grüsse Latschensepp
Sepp aus Huntertupfing schrieb: > wenn ich mir diese "ICON Seiten" so anschaue da > kann man ja so richtig gamsig werden. > Wie sieht das mit der Lizensierung aus ? die Dinger kosten ja was. > Müssen wir als "Endkunden" da zusätzlich was abdrücken? Nein, siehe hier: http://www.iconshow.de/shop/information.php?pages_id=12 Wenn ich die gekauft habe und in SerialComInstruments 4 verwende, hat der Benutzer meines Programms nichts mit der Lizenz zu tun. Das Gleiche gilt ja auch für alle anderen gekauften Componenten im Programm. Er darf natürlich nicht diese Icons aus SerialComInstruments kopieren und selbst benutzen. Das werde ich dann noch zusätzlich in den Nutzungsbedingungen meines Programms vermerken.
:
Bearbeitet durch User
Albert M. schrieb: > sand schrieb: >> Beim Laden oder Speichern ist der Ordner SerialComInstruments4 doppelt >> vorhanden > > Vielleicht hast Du mal vergessen die beigefügte Deinstallations > UnInstall.Exe zu benutzen. Dieses Verhalten habe ich heute auf meinem Win7-PC auch festgestellt (ich habe wohl früher nicht darauf geachtet, vielleicht wars schon länger so), bei der neuesten SerComInst-Version; die Vor-Versionen hatte ich immer mit dem Uninstall aus der Windows-Programmverwaltung vor einem Update deinstalliert. Die doppelten Eintraäge (einmal mit Groß/Kleinschreibung, einmal nur Kleinschreibung) haben im Ordner-Icon ein kleines Vorhängeschloss drin, das ich bei keinem anderen Ordner-Icon gesehen habe. Was bedeutet das? Hat das mit Eigentümer-Rechten zu tun? Noch etwas anderes fiel mir schon mehrfach auf: beim Starten der Visualisierung (Klick auf den COM-Button) meldete SerComInst, der COM-Port sei schon für ein anderes Programm blockiert, und es wird nicht online; aber das geschieht ja direkt nach dem Einschalten des PC's, da habe ich kein anderes Programm gestartet. Wenn icgh dann SerComInst beende und z.B. HTerm aufrufe, kann ich auch dort nicht auf COM1 zugreifen, erst wieder nach Reboot des PC, dann gehts meistens (einmal mußte ich ein weiteres Mal rebooten). Wie kann man denn herausfinden, welches Programm den COM1 angeblich in Beschlag hat? Gehts mit Bordmitteln?
Günter R. schrieb: > Die doppelten Eintraäge (einmal mit > Groß/Kleinschreibung, einmal nur Kleinschreibung) haben im Ordner-Icon > ein kleines Vorhängeschloss drin, das ich bei keinem anderen Ordner-Icon > gesehen habe. Das hat nichts mit meiner Software zu tun, sondern ist eine schwer nachzuvollziehende Eigenschaft der Schattenkopieerstellung von Windows. Wenn Du im Explorer unter Extras/Ordneroptionen/Ansicht den Punkt "Ausgeblendete Dateien, Ordner oder Laufwerke nicht anzeigen" markierst, dürfte der Spuk verüber sein. Vieleicht kann ein Windows Experte was dazu sagen. Versuche mal auf z.B. Laufwerk D zu speichern, dann wird Windows wahrscheinlich nichts weiteres anlegen. Günter R. schrieb: > beim Starten der > Visualisierung (Klick auf den COM-Button) meldete SerComInst, der > COM-Port sei schon für ein anderes Programm blockiert Kann ich auf keinem meiner PCs nachvollziehen. Schau mal unter Computerverwaltung/Gerätemanager nach was bei Dir unter Anschlüsse Com eingetragen ist. Welches Programm blockiert kann man aber so nicht feststellen.
:
Bearbeitet durch User
Albert M. schrieb: > Das hat nichts mit meiner Software zu tun, sondern ist eine schwer > nachzuvollziehende Eigenschaft der Schattenkopieerstellung von Windows. > Wenn Du im Explorer unter Extras/Ordneroptionen/Ansicht den Punkt > "Ausgeblendete Dateien, Ordner oder Laufwerke nicht anzeigen" markierst, > dürfte der Spuk verüber sein. Vieleicht kann ein Windows Experte was > dazu sagen. > Versuche mal auf z.B. Laufwerk D zu speichern, dann wird Windows > wahrscheinlich nichts weiteres anlegen. Sorry, ich war zu sparsam mit meinem Bericht. Ich spreche nicht vom Projekt-Ordner, in dem ich Projekte speichere; dort wird nichts doppelt angezeigt; sondern der Programminstallationsordner "C:\SerComInstruments4" wird nochmals in Kleinschrift angezeigt, aber - wie auch schon berichtet wurde - nicht im Explorer und auch nicht im TotalCommander, sondern ausschließlich im Öffnen-Dialog von SerComInst; allerdings ist das total uninteressant, denn von dort will man ja nichts laden; ich berichte das nur der Vollständigkeit wegen, daß auch auf meinem PC dieser Effekt zu sehen ist. Ganz klar hat das nichts mit Deinem Programm zu tun, allenfalls mit der Windows-Komponente, die halt von Delphi zum Öffnen aufgerufen wird. An der kannst Du ja nichts drehen, und man sollte das Thema auch ad acta legen, weils unwichtig ist. Das mit dem COM-Port ist eigenartig; im Gerätemanager ist alles okay, "Das Gerät ist betriebsbereit.", auch kein gelbes Fragezeichen oder sonstwas komisches dort zu sehen. Sollte man auch nicht zu hoch hängen; ich beobachte es weiter; nach Reboot funktioniert ja alles bestens. Vielleicht wird sporadisch doch irgend ein portbelegendes Programm geladen. Ich beobachte das weiter, wenns wieder passiert, vielleicht finde ich eine Ursache. Noch einen schönen restlichen Ostermontag!
Angehängte Dateien:
Preview der demnächst kommenden neuen Instrumente. Ereignisanzeige Mit freiem Text vom MC, Anzeige Clear auch vom MC. Optional Uhrzeit oder Datum+Zeit Anzeige. Aktuelles Ereignis steht immer oben. Slider, sendet seinen Wert zum MC. Frei konfigurierbar wie bei Analog Meter. Feineinstellung über Mouserad oder Tastatur. Ein- oder mehr-dimensionales Button-Feld. Beliebige Array-Grösse, z.B. 8 x 12. Button Höhe und Breite beliebig, jedoch für alle gleich. Schickt Index-Nr. und Status zum MC. MC kann Text und Farbe jedes Button ändern. Eignet sich auch gut für indizierte DIP-Schalter. Mathematik/Logik Instrumente (nur bei Parametrierung sichtbar). Beliebig komplexe Ausdrücke (incl. Klammerebenen). 1 oder 2 Eingangs-Kanäle und 1 Ausgangs-Kanal. Der Ausgangs-Kanal kann von weiteren Instrumenten genutzt oder zum MC geschickt werden. DIP-Schalter Text, Höhe und Breite beliebig. Schickt Status an MC. Kann vom MC gesetzt werden. Timer / Count-Down Instrument. Kann über Parametrierung oder vom MC gesetzt werden. Das Timer- oder OnCountDown Ereignis kann zum MC gesendet werden oder zu einem passenden Instrument (z.B. LED, Button-Array).
:
Bearbeitet durch User
Angehängte Dateien:
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 11 Change Log: Text Instrument, zeigt vom MC gesendeten Text an. - Syntax: #kMt< wobei k=Kanal (1..999) und t=Text - Optional Uhrzeit oder Datum+Zeit Anzeige. - Aktuelles Ereignis steht immer oben. - Text löschen vom MC: Senden des Strings "ClrText". Beispiel #22MClrText< Eingabe Box Instrument - Zur direkten Werte-Übermittlung an den MC, COM und LAN/UDP - Akzeptiert numerische oder alphanumerische Eingaben - Bei Klick auf den S-Button im Instrument wird der Wert als String mit der Kanal-Identifikation gesendet. Syntax: #kMs< wobei k=Kanal-Nummer (1..999) und s=Wert - Es kann optional mit CRLF gesendet werden. Menue Button "Start/Stop Trends" - Startet/Stopt alle Trend Instrumente Check For New Version - Unter Menue/Hilfe aktiviert. Diverse Bugs behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Eine Bemerkung: Text Instrument -- Aktuelles Ereignis steht immer unten.
Kleine Anregung: Kann man nicht im Terminalfenster die UDP Daten anzeigen lassen und Befehle wegschicken, genauso wie von der seriellen Schnittstelle? Oder hab ich da was übersehen?
sand schrieb: > Eine Bemerkung: > Text Instrument -- Aktuelles Ereignis steht immer unten. Hatte ich für einen Speed Test gemacht (ist schneller) und es versehentlich so stehen gelassen. Wird auf "aktueller Text immer oben" korrigiert. Rainer M. schrieb: > Kann man nicht im Terminalfenster die UDP Daten anzeigen lassen und > Befehle wegschicken, genauso wie von der seriellen Schnittstelle? Oder > hab ich da was übersehen? Das Terminalfenster ist z.Z. nur für Daten der COM Schnittstelle. Könnte ich auf UDP erweitern.
Angehängte Dateien:
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 12 Neues universelles Button Panel Instrument - Eine beliebige Anzahl Buttons kann auf Panels erzeugt werden. Dabei ist jedes Panel ein eigenes Instrument. - Jedem Button Panel kann ein eigener Kanal zugewiesen werden. - Grössse und Höhe der Button einstellbar, für alle gleich. - Jeder Button kann frei Beschriftet werden. Die Beschriftung ist auch nachträglich änderbar. - Fontgrösse und Farbe wählbar, für alle gleich. - Bei Klick auf einem Button wird an COM und UDP geschickt: Syntax: #kMb< wobei k=Kanal und b=Button-Nummer - Vom MC aus kann die Farbe jeden Buttons geändert werden: Syntax: #kMfb< wobei k=Kanal, f=Farb-Nummer, b=Button-Nummer Farb-Nummer: 0=black, 1=silver, 2=gray, 3=red, 4=yellow, 5=green, 6=blue, 7=lime, 8=fuchsia, 9=MoneyGreen Bedienung Button Panel Instrument - Bei der Platzierung wird ein leeres Panel erzeugt. Doppellick auf den Panel-Rahmen öffnet die Parametrierung. - Im Design-Mode muss das Panel am Rahmen angefasst werden. Horizontale, vertikale, sonstige Ansicht mit Mouse-Ziehen. Bug Text Instrument Einfügerichtung korrigiert. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Button-Leiste probiert, vom MC zum PC Farbwechsel ohne Funktion. Im Terminal kommen die Daten an.
Angehängte Dateien:
Dann hast Du wohl vergessen dem Button Panel mittels "Save" die
Kanal-Nummer mitzugeben :)
Gerade getestet - alles funktioniert, siehe Bild.
Syntax: #kMfb< wobei k=Kanal, f=Farb-Nummer, b=Button-Nummer
Farb-Nummer:
0=black, 1=silver, 2=gray, 3=red, 4=yellow, 5=green,
6=blue, 7=lime, 8=fuchsia, 9=MoneyGreen
:
Bearbeitet durch User
Angehängte Dateien:
-
Doppelbefehl.PNG
1 KB -
Absturz_beim_Oeffnen.PNG
20 KB
Mit etwas Mühe funktioniert die Button-Leiste, - ab und zu mal. Vorausgesetzt, das beim Neuöffnen kein Absturz kommt, die Buttons jedesmal neu Installiert werden und im Bascom Quellcode der Printbefehl doppelt ausgeführt wird. Im Terminal wird der Einzelbefehl auch erkannt. Die Instrumentennummer werden oft willkürlich vergeben. zB. beim Aufruf sagt Nr. 46 ist schon vergeben, dann kommt Nr. 47, wird angenommen, später erscheint im Feld doch Nr. 46 ???????
Angehängte Dateien:
-
Rahmen.PNG
818 Bytes
Dieser Rahmen , einmal nach hinten gesetzt kann ich nicht mehr löschen.
Anbei eine neue Test-Version SerialComInstruments 4 Alpha 13 Ich hoffe, damit sind erstmal die schwerwiegensten Bugs beseitigt, so dass das Button Panel voll funktionsähig ist. sand schrieb: > Dieser Rahmen , einmal nach hinten gesetzt kann ich nicht mehr löschen. Kann ich z.Z. nicht nachvollziehen, ich kümmer mich aber drum. Hast Du beachtet, dass man nur im Run-Mode löschen kann? sand schrieb: > Fehlermeldung beim Schliessen. COM war im Betrieb. Hatte vergessen vor dem Beenden COM immer zu schliessen. sand schrieb: > sagt Nr. 46 ist schon vergeben Beeinflusst den normalen Ablauf nicht, versuche es aber zu korrigieren. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
-
Neu_geoeffnet.PNG
1,3 KB -
neu_installiert.PNG
1,3 KB
jetzt mit alpha_13 probiert. Programm geöffnet, Buttons ohne Funktion, Terminal zeigt die Befehle an. Button gelöscht, neu aufgesetzt, es funktioniert. Gespeichert, Programm geschlossen, dann geöffnet, Buttons ohne Funktion! Den Rahmen habe ich natürlich in Run Mode versucht zu löschen. Ich zeigte aber in Design Mode weil so ist sichtbar, das der Zugriffsrahmen nicht aktiv ist. Vielleicht hinter den Raster geschoben wurde.
Ich habe jetzt den Fehler gefunden: Alle Ereignisse werden in die ini-Files geschreiben, nur das OnButtonClick Ereignis vom Button Panel nicht. Auf die Schnelle kann ich jetzt den Grund nicht finden, da die Internas der ini-File Erzeugung kompliziert sind. Leider kann ich erst nächste Woche weitermachen.
Hallo Albert, noch eine Bemerkung, wenn ich auf eine Instrumentbeschriftung klicke (einmal), egal welche, wird immer der Button Editiermaske Nr.46 aufgerufen. Gruss sand
Das Speichern und Laden funktioniert jetzt auch mit den Button Panels incl. des ButtonClick Ereignisses. Ich versuche Morgen noch kurz ein neues Build zu machen, kann es aber nicht versprechen. Ansonsten nächsten Dienstag.
:
Bearbeitet durch User
Dann wünsche ich schönes Wochenende. Es lenzt!
Hallo Albert. Ich verfolge schon eine ganze Weile Dein Projekt. Ich muss Dir allen erdenklichen Respekt für Deinen unermüdlichen Einsatz ausprechen. Genau diese Software ermöglicht Hobby-Programmierer von MC´s wie ich einer bin, eigene Projekte zu visualisieren, zu messen und zu steuern. Ich hoffe Du hast noch viel Freude daran uns mit Deinem Projekten zu bereichern.
Anbei eine neue Version SerialComInstruments 4 Alpha 14 ..und Danke für euren Zuspruch! Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert, das mit dem Button Panel ist ne tolle Sache, da man direkt über die Buttonfarbe schon den Zustand sieht. Dann braucht man keine LED mehr dranbauen. Welches ist Farbenummer der Originalfarbe des Buttons? Gibt es auch eine Blink-Option wie bei den Einzel-LED? LED: Die Led gehen nicht grösser als 80x80. Ich hatte vor, eine LED richtig gross zu machen und hinter entsprechende Instrumente als Hintergrund zu legen. Und dies dann bei Alarm rot blinken zu lassen. Geht das irgendwie? Digitale "7-Segment-Anzeigen" Wann sind die in der Version 4 verfügbar? Momentan behelfe ich mit mit dem Textfeld auf einzeilig. Sieht halt nicht so toll aus :-(
Rainer M. schrieb: >Digitale "7-Segment-Anzeigen" >Wann sind die in der Version 4 verfügbar? Momentan behelfe ich mit mit >dem Textfeld auf einzeilig. Sieht halt nicht so toll aus :-( Da kannst du behelfsmäßig aus Tankinstrument brauchbare Digianzeige basteln. Siehe oben letztes Bild. Bietet sogar mehr als...
Angehängte Dateien:
Es gibt noch einen Fehler beim Laden von Projekten, in denen Trend Instrumente vorkommen. Ist in der nächsten Version behoben. Ausserdem mache ich meine Debug-Ansicht der Instrumente verfügbar (siehe Bild). Diese ist nach jeder Spalte sortierbar. Alle Instrumenten Nummern, auch bereits gelöschte (mit x gekenzeichnet), werden aufgelistet. Rainer M. schrieb: > Welches ist Farbenummer der Originalfarbe des Buttons? Für die Standard Button Farbe gibt es in der nächsten Version einen zusätzlichen Button. Rainer M. schrieb: > Gibt es auch eine Blink-Option wie bei den Einzel-LED? Nein, geht bei diesen Componenten nicht. Rainer M. schrieb: > Die Led gehen nicht grösser als 80x80. Ich hatte vor, eine LED richtig > gross zu machen und hinter entsprechende Instrumente als Hintergrund zu > legen. Und dies dann bei Alarm rot blinken zu lassen. Geht das > irgendwie? Die max. Grösse der LED ist 80 und lässt sich nicht ändern. Wenn Du so ein riesiges Alarm Element brauchst, lass ich mir dafür was anderes einfallen. Rainer M. schrieb: > Digitale "7-Segment-Anzeigen" > Wann sind die in der Version 4 verfügbar? Kurzfristig kommen weitere Anzeigen.
:
Bearbeitet durch User
Brauchen tu ich das nicht, ich dachte nur, das könnte mal praktisch sein, den ganzen Hintergrund blinken zu lassen. So bei ner Kernschmelze oder so ;-)
Albert M. schrieb: > Es gibt noch einen Fehler beim Laden von Projekten, in denen Trend > Instrumente vorkommen. Ist in der nächsten Version behoben. Hallo Albert, ja, das habe ich gemerkt, daß einzelne Trends nicht immer funktionieren nach einem Programmstart und Laden des Projekts, oder auch mal, daß erst nach z.B. 3 Stunden Daten angezeigt werden, davor eine gerade Linie. Die Trendanzeigen sind für meine Heizungssteuerung bzw. Überwachung sehr interessant. Da möchte ich fragen, ob es geplant ist, daß diese mal einen Rollbalken bekommen, sodaß man Vergangenes wieder reinrollen kann (Oder gibts das schon? War geschäftl. unterwegs und bin erst heute wieder online, hatte zuletzt Alpha10 getestet.).
Günter R. schrieb: > Die Trendanzeigen sind für meine Heizungssteuerung bzw. Überwachung sehr > interessant. Da möchte ich fragen, ob es geplant ist, daß diese mal > einen Rollbalken bekommen, sodaß man Vergangenes wieder reinrollen kann > (Oder gibts das schon? Das würde ich eher über eine Datenbank machen, die unabhängig auf einem Server läuft, damit der PC nicht dauernd laufen muss. Ausserdem bleiben die Daten dann dauerhaft gespeichert.
Rainer M. schrieb: > Das würde ich eher über eine Datenbank machen, die unabhängig auf einem > Server läuft, damit der PC nicht dauernd laufen muss. Ausserdem bleiben > die Daten dann dauerhaft gespeichert. Hallo Rainer, danke für den Hinweis; das habe ich schon: die Daten werden zusätzlich auf einer SD-Karte geloggt (mit Datum und Uhrzeit), aus diesen könnte ich die Visualisierung jederzeit auch nochmals erstellen, aber im SerComInst werden sie halt im laufenden Betrieb sehr schön dargestellt, und nebendran auch die aktuellen Temperaturen auf Temp-Meter-Instrumenten. Mein PC ist ein älterer gebrauchter Lenovo M92 unter Win7, klitzekleiner PC, den ich extra dafür angeschafft habe (18 18 3,5 cm, allerdings ext. Netzteil, mit nur 12 - 15 W Energieverbrauch; den TFT-Schirm schalte ich nur ein, wenn ich gucken will, der braucht also nix). @Albert: Nach einem Programm-Neustart laufen jetzt die 4 Trend-Instrumente wieder einwandfrei (immer noch unter Alpha 10). Will erst Deine nächste Version aufspielen; da freue ich mich schon auf die Debug-Ansicht der Instrumente ...
Bitte die eben gepostete und wieder gelöschte Vers4 Alpha 15 nicht benutzen. Die korrigierte Version kommt morgen. Ich möchte das Datenformat um ein Simple-Format erweitern, so dass für einfache Anwendungen es reicht die Messwerte einfach z.B. semicolon-separiert zu schicken. Da auch viele einfache Messgeräte ähnliche Protokolle senden, würde ich gerne wissen, was ihr zusätzlich implementiert haben möchtet. Z.Z. sähe die Syntax so aus: Messwert Seperator Messwert CR LF wobei Seperator wählbar, z.B. Semicolon. Der Part Messwert Seperator lässt sich beliebig erweitern, so dass man z.B. 10 Messwerte schickt mit Abschluss CR LF. Intern würden die Messwerte der Reihe nach den Kanälen von 1 an aufwärts zugeordnet. Voraussetzung für dieses zusätzliche Format ist natürlich, dass die Werte immer in der gleichen Reihenfolge kommen.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.1
Instrument Liste zugefügt
- Listet alle Instrumente auf allen Seiten auf.
- Mit Klick auf die Header kann sortiert werden.
- Mit Doppelklick auf eine Instr.Nr. wird die passende
Darstellungs-Seite aufgerufen und das Instrument blinkt.
- Die einzelnen Spalten haben folgende Bedeutung:
Instr.Nr. = Instrumenten Nummer
Kanal = Zugeordneter Kanal
Sub = nur intern, virtueller Kanal bei Trend Instr.
Klickbar ist nur der jeweils erste Trend-Kanal
Aktiv = Sichtbare Instrumente
Display = Darstellungsseite, Instr. gelöscht = x
Beschreib. = Instrumenten-Kategorie
- Alle Design Instrumente haben immer die Kanal-Nr. 0
Zuordnungsfehler beim Projekt-Laden korigiert.
Diverse Bugs behoben.
Erinnerung: Wie alle Instrumente können auch die Design Instr.
mit der Tastatur über STR+Pfeiltasten Pixelweise verschoben und mit
SHIFT+Pfeiltasten in der Grösse geändert werden.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
-
Instrumenten-Liste.PNG
92 KB
Hallo Albert, die Instrument-Liste ist nützlich, aber werden nicht alle Geräte dargestellt. (bei mir) siehe Bild. Gruss sand
Angehängte Dateien:
@sand Bei einer neuen Version können nicht immer alte Projekt-Files benutzt werden, da sich die File-Struktur ändern kann. Bitte Projekt komplett neu erstellen und Info ob es funktioniert. Bild oben ein kurzer Test von mir.
:
Bearbeitet durch User
Projekt neu aufgelegt, Instrumentliste funktioniert, das Programm hat große Neigung zum Absturz beim Speichern und Laden. (keine Rückmeldung) Prozess muss beendet werden sonst kein Reaktion.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.2 Neues Num Display Instrument für numerische Anzeigen - Syntax: #kMm< wobei k=Kanal und m=Messwert - Wert- und Label-Feld (Text). - Wert- und Label-Breite getrennt einstellbar. - Anzahl Stellen / Precision einstellbar. - Display Typ (Formatierung) wählbar: Integer, Float, FixPoint, Exponent, Engineer, Binär (Binär zeigt den numerischen Wert im Binär-Format) - Optional wird ein positives Vorzeichen angezeigt. - Wert Position wählbar: Linksbündig, mittig, rechtsbündig - Wert-, Text- Farben wählbar (Text/Hintergrund). - Optional Label Hintergrund transparent. Beispiele siehe Bild. Gruss Ulrich Albert http://www.serialcominstruments.com/ P.S. bei der Bin Anzeige habe ich versehentlich eine Stelle bei der Precision zuwenig angegeben, daher stimmt der Wert (2745) nicht, die erste 1 fehlt.
:
Bearbeitet durch User
Lieber Ulrich, wird denn dann das Programm für den GRBL-Arduino auch so schön und ausgefeilt wie das hier ? Sind auch noch paar Sachen dran, die in der praktischen Anwendung nicht so flüssig und intuitiv bedienbar sind... Da würde sicher die Community auch gern fleißig an Verbesserungen helfen. Ein wenig Neid fließt da schon mit ein, wie das hier vorwärts geht, das man die Uhr stellen könnte danach und die CNC deiner Fans von der anderen Strecke muss halt weiter so dahin werkeln ohne Herzen erwärmende Updates. Hochachtung für deine Arbeit und Dank empfinden wir alle außerordentlich - aber bißchen stiefmütterlich behandelt fühlen wir uns leider doch.
@Realist (Gast) Wie schon mehrfach zugesagt, geht es mit SerialComCNC bald weiter.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.3 Für Alle die nur mal eben was probieren möchten oder die einfache Messgeräte anschliessen wollen, gibt es jetzt eine weitere Möglichkeit: Neues Simple Protokoll (COM-Schnittstelle) - Die Messwerte können als Strings direkt empfangen werden. - Mehren Messwerte aus verschiedenen Quellen werden durch einen Seperator getrennt (z.B. Semicolon) und die Auflistung mit CRLF oder auch nur CR abgeschlossen. - Beim Empfang werden der Reihe nach autom. Kanal-Nummern zugeordnet beginnend mit 1, Ende bei Erkennung von CR. - Die einmal gewählte Reihenfolge muss natürlich eingehalten werden damit die Kanalzuordnung stimmig bleibt. Beispiele (mit Semicolon als Seperator): 0.4532CR wird dem Kanal 1 zugewiesen 2.345;7;4.0121;0.53CR wird den Kanälen 1 bis 4 zugewiesen Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, Trend Instrument hat einen vertikalen grünen Cursor. Es wäre nicht schlecht wenn es möglich ist, die 4 Kanäle der Cursorposition entsprechend als integrierte Digitalanzeige darzustellen. Grüsse sand
sand schrieb: > Trend Instrument hat einen vertikalen grünen Cursor. Es wäre nicht > schlecht wenn es möglich ist, die 4 Kanäle der Cursorposition > entsprechend als integrierte Digitalanzeige darzustellen. Kommt demnächst, incl. Bewegen in die nicht mehr sichtbare Historie (falls der eingestellte Wert vom MaxRec das zulässt), sowie Speichern/Laden des kompletten Trend Inhaltes.
Albert M. schrieb: > Kommt demnächst, incl. Bewegen in die nicht mehr sichtbare Historie > (falls der eingestellte Wert vom MaxRec das zulässt), sowie > Speichern/Laden des kompletten Trend Inhaltes. Super. Darauf freue ich mich! Ich teste gerade an der neuen Version 4.0.3. LED und Num-Display funktionieren prima. Nun wollte ich um ein Num-Display einen Rahmen satt anliegend haben; aber es gelingt mir wegen der Rasterung nicht, diesen sauber um das Num-Display zu legen; das Display ist immer etwas zu klein oder zu groß. Gibt es einen Trick? Das Schalter-Instrument funktioniert auch gut und sieht sehr gut aus. Man könnte evt. im Handbuch noch ergänzen, daß das Senden beim Loslassen der Maustaste geschieht, nicht beim Drücken. Button-Panel funktioniert auch gut. Dort fällt mir auf, daß - nur hier - die Befehle, die zum uC gesendet werden, mit CR/LF gefolgt werden. Das Ziehen im Design-Modus ist auch etwas anders, der Rahmen bewegt sich erst beim Loslassen der Maus und nicht, wie bei den anderen Elementen, schon beim Bewegen. Das Text-Display habe ich auch probiert, funktioniert ebenfalls prima. Dort fällt auf, daß auch Punkte durch Kommas ersetzt werden. Das ist ja die gleiche Ersetzung wie bei Meßwerten, bei denen ein gesendeter Dezimalpunkt in einem Display als Dezimalkomma erscheint (und das ist auch gut so). Ein Komma bleibt ein Komma beim Textdisplay. Wäre zu fragen: wie sendet man einen Punkt? Simple Data Protocol teste ich auch noch. Noch eine Anregung beim Terminal: Da könnte es praktisch sein, wenn man per Haken wählen könnte, ob der zu sendende Text stehen bleibt, sodaß man den mehrfach senden kann einfach durch Klick auf "Send". Oder evt. auch so, daß der Text nach dem ersten Senden markiert wird (also windows-üblich blau wird) und stehen bleibt, bis man etwas neues eingibt; solange könnte man dann den bisherigen Text mehrfach senden. Was hälst du davon? Insgesamt ein toller Fortschritt gegen die letzte Version Alpha10, die ich getestet hatte. Herzlichen Dank!
Günter R. schrieb: > es gelingt mir wegen der Rasterung nicht, diesen > sauber um das Num-Display zu legen; das Display ist immer etwas zu klein > oder zu groß. Gibt es einen Trick? Ja, gibt es. Siehe hier: Albert M. schrieb: > Erinnerung: Wie alle Instrumente können auch die Design Instr. > mit der Tastatur über STR+Pfeiltasten Pixelweise verschoben und mit > SHIFT+Pfeiltasten in der Grösse geändert werden. Na ja, fast alle. Die Background Icons lassen sich nur verschieben, da sonst die Linienbreiten verändern würden. Es gibt aber demnächst Background Vektor Bilder, die frei skalierbar sind. Günter R. schrieb: > Button-Panel funktioniert auch gut. Dort fällt mir auf, daß - nur hier - > die Befehle, die zum uC gesendet werden, mit CR/LF gefolgt werden. Ich überlege noch, ob generell alles was zum MC gesendet wird mit CRLF abgeschlossen wird. Das dürfte auch eigentlich die nicht stören, die auf das "<" ab Ende reagieren möchten. Günter R. schrieb: > *zu Button Panel* > Ziehen im Design-Modus ist auch etwas anders, der Rahmen bewegt sich > erst beim Loslassen der Maus und nicht, wie bei den anderen Elementen, > schon beim Bewegen. Das lässt sich z.Z. nicht ändern, aber ich denke damit kann man leben. Günter R. schrieb: > Ein Komma bleibt ein Komma beim Textdisplay. Wäre zu > fragen: wie sendet man einen Punkt? Wird korrigiert, so dass das Textdisplay genau das zeigt was gesendet wurde. Günter R. schrieb: > Terminal: Da könnte es praktisch sein, wenn man > per Haken wählen könnte, ob der zu sendende Text stehen bleibt, sodaß > man den mehrfach senden kann Wird integriert. Danke für Deinen Test.
:
Bearbeitet durch User
Angehängte Dateien:
Zwischendurch noch einen Performance Test: Mit einem Arduino Uno (500.000 baud) schaffe ich es z.Z. 5.400 Samples/s zu senden (Integer als String). SerialComInstruments macht das klaglos mit. Darauf zugeschnittene schnelle graph. Instrumente kommen demnächst.
:
Bearbeitet durch User
Albert M. schrieb: > Anbei neue Version SerialComInstruments 4.0.3 > > Für Alle die nur mal eben was probieren möchten oder die einfache > Messgeräte anschliessen wollen, gibt es jetzt eine weitere Möglichkeit: > > Neues Simple Protokoll (COM-Schnittstelle) > - Die Messwerte können als Strings direkt empfangen werden. > - Mehren Messwerte aus verschiedenen Quellen werden durch einen > Seperator getrennt (z.B. Semicolon) und die Auflistung mit > CRLF oder auch nur CR abgeschlossen. Cool! Dann kann ich das am Montag gleich mal mit dem uEpsilon Laser Distanz Messer ausprobieren.
Angehängte Dateien:
... und was es demnächst in SerialComInstruments 4 noch gibt: Siehe Bilder oben, XY-Realtime-Plots mit dritter Dimension als frei zuordbaren farbcodierten Wert, incl. Pannig/Zoomimg.
:
Bearbeitet durch User
Albert M. schrieb: > XY-Realtime-Plots mit dritter Dimension als frei > zuordbaren farbcodierten Wert, incl. Pannig/Zoomimg. Klasse, darauf freue ich mich schon. Genau sowas suche ich im Moment! Tolle Arbeit!
Kann man, da das alpha ja aus dem Dateinamen weg ist, inzwischen die Projekte problemlos übernehmen, wenn eine neue Version kommt?
Rainer M. schrieb: > da das alpha ja aus dem Dateinamen weg ist Der Hinweis auf die beschränkte Nutzungsdauer ist auch weg ?!
Albert M. schrieb: > Neues Simple Protokoll (COM-Schnittstelle) Ich habe hierzu nochmal eine Frage: Oftmals müssen Geräte erst mit einem Initialwert gefüttert werden, damit sie antworten und Messwerte schicken. Im Beispiel vom µEpsilon geräten ist es z.B. der Befehel "dt"+CRLF. Wäre es möglich, dass Du hier noch eine möglichkeit vorsiehst, um das ganze an das Gerät zu füttern? Schönen Sonntag, grüße M.S.
Rainer M. schrieb: > Kann man, da das alpha ja aus dem Dateinamen weg ist, inzwischen die > Projekte problemlos übernehmen, wenn eine neue Version kommt? Nein, je nach zukünftigen neuen Instrumenten kann es notwendig sein die interne Struktur zu ändern, was oft auch Auswirkungen auf die Datenstruktur für das Speichern/Laden des Projektes haben kann. Helmut schrieb: > Der Hinweis auf die beschränkte Nutzungsdauer ist auch weg ?! Ich habe nur keine Lust das dauernd zu erwähnen. Der Vermerk ist nach hier verlagert (unter: Verwendungsbeschränkung der Software): http://www.serialcominstruments.com/download.php Martin S. schrieb: > Oftmals müssen Geräte erst mit einem Initialwert gefüttert werden, damit > sie antworten und Messwerte schicken. Im Beispiel vom µEpsilon geräten > ist es z.B. der Befehel "dt"+CRLF. > Wäre es möglich, dass Du hier noch eine möglichkeit vorsiehst, um das > ganze an das Gerät zu füttern? Kannst Du bereits jetzt schon mit dem internen Terminal. Wenn dies aber repetiv gesendet werden muss, also jedesmal ein "dt" damit Dein Gerät einen Messwert sendet, könnte ich einen Timer in das bekannte "Send Predefined Commands" Instrument aus der alten Version integrieren. Siehe auch: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Dieses Instrument kommt demnächst auch für SerialComInstruments 4. Heute habe ich einen Test- und Probier-Sonntag, da ich wegen akutem Heuschnupfen/Pollenallergie nicht nach draussen gehen kann. So bin ich dabei einige neu vorgesehene Verarbeitungsstrukturen mal ausgiebig untersuchen: IIR Filter und FFT. IIR Filter (Butterworth, Bessel, Chebyshev und Infinite-Impulse-Response (IIR) Filters (Lowpass, Highpass, Bandpass oder Bandstop) mit einer max. Filter Ordnung von 8. Processing Speed ist beim IIR filter ca. 5-10 millions Samples/s, bei der FFT (1024) ca. 5.000 bis 10.0000 mal pro Sekunde auf einem i7 PC. Sieht doch schon mal gut aus. Ich wünsche euch einen schönen Sonntag. Gruss Ulrich Albert
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.4
Neues Instrument Vertical Slider
- Sendet den eingestellten Wert an den Mikrocontroller.
- Der Wert wird nicht beim Verschieben, sondern erst beim
Loslassen der linken Mousetaste gesendet.
- Feineinstellung über Mouserad oder Tastatur Pfeiltasten,
während die linke Mousetaste gedrückt bleibt.
- Wertebereich frei skalierbar
- Wenn Instrument-Color gleich Anzeigefenster-Color, dann
wird das Instrument quasi-transparent dargestellt.
- Die übertragenen Nachkommastellen werden durch den
Display Format-String bestimmt.
- Protokoll: #kMw<
wobei: k=Kanal, w=Wert, CRLF=asc13+asc10
Dezimal-Delimiter wird als Punkt gesendet.
Es wird autom. CRLF angehängt.
Interface Simple Protokoll erweitert mit optionalem Trigger
für externe Geräte:
- Trigger Char/String frei wählbar.
- Beliebige Wiederholzeiten von 20 ms bis 10.000 ms.
Bug: Text Display zeigt jetzt Komma und Punkt richtig an.
Change: Im Terminal bleibt nach Send der Eingabetext erhalten.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, beim Vertikal Slider wäre meiner Meinung nach eine bessere Lösung, wenn CRLF wie beim Eingabe Box nur optional zuschaltbar ist. Grüsse sand
In der Version 4.0.4 fehlt für das Vertical Slider Instrument noch das Senden über LAN/UDP. Kommt in der nächsten Version. sand schrieb: > beim Vertikal Slider wäre meiner Meinung nach eine bessere Lösung, wenn > CRLF wie beim Eingabe Box nur optional zuschaltbar ist. Ich denke über eine globale Einstellung für alle Instrumente die senden nach. Also entweder für alle mit angehängtem CRLF oder für keins. Das spart mir Programmierarbeit und ist wahrscheinlich konsistenter.
Angehängte Dateien:
Hier eine Vorschau auf das kommende Mathematik Modul. Gegeben sind die frei wählbaren Eingangskanäle X und Y die über eine (fast) beliebige Formel den Ausgangskanal Z ergeben. Die Formel kann auch auf nur einen Eingangskanal angewand werden. Die Klammerebenen können beliebig tief verschachtelt sein. Der Ausgangskanal Z wird wieder in das System/CommandProcessor eingespeist und kann von weiteren Instrumenten benutzt werden. Die Formel wird nicht über einen langsamen Interpreter abgearbeitet, sondern liegt nach einem Klick auf "Set" intern als schnelle kompilierte Version vor. Wieviele Mathematik Module ich zulasse müssen noch durchzuführende Speed-Tests zeigen.
:
Bearbeitet durch User
Albert M. schrieb: > sand schrieb: >> beim Vertikal Slider wäre meiner Meinung nach eine bessere Lösung, wenn >> CRLF wie beim Eingabe Box nur optional zuschaltbar ist. > > Ich denke über eine globale Einstellung für alle Instrumente die senden > nach. Also entweder für alle mit angehängtem CRLF oder für keins. Das > spart mir Programmierarbeit und ist wahrscheinlich konsistenter. Ja, das fände ich gut, wenn man das optional haben kann über eine Check-Box (für alle Instrumente gleichzeitig). Ich denke, das Instruments-Menü wäre dafür ein gut geeigneter Ort.
Albert M. schrieb: > Hier eine Vorschau auf das kommende Mathematik Modul. Das sieht doch sehr gut aus. Wann würde denn die Berechnung durchgeführt werden? Immer dann, wenn sich ein Eingabewert ändert? Oder muß die Berechnung irgendwie getriggert werden? Denn andernfalls könnte es ja sein, daß zwei (oder mehr Werte) zu kommen haben, aber die Berechnung schon nach dem ersten Wert stattfindet und ausgegeben wird, aber diese Werte passen evt. nicht zusammen, weil von den anderen Werten die Vorzustände genommen werden.
Günter R. schrieb: > Das sieht doch sehr gut aus. Wann würde denn die Berechnung durchgeführt > werden? Die Berechnung (bei zweikanaliger Mathematik) wird jeweils ausgeführt, wenn beide Werte der Kanäle X und Y eingetroffen sind; die Reihenfolge ist egal. Danach wird das Ereignis-Flag der Kanäle zurückgesetzt und ein neuer Zyklus kann beginnen. Es liegt naturgemäss in der Verantwortung des Anwenders, dass die Kanäle auch irgendwann eintreffen, je kürzer hintereinander desto zeitäquidistanter wird das Ergebnis. Sinnvoll ist es, wann immer machbar, die Kanäle X und Y im 2er Pack zu schicken.
:
Bearbeitet durch User
Albert M. schrieb: > In der Version 4.0.4 fehlt für das Vertical Slider Instrument noch das > Senden über LAN/UDP. Kommt in der nächsten Version. Gibt es dann auch die Möglichkeit das Instrument mit Werten vom uC aus zu steuern? Wenn ich z.B. den Wert über die Webseite oder einen Slider in Blynk ändere, sollte sich der Slider hier ja auch aktualisieren. Oder bei einem Neustart auf den aktuellen Wert einstellen. Wäre ja dann wie ein Vertikalmeter, an dem man den Zeiger verschieben kann ;-)
:
Bearbeitet durch User
Rainer M. schrieb: > Gibt es dann auch die Möglichkeit das Instrument mit Werten vom uC aus > zu steuern? Ja, das Vertikal Slider Instrument lässt sich ab der nächsten Version auch vom MC aus steuern.
Anbei neue Version SerialComInstruments 4.0.5 Die Pages/Displays können nun vom Mikrocontroller aus umgeschaltet werden. Protokoll: #SPn< wobei S=SystemCmd, P=Page, n=PageNr. 1..5 Die Anzahl der verfügbaren Pages wurde auf 5 erhöht. Das dürfte eigentlich reichen, sollte jemand mehr brauchen, dann bitte melden. Der Vertikal Slider kann jetzt auch vom MC aus gesetzt werden. Protokoll: #kMw< wobei k=Kanal und w=Wert Vertical Slider sendet jetzt auch über UDP. Im Main-Menu kann unter Settings gewählt werden ob beim Senden von Instrumenten CRLF angehängt wird. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
-
Grafikfehler.gif
17 KB
Kleiner Grafikfehler - siehe Bild. Tool-Box wird nicht richtig dargestellt und darunter sind irgendwelche schwarzen Pixel.
Martin S. schrieb: > Oftmals müssen Geräte erst mit einem Initialwert gefüttert werden, damit > sie antworten und Messwerte schicken. Im Beispiel vom µEpsilon geräten > ist es z.B. der Befehel "dt"+CRLF. Hallo Martin, das habe ich ja in der Version 4.0.4 mit der erweiterten Option im Simple Protokoll als Trigger implementiert. Funktioniert das mit Deinen µEpsilon Geräten? Reicht der eingebbare ms-Bereich für die Wiederholrate? Martin S. schrieb: > Kleiner Grafikfehler - siehe Bild. > Tool-Box wird nicht richtig dargestellt und darunter sind irgendwelche > schwarzen Pixel. Danke für den Hinweis.
:
Bearbeitet durch User
Albert M. schrieb: > Martin S. schrieb: >> Oftmals müssen Geräte erst mit einem Initialwert gefüttert werden, damit >> sie antworten und Messwerte schicken. Im Beispiel vom µEpsilon geräten >> ist es z.B. der Befehel "dt"+CRLF. > > Hallo Martin, das habe ich ja in der Version 4.0.4 mit der erweiterten > Option im Simple Protokoll als Trigger implementiert. Funktioniert das > mit Deinen µEpsilon Geräten? Reicht der eingebbare ms-Bereich für die > Wiederholrate? Ich habe das heute auf die Schnelle nicht zum laufen bekommen. Aber morgen nehm ich mir mal die Zeit und probiere das nochmal aus. >> Kleiner Grafikfehler - siehe Bild. >> Tool-Box wird nicht richtig dargestellt und darunter sind irgendwelche >> schwarzen Pixel. > > Danke für den Hinweis. Gern.
Der Slider-Zeiger springt zwischen 0 und eingestellter Wert.
sand schrieb: > Der Slider-Zeiger springt zwischen 0 und eingestellter Wert. Kann ich bei mir nicht reproduzieren. Unter welchen Umständen kommt das bei Dir vor?
Aber nur in dem Fall wenn der Slider aktiviert wird als Leitgerät. So lange bis ein anderer Sollwertgeber Priorität hat verhält sich als pure Messinstrument ruhig.
Es fällt besonders beim Feineinstellungsversuch auf.
sand schrieb: > Aber nur in dem Fall wenn der Slider aktiviert wird als Leitgerät. So > lange bis ein anderer Sollwertgeber Priorität hat verhält sich als pure > Messinstrument ruhig. Programmintern gibt es keine Aktivierungen als Leitgerät oder Prioritäten, daher verstehe ich jetzt nicht so ganz was Du meinst. Ich habs jetzt nochmal mit 5 Slidern versucht und kann das von Dir beschriebene Verhalten nicht nachvollziehen. Bitte untersuch mal den Datenverkehr ob da nicht irrtümlich auf deinem Kanal für den Slider eine Null ankommt, denn ohne dem kann der Slider nicht auf Null springen. Vielleicht kann ja noch jemand das Ganze mal testen.
:
Bearbeitet durch User
Bei mir ist es so, dass eine 0 ankommt, aufgrund anderer Eingabeoptionen (Blynk vom Iphone aus). Muss den Fehler noch rausprogrammieren
:
Bearbeitet durch User
Es gibt noch einen Bug: Es lassen sich mit dem Kommando #SPn< nur die Displays 1 bis 3 aufrufen. Wird korrigiert auf 1 bis 5. Es wird zum Testen in der nächsten Version eine Eingabebox geben, mit der es möglich ist einen Kommando-String direkt dem Command-Processor zuzuführen, ohne das die Schnittstellen aktiviert sein müssen. Damit lassen sich zum Testen alle Instrumente mit Werten beaufschlagen oder sonstige Aktionen ausführen, genau so als wären die Kommandos mit der entsprechenden Syntax von den Schnittstellen.
Albert M. schrieb: > Es wird zum Testen in der nächsten Version eine Eingabebox geben, mit > der es möglich ist einen Kommando-String direkt dem Command-Processor > zuzuführen, ohne das die Schnittstellen aktiviert sein müssen. Damit > lassen sich zum Testen alle Instrumente mit Werten beaufschlagen oder > sonstige Aktionen ausführen, genau so als wären die Kommandos mit der > entsprechenden Syntax von den Schnittstellen. Das funktioniert bereits schon gut mit dem Programm PacketSender.
Anbei neue Version SerialComInstruments 4.0.6 Die Skalierungsfaktoren für die Instrumente Vertikal-, Horizontal, Temp- und Round-Meter, sowie für Tank und Trend sind nun freigegeben. Der Menuepunkt "Generator" wurde umbenannt in "Test Tools". Hier ist es jetzt, zusätzlich zum Generator, möglich einen Test-String (Kommando) direkt dem Command-Processor zuzuführen, ohne das die Schnittstellen aktiviert sein müssen. Damit lassen sich zum Testen alle Instrumente mit Werten beaufschlagen oder sonstige Aktionen ausführen, genau so als wären die Kommandos von den Schnittstellen. Bug: Es liessen sich mit dem Kommando #SPn< nur die Displays 1 bis 3 aufrufen. Ist korrigiert auf 1 bis 5. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
-
Fehler.PNG
28 KB
Nach dem Öffnen des Programms, und verbinden mit COM zuerst ohne jegliche Reaktion darauf. Beim Doppelklick auf die Instrumente kommt immer die Fehlermeldung - siehe Bild. Wenn die Instrumente neu abgespeichert sind dann funktionieren sie wieder bis zur Neueröffnung des Programms.
Top für meine Arduino Mega2560 und DUE. Gruss
Bei File/New stürtz das Programm ab. Win7 64Bit. Gruss
sand schrieb: > Beim Doppelklick auf die Instrumente kommt > immer die Fehlermeldung - siehe Bild. Wenn die Instrumente neu > abgespeichert sind dann funktionieren sie wieder bis zur Neueröffnung > des Programms. Kann ich zwar auf die Schnelle nicht reproduzieren, aber es liegt ein Fehler vor der behoben werden muss. peter schrieb: > Wo ist bitte die Konfigseite ? Doppel-Klick auf Instrument. peter schrieb: > Bei File/New stürtz das Programm ab. Wird in der nächsten Version behoben.
Albert M. schrieb: > peter schrieb: >> Wo ist bitte die Konfigseite ? > > Doppel-Klick auf Instrument. Intuitiv markiert man das Instrument und erklickt mit der rechten Maustaste zugehörige Optionen.
Also ich hab jetzt mal an dem Slider weiterprogrammiert, und jetzt funktioniert es genau so wie ich es mir vorgestellt habe. Auf dem Iphone habe ich Blynk, der Arduino lässt sich über SerialComInstruments (UDP), Blynk, Webseite und später noch über Touch LCD steuern. Hier mal ein kurzes Filmchen. Erhebt keinen Anspruch auf Proffesionalität https://www.youtube.com/watch?v=xE1IDJpjF50 Da sieht man schön, wie die Buttons aktualisiert werden, und wie die Slider sich gegenseitig aktualisieren. Auch das Buttonfeld mit 4 Buttons (-1, +1, -5, +5) aktualisiert die Slider. Vielleicht inspiriert es ja den einen oder anderen.
:
Bearbeitet durch User
Echt cool und sehr gut im Video dokumentiert. Von Iphone Programmierung hab ich keine Ahnung, aber Deine Oberfläche sieht spitze aus. Bei mir scheitert es schon daran, dass ich kein Iphone besitze, nur ein uraltes Handy :) Rainer M., darf ich Dein Video auf meiner Webpage verlinken?
:
Bearbeitet durch User
Das Iphone ist jetzt auch schon über 3 Jahre alt. Blynk gibt es auch für Android. Wenn man sich etwas einarbeitet, ist das Klasse zum Fernsteuern und Werte anzeigen. Man kann auch Alarme zum Handy senden, wenn die App nicht aktiv ist. Dafür nehme ich zwar momentan noch Prowl, werde es aber umstellen.
Klar, kannst du verlinken. Ich lass das dann auf youtube
Angehängte Dateien:
Das kommende Mathematikmodul habe ich auf IIR-Filter erweitert. Damit ist eine äusserst effektive Signalfilterung möglich auch bei sehr niedrigen Frequenzen. Zur Kontrolle der eingestellten Filterparameter kann man optional die Filterkurven visualisieren (Bilder 2 bis 4). Die Bilder 5 und 6 zeigen anhand eines realen Signals einen Tiefpass und einen Hochpass. Beim IIR-Filter ist der Eingangs- und Ausgangskanal frei wählbar. Der Ausgangskanal wird dem internen Command-Processor zugeführt und ist von allen Instrumenten nutzbar. Zudem wird das Modul noch mit FFT erweitert, daran arbeite ich gerade.
:
Bearbeitet durch User
Wie muss ich das Projektverzeichnis und welche Parameter übergeben, dass ich das ganze per Doppelklick im Vollbildmodus starten kann? bzw. in Autostarte einbindeb
Rainer M. schrieb: > Wie muss ich das Projektverzeichnis und welche Parameter übergeben Command Line Parameter werden in Vers. 4 noch nicht unterstützt. Kommt aber kurzfristig.
Angehängte Dateien:
Das Mathe und Filter Modul wird so langsam komplett. Siehe auch hier: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Die FFT funktioniert bereits ohne das System merklich zu belasten. Obiges Bild zeigt eine laufende Realtime 2048 Punkte FFT. Die Daten kommen hier mit 500 Samples/s über die serielle Schnittstelle. Die Grundfrequenz des Signals ist ca. 4 Hz. FFT ist erlaubt mit 2^6 (64) bis 2^15 (32.768) Punkte.
:
Bearbeitet durch User
Ich habe heute wieder mal einiges an V. 4.0.6 getestet. - Test-Kommando-Box funktioniert gut. Wäre evt. schön, wenn sie ihre Position behalten würde, wenn man sie z.B. in die rechte obere Ecke schiebt; beim Neu-Aufrufen ist sie derzeit immer in der Bildschirmmitte, da stört sie mich u.U. - Umschalten der Pages mit SPn funktioniert auch gut. Man könnte überlegen, ob man im Protokoll bei "M" bzw. "SP" auch Kleinbuchstaben zuläßt. Aber das ist nicht wichtig. - Das optionale Senden von CR-LF ist prima, gerade wenn man mit z.B. HTerm testet. - Slider-Instrument funktioniert bei mir auch einwandfrei (Senden und Empfangen), auch die Rollrad-Feineinstellung. Interessante Feststellung: klickt man irgendwo innerhalb des Instruments hin, aber nicht auf den Slider direkt, so kann man den eingestellten Wert senden ohne Gefahr, den Slider unabsichtlich zu verstellen; das ist gut. - Textbox: Komma/Punkt funktioniert jetzt, wie Du geschrieben hattest. - Eingabebox funktioniert gut. - Die Instrumenten-Liste funktioniert auch, allerdings werden die Beschreibungstexte rechts abgeschnitten; mag das an meinem TFT mit nur 1024 * 786 liegen? Das Blinken eines lokalisierten Instruments bei Doppelklick auf eine Zeile ist auch gut. Der Button "ShowInstrument Data" ist wohl noch außer Funktion... - Im Fenster des Test-Generators ist bei mir unten der Erklärungstext abgeschnitten; dort lese ich nur als letzte Zeile "Es wird jede 1 ms ein neuer Wert", darunter sehe ich nur ein paar Pünktchen. Die Null vom "+10" der Kanal-2-Zeile ist auch angeschnitten. - Start/Stop vom Trend-Instrument funktioniert auch gut. Wie kann man eigentlich den Inhalt löschen, also die Aufnahme von vorn beginnen lassen? Der Start/Stop-Button gilt wohl für alle vorhandenen Trend-Instrumente gleichzeitig? Diesen Button könnte man evt. noch einfärben, wenn er aktiv ist, so wie den COM-Button. Alles in allem finde ich keine gravierenden Fehler (außer dem Absturz bei File/New). Funktioniert alles wie es soll. Super Programm! Gruß, Günter
Man sollte die Texte selber festlegen können in Typ und größe. Gruss
Mir fällt noch etwas ein zum Trend-Instrument: Wenn man dort mit der Maus in den Instrument-Bereich geht, entsteht ja ein grüner senkrechter Balken an der Stelle des Mauszeigers. Drückt man dann die linke Maustaste, so öffnet sich das zugehörige Einstellungen-Fenster. Es wäre schön, falls das überhaupt möglich ist, wenn dann dort die genaue Zeitposition angezeigt werden würde, an der der grüne Balken stand, als man die Maustaste gedrückt hat.
Günter R. schrieb: > Mir fällt noch etwas ein zum Trend-Instrument: > ... wenn dann dort die genaue Zeitposition angezeigt werden würde und > Wie kann man > eigentlich den Inhalt löschen, also die Aufnahme von vorn beginnen > lassen? Kommt demnächst. Danke für den ausführlichen Test. peter schrieb: > Man sollte die Texte selber festlegen können in Typ und größe. Da denke ich mal drüber nach.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.7 FFT-Instrument zugefügt (unter Tool-Box / Controls). - FFT-Punkte 64, 128, 512, 1024, 2048, 4096 und 8192 Die FFT wird jeweils ausgeführt, wenn die Anzahl der eingetroffenen Messwerte gleich den gewählten FFT-Punkten ist. - Sample Rate [Hz] einstellbar (Anzahl der Messwerte/s) Die Sample Rate bestimmt die Skalierung der Frequenz-Achse - FFT-Graphik skalierbar in X und Y Achse - Es ist nur 1 FFT-Instrument erlaubt. Command Line Parameter zugefügt. - Es ist der Aufruf des Programms in der Form "Filename Parameter" möglich, der Parameter ist das Projekt Ordner-Verzeichnis. - Beispiel: C:\SerialComInstruments 4\SerialComInstruments.exe c:\Projekt_1 Wichtig: Im Namen des Projekt-Files dürfen sich keine Leerstellen befinden. Es wird immer sofort der gespeicherte Serielle- und UDP-Port geöffnet. Bug: Absturz nach "File/New" behoben. Die Bilder oben zeigen FFT mit Sinus- und Rechteck-Signalen. Das letzte Bild zeigt eine FFT mit einer Sample-Rate von 2500 Messwerten/s und einem Sinus-Signal von 400 Hz, ADC-Messung mit einem Arduino-Uno bei 500.000 baud (Signal vom Funktionsgenerator). Ein Instrument um schnelle Signale graphisch darzustellen kommt demnächst. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Günter R. schrieb: > Der Button "ShowInstrument Data" ist wohl noch außer Funktion... Nein, damit wird die Liste neu augebaut. Eine Wirkung zeigt sich natürlich nur wenn sich bei den Instrumenten was geändert hat. Die Grösse für die Beschreibungsspalte wird erweitert. Günter R. schrieb: > Mir fällt noch etwas ein zum Trend-Instrument: > Wenn man dort mit der Maus in den Instrument-Bereich geht, entsteht ja > ein grüner senkrechter Balken an der Stelle des Mauszeigers. > Es wäre schön, falls das überhaupt möglich ist, > wenn dann dort die genaue Zeitposition angezeigt werden würde Kommt mit der nächsten Version. Unten im Status-Panel wird bei Bewegung des Skalen-Cursors (grüne Linie) über die Graphik die zugehörige Rec-Nummer, Datum+Zeit, sowie die Werte der Kanäle 1 bis 4 angezeigt.
:
Bearbeitet durch User
Albert M. schrieb: > Kommt mit der nächsten Version. Unten im Status-Panel wird bei Bewegung > des Skalen-Cursors (grüne Linie) über die Graphik die zugehörige > Rec-Nummer, Datum+Zeit, sowie die Werte der Kanäle 1 bis 4 angezeigt. Prima. Das ist natürlich noch besser als mein Vorschlag.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.8 Umfangreiche Trend Instrument Erweiterungen - Mit dem "Clear Display" Button im Parameter-Fenster wird der Grafik-Inhalt des jeweiligen Trend-Instruments gelöscht. - Bewegliche grüne Cursor-Linie: Bei Bewegen der Linie mit der Mouse werden unten im Status-Panel die zugehörige Record-Nummer, Datum+Zeit, sowie die Werte der Kanäle 1 bis 4 angezeigt (aus Geschwindigkeitsgründen unformatiert). - Ein Bedien-Fenster öffnet sich bei Rechtsklick auf das Instrument. Es kann sich im Bereich der eingestellten MaxRecords innerhalb der Messwerte in der Historie vorwärts und Rückwärts bewegt werden. MaxRecords muss der gewünschten Aufzeichnungsdauer angepasst werden, je nach PC bis zu 100.000 oder mehr. - Speichern und Laden aller Daten-Records über die Buttons "Save Records" und "Load Records" im Parameter-Menue. Zum Speichern ist es empfehlenswert die laufende Aufzeichnung anzuhalten. Das Laden muss in das gleiche Trend-Instrument wie beim Speichern erfolgen, damit die Skalierungen stimmen. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
In der nächsten Version unter Anderem:
Direkte Weiterleitung von eingehenden UDP Nachrichten auf die serielle
COM Schnittstelle. Es können beliebige Inhalte von UDP auf COM
umgeleitet werden mit folgender Syntax:
$t< wobei $ = Start-Bezeichner
t = beliebiger Text-String
< = Ende-Bezeichner
Die Zeichenfolge, incl der Start/Ende-zeichen, wird von
SerialComIntruments nicht verändert oder ausgewertet, also reine
Weiterleitung.
Damit kann sich jeder das für ihn passende zurechtschneidern.
In anderen Commands darf das $ Zeichen nicht mehr verwendet werden.
Falls gewünscht kann ich das Gleiche auch in umgekehrter Richtung
implementieren, also direkte Weiterleitung von COM auf UDP, so das man
dem MC damit quasi eine bi-direktionale LAN/UDP Schnittstelle verpasst.
Die Syntax wäre wie oben.
Weitere Schnittstellen kommen demnächst.
:
Bearbeitet durch User
Albert M. schrieb: > Falls gewünscht kann ich das Gleiche auch in umgekehrter Richtung > implementieren, also direkte Weiterleitung von COM auf UDP, so das man > dem MC damit quasi eine bi-direktionale LAN/UDP Schnittstelle verpasst. > Die Syntax wäre wie oben. > > Weitere Schnittstellen kommen demnächst. Ruhe sanft, meine kleine Fräse. Es war mal schön mit dir :(
Ich habe heute die Version 4.0.8 installiert. Hierbei auch gleich Programmaufruf mit Kommandozeilenoption. Das funktioniert gut, allerdings wird - im Gegensatz zum Projekt-Laden aus dem Menü - oben im Programmheader statt des Projektpfades der Pfad "C:\User\Anwender" angezeigt (was ja nicht richtig ist - meine Projekte stehen unter "C:\Dateien\SerialComInstruments\...") - ich mag diesen "EigeneDateien"-Quatsch von Windows nicht, bin ja der einzige Benutzer (außer der Einbrecher kommt ...). Das sollte man wieder ändern, damit man dann auch ein aktualisiertes Projekt sofort wieder über "File/Save Project" unter dem aktuellen Namen abspeichern kann, ohne etwas eingeben zu müssen. Prima ist, daß COM+LAN+Trend sofort aktiv sind, wenn man per Kommandozeile starten läßt. Dann habe ich festgestellt (war wohl auch früher schon so), daß man im Trend-Instrument nur max. 10 "Raster Y WerteSteps" eingeben kann; bei größeren Zahlen wird 10 genommen. Das könnte auch feiner sein, speziell, wenn man ein Trend-Instrument auf eine ganze Bildschirmseite großzieht. Die Cursor-Anzeige in der Statuszeile mit dem grünen Balken ist super!
Angehängte Dateien:
Ein Beispiel für die Effizienz des Realtime IIR Filter-Moduls in SerialComInstruments 4, siehe Bilder oben als Snapshots der laufenden Darstellung. Signale erzeugt mit Rigol 1022 Fkt Generator, gemessen mit Arduino-Uno und übertragen mit 115200 Baud. Der Arduino misst und sendet alle 1,5 ms, daher die oben eingestellte Samplerate von 666 Hz.
:
Bearbeitet durch User
Einstellung Rechte Skala beim Trend Instrument wird nicht mit abgespeichert. Grüne Cursor zeigt keine Werte an.
sand schrieb: > Einstellung Rechte Skala beim Trend Instrument wird nicht mit > abgespeichert. > Grüne Cursor zeigt keine Werte an. Gerade nochmal getestet. Beides funktioniert einwandfrei. Projekt-Files von früheren Versionen dürfen nicht benutzt werden, vielleicht trift das bei Dir zu. Es werden in der Statusleiste nur Werte angezeigt, wenn sich die grüne Messline innerhalb eines Signals befindet.
:
Bearbeitet durch User
Cursor Geschichte funktioniert, gefolgt wie du gesagt hast. Was ich weiterhin nicht verstehe, warum springt der Slider-Zeiger bei mir immer zwischen Skala min. Wert und eingestelltem Wert. Egal was ich tue der Zeiger pendelt. Der Wert wird zwar angenommen aber auch mühsam. Feineinstellung ist nicht möglich. Wohl überlegt, warum soll ein Geberinstrument auch für Rückmeldung dienen?
Hallo, guten Tag. Vielen dank für deine Neuigkeiten. Mein Wunsch für den Hintergrund: die Alphablendung bitte weglassen..oder selber einstellen lassen. Ich mag lieber eine durchgehende einheitliche Hintergrund-Farbe. Danke. Gruss
Hier gibt es ein Video über die neuen Instrumente: https://youtu.be/ocU-URMLWtM Leider etwas ruckelig, vielleicht habe ich beim Veröffentlichen den falschen Video-Codec ausgewählt.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.9
Direkte UDP Weiterleitung.
- UDP Weiterleitung von eingehenden UDP Nachrichten auf die serielle
COM Schnittstelle zum MC.
- Es können beliebige Text-Inhalte von UDP auf COM geschickt werden
mit folgender Syntax:
$t< wobei $ = Start-Bezeichner
t = beliebiger Text-String
< = Ende-Bezeichner
- Ist "Senden mit CRLF" aktiviert wird ein CRLF angehängt.
In anderen Commands darf das $ Zeichen nicht mehr verwendet werden.
Neues Instrument Text Shape (siehe Bild oben).
- Anzeigen von Textinhalten in beliebiger Grösse.
- Text-Font, Text-Farbe und Background-Farbe wählbar
- 10 verschiedene Shapes, wie Rechteck, Elypse, Dreieck usw.
- Setzen des Textes vom Konfigurationsmenue.
- Setzen des Textes vom Mikrocontroller:
Protokoll #kMfbt< wobei k=Kanal, t=Text
f=TextFarbe, b=BackgroundFarbe
Farbwerte f bezw. b:
0 = schwarz 1 = weiss
2 = rot 3 = hellgrün
4 = gelb 5 = hellblau
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
-
Bild2.jpg
45 KB
Wie funktioniert bitte das Testen ? Bekomme es nicht hin. Habe Kanal und Wert eingegeben und gestartet. Es bleibt auf 0. Danke. Gruss
In deinem Befehl fehlt noch das abschließende <
Was mir fehlt ist eine Reihe von 8 Leuchtdioden die man mit einem Wert 0-255 ansteuern kann. Oder Leuchtbalkenreihe von 8 oder 10 Leuchtbalken. Danke. Gruss
Angehängte Dateien:
-
Bild_V0.46a-1.jpg
38 KB
Hallo, guten Tag. Wo finde ich diesen Drehregler und auch Anzeigenformat der 7Segmentziffern? Danke. Gruss
peter schrieb: > Wo finde ich diesen Drehregler und auch Anzeigenformat der > 7Segmentziffern? Du würfelst hier zwei völlig verschiedene Software Versionen durcheinander. Die neue Version 4 hat mit den alten Version 0.4xx nicht mehr viel gemein. In Vers. 4 sind z.Z. nur die Instrumente verfügbar, die in der Instrumenten Tool Box angezeigt werden. Wie Du aber siehst kommen laufend neue dazu. Den Drehregler kannst Du direkt durch den verfügbaren Analog Slider ersetzen.
Ja danke. Ich war jetzt auf der Internetseite, wo ich lesen konnte , was drin ist und was noch nachkommt. Danke für die info. Gruss
Angehängte Dateien:
-
Zuschneiden.jpg
58 KB
Ich habe gerade noch einen Fehler im Analogmeter festgestellt: 1.) wenn man die Skala haben will, dass Minus Werte oben stehen, dann klappt das nur bei der ersten Eingabe beim neuen Instrument. Änderungen an vorhandenen Instrumenten stellen die negativen Werte immer unten dar Es wird der Wert nicht vom Zeiger dargestellt, sondern nur oben als Zahl. Siehe Beispielbild. Beide Instrumente sind auf dem gleichen Kanal, die Werte rechts gehören zum rechten Instrument.
Warum wurde die erst Version 0... durch diese ab 4 ersetzt? Danke. Gruss
Dumme Frage, wie bekomme ich ein Background Icon hinter die Instrumente?
Rainer M. schrieb: > Ich habe gerade noch einen Fehler im Analogmeter festgestellt Werde ich in der nächsten Woche untersuchen. peter schrieb: > Warum wurde die erst Version 0... durch diese ab 4 ersetzt? In der 4 können die Instrumente beliebig oft platziert werden, die interne Struktur (Kanal-orientiert) ist wesentlich flexibler in den Ausbaumöglichkeiten und das User-Interface ist besser. Rainer M. schrieb: > wie bekomme ich ein Background Icon hinter die Instrumente? Ich werde hier noch wie beim Rahmen-Instrument die Möglichkeit anbieten es nachträglich in den Hintergrund zu setzen. Momentan geht es nur indem man das Background Icon zuerst setzt und dann das gewünschte Instrument.
:
Bearbeitet durch User
In der 4.0.9 geht eingehendes UDP nur, wenn auch COM aktiviert ist, d.h. beide grün. In der 4.0.8 funktionierte dies einwandfrei.
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.9.1 Erweiterungen für Instrument "Text Shape" - Kann wahlweise auf Vordergrund oder Hintergrund gesetzt werden. Einstellung dazu im Parameter Menue. Damit können auf dem Shape Instrumente oder Icons platziert werden. - Der optionale Text kann im Shape positioniert werden auf Center, Center oben und Center links. - Es wurde weitere vom MC setzbare Farben zugefügt: 6 = Cream (= Fenster Hintergrundfarbe) 7 = SkyBlue 8 = MoneyGreen Instrument "Backgrond Icon" kann wahlweise mit Klick auf Vordergrund oder Hintergrund gesetzt werden. UDP Fehler (UDP nur wenn COM aktiviert) behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComInstruments 4.0.9.2
Neues Instrument Switch Picture
(im Bild oben werden die Schalter beim Klick geöffnet/geschlossen)
- Bildelement ändert beim Klick den Bildinhalt.
- Geeignet z.B. für die Simulation von Schaltungen,
Linien-Verzweigungen, Schaltwarten, Geräten usw.
Es können beliebige Bilder/Grafiken eingefügt werden.
Für Grafiken mit transparentem Hintergrund ist z.B. das
gif- oder png-Format vorzuziehen.
Die Grafiken/Bilder sollten sich möglichst im Unterordner
BackgroundPicture befinden.
- 3 States (Bilder) möglich für Klick On, Klick Off, Disabeld
- Sendet den Klick-Status über die Schnittstellen.
- Auch vom Mikrocontroller steuerbar
Syntax: #kMs< wobei k=Kanal und s=Status [0,1,2]
0=BildOff, 1=BildOn, 2=BildDisabled
- Über die Buttons Front/Back im Parameter-Menue kann das
Switch Picture in den Vorder- oder Hintergrund gesetzt werden.
- Das Parameter Menue wird nicht über Doppelklick aufgerufen,
da sich sonst der Zustand ändern würde, sondern über einen
Klick mit der rechten Mouse-Taste.
- Die Status-Grafiken/Bilder werden beim Klick nicht zeitraubend
von der Harddisk geladen, sondern sind Bestandteil des Instrumentes.
Nur bei der Parametrisierung wird einmalig von der Disk geladen.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Angehängte Dateien:
Für die neue Version 4.0.9.2 hier noch ein Schalter Switch Picture Set als ZIP-Datei. Beispiel siehe Bild oben. Enthält 4 transparente Schalter mit allen Schaltzuständen und Orientierungen. Erstellt mit dem freien Greenfish Icon Editor als PNG und mit IrfanView in transparentes GIF überführt. Wer sich eigene Linien-Grafiken mit Greenfish erstellen möchte kann das mit folgenden Einstellungen (rotes Fadenkreuz für Mitte aktivieren): - Liniebreite 6 Pixel - Farbe mittleres Grau mit R=100, G=100, B=100 - Standard Icon-Masse z.B. 50 x 50, 100 x 50, 200 x 50 Pixel
:
Bearbeitet durch User
Hallo Albert, Dein Programm schreitet ja mit Riesenschritten voran. Toll. Herzlichen Dank! Ich wollte mal anfragen, ob die Notwendigkeit, bei jedem Update das Projekt immer wieder von Null auf neu aufbauen zu müssen, immer bleiben wird, oder ob es mal wieder so kommt (wie bei der früheren Version), daß man bei einem Update das Projekt (bzw. die Projekte) einfach so übernehmen kann. Das Updaten ist recht mühsam, das Neu-Aufbauen der Projekte eine gewisse Hürde. Das sollte man nicht unterschätzen. Das soll jetzt keine Faulheit meinerseits darstellen angesichts Deiner nicht zu knappen Arbeit, die Du in dieses Projekt steckst.
Günter R. schrieb: > Ich wollte mal anfragen, ob die Notwendigkeit, bei jedem Update das > Projekt immer wieder von Null auf neu aufbauen zu müssen, immer bleiben > wird, oder ob es mal wieder so kommt (wie bei der früheren Version), daß > man bei einem Update das Projekt (bzw. die Projekte) einfach so > übernehmen kann. Solange keine internen Strukturen geändert werden, können bestehende Projekte in neue Programmversionen übernommen werden. Das war bei den 2 letzten Versionen der Fall. Bei neuen Versionen werde ich eine Info geben wenn bestehende Projekte nicht direkt übernommen werden können. Übrigens wird in der aktuellen Version beim Aufruf der Switch Picture Parametrisierung noch versehentlich eine zusätzliche Meldung angezeigt. Dies wird in der nächsten Version korrigiert. Event. bekommen auch die Bilder für Switch Picture ein eigenes Verzeichnis, um sie leichter von den Background Icons unterscheiden zu können. Hat mich jetzt selber beim Auswählen der jeweiligen Bilder gestört :)
:
Bearbeitet durch User
Albert M. schrieb: > Bei neuen Versionen werde ich eine Info geben wenn bestehende Projekte > nicht direkt übernommen werden können. Das ist gut, prima, danke. Man könnte es aber auch automatisieren: wenn Du in ein abgespeichertes Projektfile eine Art Format-ID aufnimmst und diese beim Laden eines Projekts mit einem aktualisierten Programm gegenprüfst, könnte das Programmupdate erkennen, ob ein geladenes Projekt zur aktuellen Version paßt oder ob es neu aufgebaut werden müßte (d.h. ggf. eine Meldung anzeigen und evt. sicherheitshalber das Projektfile abweisen). Die gegenzuprüfende Format-ID müßte man dann immer um z.B. 1 erhöhen, wenn sich relevante Datenstrukturen ändern. So habe ich das mal bei einem älteren uC-Projekt mit gutem Erfolg realisiert.
Hallo Albert, ich habe mal eine Frage zur Trend-Erfassung und zu dem Abspeichern von Trenddaten. Ich habe schon mehrmals abgespeichert, aber bislang noch nie etwas mit diesen Daten angefangen, weil ich derzeit eine laufende Aufzeichnung der Solaranlagendaten nicht unterbrechen will. Ist es so, daß man Trenddaten laden kann und dann die laufende Aufzeichnung starten kann und die neuen Daten werden dann an die geladenen hinten dran gehängt, d.h. die Aufzeichnung läuft so weiter, wie man sie nach dem Abspeichern gestoppt hat?
Günter R. schrieb: > Ist es so, daß man Trenddaten laden kann und dann die laufende > Aufzeichnung starten kann und die neuen Daten werden dann an die > geladenen hinten dran gehängt, d.h. die Aufzeichnung läuft so weiter, > wie man sie nach dem Abspeichern gestoppt hat? Es werden beim Laden von gespeicherten Daten (wenn kein Clear Display erfolgte) diese dem aktuellen Kurvenverlauf angehängt. Nach dem Laden von Daten kann ebenfalls mit einer Erfassung fortgefahren werden. Es wird in jedem Fall eine Austastlücke zur Kennzeichnung angezeigt. Alte und neue Daten können wiederum zusammen in ein neues File gespeichert werden. Mit Rechtsklick auf Trend kann durch die Historie gescrollt werden. Gespeichert wird immer nur die Anzahl von Samples die in MaxRecords angegeben wurde. Bei Überschreitung von MaxRecords fallen bei jedem neuen Sample die ältesten Werte weg. Je nach PC RAM kann MaxRecords 100.000 Samples oder höher sein.
:
Bearbeitet durch User
Hallo Albert. ich verwende deine SerialComInstruments (alte Version) um die Koordinaten meiner CNC-Fräse zu visualisieren, wenn ich mit den Joysticks [http://www.harald-sattler.de/html/joystick-steuerung.htm#Joysticks] Stepimpulse erzeuge (solange es noch keine direkte Schnittstelle zu SerialComCNC gibt ;-) Ich habe allerdings ein Problem mit der Kommunikation zwischen µC (ein Arduino nano) und Rechner, sobald die empfangende Software auf dem Rechner SerialComInstruments (im Folgenden SCI) ist. Sobald ich die serielle SS in SCI aktiviere, funktioniert mein Programm auf dem µC nicht mehr, die Tasten und Joysticks werden nicht mehr abgefragt, es werden keine Steps mehr erzeugt. Natürlich ist das Ganze nicht so geradlinig wie eben beschrieben, sonst wäre die Fehlersuche (oder Ursachenforschung) ein Leichtes. Direkt nach dem Download einer geänderten Version der µC Firmware funktioniert alles prima, die Motoren laufen, die Koordianten werden angezeigt. Wird der Rechner gebootet, funktioniert die Steuerung wie vorgesehen. Wird dann SCI gestartet und verbunden, funktioniert mein µC-Programm nicht mehr wie gewünscht. Abhilfe: Reboot und SCI nicht starten. Alternativ kann ich ohne Reboot eine andere Serial-Software starten (den Seriellen Monitor der Arduino-IDE z.B.), die das Problem ebenfalls wieder aufhebt. Starte ich jetzt SCI wieder, werden sowohl Steps erzeugt, als auch die Koordinaten wieder angezeigt. An meinem µC-Code scheint es nicht zu liegen, ich konnte keine Verklemmer oder endless loops entdecken. Ich habe schon alles Mögliche getestet, finde aber keine Lösung für das Problem. Gerade habe ich dann einen seriellen Sniffer parallel laufen lassen, der mir als Unterschied zwischen Arduino-SeriellMonitor und SCI anzeigt, dass SCI die Leitung DTR: Off schaltet, Arduino hingegen DTR: On. Kann das das Problem verursachen?? Ich hoffe, du hast eine Idee. Kann ich testweise den Status von DTR bei SCI irgendwie beeinflussen? Gruß Harald
Anbei neue Version SerialComInstruments 4.1 Alle Beschränkungen entfernt: - Keine zeitliche Beschränkung mehr (bisher 2 Jahre). - Obfuscation, Virtuelle Protection Maschine und Länderbeschränkungen entfernt. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert, bin hoch erfreut, wieder von Dir zu hören. Ich hoffe, die Sommerpause hat Dir gutgetan und Du hast Kraft und neue Ideen gesammelt. Bin aber überzeugt davon, daß Du wieder tolle Fotos geschossen hast; muß demnächst mal wieder Deine Foto-Page besuchen (super Makrobilder ...). Auf jeden Fall herzlichen Dank dafür, daß Du die Beschränkungen aufgehoben hast. Werde diese Version testen und mich rückmelden. Kann man davon ausgehen, daß zunächst mal der gleiche Stand wie zuvor realisiert ist? Lieben Gruß Günter
Günter R. schrieb: > Kann > man davon ausgehen, daß zunächst mal der gleiche Stand wie zuvor > realisiert ist? Ja, es gibt funktional keinen Unterschied.
Herzlichen Dank Ulrich, ohne Begrenzung ist das wirklich ein großes Geschenk an die Community. Jetzt muss ich mich 'mal wieder um meine Fräse kümmern. Liebe Grüße Einhart
Einhart P. schrieb: > Jetzt muss ich mich 'mal wieder um meine Fräse kümmern. :) Versteh schon. Die Beschränkungen bei SerialComCNC werden auch entfernt.
Albert M. schrieb: > Versteh schon. > Die Beschränkungen bei SerialComCNC werden auch entfernt. Siehste! Und die denken alle du hättest keinen Humor. :-)
Bei mir war das keine Absicht - eher ein Freudscher Verschreiber :-). Dann noch 'mal Danke für SerialComCNC!
Albert M. schrieb: > Anbei neue Version SerialComInstruments 4.1 > > > Alle Beschränkungen entfernt: > Danke Albert! Da kann ich es ja dann doch noch benutzen... Die exe ist nun auch viel kleiner. Die Verschlüsselung und Laufzeitbeschränkung hat echt so viel mehr Bytes gekostet?
Hallo Albert, gehst du noch die aufgelaufenen Anfragen im Thread durch, oder ist Geschichte Geschichte? Ich frage, weil ich ja (eventuell?) ein Problem mit den "alten" (V0.8 oder V0.9) Instruments habe, die unter gewissen (für mich nicht nachvollziehbaren) Umständen meinen Joystick-Controller blockieren... Bezug ist dieser Beitrag: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Gruß Harald
:
Bearbeitet durch User
@Harald Sattler Dazu habe ich Dir im SerialComCNC Thread was geschrieben.
Abdul K. schrieb: > Die exe ist nun auch viel kleiner. Die Verschlüsselung und > Laufzeitbeschränkung hat echt so viel mehr Bytes gekostet? Ja, dies war insbesondere der zusätzlichen Virtual Machine geschuldet, die innerhalb von SerialComInstruments lief.
Hallo, ich habe das Programm erst jetzt wahrgenommen und gleich mal getestet. Macht einen super eindruck. Aber da kommen auch schnell eine Fragen auf: Kann man auch 2 oder mehr Datensender anschließen? Ich habe logischerweise mehr als nur ein Messsystem und müsste jetzt, wenn ich es richtig verstehe, alle an einen Kontroller anbinden und dann die Informationen weiter leiten. Das macht die Sache nicht gerade einfacher. Wenn ich schon mal dabei bin, die alte GPIB Geräte die ich habe, würde ich gerne auch einbinden. Viele Grüsse, Uli
Uli schrieb: > Aber da kommen auch schnell eine Fragen auf: > Kann man auch 2 oder mehr Datensender anschließen? Mehrere serielle Schnittstellen und event. direkte Bluetooth- und HID-Anbindung, wenn dies auf Interesse stösst, kommen demnächst. Uli schrieb: > Wenn ich schon mal dabei bin, die alte GPIB Geräte die ich habe, würde > ich gerne auch einbinden. Machbar, aber vorerst nicht vorgesehen.
Albert M. schrieb: > direkte Bluetooth- [...] Anbindung Ost ja nix anderes als eine serielle Schnittstelle o.O
Albert M. schrieb: > Alle Beschränkungen entfernt: Albert, du bist ein Schatz. > Mehrere serielle Schnittstellen und event. direkte Bluetooth- und > HID-Anbindung, wenn dies auf Interesse stösst, kommen demnächst. Stößt bei mir auf großes Interesse.
Mich würde dieses Feature auch interessieren. Günter
Ich habe heute festgestellt, daß sich das Verstellen der COM-Baudrate im Interface-Menü offensichtlich erst auswirkt, wenn man "trennt" und dann wieder "verbindet". Da könnte man überlegen, ob man nicht durch Auswahl aus der Baudraten-Liste den Event "Trennen/Verbinden" auslöst, sodaß das automatisch geht. Dann habe ich bei der Trendanzeige (mein wichtigstes Feature, wegen der Heizung) festgestellt, daß diese doch gelegentlich ausfällt, wenn man etwas verändert, oder u.U. auch durch kurze Datenfehler, wenn z.B. eine andere Datenquelle angesteckt wird, die zunächst eine andere Baudrate hat und man diese dann erst wieder in SerComInst anpaßt, s.o.. Dabei wird aber nach wie vor im Button oben "Stop Trend" angezeigt, also quasi der Run-Modus. Da könntest Du, wenn Du Zeit hast, mal nach der Stabilität der Trendanzeige schauen. Es wäre u.U. auch nicht schlecht, wenn man den Trendbutton oben - wie auch bei COM und LAN - grün einfärben würde, wenn die Aufzeichnung läuft, damit man das besser sieht. Danke. Günter
Hallo Günter, kommt mit auf die ToDo Liste. Gruss Ulrich
Hallo Albert, ich habe gerade die neue Version 4.1 von SerialComInstruments am laufen. Mir fallen gleich ein paar Dinge auf: Das COM-Terminal hat keine Option für einen automatischen Zeilenumbruch. Sobald die erste Zeile vollgeschrieben ist ändert sich hier nichts mehr. Ich kann nur im µC CRLF senden um sowas zu erzielen. Beim Trend-Instrument komme ich in die Parameteransicht in dem ich einen einfachen Klick mache. Bei anderen Instrumenten ist ein Doppelklick vonnöten. Generell finde ich den Doppelklick auch besser damit nicht jedes mal die Parameteransicht aufpoppt sobald man da versehentlich mal draufklickt. Desweiteren könnte man am Design noch feilen. Z.B. gibt es links und rechts fest eine Skala. Manchmal braucht man aber die rechte Skala nicht und würde sie gerne abschalten, das geht aber leider nicht. Für Ch3 und Ch4 hat man dann gar keine Möglichkeit, die Skala anzupassen. Schön wäre auch, wenn man die 4 Kanäle irgendwie benennen könnte und dieser Name dann vielleicht sogar in der entsprechenden Kanalfarbe irgendwo entweder als Legende oder direkt im Plot an den Linien anhaftend angezeigt wird. Und noch ein weiterer Vorschlag, was sinnvoll wäre: Eine Liste mit allen Kanalnummern/Werten, die gerade über die Serielle Schnittstelle reingekommen sind. Ansonsten: Nützliches Programm! verwende ich gerne! lg Paul
:
Bearbeitet durch User
Angehängte Dateien:
Hallo Albert, hier mal Trendanzeigen, bei denen ein Meßwert den definierten Bereich verläßt (Boiler Unten / Solar, ist jetzt natürlich kalt, unter 20 Grad im Boiler); die grüne Linie macht ganz wilde Ausschläge. Vielleicht kannst Du gelegentlich danach schauen; sollte wohl so sein, daß sich entweder eine Bodenlinie ergibt - oder gar keine Linie. Bei Rechtsklick in der Trendanzeige meldet sich ja die "Trend Anzeige"; der Ende-Button scheint mir nicht so ganz zu funktionieren (Begin-Button dagegen schon). Bei Klick auf "Ende" ist der Bildschirm zunächst leer, beim Scrollen nach rechts kommt aber nicht (immer) das Datenende in den sichtbaren Bereich, sondern ein Bereich viel weiter links. Da wäre es schön, wenn "Ende" z.B. das Datenende in die Bildschirmmitte brächte. Version ist 4.1.0.0 (also die neueste Version). Gruß Günter
Hallo Günter, Günter R. schrieb: > Trendanzeigen, bei denen ein Meßwert den definierten Bereich > verläßt Das ist ein Problem der zugekauften Instrumenten Komponenten. Den Hersteller hatte ich bereits darauf angesprochen, er will aber aus unerfindlichen Gründen vorerst daran nichts ändern. Abhilfe ist z.Z. nur möglich indem bereits im MC der auszugebende Wert auf Über/Unterschreiten überprüft und entsprechend gesetzt wird. Um das Problem aber generell zu umgehen, werde ich in einer der nächsten Versionen die Min/Max-Überprüfung der betroffenen Instrumente direkt in SerialComInstruments ausführen. Zudem diskutiere ich nochmal mit dem Komponentenhersteller. Günter R. schrieb: > Trend-Anzeige der Ende-Button Gleiches Komponenten Problem wie oben. Wird auch mit dem Komponenten Hersteller diskutiert. Paul H. schrieb: > COM-Terminal hat keine Option für einen automatischen Zeilenumbruch. Wird geändert. Paul H. schrieb: > Eine Liste mit allen Kanalnummern/Werten, die gerade über > die Serielle die Schnittstelle reingekommen sind. Das wäre ja nichts anderes als ein COM-Monitor als neues Instrument. Mal schauen :)
:
Bearbeitet durch User
Angehängte Dateien:
Hallo Albert,
ich hatte die "stillen Tage" über Weihnachten genutzt, um mir ein neues
abgespecktes 1-Wire-Thermometer für meine Heizungsanlage zu bauen, mit
ATmega168 und ohne LCD-Display. Alle Daten möchte ich jetzt viel
komfortabler direkt in SerComInst anzeigen lassen, d.h. die Textausgaben
in Textboxen am PC. Daher habe ich jetzt erstmals die Instrumente "Num
Display" (zur Anzeige der Anzahl von aktiven 1-Wire-Devices und
Fehlerzahlen) und "Text" (zur Anzeige der Sigon-Message und für
Fehlermeldungen) eingesetzt. Dabei fallen mir einige Probleme auf:
- Es scheint Fehler zu geben beim Speichern der Instrumente "Text" und
"Num Display". Bei Erstellung des Projekts funktionierte alles prima,
aber nach Speichern und Neu-Laden waren die genannten Instrumente
teilweise außer Funktion.
- Ruft man die Einstellungs-Menüs durch Doppelklick auf, so passiert es
gelegentlich (aber nicht immer), daß sich die Schriftart und -größe
ändert (z.B. von "Courier New" auf "MS Sans Serif").
- Beim Text-Instrument und beim Num-Display-Instrument gibt es Probleme
nach Laden des Projekts; diese interpretieren andere Kanäle als die, die
für sie vorgesehen und eingetragen sind. Wenn man dann ins
Einstellungen-Menü geht und Save macht, funktioniert es wieder,
allerdings verstellt sich dann mitunter die Schriftart, obwohl im
Font-Feld immer noch die richtige Schriftart steht (Courier New). Bei
nochmaligem Aufruf des Einstellungs-Menüs steht dann die veränderte
Schriftart im Font-Feld.
Diese Kanal-Fehler sieht man beim zweiten Screen-Shot, bei dem im oberen
Textfeld "10.0" steht, und im untersten Num-Display ("Err85"), bei dem
"10" steht statt "0" (diese "10.0" sollten nur bei den
Meter-Instrumenten landen als deren Initialisierung).
- Beim Text-Instrument kann man ja die Textbox mittels "ClrText"
löschen. Das funktioniert gut. Kann man den Text "ClrText" auch in
anderen Text einbetten (wohl nicht?) oder muß ein eigener Datensatz wie
z.B. "#12MClrText<" gesendet werden, damit dies erkannt und darauf
reagiert wird?
- Beim Speichern eines Projekts sollte m.E. der Dateninhalt eines
Instruments nicht mitgespeichert werden, sodaß beim Laden eines Projekts
die Instrumente zunächst "leer" sind.
- Es wäre praktisch, wenn es einen Initialisierungsbefehl für das ganze
Projekt gäbe, sodaß vom Microcontroller her die ganze Maske gelöscht
werden könnte. So einen Befehl würde der uC senden, wenn man dort dessen
Reset-Taste drückt.
Ich habe gesehen, daß Du jetzt wieder beim CNC-Projekt aktiv bist. Das
ist prima. Diese obigen Anregungen eilen ja nicht. Ich bin geduldig.
Vielleicht hast Du in näherer Zukunft mal Zeit, Dich damit zu befassen.
Vielen Dank.
Liebe Grüße und ein gutes Neues Jahr!
Günter
Angehängte Dateien:
-
SCI_Skalierung.png
60 KB
Hallo Günter, Dir auch ein gutes Neues Jahr! Danke für Deinen Bug Report. Werde ich schnellstmöglich abarbeiten. Noch etwas zur optisch gefälligen Skalierung der Instrumente. Ich stelle immer wieder bei den eingestellten Bildern fest, dass die Instrumente durch nicht korrekte Parameter unschöne Skalierungen mit krummen Werten ergeben. Richtig skalierte Instrumente (siehe Bild oben) ergeben sich mit der einfachen Formel: SkalaSteps = (AnzeigeBis - AnzeigeVon) / GewünschteTeilung Beispiel am obigen Instrument 3, gewünschte Teilung 5er Schritte: SkalaSteps = (50 - 10) / 5 = 8 Ein gerades Vielfaches oder ein gerader Teiler des Wertes von SkalaSteps passt dann auch immer. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Albert M. schrieb: > Ich stelle immer wieder bei den eingestellten Bildern fest, dass die > Instrumente durch nicht korrekte Parameter unschöne Skalierungen mit > krummen Werten ergeben. Hallo Albert, da hast Du absolut recht. Es ist allerdings so, daß diese vier Analog-Meter unten normalerweise bei 20 Grad beginnen (dann sind sie schön skaliert), jedenfalls ist es bei der Nutzanwendung im Heizraum so. Der Aufbau des neuen Thermometers fand aber im "Bastelkeller" statt, der kälter als 20 Grad ist, daher habe ich auf die Schnelle und ohne auf die Optik zu schauen, die unteren Grenzen abgesenkt; da waren mir die Text-Instrumente wichtiger als die Temperaturen, die ja seit langem perfekt funktionieren (auch die Analog-Meter dazu). Aber danke für den Hinweis und die Formel. Günter
So, Ich habe das mir mal geladen und 1h getestet. Das sieht eigentlich nicht schlecht aus, aber: 1) Das Aufrufen des Interface Editors gelingt nicht (sofort). Ich muss immer in den Betriebsdialog, statt in den Konfigmodus - dann geht es. 2) Leider gehen manche Klicks dafür ins Leere. Es ist mir nicht möglich, Buttons oder die dafür vorgesehen Areale zu wählen.(?) 3) Ich bin auch generell nicht in der Lage, platizerte Elemente wieder zu löschen! Auch wenn ich den IF-Editor offen habe und z.B. Farben verändern konnte, oder Texte, geht ein Klick auf "Löschen" ins Leere. Das Objekt bleibt. (??) 4) Die Anzeige ist ungeschickt. Man müsste unterscheiden, zwischen dem Wert der gesendet wird und dem der angezeigt werden soll. Die Anzeige müsste sinnvoller Skalieren. Beispiel: Ich weil von 0...125% Regeln, der dazu passende Wert ist aber mit 0...2047 skaliert. ?
Manual lesen hilft. Grundrechenarten helfen bei der Skalierung auch. Und .... ich hab keine Lust darauf weiter zu antworten, keine Deiner "Feststellungen" ist zutreffend.
:
Bearbeitet durch User
Angehängte Dateien:
-
screen.gif
28 KB
Laut Manual soll man durch einen Doppelklick das Element editieren
können. Das habe ich gemacht. Es öffnet sich garnichts. Man muss des
Interface manuell anwählen, dann kommt manchmal was. Man muss aber
nervig mehrfach ergebnislos auf das Element klicke. Das ist mal Fakt.
Und: Das Löschen geht nicht. Weder ein button, noch ein Regler lassen
sich wieder entfernen. Auch die Uhren nicht.
Die habe Ich vorgefunden, nachdem Ich den slider weggerutscht habt.
>Grundrechenarten
Ich habe erklär, wozu man zwei Skalen braucht.
Instrumente platzieren, verschieben, Grösse ändern im Design Mode (Gitter-Raster wird angezeigt) Instrumente editiere und löschen im Anzeige Mode (Gitter-Raster wird nicht angezeigt) Umschalten der Modes über Button "Design Toggle" Instrument löschen: Klick rechte Mousetaste auf Instrument. Instrument editieren: Doppelklick auf Instrument. Skalieren über Skalierungsfaktor. Deine Erklärung weswegen Du 2 Skalen brauchst ist nicht wirklich verständlich. Egal - mach einfach zwei Skalen mit dem gleichen Kanal aber unterschiedlichen Skalierungsfaktoren.
Markus W schrieb in einem Parallel Thread: "Es geht auch darum, dass eine Person, die das nicht so perfekt kann, sich für eine Schaltung etwas zusammenbauen können soll. Z.B. der Kunde oder eine Praktikant beim Kunden oder jemand bei mir." Hast Du die Nutzungsbedingungen von meinem Programm auch gelesen? Die meine ich wirklich ernst.
Beitrag #4853975 wurde von einem Moderator gelöscht.
Man könnte an dieser stelle mal das "Prinzip der geringsten Überraschung" einwerfen. https://de.wikipedia.org/wiki/Principle_of_Least_Surprise Als konstruktive Kritik mein Vorschlag an dich, Albert, dieses Prinzip an der ein oder anderen Stelle noch etwas mehr zu beherzigen, sofern deine Software auch auf die Benutzung durch andere User gedacht ist :-)
Gibts denn irgendwo eine noch lauffähige V0.x? Hat sich jetzt bei mir verabschiedet (das interessante feature der Laufzeitbegrenzung :-) Ich brauch nur die Digitalanzeigen, die es wohl bei der 4.x nicht mehr gibt.
Darf man erfahren, welche Erkenntnis Du gehabt hast? Ich verwende SerComInst auch intensiv. Die neue Version 4.1 (ohne Laufzeitbeschränkung) ist ja viel universeller als die 0.x-Versionen u.a. durch die freie Kanalzuordnung. Günter
Habe erst die 4er-Version versucht, aber da sind die Digital-Anzeigen unbrauchbar (Grösse). Dann noch mehrere 0.x-Versionen (die Laufzeitbegrenzung sollte doch bei Einstellung der Weiterentwicklung entfernt werden??). Ging jedenfalls keine der versuchten mehr. -> ComVisu, funktioniert.
Die Weiterentwicklung ist ja m.W. durchaus nicht eingestellt, sondern pausiert höchstens. Und warum sollte Albert an alten Versionen herumändern? Da steckt er seine Zeit lieber in die aktuelle Version.
Eben, deswegen denke ich ja, dass an der alten Version nichts mehr getan wird. Albert M. schrieb: > Ja, wie zur Zeit auch. Daran wird sich auch zuerst mal nichts ändern. > Die zeitliche Begrenzung der aktuellen Version beträgt, wie auch für > weitere Versionen, jeweils 1 Jahr vom Veröffentlichsdatum. Wenn Du immer > eine einigermassen aktuelle Version benutzt dürfte das kein Problem > sein. Falls ich das Projekt mal beende, werde ich als letzte Version das > Zeitlimit aufheben. Und es kann ja leicht passieren, dass er gar nichts mehr dran macht oder vielleicht auch gar nichts mehr machen kann. In beiden Fällen steht man spätestens nach einem Jahr da. Wozu der Selbstzerfalls-Mechanismus überhaupt gut sein soll, hat sich mir auch noch nicht erschlossen (wurde hier aber wahrscheinlich schon behandelt, habe es aber nicht gelesen/gefunden).
@H.Joachim Seifert Keine Panik, es geht nichts verloren :) Anbei geänderte alte Version SerialComInstruments v0.9 v0.9 Change Log --------------- Alle Limitierungen entfernt. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Ulrich, vielen Dank dafür! Auch mir gefällt die Koordinatenanzeige in der alten Version besser als in der Neuen, wobei ich nur mal ganz am Anfang bei der V4 kurz reingeschaut habe. Vielleicht gibt es ja inzwischen hier auch schon etwas Passenderes... Gruß Harald
Tolle Arbeit Ulrich! Installiert - V24 angeschlossen - läuft. Wenn ich einen Wunsch äußern darf. Eine Umschaltung auf Hex-Darstellung würde das „Num Display“ noch schlagkräftiger machen :-)
Angehängte Dateien:
Hallo Albert, heute stellte ich wieder mal fest, daß die Trend-Aufzeichnung von alleine angehalten hat. Die Aufzeichnung läuft seit dem letzten "Clear Display" schon seit Wochen. Die Anzahl Records habe ich auf "200000" eingestellt. Könnte es sein, daß hier eine Grenze erreicht wurde und die Aufzeichnung aus diesem Grund anhielt? Ich meine, früher mal gelesen zu haben, daß beim Erreichen der Grenze ältere Datensätze gelöscht werden, also Funktion wie ein überschreibender Ringpuffer. Mag da ein Bug drinstecken? Ich habe mal das Projekt beigepackt sowie Screenshots und die Trenddaten dazu. Vielleicht hast Du mal Langeweile und magst drüberschauen. Vielen Dank. Lieben Gruß Günter
Hallo Albert, heute habe ich mal das "Terminal" eingesetzt, um die empfangenen Daten zu beobachten. Da von meinem Thermometer immer gleich ein Schwung von mind. 6 Kanälen kommt, laufen die Daten im Terminalfenster nach rechts raus und können nicht kontrolliert werden, da kein Rollbalken entsteht bzw. die Daten nicht umgebrochen werden (was noch besser wäre als ein Rollbalken). Könntest Du da gelegentlich einen Umbruch einbauen? Andererseits: ein vom uC eingefügtes CRLF nach jeder Nachricht wird doch m.W. von SerComInst auswertungsmäßig ignoriert. Das würde doch zunächst auch helfen? Was auch toll wäre (ich glaube, das hat auch schon mal jemand vorgeschlagen): ein Monitor für Nachrichten der Form "#xxxMvvvv<" jeweils in einer eigenen Zeile; die zu beobachtende Kanalnummer sollte angegeben werden können (Filterung), oder auch bis zu beispielsweise 5 Kanäle gleichzeitig (und alle anderen für das Monitoring ignorieren). Das wäre zum Debuggen sehr hilfreich. Gruß, Günter
Hallo, Ulrich! Wir sind bei der Netzsuche auf Dein Visualisierungsprogramm gestoßen, nachdem wir zunächst nur die einlaufenden Daten per terminal-Programm eingelesen hatten. Ich bin Elektroautofahrer aus Krefeld mit ramponierten Nicad-Akkus und um auf einen grünen Zweig zu kommen, versuche ich alle 20 Batteriespannungen in ihrem Verlauf (Trend) möglichst gleichzeitig und über lange Zeit darzustellen.10 Tinies liefern als daisy chain völlig störungsfrei die Daten und diese werden ebenso störungsfrei, ohne Quarzsteuerung, über die Zweidraht-Schnittstelle in Deinem terminal fehlerfrei dargestellt. Was auch ganz wunderbar funktioniert, die Darstellung im Trend-grapher, aber nur für maximal 5 Eingänge. Kommt der 6.hinzu, werden die ersten 5 Linien noch alle richtig und stabil dargestellt, aber ab dem 6. Kanal springt die Anzeige unmotiviert zwischen dem aktuellen Wert und der Nullinie hin und her, und die folgenden Kanäle ebenso. Wir haben herumgerätselt und sind inzwischen überzeugt, der Fehler muss aus der software kommen. Wir programmieren in Delphi 6.1 und würden gerne diese Unzulänglichkeit beseitigen. Als einen möglichen Ausweg haben wir gefunden, mehrere Trendfenster zu öffnen und jeweils nur 5 Kanäle darzustellen, was aber den Vergleich erschwert. Wir hätten gerne alle 20 Kanäle in einem Bild. Neu programmieren, das wäre sicherlich nicht sinnvoll. Wir wissen, wieviel Arbeit in Deinem Projekt steckt. Wir kämen sicherlich zurecht, wenn wir Einblick in den sourcecode hätten und könnten diese Verbesserung mit Sicherheit alleine bewerkstelligen und hier öffentlich machen. Krefeld ist nicht weit von Mönchengladbach und mein Elektroauto schafft die Strecke (noch). Eine zweite Ergänzung betrifft die Trendaufzeichnung, in der wir keine Möglichkeit haben, zu scrollen, wenn wir einmal kürzere Zeitabläufe darstellen wollen, der Cursor läuft immer von links bis rechts an den Bildrand und bleibt dann stehen. Das wäre sicherlich einfach zu ändern, aber eben nur mit Einblick in den sourcecode. Sicherlich sind auch unsere Messplatinen für viele interessant, weil sie sich sehr universell anwenden lassen: bei zwischen 3 und 20 mA Stromaufnahme ab 3,7 Volt liefert eine Platine 8 Messwerte mit 9600 baud über Optokoppler (open collector) auf den Zweidrahtbus , der über einen USB -Adapter das laptop versorgt. Als nächste Anwendung denken wir an die Langzeitaufzeichnung aller möglichen Messwerte einer Wassermühle, die als Inselanlage unter anderem Elektroautos versorgt. Energieernte, Spannungen und Ströme, Wasserstände usw. dafür haben wir bereits einen Steuerungsrechner in Betrieb. Nicht unpraktisch wäre es aber, wenn wir auch die im laptop eingelesenen Werte per Delphi verarbeiten und nutzen könnten...mit Zugänglichkeit und öffentlicher Darstellung per Internet. Bernd
@ Günter R. (galileo14) Betr.: Trendaufzeichnung bei langen Laufzeiten Die Aufzeichnung darf nicht stehenbleiben. Die ältesten Werte werden immer gelöscht. Betr.: Terminalfenster Schau ich mir an und werde es falls notwendig korrigieren. Betr.: Monitor für Nachrichten der Form "#xxxMvvvv<" jeweils in einer eigenen Zeile. Lässt sich implementieren, event. auch mit zusätlicher Farbcodierung. Leider lässt meine Schaffenskraft bekannterweise während den schöneren Jahreszeiten wie immer nach, daher wird ein Update noch etwas auf sich warten lassen.
Bernd S. schrieb: > Kommt der 6.hinzu, werden die ersten 5 > Linien noch alle richtig und stabil dargestellt, aber ab dem 6. Kanal > springt die Anzeige unmotiviert zwischen dem aktuellen Wert und der > Nullinie hin und her, und die folgenden Kanäle ebenso. Welche Version? Dieser Fehler kann auftreten wenn die Messwerte die eingestellten Parameter über/unterschreiten. Bernd S. schrieb: > Eine zweite Ergänzung betrifft die Trendaufzeichnung, in der wir keine > Möglichkeit haben, zu scrollen, wenn wir einmal kürzere Zeitabläufe > darstellen wollen, der Cursor läuft immer von links bis rechts an den > Bildrand und bleibt dann stehen. Welche Version? Bitte den Fehler genauer beschreiben. Bernd S. schrieb: > Wir kämen sicherlich zurecht, wenn wir Einblick in den sourcecode hätten Der Source Code ist nicht öffentlich. Bernd S. schrieb: > ...mit Zugänglichkeit und > öffentlicher Darstellung per Internet. Einfach das integrierte LAN/UDP Interface nutzen. https://www.youtube.com/watch?v=xE1IDJpjF50
Jetzt hat mein Video schon 523 Views. //*stolz*//
:
Bearbeitet durch User
Beitrag #4965717 wurde von einem Moderator gelöscht.
Beitrag #4965776 wurde von einem Moderator gelöscht.
Beitrag #4965834 wurde von einem Moderator gelöscht.
Beitrag #4966655 wurde von einem Moderator gelöscht.
Beitrag #4966757 wurde von einem Moderator gelöscht.
Beitrag #4966766 wurde von einem Moderator gelöscht.
Beitrag #4966915 wurde von einem Moderator gelöscht.
Herrje, gefällt da jemandem Deine Nase nicht? Albert hat sich viel Mühe mit seinem Programm gegeben und stellt es auch noch kostenlos zur Verfügung. Welchen Grund habt Ihr für Eure Störungen? Hallo, Ulrich! Logview läuft nicht mit unserer hardware, aber mit Deinem Programm. Die zeitlich wild einlaufenden Daten werden abgezählt und richtig eingeordnet. Stabil und zuverlässig und richtig in Deiner Version serialcominstruments 4.1.0.0 angezeigt. Aber nur im terminal. Immerhin, der Rest lässt sich sicherlich noch lösen. Ich habe vergessen, meine Antwort abzuschicken und die ging dann verloren. Sicherlich nicht schlimm, denn inzwischen habe ich eine Lösung gefunden, wie ich mit den noch vorhandenen Störungen fertig werde. Insbesondere bin ich darauf gekommen, dass ich über die "display-Wahl" mehr als vier Kanäle darstellen kann, und fünf mal vier Kanäle sind eben auch 20, so viel, wie mein Citroen Saxo electrique Batterien hat. Ab dem 5. Kanal fangen die Anzeigen an, zu springen, aber nicht, wenn ich ein zusätzliches neues display anlege. Also, es funktioniert so und auch der simple graph mit seiner Verschiebbarkeit ist eine große Hilfe. Dein Programm ist also wie gemacht für unsere hardware , oder auch umgekehrt. Das wäre eigentlich ideal: (Wunsch an den Osterhasen) Alle 20 Batterien in einer einzigen oszillographischen Darstellung, verschiebbar, per offseteinstellung. Am liebsten aber noch mehr, der Citroen Berlingo hat 27 Akkus, der Tesla über 100 hintereinanderliegende Einzelzellen. Deshalb die Offseteinstellung: Normal, wenn alles in Ordnung ist, laufen alle im Pulk, wie bei der tour de France und uns interessieren nur die, die aus dem Pulk herausfallen und eigene Wege gehen. Das kann man, ohne die Aufmerksamkeit für die Straße zu verlieren, auch ohne Anhalten und längere Betrachtung erkennen. Auch nach der Fahrt ist noch alles gespeichert und lässt sich voll und ganz zurückholen. Also, Supersoftware, die Du da gemacht hast. Dass man mehr als 5 Kanäle fehlerfrei in einer einzigen Anzeige darstellen kann,lässt sich ja wohl noch leicht bewerkstelligen? Im terminal wird ja alles richtig dargestellt. Ich denke nicht, dass wir uns hinsetzen müssen und eine eigene software schreiben, nach der Arbeit, die Du und Deine Helfer sich gemacht haben? Dass das viel Arbeit ist, wissen wir. Du wohnst 30km von mir und ich kann mir vorstellen, dass Dich interessiert, wo Deine software einsetzbar ist und würde, sofern Du es wünschst, gerne vorbeikommen und es Dir vorführen. Ist aber jetzt noch ein wenig früh und wir sind noch mit dem Einbau in der korrosiven Atmosphäre des Elektroautos beschäftigt. Wenn es läuft, kommt das Ganze in alle Elektroautos, gleich, welche Art von Batterien! Ich misstraue Batteriemanagementsystemen, hier hat man, im Gegensatz zu diesen, alles im Blick! Wenn Elektroautos eines nicht mögen, wie bei mir, unterschiedliche Batterien. Mit Deiner software, so denke ich, bekommen wir schnell eine Übersicht und können aussortieren, was das Fahren unerträglich macht. Danke! Bernd
Irgendwie hakelt bei mir die Anzeige des Forums. Wahrscheinlch, weil ich einiges ausgeschaltet habe, weil ich Werbung nicht so spannend finde...Aber ich stelle gerade fest, dass mein letztes posting doch angekommen ist, hergestellt während des Ladens in Düsseldorf. Wie ich es sehe, werde ich zukünftig viel Zeit zum Testen von serialcominstruments haben... Bei 4,5 Stunden Ladezeit bei ganz leeren Akkus hat man ja wohl nichts Gescheiteres zu tun, wenn die Ladesäule in der Walachei steht. Wie machen das bloß die Helipiloten, in 20 Minuten vollzuladen?
Die laden mit 3C Aber bei einem Auto brauchts dafür dicke Kabel und viele kW an der Ladesäule. Aber das weisst du bestimmt schon ;-)
:
Bearbeitet durch User
Ja, es wird Zeit, dass ich mal wieder die Heli-Piloten in Düsseldorf-Lörick besuche. Die sind immer auf dem neuesten Stand. Die Nicads meines Saxos vertragen 2C. Ehe ich die aber anwenden kann, muss ich dafür sorgen, dass alle Akkus genau gleich sind. Im Moment sind sie es nicht und es ist schwer, alle 20 in getrennten, geschlossenen Kisten zu überwachen, die sich unter dem Fahrzeug befinden. Wir haben jetzt eine hardware gebaut, die alle Spannungswerte auf einen Zweidrahtbus, der durch das ganze Fahrzeug und an eine USB-Schnittstelle führt. Etliche Fehlerquelen tauchen auf, an die man so schnell nicht denkt. So, wenn das windows nach einem update das Programmiergerät nicht mehr richtig bedient... Überläufe, da haben wir auch noch mit zu kämpfen und im serialinstruments scheinen auch noch einige Fehler versteckt zu sein. Schwierig, wenn man nicht selbst durch den Code steigt und wir haben jetzt kurzerhand die Saftware neu geschrieben. Die läuft jetzt, bis auf einige Unstimmigkeiten, ganz hervorragend und genau. Nur so konnten wir unterscheiden, was auf unsere Künste, auf Fehler der hardware und was auf Alberts Programme zurückzuführen ist. Der Aufwand war unbedingt erforderlich, denn nun konnten wir vor allem die hardwarefehler einkreisen und beseitigen. Damit läuft merkwürdigerweise jetzt auch Alberts Programm ganz ungleich stabiler. Das terminal hatte nie einen Fehler gezeigt, aber die graphische Darstellung. Mal sehen, was wir von Alberts Programm noch verwenden werden. Einen Fehler zu suchen, ist schwerer, als selbst zu programmieren. Manche sind alleine auf Missverständnisse zurückzuführen. Also, um eigenes Programmieren führt kein Weg. Gleich, in welcher Sprache, denn wir brauchen keine schnelle Messung. Wir verwenden Delphi.
Angehängte Dateien:
Hallo Albert, heute ist mir wieder ein ominöser Abbruchfehler (Hänger) an Trendinstrumenten untergekommen, siehe Screenshots; diesmal aber so, daß die Trendaufzeichnung weitergelaufen ist, ohne aktualisierte Meßwerte zu beachten. Daß welche kommen, konnte ich über die Bargraph-Instrumente verifizieren (Registerkarte "Display 1"). Dort sah ich, daß sich bei jeder Messung meiner Thermometerapplikation z.B. die Kesselwerte langsam geändert haben, sich bei den Trendanzeigen jedoch gerade Linien ergaben ohne Struktur. Bei früheren Trend-Abbrüchen wars aber immer so, daß überhaupt nichts mehr geschrieben wurde und nicht eine gerade Linie wie jetzt. Ich habe dann "Stop Trend /Start Trend" gemacht, dann liefs wieder. Viele Grüße Günter
Hallo Albert, bin auch diese Woche erst von einem anderen Forum auf Dein Programm aufmerksam gemacht worden. Das ist genaus das, was ich für mein Quadrocopter Projekt gesucht habe. Bin nicht so versiert wie die meisten anderen Autoren, aber ich finde es einfach toll. Habe auch direkt erfolreich ausprobiert. Die Dokumentation ist einfach zu verstehen. Ich bin an den 270° Anzeigen interessiert. In der 4er Version gab es die. In der aktuellen Fassung sind sie disabled. Hat das einen Grund? In diesen langen Beitrag habe ich es vielleicht übersehen? Nochmals vielen Dank für die tolle Arbeit, ich beobachte weiter. Willi
Ich komme etwas mit den Versionen durcheinander. Die aktuellste ist die 4.1 richtig? Gibt es da kein Hintergrundbild?
:
Bearbeitet durch User
I will try in english. If there is no data being received anymore, then the instruments will keep showing the last received data. Is there a way that the instruments (meters) show 0 or "NO DATA" a timeout period of XX sec thanks for reading
Ich habe auch noch eine Frage. Ich möchte mittels udp auf einen MC senden. Wo kann ich die IP Adresse des Empfängers einstellen? Und sind mehrere Empfänger möglich?
Albert M. schrieb: > Hast Du die Nutzungsbedingungen von meinem Programm auch gelesen? Ich lese daraus, dass es nicht beabsichtigt ist, dass Programm kommerziell zu verwenden. Mögliche Lizenzen hin oder her hat es wohl nicht den Standard, um dort genutzt zu werden. Rein privat brauche ICH das eher weniger. Meine Anforderungen an eine RPS bestehen weiterhin.
Hallo, vielleicht bin ich der Einzige hier, der beim Schließen des Programms die Fehlermeldung bekommt:Zugrifffehler bei Adresse xxx in Modul SerialComInstruments.exe. Lesen von Adresse xxx. Diese Meldung kommt nur, wenn ich mittels Arguino Daten sende und dann irgendwann das Programm schließe. Wenn ich das Projekt aufrufe und keine Verbindung zum Arduino herstelle, schließt es ordnungsgemäß. Ich verwende Windows10
Jörg R. schrieb: > Hallo, vielleicht bin ich der Einzige hier, der beim Schließen des > Programms die Fehlermeldung bekommt:Zugrifffehler bei Adresse xxx in > Modul SerialComInstruments.exe. Lesen von Adresse xxx. Diese Meldung > kommt nur, wenn ich mittels Arguino Daten sende und dann irgendwann das > Programm schließe. Wenn ich das Projekt aufrufe und keine Verbindung zum > Arduino herstelle, schließt es ordnungsgemäß. Ich verwende Windows10 Hab das Programm im Kompatibilitätsmodus laufen! So funktioniert alles einwandfrei.
Hallo, bin wieder mit mit Deinem Programm beschäftigt. Ich möchte es zum debuggen meines Quadrocopter Projekts verwenden. Einige Instrumente sind aber ausgegraut, bzw. fehlen in der Version 4.1. wie z.B. das PID Instrument. Sind diese Instrumente noch zu erwarten? Wäre echt super. MfG Willi
Hallo, ist dieser Beitrag tot, oder gibt es eine Fortsetzung in einen neuen Thread? Für eine Info wäre ich sehr dankbar. Warum wird eine BT Verbindung nicht aufgelistet? LG und schöne Ostern Willy.
Hallo, anscheinend führt der download-link für SerialComInstruments 4 immer auf diese Seite, hier kann man jedoch nur die v0.9 runterladen. Weiss jemand, wie man an die v4 rankommt? Gruß, Wolfram.
Beitrag #5394022 wurde vom Autor gelöscht.
Hallo Wolfram, hinter dem Link steht noch ein "Anker" (die Nummer hinter dem #) auf den pasenden Beitrag hier im Thread: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle"
Beitrag #5394492 wurde von einem Moderator gelöscht.
Das glaube ich eher nicht. Eher glaube ich, dass er es wegen zuviel PN und zuviel Wunschkonzert offline genommen hat.
Heiner schrieb im Beitrag #5394492: > Hmm, vielleicht hat der Albert ja schon die Dollars in den Augen und > möchte > Kohle machen? Ich glaube das hat er nicht nötig. Vielleicht geht es ihm nicht gut oder er ist im schlimmsten Fall schon verstorben. Ich weiß, dass er wohl so seine körperlichen Probleme hatte. Er ist bestimmt nicht everybody's darling, aber ein netter Kerl.
Wenn dem so ist, tut es mir wirklich leid.
Beitrag #5396296 wurde von einem Moderator gelöscht.
Bin weder bereits verstorben, noch krank und erfreue mich bester Gesundheit. Fürs Proggen habe ich keine Lust. Und wie ich sehe wurden diverse Hate Beiträge auch bereits von den Admins entfernt. Meine Zeit vertreibe ich mir lieber mit Reisen, Natur, Fotografie oder reines Nichtstun. Gruss Ulrich Albert https://www.facebook.com/Ulrich.A.Maassen
:
Bearbeitet durch User
Albert M. schrieb: >..... > > Meine Zeit vertreibe ich mir lieber mit Reisen, Natur, Fotografie oder > reines Nichtstun. > >...... Genau so würde ich das auch machen ;-) Christian
Christian B. schrieb: > Albert M. schrieb: > >>..... >> >> Meine Zeit vertreibe ich mir lieber mit Reisen, Natur, Fotografie oder >> reines Nichtstun. >> >>...... > > > Genau so würde ich das auch machen ;-) Die Frage, die sich dann stellt, ist jedoch: Wird es mit dem Projekt weiter gehen, wenn der Winter naht (haha Game or Thrones Anspielung), oder hat Albert grundsätzlich keine Lust mehr, auf programmieren? Beides könnte ich verstehen.
Martin S. schrieb: > Die Frage, die sich dann stellt, ist jedoch: Wird es mit dem Projekt > weiter gehen, wenn der Winter naht (haha Game or Thrones Anspielung), > oder hat Albert grundsätzlich keine Lust mehr, auf programmieren? Beides > könnte ich verstehen. Es gibt Lust und Laune Projekte, die macht man solange wie man mag. Irgendwann ist mal Schluß mit Lust oder es gibt andere Prioritäten. Wie es mit dem Projekt weitergeht hat er doch schon geschrieben, s.o. Christian
Christian B. schrieb: > Wie es mit dem Projekt weitergeht hat er doch schon geschrieben, s.o. Dazu finde ich nichts. Im 04/17 schrieb er recht interessiert mit anderen Foristen und merkte an, dass er zur schönen Jahreszeit nichts macht. Aktuell schrieb er, dass er auf's Proggen keine Lust hat, was in Anbetracht des aktuell wirklich schönen Wetters nicht verwunderlich ist. Beides impliziert keine Aussage über die Zukunft des Projekts.
Albert M. schrieb: > Bin weder bereits verstorben, noch krank und erfreue mich bester > Gesundheit. Na das ist schön zu hören und freut mich ehrlich. Ich weiß nur, dass es dir eine Zeit wohl nicht all zu gut ging (von dir selbst) und bevor hier wieder einige einen "Anspruch" auf deine freiwillige Leistung erheben und bei nicht erlangen dann meckern, wollte ich zu bedenken geben, dass du evtl. auch andere Gründe haben könntest. Wie schnell so was gehen kann, habe ich unlängst erst selbst erlebt.
Albert M. schrieb: > Meine Zeit vertreibe ich mir lieber mit Reisen, Natur, Fotografie oder > reines Nichtstun. Viel Freude dabei und vielen vielen Dank für die Software. und ja, ich muss zugeben dass ich ein wenig neidisch bin.
Albert M. schrieb: > Meine Zeit vertreibe ich mir lieber mit Reisen, Natur, Fotografie oder > reines Nichtstun. Hallo Albert, ja, da hast Du recht, so zu handeln. Sehr herzlichen Dank für Deine Software und die Aufhebung des Zeitlimits. Es hat Spaß gemacht, mit Dir zu planen und im Kontakt zu sein. Alles Gute, und bleib gesund! Liebe Grüße Günter
Albert, schick mir doch bitte eine Mail, wenn du wieder so tolle Fotos gemacht hast und die auf deiner HP zu sehen sind. Habe übrigens nun auch digital angefangen. Noch nicht viel, weil es mir schon länger nicht gut ging. Ansonsten viel Spaß bei der Freizeitgestaltung!
Vielleicht sammeln wir ein wenig Geld für Alberts nächsten Urlaub. Dann hat er wieder Lust aufs Programmierung und Bild-Posten.?
Da bin auch ich beruhigt. Vielen Dank auch von mir für das tolle Tool.
Hello. Great job. Is it very interesting tool. I have question: Is it possible to join instruments with line? I didn't find any tools for line drawing. Regards, Matjaz
Hallo Albert Schön von dir zu hören Ich wünsche dir eine gute Gesundheit ,viel Spass auf deinen Reisen und vielen Dank für das Programm fredfromflett
Hello, Nice application, but it doesn't work. I tried - 4.1 - can't open instruments settings, as I understood from German manual, to open setting you need to double click an instrument, no luck with this way, no luck with right clicking, can't find anything in the menus. - 4.0.x - when I try to start them it says "You don't have permision to start this application. Please contact the developer". A bit senseless ... Regards, Serge
I think you downloaded the wrong version. I recently installed win10 and this program from scratch. Works like a charm.
Hallo Albert und alle anderen. Zuerst wollte ich mich mal bei Albert für seine tolle Arbeit bedanken. Ich hab mir das alte SerialComInstruments 0.9 installiert und eine Oberfläche mit Instrumenten gemacht. Zuvor habe ich schon ein Meßgerät mit Arduino entwickelt. Das sendet fleißig an die Serielle Schnittstelle und sowohl über das Arduino Terminal als auch über Hyperterminal bekomm ich die ganzen Daten auf dem PC angezeigt. So nun hab ich das was der Arduino sendet um die Commandos für die Instrumente erweitert. Auch das geht mit Arduino Terminal und mit Hyperterminal. Sobald ich aber Connect beim SerialComInstruments mache, hängt der Arduino sich auf. Ich weiß nicht exact was passiert, aber er hängt auf alle Fälle irgendwie. Der Arduino gibt nur Daten auf den PC aus, er wartet nicht auf irgendwas vom PC. Ich weiß, dieser Thread ist schon einige Jahre "tot", aber ich würde das schöne Programm von Albert gern benutzten und brauch dafür Hilfe. LG
Ich habe mein Problem jetzt gelöst. Der Arduino nano wurde sowohl von USB als auch von meiner Hardware mit 5V versorgt. Ich dachte, die Diode auf dem Nano wäre genug = ausreichende Trennung. Alles hat funktioniert. Mit Hyperterminal oder dem Arduino Terminal hab ich die Messwerte erhalten, alles ohne Problem. Als ich dann SerialComInstruments verwendet habe, um die Messwerte graphisch dar zu stellen hat sich der Nano aufgehangen. Ohne Reset ging da nix mehr. Nach viel probieren und testen und messen, bin ich dann drauf gekommen, dass eine Vf=200mV Diode, die die 5V aus meiner Hardware von dem Nano trennen, die Lösung ist. Warum, kann ich nicht logisch erklären. Aber vielleicht hilft es ja jemand anderem mal. Ansonsten bin ich mit SerialComInstruments sehr zufrieden. LG
Klaus B. schrieb: > Nach viel probieren und testen und messen, bin ich dann drauf gekommen, > dass eine Vf=200mV Diode, die die 5V aus meiner Hardware von dem Nano > trennen, die Lösung ist. So entwickeln Arduino-Nutzer. Keine Ahnung von nix aber es werden halt mal ein paar Bauteile entfernt. Was soll man dazu noch sagen?
Das nennt man in besseren Kreisen : Evolution
Vielen Dank auch, dass Ihr mir vorwerft von nix ne Ahnung zu haben. Zu Eurer Info, ich habe keine Bauteile entfernt, sondern noch eines dazu gepackt. Ich stell hier meine Lösung rein, damit es anderen hilft und man schmeißt einem hin keine Ahnung zu haben. Nette Leute seid Ihr.
Klaus B. schrieb: > Nette Leute seid Ihr. Weist du nicht, wo du hier bist? Und dann auch noch mit einem Arduino ankommen ;-)
Rainer M. schrieb: > Weist du nicht, wo du hier bist? Sorry, wusste offensichtilch wirklich nicht, wo ich hier bin. Arduino's werden hier wohl gehasst? Ich mach mich dann mal besser auf den Weg ins Arduino Forum.
Rainer M. schrieb: > I think you downloaded the wrong version. > I recently installed win10 and this program from scratch. Works like a > charm. Can you tell which version you tried? I tried at least 5 last versions of V4, no luck with any under Win10 and Win7.
Wie programmiert man denn so eine GUI? Ein grosses Panel, auf das man einzelne Instrumente legt, ist kein Problem. Nur wie programmiert man das so, dass der Benutzer per Maus die Instrumente selbst beliebig neu positionieren und herumschieben kann auf dem Panel?
Ist doch kein Problem. Du musst nur dein Programm in einen Modus versetzen in dem die einzelnen Instrumente zwar gerendert werden aber sich eben mit der Maus verschieben lassen. Du bist der Programmierer, du kannst über alles was deine Software mit den Maus- und Tastatureingaben anstellt frei bestimmen. Wie du das genau umsetzen muss hängt halt völlig davon ab, welche Programmiersprache und welches GUI-Framework du nutzt.
:
Bearbeitet durch User
Wenn das Programm wirklich gut ist, sollte man gfs den Entwickler supporten. Ein paar Eurolein über paypal sollten drin sein. Wenn das dingens mal ausgereift ist, gucke ich wieder rein.
Der ingenieur schrieb: > Entwickler ist längst über alle Berge und hat Besseres zu tun. Muss mich immer noch ärgern daß ich auf das Programm gesetzt habe. Eine Sackgasse.
Meine Webseite für SerialComInstruments ist umgezogen nach: http://www.serialcominstruments.freecluster.eu Downloads sind dort ebenfalls verfügbar. Gruss Ulrich Albert Maassen
Hat er nicht schon genug gratis gearbeitet?
Seit Albert bei nach der 0.48er Version willkürlich die Codes der Instrumente änderte und diese Version auch nicht unter Win10 läuft bin ich abgesprungen und mach das jetzt mit Node-Red - mit seiner flexiblen Installations-Basis und seinem flexiblen Dash-Board. Damit ist die Visualisierung nicht mehr auf eine mickrige OS-Basis festgelegt und im Netz von überall abrufbar!
:
Bearbeitet durch User
Video SerialComInstruments 4.1 mit ESP 32 unter MicroPython mit Windows 10. Simple Demo: ESP32 ADC mit offenem Eingang und gleichzeitige Sinus Erzeugung. ADC auf Kanal 2 und Sinus auf Kanal 5 von SerialComInstruments geschickt. Youtube Video hier: https://youtu.be/yvhrARt-BrY
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.