Da ich kein einfaches Utility zum Testen der Daten von der seriellen Schnittstelle finden konnte, habe ich kurzerhand ein Programm zur Anzeige der numerischen Daten und Anzeige in einer Grafik geschrieben. Vieleicht ist es ja einem von euch nützlich. Ich stelle damit zur Zeit meine Daten von einem Ultraschall-Modul HC-SR04, welches über einem ATMega 168 gesteuert wird dar (siehe Bild). Die Software ist noch in einem Rohzustand, aber voll funktionsfähig. Die Eingaben in den Edit Feldern werden aber noch nicht auf Sinnhaftigkeit überprüft. Die Rohdaten müssen als Integer über die Schnittstelle gesendet werden. Die Skalierung incl. Offset erfolgt dann anschliessend in meinem Programm. Falls einer noch dazu Ideen hat - nur zu. Im übrigen lässt sich der Grafikinhalt durch Bewegen der Mouse (linke Taste gedrückt) in der Grafik verschieben, incl. mitlaufendem Koordinatensystem. So kann man z.B. die X-Achse auf max 100 einstellen, die überlaufenden Werte sind aber trotzdem vorhanden und können, auch währen der Erfassung, durch Verschieben des Koordinatensystem eingeshen werden. Falls es hierzu Interesse gibt, stelle ich eine erweiterte Version nächste Woche ein, eventuell auch mit der Möglichkeit einer FFT-Darstellung :)
Angehängte Dateien:
:
Verschoben durch User
Schönes Tool! Kann man auch mehrere Werte gleichzeitig anzeigen? In welchem Format werden die Daten gespeichert?
Jesse schrieb: > Schönes Tool! > Kann man auch mehrere Werte gleichzeitig anzeigen? In welchem Format > werden die Daten gespeichert? Das Programm ist on the fly in ein paar Stunden enstanden, eigentlich nur für meine Ultraschalldaten. Speichern der Daten in einem simplen Format sollte kein Problem sein, ist aber z.Z. noch nicht implementiert. Daten aus mehreren Kanälen könnte man auch für eine spätere Versionen vorsehen. Das ganze ist in Delphi programmiert, in meinem Alter von 62 darf ich das noch in dieser, für mich komfortablen Programmiersprache :) Die C-Programmierer schütteln sich da wahrscheinlich ...
Angehängte Dateien:
Hier noch kurz eine bereinigte Version. Das Programm ist jetzt portabel und arbeitet ohne Installer. Die Fenstergrösse ist veränderbar. Die Grafik kann nun als Bitmap gespeichert werden. Die komplette Erfassung (auch über die Grafik-Fensterbreite hinaus) kann gespeichert und wieder geladen werden. Die Xmax und Ymax sind jetzt Float-Werte anstatt Integer. Die Grafik hat ein einblendbares Grid. Zur Zeit ist die Grafik in X und Y scrollbar, nächste Woche kommt noch eine Zoomfunktion hinzu. Jetzt ist erst mal Wochenende :)
Neue Version
Neue Version mit Zooming und Panning der Grafik. Logarithmische und lineare Darstellung der Y-Achse. Div. Bugs in der seriellen Erfassung und Grafikanzeige behoben. Die max. Durchsatzrate beträgt ca. 50 Messwerte pro Sekunde bedingt durch die komplexe Grafikdastellung. das dürfte aber für die meisten Bastelanwendungungen reichen :)
Ist es schwierig, einen zweiten Graphen einzubauen?
Jesse schrieb: > Ist es schwierig, einen zweiten Graphen einzubauen? Nein - nicht schwierig sondern zeitaufwendig. Dazu müsste man sich auch noch über das Datenprotokoll einigen. Ein Kanal kann ohne Umstände einfach vom Microkontroller losgeschickt werden und mit meiner Software ist ein einklinken in den Datenstom zu jeder Zeit möglich. Zwei Kanäle müssten irgendwie gekennzeichnet werden. Eventuell vor jedem Wert ein "A" bezw. "B" setzen. Oder sonstwas. Mein Grafikmodul in der Software könnte mehrere Kanäle verarbeiten und darstellen, sogar mit getrennter Y-Skalierung für jeden Kanal und in unterschiedlichen Farben. Für mich plane ich in den nächsten Tagen noch eine High Speed Funktion mit direkter Speicherung und nachträglicher Darstellung des Graphen. Die Realtime Darstellung schafft max. 50 Samples/s, mit der High Speed Funktion hoffe ich auf einige Tausend/s zu kommen. Mal sehen. Leider ist das Interesse hier zu gering als dass ich eine besondere Motivation für derartige Erweiterungen hätte die ich selber zur Zeit nicht nutze.
Albert M. schrieb: > Mal sehen. > Leider ist das Interesse hier zu gering als dass ich eine besondere > Motivation für derartige Erweiterungen hätte die ich selber zur Zeit > nicht nutze. Mach BITTE. Ich finde das Tool unsagbar praktisch! Und danke dir für deine Mühen :)
Leider umsonst programmiert. Das hier kann das alles und noch viel mehr: https://sites.google.com/site/terminalbpp/ Wenn man mehr Graph- und Loggingoptionen braucht: http://www.logview.info/vBulletin/
Immanuel Cunt schrieb: > Leider umsonst programmiert. Das hier kann das alles und noch viel mehr: > https://sites.google.com/site/terminalbpp/ > Wenn man mehr Graph- und Loggingoptionen braucht: > http://www.logview.info/vBulletin/ Anscheinend hast Du die Software unter beiden Links noch nie benutzt. Sonst wüstest Du dass Terminalbpp nur äusserst primitive Graphik anbietet. Und Logview eigentlich für Akkuladegeräte und Datenlogger konzipiert wurde und auch nur mit den Protokollen der angegebenen Hersteller direkt kompatibel ist. Eigene Protokollen sind nur mit Aufwand möglich. Hingegen ist meine Software sofort ohne umständliches Gehampel einsatzfähig. Aber wie Du möchtest, müh Dich nur mit den von Dir gelobten Programmen rum :) Im übrigen will ich auch nicht mit irgendwelchen Tools in Konkurrenz treten, sonder habe es, wie oben schon erwähnt, für meine eigenen Belange geschrieben, weil ich nichts für mich passendes gefunden habe.
Wenn ich das richtig sehe kann dein Prog nur einen Graphen zu zeit darstellen? Und nur Integer? Schöner wäre wenn wie bei SerialChart einfach im CSV-Format ankommende Daten Dargestellt werden, und so viele Charts mit einzelnen Skalierungen wie man will und natürlich auch float.
Timmo H. schrieb: > Wenn ich das richtig sehe kann dein Prog nur einen Graphen zu zeit > darstellen? Und nur Integer? > Schöner wäre wenn wie bei SerialChart einfach im CSV-Format ankommende > Daten Dargestellt werden, und so viele Charts mit einzelnen Skalierungen > wie man will und natürlich auch float. Darüber denke ich nächste Woche mal nach. Integer und Float ist sicherlich kein Problem, CSV auch nicht. Mehrere Charts mit einzelnen Skalierungen könnte mein Grafikmodul bereits, ist aber mehr Aufwand bei der Integration.
Angehängte Dateien:
Neue Version 0.3 Die Grafik zeigt jetzt bis zu 1000 Samples/s und kann max 25.000 Samples aufnehmen. Die Grafik könnte zwar bis zu 50.000 Samples/s darstellen, die bekommt man aber nicht über die serielle Schnittstele in der Geschwindigkeit. Mehrere Bugs in der seriellen Schnittstelle wurden behoben, so dass diese jetzt auch mit max. Übertragungsrate störungsfrei arbeitet. Floatwerte können nun auch ohne Probleme erfasst werden. Als nächstes wird eine scrolling Grafik (Trend) implementiert, die beliebeig lange laufen kann, da die ältesten Samples immer entfernt werden. Falls für jemanden eine Darstellung der Daten als Instrumente (Zeiger / Balken usw) interessant ist, bitte melden. Das ist natürlich nur für langsame Erfassung sinnvoll. Wenn das alles läuft kommt die Erweiterung auf 2 Kanäle.
Albert M. schrieb: > Die Grafik könnte zwar bis zu 50.000 Samples/s darstellen, > die bekommt man aber nicht über die serielle Schnittstele in der > Geschwindigkeit. Wenn es Programmierer nur mal unterlassen würden sich irgendwelche Annahmen zu erträumen. Die meisten USB-Seriell Adapter haben kein Problem 1Mbit/s zu übertragen.
Immanuel Cunt schrieb: > Wenn es Programmierer nur mal unterlassen würden sich irgendwelche > Annahmen zu erträumen. > Die meisten USB-Seriell Adapter haben kein Problem 1Mbit/s zu > übertragen. Ich erträume mir nichts, sondern gehe von der Realität aus. Und die ist nun einmal so, dass die zugehörigen oder mitgelieferten Treiber diese hohe Rate meist nicht unterstützen. Mir ist noch kein Treiber untergekommen der im Gerätemanager von Windows mehr als max.128000 oder 256000 baud anbietet. Möglich dass Du so ein Teil hast, aber das als Standard zu Bezeichnen ist ziemlich fragwürdig.
Hallo, ist das mit einer frei verfügbaren Delphi Entwicklungsumgebung erstellt, oder einer kostenpflichtigen? olli
Mit einem bezahltem und lizenzierten Delphi 5 Prof.
Albert M. schrieb: > Ich erträume mir nichts, sondern gehe von der Realität aus. Und die ist > nun einmal so, dass die zugehörigen oder mitgelieferten Treiber diese > hohe Rate meist nicht unterstützen. Mir ist noch kein Treiber > untergekommen der im Gerätemanager von Windows mehr als max.128000 oder > 256000 baud anbietet. Also meinem TeraTerm Pro und HTerm ist es ziemlich egal was Windows im Gerätemanager anzeigt. Alle meine (3 unterschiedlichen) USB->UARTs Chips die ich im Einsatz habe können trotzdem 921kBaud rausfeuern und der PC empfängt es auch richtig.
Immanuel Cunt schrieb: > Albert M. schrieb: > Wenn es Programmierer nur mal unterlassen würden sich irgendwelche > Annahmen zu erträumen. > Die meisten USB-Seriell Adapter haben kein Problem 1Mbit/s zu > übertragen. Und wenn Du mal gerechnet hättest, würde Du feststellen dass die 1MBit auch nur eine Datenrate von ca. 10.000 Samples/s ergeben. Also worüber möchtest Du eigenlich diskutieren.
Albert M. schrieb: > Immanuel Cunt schrieb: >> Albert M. schrieb: >> Wenn es Programmierer nur mal unterlassen würden sich irgendwelche >> Annahmen zu erträumen. >> Die meisten USB-Seriell Adapter haben kein Problem 1Mbit/s zu >> übertragen. > > Und wenn Du mal gerechnet hättest, würde Du feststellen dass die 1MBit > auch nur eine Datenrate von ca. 10.000 Samples/s ergeben. Also worüber > möchtest Du eigenlich diskutieren. Nehmen wir mal an ich übertrage 8-bit Analogwerte ... plus Start- und Stoppbit ... was gibt 1000000/10? Vor dem Programmieren solltest du dich vielleicht noch mal mit solch komplizierten, abstrakten mathematischen Themen wie Division auseinandersetzen.
Albert M. schrieb: > Und Logview eigentlich für Akkuladegeräte und Datenlogger > konzipiert ursprünglich vielleicht > wurde und auch nur mit den Protokollen der angegebenen > Hersteller direkt kompatibel ist. Eigene Protokollen sind nur mit > Aufwand möglich. nein, es ist total einfach, eigene Daten da anzuzeigen. Allerdings ist die Spezifikation des OpenFormats an einigen Stellen nicht so gut durchdacht. Das Tool selbst hat mit hohen Datenraten und Echtzeitvisualisierung seine Probleme. Nach ein paar Minuten macht er nicht mehr mit, da er intern nicht vergessen mag und zur Anzeige jeweils alle Daten durchackert. Leider ist der Source nicht öffentlich und die Weiterentwicklung weitestgehend eingestellt. Ich hab schon öfter darüber nachgedacht hier mal ein Projekt anzufangen, das eine möglichst vielseitige Spezifikation erarbeitet, in der Hoffnung, dass ein solches Format Anklang findet und es sich lohnt eine SW dafür zu schreiben oder eine bestehende Open Source Software anzupassen.
Immanuel Cunt schrieb: > Nehmen wir mal an ich übertrage 8-bit Analogwerte ... plus Start- und > Stoppbit ... was gibt 1000000/10? > Vor dem Programmieren solltest du dich vielleicht noch mal mit solch > komplizierten, abstrakten mathematischen Themen wie Division > auseinandersetzen. Ich bin von meiner Berechnung von 10stelligen Floatwerten ausgegangen. Sorry da haben wir uns missverstanden. Übertragung auch von Floatwerten war ein Wunsch hier im Forum, den ich gerade implementiert habe, dabei ergeben sich die von mir genannten ca. 10.000 samples/s. Bei reiner 8 bit Rohdatenübetragung hast Du natürlich recht :)
Vlad Tepesch schrieb: > LogView: > Allerdings ist die Spezifikation des OpenFormats an einigen Stellen > nicht so gut durchdacht. > Das Tool selbst hat mit hohen Datenraten und Echtzeitvisualisierung > seine Probleme. Nach ein paar Minuten macht er nicht mehr mit, da er > intern nicht vergessen mag und zur Anzeige jeweils alle Daten > durchackert. Meine Software ermöglicht bei der Echtzeitanzeige max. 25.000 Samples. Im Trendbetrieb, den ich in den nächsten Tagen implementiere, ist beliebeig lange Aufzeichnung möglich, weil die ältesten Daten immer entfernt werden.
Albert M. schrieb: > ... Das Tool scheint mir aber relativ unflexibel (was ja angesichts der bisher kurzen Entstehungsgeschichte auch klar ist). Ich finde den Ansatz von OpenFormat schon recht gut. Die Aufteilung in Kanäle, mit jeweils einzelnen Feldern, die ausführlich definiert werden. Aber die Spezifikation ist unzureichend. Ich würde hier glaub ich auch eher auf xml setzen, als auf ein Ini-Format, was nicht vernünftig validiert werden kann. Einen Editor für die Spezifikation kann man immer noch drum rum bauen. Man müsste sich eine gutes Schema überlegen, was das Tool dann einlesen kann, damit man solche sachen, wie Umrechnung und Anzeigebereiche nicht von Hand konfiguieren muss. Dann ist es auch nicht so aufwendig mehrere Graphen einzubinden. Vielleicht sollte man einfach mal eine Thread aufmachen, um Anforderungen zu sammeln und so ein Format zu definieren. Vielleicht kennt auch jemand was gutes, was mir bei meiner Suche vor einer Weile nicht unter gekommen ist. Gleiches gilt für das Programm. Da könnte man parallel Anforderungen für ein Logging/Visualisierungs-Tool sammeln/definieren. Gui Programmierung ist allerdings nicht so meins, weswegen ich sowas bisher nie angefangen habe. Das ganze ist auch relativ komplex. Gerade bei Messwertvisualiserung gits ja alle möglichen Sonderwünsche. alleine für die simpelsten Dinge, wie was passiert, wenn weniger/mehr Messwerte als Pixel da sind, gibt es zig Lösungen.
Vlad Tepesch schrieb: > Albert M. schrieb: >> ... > > Das Tool scheint mir aber relativ unflexibel (was ja angesichts der > bisher kurzen Entstehungsgeschichte auch klar ist). Das Programm ist nicht als Eierlegendewollmilchsau gedacht und wird es auch nicht werden. Es soll mich bei meinen Basteleien mit Microprozessoren unterstützen und möglicht einfach zu bedienen sein. Und wem die Software gefällt kann sie gerne benutzen. Wer Tips geben will kann das auch gerne machen. Wenn euch andere Tools besser gefallen, dann benutzt doch diese. Um es deutlich zu sagen: Ich habe keine Lust meine ganze Freizeit daran zu verbringen, also bitte realistisch mit den Anforderungen bleiben.
Hi Ich hab mal ein wenig mitgelesen... Klasse. Endlich hat mal jemand seine Arbeit der Öffentlichkeit zur Verfügung gestellt und schon kommen die Stimmen aus dem Hintergrund. Leute, ich hab gelesen: "Ich hab mir ein Tool geschrieben und wer Interesse hat, darf es nutzen." Da steht nicht: "Ich hab euch ein Tool geschrieben und nun bitte sagt mir, was ihr noch wollt." @Albert M. Nett von dir. Aber wie du siehst gibt es immer ein paar Superschlaue, die kaum eigene Entwicklungen der Allgemeinheit verfügbar machen, jedoch glauben, anderen zu sagen, das sie das Recht hätten, Anforderungen zu stellen und alles zu bemängeln. Die Diskussion über Geschwindigkeiten sind doch albern. Nimm es deshalb nicht zu ernst. Ich finde es gut, wenn so eine Anwendung auch frei angeboten wird. Wenn es dir nichts ausmacht, dann mach doch deinen Quellcode auf. Dann können sich ja die "Experten" drann vergnügen..... @Rest Bravo, eure Kritik ist sowas von konstruktiv..... Gruß oldmax
Neue Version 0.4. Zusätzliche scrolling Trendanzeige. Bugs behoben: Eingabefelder Daten Offset und Graph Ymin jetzt Float.
oldmax schrieb: > Nett von dir. Aber wie du siehst gibt es immer ein paar Superschlaue, > die kaum eigene Entwicklungen der Allgemeinheit verfügbar machen, jedoch > glauben, anderen zu sagen, das sie das Recht hätten, Anforderungen zu > stellen und alles zu bemängeln. Die Diskussion über Geschwindigkeiten > sind doch albern. Nimm es deshalb nicht zu ernst. Ich finde es gut, wenn > so eine Anwendung auch frei angeboten wird. Wenn es dir nichts ausmacht, > dann mach doch deinen Quellcode auf. Dann können sich ja die "Experten" > drann vergnügen..... Du siehst das schon genau richtig wie es hier so abgeht Oldmax, deshalb danke für Dein Verständnis. Den Quellcode werde ich allerdings nicht freigeben; sollen doch die wichtigen Experten hier selber versuchen so was auch in 5 Tagen hinzubekommen. Ob ich unter den Gegebenheiten in diesem Forum lange Lust habe neue Versionen einzustellen weiss ich noch nicht.
Albert M. schrieb: > Sorry da haben wir uns missverstanden. > Ich bin von meiner Berechnung von 10stelligen Floatwerten ausgegangen. Und du bist von der ASCII-Übertragung von 10-stelligen Floatwerten ausgegangen... Und gerade die ASCII-Übertragung macht bei der seriellen Schnitte durchaus Sinn, weil dann dank STX, ETX und CR/LF jedes noch so schäbige Terminalprogramm mithören und mitloggen kann.
Neue Version 0.5 Comport und Baudrate ermöglichen die Eingabe benutzerspezifischen Werte. Eingabefelder DatenOffset und GraphYmin sind nun Floatwerte. Zusätzliche scrolling Trendanzeige. Hierbei wird der älteste Sample jeweils entfernt und der Graph bei jedem neuen Sample weitergeschoben. Die Sample-Nummer mit der die Grafik intern arbeitet ist jetzt ein int64. Dadurch kann der Trend mit den hierbei erlaubten max. 200 Samples/s sehr lange laufen. Es wird nur die Anzahl der unter Xmax eingegeben Samples gespeichert. Die max. erreichbare Samplerate im Normalbetrieb beträgt 2000 Samples/s und kann bis zu 50000 Samples erfassen (ASCII 10stellig gemessen bei 115200 Baud). Anzeige der aktuellen Samplenummer in der Statuszeile. Vorgesehene Features für nächsten Versionen: - Scrolling Trend X-Achse auch als Zeitskalierung in ss:mm:hh - X-Achse generell in us, ms, s saliert, aber nur wenn ich eine schnelle Timer-Komponente finde, die sich nicht vom internen Windows-Gewerkel beeindrucken lässt. - 2 Kanal Erfassung - Fourieranalyse (event. auch in Realtime)
Vielen Dank für das Tool! Hatte es ebenfalls mit Logview versucht, finde aber das OF und die geringe bzw. recht große Zeitbasis auch eher hinderlich. Also, Danke :-)
Hallo vaid, es freut mich dass Dir mein Tool gefällt :)
Hi Albert dein Tool ist super, bitte nur so weiter l-hase
Hallo, ich würde das Programm auch gerne nutzen aber bei mir werden die Werte nicht angezeigt, die ich rüberschicke (das Programm scheint zu arbeiten und es gibt keine Fehlermeldung). Beim Hyperteminal werden die Werte (z.b. konstant die 10) korrekt angezeigt. Baudrate und Comport stimmen. Der µC ist ein ATMega 2560 und ich Nutze die Lib von Peter Fleury (programmierung mit dem AVR-Studio). Für Lösungsansätze wäre ich dankbar. Gruß
Basti schrieb: > ich würde das Programm auch gerne nutzen aber bei mir werden die Werte > nicht angezeigt, die ich rüberschicke (das Programm scheint zu arbeiten > und es gibt keine Fehlermeldung). Beim Hyperteminal werden die Werte > (z.b. konstant die 10) korrekt angezeigt. Schickst Du die Werte als ASCII oder binär als Byte? Zur Zeit ist nur ASCII (also als Messwert als String schicken) möglich. Ein CR ( #13) hinter jedem Sample ist notwendig als Ende-Kennung.
Tolles Tool Albert und Danke das Du es uns zur Verfügung stellst ! Laß Dich bitte nicht von den unverbesserlichen Nörglern und Besserwissern verärgern. Echt einen reife Leistung dies in so kurzer Zeit zu programmieren. Noch einen schönen Tag wünsch ich Gruß
Spitze dein Tool, vielen Dank dafür. MfG Elektro Lux
Hier gibt's auch noch ein schönes Tool für mehrere Graphen und mit der Möglichkeit, das ganze als .csv zu Speichern. Beitrag "Vorstellung: grafisches Terminal serielle Schnittstelle sTerm"
Angehängte Dateien:
Neue Version 0.6 Jetzt auch mit 2 Kanälen im Normal-Mode und bei der fliessenden Trend-Darstellung. Beliebige Y-Achsenbeschriftung. Max. Anzeigerate im Normal-Mode (1 Kanal) 2000 Samples/s. Die Speichertiefe wurde auf 100.000 Samples erhöht. Im fliessenden Trend-Modus (1 Kanal) sind bis zu 100 Samples/s möglich. Die Speichertiefe ist hierbei unbegrenzt, da immer die ältesten Samples verworfen werden. Behobene Fehler: Skalierung der Programmoberfläche war unter verschiedenen Schrift- und Bildschirmgrössen oder nach Vergrössern/Verkleinern nicht korrekt. Fehler bei der Trenddarstellung. Diveres Minor Bugs. Änderung des Programm-Namens von SerialGrapher auf SerialComGrapher wegen Namensüberschneidung.
Hallo Albert, ich habe Dein Tool zwar noch nicht ausprobiert, finde aber anhand der gelesenen Beiträge die Programmierung als gelungen, vor allem in so kurzer Zeit. Auch wenn Du bereits gesagt hast, dass Du den Quellcode nicht bereitstellst, möchte ich Dir die Info geben, dass möglicherweise auch die Linux-Gemeinde an Deinem Tool Interesse haben könnte. Unter Linux gibt es das Lazarus/FreePascal Paket, das im gewissem Umfang zu Delphi kompatibel ist. Möglicherweise könnte man Dein Programm darauf portieren. Wollte das nur erwähnt haben, falls Du es nicht selber machen kannst/willst, aber andere dazu bereit wären. Danke für Deine Mühe das Programm. Gruß Markus DL8MBY
Angehängte Dateien:
-
Lazarus.jpg
77 KB
Nachtrag zu meinem Posting! Siehe angehängtes Bild der FreePascal IDE Namens Lazarus. Gibt es auch für Windows (Googel Lazarus + FPC). Möglicherweise kannst Du Deine Quelle direkt in Windows mit Lazarus + FPC compilieren und sehen ob es klappt oder Libs fehlen. Siehe auch: http://wiki.freepascal.org/Lazarus_For_Delphi_Users/de Gruß Markus DL8MBY Hallo Albert, ich habe Dein Tool zwar noch nicht ausprobiert, finde aber anhand der gelesenen Beiträge die Programmierung als gelungen, vor allem in so kurzer Zeit. Auch wenn Du bereits gesagt hast, dass Du den Quellcode nicht bereitstellst, möchte ich Dir die Info geben, dass möglicherweise auch die Linux-Gemeinde an Deinem Tool Interesse haben könnte. Unter Linux gibt es das Lazarus/FreePascal Paket, das im gewissem Umfang zu Delphi kompatibel ist. Möglicherweise könnte man Dein Programm darauf portieren. Wollte das nur erwähnt haben, falls Du es nicht selber machen kannst/willst, aber andere dazu bereit wären. Danke für Deine Mühe das Programm. Gruß Markus DL8MBY
Hallo Markus, Free Pascal / Lazarus ist mir natürlich bekannt. Leider ist es so, dass das Herzstück meiner Software eine ziemlich teure Delphi-Komponente für die schnelle Grafikdarstllung in wissenschaftlichen Applikationen ist und die ist für Lazarus nicht verfügbar. Den Grafikkern selber zu entwicklen würde Monate dauern. Ich würde es unter Linus mal mit Wine (Virtual Machine) versuchen, ich weiss allerdings nicht, ob Wine Com-Schnittstellen unterstützt und ob dann noch genügend Rechenpower für meine Software bleibt.
Hallo Albert, Spitzen Tool was du da programmiert hast und uns allen zur Verfühgung stellst. Das ist ja nicht selbstverständlich, wenn man die Beiträge manch anderer hier liest. Mir gefällt es jedenfalls und wollt dir auchmal DANKE dafür sagen. Gruß Steffen
Hallo Albert, hatte fast schon diese Befürchtung, wollte es aber trotzdem vollständigkeitshalber erwähnt haben. Möglicherweise ist irgendwann auch die von Dir verwendete SCI-Graphic-Unit portiert. Ich selber habe noch irgendwo ein Borland Delphi 2008 auf einem alten XP-Rechner installiert. Gruß Markus DL8MBY
Angehängte Dateien:
Neue Version 0.6.5 Dynanische Darstellung bei schnellen Sampleraten verbessert. Dyn.Darstellung kann für langsame Datenraten auch ausgeschaltet werden (siehe hierzu auch Info und Hilfe). Der Com-Puffer wurde auf 2 x 16.000 Samples erhöht. Anzeige der Pufferauslastung und der Dauer der Skalierung und Darstellung in der Statuszeile. Diverse Minor Bugs beseitigt.
Entwickelt sich wirklich prächtig. Weiter so!
Hi Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) , ich lese auch schon lange mit und teste auch eifrig deine Versionen des Programmes. Ich wollte nun auch einmal etwas LOB loswerden und sage dir vielen Dank für das schöne Tool. Ich finde es wirklich prima. Gruss Klaus de Lisson
Angehängte Dateien:
Neue Version 0.6.6 Major Bug in der Trend-Darstellung behoben. Danke an Klaus und Timmo für euren Zuspruch !
Vielen Dank für deine Mühe, kann das Programm gerade gut gebrauchen Ist vielleicht noch eine Autoscale-Funktion geplant? Ausserdem die Möglichkeit mehr als 2 Channel zu nutzen, vielleicht mit vorgestellten Buchstaben als Format (A=Kanal1, B=Kanal2, C=Kanal3,...) "A231\r\nB281\r\n..." oder weiter mit Semikolon
@Albert Stell den Quelltext doch ein. Du kennst die hier doch. Da werden die unglaublichsten Ideen eingebracht. Als GNU und Dein Name bleibt erhalten.
Karl schrieb: > Vielen Dank für deine Mühe, kann das Programm gerade gut gebrauchen > Ist vielleicht noch eine Autoscale-Funktion geplant? > Ausserdem die Möglichkeit mehr als 2 Channel zu nutzen, vielleicht mit > vorgestellten Buchstaben als Format (A=Kanal1, B=Kanal2, C=Kanal3,...) > "A231\r\nB281\r\n..." oder weiter mit Semikolon Mehr als 2 Kanäle sind z.Z. nicht vorgesehen. Als nächstes kommt die Skalierung der X-Achse alternativ als Zeit (ms/s/h/t) und eine High-Speed-Version mit der Darstellung von bis zu 20.000 Samples/s. Peter W. schrieb: > Stell den Quelltext doch ein. Du kennst die hier doch. Da werden die > unglaublichsten Ideen eingebracht. Als GNU und Dein Name bleibt > erhalten. Dazu hatte ich schon einmal weiter oben ausführlich geantwortet. Kurzfassung: Den Delphi(Pascal)-Quelltext stelle ich nicht ein. Das gilt ebenso für mein Programm PolynomMaker Beitrag "PolynomMaker - Funktion für nichtlineare Bauelemente finden"
Hallo Albert! Auch von mir ein Dankeschön! Habe das Programm eben zum Auslesen meines Drucksensors getestet und es klappt auf Anhieb. Super Sache!
Endlich! Endlich gibt es ein Programm das wirklich intuitiv eine graphische Ausgabe aus Standardmessdaten hergibt und scheinbar sehr stabil läuft. Womit programmiert man soetwas? Wirst du noch einen Zeitstempel einpflegen und kannst du es ermöglichen, zwei Charts mit individuellen Achsen und individuellen Refresh-Zeiten zu realisieren? Vielen Dank!
Die Software wurde, wie bereits mehrfach geschrieben, in Delphi (Pascal) erstellt. Die von Dir gewünschten 2 Charts mit individuellen Zeitachsen will ich nicht realisieren. Das Ganze wird von mir ab und zu als Hobby betrieben, da wollen wir die Sache mal nicht übertreiben :) Es existiert eine neue Version mit alternativer Skalierung der Zeitachse in ms/s/h. Das wäre dann der Zeitstempel. Zur Zeit möchte ich diese neue Version allerdings nicht veröffentlichen, da mir ehrlich gesagt die Motivation dazu fehlt.
Angehängte Dateien:
-
SerialComGrapher.PNG
55 KB
Hallo Albert, vielleicht kann ich dich ein bisschen motivieren deine neue Version mit Skalierung der Zeitachse zu veröffentlichen. Ich setze dein Programm ein um die Sprungantwort von einem (noch nicht ganz optimal eingestellten)PID-Temperaturregler anzuzeigen. Die Messwerte in einem zeitlichen Bezug darzustellen wäre sehr hilfreich. Siehe Messkurve im Anhang. Ich würde mich über deine Programm Veröffentlichung freuen. Gruß biker10
WOW! Gerade heute habe ich mich gefragt ob es so ein Programm wohl gibt und wie durch Zufall gerate ich hier her :). Zwar konnte ich das Tool noch nicht testen, aber es sieht wirklich toll aus! Vielen Dank dafür!
Tolle Arbeit! Gibt es Beispielanwendungen für C oder Luna?
jm 2c schrieb: > Tolle Arbeit! Gibt es Beispielanwendungen für C oder Luna? Schick einfach den Messwert als String + CRLF, das geht mit jeder Programmiersprache. Ist aber in der Programmhilfe nochmal (auch für 2 Kanäle) erklärt.
Hallo Dies ist wirklich eine super Software, genau dannach habe ich gesucht. Die Zeitachse wäre wirklich ganz nett, aber kann man ja über die Rate der gesendeten Daten auch darstellen. also Werte mit 10Hz->pro Wert 0.1s Bitte verfolge das Projekt weiter, das wäre wirklich eine super Sache
Tolles Programm, das wirklich leicht zu bedienen ist! Danke dafür! Wäre super, die in der Oberfläche schon angedeuteten Optionen auch noch zu haben (Export & Zeitachse)! Nochmals Danke Ralf
Es freut mich, dass euch meine Software nützlich ist. Es wird eine gänzlich neue und schnellere Version mit verbesserten Möglichkeiten geben. In der Zwischenzeit verweise ich mal auf mein anderes Projekt: Virtuelle Instrumente an serielle Schnittstelle Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle" Homepage mit allen Projekten: http://www.serialcominstruments.com Gruss Ulrich Albert
Toll wäre noch eine Funktion die automatisch jede Veränderung in eine Bilddatei speichert, so das man die Daten z.B. auf einer Webseite nutzen kann.
was Du unbedingt noch machen müsstest, eine Möglichkeit die anderen Parameter einer seriellen Schnittstelle einstellen zu können. Anzahl der Bits, Parity, Stopbits. Dann ware die Software echt super, so ist sie nur super. :)
Nicht schlecht - wird das Programm noch gepflegt?
Gerade getestet -> sehr praktisches Tool, danke!!
colsceg schrieb: > eine Möglichkeit die anderen > Parameter einer seriellen Schnittstelle einstellen zu können. Anzahl der > Bits, Parity, Stopbits. Kann ich in der nächsten Version verfügbar machen, siehe unten. Andreas Fischer schrieb: > wird das Programm noch gepflegt? Zur Zeit nicht, aber wenn die nächsten langen Winterabende kommen wird es eine gänzlich neue, schnellere Version geben. Dennis schrieb: > Gerade getestet -> sehr praktisches Tool, danke!! Freut micht dass es Dir nützlich ist.
Sieht gut aus, was Du da so baust ... weiter so!!!
Da gravierende Fehler in SerialComGrapher festgestellt wurden, gibt es in Kürze eine völlig überarbeitete und wesentlich schnellere Version. http://www.serialcominstruments.com/
Angehängte Dateien:
-
SerialComGrapher_Bild1.png
39 KB -
SerialComGrapher_Bild2.png
45 KB
@ Admins bitte nach Projekte verschieben da es eine Software zum Test und Betrieb für Mikrocontroller ist. Hier schon mal eine Vorschau auf die völlig überarbeitete neue Version. Die max. Samplerate wurde von 2.000 auf 5.000 Samples/s erhöht. Gemessen mit ATMega Nano 16 MHz und 500.000 Baud. Wesentlich schneller gibt die Schnittstelle eh nicht mehr her (Messwerte Ganzzahlig oder Floatingpoint als Strings). Der max Speicher beträgt 100.000 Werte. Im Flow-Trend Modus ist jedoch beliebig lange Darstellung möglich. Die Darstellung kann beliebig gezoomt oder verschoben werden. Neu sind weitere Fenster für langsamere Erfassung und Darstellung, incl. Zeiteinblendung in der Grafik, siehe Bild oben. Mehr Darstellungsarten, z.B. Port auslesen und mit Leds darstellen usw., sowie beliebigen Text/Kommandos an dem MC senden, Daten-Terminal, sind in Vorbereitung. Das Datenformat bleibt wie gehabt (m=Wert und CRLF=asc 13+10): 1-Kanal: mCRLF 2-Kanal: m;mCRLF Gruss Ulrich Albert
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComGrapher_Bild3.png
36 KB -
SerialComGrapher_Bild4.png
49 KB
Anbei die völlig überarbeitete Version SerialComGrapher V0.9 SerialComGrapher ist ein Visualierungstool für Daten von der seriellen Schnittstelle und eignet sich besonders für das Testen oder Werteerfassung von Mikrocontrollern. Verschiedene Darstellungsarten sind spezialisiert auf die schnelle Erfassung bis zu 5.000 Werte/s mit Realtime-Anzeige oder die Bedürfnisse für langsame Erfassung. Es können 1 oder 2 Kanäle dargestellt werden. Ein besonderes Datenformat ist nicht erforderlich, es beschränkt sich auf die Übertragung der Daten als String und der Ende-Kennung mit CRLF. Bei Übertragung von 2 Kanälen werden diese im Übertragungs-String durch ein Semicolon separiert. Die Darstellung erlaubt das Zoomen und Verschieben der Grafik. Der max. Speicher beträgt 100.000 Werte. Im Flow-Trend Modus ist jedoch beliebig lange Darstellung möglich. Ein Manual folgt demnächst. Zur Zeit gibt es aber Bedienhinweise in der Hilfe. Das Programm ist sofort ohne Installationsroutine startfähig und portabel. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
In der Bedienoberfläche sind noch einige Ungereimtheiten, die werden in der nächsten Version behoben.
:
Bearbeitet durch User
Meine (kurze) Wunschliste: Dezimalpunkt/Dezimalkomma einstellbar Kanaltrenner einstellbar: ; , TAB SPC Zusaetzliche Baudrate: 921600 Was ich noch nicht getestet habe: Die serielle Schnittstelle sollte beim Start noch einmal explizit rueckgesetzt werden. Das ist insbesondere fuer USB-Serial-Wandler wie den PL2303 noetig die sonst gerne schonmal aufgeben ueberhaupt noch etwas einzulesen. Den Unterschied sieht man sehr schoen bei den 2 Terminalprogrammen: "Tera Term" - setzt die Schnittstelle zurueck und funktioniert ohne Probleme. "Hyper Term" - tut dies nicht und man darf den Adapter einmal ziehen und wieder einstecken... Sowohl die PL2303HX als auch die FTDI FT232RL koennen hier mit Tera Term V 4.67 problemlos die 921600 benutzen. Weiterhin Gutes Gelingen und Danke
Angehängte Dateien:
-
SerialComGrapher_Bild7.png
70 KB -
SerialComGrapher_Bild6.png
92 KB
Anbei neue Version SerialComGrapher V0.9a Change Log 0.9a --------------- Neue Funktion Port-Zustand darstellen mit LED Anzeige - Es werden Werte im Bereich von 0..255 im Kanal 1 erwartet. Interpretiert wird der Wert als Byte und so über die Leds binär dargestellt. Damit kann z.B. das Byte eines MC-Ports einfach angezeigt werden. Neue Funktion Terminal - Empfangen und Senden - Das Terminal empfängt alle Rohdaten bereits vor dem Command-Processor und damit völlig unabhängig von den Einstellungen (1..2 Kanal usw). Es werden nur direkt darstellbare Zeichen angezeigt. ...... schrieb: > Dezimalpunkt/Dezimalkomma einstellbar > Kanaltrenner einstellbar: ; , TAB SPC > Zusaetzliche Baudrate: 921600 Versuche ich in der nächsten Version zu berücksichtigen. www.serialcominstruments.com
:
Bearbeitet durch User
Angehängte Dateien:
...... schrieb: > Kanaltrenner einstellbar: Semicolon , TAB und SPC Ist für die nächste Version implementiert. > Zusaetzliche Baudrate: 921600 Ist für die nächste Version implementiert. Getestet habe ich allerdings mit einem Arduino Nano mit 1.000.000 Baud (hat 16 MHz Quarz und damit dabei keinen Baudratenfehler). Funktioniert erstaunlicherweise problemlos. 512.000, 921.600, und 1.000.000 Baud zusätzlich implementiert. Mit den 1.000.000 Baud werden mehr als 10.000 Samples/s in Realtime angezeigt.
:
Bearbeitet durch User
Anbei neue Version SerialComGrapher V0.9b Change Log 0.9b --------------- Für 2-Kanal Betrieb sind nun folgende Delimiter als Trennzeichen zwischen den beiden Kanälen wählbar: - Semicolon (#59), Tab (#9), Leerzeichen (#32) Als Baudrate sind zusätzlich einstellbar: - 512.000 Baud, 921.600 Baud und 1.000.000 Baud ComboBox MaxSamples, bei Erreichen des eingestellten Wertes wird die Erfasung abgebrochen. Fehler beim Öffnen von Slow Display beseitigt, sowie sonstige Bugs behoben. www.serialcominstruments.com
:
Bearbeitet durch User
@Albert Du hattest Dich einige Posts weiter oben entschuldigt, daß Du mit Delphi programmierst. Ich finde Delphi respektive Pascal auch super und erstelle selbst den größten Teil meiner Programme damit. Pascal ist eine hervorragend strukturierte und durchdachte Programmiersprache. Wenn es da einen guten Compiler für Mikrocontroller geben würde, dann würde ich diese Sprache auch für die Programmierung selbiger benutzen. Leider gibt es da nichts und so muß man halt C nehmen. Dein Engagement ist absolut lobenswert. Laß Dich nicht von den Besserwissern unter kriegen - die sollen erst mal beweisen, daß sie es besser können. Gruß Twistete
Sorry in der Grußformel ist mir ein kapitaler Tipfehler unterlaufen. Es muß natürlich Gruß Twinsetter heißen
Twinsetter schrieb: > @Albert > Du hattest Dich einige Posts weiter oben entschuldigt, daß Du mit Delphi > programmierst. Das war eher ironisch gemeint. Es gibt keinerlei Grund sich für Delphi entschuldigen zu müssen. Die Anderen wissen es nur nicht bessr :)
Da geb ich Dir zu 100% recht. Bin grad dabei einen MSP430 zu programmieren und da es dafür keinen brauchbaren Pascalcompiler muß es halt C sein. Ich drücke es gelinde aus: Ich bekomme noch die Krise. Dinge die sich in Pascal einfach und effizient lösen lassen, benötigen in C Verrenkungen, daß es einen graust. Gut es ist nicht alles schlecht in C, aber in der Summe finde ich Pascal besser. Vom fehlenden ausgereiften Bibliothekskonzept (Units) mal ganz zu schweigen. Das gibt es in C nicht wirklich - die Headerfiles sind da eher eine Krücke. Übel ist auch das jeder C-Compiler an einigen Stellen komplett anders ist, z.B. Interruptserviceroutinen, um nur eine Baustelle zu nennen. Gruß Twinsetter
Twinsetter schrieb: > Übel ist auch das jeder C-Compiler an einigen Stellen komplett anders > ist, z.B. Interruptserviceroutinen, um nur eine Baustelle zu nennen. Und Du glaubst, daß das in Pascal anders wäre? Seit wann sind Interrupts Teil des Pascal-Sprachumfangs?
Bitte Programmiersprachen Diskussionen woanders führen.
Rufus Τ. F. schrieb: > Seit wann sind Interrupts > Teil des Pascal-Sprachumfangs? Habe ich nicht behauptet (ich kenne Pascal gut genug und weisd das dies kein Bestandteil des Sprachumfanges ist), aber wir wollen hier nicht eine Diskussion über Programmiersprachen lostreten, da gibt es, wie Albert schon richtig angemerkt hat, andere Orte im Forum. Gruß Twinsetter
Twinsetter schrieb: > [...] aber wir wollen hier nicht eine Diskussion über Programmiersprachen > lostreten, Warum fängst Du denn dann eine an?
Twinsetter schrieb: > Ja ist ja gut Gut ist es, wenn Du Dir und uns bescheuerte Auswürfe wie diesen: Beitrag "Re: Daten von der seriellen Schnittstelle einfach darstellen" und diesen: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" einfach mal ersparst. Wenn Du hier dermaßen den Lauten machst, mußt Du Dich über Gegenrede nicht wundern. Können wir also damit rechnen, daß Du Dich in Zukunft etwas zurückhaltender beträgst?
Albert M. schrieb: > Anbei neue Version SerialComGrapher V0.9b > > Change Log 0.9b > --------------- Ich kann die zip-Datei unter Windows 10 (mit dem Windowseigenen "Entzipper") partout nicht entpacken.Bei 97% ist Schluss.Danach muss ich zwangsweise das ganze abbrechen,was dann zur wiederum zur Folge hat,dass der Desktop und die Taskleiste "refreshed" wird.Macht man das 3 Mal fehlen dann Icons in der Taskleiste.Neustart erforderlich. Verwende ich ein separates Programm,laesst es sich "muehsam" entzippen und das Programm kann gestartet werden.Allerdings ist die Oberflaeche nicht so wie sie sein sollte: Aktiviert man "Show Display" werden die Skalen nicht komplett angezeigt.Statt bei 0 und 0.00 fangen sie bei 2 und 10 an. So war es zumdindest letzte Woche.Mittlerweile habe ich ein aelteres Backup von Windows 10 zurueckgespielt und probierte es nochmal: leider gleiches Problem. Fruehere Versionen von "SerialComGrapher" lassen sich problemlos entzippen und auch starten.Das gleiche gilt auch fuer "fremde" zip-Dateien Haben andere hier aehnliche Erfahrungen gemacht? Hab momentan keinen Zugriff auf einen 2. Rechner......
@Sheeva Plug Oh da hat aber einer recherchiert und fühlt sich dazu gleich noch auf den Schlips getreten. Außer die Leute im Forum dumm an zu machen trägst Du nichts zum Thema bei. Selbst in dem von Dir zitierten Thread ist Dir nichts weiter eingefallen als an Alberts Prinzipien rum zu mäkeln. Er möchte das seine Arbeit nicht kommerziell verwertet wird und dann haben wir dies zu akzeptieren. Weiterhin möchte er seinen Code nicht öffentlich machen und auch dies haben wir zu akzeptieren. Er hat ein Programm geschrieben und stellt es der Community zur Verfügungen insofern hat er Respekt verdient. Er hat auch eindeutig gesagt, daß er mit Delphi programmiert und damit sind von Windows abweichenden OS außen vor und auch dies müssen wir akzeptieren. Im übrigen habe ich im von Dir zitierten Thread lediglich auf den Unsinn eines Users geantwortet der Null Ahnung von Objekt Pascal respektive Delphi hat und zum Thema Pascal/Delphi nur dummes Zeug geschwatzt hat. Wenn den Du den Beitrag inklusive Zitat richtig gelesen hättest, dann hättest Du dies selbst feststellen können. Für mich ist an dieser Stelle das Thema erledigt und ich werde das mit Dir - zumindest in diesem Thread - nicht weiter ausdiskutieren. Du scheinst eh zu den Leuten zu gehören die keine Meinung neben Deiner akzeptieren. Gruß Twinsetter PS: Habe mir mal die Mühe gemacht und ebenfalls quer recherchiert. Fazit Du bist der "Größte"
Twinsetter schrieb: > Oh da hat aber einer recherchiert und fühlt sich dazu gleich noch auf > den Schlips getreten. Ich habe gar nicht recherchiert. Mir sind Deine Auswüchse nur schon in dem anderen Thread sehr negativ aufgefallen, weil sie überhaupt gar nichts zum Thema beigetragen und stattdessen pauschal Anwender bestimmter Werkzeuge diffamiert und bepöbelt haben. Und ja, stell' Dir vor, als Anwender dieser Werkzeuge fühle ich mich von Deinen dummen und überflüssigen Pöbeleien tatsächlich auf den Schlips getreten -- nicht allzu sehr, aber genug, um mir ein paar Minuten Zeit zu nehmen, einige Zeilen darauf zu antworten. Das hätte ich sogar bleibenlassen, wenn Du in diesem Thread nicht schon wieder mit demselben Scheiß angefangen hättest. Aber genau das hast Du mit Deinen Provokationen und Pöbeleien doch sicher auch gewollt und bezweckt, oder? Sonst hättest Du nämlich bei den Themen bleiben und uns Deine Haßtiraden ersparen können. > Außer die Leute im Forum dumm an zu machen trägst Du nichts zum Thema > bei. Willst Du etwa behaupten, Deine grund- und hirnlosen Haßtiraden auf C- und C++-Anwender würden irgendein Thema voranbringen? Im Ernst? Im Übrigen hast Du schlecht recherchiert. Zum Beispiel in diesem Thread [Beitrag "Linux: Server-Anwendung"] habe ich IMHO recht konstruktiv zum Thema beigetragen, und dem TO einige sinnvolle Lösungen für sein Problem vorgeschlagen. > Selbst in dem von Dir zitierten Thread ist Dir nichts weiter > eingefallen als an Alberts Prinzipien rum zu mäkeln. Lesen lernen: ich habe nicht gemäkelt, sondern nach dem Warum gefragt. > Er möchte das seine Arbeit nicht kommerziell verwertet wird und dann > haben wir dies zu akzeptieren. Das habe ich akzeptiert, aber nach dem Warum gefragt, weil ich verstehen möchte, warum er das tut. Immerhin entwickle ich selbst Software, die ich der Allgemeinheit meistens unter OpenSource-Lizenzen zur Verfügung stelle, und stehe deshalb regelmäßig vor denselben Fragen, die Albert für sich ganz anders beantwortet, als ich das tue. Da würde ich gerne verstehen, warum er diese Entscheidung getroffen hat; vielleicht habe ich bei meinen Entscheidungen ja etwas übersehen. Um unerwünschte, also hier: kommerzielle Verwendungen ausschließen, hat der liebe Gott im Übrigen verschiedene Lizenzen erfunden. Um dieses Ziel zu erreichen, muß man weder bestimmte Nutzergruppen diskriminieren, noch gezielt die Interoperabilität zerstören. > Weiterhin möchte er seinen Code nicht öffentlich machen und auch dies > haben wir zu akzeptieren. Das habe ich akzeptiert, möchte seine Gründe aber trotzdem verstehen. > Er hat ein Programm geschrieben und stellt es der Community zur > Verfügungen insofern hat er Respekt verdient. Das habe ich verstanden, weißt Du. Mein Respekt geht allerdings nicht mit einer frag- und kritiklosen Anbetung einher, weißt Du. Ich glaube daran, daß die meisten Menschen vernunftbegabt sind und für ihre Entscheidungen rationale Gründe haben. > Er hat auch eindeutig gesagt, daß er mit Delphi programmiert und damit > sind von Windows abweichenden OS außen vor und auch dies müssen wir > akzeptieren. Deplhi-Programme kann man unter Linux ganz wunderbar mit Wine oder unter einem virtualisierten Windows betreiben, kein Problem. Das wird von Albert aber laut seiner Aussage absichtlich verhindert, weil er seine Binärcodes erstens obfuskiert und zweitens prüft, ob das Programm in einer virtuellen Umgebung läuft. Da wird es doch wohl erlaubt sein, zu fragen, warum er so einen enormen Aufwand betreibt, nur um viele Interessierte auszuschließen. > Im übrigen habe ich im von Dir zitierten Thread lediglich auf den Unsinn > eines Users geantwortet der Null Ahnung von Objekt Pascal respektive > Delphi hat und zum Thema Pascal/Delphi nur dummes Zeug geschwatzt hat. > Wenn den Du den Beitrag inklusive Zitat richtig gelesen hättest, dann > hättest Du dies selbst feststellen können. Richtig ist, daß die Ausführungen des betreffenden Teilnehmers nicht sehr klug waren. Richtig ist aber auch, daß Dein "Beitrag" mindestens genauso dumm und falsch war, und Du gezielt, persönlich und pauschalisierend auf alle C++-Anwender eingeprügelt hast. > Für mich ist an dieser Stelle das Thema erledigt und ich werde das mit # > Dir - zumindest in diesem Thread - nicht weiter ausdiskutieren. Puh, dann können wir uns ja endlich wieder dem Thema widmen, nämlich einer Software, die ich zwar gerne einmal ausprobieren würde, aber nicht kann, weil der Autor unverständlicherweise einen exorbitanten Aufwand betreibt, nur um mich und andere auszuschließen. > Du scheinst eh zu den Leuten zu gehören die keine Meinung neben Deiner > akzeptieren. Deine Pöbeleien gegen C- und C++-Anwender widerspruchslos zu akzeptieren, fällt mir zugegebenermaßen nicht leicht, zumal sie ja auch keine Beiträge zu den Dir angeblich so wichtigen Themen leisten. Ansonsten habe ich kein Problem damit die Meinungen anderer Leute zu akzeptieren. Gerade deswegen hinterfrage ich sie, weil ich gerne die Gründe dafür verstehen möchte. Es scheinst vielmehr Du selbst zu sein, der Probleme mit den Meinungen anderer Leute hat. Wie sonst ließen sich Deine grundlosen Haßtiraden auf pauschal alle C- und C++-Nutzer erklären? Schon unsere Mütter wußten: wie es in den Wald hineinruft, so schallt es wieder heraus. Anstatt mich und andere hier zu bepöbeln, nur weil wir Werkzeuge verwenden, die Du nicht magst, darfst Du Dich bitte an Deine eigene Nase fassen und Dein eigenes Verhalten reflektieren. Viel Glück!
An die Forumuser: Twinsetter (Gast) Sheeva Plug(sheevaplug) Koennt ihr mal bitte fuer ca.24 Stunden eure Streitigkeiten beilegen, so dass vielleicht andere hier auf dem Forum mein Posting lesen koennen und eventuell eine Antwort darauf haben? Danke ! Toxic schrieb: "SerialComGrapher V0.9b" > Ich kann die zip-Datei unter Windows 10 (mit dem Windowseigenen > "Entzipper") partout nicht entpacken. > Haben andere hier aehnliche Erfahrungen gemacht? Hab momentan keinen > Zugriff auf einen 2. Rechner......
Toxic schrieb: > Koennt ihr mal bitte fuer ca.24 Stunden eure Streitigkeiten beilegen, Das mußt Du mir nicht sagen, ich *re*agiere dabei nur. > Toxic schrieb: > > "SerialComGrapher V0.9b" >> Ich kann die zip-Datei unter Windows 10 (mit dem Windowseigenen >> "Entzipper") partout nicht entpacken. > >> Haben andere hier aehnliche Erfahrungen gemacht? Hab momentan keinen >> Zugriff auf einen 2. Rechner...... Ich hab's gerade mal mit KUbuntu Linux 15.04 ausprobiert, und sowohl der grafische Entpacker "ark" als auch das Kommandozeilenwerkzeug "unzip" konnten die Datei problemlos entpacken. Allerdings ist Linux-Software ja dafür bekannt, besonders robust, zuverlässig und fehlertolerant zu sein. Trotzdem würde ich den Fehler an dieser Stelle bei Windows10 und seinen Werkzeugen vermuten, zumal Du die Software ja mit einem externen Entpacker extrahieren kannst. Wobei: was ist an dieser Stelle "mühsam"? Daß Du einen externen Entpacker benutzen mußt oder macht der dann auch Mucken? Die Darstellungsfehler könnten natürlich damit zusammenhängen, daß Windows10 Probleme mit Alberts Code-Obfuskierung oder mit den Kompilaten seiner etwas älteren Delphi5/7-Umgebung hat, da habe ich schon ein paar Nutzerberichte über kleinere und größere Schwierigkeiten gelesen.
Karl Käfer schrieb: > Trotzdem würde ich den Fehler an dieser Stelle bei Windows10 und seinen > Werkzeugen vermuten, zumal Du die Software ja mit einem externen > Entpacker extrahieren kannst. Wobei: was ist an dieser Stelle "mühsam"? > Daß Du einen externen Entpacker benutzen mußt oder macht der dann auch > Mucken? 1.Ich habe einen externen Entzipper verwendet und in meinem allerersten(!) Posting auch zusaetzliche Infos hinzugefuegt. 2.Wollte auch nur wissen ob es anderen Usern unter Windows 10 genauso ergeht. 3.Ausser dieser speziellen Zip-Datei funktioniert mein Laptop einwandfrei. 4.Da ausser deiner Antwort (danke dafuer) keiner auf meine Frage eingegangen ist,werde ich wohl oder uebel einen anderen Lappy mit einem Windows 10 auftreiben muessen.
Toxic schrieb: > Ich kann die zip-Datei unter Windows 10 (mit dem Windowseigenen > "Entzipper") partout nicht entpacken.Bei 97% ist Schluss. Ich habe jetzt unter Win7 mehrmals die Zip-Datei hier vom Forenserver runtergeladen und direkt mit WinRAR entzippt. Einmal ging das genau wie bei Dir daneben, obwohl die CRC Checksumme des ZIP-Files stimmte, also angeblich ohne Übertragungsfehler. Karl Käfer schrieb: > Die Darstellungsfehler könnten natürlich damit zusammenhängen, daß > Windows10 Probleme mit Alberts Code-Obfuskierung oder mit den Kompilaten > seiner etwas älteren Delphi5/7-Umgebung hat, da habe ich schon ein paar > Nutzerberichte über kleinere und größere Schwierigkeiten gelesen. Der Delphi 7 Code und die Obfuskierung ist absolut kompatibel mit Win10. Die erwähnten Probleme bezogen sich ausschliesslich auf die automatische Erkennung benutzter ComPorts, die bei einigen unter Win10 funktionierte, bei anderen nicht. Wen es interessiert, kann dazu ja mal die letzten Posts zu SerialComCNC lesen: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Es deutet alles darauf hin, das dies ein Win10 Problem in der Schnittstellenbehandlung ist. Als Lösung habe ich dort angeboten den ComPort alternativ aus einer Liste auszuwählen, was auch anstandslos mit Win10 funktioniert. Dies werde ich nun für die nächste Version von SerialComGrapher einführen. Was die Darstellungsfehler der Instrumente anbetrifft, so können diese wahrscheinlich nur mit dem fehlerhaften Entpacken der Zip Datei zusammenhängen. Diese Instrumente werden auch in SerialComInstruments benutzt, welches ebenfals obfuskiert ist und seit mehreren Versionen offensichtlich unter Win10 problemlos läuft. Das SerialComGrapher nicht mehr unter virtuellen Umgebungen (VM, Virtual PC, VirtualBox, SandBoxie usw) lauffähig ist setzte ich inzwischen als bekannt voraus. Wine könnte da eine Ausnahme sein, für Probleme damit übernehme ich allerdings keinen Support, da ich von Linux keine Ahnung habe. Sheeva P. schrieb: > Puh, dann können wir uns ja endlich wieder dem Thema widmen, nämlich > einer Software, die ich zwar gerne einmal ausprobieren würde, aber nicht > kann, weil der Autor unverständlicherweise einen exorbitanten Aufwand > betreibt, nur um mich und andere auszuschließen. Von "exorbitanten Aufwand" kann keine Rede sein. Das sind, nach einmaliger Konfiguration, beim Build Prozess zwei Mouse Klicks mehr. Vielleicht funktioniert die Software ja unter Wine, Ergebnisse diesbezüglich interessieren mich und ich würde, wenn es denn geht, Wine nicht explizit blockieren um Linux User auszuschliessen. Irgendwo in den Threads zu meiner Software, ich weiss nicht mehr welcher, hatte mal jemand Tricks rausgefunden (Ansprechen der Schnittstelle) wie es unter Wine geht. Habe jetzt aber keine Lust danach zu suchen :)
:
Bearbeitet durch User
Albert M. schrieb: > Toxic schrieb: >> Ich kann die zip-Datei unter Windows 10 (mit dem Windowseigenen >> "Entzipper") partout nicht entpacken.Bei 97% ist Schluss. > > Ich habe jetzt unter Win7 mehrmals die Zip-Datei hier vom Forenserver > runtergeladen und direkt mit WinRAR entzippt. Einmal ging das genau wie > bei Dir daneben, obwohl die CRC Checksumme des ZIP-Files stimmte, also > angeblich ohne Übertragungsfehler. Danke fuer Dein Posting ! Ich werde Dein Programm "SerialComGrapher" naechstens nochmal testen,sowie ich einen 2. Lappy habe. Den "SerialComCNC" hab ich eben downgeloaded,problemlos entzippt und auch problemlos starten koennen.
Betr. Linux / Wine Ich habe mich mit dem Problem nochmal beschäftigt. Die Wine Inkompatibilit ensteht hauptsächlich durch ein Redirekt der WinAPI Funktionen durch mein Obfuskier/Protect-Tool. Das API-Redirekt werde ich für die nächste Version explizit für Wine deaktivieren. Wenn SeriaComGrapher damit unter Linux/Wine funktioniert, werde ich diese Änderung auch für SerialComInstruments und SerialComCNC einführen.
:
Bearbeitet durch User
Albert M. schrieb: > Betr. Linux / Wine > > Ich habe mich mit dem Problem nochmal beschäftigt. Die Wine > Inkompatibilit ensteht hauptsächlich durch ein Redirekt der WinAPI > Funktionen durch mein Obfuskier/Protect-Tool. Das API-Redirekt werde ich > für die nächste Version explizit für Wine deaktivieren. > > Wenn SeriaComGrapher damit unter Linux/Wine funktioniert, werde ich > diese Änderung auch für SerialComInstruments und SerialComCNC einführen. Cool, danke.
Anbei neue Version SerialComGrapher V0.9c Testversion für Win10 und Linux/Wine Change Log 0.9c --------------- Für Win10 das Häkchen vor ComPort entfernen (autom. Portsuche aus) und dann den gewünschten ComPort aus der Liste wählen. Bitte mal Testen ob diese Version unter Linux/Wine funktioniert. Die WinAPI-Redirekt Funktionen wurden für Wine deaktiviert. Leider kann ich zu Wine mangels Linux Kenntnissen keine weitere Unterstützung geben. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Sheeva P. schrieb: > Willst Du etwa behaupten, Deine grund- und hirnlosen Haßtiraden auf C- > und C++-Anwender würden irgendein Thema voranbringen? Im Ernst? Nenne einen Satz in diesem Thread wo ich einen C/C++-Anwender mit Haßtiraden belegt habe. Ich habe lediglich mit Albert einen kurzen Disput zum Thema Pascal vs C/C++ geführt und dabei geäußert was ich an C nicht so toll finde. Damit greife ich aber keinen Programmierer an. Jeder soll die Hochsprache (oder auch ASM) benutzen von der er meint das er damit seine Aufgaben am besten lösen kann. Aufgeblasen zu einem Thema hast Du die Sache. Wenn Du einen aus einer Kritik an einer Programmiersprache einen persönlichen Angriff machst, dann tust Du mir nur leid. Im übrigen programmiere ich beruflich auch mit C/C++/C# - dann hätte ich mich ja selbst mit Hautiraden belegt. Twinsetter
Scheiß automatische Rechtschreibkorrektur- es muß natürlich im letzten Satz Haßtiraden und nicht Hautiraden heißen
Twinsetter schrieb: > Ich habe lediglich mit Albert einen kurzen Disput zum Thema Pascal vs > C/C++ geführt Ich habe mit Dir keinen derartigen Disput geführt. Das war ein Monolog von Dir. Es reicht jetzt mit diesen sinnlosen Diskussionen. Du hast damit hier angefangen und meinen Thread nun genug gestört. Und darauf antworten brauchst Du auch nicht mehr.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei neue Version SerialComGrapher V0.9d Change Log 0.9d --------------- Fast Display - Neue Eingabe Box "MC Sample/Time" unter CH1 Nach Eingabe der vom MC vorgegebenen Sample Zeit, z.B. 200 us (alle 200 us wird ein Wert gesendet), kann mit dem beweglichen roten Linien-Cursor die reale Zeit oben rechts in der Anzeigebox abgelesen werden (Bild 11). Statistik Fast Display - Unter dem Menue-Punkt Mathematik/Statistik werden diverse Statistische Daten der aktuellen Messung angezeigt: Min, Max, Mittelwert, Standard Abweichung usw. Die statistischen Daten können optional ins Clipboard kopiert werden. Bild 10 oben zeigt A/D-Wandler Test. Slow Display - Die Kurven-Darstellung kann nun auch hier gespeichert und wieder geladen werden. An die Linux Nutzer: Habt ihr die Software nun unter Wine mal getestet? http://www.serialcominstruments.com/
:
Bearbeitet durch User
Wo bleiben denn die Linuxjünger die Dich zu den Anpassungen bewegt haben?? Ich habe Dein Programm gerade mal getestet und konnte auch die älteren Versionen unter MacOS und Linux zur Funktion bewegen. Also zumindest bei den älteren Versionen wird Wine wahrscheinlich nicht funktionieren. Das Problem an Wine ist einfach, daß es kein Windowsemulator ist, sondern nur Windows-API Aufrufe nach Linux umsetzt. Ich habe selbst Wine mit verschiedenen Programmen getestet. Vieles funktioniert, aber es gibt eben auch mehr oder weniger Aussetzer. Eine vernünftige Lösung ist nur über Virtualisierung hinzubekommen. Allerdings impliziert dies, daß man ein paar Euronen für ein lizensiertes Windows in die Hand nehmen muß, was sich aber im Endeffekt lohnt. Unter Mac ist Parallels eine gute Wahl, da hiermit die Windowsprogramme in die Oberfläche perfekt integriert werden. Fazit: Eigentlich braucht es keine Anpassungen um das Programm unter Mac/Linux zu nutzen. Mit Virtualisierung funktioniert es definitiv und das kostet nicht die Welt. Win XP gibt es laut Google schon ab ca. 20-30€. Zeno
Zeno schrieb: > Wo bleiben denn die Linuxjünger die Dich zu den Anpassungen bewegt > haben?? Dann melde ich mich mal. Das Programm ist fuer Windows geschrieben und auch nur dafuer. Ich weigere mich Windows zu nutzen, ergo auch dessen Programme die nur dafuer geschrieben sind. Ich kaufe auch keine Hardware bei der der Hersteller nicht zumindest an Linux denkt. Also nutze ich dieses Programm eben nicht.
Barney G. schrieb: > Das Programm ist fuer Windows geschrieben Ja, weil der Programmautor, wie er selbst schreibt, ausschließlich unter Windows arbeitet und demzufolge auch nur eine Entwicklungsumgebung für dieses System im Einsatz hat. Warum es unter Wine nicht oder bisher nicht funktioniert hat er ja dargelegt. Ich hab's halt mal mit Virtualisierung versucht und da funktioniert das auf den von mir genannten Systemen. Warum Wine eben nicht Windows ist habe ich ja auch kurz angesprochen. Wie heißt es auf der Wien-Homepage: "Wine is not a emulator" - oder so ähnlich. Zeno
Barney G. schrieb: > Zeno schrieb: >> Wo bleiben denn die Linuxjünger die Dich zu den Anpassungen bewegt >> haben?? > > Barney Geroellheimer schrieb: > Dann melde ich mich mal. > Das Programm ist fuer Windows geschrieben und auch nur dafuer. Ich > weigere mich Windows zu nutzen, ergo auch dessen Programme die nur > dafuer geschrieben sind. Ich kaufe auch keine Hardware bei der der > Hersteller nicht zumindest an Linux denkt. > Also nutze ich dieses Programm eben nicht. Barney, gehörtes Du zu denen dich mich zu der Anpassung bewegt haben? Nein. Also wolltes Du nur mal eben sinnfrei hier Deinen Windows Frust mit ebenso sinnfreien Statements los werden und was rumtrollen. Anscheinend kommt Dir nicht mal in den Sinn, dass Deine Argumentation auch für alle Linux Programme gilt die nicht unter Windows lauffähig sind. Hast Du von den Window Nutzern hier jemals entsprechende Statements gehört? Warum führen sich viele Linux Nutzer so aufdringlich militant auf? Und ob Du nun meine Software nutzt oder nicht ist mir schnurzegal.
:
Bearbeitet durch User
Albert M. schrieb: > Und ob Du nun meine Software nutzt oder nicht ist mir schnurzegal. Was regst Du Dich dann so auf ? Herztropfen nicht genommen ? Und nein, ich nutze sie nicht, steht ja oben. Und das gilt nicht nur fuer Linux, auch fuer MAC. Zudem war die Antwort fuer Zeno bestimmt, denn der hatte gefragt.
:
Bearbeitet durch User
Hier mal ein Demo-Video von SerialComGrapher auf Youtube: https://youtu.be/gEYJ3c-xppU gezeigt wird zuerst schnelle Erfassung mit bis zu 10.000 Samples/s, anschliessend langsame Erfassung und floating Trend. Schnittstelle 500.000 Baud, Arduino Nano. http://www.serialcominstruments.com/
:
Bearbeitet durch User
Albert M. schrieb: > Anscheinend kommt Dir nicht mal in den Sinn, dass Deine Argumentation > auch für alle Linux Programme gilt die nicht unter Windows lauffähig > sind. Hast Du von den Window Nutzern hier jemals entsprechende > Statements gehört? Also mir fallen nicht sehr viele Linux-Programme ein, die nicht auch unter Windows verfügbar wären. Systemnahes, klar: es wäre ja auch ziemlich blöd, tune2fs auf ein NTFS-Dateisystem anzuwenden. Aber sonst?
Wäre die Software denn nicht mit einem überschaubaren Aufwand portabel zu machen?
wxWidget-User schrieb: > Wäre die Software denn nicht mit einem überschaubaren Aufwand portabel > zu machen? Wenn ich Alfred richtig verstanden habe, verwendet er Delphi Pro mit einer windowsspezifischen, propritären Komponente. Dann könnte die Sache mit der Portabilität etwas schwierig werden. Zumal Alfred, wenn ich das richtig verstanden habe, zuhause kein Linux hat, und die Sache für ihn ein Hobbyprojekt ist.
:
Bearbeitet durch User
Sheeva P. schrieb: > Wenn ich Alfred richtig verstanden habe, verwendet er Delphi Pro mit > einer windowsspezifischen, propritären Komponente. Dann könnte die Sache > mit der Portabilität etwas schwierig werden. Ich bin ja nicht alleine um die Uhrzeit noch aktiv :) Genau ich verwende diverse zugekaufte Delphi Komponenten die es für Lazarus nicht gibt. Somit wird es keine Version für Linux geben. Ich habe aber seit der letzten Version die Restriktion für Wine entfernt, vielleicht geht es ja damit. Sheeva P. schrieb: > Zumal Alfred, wenn ich das richtig verstanden habe, zuhause kein Linux > hat Zu hause ist gut, ich bin 65, damit lustiger Rentner und immer/meist zuhause. Linux habe ich zwar auf einem PC laufen, ist aber nicht mein Ding und ich habe keine Motivation mich damit intensiver zu beschäftigen. > und die Sache für ihn ein Hobbyprojekt ist. Genau, das ist eines meiner Hobbies um die Birne fit zu halten. Im übrigen habe ich Programmieren nicht gelernt, war nie Programmierer und will auch keiner mehr werden. Na gut, während des Studiums ein Semester an einer ollen IBM 1620 mal etwas FORTRAN. Eines meiner vielen Hobbies: http://www.fotocommunity.de/fotograf/ulrich-maassen/fotos/1508221 http://www.natur-mg.de/Myself.html Deshalb haben die Rentner nie Zeit :) >Zumal Alfred ... Im übrigen heisse ich nicht Alfred :) Gruss Ulrich Albert
:
Bearbeitet durch User
Albert M. schrieb: > Im übrigen heisse ich nicht Alfred :) Entschuldige bitte, ich habe gerade mit einem (ganz wunderbaren) Alfred eine Woche lang die Gegend um Trogir in Kroatien besegelt und immer noch Seegang. Ich werde Deine Software allerdings sehr gerne unter Linux mit Wine testen, sobald ich eine passende Maschine übrig habe. Im Moment geht es auf meinen Maschinen noch um Redis und Apache Storm. ;-)
Na so richtig testet keiner Dein Programm unter Linux. Machen alle nur viel Wind drum und haben dann fadenscheinige Ausreden, warum sie gerade nicht testen können. Ich sage mal so, Du hättest Dir DEin Engagement bezüglich Linux sparen können - interessiert ja eh keinen. Gruß Zeno
Zeno schrieb: > Na so richtig testet keiner Dein Programm unter Linux. Machen alle nur > viel Wind drum und haben dann fadenscheinige Ausreden, warum sie gerade > nicht testen können. Ist doch hier im Forum nichts neues. > Ich sage mal so, Du hättest Dir DEin Engagement bezüglich Linux sparen > können - interessiert ja eh keinen. Ist mir eine Lehre für die Zukunft. Die Sperre für sämtliche virtuellen Umgebungen kommt jetzt in der nächsten Version eben wieder rein.
Hallo Albert, Erstmal super Software! Wirklich sehr praktisch. Einen kleinen Verbesserungsvorschlag habe ich jedoch trotzdem noch. Ich finde der Skalierungsfaktor sollte standardmässig auf 1 gesetzt sein. Habe mich über eine halbe Stunde gefragt wieso ich immer nur 0 angezeigt bekomme. Bis ich dann den Skalierungsfaktor gefunden habe. =) Grüsse Dominic
Dominic A. schrieb: > Ich > finde der Skalierungsfaktor sollte standardmässig auf 1 gesetzt sein. > Habe mich über eine halbe Stunde gefragt wieso ich immer nur 0 angezeigt > bekomme. Bis ich dann den Skalierungsfaktor gefunden habe. =) Dann wirst Du den Skalierungsfaktor selbst verstellt haben. Der steht beim Programmstart für beide Kanäle immer auf 1, was anderes wäre auch Unfug.
Bei mir stehen alle Werte beim Start auf 0. Habe es soeben nocheinmal ausprobiert.
Albert M. schrieb: > Ist doch hier im Forum nichts neues. Ja ist mir leider auch schon aufgefallen. Es sind halt immer wieder Leute dabei, die erst mal viel heiße Luft erzeugen und wenn's konkret wird den Schwanz einziehen oder sich sofort angepisst fühlen wenn mal jemand in eine andere Richtung denkt und vom allgemeinen Standard abweicht. Dabei bringen grad diese Leute oftmals frischen Wind rein und regen zum Nachdenken an. >Ist mir eine Lehre für die Zukunft. Die Sperre für sämtliche virtuellen Umgebungen kommt jetzt in der nächsten Version eben wieder rein. Mach Dir da keinen Stress, das ist es einfach nicht wert. Die Arbeit kannst Du Dir auch sparen, da es offensichtlich keiner unter unixartigen Systemen nutzt. Ich für meine Person hab's einfach mal aus Interesse in einer VM mit Win (verschiedene VM'S) unter Linux und Mac ausprobiert und es hat funktioniert. Gruß Zeno
>> Die Sperre für sämtliche virtuellen Umgebungen kommt jetzt in der >> nächsten Version eben wieder rein. >> Zeo schrieb: > Mach Dir da keinen Stress, das ist es einfach nicht wert. Die Arbeit > kannst Du Dir auch sparen, da es offensichtlich keiner unter unixartigen > Systemen nutzt. Ist kein Stress, nur ein Häkchen vor dem Start der Protection-Software :)
Es ist schon interessant : Erst wird geblökt, dann bewegt sich einer und macht was bz. reagiert und dann interessiert es keine Sau. Tolle Forumskultur! @Albert: Bemühe Dich in Zukunft nicht mehr was zu bewegen, Du wirst zum Schluß ruhiger leben. Es scheint eh keinen zu interessieren. Es ist leider wie so oft Engagement wird nicht belohnt. Sehr sehr traurig. Zeno
Schade,dieser Frust,ich habe gerade begonnen mit dieser Software herumzuspielen, und ich wollte mal DANKE sagen das Du Sie uns zur Verfügung gestellt hast Gruß Robert
Zeno schrieb: > Es ist > leider wie so oft Engagement wird nicht belohnt. Nein, es gibt durchaus Leute, die das nutzen und gerne sehen. Nur plärren sie nicht ständig in Foren herum, weil sie arbeiten müssen. @Albert: Nicht kirre machen lassen. Weiter Programmieren und cool bleiben.
Andreas F. schrieb: > Zeno schrieb: >> Es ist >> leider wie so oft Engagement wird nicht belohnt. > > Nein, es gibt durchaus Leute, die das nutzen und gerne sehen. Nur > plärren sie nicht ständig in Foren herum, weil sie arbeiten müssen. Die meisten hier müssen wohl arbeiten gehen um ihren Hobby fröhnen zu können. Aber wenn sich jemand - Albert - engagiert, versucht etwas zu bewegen und dabei auf die Wünsche der User eingeht, dann sollte er auch ein Feedback erwarten dürfen, insbesondere dann wenn er explizit danach fragt. Statt dessen bekommt er von Usern die immer und immer wieder eine bestimmte Funktionalität eingefordert haben, nur fadenscheinige Argumente, wie "ich teste, wenn ich eine passende Maschine habe", zurück. Hää?? Wenn ich eine bestimmte Funktionalität haben möchte und dies dann auch realisiert wird, dann habe ich die verdammte Pflicht und Schuldigkeit dies zu testen und ein Feedback zurück zu geben. Die Zeit sollte dann schon da sein, zumal die gleichen User offenbar ausreichend Zeit haben andere umfänglich dumm anzumachen und zu beleidigen. Sicher muß sich nicht jeder der frei verfügbares Gedankengut, Software, Dokumentation etc. aus Foren benutzt auch dazu äußern. Andererseits leben Foren vom Mitmachen, also Schreiben. Und natürlich finde ich es gut wenn jemand etwas tut und dann seine Arbeit auch noch der Allgemeinheit zur Verfügung stellt. Und natürlich sollte er sich nicht beirren lassen und weiter machen. Aber ein wenig Fairness ist doch wohl nicht zu viel verlangt. So wie es hier leider viel zu oft abläuft, muß man sich nicht wundern, wenn die Leute, die aktiv mitgestalten, frustiert sind und sich letzendlich zurück ziehen. Zeno
Angehängte Dateien:
-
Meldung.png
13 KB
Hallo Albert, wollte grad Dein Programm unter Win7 starten, bekam aber von AntiVir die angehängte Meldung... Gruss Chregu
Lade die beanstandete Datei doch mal bei virustotal hoch, dann bekommst du mehr Ergebnisse. Evtl. stört sich Avira an seinem DRM Modul, oder UDP Kommunikation.
Christian M. schrieb: > wollte grad Dein Programm unter Win7 starten, bekam aber von AntiVir die > angehängte Meldung... Das Programm ist durch ein Virtualisierungs-Tool gegen Einsicht in das Exe-File geschützt. Durch das Scramblen des exe-Files können sich dabei Byte-Muster ergeben, die Virussignaturen ähnlich sehen. In der neuesten Version des von mir benutzten Protection Tools gibt es ein jetzt Taggant-System, welches bei den meisten Anti-Virus-Tool Herstellern bekannt gemacht wurde. Damit dürfte das Problem bei den nächsten Versionen von SerialComGrapher und meinen anderen Programmen nicht mehr auftreten.
:
Bearbeitet durch User
Ja super Danke! Habs jetzt "force" laufen lassen. Muss mich noch reinarbeiten, so auf Anhieb hat's nicht funktioniert. Du, müssen die Daten mit Float unbedingt ein Komma haben, Punkt geht nicht? Gruss Chregu
Christian M. schrieb: > Du, müssen die Daten mit Float > unbedingt ein Komma haben, Punkt geht nicht? Ich sehe Du bist aus der Schweiz. Ändere mal das Windows Gebietsschema auf Deutsch, damit kannst Du die Float mit Punkt senden. Das sollte in der Software noch berücksichtigt werden.
Zeno schrieb: > Die meisten hier müssen wohl arbeiten gehen um ihren Hobby fröhnen zu > können. > > Aber wenn sich jemand - Albert - engagiert, Damit wir uns nicht missverstehen: Meine Aussage war, dass es sicher viele gibt, die solche Software leise nutzen und man nur deshalb, weil sie nichts schreiben, nicht schlussfolgern darf, dass sie es nicht gut finden. Nicht jeder hat die Zeit, ständig in Foren aktiv zu sein. Ich nutze das auch einfach mal eben und gut ist.
Gibt es eigentlich einen Grund, das nicht kommerziell einzusetzen?
Hallo Albert, Ich habe mir Deine Software mal angeschaut - prima gemacht! Was ich mir noch wünschen würde. Meine seriellen Daten sind so aufgebaut: (kommen von einem Druckregler) Adresse Sollwert Sensorwert Istwert Stellgröße Alle Daten sind durch Leerzeichen getrennt. Mich interessiert nur der Sensorwert, daher wäre es wünschenswert, dass man angeben kann ab welcher Stelle und wieviel Zeichen eingelesen werden. Zusätzlich wäre es schön, wenn man den zweiten Kanal von einer zweiten seriellen Schnittstelle darstellen könnte. Wiederum mit Auswahl ab welcher Stelle im Datensatz. MfG Gastinger
Hallo, ich habe jetzt diesen Thread gelesen. Habe aber das Programm noch nicht ausprobiert, fände es aber durchaus sehr nützlich. Habe auch den Wunsch meines Vorredners, nach flexiblen Datenstromaufbau. Also Position und Länge der Daten angeben. Eventuell für den zweiten Kanal eine zweite Startposition und Länge im Datensatz. Viele Grüße und ein schönes Wochenende Micha
BMSR-Techniker schrieb: > Habe auch den Wunsch meines Vorredners, nach flexiblen Datenstromaufbau. R. Gastinger schrieb: > Zusätzlich wäre es schön, wenn man den zweiten Kanal von einer zweiten > seriellen Schnittstelle darstellen könnte. Wiederum mit Auswahl ab > welcher Stelle im Datensatz. Lässt sich implementieren. Dauert allerdings etwas, da ich z.Z. mit der neuen Version SerialComInstruments 4 beschäftigt bin.
Hallo Albert M., vielen Dank, dass Du Deinen SerialComGrapher zur freie Nutzung zur Verfügung stellst. So etwas habe ich schon lange gesucht. Nach einigen kleinen Anlaufschwierigkeiten komme ich damit auch ganz prima zurecht. Allerdings gelingt es mir nur extrem selten, den SerialCom Grapher v0.9d unter Windows 10 zu starten. Ich erhalte fast immer die Fehlermeldung "Runtime error 216 at 00AF22E". Auf einem Rechnern mit Windows XP oder Windows passiert das so gut wie nie. Der SerialComGrapher v0.6.6 startet unter Windows 10 immer sofort fehlerfrei. Ich habe festgestellt, dass es etwas öfter gelingt, den SerialComGraphers v0.9d zu starten, wenn ich jeweils kurz zuvor die Version v0.6.6 gestartet habe. Ich habe meinen Rechner schon auf einschlägige, infrage kommende Viren überprüft, aber keine feststellen können. Gibt es Hinweise von anderen Usern, die evtl. dasselbe Problem haben? Hat irgend jemand eine Idee, wie man diesen Fehler beseitigen kann? Herzliche Grüße, Wolfgang
Über die große Suchmaschine bin ich auf Dein Programm SerialComGrapher gestoßen. Eine tolle Idee und für mich vielleicht eine echte Alternative zu LogView. Nachdem der Hinweis von Avira kam, habe ich den Echtzeitscan deaktiviert. Danach dachte ich, würde es laufen, aber leider kommt der Hinweis, dass das Programm nicht in einer virtuellen Maschine laufen wird. Ist das wirklich so gewollt? Ich nutze Ubuntu und habe Win7 nur in einer virtuellen Maschine laufen. Einen reinen Win-PC habe ich nicht. Läßt sich das Problem (außer durch eine Win-Installation) beheben? Mit Wine habe ich noch nicht viel gearbeitet. Wie läßt sich herausfinden, welchen COM-Port der USB-TTL Adapter bekommen hat? dmesg sagt: [16774.103462] cp210x 2-1.1:1.0: cp210x converter detected [16774.105679] usb 2-1.1: cp210x converter now attached to ttyUSB0 Wenn ich dann com1 wähle durch Eingabe von ln -s /dev/ttyUSB0 com1 kommt trotzdem der Hinweis in Deinem Programm "SetupCom function failed (Error:6) Frank
Frank S. schrieb: > Ist das wirklich so gewollt? ja Albert hat einen Schutz eingebaut, damit keiner auf die Idee kommt zu reengineeren. Daher läuft diese Software nicht unter Linux. Das ist ein Grund, warum sich schon mehrere beschwert haben. Wenn ich das richtig in Erinnerung habe sorgt der Schutz ebenfalls dafür, dass die SW nach einem Jahr ebenfalls nicht mehr funktioniert. Nur so als Hinweis ;-)
Hi Albert, ich möchte auch grad mal dein Programm ausprobieren. Leider fliegen mir beim Starten der Aufzeichnung Fehlermeldungen um die Ohren: - Thread-Fehler: Das Handle ist ungültig (6) - Listenindex überschreitet das Maximum (1) - Die Statusleiste meldet Buffer Overflow Ggw. möchte ich einen 16-Bit Wert aufzeichnen, Darstellung ist dezimal ASCII mit abschließendem CR/LF, Baudrate 115200, Schnittstelle ist ein USB/Seriell-Wandler von Cypress. TeraTerm zeigt die Daten korrekt an. Wenn ich es richtig berechnet habe müsste ich selbst bei einem einstelligen Messwert inkl. CR/LF bei max. 3840 Samples/s, also weit unter dem Maximum liegen. Die restlichen Einstellungen für Skalierung o.ä. habe ich nicht angepasst. Hab ich etwas übersehen? Gruß Ralf
Guten morgen Wie verbindie ich die Software mit den VL6180x sensor ist mit Arduino uno verbunden. Er zeigt schon die Schnittstelle aber wenn ich auch Play drücke zeigt er Fehler. Vielen dank
Tolles Projekt. würde ich gern ausprobieren. Gibt´s da noch ne virernfreie Version? Wahscheinlich ist diese hier schon zu lange im Forum. AVG: Böses Virus, Rang 45 der Bösenliste. Gruß aus Spandau
Thomas S. schrieb: > Gibt´s da noch ne virernfreie Version? Guckst Du oben im Thread: Beitrag "Re: Daten von der seriellen Schnittstelle einfach darstellen" In den nächsten Wochen gibt es eine neue Version ohne Virtualisierungs-Tool, welches diese false positiv Meldungen in einigen Antiviren Programme erzeugt.
Danke. Leider kann ich das Tool auch nach Forcen nicht starten. Irgendwer (win7) erlaubt´s nicht. Schade, muß ich warten. Gruß aus Spandau
Anbei neue Version SerialComGrapher V1.0
Change Log 1.0
---------------
Alle Beschränkungen entfernt:
- Keine zeitliche Beschränkung mehr.
- Obfuscation, Virtuelle Protection Maschine
und Länderbeschränkungen entfernt.
Neue Funktion im Fast-Display Betrieb:
- Der Inhalt des Fast Display kann jetzt direkt
mittels "clr" vom Mikrocontroller gelöscht werden:
Syntax: clr + CR + LF oder
CLR + CR + LF
als ASCI-String senden, wobei
CR = ASCI 13 und LF = ASCI 10
Gruss Ulrich Albert
http://www.serialcominstruments.com/
Anbei neue Version SerialComGrapher V1.0.1 Change Log 1.0.1 ---------------- Slow Display - Bug in der Start-Stop Logik behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hi servus leute, ist es möglich eine linux version davon zu bekommen?
hallo, ich habe gerade sas projekt am laufen : Beitrag "Messdatenaufnahme mit ATTINY 45/85" UNd deine software genau das macht, was ich auch selber machen würde, giebt es keinen sinn, es nochmal aufzubauen. Deshalb meine Frage: - könnte man es auf mehr als 2 kanäle ausweiten, oder aber zumindest die auswahl des kanals zu erweitern, so daß ich z,b kanal 1 und 5 auswählen kann. Da der platz dann wohl begrenzt ist, könnte man die instrumente ausblendbar machen. Gruß Michael
Beitrag #5238688 wurde von einem Moderator gelöscht.
Albert M. schrieb: > Nueva versión adjunta SerialComGrapher V1.0.1 > > Cambio de registro 1.0.1 > ---------------- > > Visualización lenta > - Se corrigió un error en la lógica start-stop. > > Saludos Ulrich Albert > http://www.serialcominstruments.com/ HOLA NO FUNCIONA EL LINK TIENE OTRO PARA PODER DESACRGAR LA APLICACION
Zeno schrieb: > Aber wenn sich jemand - Albert - engagiert, versucht etwas zu bewegen > und dabei auf die Wünsche der User eingeht, dann sollte er auch ein > Feedback erwarten dürfen, insbesondere dann wenn er explizit danach > fragt. Statt dessen bekommt er von Usern die immer und immer wieder eine > bestimmte Funktionalität eingefordert haben, nur fadenscheinige > Argumente, wie "ich teste, wenn ich eine passende Maschine habe", > zurück. Auch wenn dieser Thread nun schon etwas älter ist, möchtest Du vielleicht Folgendes verstehen: Es ging mir NICHT um eine Funktionalität oder darum, Alberts Software in einer Linux-Version zu bekommen. Es ging mir nur darum, zu verstehen, WARUM er sich offensichtlich große Mühe damit macht, zu verhindern, daß jemand seine Software mit einer Windows-VM benutzt.
Sheeva P. schrieb: > Es ging > mir nur darum, zu verstehen, WARUM er sich offensichtlich große Mühe > damit macht, zu verhindern, daß jemand seine Software mit einer > Windows-VM benutzt. Wohl einfach weil er es kann, ist ja nicht trivial. Der Gebrauch für bestimmte Länder ist ebenfalls in allen seinen Freeware Produkten unterbunden. Wird wohl seinen Grund haben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.