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