Jetzt habe ich entdeckt. Dezimalzeichen wird als Komma gesendet, vermutlich deshalb wird abgeschnitten.
Besteht die Möglichkeit in der Konfigurationsmodi diesbezüglich eine frei Wahl treffen?
rodnas schrieb: > Besteht die Möglichkeit in der Konfigurationsmodi diesbezüglich eine > frei Wahl treffen? Die Festlegung, ob Punkt oder Komma das Dezimaltrennzeichen ist, wird vom Betriebssystem übernommen (Regionseinstellungen). Bei Eingängen wird beides akzeptiert. Ich schau mal, ob ich das noch einstellbar machen kann.
Es geht weiter mit Version V0.44 mit folgenden Neuerungen: - Vollbildmodus und Vollfenstermodus implementiert, welche im Ausführen-Menü oder per Kommandozeilenparameter gestartet werden können. - Die Projektdatei kann beim Starten der Comvisu über Kommandozeile übergeben werden. Das ermöglicht auch die Dateiendungszuordnung in der Windows-Systemsteuerung, sodass Projekte per Doppelklick im Explorer geöffnet werden können. Die Kommandozeilenparameter "-Connect", "-FullScreen", "-FullWindow" und "-RunMode" sind selbserklärend, Details finden sich in der aktualisierten Dokumentation (im Zip). - Überarbeitetes Terminal mit der Anzeige aller (Ascii-) Zeichen, auch der Steuerzeichen und zusätzlicher Anzeige des Codes in hexadezimaler Schreibweise. Der Umbruch funktioniert nun sauber. - Auswahlmöglichkeit der anzuzeigenden Schnittstelle im Terminal. - Sporadisch auftretender Fehler beim Schließen der COM-Schnittstelle behoben.
Guten Morgen Est Est Est, danke für die Weiterentwicklung. Bemerkung: Bildanzeige funktioniert nicht mehr. Frage: Noch nicht probiert deshalb die Frage. Die Schnittstellenumschaltung für Terminal gilt jetzt auch für die Ausführungsmodus? Gruß rodnas
> Bemerkung: Bildanzeige funktioniert nicht mehr.
Entschuldigung, meine eigene Dummheit war die Ursache.
Gruß
rodnas
Währe es möglich die feste Kommastellen bei Analoganzeige/Schieber so zu realisieren wie bei der Nummerische Digitalanzeige? Ich meine diese zusätzliches Kontrollkästchen. rodnas
rodnas schrieb: > Guten Morgen Est Est Est, Guten Morgen~ > Frage: Noch nicht probiert deshalb die Frage. Die > Schnittstellenumschaltung für Terminal gilt jetzt auch für die > Ausführungsmodus? Nein, die Schnittstellenumschaltung gilt nur für das Terminal. Für den Hauptbildschirm ist eine solche Umschaltmöglichkeit in meinen Augen auch nicht so sinnvoll. Dort werden ja alle Schnittstellen verarbeitet. Entweder man braucht eine Schnittstelle oder nicht. Und zum Testen kann man ja die nicht benötigten Schnittstellen einfach löschen (z.B. nach abspeichern unter anderem Namen). Was ich mir aber vorstellen könnte, ist die Möglichkeit, Schnittstellen in der Liste deaktivierbar zu machen, das wäre evtl. interessant, wenn man einen Teilnehmer gerade nicht angesteckt hat. Moby A. schrieb im Beitrag #4600486: > Est Est Est, das war wieder ausgezeichnete Arbeit, ich bin begeistert! > Wieder ein gewaltiger Schritt nach vorne! Das ist schon eine richtig > runde Sache geworden. Soweit ich bislang testen konnte funktioniert > auch alles wie beschrieben. Fullscreen + beliebig viele Tabs, das ist > konkurrenzlos ! Danke, danke:-) > Zwei Frage noch > - zum Hintergrundbild: Lässt sich das im Fenstermodus ohne viel Arbeit > eventuell noch mit der Fenstergröße mitskalieren? Das schau ich mir mal an, sollte machbar sein. > - zur LED-Form: Wären runde Bauelementformen aufwendig umzusetzen? Vom Aufwand kann ich es noch nicht richtig abschätzen, deshalb hab ich es bisher auch noch nicht in Angriff genommen. Mal sehen, wann ich dazu komme.
rodnas schrieb: > Währe es möglich die feste Kommastellen bei Analoganzeige/Schieber so zu > realisieren wie bei der Nummerische Digitalanzeige? Ich meine diese > zusätzliches Kontrollkästchen. Ja, das ist kein Problem, ich baus bei der nächsten Version mit ein. EDIT: Die Einstellung würde sich dann auf den "Numerischen Wert" und auch auf die Skalenbeschriftung auswirken.
:
Bearbeitet durch User
Instrument Numerische Ausgabe: Die eingestellte Wert wird nicht abgespeichert.
Es gibt jetzt auch eine Linuxversion, dazu habe ich einen neuen Thread aufgemacht, Download dort: Beitrag "Comvisu für Linux"
Guten Tag Est Est Est, ich hätte einen Vorschlag, ein Instrument womit man zyklisch Daten senden kann. Also mit einstellbaren Intervalle z.B. von 10ms bis eine Stunde. Sozusagen eine getriggerte Numerische Ausgabe bzw. Taster. Gruß rodnas
rodnas schrieb: > Guten Tag Est Est Est, > > ich hätte einen Vorschlag, ein Instrument womit man zyklisch Daten > senden kann. Also mit einstellbaren Intervalle z.B. von 10ms bis eine > Stunde. > Sozusagen eine getriggerte Numerische Ausgabe bzw. Taster. Daran habe ich auch schon gedacht. Wo ich noch hänge, ist, dass es evtl. auch interessant sein könnte, (zyklisch) Werte zu schicken. Mal schauen, wie ich das Einbauen kann. rodnas schrieb: > Instrument Numerische Ausgabe: Die eingestellte Wert wird nicht > abgespeichert. Das hab ich mir schon notiert~
Hi, Ich hab deine Software mal ausprobiert, unter Windows & Linux. Und wie es mit neuen Usern so ist, hab ich gleich mal was zum herumjammern :-) - Leider funktioniert die Konsole über eine UDP-Verbindung nicht. Das Zeilende des Strings (\n) wird ignoriert und durch Leerzeichen ersetzt (in Terminal & Konsole). Das ist lt. Thread wohl schon länger ein Thema. - Ab und zu (bei bestimmten Stringwerten?) stolpert die Linuxversion mit folgender Fehlermeldung: ComvisuV045: xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Verbesserungsvorschläge: - Bei den Kurven-Widgets kann die Schriftart & Textfarbe nicht eingestellt werden (bei anderen Widgets gehts). - Einstellbare Font für die Konsole. - Recorder für die Konsole. MaW: Einfach die Texte die daherkommen (optional) in ein logfile mitschreiben. Ansonsten finde ich die Anwendung super, sie füllt genau die Lücke zwischen Debugausgaben und einer grossen, teuren und komplexen Prozessvisualisierung. Weiter so !
Werner A. schrieb: > Ich hab deine Software mal ausprobiert, unter Windows & Linux. > Und wie es mit neuen Usern so ist, hab ich gleich mal was zum > herumjammern :-) Kritik ist natürlich immer willkommen~ > - Leider funktioniert die Konsole über eine UDP-Verbindung nicht. > Das Zeilende des Strings (\n) wird ignoriert und durch Leerzeichen > ersetzt (in Terminal & Konsole). Das ist lt. Thread wohl schon länger > ein Thema. Habs grad nochmal probiert. Der Umbruch mit \n sollte eigentlich funktionieren. Kann es sein, dass dein Compiler für den µC das \n in das Steuerzeichen Zeilenumbruch (Ascii 0x0D) übersetzt hat? An der Stelle ist dann tatsächlich noch ein Fehler in der UDP-Schnittstelle, Steuerzeichen werden als Leerzeichen behandelt. Ich schau, dass in der nächsten Version dann auch Steuerzeichen als Umbruch akzeptiert werden (und der Fehler behoben). Bei der seriellen Schnittstelle könnte es sogar schon funktionieren. > - Ab und zu (bei bestimmten Stringwerten?) stolpert die Linuxversion mit > folgender Fehlermeldung: > ComvisuV045: xcb_io.c:165: dequeue_pending_request: Assertion > `!xcb_xlib_unknown_req_in_deq' failed. Passiert das mit eingeschaltener Konsole? Und nur mit eingeschaltener Konsole? > Verbesserungsvorschläge: > - Bei den Kurven-Widgets kann die Schriftart & Textfarbe nicht > eingestellt werden (bei anderen Widgets gehts). Ja, das ist sinnvoll. Idee war den Eigenschafteneditor kompakt zu halten. Ich bau es noch ein. > - Einstellbare Font für die Konsole. OK. > - Recorder für die Konsole. MaW: Einfach die Texte die daherkommen > (optional) in ein logfile mitschreiben. Ist sicher auch sinnvoll. Wird notiert~ > Ansonsten finde ich die Anwendung super, sie füllt genau die Lücke > zwischen Debugausgaben und einer grossen, teuren und komplexen > Prozessvisualisierung. > Weiter so ! Danke:-)
Neue Version V0.5. - Für das Menü können jetzt als Sprache statt Deutsch auch Englisch oder Chinesisch eingestellt werden. Die Auswahl erfolgt über das Menü oder per Kommandozeilenparameter beim Starten des Programms ("-lang=de", "-lang=en" und "-lang=zh"). - Es gab diverse interne Probleme insbesondere bei Verwendung mehrerer Schnittstellen, aber auch in der Terminal- und Konsolenausgabe, welche jetzt soweit behoben sind. - In den Diagramm-Instrumenten lässt sich nun die Schriftart/-Größe einstellen. - Für die Konsole lässt sich nun die Schriftart einstellen - Aufzeichnung der Konsole in eine Datei möglich. - Numerische Ausgabe speichert Eingabefeld mit ab. - Analoganzeige: Digitalwert und Skalenwerte können nun mit fester Anzahl an Nachkommastellen angezeigt werden. - Passive Befehle nun möglich, d.h. der Befehl löst keine Berechnung für die abhängigen Instrumente aus, sondern schreibt den Kanalwert nur in den entsprechenden Kanalspeicher. Passive Befehle sind solche mit vorangestelltem Schrägstrich "/". Z.B.: "/#5F12;" schreibt den Wert 12 in den Speicher von Kanal 5, aktualisiert aber keine Instrumente. Das ist sinnvoll, wenn ein Instrument von mehr als einem Kanal abhängt und daher "Zwischenwerte" zu falschen Werten führen würden. Beispiel: Eingang =#5*#6 darf bei sich gleichzeitig ändernden Werten für die Eingänge #5 und #6 nur einmal berechnet werden. Die Befehlsfolge "/#5F__;#6F__;" ermöglicht das. - Bewegen im Bearbeitenmodus bei gedrückter Steuerungstaste bewegt das Instrument nun gerastert in 10er Schritten.
Moby A. schrieb im Beitrag #4634429: > Die englische und vor allem chinesische Sprach-Erweiterung sind ja ein > echter Genie-Streich! Was für eine Markt-Erweiterung! ;-) Jetzt muss ich nur noch ein chinesisches Mikrocontroller.net finden:-)
Hallo Est Est Est, alle Achtung, wieder super Leistung! Danke rodnas
Moby A. schrieb im Beitrag #4640027:
> Die Instrumenten-Abmaße lassen sich nicht mehr frei ändern.
Habs grad getestet, geht eigentlich schon. Welche Instrumente lassen
sich bei dir nicht in der Größe ändern?
Grüße
Moby A. schrieb im Beitrag #4640685:
> Habe gerade nochmal die Zeichenausgabe getestet
OK, das Problem tritt bei mir auch auf, ich schau mirs an.
Moby A. schrieb im Beitrag #4641038: > Stichwort Tasterinstrument: Wäre es möglich, diesem einen "freien" > Rückgabewert zuordnen zu können, d.h. beliebige numerische Werte, > insbesondere aber auch Zeichenketten? Das sollte kein Problem sein, dann gibt es 2 zusätzliche Modi, Freitext als Zahl und Freitext als Zeichen.
Version V051: - Fehler beim Ändern der Größen behoben, betroffene Instrumente: Fernanzeige, Zeichenausgabe, Mehrfachzeitdiagramm. - Tasterinstrument kann nun optional auch einen frei definierbaren Text/Zahl senden
Moby A. schrieb im Beitrag #4642354: > Und das bei dem Wetter! Ja, einen Sonnenbrand hab ich mir heute auch schon geholt~ > Dafür ist es natürlich essentiell, > alle benötigten Instrumente samt endgültiger Codes zu kennen. Es kommen ja eigentlich immer nur Funktionen hinzu, du kannst dich also zumindest darauf verlassen, was schon verfügbar ist. Was ich auf jeden Fall noch vorhabe, ist ein Konsoleninstrument, d.h. ruhig ein Kanal pro Schnittstelle dafür freihalten. > Wenn ich das richtig sehe sind damit nun > x-beliebig viele Taster möglich geworden und es langt für alle ein > einziger Kanal, weil sich jetzt alle über ihre Rückgabewerte > unterscheiden lassen !? Stimmt, so weit hab ich gar nicht gedacht :-) Dann kann man jetzt die Taster einfach durchnummerieren oder sogar per Namen unterscheiden.
Hallo, ich habe jetzt unter Linux das Programm probiert und nach einem kleinen Problem (siehe Beitrag "Comvisu für Linux") hat es auch funktioniert. Interessant ist die Syntax für die serielle Kommunikation. Vor einigen Jahren haben ein Kollege und ich was ähnliches gemacht. Die Protokolle sind fast ident. Mir würde diese Art von Anwendungen als Web-Server vorschweben/sehr gefallen. Dann wäre es auch netzwerk- und handytauglich: COM AJAX/WebSockets [Arduino...]<--->[node.js WebServer]<--------------->[Browser] Aber leider wegen mangelnder Zeit + Bedarf verfolge ich momentan die Idee aktiv nicht weiter. Ein Demo/Grundgerüst eines Workshops, den ich gehalten habe, ist im Anhang. Vielleicht interessiert dich auch dieser Ansatz. Lg, Klaus
Weinga U. schrieb: > Hallo, > > ich habe jetzt unter Linux das Programm probiert und nach einem kleinen > Problem (siehe Beitrag "Comvisu für Linux") hat es > auch funktioniert. > > Interessant ist die Syntax für die serielle Kommunikation. Vor einigen > Jahren haben ein Kollege und ich was ähnliches gemacht. Die Protokolle > sind fast ident. > > Mir würde diese Art von Anwendungen als Web-Server vorschweben/sehr > gefallen. Dann wäre es auch netzwerk- und handytauglich: > > COM AJAX/WebSockets > [Arduino...]<--->[node.js WebServer]<--------------->[Browser] > > Aber leider wegen mangelnder Zeit + Bedarf verfolge ich momentan die > Idee aktiv nicht weiter. Hallo Klaus, das Programm habe ich dahingehend entworfen, um ein Hilfsmittel für die µC-Programmierung zu haben, insbesondere für Schaltungen mit Sensoren etc. Daher gibt es auch ein explizites Konsolenfenster mit fester Kanalzuordnung (minimaler Einrichtaufwand). Oder per Default verschiedene Farben für die Bearbeiten- und Ausführenoberfläche anstatt verschiedene Farben pro Blatt. Für die Benutzung als User-Interface kann man sich das ja dann trotzdem nach eigenem Gusto einrichten. Für die oben genannte Anwendung ist aber ein klassisches PC-Programm am Geeignetsten. Man braucht keinen Server einrichten usw. Eine Erweiterung für eine Browserdarstellung wäre sicher nützlich und wünschenswert, aber dann doch ein Riesenaufwand, da ja dann beide Systeme bedient werden müssen, insbesondere die Grafik muss dann getrennt erzeugt werden. D.h. für mich ist das nicht machbar.
Hallo Est Est Est, die Zielgruppe deiner Anwendung ist mir klar. Die Idee mit nodejs wäre gleich eine reine Web-Anwendung, die auch lokal natürlich wie ein Programm verwendet werden kann. D.h. man startet die Nodejs Anwendung mit >node comvisu.js und verbindet sich im Browser mit 127.0.0.1 und sieht dort auch die Signale oder was auch immer. nodejs ist der Web-Server und arbeitet als Kommandozeilenprogramm. Es managed die serielle Schnittstelle und liefert alle Daten und Dateien an den Browser der gerade anfragt. Ein Demo wie gesagt in meiner ZIP Datei. Den Vorteil, den deine Lösung hat, ist die standalone EXE. nodejs Anwendungen kann man auch packen, das habe ich aber noch nicht probiert. Dann wäre es auch standalone. Schön finde ich, dass du mehrere Comports und UDP unterstützt. 1. Frage: Die Signalplots, sind die Punkte resampled? 2. Frage: Beim Datarecorder: können mehrere Signale in einer Datei aufgezeichnet werden? Danke. Klaus
Weinga U. schrieb: > Die Idee mit nodejs wäre > gleich eine reine Web-Anwendung, die auch lokal natürlich wie ein > Programm verwendet werden kann. > D.h. man startet die Nodejs Anwendung mit > >node comvisu.js > und verbindet sich im Browser mit 127.0.0.1 und sieht dort auch die > Signale oder was auch immer. > nodejs ist der Web-Server und arbeitet als Kommandozeilenprogramm. Es > managed die serielle Schnittstelle und liefert alle Daten und Dateien an > den Browser der gerade anfragt. Ein Demo wie gesagt in meiner ZIP Datei. Ah Ok, da hatte ich dich nicht richtig verstanden. Ehrlich gesagt habe ich gewisse Vorbehalte gegenüber Web-Anwendungen. Mir ist einfach noch keine begegnet, welche sowohl umfangreich ist als auch ordentlich bedienbar wäre. Insofern habe ich mich auch noch nicht in diese Richtung informiert/eingearbeitet. Deine Demo hab ich runtergeladen, wie kann ich die Demo starten? > Den Vorteil, den deine Lösung hat, ist die standalone EXE. nodejs > Anwendungen kann man auch packen, das habe ich aber noch nicht probiert. > Dann wäre es auch standalone. Ja, eine Exe läuft einfach, man braucht keinen passenden Browser, scripting erlauben etc. > 1. Frage: Die Signalplots, sind die Punkte resampled? Eingehende Befehle werden verarbeitet/berechnet und in den Instrumentenspeicher geschrieben. Dieser Speicher wird vom Diagramm selbst in einer einstellbaren Periode abgetastet. So kann man die Datenmenge an seine Aufnahmedauer anpassen. Außerdem ist die CPU-Auslastung für die Abtastung im Grunde immer gleich (keine Überraschungen). Dafür verliert man aber Werte, wenn zwischen je einer Abtastung zwei oder mehr neue Werte reinkommen. > 2. Frage: Beim Datarecorder: können mehrere Signale in einer Datei > aufgezeichnet werden? Bisher nicht, das steht aber ganz oben auf meiner Liste! Bisher lassen sich auch nur Zahlenwerte speichern.
Ich will jetzt nicht diesen Thread offtopicen, aber mein Demo kannst du starten wie folgt: 1. nodejs downloaden und installieren https://nodejs.org 2. Konsole im workshopserver verzeichnis öffnen 3. "npm install" ausführen, dann werden zusätzliche pakete downgeloaded 4. "node server.js" ausführen 5. Browser öffnen und 127.0.0.1:8080 eingeben (optional mit Hardwaresupport) 6. Arduino Software einspielen 7. in server.js den comport einstellen: /dev/ttyUSB0 ändern in \\.\COMx 8. Schritt 4 und 5 ausführen. Ich hoffe, ich habe nichts übersehen. Lg, Klaus
Neue Version V0.60 - Das Zeitdiagramm ist weitgehend überarbeitet, es sind jetzt bis zu 10 Kurven in einem Diagramm möglich und es können bis zu 6 Y-Skalenbereiche konfiguriert und die Kurven zugeordnet werden. Achsenbeschriftungen sind nun auch möglich. Es gibt außerdem einen definierbaren Steuerkanal, über welchen das Diagramm über die Schnittstelle zurückgesetzt werden kann. Die Befehle (als Zeichenkette S) lauten "Clear" und "Reset". Das Zeitdiagramm kann nun maximal 100.000 Punkte aufzeichnen, darüber hinaus werden jeweils die ältesten 5000 Punkte gelöscht. Dadurch wird auch bei einer langen Aufzeichnung eine Überlastung verhindert. - Neues Instrument XY-Diagramm bei welchem der X- und Y-Wert über getrennt über zwei Eingänge übermittelt wird. Bei jedem Eingang über den X-Kanal wird ein Punkt gezeichnet, entsprechend muss zuerst der Y-Wert und dann der X-Wert übertragen werden. - Diverse kleinere Änderungen. Für das Zeitdiagramm gibt es nur erstmals keine direkte Rückwärtskompatibilität mehr. Zwar wird das Diagramm geladen, aber die Werte für den Eingang, die Achsenbereiche und die Kurvenfarbe werden nicht übernommen. Desweiteren können Diagramme, welche mit der neuen Version gespeichert wurden, nicht in alten Versionen geöffnet werden. In dem Fall kommt es zu einem Absturz. Der zugrundeliegende Fehler ist nun behoben, für die alten Versionen kann das aber natürlich nicht mehr rückwirkend angepasst werden. Das aber nur am Rande, es sollte sowieso keinen Grund geben, auf eine alte Version zurückzugehen. Ich hab nun endlich auch eine Homepage eingerichtet, ein Download ist auch dort möglich: www.comvisu.de Edit: Für das Zeitdiagramm lässt sich für die X-Achse nun auch die aktuelle Uhrzeit und das Datum anzeigen
:
Bearbeitet durch User
Sehr schön. Gerade entdeckt. Freue mich schon darauf wieder aufer Arbeit zu sein um es aus zu testen. Gibts inzwischen eine Webseite? Du könntest ein bisschen Werbung vertragen wie die Downloadzahlen zeigen. Werds mal herumsprechen. Wird ab Version 1 verkauft?
hallo schrieb: > Gibts inzwischen eine Webseite? Ja, hab ich grad im letzten Beitrag verkündet (ich weiß, ist mittlerweile ein langer Thread): http://www.comvisu.de > Du könntest ein bisschen Werbung vertragen wie die Downloadzahlen > zeigen. Werds mal herumsprechen. Werbung wäre auf jeden Fall nicht schlecht! Die Möglichkeiten sind schon weitgehend, ich denke man kanns guten Gewissens weiterempfehlen. > Wird ab Version 1 verkauft? Wie geschrieben stell ich das Programm Privatleuten sowieso immer kostenlos zur Verfügung. Und kommerzielle Interessenten haben sich bisher nicht gemeldet, von daher... nein. Dass ich auf Version 1 hinarbeite hat damit zu tun, dass jetzt die Erweiterung der Funktionalität im Vordergrund steht und auch Inkompatibilitäten zwischen Versionen auftreten können. Für die einzelnen Versionen teste ich meistens nur die Dinge, wo ich auch direkt etwas geändert habe. Dabei passieren schon auch mal Schnitzer. Version 1 soll dann quasi ein 'Stable Release' sein.
Ich finde das Programm richtig gut und echt hilfreich. Gerade durch die Verwendung von Formeln ist es recht gut zu konfigurieren. Allerdings hätte ich einen Wunsch. Ich würde es gut finden, wenn in den UDP-Socket-Einstellungen unter eigene Adresse auch die aktuell eigenen IP-Addressen aufgeführt wären. Es scheint mir so, dass "192.168.2.8" aktuell nur als Platzhalter dient. Grüße Alex
Alex schrieb: > Es scheint mir so, dass "192.168.2.8" aktuell nur als Platzhalter dient. Das ist richtig, es soll nur zeigen, wie die Adresse in etwa aussehen sollte. > Allerdings hätte ich einen Wunsch. Ich würde es gut finden, wenn in den > UDP-Socket-Einstellungen unter eigene Adresse auch die aktuell eigenen > IP-Addressen aufgeführt wären. Ich hatte mir das früher schonmal angeschaut. Die Schnittstellenbibliothek stellt aber keine Möglichkeit zur Verfügung nur IP4-Adressen anzuzeigen. Gut, die IP6-Adressen schaden wohl auch nicht... ich schau danach~ Grüße
Hallo Est Est Est, meine besten Wünsche zur Weiterentwicklung! Kleine Bemerkung: Die Beschriftung der Zeitachse zeigt bei mir nur Punkt an, anstatt Doppelpunkt. Gruß rodnas
Hallo rodnas! rodnas schrieb: > Kleine Bemerkung: Die Beschriftung der Zeitachse zeigt bei mir nur Punkt > an, anstatt Doppelpunkt. Du meinst in der Datum/Uhrzeit-Darstellung? Der Punkt ist hier Absicht, da es sich um die Trennung Minuten und Sekunden (mm.ss) handelt. Die Voreinstellung des Diagrammbereichs sind ja 20 Sekunden. Der Punkt als Trennzeichen ist zur Unterscheidung gegenüber Stunden und Minuten (hh:mm). Einfach Rauszoomen (Ctrl+Scrollen) oder Diagrammgrenzen größer einstellen, dann wird es klarer. Das Trennzeichen für Millisekunden ist auch ein Punkt, hat aber immer 3 Stellen dahinter (mm.zzz). Grüße
Guten Morgen Est Est Est, vor etwa 3 Monaten haben wir uns über ein Instrument mit der Fähigkeit zyklisch Daten senden zu können unterhalten. Ist diese Gedanke zur Reife gekommen? Gruß rodnas
Neue Version V0.7: - Neues Instrument Getaktete Ausgabe. Das Instrument gibt zyklisch Werte aus, die Periode ist einstellbar ab mindestens 0,1 Sekunden. Für den Wert kann eine Konstante oder eine Berechnungsformel angegeben werden. Im Gegensatz zu "normalen" Eingängen wird der Wert immer beim Senden berechnet und nicht durch etwaige Eingänge getriggert. Damit kann beispielsweise die aktuelle Uhrzeit mit der Funktion time() übermittelt werden. - Neue Funktionen time(), date() und datetime(). Gibt jeweils die aktuelle Uhrzeit als Zahlenwert im Format hhmmss, YYYYMMDD bzw. YYYYMMDDhhmmss zurück. - Überarbeitets Instrument Dateirekorder. Der Eingang verarbeitet nun sowohl Zahlenwerte als auch Zeichenketten. Außerdem können nun bis zu 10 Werte in eine Datei aufgezeichent werden, die hintereinander, d.h. als Spalten, angeordnet werden. Zu beachten ist, dass immer dann eine neue und komplette Zeile in die Datei geschrieben wird, wenn ein Wert auf dem ersten Kanal eingeht. D.h. die anderen Kanäle müssen zuerst bedient werden. - In der Schnittstellenanzeige für UDP-Verbindungen werden nun die verfügbaren lokalen IP-Adressen angezeigt, sowohl IP4- als auch IP6-Adressen. Bei Klick auf die Adresse wird diese für die Schnittstelle übernommen. Die "Klickübernahme" ist jetzt auch für die seriellen Schnittstellen (nur in der Windowsversion) implementiert. Viel Spaß~
Hallo Est Est Est, Wäre der Aufwand zu groß für LED-s bzw. Fernanzeige eine zuschaltbare Blinkfähigkeit anzuheften? Grüße rodnas
Ein Gedankenspiel: Ein Matrix Instrument welches von der Taktausgabe gezielt schrittweise oder zufällig lesbar ist und dessen Inhalt an µC weitergeleitet wird. Gruß rodnas
rodnas schrieb: > Wäre der Aufwand zu groß für LED-s bzw. Fernanzeige eine zuschaltbare > Blinkfähigkeit anzuheften? Hallo Rodnas, Ich hab schon ein neues LED-Instrument vorgesehen, welches nur Impulse ausgibt (Ist sogar schon fertig~). Ein Modus 'Dauer-Blinken' für die normale LED wär aber vielleicht zusätzlich auch nicht schlecht. rodnas schrieb: > Ein Gedankenspiel: > Ein Matrix Instrument welches von der Taktausgabe gezielt schrittweise > oder zufällig lesbar ist und dessen Inhalt an µC weitergeleitet wird. Mit Matrix meinst du eine Lookup-Tabelle, oder? Das wurde weiter oben im Thread schon mal angesprochen. Die Umsetzung ist aber nicht ganz einfach, für jede Lookup-Tabelle müsste dann eine Funktion zum Abrufen bereitgestellt werden, was einen Eingriff in den Parser bedeutet... Also eher nicht, aber ich behalts im Hinterkopf. Grüße
Neue Version V0.80: - Neues Instrument BlinkLED. Die LED leuchtet immer auf, wenn ein Wert größer Null eingeht. Ist die LED bei Eingang bereits in einem Blinkvorgang, so wird genau ein Impuls in direktem Anschluss an die Pausenzeit berücksichtigt, d.h. ein neuer Blinkvorgang gestartet. So wird bei vielen kontinuierlichen Impulsen trotzdem ein gleichmäßiges Blinken erreicht. Einsatz z.B. als 'Online'-Anzeige oder zum Darstellen von Schnittstellenaktivität etc. - Neues Instrument LED-Leiste zur binären Anzeige von Zahlen. Einsatz z.B. zur Darstellung von Portzuständen - Neues Instrument Tongeber. Gibt einen Signalton mit einstellbarer Frequenz aus. Modi Dauerton, Intervallton und Einzelimpuls einstellbar. In der Linuxversion funktioniert die Tonausgabe nicht, d.h. das Instrument ist unter Linux nicht funktionstüchtig (verursacht aber auch keinen Fehler). - E/A-Kanal jetzt mit Sendeanimation, um zu sehen, ob Werte verarbeitet werden.
Hallo Est Est Est, danke für deine Arbeit. Ich verwende dein Programm sehr gerne. Folgende Feature-Requests bzw. Ideen hätte ich (einfach zum Nachdenken). Ich verstehe, dass diese auch komplexer sind als Led EIN/AUS. 1) Comvisu kann HTTP Requests an einen Server machen, wo ebenfalls die Daten in beiden Richtungen ausgetauscht werden können (selbe Format). D.h. eine neue Verbindungsart mit URL und einer Zykluszeit für die Requests. Eine schnelle Kommunikation kann man so natürlich nicht machen. HTTPS bitte auch nicht vergessen. 2) Eine Möglichkeit SVGs zu verwenden, wo in den Transformationen (Drehung, Schieben) die Formeln mit #5 z.B. drinnen Stehen. So könnte man Animationen machen. Das SVG selbst muss natürlich in einem anderen Programm erstellt werden. Keine Ahnung, ob dein GUI Toolkit das gut unterstützt. 3) Der µC selbst kann die GUI an comvisu schicken und so die Visu aufbauen. Dann hat man immer die richtige Anzeige zum richtigen Projekt. Ich denke es würde reichen, wenn comvisu das ganze als BASE64 exportieren und importieren kann. Der µC schickt das dann beim Einschalten rüber (oder so ähnlich :-) ) Lg
Hallo Weinga Unity, die Vorschläge hören sich gut an. Sind aber, wie du ja auch schon bemerkt hast, keine Kleinigkeiten. Ich schau mir auf jeden Fall mal an, was für die Umsetzung in etwa nötig wäre und hab auch gleich ein paar Fragen~ Zu 1) In dem Bereich kenn ich mich nicht gerade aus, vielleicht kannst du es noch ein bisschen konkrekter ausführen. Wenn ich es richtig verstehe, wird beim HTTP-Request keine Verbindung gehalten, sondern nur solange die Abfrage ausgeführt wird? Das heißt, dass wenn man in der Comvisu auf "Verbinden" geht, dann auch keine Verbindung aufgebaut werden würde, sondern immer nur dann, wenn tatsächlich eine Anfrage gesendet werden soll, und zwar für jede Anfrage einzeln. Eine Anfrage wäre dann das Senden eines Wertes, z.B. über ein Tasterinstrument. Statt "GET ..." würde dann z.B. "#5F1;" in der Anfrage stehen. Geht das überhaupt? Oder müsste der Befehl in den Datenteil der Anfrage? Der Server würde dann innerhalb eines Timeouts ggf. auf die Anfrage mit einem Befehl antworten. Die Antwort wird dann ganz normal als ein eingehender Befehl verarbeitet. Das heißt, der Server kann selber nur auf Anforderung Senden. Zu 3) Ein Problem dabei ist allerdings, dass die Schnittstelle ja schon verbunden und damit auch eingerichtet sein muss, um die Daten senden zu können. Was ich mir als einfachere Alternative vorstellen könnte, ist, über einen speziellen Befehl den Pfad der .visu-Datei zu senden, die dann geladen wird. Funktioniert dann halt nur am gleichen Rechner.
Hallo Est Est Est, 1) Ja, man macht je Request eine Verbindung auf, die wieder geschlossen wird. Du müsstest einen GET-Request machen und im URI https://test.cc?data=#5F10.3;#2F30,4; Kannst du Daten zum Server schicken. In Response (Dateibereich) kannst du dann Daten empfangen. Auch wieder ein String. Server kann so selber nichts senden. 3) Das Problem wurde mir auch kurz nach meinem Betirag bewusst... Lg
Alles klar, dann hab ichs soweit verstanden und versuch mich mal daran~ Grüße
Ich hab jetzt mit dem URL-Request ein bisschen rumprobiert, scheint für HTTP auch soweit zu funktionieren. Weinga U. schrieb: > HTTPS bitte auch nicht vergessen. Genau das hat sich als Problem rausgestellt. Bibliotheken für verschlüsselte Verbindungen habe ich nur solche gefunden, welche als DLL eingebunden werden, d.h. das würde das jetzige Konzept einer Stand-Alone-EXE kippen, was ich aber nicht möchte. Das heißt die Frage ist jetzt, wäre eine URL-Request auch ohne Verschlüsselung noch interessant? Oder kennt jemand eine SSL-Bibliothek für Lazarus, welche statisches Linken erlaubt?
Hallo Est Est Est, HTTP ohne (s) wird auch akzeptiert :-) Ich wollte damit ausdrucken, dass (wenn möglich) HTTPS auch gleich mit implementiert wird. D.h. du hast schon was funktionsfähiges hinbekommen? Lg
Weinga U. schrieb: > D.h. du hast schon was funktionsfähiges hinbekommen? Ja, ein URL-Request hab ich hinbekommen, ist aber noch nicht in die Comvisu integriert. Mir fehlt auch die Möglichkeit zu testen, ob der Dateibereich richtig ankommt. Vielleicht kannst du testweise einen Server einrichten, an den ich Anfragen schicken kann und der einfach ein Echo schickt? Oder Kanal+1, wie auch immer. Sollten (Ziel-)Portnummern einstellbar sein, oder geht man da sowieso immer über den Standardport? Grüße
URL mit Port-Nummer ist sicher hilfreich. Ich kann dir sicher einen kleinen Server mit node.js machen, den du lokal bei dir dann laufen lassen kannst. Wann ist eher das Problem. Gib mir etwas Zeit. Lg
Ich dachte eher an einen (deinen) Server online :-) Naja, ich implementier und teste die URL-Anfrage mal so weit ich komm, dann sehen wir weiter. Vielleicht findet sich auch sonst jemand, der eine Echo-Funktion in seiner Seite kurz einbauen kann?
Hallo Est Est Est, ich habe einen kleinen Echo-Server mit node.js geschrieben. 1) nodejs.org downloaden 2) Datei im Anhang downloaden 3) Terminal öffnen im Ordner mit der server.js Datei 4) Starten mit >node ./server.js serverport=8080 5) Browser öffnen und eingeben: http://127.0.0.1:8080/echo?comvisu=%235F12,3;%236F32,3; %23 ist das # Symbol im URL Ich habe nach einem nodejs Dienst gesucht und auch gefunden. Aber ich kenn mich mit dem Web-Interface nicht aus :-) Lg
Hallo Weinga Unity, Unsere Bemühungen haben sich jetzt ein bisschen überschnitten, ich hab in der Zwischenzeit schon eine erste Implementierung gemacht gehabt. Im Protokoll gibt es einen kleinen Unterschied, und zwar habe ich es so umgesetzt, dass beim Senden der Befehl im Dokument/Dateibereich übermittelt wird und nicht hinter dem Fragezeichen mit in der URL steckt. Vorteil ist, dass das Format in beide Richtungen gleich ist und die URL tatsächlich 1:1 wie in den Schnittstelleneinstellungen aufgerufen wird. Spricht da etwas dagegen, es so zu machen? Vollständig testen konnte ich meine Lösung bisher nicht, den Ausgang habe ich mir mit WireShark angeschaut und für den Eingang eine Datei mit Inhalt "#0STestRequest" auf meine Webseite gestellt. Hat soweit beides funktioniert. Viele Grüße~
Hallo Est Est Est, entweder irre ich mich jetzt total, aber es gibt ja keinen HTTP-Request (GET, PUT, POST), der es offiziell erlaubt, Daten in beide Richtungen über den Dokument/Dateibereich zu schicken. Deswegen schicke ich die Daten immer über den URL zum Server und die Daten vom Server zum Client im Dokument/Dateibereich. Und alles über einen GET Request. Aber ich kann mich auch irren. Lg
Alles klar, habs jetzt verstanden, die Schnittstelle würde es ermöglichen, aber standardkonform wäre es dann nicht mehr. Dann bau ichs entsprechend um. Ist gut, dass wir darüber gesprochen haben~~ Grüße NACHTRAG: Wenn ich das richtig seh, sind einige Zeichen in der URL nicht erlaubt, d.h. ich muss sie dann ersetzen, wie du es mit der Raute "#" gemacht hast?
:
Bearbeitet durch User
Hallo Est Est Est, ja, das ist immer so eine Sache mit den Zeichen und du siehst das richtig. Darum haben sich auch BASE64 und ähnliches bewährt. D.h. bei Strings musst du aufpassen im URL. Lg
Hallo Weinga Unity, jetzt habe ich nochmal weitergesucht, so ganz zufrieden bin ich noch nicht. Es sind doch einige Zeichen, welche nicht erlaubt sind. Eine zusätzliche Problematik sind dann wohl Unicode-Zeichen. Über Daten im Dateibereich würde sich das vereinfachen, auch bei der Gegenstelle. Laut englischer Wikipedia kann POST in beiden Richtungen einen Body (=Dateibereich?) enthalten. https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Summary_table Aber für mich ist das hier Neuland, d.h. ich lass mich auch überzeugen.
Das ist auch so. Ein POST-Request sendet Daten zum Server mit dem selben Verfahren, mit dem der Server antwortet. URL's haben ja nicht nur "Zeichen-Einschränkungen", sondern machen auch "Probleme", wenn mal etwas mehr Daten mitkommen sollen.
Gibt es dann sonst etwas, das gegen POST und die Übertragung der Befehle im Dateibereich sprechen würde?
Neue Version V0.90 mit folgenden Neuerungen: - Neue Schnittstellenart: URL-Request. Wie in den letzten Beiträgen besprochen lassen sich nun URL-Anfragen durchführen. Es wird die Methode "POST" verwendet und der Sendebefehl in den Dateibereich (Body) der Anfrage gepackt. Der Dateibereich der Antwort vom Server wird dann als Eingang verarbeitet, eine leere Antwort wird ignoriert. Als URL kann eine IP mit zugehörigem Port oder eine "echte" URL angegeben werden, z.B. "comvisu.de/TestRequest". SSL-Anfragen (https) sind nicht möglich. Beim Verbinden wird als Verbindungstest eine "GET"-Anfrage gesendet. - Neues Instrument Lookup-Tabelle Das Instrument Lookup-Tabelle stellt zur Benutzung durch andere Instrumente eine Funktion zur Verfügung, als Funktionsargument wird der Indexwert übergeben. Der Name der Funktion ist in den Eigenschaften der Lookup-Tabelle zu definieren. Die Anzahl an LUT-Instrumenten ist nicht beschränkt und es können quasi beliebige Namen verwendet werden. Die Indexwerte können wahlweise gerundet oder interpoliert werden. - Neue Funktionen (speicherwertig): COUNT,LAST,Z,SEQMIN,SEQMAX,FLOATAVG Speicherwertige Funktionen ist eine neue Kategorie an Funktionen, im Gegensatz zu den bisherigen Funktionen haben sie für jede Verwendung eigene Speicher. So zählt die Funktion COUNT beispielsweise bei jedem Aufruf um eins hoch, und zwar für jedes Instrument getrennt. Details zu den Funktionen sind in der Doku beschrieben. Wenn es Wünsche für weitere Funktionen gibt einfach sagen:-) - Neue Funktionen ANS und Null ANS gibt den Wert des letzten Ergebnisses zurück, sinnvoll zur Berechnung von Filtern. Null gibt unabhängig von den Funktionsargumenten den Wert 0 zurück, äquivalent zu 0* (Null mal...). So zählt Beispielsweise ein Eingang "count()+null(#5)" (Äquivalent zu "count()+0*#5") jeden eingehenden Befehl auf Kanal #5. - Zeitdiagramm löst nun bei jeder Abtastung eine Berechnung aus. Das kostet zwar Rechenzeit, aber so können Funktionen zur Filterung eingesetzt werden, zum Beispiel mit gleitendem Mittelwert (FLOATAVG). - Fehler in XYTimeChart beseitigt Wie immer gibt es auch eine Linuxversion, siehe Beitrag "Re: Comvisu für Linux" Downloads auch unter http://Comvisu.de
Hallo Est Est Est, Lookup-Tabelle Wertetabelle: Fehler beim Laden der Datei Grüße rodnas
Das deutet auf einen Fehler im Dateiformat hin, probier mal die angehängte LUT aus, oder schicke mir deine zum testen. Die beiden Spalten müssen durch ein Tab oder durch e i n Leerzeichen getrennt sein. Grüße
Es funktioniert!!! :) Jetzt habe ich mit Windows Editor erstellt. Früher mit Open Office aber auch als txt abgespeichert und fehlgeschlagen. Danke! rodnas
Hallo Est Est Est, Ich wünsche Dir einen guten Rutsch ins neue Jahr, viel Glück, Gesundheit und Erfolg und Lust das Programm weiter zu entwickeln was Du uns geschenkt hast. Danke nochmals Rodnas
Auch von mir die besten Wünsche. Muss mich jetzt mir dem Proggi mal befassen!
Bei mir ist es jetzt schon schon zweimal abgestürzt. Habe allerdings eine Spezial-CPU auf Win7. Werde es mal auf einem anderen PC testen, ob das da auch so ist. Aber mal was zur Funktion, mit dem Hinweis, daß Ich das noch nicht 100% getestet habe und es sein kann, dass das eine oder andere schon realisert ist. Was es vielleicht noch bräuchte, um damit effektiv arbeiten zu können: - ein ab- und einschaltbares Raster zum Platzieren der Bauteile - automatisches Andocken an Nachbarn, wenn man z.B. zwei Tasten platziert, damit sie nicht überlappen und dicht sitzen - wählbare ICONs, also eine eigene Grafik in einer Standardgröße, zum Beispiel der des Tasters, um selber designen zu können - Einen Schalter, der richtig einrastet, gfs in Form von zwei zu malenden Bitmaps - Slider wie bei einem Mischpult in ausreichender Größe - ein eigenes Hintergrundbild in Vollbildgrösse, das man laden kann - Umschalten auf Vollbild beim Aktivbetrieb, ohne irgendwelche Menüs - Drehknöpfe , die die Position mit einem Strich anzeigen - vom user platzierte Umschaltknöpfe im Bild, mit denen man Seiten wechseln kann, dafür keine Tabs mehr - eine einfache Textausgabe mit wählbarer Farbe aber transparentem Hintergrund Gebaut werden soll sowas: http://www.96khz.org/doc/vasynthesispolymorph.htm Für die Schalter und Taster würde es reichen, wenn man ein "EIN"-Bild hinterlegen kann, dass über die Bitmap im Hintergrund gelegt wird. Der Benutzer muss dann den Hintergrund mit "Aus"-Bild malen. Der weniger versierte Benutzer könnte dann einfach normale Geräte fotografieren und den gedrückten Knopf als Bild nehmen. Bei den slidern und Drehknöpfen wäre wichtig, das sie sofort bei Änderung des Wertes den neuen Senden, damit das Gerät reagieren kann. Die müssten eigentlich nur die Mausposition auswerten, die in dem Bereich des Elementes liegt und dann schauen, oder Knopf angefasst wurde. Bild einblenden ginge mit einem Offset des Bedienknopfes vor transparentem Hintergrund. Wäre in meinem Fall gfs. für den professionellen Einsatz und dürfte ein bissl was kosten.
Jürgen S. schrieb: > Was es vielleicht noch bräuchte, um damit effektiv arbeiten zu können: Dem möchte ich mich voll und ganz anschließen- und noch runde LED-Formen ergänzen. Wünschen wir Est Est Est viel Tatkraft für dieses Jahr! Danke für das jetzt schon überaus nützliche Programm!
Jürgen S. schrieb: > Bei mir ist es jetzt schon schon zweimal abgestürzt. Das ist natürlich schlecht... In der letzten Version habe ich ein paar Änderungen in der Kommunikation zwischen den Threads vorgenommen. Du hast die aktuelle Version V0.9 benutzt, oder? Kannst du helfen den Fehler noch etwas einzugrenzen? Welche Schnittstelle war verbunden, sind Daten angekommen, viele? Gab es zeitgleich Ausgaben, evtl. eine Benutzeraktion? Wie hat sich der Absturz gezeigt, gab es eine Fehlermeldung, oder ist es hängen geblieben? > Habe allerdings eine Spezial-CPU auf Win7. Auf Win7 programmier ich das Programm. Ob es was mit der CPU zu tun haben kann, keine Ahnung. > Was es vielleicht noch bräuchte, um damit effektiv arbeiten zu können: > - ein ab- und einschaltbares Raster zum Platzieren der Bauteile Wenn man Steuerung drückt, erfolgt ein Verschieben mit der Maus im 10-Pixel-Raster. Mit den Pfeiltasten werden die Bauteile/Instrumente ebenfalls im 10-Punkte-Raster bewegt. > - automatisches Andocken an Nachbarn, wenn man z.B. zwei Tasten > platziert, damit sie nicht überlappen und dicht sitzen Ja, wäre schön, ist mir aber zu aufwendig. Durch das Raster kann man auch viel erschlagen. Soll es eine schönere Anordnung werden, die nicht ins Raster passt, kann man auch im Eigenschafteneditor die Position editieren. > - wählbare ICONs, also eine eigene Grafik in einer Standardgröße, zum > Beispiel der des Tasters, um selber designen zu können > - Einen Schalter, der richtig einrastet, gfs in Form von zwei zu > malenden Bitmaps OK, das wäre eine neue Kategorie Bitmap-Elemente. Ich mach mir mal Gedanken, wie ich das umsetzen kann. > - Slider wie bei einem Mischpult in ausreichender Größe Das würde dann auch unter die Bitmapelemente fallen. Einen funktionalen Slider gibt es ja schon (Analoganzeige/-schieber in Ausgangskonfiguration). > - ein eigenes Hintergrundbild in Vollbildgrösse, das man laden kann Im Bearbeiten-Modus unter Hilfsmittel/Hintergrund kann man ein Hintergrundbild für jedes Blatt/Tab einstellen. > - Umschalten auf Vollbild beim Aktivbetrieb, ohne irgendwelche Menüs Es gibt die Kommandozeilenparameter -FullScreen und -FullWindow. Denkbar als neue Funktionalität wären auch Projekteinstellungen, dass das Projekt immer im Vollbildmodus startet. > - Drehknöpfe , die die Position mit einem Strich anzeigen Muss ich mir überlegen, Bedienung mit der Maus ist halt nicht so toll und recht anspruchsvoll zum Implementieren. > - vom user platzierte Umschaltknöpfe im Bild, mit denen man Seiten > wechseln kann, dafür keine Tabs mehr Vom µC aus kann man die Tabs mit der Funktion "sheet(n)" umschalten. Ich überlege mir auch noch ein Instrument Ausgangseingangsumleitung zu machen, dann könnte ein Tasterwert auf einen Eingang gelegt werden, der dann wiederum die Seite auswählt. Ist halt ein bisschen ein gefrickel dann. Das Verstecken der Tableiste wäre als Projekteinstellung denkbar. > - eine einfache Textausgabe mit wählbarer Farbe aber transparentem > Hintergrund Ich weiß :-) Gibt leider technische Probleme, das umzusetzen. D.h. ich hab bisher keine zufriedenstellende Lösung dafür gefunden. > Gebaut werden soll sowas: > http://www.96khz.org/doc/vasynthesispolymorph.htm Für eine solche Anwendung wären Bitmap-Elemente ja zwingend. Wäre sicher interessant. > Wäre in meinem Fall gfs. für den professionellen Einsatz und dürfte ein > bissl was kosten. Auftragsmäßig Funktionen einzubauen werde ich nicht machen, ist halt ein Hobbyprojekt. Wenn du das Programm kommerziell nutzen willst, können wir uns aber sicher einigen. Wenn meine Serverkosten gedeckt wären, wäre das auch nicht schlecht~ Udo schrieb: > Dem möchte ich mich voll und ganz anschließen- und noch runde LED-Formen > ergänzen. Runde LED wurden ja bereits gewünscht. Die Umsetzung, dass die LEDs nicht noch von einem viereck eingefasst sind, ist aber schon wieder schwieriger. > Wünschen wir Est Est Est viel Tatkraft für dieses Jahr! Danke > für das jetzt schon überaus nützliche Programm! Das freut mich!
Hallo Est Est Est, es wäre nicht schlecht beim Terminal einen ein-ausschaltbare Zeilenumbruch hinzufügen. Gruß rodnas
Ich habe den Absturz jetzt noch nicht reproduzieren können. Ja es war die 0.9. >> - Drehknöpfe , die die Position mit einem Strich anzeigen >Muss ich mir überlegen, Bedienung mit der Maus ist halt nicht so toll >und recht anspruchsvoll zum Implementieren. Ich denke, es würde auch reichen, einen symbolischen Drehknopf zu nehmen, der keine Markierung hat, aber eine Riffelung mit 24 Punkten, die dem typischen Raster entsprechen. Der Drehknopf kennt nur 3 optische Stellungen und läuft dann beim Drehen virtuell eins nach rechts oder links, was sich ganzzahlig wiederholt und trotzdem einen Eindruck des Fluss erzeugt - ähnlich wie bei LED-Ketten: Also Rechts : 100, 010, 001, ergibt 100100100, 010010010, 001001001, 100100100 ... Dann einfach eine Anzeige über den Elementen wie ich es bei meiner Console hatte: Das ist ein virtueller Drehknopf der endlos dreht, wobei links die Stellung in Prozent optisch, oben der resultierende Wert und rechts daneben das Multiplikationsergebnis angezeigt wird. So steckt das im FPGA - ist halt ein Resourcenfresser! Man bräuchte das parallel auf einem Desktop, weil einige eben doch wieder Patches und alles per PC speichern wollen.
:
Bearbeitet durch User
rodnas schrieb: > es wäre nicht schlecht beim Terminal einen ein-ausschaltbare > Zeilenumbruch hinzufügen. Hallo Rodnas, wo würdest du gerne umbrechen? Am Ende von Befehlen? Es gibt ja schon die Befehlsliste rechts vom Zeichenfenster. Umbrechen bei '\n' oder bei Steuerzeichen? Dann würden ggf. Befehle mittendrin umgebrochen. Das Terminal ist ja eigentlich nur für die Einrichtung der Schnittstellen gedacht, mit der hexadezimalen Anzeige (war eine Heiden-Arbeit~) wie ich meine schon recht komfortabel. Jürgen S. schrieb: > Ich habe den Absturz jetzt noch nicht reproduzieren können. Ja es war > die 0.9. Auch wenns nicht reproduzierbar ist, die Randbedingungen zu wissen, unter dennen der Absturz aufgetreten ist, könnte schon helfen. Instabilitäten haben natürlich erste Priorität. > Ich denke, es würde auch reichen, einen symbolischen Drehknopf zu > nehmen, der keine Markierung hat, aber eine Riffelung mit 24 Punkten, > die dem typischen Raster entsprechen. Der Drehknopf kennt nur 3 optische > Stellungen und läuft dann beim Drehen virtuell eins nach rechts oder > links, was sich ganzzahlig wiederholt und trotzdem einen Eindruck des > Fluss erzeugt - ähnlich wie bei LED-Ketten: > Also Rechts : 100, 010, 001, ergibt 100100100, 010010010, 001001001, > 100100100 ... > Dann einfach eine Anzeige über den Elementen wie ich es bei meiner > Console hatte: OK, ich verstehe was du meinst. Wäre natürlich möglich, aber ist jetzt sicher nicht meine Priorität. Wenns nur um die Funktionalität geht, kann man sich ja mit Plus- und Minustastern helfen. Die Kategorie Bitmap-Instrumente gefällt mir dagegen gut, damit kann man dann sehr viel individualisieren. Viele Grüße
Hallo Est Est Est, ich habe bis jetzt die HTTP Request immer noch nicht getestet... werde ich noch. Vorher möchte ich aber noch ein Oszilloskop realisieren. D.h. der µC nimmt eine Messung auf, löscht ein XY Diagramm und schickt dann zuerst Y und dann X (die gemessene µC Zeit). Dann soll es wieder auf einen Trigger warten. Mein Problem: ich finde den Befehl für das Löschen nirgends mehr in der Doku... bin mir aber sicher diesen gesehen zu haben. Du schreibst auch davon in der GUI beim XY Diagramm. Ich verwende noch V0.8 Kannst du mir bitte einen Hinweis so schnell wie möglich geben. Ich will heute noch weiterarbeiten. Danke. Ich kann immer wieder ein Lob an das gelungene und 100% effiziente Konzept aussprechen. Ich verwende das Programm im Unterricht für Laborübungen und die Schüler haben keine Probleme und können damit auch wirklich rasch umgehen. Anscheinend stürtzt das Programm bei den Schülern beim Speichern manchmal ab, aber das habe ich noch nicht weiter verfolgt. Ich hoffe, der Einsatz im Unterricht fällt unter NONCOMMERCIAL ;-) Lg, Klaus
Noch ein (kleines) Featurerequest: Kannst du bei den COM-Portnamen für Linux auch /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2 und /dev/ttyACM3 hinzufügen. Oder eine automatische Erkennung? Lg
Weinga U. schrieb: > Vorher möchte ich aber noch ein Oszilloskop realisieren. D.h. der µC > nimmt eine Messung auf, löscht ein XY Diagramm und schickt dann zuerst Y > und dann X (die gemessene µC Zeit). Dann soll es wieder auf einen > Trigger warten. Das hab ich auch schon gemacht. Hat mit V0.9 dann gut funktioniert. In V0.8 war noch ein Fehler im Pufferspeicher des XY-Diagramms, es gehen dann Daten verloren. Du solltest als gleich auf 0.9 umsteigen~ > Mein Problem: ich finde den Befehl für das Löschen nirgends mehr in der > Doku... bin mir aber sicher diesen gesehen zu haben. Du schreibst auch > davon in der GUI beim XY Diagramm. In der GUI wird der Befehl doch erklärt. Du musst den Steuerkanal belegen, z.B. mit #7, d.h. Eingänge auf Kanal 7 werden dann an den Steuerkanal geleitet. Mit der Zeichenkette 'clear' oder 'reset', also im Beispiel mit dem Befehl '#7SClear;' wird dann das XY-Diagramm zurückgesetzt. EDIT: Du musst im Eigenschafteneditor vom XY-Diagramm auf das Untermenü Steuerkanal und dort einen Kanal setzen. > Kannst du mir bitte einen Hinweis so schnell wie möglich geben. Ich will > heute noch weiterarbeiten. :-) > Ich verwende das Programm im Unterricht für Laborübungen und die Schüler > haben keine Probleme und können damit auch wirklich rasch umgehen. > Anscheinend stürtzt das Programm bei den Schülern beim Speichern > manchmal ab, aber das habe ich noch nicht weiter verfolgt. Ich hoffe, > der Einsatz im Unterricht fällt unter NONCOMMERCIAL ;-) Das freut mich! Für die Lehre darfst du es gerne verwenden. Abstürze sind natürlich übel, ich schau mal danach, ist halt immer die Nadel im Heuhaufen, besonders wenn es keine Eingrenzungen gibt...
:
Bearbeitet durch User
Danke für die Antwort. > EDIT: Du musst im Eigenschafteneditor vom XY-Diagramm auf das Untermenü > Steuerkanal und dort einen Kanal setzen. Ich wusste, irgendwo habe ich die Beschreibung schon einmal gesehen. Lg.
Est Est E. schrieb: > Unter > Beitrag "Re: Comvisu für Linux" > oder > http://comvisu.de Ja, und? gibt es das nun oder nicht? Ich verstehe die Antwort so: JA. Nur: Ich finde es wie Winegart auch nicht.
Heiko S. schrieb: > Ja, und? gibt es das nun oder nicht? > Ich verstehe die Antwort so: JA. Nur: Ich finde es wie Winegart auch > nicht. Genau, im "Linux-Thread" kann man die Zip mit der LinuxVersion runterladen. Auf meiner Homepage funktioniert der Download jetzt auch (wieder). Grüße~
Es gibt keinen Artikel über Comvisu, dadurch ist die Information schwer zu finden.
Das Stimmt schon, es scheinen ja gelegentlich sogar noch Downloads von der ersten Version gezogen zu werden... Ist natürlich jeder Willkommen, einen Artikel zu erstellen.
Habs grad auch probiert und den Artikel erstellt, Inhalte fehlen noch: https://www.mikrocontroller.net/articles/Comvisu Bei mir hats auch erst auf den zweiten Versuch geklappt, in der Artikelsuche muss man scheinbar auf den Button "Suche" statt auf "Ausführen" klicken, sonst kommt der Link mit "Artikel erstellen" nicht. Grüße~
Hallo Est Est Est, danke für dein flexibles und praktisches Programm. Ist es möglich Bildgröße und -position zu speichern? Oder auch eine Angabe als Startparameter? Dazu vielleicht die Speicherung/Angabe eines Start-Blattes. Und wie sieht es mit einer mqtt Schnittstelle aus? Gruß
R. Manfred B. schrieb: > Ist es möglich Bildgröße und -position zu speichern? Du meinst das Fenster? Das ist tatsächlich eine Sache, welche mich auch noch stört. Problem ist, dass es dazu einer Konfigurationsdatei bedarf. Da das Programm ja keine Installation benötigt müsste die Datei im gleichen Ordner sein. Wäre so aber wohl das Beste. > Dazu vielleicht die Speicherung/Angabe eines Start-Blattes. Als Kommandozeilenparameter wäre das denkbar. Ansonsten kannst du natürlich auch von der Gegenstelle aus mit der Funktion Sheet() das Blatt auswählen. > Und wie sieht es mit einer mqtt Schnittstelle aus? Das scheint recht interessant zu sein, kannst du ein bisschen ausführen, wie du dir das mit dem Protokoll im Detail vorstellst? Wie könnte publish/subscribe realisiert sein? D.h. wie können die Kanäle damit verwurstelt werden.
Hallo Est Est Est, > wie du dir das mit dem Protokoll im Detail vorstellst? Wie könnte > publish/subscribe realisiert sein? D.h. wie können die Kanäle damit > verwurstelt werden. vielleicht eine Tabelle in den Einstellungen, wo jeder sich selbst zusammen stellt, welcher Kanal auf welches Topic. Beim subscriben auch mit # und +, zur Not können ComVisu oder der Kontroller das anhand der Kanalnummer auseinander tüteln. Besser wohl ein Topic je Kanal, damit auch irgendwelche fertigen Apps da mitspielen können. Oder so. :-) Halt so flexibel wie machbar. Gruß
Hallo Manfred, > vielleicht eine Tabelle in den Einstellungen, wo jeder sich selbst > zusammen stellt, welcher Kanal auf welches Topic. Das war auch mein erster Gedanke, dass in den Schnittstelleneinstelungen dann Topics und Kanäle einander zugeordnet werden können. Oder ich bohr die Syntax auf, dass Kanäle nicht nur über Zahlen definiert werden können, sondern auch über Zeichenketten (mit vorangestellter '#'), dass man dann die Topics als Kanal ausschreiben kann. Aber ich kann nichts versprechen, hab bisher nichts mit MQTT gemacht. Viele Grüße
UDP wird bereits seit der Version 0.3 unterstützt. Einfach mal die aktuelle Version testen~
Hallo, das Programm ist zum Testen echt super. Aber eine Sache bekomme ich hier nicht so recht eingestellt. Ich nutzt für Eingaben/Ausgaben nur Int16/Int32. Beim einem Eingang kann man ja einfach #3/10 angeben und schon hat man eine Kommastelle aus dem Int. Aber wie kann ich als Eingabe zb. 12.45 -> 1245 machen und wenn man 12.456 eingibt immer noch 12.46 (idealerweise mit rundung) ausgeben. So wie ich das jezt sehe kann man nur Floats oder int ohne einstellbare Limits an eine Schnittstelle senden. MfG Sebastian
Gerechnet wird intern immer mit der vollen Genauigkeit. Die Anzeige kann man aber jeweils anpassen, und zwar gibt es in den Instrumenten, welche Zahlen numerisch anzeigen können, die Einstellung "Nachkommastellen" und "Feste Kommastellen". Überflüssige Nachkommastellen werden dann entsprechend abgeschnitten, eine Rundung wird allerdings nicht durchgeführt. Grüße
Es geht aber um die Ausgabe -> also das steurn/senden. Wenn man zb. aus 100.1% -> (int) 10010 senden will. Das lesen der Daten ist soweit kein Problem. Ledig die Charts sind etwas ungewöhnlich, da diese nicht durchlaufen und sich immer neu aufbauen wenn ein messwert am ende angekommen ist.
Sebastian__ schrieb: > Es geht aber um die Ausgabe -> also das steurn/senden. > Wenn man zb. aus 100.1% -> (int) 10010 senden will. Ah, jetzt hab ich verstanden, was du meinst. Da ist tatsächlich noch eine Lücke im Konzept. Bei der nächsten Version werde ich eine Funktion "round()" einbauen, mit der man dann die eingehenden Zahlen bereits runden kann. Z.B.: = round(#3)/10 Im Grunde wäre auch die Einstellmöglichkeit für die Nachkommastellen für alle Sendeinstrumente nicht schlecht, aber ich weiß nicht, ob sich das vom Aufwand her lohnt. > Ledig die Charts sind etwas ungewöhnlich, da diese nicht durchlaufen und > sich immer neu aufbauen wenn ein messwert am ende angekommen ist. Das hab ich absichtlich so gemacht, ich mags nicht so, wenn die Chartachsen durchlaufen. Bei stehenden Achsen kann man die Kurve m.E. während der Aufzeichnung besser beobachten. Die alten Werte werden ja auch nicht gelöscht, man kann das Diagramm einfach nach links (und rechts) verschieben. Ich halte die Charts für vergleichsweise komfortabel :-)
Hallo, ist es irgenwie möglich einen numerischen Eingang/zhal zu maskieren? Also zb. aus einen uint16_t das bit 0x80 maskieren und dann als 0/1 auszugeben, sozusagen als Status für LEDs. MfG Sebastian
Ich habe bei der 0.9 Version einen Bug gefunden. Wenn man die LED Leiste benutzt um sich einen Bit status anzeigen zu lassen, dann wir der status falsch ausgegeben. Wenn man ein uint32_t hat das 0xffff.ffff -> 4.294.967.295, dann macht die Anzeige daraus -1, und das Bit 31 wird nicht dargestellt.
Hallo Sebastian Sebastian__ schrieb: > ist es irgenwie möglich einen numerischen Eingang/zhal zu maskieren? Nein, bisher nicht. Baue ich zur nächsten Version mit ein. Entweder als Funktion oder Operator, das überleg ich mir noch. Also für bitweises und/oder/nicht/xor. Sebastian__ schrieb: > Ich habe bei der 0.9 Version einen Bug gefunden. Alles klar, das beheb ich auch. Die nächste Version wird allerdings noch etwas auf sich warten lassen. Grüße
Eine neue Version V0.95. Ich konnte mich noch nicht durchringen die 1 zu ziehen~ Folgende Neuerungen: - Neue Funktion 'round' zum Runden. - Neue Operatoren 'and', 'or', 'xor' für logische Verknüpfungen und 'bitand', 'bitor', 'bitxor' für bitweise Verknüpfungen. - Neue Funktionen 'not' zur logischen Negation und 'bitnot' zur bitweisen Negation einer Zahl. - Neue Instrumentenart 'Bitmap-Instrumente' mit den Instrumenten Taster, Schalter und Schieberegler. Den Bitmap-Instrumenten können Bilder zugeordnet werden und so die Darstellung beliebig verändert werden. Die Instrumentengröße ergibt sich aus den Bitmaps. Details sind in der Doku beschrieben. - In der Linux-Version werden nun auch die verfügbaren Schnittstellen aufgelistet. - Diverse Fehler ausgebessert. Downloads auch unter http://Comvisu.de
Hallo. gibt es eine Möglichkeit die Form des Inputs auch in eine Andere Form zu bringen? Wenn man z.B. nicht mit ASCII arbeitet sondern mit einem Hex Protokoll. Und wie sieht es mit gewerblicher Nutzung Aus. Dazu hab ich hier noch nichts gefunden.
Tobias K. schrieb: > Hallo. > gibt es eine Möglichkeit die Form des Inputs auch in eine Andere Form zu > bringen? Hallo Tobias, aus der Comvisu heraus gibt es keine Möglichkeit mit einem binären Protokoll. Der Grund ist, dass die Auswertung schwieriger ist, da ja Daten den gleichen Wert wie Steuerzeichen annehmen können. Es wäre also höchstens interessant, bestehende Protokolle zu übernehmen, z.B. von DSOs, aber da gibt es ja unzählige verschiedene... Was aber funktioniert, ist ein eigenes (einfaches) Programm als Protokollumsetzer zu schreiben, das die Schnittstelle einliest und dann für die Comvisu angepasst einem lokalen UDP-Socket sendet (z.B. IP 127.0.0.1). Auf dem gleichen Rechner natürlich. So können übrigens auch zwei Instanzen der Comvisu miteinander kommunizieren (siehe Anhang). > Und wie sieht es mit gewerblicher Nutzung Aus. Dazu hab ich hier noch > nichts gefunden. Da gab es bisher keine Anfragen. Du kannst mir eine Email an kontakt (ät) comvisu.de schicken. Viele Grüße
Welche Einsatzgebiete gäbe es, wo "zwei Instanzen kommunizieren"??
Hallo Est Est Est, tolles Programm! Ich habe mich heute mal drangesetzt und ein paar Instrumente plaziert, siehe Projektfile "test1.visu". Funktioniert im Prinzip alles, und das Konzept mit den Formeln bei den Kanälen ist super! Allerdings stürzt das Programm recht häufig ab. Es läuft hier auf Win7 Pro, mit COM1 nativer Schnittstelle (kein USB; älterer Dell-PC). Absturz z.B. nach Neustart, wenn Comvisu mehrmals seine Taktausgabe tätigt (6 mal), ohne daß ich je etwas zu Comvisu sende. Oder vorher schon, wenn ich eine "Numerische Ausgabe" tätige (hier "Out1"), zweimal gesendet, und Convisu stürzte ab. Aber nicht immer! Oder manchmal erst nach viel mehr "Sendungen". Mache ich etwas falsch, mag es an meinem PC liegen, oder könnte es sich um einen Programmfehler handeln? Viele Grüße und vielen Dank! Günter
H. S. schrieb: > Welche Einsatzgebiete gäbe es, wo "zwei Instanzen kommunizieren"?? Eine echter Einsatzzweck fällt mir auch nicht ein, aber man könnte damit z.B. zu Testzwecken eine Gegenstelle simulieren. Ist ja auch kein spezielles "Feature", sondern funktioniert halt einfach aufgrund des UDP-Protokolls. Günter R. schrieb: > tolles Programm! Danke :-) > Allerdings stürzt das Programm recht häufig ab. Es läuft hier auf Win7 > Pro, mit COM1 nativer Schnittstelle (kein USB; älterer Dell-PC). Hm, schlecht. > Mache ich etwas falsch, mag es an meinem PC liegen, oder könnte es sich > um einen Programmfehler handeln? Falsch machen kann man nichts. D.h. es muss sich um einen Programmfehler handeln. Wenn ich dich richtig verstanden habe, sind die Absturz genau dann passiert, wenn gerade gesendet wurde? Wie stürzt das Programm ab, gibt es eine Fehlermeldung, schließt es sich selbst, oder friert es ein? Bei der letzten Version habe ich etwas in der Schnittstellenverarbeitung geändert, es kann gut sein, dass dort was im Argen liegt. Ich schaus mir auf jeden Fall an und meld mich wieder. Bei meinen Tests ist nichts passiert. Viele Grüße
Es friert ein (Windows: "Keine Rückmeldung"). Passiert bei fast allen Operationen, daher könnte es gut etwas mit der Schnittstellensteuerung zu tun haben. Ganz klasse finde ich, daß das Programm nicht installiert werden muß, sondern quasi "out of the box" lauffähig ist. Anfangs hat mich irritiert, daß beim Umschalten auf "Bearbeiten" und zurück auf "Ausführen" immer wieder erst manuell verbunden werden muß. Hast du mal darüber nachgedacht, den Verbindungsstatus zu speichern und beim "Ausführen" automatisch wieder zu verbinden, wenn vorher hier mal verbunden war? Bei "Konsole", "Terminal" und "Schnittstelle" bleibts ja verbunden, nur "Bearbeiten" trennt die Verbindung (das ist ja okay, muß auch wohl so sein). Ansonsten: super Features; auch die Möglichkeit, manuell Testwerte einfach einzugeben, oder schnell mal etwas zum uC zu senden (aber wie gesagt: nach dem zweiten oder dritten Mal oftmals Absturz). Vielleicht noch eine Anregung: intern könnte ein "Änderungsstatus" gespeichert werden, d.h. ein Flag, das immer dann gesetzt wird, wenn am Projekt etwas geändert wird, entsprechend, wie wenn bei z.B. MS-Word etwas getippt wird. Beendet man dann das Programm, sollte eine Abfrage kommen, ob das Projekt gespeichert werden soll (wie bei anderen Windows-Programmen). Und wurde jemals gespeichert, sodaß oben der Projektname steht, so könnte man ein Sternchen einblenden, wenn das Projekt erweitert bzw. geändert wird, und dann käme wieder diese Sicherheitsabfrage beim Beenden, wenn man nicht vorher schon auf "Save" geklickt hat (und dabei verschwände das Sternchen).
Hallo Günther, auf meinem Rechner kann ich das Einfrieren nicht nachvollziehen. Hab jetzt dein Projekt eine halbe Stunde laufen lassen, auch mit sehr kleinen Ausgabeintervallen von 0,1s (Taktausgabe). Allerdings habe ich keinen echten COM-Port zur Verfügung, sondern arbeite mit einem USB-Seriell-Wandler. Vielleicht ist da das Timing unterschiedlich. Im Programm gibt noch eine "Baustelle" auf Schnittstellenebene, mit der es zu tun haben kann. Das gehe ich an, wird aber etwas dauern. Hast du die gleichen Probleme bei der Version V0.9? Bezüglich automatisches Verbinden, ich sehe da eigentlich keine Notwendigkeit. Es ist ja nur ein zusätzlicher Klick. Bei automatischem Verbinden würde man ja den Formelstatus nicht angezeigt bekommen. Das eine Änderung der Einstellungen sichtbar ist, wäre schon gut, ist halt alles ein Aufwand, die Prioritäten liegen da bei mir noch woanders (Insbesondere wenn Abstürze vermeldet werden).
Hallo Est Est Est, habe eben die Version 0.90 getestet. Sie friert auch ein, erscheint aber dennoch viel stabiler, d.h. das Einfrieren erfolgt nach viel häufigerem Senden von Comvisu (z.B. kann ich bei 0.90 20 - 30 mal auf "Ausgang #25STest;" klicken, bis es einfriert, bei 0.95 häufig schon nach dem ersten oder zweiten Mal). Wenn nur mein uC sendet, Comvisu aber nicht, stürzt bei beiden Versionen nichts ab. Habe jetzt aber erst mal nur die "Numerische Anzeige" als Instrument definiert.
:
Bearbeitet durch User
Hallo Günter, habe deine Antwort gar nicht gesehen. In der Zwischenzeit habe ich eine Anpassung im Bereich der Schnittstelle gemacht. Ich schicke dir eine Version per PM*. Kannst du die bitte mal testen, diese läuft hoffentlich stabil. Was zwischen V0.9 und V0.95 auch unterschiedlich ist, ist die interne Verarbeitung der Sendeanimation (Grüner/gelber/roter Balken der anzeigt, dass gesendet wurde). Beim Instrument Taktausgabe ist die Sendeanimation deaktivierbar. Gibt es im deaktivierten Fall ein Unterschied in der Stabilität? Viele Grüße *Edit: PM-Funktionalität funktioniert leider nicht. Testversion unter diesem Link: comvisu.de/download/ComvisuV096.zip
:
Bearbeitet durch User
Hallo Est Est Est, danke für den Link. Bin am Testen. Ich mache es sehr ausführlich und probiere auch auf dem Notebook (auch Win 7, aber mit weniger installierten Programmen, daher stabiler, außerdem nicht am Internet angeschlossen ...). Ich melde mich morgen dazu, oder spätestens übermorgen (Di). Viele Grüße Günter P.S. Warum funktionierte PM nicht? Liegts an meinem Account?
Hallo Günter, es eilt nicht, wanns dir halt reinpasst~ Natürlich sollte das Programm auch auf beanspruchteren Installationen stabil laufen... Ich hoffe, dass es das durch die (kleine) Änderung auch tut. Warum die PM nicht funktioniert hat, weiß ich auch nicht, ich vermute es lag an irgend welchen Skripten, die ich nicht aktiviert hatte (NoScript). Nach der 5ten Iteration, dieses und jenes Skript erlauben, hab ichs dann aufgegeben. Viele Grüße
Hallo Est Est Est, ich habe eben alle drei Versionen 0.90, 0.95 und 0.96 nochmals getestet (der Gegenpartner war HTerm 0.8.1 von Tobias Hammer auf einem zweiten PC - auch ein super Programm!). Die Test-Instrumentierung ist: Numerische Anzeige auf #1, Taktausgabe auf #2, sonst nichts. D.h. ich beobachte, ob meine gesendeten Daten ankommen, und ob die Taktausgabe wie gewünscht alle 2 Sekunden einen Wert sendet. Folgende Erkenntnis nun auf dem Notebook (Dell, Win7, jetzt mit USB-COM1, FTDI 232): Alle Programme stürzen nicht wirklich ab (das erschien mir vorgestern nur so). Aber: V. 0.90 sendet und empfängt wie es soll, und reagiert auf Mausklicks. V. 095 und 0.96 (kein merklicher Unterschied): Taktausgabe nur nach Datenempfang; Mausklicks werden auch erst ausgewertet, wenn Daten empfangen werden. D.h. beide Versionen senden höchstens einmal, frieren dann ein und "warten", bis von außen Daten kommen. HTerm hat ja die schöne Funktion "Autosend"; wenn man damit ständig Daten zu Comvisu senden läßt, scheint das Programm korrekt zu funktionieren, aber sobald man das ständige Senden durch HTerm anhält, friert Comvisu ein (0.95 und 0.96). Dann habe ich nochmals auf dem Internet-Desktop-PC (wie vorgestern getestet), mit der dort vorhandenen nativen COM1 (kein USB): Das Verhalten (bei 0.90 und bei 0.96) ist hier völlig anders. Mit Sendeanimation sendet Convisu auch ohne Datenempfang mehrmals, z.B. 20 oder 30 mal, friert dann ein. Sende ich dann manuell Daten zu Convisu, so dauert es bis zu 10 Sekunden, bis Comvisu regiert, aber dann geht es erstmal wieder weiter, bis es nach mehreren Taktausgaben wieder einschläft. Ohne Sendeanimation ist es ähnlich; allerdings fiel mir eben auf, daß 0.90 nach einigem "Schlafen" auch von selbst wieder mal aufwacht und wieder eine Weile sendet, ohne eigenen Datenempfang. Gibt halt viele Kombinationsmöglichkeiten. Welchen Einfluß Nativ-COM1 und USB-COM hat, kann ich nicht sagen. Ob die Unterschiede daran liegen, oder an unterschiedlichen PC-Konfigurationen (aber immer Win7!)? Viele Grüße Günter
Hallo Günter, das ist schon ein sehr merkwürdiges Verhalten, welches du beschreibst. Auf meinem Rechner kann ich das nicht nachvollziehen. Mein Aufbau: System ebenfalls Win7, USB-Seriell-Adapter (FTDI, auch CH340), daran ein Atmega32, welcher die empfangenen Daten auf einem Display anzeigt. Das geschieht jeweils 'sofort', ohne dass ein zweites Senden notwendig wäre. Das funktioniert zyklisch (Taktausgabe) ohne irgendwann zu unterbrechen (Läuft jetzt seit einer halben Stunde und jede halbe Sekunde trifft ein neuer Wert ein). Und das auch bei nur ausgehenden Werten. Version 0.96. Könnte es auch sein, dass das Problem doch außerhalb der Comvisu liegt? Günter R. schrieb: > Alle Programme stürzen nicht wirklich ab > [...] > frieren dann ein und "warten", bis von außen Daten kommen. > [...] > Sende ich dann manuell Daten zu Convisu, > so dauert es bis zu 10 Sekunden, bis Comvisu reagiert, aber dann geht es > erstmal wieder weiter, bis es nach mehreren Taktausgaben wieder > einschläft. Kannst du nochmals genau beschreiben, wie die Anzeige aussieht? Kommt, wenn die Comvisu wie du sagst einschläft, die Fensterüberschrift "Keine Rückmeldung"? Bewegt sich im Fenster noch etwas (es gibt oben rechts über dem Menü im "Verbunden"-Kästchen ja ein schwarz-weiß blinkendes Feld, welches anzeigt, dass die Anzeige "lebt"). Wenn du sagst die Comvisu schläft, nehme ich an, dass das Feld stehen bleibt? Viele Grüße Est Est Est
Kann es sein, dass da der 32/64 Bit Zugriff auf die Schnittstelle nicht korrekt gelöst ist und jeweils freigegeben wird? Da scheinen irgendwie manchmal 2 Prozesse auf einander zu warten, jedenfalls hängt sich das bei mir auch oft auf.
Die Schnittstelle sprech ich über eine Bibliothek (Synaser) an, ein 32/64bit-Problem kann ich mir kaum vorstellen. Es sind aber mehrere Threads involviert (MainThread, Sendethread und je Schnittstelle ein Empfangsthread), es kann gut sein, das dort das Problem liegt. Kannst du noch genauer sagen, was im Detail passiert? Bleibt das Programm nur beim Senden hängen, oder unbhängig davon? Läuft es bei dir sporadisch auch wieder weiter oder bleibt es entgültig hängen? In welcher/welchen Versionen tritt das bei dir auf? Nachtrag: Treten die Probleme genauso bei deaktiviertem Terminal auf?
:
Bearbeitet durch User
Est Est E. schrieb: > Kannst du nochmals genau beschreiben, wie die Anzeige aussieht? Kommt, > wenn die Comvisu wie du sagst einschläft, die Fensterüberschrift "Keine > Rückmeldung"? Bewegt sich im Fenster noch etwas (es gibt oben rechts > über dem Menü im "Verbunden"-Kästchen ja ein schwarz-weiß blinkendes > Feld, welches anzeigt, dass die Anzeige "lebt"). Wenn du sagst die > Comvisu schläft, nehme ich an, dass das Feld stehen bleibt? Bei Version 0.95: Wenn das Programm "einschläft", hört das schwarz/weiße Feld auf zu blinken, aber es kommt zunächst noch nicht die Meldung "Keine Rückmeldung" oben in der Programmüberschrift; die kommt aber dann, wenn ich mit der Maus irgendetwas klicke, z.B. auf "Werte löschen" oder etwas anderes. Dann kommt diese Meldung, und die Sanduhr bleibt an. Wenn ich dann aber Daten an Comvisu sende, geht es weiter, das Programm "wacht" wieder auf, und die Meldung "Keine Rückmeldung" verschwindet, bis zum nächsten Mal. Das Programm stürzt also nicht dauerhaft total ab, aber für die Anwendung wirkt es so. Bei Version 0.96 ist es genauso. Beides wieder mit dem USB-Serial-Kabel (FTDI) getestet.
Alles klar, dann weiß ich zumindest wo ich suchen muss. Vermutlich blockiert der Empfangsthread das Senden, welches der Hauptthread durchführt, und damit den Hauptthread selbst. Ich melde mich wieder.
:
Bearbeitet durch User
In V0.95 und 0.96 war ein Schnitzer drin, und zwar für eine vorgesehene Änderung ein (noch) leerer Thread, der die CPU auslastet. Bei Maschinen mit einem Kern führt das wohl zur Verstopfung. Eine neue Testversion unter dem untenstehenden Link. Günter, kannst du diese bitte testen. Sie beinhaltet die Verbesserung zwischen V0.95 und V0.96 ohne den Schnitzer. comvisu.de/download/ComvisuV097.zip Viele Grüße Est Est Est
Hallo Est Est Est, sieht gut aus. Kein Hänger nach über einer halben Stunde. Ich denke mal: Fehler beseitigt. Jetzt werde ich weitere Komponenten testen. Herzlichen Dank! Viele Grüße Günter
Hallo Günter, freut mich, dass es jetzt geht. Hast du es auch unter der 'echten' seriellen Schnittstelle getestet, oder nur an der USB-Seriellen? Es gibt noch ein paar Stellen im Programm mit dem "alten" Code, und zwar im Terminal, und in der UDP-Schnittstelle. Das überarbeite ich auch bis zur nächsten Version. Viele Grüße
Ich habs jetzt erstmal nur mit der echten Schnittstelle getestet, nicht mit dem USB-FTDI-Teil. Wäre das wichtig? Dann mach ich's noch.
Nein, das passt dann. Mit der echten seriellen Schnittstelle hat sich das Problem ja zuerst gezeigt. Die USB-Serielle scheint etwas robuster zu sein, was das Timing angeht.
Neue Version V1.0 mit folgenden Neuerungen: - Schnittstellen sind deaktivierbar. Nicht benötigte Schnittstellen können nun deaktiviert werden, nur aktivierte Schnittstellen werden verbunden. - Instrumente sind deaktivierbar. Deaktivierte Instrumente sind bei verbundener Schnittstelle ausgeblendet und es findet keine Datenverabeitung darüber statt. - Meldungsanzeige im Ausführen-Menüband. Verlorene Pakete und ein Schnittstellenabbruch wöhrend dem Betrieb wird nun dem Benutzer signalisiert. Pakete können bei internem Pufferüberlauf verloren gehen, wenn Daten mit zu hoher Rate verarbeitet werden müssen. - Änderung im Verbindungsverhalten: Sind nicht alle eingerichteten Schnittstellen verfühgbar, so werden die übrigen trotzdem verbunden und die Meldung "Verbindungsabbruch" ausgegeben. Geht eine Schnittstelle während dem Betrieb verloren, so laufen die übrigen weiter. - Globale Einstellungen: Dezimaltrenner beim Senden, Start im Ausführen-Modus, Start mit letztem Projekt - Neue Funktionen int8, int16, int32, uint8, uint16, uint32: Mit diesen Funktionen werden eingehende Zahlen auf den angegebenen Datentyp gemappt. Aus uInt8(65535) wird bspw. 255. Damit können u.a. Sensordaten mit negativen Werten dargestellt werden, auch wenn im Mikrocontroller alle Werte vorzeichenlos verarbeitet werden. - Zahlen in Formeln können nun auch binär (0b) und hexadezimal (0x) angegeben werden - Im Terminal werden nun auch gesendete Befehle aufgeführt - Diverse kleine Änderungen Wie immer gibts auch eine Linuxversion, siehe "Nachbarthread". Downloads auch unter Comvisu.de Viele Grüße!
Hallo Est Est Est, hört sich nach lauter sinnvollen Änderungen und Erweiterungen an. Ich freue mich das im Unterricht mit meinen Schülern ausprobieren zu können. Danke nochmal dafür. Auch für die Linux Version :-) Wegen Linux: Der Tongenerator funktioniert leider nicht unter Linux Ubuntu 16.04 mit Gnome. Lg
Hallo Weinga Unity, der Tongenerator funktioniert unter Linux generell nicht. Ich hab einfach keine elegante Lösung gefunden, das unter Linux umzusetzen. Das ist aber die einzige Funktion, die unter Linux fehlt. Ansonsten viel Spaß mit dem Programm~ Grüße
Hallo Est Est Est, ich wollte dir nur die Rückmeldung geben. Die Schüler haben eh fast alle Windows, da gehts. Nur beim Lehrer halt nicht :-)
Hallo Est Est Est, wie immer, super Leistung. Ich habe jedoch einen Darstellungsfehler wie im Bild ersichtlich. Die "x"-s sind nicht vollständig sichtbar. Die übliche Verschiebungsoption ist nicht vorhanden. Was könnte ich machen? Gruß rodnas
Hallo rodnas, das ist ein Fehler in der Darstellungsbreite, ich korrigier das. Bis es die neue Version gibt, kannst du per Pfeiltasten zwischen den Feldern springen. Also sichtbaren Bereich anklicken und rechte Pfeiltaste drücken. Ist nicht schön, aber wie gesagt ich besser das aus. Viele Grüße
Hallo Est Est Est, ich habe ein Problem, wenn ich floatAvg Berechnung durchführe, zB. nach einem Reset, in der Nummerische Anzeige wird recht flott berechnet, aber parallel dazu im Zeitdiagramm wird der tatsächliche Wert wesentlich langsamer, verspätet angezeigt. Gruß rodnas
Hallo Rodnas, die Funktion FloatAvg verwendet ja die Werte aus mehreren hintereinanderfolgenden Berechnungen. Bei der Digitalanzeige wird immer dann eine neue Berechnung durchgeführt, wenn ein neuer Befehl eingeht. Beim Zeitdiagramm wird die Berechnung in festen Zeitintervallen ausgelöst. D.h. dass FloatAvg bei dir bei der numerischen Anzeige schneller konvergiert, kann eigentlich nur sein, wenn öfters Befehle eingehen, wie im Diagramm die Abtastrate ist. Vielleicht habe ich dich aber auch falsch verstanden und es geht um eine andere Verzögerung? Viele Grüße
Hallo Est Est Est, Soweit ist der Vorgang mir klar, auffallend war nur nach einem Reset, bzw. nach einer Umschaltung auf "Bearbeiten". So fängt die Berechnung mit 0 an. Nach Verbindungsunterbrechung wird aber mit dem letzten gespeicherten Wert fortgeführt. Ich dachte das "Bearbeiten" ähnlich behandelt wird wie eine Verbindungsunterbrechung. Gruß rodnas
Hallo Rodnas, habs mir nochmal angeschaut. Es ist schon so wie du sagst, die speicherwertigen Funktionen werden alle resetet wenn man in die Ausführen-, Konsolen- oder Terminaloberfläche wechselt (Außer die Schnittstellen sind schon in Betrieb). Das ist tatsächlich kein gewünschtes Verhalten. Den Wert beim Neuverbinden jeweils zurückzusetzen möchte ich eigentlich auch nicht. Ich überleg mir was... Viele Grüße
Hallo Est Est Est, währe es möglich, wenn der Cursor im Diagramm einen Datenpunkt berührt, dessen Wert und Zeitstempel einzublenden? Gruß rodnas
Hat mal jemand probiert, dort I2C-Sensoren dran zu bekommen? Wäre es möglich, damit die I2C-Sequenzen zum Steuern und Konfigurieren der Sensoren zu managen?
Testweise gibt es eine Version für den Raspberry Pi, siehe Linux-Thread: Beitrag "Re: Comvisu für Linux" Die Resonanz ist bislang gering. Wer es testet: Gerne eine Rückmeldung geben, ich habe es bisher nur in einer Emulation laufen lassen und entsprechend kein Schnittstellen dran gehabt.
Hallo Est Est Est, Comvisu für RaspberryPi wäre für mich DER Grund, einen RP zu kaufen. Bin sehr interessiert, allerdings noch 2 Wochen beruflich unterwegs, bevor ich handeln kann. Ich melde mich, sobald ich einen RP habe und Comvisu testen kann. Dann wirst du jede Menge Response bekommen. Günter
Für mich wäre das auch interessant. Das Programm kann man sich dann auch ruhig ein paar Euros kosten lassen!
Einfach mal ausprobieren, das Programm habe ich wie gesagt im Linux-Thread eingestellt: Beitrag "Re: Comvisu für Linux" Es kann sogar sein, dass es auch auf anderen Arm-Linux-Boards läuft, wie dem Beagle Bone. Das müsste auch getestet werden. Compiliert habe ich für ARMv6 und nicht speziell für den Raspberry, könnte aber trotzdem letztlich an Bibliotheken hängen. Für die private Nutzung verlange ich nichts, freue mich aber über eventuelle Spenden.
In unserem Fall wäre es vermutlich durchaus eine kommerzielle Nutzung.
Dann schreib mich mal an, wir werden uns sicher auf etwas einigen. webmaster (ät) comvisu.de Viele Grüße
Hallo, ich habe mit der aktuellsten Version 1.00 ein ähnliches Problem wie weiter oben Günter R. ( Beitrag "Re: Serielle Visualisierung mit Comvisu" ). Windows 7, Prolific USB-to-Serialwandler mit PL2303 Chip. So lange ComVisu Nachrichten empfängt läuft alles einwandfrei. Wird auf dem COM-Port aber nichts gesendet, so dauert es einige Sekunden und das Programm friert ein. Provozieren kann man das Verhalten auch, wenn nichts gesendet wird und man auf "Trennen" klickt. Dann ist das Programm wirklich inaktiv und reagiert nicht auf Klicks. Einziger Weg zum beenden ist der Task Manager. Probleme gibt es auch, wenn z.B. der Wandler entfernt und wieder angesteckt wird. Nach dem entfernen lief das Programm weiter mit den letzten Werten. Nach dem Wiedereinstecken gab es einen Absturz. Grüße Sebastian
Hallo Sebastian, ich komme gerade zeitlich nicht dazu, danach zu schauen. Im Februar gehts aber weiter. Wenn ich dich richtig verstanden habe, waren die Fehler nicht sporadisch, sondern sind immer aufgetreten? Viele Grüße
Hallo Est Est Est, ich habe jetzt meine Heizungsvisualisierung auf Comvisu erweitert. Alles funktioniert sehr gut, allerdings habe ich große Probleme beim Anwenden eines Zeitdiagramms. Da ist z.B. die Zeitskala dimensionslos mit einem Min- und einem Max-Wert ausgestattet. Und man kann "Datum und Uhrzeit" ankreuzen. Den Effekt davon habe ich aber noch nicht gesehen. Auch den Zusammenhang von Abtastperiode zu Zeitfortschritt auf der Zeitskala und die Anzahl der Datenpunkte im Puffer erkenne ich nicht. Nach meinem Verständnis wäre es schön, wenn man eine Ringpuffergröße definieren könnte, sodaß bei vollständiger Füllung der Puffer hinten gelöscht und vorn gefüllt wird, wie bei einem Endlos-Tonband. Dann gäbe es nie Speicherüberlauf. Und man könnte eine definierte Zeit "zurückblättern", vom aktuellen Zeitpunkt beginnend. Gibt es eine nähere Beschreibung, wie man es hinbekommt, daß auf einen ganzflächigen Bildschirm z.B. 2 Tage dargestellt werden, bei einem Sampling von z.B. 1/Min.? Ich weiß, Du hast z.Zt. keine Zeit, daran zu arbeiten oder groß Fragen zu beantworten. Macht ja nichts, eilt überhaupt nicht. Vielleicht kannst Du bei Gelegenheit dieses Thema aufgreifen. Herzlichen Dank schon mal. Günter
Hallo Günter, zum Zeitdiagramm: Im Puffer werden maximal 100'000 Werte aufgenommen, nach jeweiligem Überschreiten werden die ersten 5000 Werte gelöscht. Der Puffer fungiert also bereits als Art Ringspeicher. Die Grenzen sind fest im Programm hinterlegt. Der einstellbare Min- und Max-Wert für die X-Achse ist in Sekunden, also nicht dimensionslos. Möchte man 2 Tage darstellen, so würde man als Min-Grenze "0" und als Max-Grenze 2*24*60*60 = "172800" einstellen. Für ein Sampling pro Minute stellt man bei der Abtastperiode (in Sekunden) "60" ein. Wenn du "Datum und Uhrzeit" ankreuzt, ändert sich die Darstellung auf die absolute Zeit, es werden jeweils nur 2 Zeitbereiche (z.B. Stunden und Minuten) angezeigt, je nach Zoomstatus. Bei den Vorgabeeinstellungen sind ja 20 Sekunden eingestellt, entsprechend wird am linken Graphenrand die aktuelle Uhzeit in Minuten und Sekunden stehen (mm.ss). Die Formate lassen sich eindeutig unterscheiden: DD.MM. (Tag/Monat) DD. hh:mm (Tag/Stunde/Minute) hh:mm (Stunde/Minute) mm.ss (Minute/Sekunde) ss.nnn (Sekunden/Millisekunden) Was nicht ohne weiteres geht, ist die Anzeige jeweils tagweise, d.h. um 0 Uhr nachts, umzubrechen. Der Anfang bezieht sich immer auf den aktuellen Start. Man kann zwar bei der Min-Grenze einen z.B. negativen Wert eintragen, um den Graphenanfang auf Mitternacht zu legen, der wäre dann aber davon abhängig, wann man die Aufzeichnung startet. Also wahrscheinlich nicht so praktikabel. Ich hoffe es ist jetzt etwas klarer. Wahrscheinlich sollte ich das noch besser dokumentieren :) Viele Grüße
Hallo Est Est Est, gute Beschreibung, danke! So probiere ich es. Günter
Hallo Est Est Est, ich habe jetzt meine Heizungsvisualisierung fertig, funktioniert super, vielen Dank! Das Zeitdiagramm (nachdem ich es jetzt kapiert habe) geht auch sehr gut. Ein paar kleine Verbesserungen möchte ich anregen (ist hier jetzt nur Kosmetik, und da fällt mir auch noch mehr ein): - Wenn ein Projektfile geladen ist und somit oben dessen Name angezeigt wird, wäre es schön, wenn - wie bei anderen Windows-Programmen - vor dem Dateinamen bzw. Pfad ein "*" angezeigt wird, sobald am Projekt irgendetwas geändert wird, als Indikator, daß man "Speichern" sollte; und wenn das Progamm beendet wird, sollte ein Warn-Fenster darauf hinweisen, sonst geht evt. unbeabsichtigt eine Projektfile-Änderung verloren, wenn man nicht dran denkt. So machen es je die Office-Programme, z.B. Word. Alternativ zum Sternchen: den "Speichern"-Button abgrauen und erst dann high-lighten, wenn sich am Projekt etwas ändert (sieht man auch an manchen Windows-Programmen, finde ich auch nicht schlecht). - Es gibt ja die Command-Line-Optionen "-FullScreen" und "-FullWindow"; für mich wäre eine dritte fast noch lieber: "-ScreenMaximize" oder so, mit der Wirkung, daß das Programm den ganzen Bildschirm einnimmt, aber die Menüzeile noch stehen bleibt, also so, wie wenn man oben rechts auf "Maximieren" klickt. Ansonsten ein super Programm, freue mich auf die nächste Version (auch für den Raspi). Günter
Gleich noch eine Anregung für das Zeitdiagramm: Wenn der Bildschirm vollgeschrieben ist, springt ja die gesamte Bildschirmdarstellung nach links, sodaß der Bildschirm zunächst wieder quasi leer ist und erneut vollgeschrieben wird. Hier wäre es schön, wenn man im Einstellmenü z.B. auswählen könnte, daß die Darstellung nur um eine halbe Bildschirmbreite nach links springt, oder ein Drittel, sodaß man permanent einiges von den letzten Daten sieht. Günter
Hallo Günter, zu Punkt eins, dass eine Veränderung angezeigt wird, das Umzusetzen wäre recht aufwendig. Ich denke im Vergleich zum Nutzen lohnt in diesem Fall der Aufwand nicht. Zum 2ten: Wie genau stellst du dir "-ScreenMaximize" vor? Tatsächlich nur das maximierte Fenster komplett mit Rahmen? In diesem Fall kannst du in der Verknüpfung, mit welcher du ein Programm aufrufst, angeben, ob das Programm maximiert, minimiert etc. gestartet werden soll (zumindest unter Windows weiß ich dass das geht, in den Eigenschaften der Verknüpfung). Ist aber auch kein Problem das noch einzubauen. Zum 3ten: Das notier ich mir, ist eine gute Idee! Viele Grüße~
Est Est E. schrieb: > Zum 2ten: Wie genau stellst du dir "-ScreenMaximize" vor? Tatsächlich > nur das maximierte Fenster komplett mit Rahmen? In diesem Fall kannst du > in der Verknüpfung, mit welcher du ein Programm aufrufst, angeben, ob > das Programm maximiert, minimiert etc. gestartet werden soll (zumindest > unter Windows weiß ich dass das geht, in den Eigenschaften der > Verknüpfung). Ist aber auch kein Problem das noch einzubauen. Hallo Est Est Est, das habe ich mit den Eigenschaften des Desktop-Icons mal probiert; aber egal was ich einstelle (Normales Fenster, Minimiert, Maximiert), kommt immer die verkleinerte Darstellung, da ändert sich nichts (Win 7 Prof). Ich vergrößere das Programm dann immer gleich (siehe Screenshot), wäre schön, wenn es gleich so starten könnte bei Klick auf das Icon; aber das ist Peanuts, nicht wirklich wichtig. Eher interessant wäre die Warnung beim Beenden des Programms, wenn das Projektfile geändert wurde (muß ja nicht das Sternchen sein beim Dateinamen oder das abgegraute Diskettensymbol). In meinen Programmen habe ich ein Change-Flag, das wird gesetzt, wenn an einem Projektfile etwas geändert wird, und beim Programm-Ende frage ich das ab und bringe das Meldungsfenster, sodaß gespeichert werden kann (aber nicht muß). Kannst ja mal prüfen, ob das evt. ohne großen Aufwand einzubauen wäre. Danke. Günter
Hallo Günter, das Change-Flag ist klar, gibt halt soviele Stellen, wo es gesetzt werden müsste... Aber ich überlegs mir. Das Programm über die Verknüpfung maximiert zu starten geht bei mir auch nicht, habs grad probiert. Und dann gleich den Parameter "-WindowMaximized" in die Comvisu eingebaut:) Grüße~
Super. Vielen Dank schon mal. Bin gespannt auf die nächste Version. Aber: kein Streß! Laß Dir Zeit. Günter
Hallo Est Est Est, ich befasse mich ja intensiv mit CV, speziell mit dem Zeitdiagramm. Da kann man ja mit der rechten Maustaste gedrückt haltend das Bild verschieben, also sozusagen zurückscrollen. Das geht gut. Was passiert, wenn man das Bild dann so stehen läßt, daß also die aktuellen neuen Daten ein Stück weit rechts aus dem Bildschirm ragen? Springt die Anzeige dann irgendwann wieder nach vorn oder bleibt sie so stehen? Ist dieses Verhalten "wohldefiniert" oder ein bißchen zufallsabhängig? Ich habe den Eindruck, daß das bildweise Weiterspringen (über das wir kürzlich schon diskutiert hatten) nicht mehr so klar weiterläuft, wenn man mal zurückgescrollt hat oder wenn man die "Lupe" benutzt hat (mit der linken Maustaste Rechteck über interessierenden Bereich aufziehen - funktioniert sehr gut!). Kannst Du, wenn Du Zeit hast, auch darauf mal Dein Augenmerk richten? Danke. Günter
Hallo Günter, während den Verschiebe- und Zoomaktionen wird der automatische Vorschub deaktiviert, damit man 'in Ruhe' schauen kann. Durch Klick mit der linken Maustaste in die Diagrammfläche verlässt man den Zoom und der Vorschub wird auch wieder gestartet. Das Bild sollte dann an die aktuelle Stelle springen, also auch wenn man mehrere Vorschübe verpasst hatte. So ist es zumindest gedacht. Wenn was nicht funktioniert geb Bescheid, dann schau ich danach.
Hallo Est Est Est, danke für die Info. Habs gerade nochmal probiert. Es ist so wie Du schreibst, und so ist es auch ideal. Allerdings hatte ich zuvor kurz die Situation, daß ich mit Rechtshalten verschoben habe und dann mit Linksklick zurück zur Normalstellung wollte und der Bildschirm dann ziemlich weit zurück nach links sprang (hier auf den 28.03.) und dort blieb, auch bei mehreren Linksklicks; dies bei zwei Zeitdiagrammnen auf zwei Blättern. Ein weiteres Zeitdiagramm auf einem dritten Blatt hatte ich anfangs nicht verschoben (noch nie), das reagierte normal, und als ich dann wieder zu den anderen beiden Blättern zurück ging, reagierten die auch wieder normal, wie sie sollen. Aber jetzt "tuts wieder wie es soll". Alles in allem also kein wirkliches Problem. Daten gingen keine verloren. Wenn das Projektfile von Interesse ist, kann ichs mal posten. Günter
Dass es nach dem Blattwechsel wieder funktioniert hat, verwundert mich. Hab mir grad nochmal den Code angeschaut, der Anzeigebereich wird immer dann überprüft, wenn neue Punkte im Diagramm eingetragen werden. Du sprichst vom 28.März, kann es sein, dass in der Zeit nachdem du das Diagramm im Zoom hattest einfach erstmal keine neuen Werte reinkamen, sondern (zufällig) als du auf dem anderen Blatt warst? Andererseits dürfte das Diagramm dann auch nicht schon weitergewandert sein... komisch. Vielleicht kannst du das noch genauer beschreiben.
Hallo Est Est Est, habe noch mehrfach zurückgeblättert und gezoomt, aber das Verhalten von kürzlich ist nicht mehr aufgetreten. Ich beobachte das zwar weiter, aber ich denke, Du müßtest dem jetzt mal keine weitere Beachtung schenken. Insgesamt funktioniert das Programm und auch das Zeitdiagramm ja sehr gut. Günter
Nach längerer Zeit wieder eine neue Version V1.1 mit folgenden Neuerungen: - Neues Instrument TrayIcon (Funktioniert zuverlässig nur unter Windows): Es erscheint ein Taskleistensymbol (Symbol wählbar) im rechten Eck. Über das Instrument kann man die Comvisu in den "Tray-Modus" versetzen, dann öffnet sich das Comvisu-Fenster bei Klick auf das Taskleistensymbol und wird ausgeblendet, wenn man in den Desktop, ein anderes Fenster oder auf die Taskleiste klickt. Für den verbunden und unverbunden Zustand sind unterschiedliche Symbole hinterlegt und hinterlegbar. Der Tray-Modus ist ganz geschickt, wenn die Comvisu eher im Hintergrund mitlaufen soll. Statt Tray-Modus kann man durch Klick auf das Taskleistensymbol auch ein Befehl absetzen lassen. Es sind mehrere Symbole möglich. - Die Diagramme (Zeit- und XY-) können nun über den Steuerkanal in ihren Grenzen verändert werden. Das bietet sich z.B. an bei Verwendung als Logikanalyzer/Oszi. Die Befehle sind im Instrument in den Einstellungen 'Steuerkanal' beschrieben. - Die Fernanzeige hat nun einen Initialwert bekommen, so kann man ihn auch als statischen Text/Beschreibung verwenden. - Es gibt nun den Kommandozeilenparameter "-WindowMaximized" zum Starten der Comvisu im maximierten Fenster. - Diverse Fehler ausgebessert und kleinere Änderungen
Hallo Est Est Est, Danke für die Weiterentwicklung! Ich hätte aber einen Vorschlag. Im Ausführungsmodus die Schnittstellenwahl oben vor der Verbindungsanzeige einzublenden wie beim Terminal. Gruß rodnas
Hallo Est Est Est, toll, vielen Dank für das Update. Ich werde es demnächst testen und Dir berichten (auch für die Linux-Version für den Raspi, aber das dauert noch etwas). Günter
rodnas schrieb: > Ich hätte aber einen Vorschlag. Im Ausführungsmodus die > Schnittstellenwahl oben vor der Verbindungsanzeige einzublenden wie beim > Terminal. Das Programm verarbeitet ja prinzipiell alle Schnittstellen, die Auswahl im Terminal gibt es nur, weil eine vermischte Aufzeichnung verschiedener Schnittstellen zumindest auf Zeichenebene nicht sinnvoll ist. Für was wäre die Auswahl im Ausführenmodus dann gut? Grüße
ich dachte es wird exklusive nur die im Terminal ausgewählte Schnittstelle. So ist mein Problem gelöst. :) weitere Frage: woran könnte es liegen, das über eine aktive UDP Verbindung der Datenstrom im Programm verarbeitet wird aber im Terminal nicht angezeigt. Über WLAN funktioniert anstandslos.
Hallo zusammen! Bin neu hier und hab mich mit dem visualisieren noch nie beschäftigt. Meine Situation. Diesen Sommer haben wir unsere Heizung erneuert, diese hat ihre eigene Steuerung. Ich habe eine MichroSPS (microsps.com) und die ist zuständig für den zweiten Pufferspeicher. Jetzt bin ich vor einpaar Tagen auf dieses Programm gestoßen, installiert und versucht damit zurecht zu kommen. Leider ohne Erfolg. Hat einer von euch eine microSPS? Ich weis nicht wie ich anfangen soll, es klappt nicht die daten von der microsps dar zu stellen. Bitte um etwas Starthilfe. Danke in voraus!
Hallo Waldemar, habe mich mal ganz kurz mit der microSPS beschäftigt. Sieht interessant aus, insbesondere das Konzept, den Funktionsplan als EAGLE-Schaltplan zu erstellen und diesen als Netzliste als Steuerfile für die SPS zu verwenden. Originelle Idee, wenn es funktioniert (davon ist aber wohl auszugehen). Als Vorgehensweise würde ich das an Deiner Stelle splitten: Die Doku der microSPS beschreibt ja die Formate der auszugebenden Daten über die serielle Schnittstelle. Dort mußt Du versuchen, das Format der Visualisierungsdaten von Comvisu zu erzeugen (siehe dessen Handbuch); das Ergebnis stellst Du am besten zunächst in einem Terminalprogramm am PC dar (z.B. mit HTerm von Tobi Hammer), bevor Du die Daten direkt an Comvisu gibst. Vorher würde ich an Deiner Stelle in Comvisu ein einfaches Instrument definieren und mit einem zweiten PC (z.B. ein älteres Notebook, das hat ja fast jeder von uns) auch wieder mit HTerm Daten eintippen und an Comvisu senden (klar: kann man auch direkt in Comvisu erzeugen, man braucht keinen zweiten PC, aber dies erleichtert die Sache m.E.). Sobald das einwandfrei klappt, hast Du begriffen, wie Comvisu angesteuert wird. Dann kannst du Deine microSPS mit Comvisu koppeln und das Ganze müßte funktionieren. Etwas ähnliches habe ich in meinem Heizraum am Laufen, mit Comvisu und einer kleinen ATmega328-Anwendung auf einer Lochrasterkarte mit DS18S20-1Wire-Thermosensoren. Das klappt einwandfrei. Comvisu ist super! Viel Erfolg. Günter
Hi Leute. Ich möchte mit einem Arduino und Schieberegistern eine Weichensteuerung #Modelleisenbahn bauen (74hc595->ULN Darlington Array). Den Arduino Sketch habe ich auch schon erstellt. Momentan sende ich die seriellen Daten per Excel an den Arduino. Dazu habe ich mir je Weiche ein CommandButton (als Taster) mit entsprechendem Code eingesetzt. Jetzt möchte ich aber eine grafische Oberfläche erstellen auf die ich mein Gleisplan "malen" kann und dann die Taster einsetzen kann. Beim Thema "grafische Oberfläche" wird es jetzt mit den Excel unschön. Könnte ich das mit dem Comvisu realisieren?
Hallo Heiko, theoretisch ist machbar. Hintergrundbild ist deine Gleisanlage. Taster, Schalter, LED nach Bedarf einsetzen und dein Programm ComVisu gerecht anpassen. Gruß
Hallo Est Est Est, ich habe Comvisu 1.1 jetzt installiert. Programm läuft gut; die neuen Features habe ich aber noch nicht getestet, das kommt demnächst; ich berichte dann. Danke! Gruß Günter
@Waldemar und @Günter, Ist zwar off-topic, aber sowas wie microsps hab ich im Ansatz mal OpenSource gemacht. Das Kernelement ist der Snaiks-Kompiler, der aus einer Netzliste, die mit KiCad erstellt wurde, einen C++ Code erstellt und somit den Funktionsplan in C++ impementiert. http://www.zeilhofer.co.at/wiki/doku.php?id=snaiks-study und das update dazu: http://www.zeilhofer.co.at/wiki/doku.php?id=snaiks Bei Interesse sollten wir die Diskussion in einem neuen Thread weiterführen. LG, Karl EDIT: es wäre natürlich schön, die Lösung mit ComVisu zu koppeln :)
:
Bearbeitet durch User
Hallo Est Est Est, Zunächst mal ein Kompliment für die wirklich sehr gelungene Software :-) Ich hätte zwei Fragen/Anregungen zur Möglichkeit Daten in eine Datei zu speichern: Im Moment scheint es nicht möglich zu sein die Daten mit komplettem Zeitstempel (Datum + Uhrzeit) anstelle von Datenpunktnummer und verstrichener Zeit seit Start zu exportieren. Ist in diese Richtung etwas geplant? Das Datenfile wird momentan immer nur geschrieben, wenn die Verbindung in ComVisu getrennt wird. Wäre es möglich das so zu implementieren, dass die Daten in "Echtzeit", also wenn ein neuer Messwert ankommt, in die Datei zu schreiben um im Falle eines Absturzes oder Ähnlichem trotzdem die Daten nicht zu verlieren? Danke schonmal für die Antwort! Schöne Grüße, Georg
Hallo Georg, das Speichern von Datum und Uhrzeit kann ich einbauen, sollte kein Problem sein. > Das Datenfile wird momentan immer nur geschrieben, wenn die Verbindung > in ComVisu getrennt wird. Wäre es möglich das so zu implementieren, dass > die Daten in "Echtzeit", also wenn ein neuer Messwert ankommt, in die > Datei zu schreiben um im Falle eines Absturzes oder Ähnlichem trotzdem > die Daten nicht zu verlieren? Vom Programm werden die Daten schon immer sofort geschrieben, das Betriebssystem puffert da aber und schreibt eben spätestens bei Programmende die Datei. Darauf habe ich prinzipiell keinen Einfluss. Alternativ kann ich aus dem Programm raus nach jedem geschriebenen Wert die Datei schließen und beim nächsten wieder auf machen. Das funktioniert auch gut, verlangsamt aber das Schreiben. Vielleicht mache ich das konfigurierbar, wird dann aber wieder weniger intuitiv. Vorschläge dazu? Viele Grüße~
Hallo Est Est Est und Georg, ich verwende das Dateischreiben zwar derzeit nicht, ist aber nicht ausgeschlossen in der Zukunft. Daher kann man darauf schon ein Augenmerk richten. Ich hätte auch spontan auf Georgs Beitrag an jeweiliges Schließen der Datei nach jedem Schreiben gedacht (und Öffnen vor weiterem Schreiben/Append). Ggf. könntest Du, Est Est Est, ein Häkchen vorsehen für dieses Feature, wobei Häkchensetzen bedeuten könnte, daß das Close/Reopen bei gesetztem Haken unterlassen wird aus Geschwindigkeitsgründen, aber ansonsten by default (bei nicht-gesetztem Haken) gemacht wird, aus Sicherheitsgründen. Viele Grüße Günter
Hallo Günter, das hört sich sinnvoll an, standardmäßig den sicheren Dateizugriff zu aktivieren. Zum Raspberry-Fehler: Ich weiß bisher nicht wo der Zeitversatz herkommt, bin noch am Suchen. Viele Grüße~
Hallo Est Est Est, erst einmal ein Riesenlob für dein Programm - bin nach langer mühseligen ASCCI-Monitorerfahrung erst jetzt darauf gestossen !! Eine Frage und eine Anregung vielleicht für weitere Versionen: - Thema Dateirekorder: wie kann ich den Aufzeichnungszyklus steuern bzw. gezielt verlangsamen - Beispiel: Daten werden für optische Darstelleung alle 1s aktualisiert, sollen aber nur alle 10s gespeichert werden! ? - Ist es vorstellbar, im Programm z.B. im Rahmen der Kanalliste zu jedem verwendeten Kanal ein Kommentarfeld anzulegen, in dem man Erläuterungen, wie z.B. den Signalnamen hinterlegen kann? Alternativ wäre auch vielleicht ein einfaches Instrument im Sinne eines ASCCI-Textfeldes auf der Oberfläche super, dass man dann einfach editieren kann! Viele Grüße, Ulrich
Hallo Ulrich, zum Thema Dateirekorder, es ist kein Mechanismus vorhanden eingehende Werte gezielt auszusortieren. Es wäre denkbar eine solche Funktionalität als Funktion umzusetzen. Die könnte z.B. "downsample" heißen und als Parameter jeder wievielte Wert verarbeitet werden soll. Ich behalte das mal im Hinterkopf. Die Frage wäre noch, ob man dann Durchschnitte bilden möchte, oder wirklich nur jeweils den n-ten Wert verwendet. Man sieht hier, dass man mit einer reinen Formellösung schon an Grenzen stößt. Die Kanalliste wird im Programm aus den Instrumenten "gesammelt", Kommentare dazu müssten getrennt gespeichert werden. Das wird eher nicht kommen. Ein ASCII-Textfeld gibt esin Form der Fernanzeige schon. Unter "Initialwert" lässt sich der statische Text eintragen. Einfach den Eingang leerlassen, das verlangsamt dann auch nicht die Datenübertragung. Viele Grüße
Hallo Est Est Est, eine Frage nochmal zu deiner genialen Software : Hat etwas mit meiner letzen Frage bzgl. mögl. Datenreduktion beim Speichern zu tun - es geht um die getaktete Ausgabe: Ich habe versucht, diese Funktion zu nutzen, um Messdatenkanäle mit einem festen Zeitraster (z.B. nur alle 60s) auszugeben. Habe dazu als Eingangskanal den physikalschen Datenkanal angegeben, aus dem regelm. Daten reinkommen, z.B. "#100" oder "datetime()" und als Ausgangskanal eine noch unbenutzte Kanalnummer (z.B. "#180") angegeben. Im Betrieb zeigt das Blocksymbol auch eifrig die Sendeanimation und die aktuellen Daten an . Wenn ich allerdings einen Dateirecorder anlege und versuche den Ausgangskanal zu schreiben wird nichts abgelegt. Ebenso kann ich den Ausgangskanal nicht in einer numerischen Anzeig darstellen - wir einfach 0 angezeigt !? . Ich fürchte, ich verstehe die getaktete Ausgabe noch nicht ganz !? Für eine kurze Hilfestellung dazu wäre ich dir sehr dankbar ! Viele Grüße
Ulrich K. schrieb: > Hallo Est Est Est, > eine Frage nochmal zu deiner genialen Software : > Hat etwas mit meiner letzen Frage bzgl. mögl. Datenreduktion beim > Speichern zu tun - es geht um die getaktete Ausgabe: > Ich habe versucht, diese Funktion zu nutzen, um Messdatenkanäle mit > einem festen Zeitraster (z.B. nur alle 60s) auszugeben. > Habe dazu als Eingangskanal den physikalschen Datenkanal angegeben, aus > dem regelm. Daten reinkommen, z.B. "#100" oder "datetime()" und als > Ausgangskanal eine noch unbenutzte Kanalnummer (z.B. "#180") angegeben. > Im Betrieb zeigt das Blocksymbol auch eifrig die Sendeanimation und die > aktuellen Daten an . > Wenn ich allerdings einen Dateirecorder anlege und versuche den > Ausgangskanal zu schreiben wird nichts abgelegt. Ebenso kann ich den > Ausgangskanal nicht in einer numerischen Anzeig darstellen - wir einfach > 0 angezeigt !? . > Ich fürchte, ich verstehe die getaktete Ausgabe noch nicht ganz !? > Für eine kurze Hilfestellung dazu wäre ich dir sehr dankbar ! > > Viele Grüße Hallo Est Est, die Frage oben hat sich in der Zwischenzeit nach eigenem Ausprobieren ereldigt - habe allerdings ein kleines anderes Problem: Ich setze Comvisu ein, um einen Arduino zu steueren bzw. von dioesem Daten zu visualisieren. Ich stolpere im Zuge Änderungen an den Dateninhalten der Kommunikation sporadisch immer wieder über anhängende Fehlermeldung seitens Comvisu: "Invalid floating point operation", die teilw. sofort zum Absturz führt - teilweise auch mit OK Quittiert werden kann!? Ich kann bislang noch kein System erkennen, wann dieser Fehler auftritt nd wann nicht! Kannst du mir ienen Tip zur Ursache bzw. Vermeidung geben ? Viele Grüße
Hallo Ulrich, habe deine Beiträge erst gerade gesehen. Zur ersten Frage, die Ausgangskanäle sind getrennt von den Eingängen und lösen keine Berechnung aus (werden nicht zusätzlich als Eingang verarbeitet). Ich habe mir schon überlegt, ein instrument ähnlich des E-A-Kanals in umgekehrter Richtung zu machen, also als A-E-Kanal um so einen ausgegebenen Kanal "abfangen" zu können, mal sehen. Zur Fehlermeldung, da kann ich spontan auch nicht viel dazu sagen. "Invalid Floating Point Operation" heißt meistens, dass durch 0 geteilt wurde, was aber eigentlich von der Comvisu abgefangen wird. Kannst du mal deine Projektdatei anhängen (.visu), vielleicht ergibt sich ein Hinweis daraus. Viele Grüße
Hallo Est Est Est, danke für deine Rückmeldung - hab den Fehler in der Zwischenzeit gefunden - genau wie von dir vermutet - division by zero :-) - Divison durch einen Kanal der noch nicht initialisiert war !!! Falls du noch an der SW weiterentwickelst - vielleicht eine Anregung bzgl. Ausgabe in Datei - wäre es möglich, automatisch bei jedem erneuten Verbindungsaufbau einen neuen Dateinamen zu generieren z.B. mit fortlaufender Nummerierung oder vielleicht sogar besser mit Datum/Zeit Kennung im Namen ? Viele Grüße Ulrich
Hallo Ulrich, gut, dass es jetzt klappt~ Ich hab mir das mal notiert, das sollte intern abgefangen werden. Vielleicht gibts dann auch bald mal wieder eine neue Version. Viele Grüße
Hallo Est, nur so nebenbei: Comvisu ist sehr stabil, läuft jetzt seit mehr als 8 Monaten ununterbrochen bei meiner Heizungssteuerung - ist nicht wieder abgestürzt (hier rede ich auch für die ARM/Linux-Version, die ist auch super). Danke! Viele Grüße Günter
Neue Version Comvisu V1.6 mit folgenden Neuerungen: - Dezent überarbeitete GUI mit weniger "grau"; Beim Bearbeitenmodus kann nun keine eigene Hintergrundfarbe mehr eingestellt werden, dafür gibt es ein Karoraster zur einfacheren Ausrichtung der Instrumente und zur Unterscheidung der Modi. - Neue Schnittstelle: 'TCP-Server' und 'TCP-Client'. Der TCP-Server nimmt auf dem eingestellten Port eine beliebige Anzahl an TCP-Verbindungen an. Die Schnittstellenart 'TCP-Client' fungiert wie der Name sagt als TCP-Client, es kann damit aber auch eine Verbindung mit einem anderen TCP-Client aufgebaut werden (Option 'Mehrfaches Verbinden'). Details dazu in der Doku. - Neues Instrument Konsole. Das stellt praktisch eine Textanzeige dar mit Protokollierung. Wie bei allen Instrumenten sind auch mehrere Konsolen möglich. Das Instrument hat nichts mit dem Konsolenfenster (Kanal #0) zu tun, dieses gibt es nach wie vor. - Diverse kleinere Änderungen, u.a. im Instrument Dateirekorder. Wie immer gibt es auch eine entsprechende Linux- und Arm-Linux- (Raspberry) Version der Comvisu, siehe Nachbarthread "Comvisu für Linux" Beitrag "Comvisu für Linux"
Hallo Est, toll, da freue ich mich drauf. Werds demnächst testen, und du hörst von mir. Danke! Viele Grüße Günter
Hallo Est Est Est, Mit dem Programm bin ich weiterhin sehr zufrieden. Einfach genial. Eine Anregung hätte ich zur Erweiterung. Ein Timer oder Zeitrelais womit man ereignisgesteuert und zeitbehaftet Ausgänge beeinflussen kann. Eine Art Multifunktions-Zeitrelais. Viele Grüße rodnas
Hallo Est Est Est, bei Taktausgabe wird Ausgabewert zeigen nicht abgespeichert. Grüße rodnas
Hallo Est Est, ich bin gerade auf ComVisu gestoßen. Eigentlich war ich auf der Suche nach besseren debugging Möglichkeiten als sie die Arduino IDE bietet. Zunächst mal großes Lob für ComVisu. Neben der Hilfe bei der Arduino Programmentwicklung, kommen jetzt natürlich völlig neue Ideen ins Spiel. Daher die Frage: Gibt es in Zukunft weitere Instrumente wie z.B. Rundinstrumente, Tankanzeige oder die Möglichkeit eigene Anzeigen zu gestalten ? (ähnlich Bitmap Schieberegler) Gruß Olaf
Eure Beiträge hab ich erst jetzt gelesen, irgendwie sind keine Benachrichtigungen mehr gekommen. rodnas schrieb: > Eine Anregung hätte ich zur Erweiterung. Ein Timer oder Zeitrelais womit > man ereignisgesteuert und zeitbehaftet Ausgänge beeinflussen kann. Eine > Art Multifunktions-Zeitrelais. Du meinst bspw. ein Eingang triggert einen Zeitgeber, der nach Ablauf Befehle absetzen kann oder Eingänge triggert? rodnas schrieb: > bei Taktausgabe wird Ausgabewert zeigen nicht abgespeichert. Danke, wird korrigiert. Olaf T. schrieb: > Gibt es in Zukunft weitere Instrumente wie z.B. Rundinstrumente, > Tankanzeige oder die Möglichkeit eigene Anzeigen zu gestalten ? (ähnlich > Bitmap Schieberegler) Ich konzentrier mich eher auf funktionelle Instrumente. Wenn es nur am Zeiger-/Drehknopfinstrument fehlt, wäre das schon eine Überlegung. Aber ich denke, man bräuchte eine noch größere Palette an Bitmap-Instrumenten, um wirklich eine Oberfläche mit eigenem "Look&Feel" zu erstellen. Und da fehlt mir dann die Motivation dazu und momentan auch die Zeit.
Hallo Est Est Est Frohes Neujahr und vor allem Gesundheit wünsche ich! Est Est Est schrieb : > Du meinst bspw. ein Eingang triggert einen Zeitgeber, der nach Ablauf > Befehle absetzen kann oder Eingänge triggert? Genau so habe ich vorgestellt. Funktionen wie im Anhang. Zeit Einstellung von "s" bis "h" rodnas
rodnas schrieb: > Frohes Neujahr und vor allem Gesundheit wünsche ich! Danke und ebenfalls! :) Ich überleg mir mal wie ich so einen Zeitgeber am Geschicktesten einbauen könnte. Evtl. per Funktion statt eigenes Instrument.
Eigene Instrument ist sichtbar, programmierbar und je nach Bedarf kann man zuordnen. Ähnlich wie "Getaktete Ausgabe". Könntest du vielleicht dieses Instrument mit neuen Funktionen erweitern.
Hallo Est Est, folgende Anwendung würde ich gerne mit ComVisu realisieren, finde aber keine adäquate Lösung: Mehrere Relais (32) an einem µC sollen einzeln und/oder in Gruppen von Hand geschaltet werden können. Gleichzeitig möchte ich aber auch die Relais durch Parameter, die von einer Schnittstelle kommen, schalten. Die Schalter in ComVisu für die Relais sollten dann aber auch den neuen Zustand übernehmen und anzeigen. Das heisst, es wären steuerbare Schalter mit Eingängen notwendig. Wäre so etwas in ComVisu machbar? Viele Grüße Ralf
Hallo Ralf, das ist momentan so nicht möglich. Ja, ist ne Lücke... Ich schau mal ob ich das kurzfristig einbauen kann. Viele Grüße
Hallo Est Est, ich wollte mal nachfragen, ob Du schon dazu gekommen bist zu prüfen, ob programmierbare Schalter kurzfristig in ComVisu machbar wären. Mein Interesse daran besteht immer noch ;) Viele Grüße Ralf
Hallo Ralf, implementiert ist es schon, habe aber sonst noch ein paar Sachen geändert, was noch nicht abgeschlossen ist. Also dauert noch etwas.
Hallo Est Est Est, Zusätzlich zu den bereits geäußerten Wünschen wäre meiner Ansicht nach im Bereich Schnittstelle zwei Button "Trennen" "Verbinden" willkommen. Vielleicht unter Hilfsmittel? Viele Grüße rodnas
Hallo rodnas >> Du meinst bspw. ein Eingang triggert einen Zeitgeber, der nach Ablauf >> Befehle absetzen kann oder Eingänge triggert? > Genau so habe ich vorgestellt. Funktionen wie im Anhang. Zeit > Einstellung von "s" bis "h" Kannst du bitte noch deine Anwendung dazu beschreiben. Beim Zeitrelais geht es ja eher um ein Signal, auf die Comvisu übertragen würden zwei Werte/Befehle ausgegeben, einmal beim Startzeitpunkt (1) und einmal beim Stopzeitpunkt (0). Das scheint mir eher speziell zu sein. Eine andere Möglichkeit wäre einen einfachen Zeitgeber vorzusehen. Die einfache Relaisfunktionalität könnte man sich dann aus zwei Zeitgebern zusammenbasteln, bei Impulsen wird es aber wieder schwierig.
Hallo Est Est E., Also zur Verwendung, zum Beispiel einen Regler-Sollwert ereignisbedingt und zeitbehaftet zu verstellen. Auslöseereignis kann eine Wertänderung (Umfeld) oder Zeitpunkt (comvisu) sein. Comvisu generiert eine einstellbare Zeitspanne welche entweder nach der Eingangstriggerung oder nach dem Zeitablauf einen Wert/Befehl übermittelt. Ähnlich wie Taktausgabe aber einmalig. Grüße rodnas
Hallo Est Est Est, Weitere Wunsch, wäre es möglich frei beschreibbare Textblöcke zur Beschriftung im Programm integrieren? Andere: Irgendwie bin ich nicht sicher das die LED-Leiste die Daten richtig umsetzt. Grüße rodnas
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.