Serielle Visualisierung mit Comvisu

[Est Est E. (comvisu)]

Liebes Forum,

ich möchte hier mein Programm vorstellen, das zur 
Mikrocontrollerentwicklung und zur Visualisierung über die serielle 
Schnittstelle eingesetzt werden kann. Ein ähnliches Programm gibts hier 
im Forum bereits, nur waren mir die Möglichkeiten zu eingeschränkt, 
sodass ich mich an ein eigenes gewagt habe.

Die Anzeigeelemente (bisher implementiert: Analoganzeige, 
Digitalanzeige, Zeitdiagramm, Textanzeige, Zeichenausgabe und Taster) 
können in beliebiger Anzahl auf der Oberfläche platziert und über ein 
graphisches Menü angepasst werden. Für jedes Element kann der Ein- oder 
Ausgang definiert werden (blau hinterlegtes Feld "Eingang" im 
Eigenschafteneditor). Wird bspw. Kanal #5 angegeben, dann werden die 
Daten angezeigt, die der Comvisu über die serielle Schnittstelle für 
diesen Kanal eingehen. Die Anzeige wird dann vom Mikrocontroller mit 
folgendem Befehl angesprochen (alles in Ascii):
#Kanal/Format/Wert; Beispiel: "#5F7,3;" schreibt den Zahlenwert (F) 7,3 
in Kanal 5. Das gleiche gilt für Ausgänge. Zeichenketten müssen mit "S" 
gekennzeichnet sein. Beispel: "#5SHallo Welt;". Die Eingänge können 
sogar mit Formeln definiert werden, ähnlich einer Tabellenkalkulation, 
mehr dazu in der angehängten Dokumentation.

Ein angeschlossenes Gerät kann so auf einfache Weise die Ausgaben auf 
der Comvisu erzeugen.
Es sind 1000 Kanäle definiert. Die Kanäle #1 bis #999 sind universelle 
Kanäle, die in den Anzeigeelementen verwendet werden können. Kanal #0 
ist reserviert für das Konsolenfenster. Alle Werte, die über diesen 
Kanal eingehen, werden auf der Konsole ausgegeben, wenn diese aktiviert 
ist (macht aus dem µC eine Konsolenanwendung).
Zum Testen gibt es im Ausführen-Menü die Möglichkeit manuell Befehle 
abzusetzen.

Das Programm biete ich zur privaten Nutzung kostenlos an. Das wird auch 
in Zukunft so bleiben.
Eine Installation ist nicht notwendig, die Exe kann direkt ausgeführt 
werden.

Ich würde mich über Anregungen und Kritik freuen!

Viele Grüße!

[Est Est E. (comvisu)]

Im Mehrfach-Zeitdiagramm war ein Fehler drin, es wurde nur eine Kurve 
aufgezeichnet, das ist nun behoben.
Darüber hinaus gibt es zwei neue Elemente: Einzel-LED und einen 
Dateirekorder. Wie bei den anderen Elementen gilt, man kann sie in 
beliebiger Anzahl anordnen und verwenden.

Insgesamt stehen jetzt zur Verfügung:
- Analoganzeige
- Digitalanzeige
- Zeitdiagramm
- 4-Fach-Zeitdiagramm
- Fernanzeige für Texte
- Zeichenausgabe
- Taster
- LED/Signalleuchte
- Dateirekorder

Und natürlich Terminal und Konsole.


Die Resonanz bisher könnte besser sein. Ich bin natürlich auf eure Posts 
und Meinungen angewiesen, lasst euch nicht bitten;-)

[Programmbeurteiler (Gast)]

Ich werde es mir reinziehen und dann Meldung machen.

Wäre Übrigens gut, wenn es das Programm nur einmal gäbe und zwar in der 
aktuellen Version. Mit einer Webseite wäre das geregelt.

[Est Est E. (comvisu)]

Eine Webseite ist in Planung, das wird aber noch etwas Zeit brauchen.

[Est Est E. (comvisu)]

Hier eine neue Version, es werden nun auch UDP-Verbindungen unterstützt. 
Darüber hinaus können mehrere Schnittstellen gleichzeitig verwendet 
werden, auch Serielle und UDP gemischt. Ausgänge werden in diesem Fall 
an alle Schnittstellen geschickt.
Das Terminal funktioniert nun mit der Schnittstelle, die in der Liste an 
der ersten Stelle steht. Allerdings bisher nur für die serielle 
Schnittstelle.
Desweiteren sind ein paar Fehler ausgemerzt.

[Moby A. (moby-project)]

Est Est E. schrieb:
> Wie bei den anderen Elementen gilt, man kann sie in
> beliebiger Anzahl anordnen

Ausgezeichnet. Das sprengt so wie behauptet endlich die Fesseln manch 
eines Konkurrenzprogramms! Also endlich z.B. so viele Taster und LEDs 
wie man benötigt?

> Die Resonanz bisher könnte besser sein. Ich bin natürlich auf eure Posts
> und Meinungen angewiesen, lasst euch nicht bitten;-)

Besten Dank für Deine Bemühungen, das schaut sehr gut aus, werde das 
Programm bei Gelegenheit auch mal testen! Ansonsten brauchts eben Geduld 
und Durchhaltevermögen, die Einbindung eines neuen Programms in ein 
eigenes Automatisierungs- System benötigt eben Zeit und auch das 
Vertrauen, ein langfristig angelegtes Projekt vor sich zu haben ;-)

[Günter (galileo14)]

Ich habe mal versucht, das Programm zu starten, auf einem WinXP 5.1 SP3 
System. Dort gibts aber die Fehlermeldung "Der Prozedureinsprungpunkt 
"GetTickCount64" wurde in der DLL "kernel32.dll" nicht gefunden. Damit 
kann bei mir das Programm nicht gestartet werden. Ist es evt. erst ab 
Win7 geeignet?

[Est Est E. (comvisu)]

Moby A. schrieb:
> Ausgezeichnet. Das sprengt so wie behauptet endlich die Fesseln manch
> eines Konkurrenzprogramms! Also endlich z.B. so viele Taster und LEDs
> wie man benötigt?

Genau, es gibt keine interne Begrenzung, wie oft ein Element (z.B. LED) 
verwendet werden darf. Jedem Element wird dann der Eingang (bzw. 
Ausgang) zugewiesen. Die Einstellungen werden natürlich für jede Instanz 
getrennt vorgenommen und können entsprechend gespeichert werden.

Einfach mal ausprobieren!

[Est Est E. (comvisu)]

Günter R. schrieb:
> Ich habe mal versucht, das Programm zu starten, auf einem WinXP 5.1 SP3
> System. Dort gibts aber die Fehlermeldung "Der Prozedureinsprungpunkt
> "GetTickCount64" wurde in der DLL "kernel32.dll" nicht gefunden. Damit
> kann bei mir das Programm nicht gestartet werden. Ist es evt. erst ab
> Win7 geeignet?

Bisher habe ich es nur mit Win7 und Win 8.1 getestet. Ich schau mir das 
an!

[Günter (galileo14)]

Unter Win7 startet das Programm. Aber für eine konkrete Anwendung würde 
ich ggf. gerne einen älteren WinXP-PC verwenden, der dann z.B. im 
Heizraum steht und Heizungsdaten anzeigt.

[rodnas (Gast)]

(Bascom)

     Print "#10F" ; Str(Temp1) ; " ; "      'test für comvisu
     Print
     Print "#0F" ; Str(Temp1) ; " ; "
     Print

in der Konsole wird angezeigt, die Instrumente bleiben ungerührt.
Woran könnte es liegen?

[Est Est E. (comvisu)]

rodnas schrieb:

>      Print "#10F" ; Str(Temp1) ; " ; "

> in der Konsole wird angezeigt, die Instrumente bleiben ungerührt.
> Woran könnte es liegen?

Bascom kenne ich nicht, aber vor dem Strichpunkt ist noch ein 
Leerzeichen? Versuche es mal ohne dieses.

Wenn die Daten über die serielle Schnittstelle kommen, kannst du alle 
eingehenden Zeichen im Terminal-Fenster anschauen (und hier posten).

Edit: Habs grad getestet, müsste auch mit Leerzeichen funktionieren.

[rodnas (Gast)]

So kommt es herüber,

jetzt ohne Leerzeichen vor und nach dem Strichpunkt, aber keine 
Änderung.

[Est Est E. (comvisu)]

Es müsste schon funktionieren. Unter welchem System hast du es am 
Laufen?

In der Statusanzeige "Verbunden", blinkt bei Dir das kleine Kästchen 
schwarz-weiß? Das zeigt die zyklische Aktualisierung der Anzeigen an.
Versuche mal einen manuellen Befehl zu setzen, siehe Anhang. Z.B. 
"#10F5;", das kann auch gemacht werden, wenn die Schnittstelle nicht 
verbunden ist.
Ein weitere Testmöglichkeit ist einen Eingang #10+0*#11 zu definieren. 
dann kannst du die Anzeigenneuberechnung über den manuellen Befehl 
triggern und siehst dann, welcher Wert auf Kanal 10 liegt (Werte bleiben 
auch nach Trennen noch bestehen). Normalerweise müsste der Kanal aber 
automatisch getriggert werden.

[Carl D. (jcw2)]

23.9 vs. 23,9

Typisches Konvertier-Sprach-Problem.

[chris_ (Gast)]

Mit welcher Programmiersprache hast Du ComVisu gemacht? Ist es auch mit 
Delphi wie VirtualComInstruments?

[Johannes M. (johannesm)]

Habe das Programm gerade durch Zufall entdeckt und sieht auf den ersten 
Blick sehr gut aus!
Besonders die manuelle Skalierung der x/y-Skala in den Diagrammen 
gefällt mir, dann kann man einfach die Rohdaten anzeigen (im Moment 
hantiere ich mit 32Bit ADCs rum). Bei anderen Programmen musste man 
immer einen Großteil der Auflösung opfern, weil die z.B. nur +/-10 
vernünftig anzeigen konnten.
Ich war schon kurz davor mir das LabView Home Bundle zu kaufen, aber 
hiermit werde ich erstmal auskommen für meinen Privatkrams.

[Est Est E. (comvisu)]

Carl D. schrieb:
> 23.9 vs. 23,9
> Typisches Konvertier-Sprach-Problem.

Das kann es nicht sein, das habe ich berücksichtigt, es können beide 
Varianten verwendet werden. Ich vermute eher, dass sich Steuerzeichen im 
Befehl befinden, die die Auswertung durcheinander bringen. Oder, dass es 
Kompatibilitätsprobleme mit dem OS sind.


chris_ schrieb:
> Mit welcher Programmiersprache hast Du ComVisu gemacht? Ist es auch mit
> Delphi wie VirtualComInstruments?

Fast. Mit Lazarus/FPC.

Johannes M. schrieb:
> Habe das Programm gerade durch Zufall entdeckt und sieht auf den ersten
> Blick sehr gut aus!
> Besonders die manuelle Skalierung der x/y-Skala in den Diagrammen
> gefällt mir, ...

Das Freut mich! Die manuelle Skalierung der Y-Skala bringt allerdings 
das problem mit sich, dass man Werte außerhalb nicht sieht und auf eine 
Fehlfunktion schließen könnte. Da muss ich mir noch Gedanken dazu 
machen.

[Moby (Gast)]

Est Est E. schrieb:
> Einfach mal ausprobieren!

Also ich muß nach ein wenig Spielerei (erstmal ohne Input) schon sagen: 
Das schaut bereits in dieser frühen Phase nach einer ganz runden, 
durchdachten Sache aus! Kompliment! Genau aufs Wesentliche konzentriert! 
Alle aus meiner Sicht essentiellen Bestandteile sind enthalten, man ist 
dank der flexiblen Kanal-Zuordnung völlig frei in deren beliebiger 
Auswahl. Ein Riesenvorteil. Auch in Details sehr sinnvoll gelöst (z.B. 
LED-Beschriftung leuchtend im Bauelement). Prima. Zur Ausführung nur 
eine simple .exe: Hervorragend! Alles schön einfach. So muß das sein! 
Bloß nicht unnötig Komplexität reinbringen! Das Ganze ist natürlich 
Win10/64 kompatibel.

Nun könnte man sich sicher noch viel wünschen:

- Bauteil Platzier/Skaliergitter mit Einrasten
- freie Größenänderung der Elemente mit der Maus
- freie Text-Beschriftungsmöglichkeit (Label)
- Anzeige des geladenen Projekts (in Titelleiste)
- weitere Bauteil-Formen (z.B. rund)
- Hex-Anzeigemöglichkeit wirklich aller Zeichen im Terminal
- Fullscreen Bedienoberfläche (im Ausführen-Modus)

um mal 7 Punkte fürs Erste zu nennen. Doch wäre das alles nur mehr 
Luxus, das sind jetzt wirklich keine grundlegenden Funktionsmängel. 
Schön wäre allerdings die Zusicherung, daß sich am Datenformat der .visu 
nix mehr ändert bzw. ältere Projekte im Fall des Falles immer geladen 
und einfach neu abgespeichert werden können ;-)

An anderen Stellen hakelt es noch:

- Änderungen von Bauelementen (Größe) werden oft nicht instantan 
übernommen
- Gefährlich ist ggf. der große Sichern-Button: Ruckzuck ist ein 
bestehendes Projekt überschrieben...

Egal. Bereits jetzt scheint dieses Programm (nach noch recht 
oberflächlicher Betrachtung) absolut brauchbar. Dankeschön!

[Günter (galileo14)]

Von mir nochmals die Frage: wie steht es mit der WinXP-Kompatibiliät? 
Kannst du da nochmals danach schauen? Ich denke, man sollte das 
Potential nicht unterschätzen, ältere PCs für solche Zwecke noch zu 
verwerten.

[Est Est E. (comvisu)]

Günter R. schrieb:
> Von mir nochmals die Frage: wie steht es mit der WinXP-Kompatibiliät?

Die XP-Kompatibilität strebe ich ganz klar an.
Nur hab ich kein XP-Rechner zur Hand zum Testen.
Die Funktion Gettickcount64 gibt es tatsächlich erst ab Vista. Ich werde 
es auf GetTickCount ändern, dann sollte es auch auf XP funktionieren.

[Günter (galileo14)]

Okay, super, danke. Ich teste es gerne auf XP, wenn du eine neue Version 
zur Verfügung stellst.

[Est Est E. (comvisu)]

Moby schrieb:
> Kompliment! Genau aufs Wesentliche konzentriert!
Danke!

> Das Ganze ist natürlich Win10/64 kompatibel.
Du hast es auf Win10/64 getestet?

> Nun könnte man sich sicher noch viel wünschen:
Nur zu. Es ist für mich ja wichtig zu Wissen wo die Prioritäten liegen, 
einige der Punkte sind auch gut umzusetzen.

> - Bauteil Platzier/Skaliergitter mit Einrasten
Die Pfeiltasten bewegen das Bauteil zum Nächsten Rastpunkt im 
10-Pixel-Raster (bereits implementiert). Das ist ein Kompromiss aus 
Programmieraufwand und Benutzerfreundlichkeit.

> - Hex-Anzeigemöglichkeit wirklich aller Zeichen im Terminal
Ich tendiere gerade eher dazu alle Steuerzeichen abzufangen, da sie für 
das "Protokoll" ja nicht benötigt werden. Hälts du ein vollwertiges 
Terminal für wichtig?

> Schön wäre allerdings die Zusicherung, daß sich am Datenformat der .visu
> nix mehr ändert bzw. ältere Projekte im Fall des Falles immer geladen
> und einfach neu abgespeichert werden können ;-)
Das möcht ich jetzt fast zusichern. Einzelne Eigenschaften können sich 
zwar ändern, das Element wird aber auch dann noch geladen. Die Datei ist 
übrigens lesbar.

> An anderen Stellen hakelt es noch:
> - Änderungen von Bauelementen (Größe) werden oft nicht instantan
> übernommen
Du meinst Abmaße-Breite-Höhe? Bei mir funktioniert es für alle Elemente 
(Win7/64). Kannst du beschreiben, unter welchen Umständen es sich dann 
ändert? Beim nächsten Ändern, Klick auf Hintergrund, etc.?

> - Gefährlich ist ggf. der große Sichern-Button: Ruckzuck ist ein
> bestehendes Projekt überschrieben...
OK, da hab ich aber jetzt keine bessere Idee, höchstens die Reihenfolge 
zu ändern.

[rodnas (Gast)]

Guten Abend allerseits,

also OS ist W7 Ultimate

ich habe jetzt mit Integer probiert, also ohne Komma und Punk.
Gleiches Problem, Terminal und Konsole funktionieren, die Instrumente 
nicht.
Gibt es einen Unterschied zwischen Konsole und Instrumenten bei der 
Auswertung?

[rodnas (Gast)]

fast vergessen: 32Bit

[Est Est E. (comvisu)]

rodnas schrieb:
> Guten Abend allerseits,
>
> also OS ist W7 Ultimate
>
> ich habe jetzt mit Integer probiert, also ohne Komma und Punk.
> Gleiches Problem, Terminal und Konsole funktionieren, die Instrumente
> nicht.

Blinkt das kleine Quadrat denn schwarz-weiß während die Schnittstelle 
verbunden ist?

> Gibt es einen Unterschied zwischen Konsole und Instrumenten bei der
> Auswertung?
Ja, die Konsole wird direkt aus der Schnittstelle raus aufgerufen, die 
Instrumente werden über einen Timer aktualisiert. Deshalb die Frage, mit 
dem blinkenden Kästchen. Auch unterscheidet die Konsole nicht nach 
Zahlenwert und Zeichenkette (keine Umwandlung, da keine Berechnung).

Hast du den manuellen Befehl (in der Menüzeile der Ausführen-Oberfläche) 
mal probiert? Dort wird die Anzeige explizit aktualisiert.

[rodnas (Gast)]

Das kleine Kästchen blinkt, manuelle Triggerung, wie empfohlen, hilft 
nicht weiter nur der manuelle Anteil wird angenommen.

[Est Est E. (comvisu)]

Die Berechnung/Weiterleitung beim Manuellen Befehl wird in gleicher 
Weise durchgeführt, dann scheint was mit der Erkennung nicht zu stimmen. 
Versuch bitte mal einen konstanten Text zu senden, am Besten 
aneinandergereit, damit keine Steuerzeichen darunter sind:

 Print "#10F5;#10F5;#10F5;"

Ob dann was durchkommt... Ich kann mir es echt nicht erklären.

[rodnas (Gast)]

so kommt durch.

Also der Fehler liegt bei mir. Ich muss mir etwas einfallen lassen, wie 
ich die Print Ausgabe formatiere.

[Est Est E. (comvisu)]

Jetzt bin ich aber froh! Von der Ferne ist es ja immer schwierig mit der 
Fehlersuche.

Ab der nächsten Version werde ich Steuerzeichen rausfiltern, dann dürfte 
es kein Problem mehr in dieser Richtung geben.

[rodnas (Gast)]

Es hört sich gut an :-)

[Moby A. (moby-project)]

Est Est E. schrieb:
> Du hast es auf Win10/64 getestet?

Naja erstmal nur oberflächlich...

> Die Pfeiltasten bewegen das Bauteil zum Nächsten Rastpunkt im
> 10-Pixel-Raster (bereits implementiert). Das ist ein Kompromiss aus
> Programmieraufwand und Benutzerfreundlichkeit.

Der reicht fürs Erste auch.

> Ich tendiere gerade eher dazu alle Steuerzeichen abzufangen, da sie für
> das "Protokoll" ja nicht benötigt werden. Hälts du ein vollwertiges
> Terminal für wichtig?

Eine einschaltbare Hex-Anzeige wär praktisch um ggf. dem 
realen/fehlerhaften Output seines MC-Systems gleich nachspüren zu 
können. OK, Luxus.

> Du meinst Abmaße-Breite-Höhe? Bei mir funktioniert es für alle Elemente
> (Win7/64). Kannst du beschreiben, unter welchen Umständen es sich dann
> ändert? Beim nächsten Ändern, Klick auf Hintergrund, etc.?

Ja. Zuweilen bleibt der erweiterte Bereich eine Weile schwarz, erst beim 
nächsten Ändern (z.B. Text sichtbar machen) erscheint das Element dann 
vollständig. Ein Phänomen gleichermaßen unter Win7/10-64- und ein 
kosmetisches Problem.

[Est Est E. (comvisu)]

Moby A. schrieb:
> Zuweilen bleibt der erweiterte Bereich eine Weile schwarz,
Das ist natürlich nicht schön. Ich kümmer mich darum.

[ich (Gast)]

Kann man irgendwie die minimal mögliche Abtastrate anzeigen lassen?

[Est Est E. (comvisu)]

Bei den Diagrammen ist die kleinste einstellbare Periodendauer 0.01 
Sekunden. Gibt man einen kleineren Wert ein, dann wird er automatisch zu 
0,01 geändert.
Die tatsächliche Abtastung ist allerdings ein klein wenig höher, das 
liegt an der Tasksverteilung in Windows. Bei mir sind das etwa 13ms. Die 
Abtastzeitpunkte werden mit aufgezeichnet, sodass man den Zeitpunkt im 
Diagramm sieht (einfach reinzoomen).
Die Digital und Analoganzeige wird fest alle 0,4 Sekunden aktualisiert, 
so kann man die Anzeige auch dann noch lesen, wenn sehr schnell Werte 
vom Mikrocontroller geschickt werden.

[Est Est E. (comvisu)]

@Moby: Habs jetzt auch noch auf Win10 Pro,64bit, getestet und das von 
dir beschriebene Problem tritt bei mir nicht auf. Ist das bei dir bei 
allen Anzeigen und ab dem ersten, oder ist es erst nach einer Zeit 
aufgetreten?
Hast du dein System nativ laufen oder virtualisiert?

Edit: Beim Öffnen einer Datei und beim Hinzufügen eines Instruments wird 
dieses gleich richtig angezeigt?

[rodnas (Gast)]

Moby schreibt:

>Ja. Zuweilen bleibt der erweiterte Bereich eine Weile schwarz, erst beim
>nächsten Ändern (z.B. Text sichtbar machen) erscheint das Element dann
>vollständig. Ein Phänomen gleichermaßen unter Win7/10-64- und ein
>kosmetisches Problem.

Bei mir kommt es ebenfalls vor und bei Neupositionierung verschwindet.
Ausnahmslos bei Größenänderung.

Mir ist aufgefallen, das beim Trennen und danach Verbinden, ein MC Reset 
gemacht wird.

[Est Est E. (comvisu)]

Das ist schon seltsam, bei mir gibt es auf Vista, 7, 8.1 und 10 jeweils 
keine Probleme in der Richtung.
Nur zu verschieben reicht schon aus, dass die schwarzen Bereiche 
verschwinden?

Im Anhang eine angepasste Version, ich vermute zwar dass es genauso 
rauskommt, aber es ist ein Versuch wert (Bitte um Rückmeldung).

Desweiteren werden jetzt Steuerzeichen als Leerzeichen interpretiert. Im 
Terminal sieht man dadurch, dass zusätzliche Zeichen da sind, die 
Auswertung sollte aber trotzdem möglich sein.
@rodnas: Teste bitte nochmal mit deinem Print wie am Anfang.
Zum Reset kann ich dir nichts sagen, das kann man von Softwareseite aus 
nicht steuern.

@Günter R.: Die Gettickcount64-Funktion habe ich ersetzt, du kannst es 
unter XP also nochmals probieren.

[rodnas (Gast)]

Fiat Lux! Und es ward Licht. :-)

Es funktioniert !!!!!!!!!! V.031

Syntax: Print "#10F" ; Probe ; ";"

Danke Est Est Est :-)

Jetzt Feintuning

[Kaj (Gast)]

rodnas schrieb:
> Mir ist aufgefallen, das beim Trennen und danach Verbinden, ein MC Reset
> gemacht wird.
Hört sich nach Arduino-Boards an? Da ist das mehr oder minder "normal".

[Jonas G. (jstjst)]

Prinzipiell toll das es ein neues Programm gibt.
Aber wieder nur für Windows :(

Hat das jemand schon mal mit wine probiert?

Jonas

[rodnas (Gast)]

Kaj schrieb:

Hört sich nach Arduino-Boards an? Da ist das mehr oder minder "normal".

Board UNO Original
Gibt es eine Erklärung dazu?

[Jonas G. (jstjst)]

Hab gerade in wikipedia gelesen, dass Lazarus auch für Linux kompilieren 
kann?

Kann jemand was dazu schreiben der sich damit auskennt?

Gruß Jonas

[Est Est E. (comvisu)]

Jonas G. schrieb:
> Hab gerade in wikipedia gelesen, dass Lazarus auch für Linux kompilieren
> kann?

Ja, Lazarus ist auch für Linux verfügbar. Ich hab es bisher aber nicht 
versucht, es mangelt mir an einem Linuxrechner. Auf einer virtuellen 
Maschine bin ich beim Installieren von Lazaurus gescheitert. Darüber 
hinaus sind auch nicht unbedingt alle Bibliotheken linuxkompatibel, d.h. 
es sind dann Anpassungen nötig. Ich kann also nichts versprechen, und 
vorerst ist nicht mit einer Linuxversion zu rechnen.

[Jens (Gast)]

rodnas schrieb:
> Kaj schrieb:
>
> Hört sich nach Arduino-Boards an? Da ist das mehr oder minder "normal".
>
> Board UNO Original
> Gibt es eine Erklärung dazu?

Gibt es: Das Öffnen des Ports schaltet DTR (ich meine auf GND) und das 
Signal steuert über einen Kondensator die Reset-Leitung des Prozessors.

Grund ist der Bootloader, der auf diese Weise startet und für ein paar 
Sekunden auf Daten wartet...

Gruß
Jens

[Kaj (Gast)]

[Offtopic]
Jonas G. schrieb:
> Hab gerade in wikipedia gelesen, dass Lazarus auch für Linux kompilieren
> kann?
>
> Kann jemand was dazu schreiben der sich damit auskennt?
Einfach deine Paketverwaltung befragen. Sieht bei mir so aus:

$ yaourt Lazarus
1 community/fpc-src 3.0.0-1 [installed]
    Sources for the FreePascal compiler (required by the Lazarus IDE)
2 community/lazarus 1.6.0-1 [installed]
    Delphi-like IDE for FreePascal common files
3 community/lazarus-gtk2 1.6.0-1
    Delphi-like IDE for FreePascal gtk2 version
4 community/lazarus-qt 1.6.0-1
    Delphi-like IDE for FreePascal qt version

Und wenn du auf die Seite von Lazarus gehst http://www.lazarus-ide.org/
dann findest du oben rechts auch was, siehe Bild!
Oder du schaust einfach mal ins Wiki: 
http://wiki.freepascal.org/Installing_Lazarus/de#Installation_von_Lazarus_unter_Linux

rodnas schrieb:
> Board UNO Original
> Gibt es eine Erklärung dazu?
Ziemlich gut lässt sich das anhand von FreeBSD/Linux erklären:
Unter Linux melden sich die Arduino-Kisten als ttyACM -> Also als 
Modem! Das ist an und für sich nicht weiter schlimm, sorgt aber dafür, 
das Treiber bedingt, beim schließen des Ports ein Commando gesendet 
wird, was das setzen von DTR auf LOW emuliert und der Arduino damit 
einen Reset ausführt. Das ist halt historisch bedingt, da man ja zu 
damaliger zeit noch auf die Telefonrechnung achten musste. Flatrates gab 
es damals nicht ;)

Das setzen von DTR verwendet z.B. auch die Arduino-IDE um einen 
Software-Reset auszuführen, um das Board in den Bootloader-Modus zu 
bringen.

AutoReset is a feature that allows you to upload the compiled sketch to
the Arduino board without pressing the reset switch. The way it works is
by sending a reset signal (GND) to the reset pin using the DTR signal on
the RS-232 interface.

Beim Arduino Due passiert das über das einmalige öffnen und wieder 
schließen der seriellen Schnittstelle mit 1200 Baud. Dann ist das Board 
im Bootloader-Modus und kann über die Arduino-IDE bzw. mit BOSSAC 
geflasht werden.

Aber schau doch mal, ob das vielleicht hilft:
http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection
[/Offtopic]

[Jonas G. (jstjst)]

OK vielleicht teste ich das mal dieses Wochenende.
Aber PC Programmierung ist echt nicht mein Gebiet. Ich scheitere 
meistens schon wenn ich ein Programm selbst kompilieren muss.

Gruß Jonas

[rodnas (Gast)]

Ich kann nicht zwei Digitalanzeige bzw. Analoganzeige parallel 
betreiben.
Immer nur ein von der unterschiedlichen Kanäle wird angezeigt.

Digitalanzeige 1 und Analoganzeige 1 beschaltet mit # 20 funktioniert
Digitalanzeige 2 und Analoganzeige 2 beschaltet mit # 50 ohne Funktion

Die Kanäle sind gleichwertig. Beim Tauschen ist die Sachlage umgekehrt.

Je nach Sorte ist nur eine Anzeige freigeschaltet?

[Jonas G. (jstjst)]

Hallo,

wenn du mir die den Code zu Verfügung stellst würde ich es mal versuchen 
eine Linux Version zu basteln.

Gruß Jonas

[Est Est E. (comvisu)]

rodnas schrieb:
> Ich kann nicht zwei Digitalanzeige bzw. Analoganzeige parallel
> betreiben.
> [...]
> Je nach Sorte ist nur eine Anzeige freigeschaltet?

Nein, es gibt keine absichtlichen Beschränkungen, das verspreche ich! 
Ich kann die Fehlfunktion auf meinem Rechner auch nicht nachvollziehen. 
Wenn ich nach deiner Beschreibung vier Elemente platziere, 2x Analog (je 
Kanal #20 und #50), 2x Digital (#20+#50) und zwei Befehle sende #20F13; 
und #50F14; (z.B.), dann reagieren die Anzeigen auch wie erwartet.

Geht bei dir immer die zweitplatzierte Anzeige nicht, habe ich das 
Richtig verstanden? Und am Sender auf Mikrocontrollerseite änderst du 
nichts?
Kannst du bitte ein paar Screenshots machen?


@Jonas: Ich versuch es bei Zeit selbst mal, wird aber noch dauern.

[ich (Gast)]

Kann man iwie eine art look up table integrieren?

ansonsten gefällt mir das programm gut:)

[Est Est E. (comvisu)]

ich schrieb:
> Kann man iwie eine art look up table integrieren?

Kannst du das etwas konkretisieren?
Man sendet den Index einer Tabelle an die Comvisu und diese antwortet 
mit dem Tabellenwert auf dem gleichen Kanal? Meinst du soetwas in der 
Art? Die Frage ist dann, wie füttert man die Tabelle, händisch im 
Eigenschafteneditor (Bearbeiten-Oberfläche)?

[ich (Gast)]

Nein, sondern wenn man komplexe Messwerte hat und diese quasi live am PC 
berechnen und anzeigen lassen möchte z. B. bei hochgradig unstetigen 
Kennlinien.

Mal ein simples Beispiel, bloß damit du weißt was ich meine: 
Temperaturmessung Pt1000, µC sendet einen ADC Wert -> Ohmsches Gesetz -> 
Widerstand (das geht noch mit deinem Programm) -> Zuordnung des 
empfangenen Wertes über eine Tabelle -> Anzeige des zugeordneten Wertes 
(z. B. Temperatur)

[ich (Gast)]

Ergänzung: wie fütter ich die Tabelle: Ideal wäre natürlich, wenn man 
die vorher aus einer csv Datei oä. reinlädt

[rodnas (Gast)]

Ich glaube, die Lösung des Problems gefunden zu haben. Der erste Print 
Befehl wird ignoriert. ??? Doppelt gesendet kommt aber an. Ich habe die 
Reihenfolge auch geändert, hat nicht genützt. Also zuerst doppelt 
senden! Jedenfalls bei mir.

Test geht weiter :)

[K. L. (Gast)]

Nicht übel, sprach der Dübel. Man sollte es aber ins WIKI schieben und 
nur eine Softwareversion online haben.

[heinblöd (Gast)]

Wer zum Henker benutzt serielle Schnittstelle freiwillig unter Winblöd?

Ich hatte für mein Projekt kst2 benutzt, bei 1Mbit UART und 100% 
Auslastung frisst das aber Unmengen an RAM und wird auch wenig träge..

Wäre interessant ob dieses Programm mit 5kHz Datenrate problemlos läuft.

[Est Est E. (comvisu)]

ich schrieb:
> Mal ein simples Beispiel, bloß damit du weißt was ich meine:
> Temperaturmessung Pt1000, µC sendet einen ADC Wert -> Ohmsches Gesetz ->
> Widerstand (das geht noch mit deinem Programm) -> Zuordnung des
> empfangenen Wertes über eine Tabelle -> Anzeige des zugeordneten Wertes
> (z. B. Temperatur)
Prinzipiell hört sich das interessant an. Die Implementierung ist 
allerding aufwendig. Bei der Verwendung bräuchte man dann eine Funktion, 
z.B. "LUT1(12)", die Tabelle selbst wäre an anderer Stelle zu 
definieren.
Deinen Vorschlag behalte ich im Hinterkopf. Wie gesagt, der Aufwand...

rodnas schrieb:
> Ich glaube, die Lösung des Problems gefunden zu haben. Der erste Print
> Befehl wird ignoriert.
Das schau ich mir an und Berichte dann wieder.

Klaus L. schrieb:
> Nicht übel, sprach der Dübel.
Danke:-)

> Man sollte es aber ins WIKI schieben und
> nur eine Softwareversion online haben.
Das Problem mit den Softwareversionen sehe ich auch. Andererseits möchte 
ich auch den Usern das Programm ohne Umwege zur Verfügung stellen, der 
Direkte Weg ist eben hier im Thread. Vielleicht findet sich ja ein 
Moderator, der ab und zu die alten Versionen rausnimmt. Es ins Wiki zu 
bringen ist auf jeden Fall eine Überlegung wert.

heinblöd schrieb:
> Wer zum Henker benutzt serielle Schnittstelle freiwillig unter Winblöd?
Ich und viele Andere:-)

> Ich hatte für mein Projekt kst2 benutzt, bei 1Mbit UART und 100%
> Auslastung frisst das aber Unmengen an RAM und wird auch wenig träge..
> Wäre interessant ob dieses Programm mit 5kHz Datenrate problemlos läuft.
5kHz sind natürlich nicht wenig. Ich habe schon mal Daten mit hoher Rate 
geschickt und einen Zähler laufenlassen, was bei der Anzeige ankommt. 
Ich erinner mich nicht mehr genau an die Werte, aber es waren etwa ein 
paar Tausend Befehle pro Sekunde. Das war aber auf nur einer Anzeige. 
Verwendet man einen Kanal in mehreren Elementen, dann erhöht sich 
natürlich der Zeitbedarf für jeden Befehl. Weitere tests stehen noch 
aus.
Es ist klar dass dieses Programm kein Oszilloskop ersetzt, das ist auch 
gar nicht das Ziel.
Es soll ein Werkzeug sein in erster Linie für die Entwicklung und für 
Laboranwendungen. Die Maxime ist einfache und schnelle 
Konfigurierbarkeit und Flexibilität.

[Moby A. (moby-project)]

Est Est E. schrieb:
> Prinzipiell hört sich das interessant an. Die Implementierung ist
> allerding aufwendig. Bei der Verwendung bräuchte man dann eine Funktion,
> z.B. "LUT1(12)", die Tabelle selbst wäre an anderer Stelle zu
> definieren.
> Deinen Vorschlag behalte ich im Hinterkopf. Wie gesagt, der Aufwand...

Wenn ich was vorab zu berechnen bzw. an Werten vorzuverarbeiten habe 
kann ich das doch in meinem Zulieferer, also meinem MC-System machen... 
So eine Com-Visualisierung sollte ihrem Namen entsprechend nur 
visualisieren, was an reinem Com-Input kommt- und das gut. Alles andere 
wird schnell uferlos.

> Es soll ein Werkzeug sein in erster Linie für die Entwicklung und für
> Laboranwendungen. Die Maxime ist einfache und schnelle
> Konfigurierbarkeit und Flexibilität.

[Meister (Gast)]

Da gehtes bei komplizierten Rechnungen manchmal Platzund Taktmäßig nicht

[Est Est E. (comvisu)]

Moby A. schrieb:

> So eine Com-Visualisierung sollte ihrem Namen entsprechend nur
> visualisieren, was an reinem Com-Input kommt- und das gut. Alles andere
> wird schnell uferlos.
Naja, es soll auch die Möglichkeit geben, Berechnungen, die auf dem µC 
mit hohem Aufwand verbunden sind, oder wo das Rumprobieren und Ändern 
von Werten zeitintensiv ist, in die Comvisu auszulagern. Deshalb ist ja 
auch der Formelparser eingebaut, so kann man Rohdaten schicken und 
trotzdem eine saubere Anzeige bieten. Für mich ist der 
Programmieraufwand natürlich relevant und so wird es immer Kompromisse 
geben. Die zweite Einschränkung ist das Ziel, die Komplexität auf 
Benutzerseite so gering wie möglich zu halten. Dadurch muss man auch auf 
Funktionalität verzichten. Moby, dir gehts ja auch genau darum, oder?
Beispielsweise hatte ich ursprünglich die Möglichkeit eingebaut die 
Ergebnisse aus anderen Elementen über dessen Name in der Formel zu 
verwenden, also wie eine Variable. Dadurch kann man komplizierte Formeln 
in mehrere Teile aufsplitten (Vorteil). Das Problem dabei ist die 
Triggerung der Neuberechnung, insbesondere wenn auch noch die gleichen 
Eingangskanäle verwendet werden. Verzichtet man auf eine automatische 
Triggerung, dann wird es Probleme mit der Berechnungsreihenfolge geben 
und es wird für den Benutzer wenig intuitiv. -> Gestrichen

[Moby (Gast)]

Est Est E. schrieb:
> Die zweite Einschränkung ist das Ziel, die Komplexität auf
> Benutzerseite so gering wie möglich zu halten. Dadurch muss man auch auf
> Funktionalität verzichten. Moby, dir gehts ja auch genau darum, oder?

Genau darum. Im Augenblick schaut die Sache noch schön rund und einfach 
aus. Statt großartig komplexen Manipulationsmöglichkeiten mit dem 
Daten-Input wär mir für meinen Anwendungsfall eher an einem 
professionell darstellenden Instrumentarium mit vielen verschiedenen 
Ansichtsmöglichkeiten gelegen. Andererseits, warum sollte man 
Funktionalität, die stark nachgefragt wird und die sich ohne großen 
Aufwand einbauen lässt nicht anbieten. Insofern bleibt die Qual der Wahl 
natürlich beim Programm-Autor ;-)

Noch eine kurze Frage: Im Ausführen-Modus lassen sich ja Befehle manuell 
und gezielt an einzelne Kanäle vs. Instrumente schicken. Die Diagramme 
reagieren aber nicht !?

[Est Est E. (comvisu)]

Moby schrieb:
> Andererseits, warum sollte man
> Funktionalität, die stark nachgefragt wird und die sich ohne großen
> Aufwand einbauen lässt nicht anbieten. Insofern bleibt die Qual der Wahl
> natürlich beim Programm-Autor ;-)
Ja, es wird sich noch zeigen, in welche Richtung es geht~

> Noch eine kurze Frage: Im Ausführen-Modus lassen sich ja Befehle manuell
> und gezielt an einzelne Kanäle vs. Instrumente schicken. Die Diagramme
> reagieren aber nicht !?
Die (Zeit-!)Diagramme tasten ihren eigenen Speicher zyklisch ab. Wenn 
beim abhängigen Kanal ein neuer Wert eingeht, wird die Neuberechnung 
ausgelöst und das Ergebnis in den Speicher des Diagramms geschrieben. 
Das Diagramm kennt ja den Zeitpunkt der Datenübermittlung nicht. Der 
manuelle Befehl hat auf das Diagramm auch seine Auswirkung, nur siehst 
du diese nicht wenn die Aufzeichnung nicht läuft. Dazu muss die 
Schnittstelle verbunden sein. Ich habe auch schon an einen Art 
Offline-Modus gedacht, unter dem die Abtastung dann gestartet wird. Aber 
es gibt so viel, was man  machen könnte...

Edit und PS: Tritt seit der letzten Version das Problem mit den 
schwarzen Bereichen bei Größenänderung noch auf?

[rodnas (Gast)]

Ja, bei der Grössenänderung.

[rodnas (Gast)]

Ein Vorschlag:

Wäre nicht schlecht die Leds Grundfarbe auch individuell einstellen zu 
können.

[Moby (Gast)]

Est Est E. schrieb:
> Dazu muss die
> Schnittstelle verbunden sein.

OK, dann funktionierts auch mit manueller Eingabe ;-)

Die Diagramme sind ja mit Zoom und Achsenverschiebung wirklich schon 
sehr praktisch. Schön wäre es, wenn man während der Ausführung bzw. 
"verbunden"en Aufzeichnung schon in aller Ruhe in der Vergangenheit 
wühlen kann und die Anzeige erst beim Links-Click wieder zur 
gegenwärtigen laufend aktualisierenden Darstellung zurückkehrt- oder 
wenigstens automatisch erst dann, wenn ein paar Sekündchen keine 
Mausoperationen im Diagrammbereich mehr festzustellen sind.

Die Aufzeichnung und das manuelle Verschieben von Zeit- und Werteachse 
sollte nur im vorab definierten Bereich möglich sein.

Auf jeden Fall bist Du diagramm-funktionell der Konkurrenz schon 
meilenweit voraus. Das ist erstmal wichtiger als diagramm-optisch ;-)

Bezügl. der schwarzen Bereiche bei Größenänderung kann ich auch noch 
keine Verbesserung vermelden.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Moby schrieb:
> Auf jeden Fall bist Du diagramm-funktionell der Konkurrenz schon
> meilenweit voraus. Das ist erstmal wichtiger als diagramm-optisch ;-)

Ach Moby, dann schau Dir das beigefügte Beispiel für das kommende 
SerialComInstruments Version 4 mal an.
Da ist Verschieben (Zeit- und Y-Achse) natürlich auch während der 
laufenden Erfassung möglich. Das Instrument Design entspricht dem 
industrieüblichen Standard. Beim Verschieben der Graphik mit der Mouse 
treten keinerlei Rundungsfehler und damit krumme Achsskalierungen auf.
Die Achsen sind skalierbar (X-Achse wahlweise Milli-Sekunden, Sekunden, 
Minuten, Stunden oder Tage, die Y-Achsen optional logarithmisch), auch 
während des laufenden Online Betriebs. Maximal können bis zu 50.000 
Werte pro Sekunde dargestellt werden.

Im übrigen können in der kommenden Version alle Instrumente beliebig oft 
plaziert werden, umfangreich mathematische Verknüpfungen sind möglich 
usw.
Mehr dazu in meinem Thread:
Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"

Gruss
Ulrich Albert

[Kaj G. (Firma: RUB) (bloody)]

Ist nicht böse gemeint, aber ich frage mich ernsthaft, warum man in 
zeiten von GitHub, Bitbucket, und Co. immernoch ein Programm von Hand 
per zip-Datei verteilt. Bei Github gibts sogar ein Wiki und 
Issue-Tracker gratis dazu. Und das du deinen Code veröffentlichen musst 
(wenn du das nicht willst), wäre mir auch nicht bekannt.
Und über die Versionskontrolle kann auch jeder eine Art Changelog sehen 
und jeder könnte sich, wenn er will, auch noch eine ältere Version des 
Programms holen, um z.B. vergleiche zu machen.

Und ich glaube, das mikrocontroller.net sogar einen SVN-Server betreibt, 
den man auch nutzen könnte...
Beitrag "Hinweis: Artikelsammlung"

[F. F. (foldi)]

Est Est E. schrieb:
> Du hast es auf Win10/64 getestet?

Auf Windows10/64bit getestet. Rückgabewerte vom DS18B20 im Terminal auf 
COM4. Hat gut funktioniert.
Werde ich, wenn ich das effektiv nutzen kann, richtig testen und hier 
berichten.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

Moby schrieb:
> Auf jeden Fall bist Du diagramm-funktionell der Konkurrenz schon
> meilenweit voraus. Das ist erstmal wichtiger als diagramm-optisch ;-)

Hallo Moby, hier noch mal das obige Beispiel nun mit Panning und 
Zooming. Ich hoffe das revidiert Deine Meinung :)

Gruss Ulrich Albert

[Moby A. (moby-project)]

Albert M. schrieb:
> Hallo Moby, hier noch mal das obige Beispiel nun mit Panning und
> Zooming. Ich hoffe das revidiert Deine Meinung :)

Hallo Albert, danke für den vielversprechenden Ausblick, das war aber 
jetzt keine Meinung sondern nur die Feststellung des gegenwärtig 
verfügbaren Funktions-Stands... Ich freue mich, wenn die 
Weiterentwicklung und Auflösung unnötiger Beschränkungen Deines 
Programms wieder Fahrt aufnimmt- nur sollte sich jeder Thread fortan 
wirklich auf die Diskussion seines Programms beschränken ;-)

[Est Est E. (comvisu)]

rodnas schrieb:
> Ja, bei der Grössenänderung.
Nochmal die Frage: Reicht es aus, das Element zu verschieben, wie du 
gesagt hast? Oder musst du einzelne Werte ändern oder in die 
Ausführen-Oberfläche wechseln?

rodnas schrieb:
> Wäre nicht schlecht die Leds Grundfarbe auch individuell einstellen zu
> können.
Ich habe sowieso vor die LED in eine Mehrfarben-LED zu ändern, für den 
Wert Null kann man dann auch selbst eine Farbe bestimmen.


Moby schrieb:
> Est Est E. schrieb:

> Die Diagramme sind ja mit Zoom und Achsenverschiebung wirklich schon
> sehr praktisch. Schön wäre es, wenn man während der Ausführung bzw.
> "verbunden"en Aufzeichnung schon in aller Ruhe in der Vergangenheit
> wühlen kann und die Anzeige erst beim Links-Click wieder zur
> gegenwärtigen laufend aktualisierenden Darstellung zurückkehrt-
Da hast du recht, es ist echt ärgerlich, wenns einem den Zoom wieder 
klaut. Ich habs mir gerade angeschaut, es scheint gut machbar zu sein.

> Die Aufzeichnung und das manuelle Verschieben von Zeit- und Werteachse
> sollte nur im vorab definierten Bereich möglich sein.
Die Aufzeichnung möchte ich eigentlich nicht beschränken. Wenn das 
angegebene Zeitfenster abgelaufen ist, dann sollte ja schon weiter 
aufgezeichnet werden. Auch auf der Werteachse halte ich eine 
Einschränkung für keine so gute Idee. Das ist ja gerade das Schöne, dass 
man Daten, die in einem falsch angegebenen Fenster aufgenommen wurden, 
nicht nochmals Aufnehmen muss. Man kann ja sogar nachträglich das 
Fenster auf seine Wünsche anpassen.
Was aber zu diskutieren wäre, ist, was man bei langen Aufzeichnungen 
(z.B. Heizungssteuerung) mit alten Werten macht. Ich denke es wäre 
besser nach (z.B.) 50.000 Werten alte Werte zu verwerfen und trotzdem 
weiter aufzuzeichnen anstatt die Aufzeichnung abzubrechen.

Beim Verschieben wäre der eingeschränkte Bereich sicherlich sinnvoller. 
Das umzusetzen ist aber nicht ganz einfach. Man müsste das Verschieben 
dann zwischen dem Ursprung und den maximalen Werten erlauben. Dann wird 
man noch einen Rand vorsehen müssen. OK- ich habs mir notiert, das ist 
aber sicher erstmal keine Priorität.

> Auf jeden Fall bist Du diagramm-funktionell der Konkurrenz schon
> meilenweit voraus. Das ist erstmal wichtiger als diagramm-optisch ;-)
:-)

> Bezügl. der schwarzen Bereiche bei Größenänderung kann ich auch noch
> keine Verbesserung vermelden.
Das ist ein ganz wichtiger Punkt! Gleiche Frage wie an Rodnas: Welche 
Aktion bewirkt, dass der schwarze Bereich verschwindet? Reicht ein 
Verschieben des Elements aus, oder sind andere Maßnahmen nötig? Beim 
Laden einer Datei und beim Platzieren von neuen Elementen werden diese 
gleich richtig angezeigt?


Kaj G. schrieb:
> Ist nicht böse gemeint, aber ich frage mich ernsthaft, warum man in
> zeiten von GitHub, Bitbucket, und Co. immernoch ein Programm von Hand
> per zip-Datei verteilt.
Naja, das ist Neuland für mich. Auch wenn die Einarbeitung trivial ist 
(k.A.), ist es eben noch eine neue Baustelle. Die Problematik, dass die 
Versionen durch den Thread durch wild verstreut sind, ist mir klar. 
Siehs als Übergangslösung~

> Und ich glaube, das mikrocontroller.net sogar einen SVN-Server betreibt,
> den man auch nutzen könnte...
> Beitrag "Hinweis: Artikelsammlung"
Danke für den Link! Es scheint also durchaus erwünscht zu sein, einen 
Wikiartikel für das eigene Programm aufzumachen.


F. F. schrieb:
> Auf Windows10/64bit getestet. Rückgabewerte vom DS18B20 im Terminal auf
> COM4. Hat gut funktioniert.
> Werde ich, wenn ich das effektiv nutzen kann, richtig testen und hier
> berichten.
Danke für die Rückmeldung!
Du hast bisher nur das Terminal verwendet? Du hattest schon einen 
Mikrocontroller noch dazwischen, oder?

Grüße

[rodnas (Gast)]

Der Ablauf sieht so aus. Sinngemäß 1 Startanzeige; 2 Größenänderung; 3 
Umgeschaltet oder mit der Maus neu positioniert.
Gespeicherte Datei wird sofort korrekt Dargestellt. Nachträgliche 
Korrektur bringt das Problem erneut mit. Im Grunde genommen ist es kein 
Störfaktor mehr für mich.

[Moby A. (moby-project)]

Est Est E. schrieb:
> Die Aufzeichnung möchte ich eigentlich nicht beschränken.

Das will ich weiß Gott auch nicht- wenn für die Zeitachse aber ein Ende 
vorgesehen ist sollte dieses auch eingehalten werden, um eine 
Aufzeichnung auch automatisch stoppen lassen zu können. Ansonsten wäre 
für ein offenes Ende der Endwert einfach offen zu lassen !?

Stichwort Zeitachse: Wie schaut es hier mit aktuellen Zeitangaben inkl. 
Datum aus? Wenn der Diagrammdarstellung noch was fehlt dann vor allem 
das... ;-)

Der Start des Programms sollte mit dem aktuellen Default-Projekt 
erfolgen.

> Reicht ein
> Verschieben des Elements aus, oder sind andere Maßnahmen nötig?

Ja das reicht aus. Der schwarze Bereich erscheint bei mir übrigens immer 
nur dann, wenn man nach der Elementvergrößerung in den freien 
Oberflächenbereich und nicht direkt ins Element klickt. Analog bei 
Elementverkleinerung: wohl prinzipiell derselbe Fehler, nur hier in Form 
eines abgeschnittenen Diagramms.

> Beim Laden einer Datei und beim Platzieren von neuen Elementen werden diese
> gleich richtig angezeigt?

Ja

[Kaj G. (Firma: RUB) (bloody)]

Est Est E. schrieb:
> Naja, das ist Neuland für mich. Auch wenn die Einarbeitung trivial ist
> (k.A.), ist es eben noch eine neue Baustelle.
Okay, dann hab ich nichts gesagt :)

[rodnas (Gast)]

Vorschlag: die Möglichkeit in der Analoganzeige auch den Digitalwert 
darzustellen.

[rodnas (Gast)]

Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die noch freie 
Kanäle aufzulisten.

[rodnas (Gast)]

Vorschlag:  Verschieben eines Objekts frei nach vorne oder nach hinten.

[Moby A. (moby-project)]

rodnas schrieb:
> Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die noch freie
> Kanäle aufzulisten.

Nein, nicht die freien, sondern die schon belegten! Bei bis zu 999 
Kanälen könnte so eine automatische Doku sehr hilfreich sein! Gute Idee!

Für überflüssig halte ich (bitteschön, nur meine Meinung) die Angabe der 
Farben als Hex-Code.

[rodnas (Gast)]

Moby AVR schrieb: Nein, nicht die freien, sondern die schon belegten!

Ich stimme zu!

Vorschlag: Option, Led blinken lassen

[Est Est E. (comvisu)]

rodnas schrieb:
> Der Ablauf sieht so aus. Sinngemäß 1 Startanzeige; 2 Größenänderung; 3
> Umgeschaltet oder mit der Maus neu positioniert.
Danke für die Screenshots! Die Details sind für mich sehr wichtig.


Moby A. schrieb:
>> Reicht ein
>> Verschieben des Elements aus, oder sind andere Maßnahmen nötig?
>
> Ja das reicht aus. Der schwarze Bereich erscheint bei mir übrigens immer
> nur dann, wenn man nach der Elementvergrößerung in den freien
> Oberflächenbereich und nicht direkt ins Element klickt.
Was passiert wenn du den geänderten Wert mit Enter bestätigst? Hier 
sollte die Größe direkt angepasst werden. Erscheint die schwarze Fläche 
in diesem Fall? Oder erst bei Klick irgendwohin?

> Wenn für die Zeitachse aber ein Ende
> vorgesehen ist sollte dieses auch eingehalten werden, um eine
> Aufzeichnung auch automatisch stoppen lassen zu können. Ansonsten wäre
> für ein offenes Ende der Endwert einfach offen zu lassen !?
Die Werte der Zeitachse bstimmen ja nur das Anzeigefenster. Ist die Zeit 
erreicht, dann wird die Anzeige verschoben in den neuen Abschnitt. 
Denkbare wäre, diese Automatik optional abschaltbar zu machen. Auch 
könnte ich mir einen weiteren Eingang (Steuereingang) für einen 
Anzeigereset vorstellen, nützlich für zyklische Messungen 
beispielsweise. Ansonsten wüsste ich nicht, warum man der Aufzeichnung 
eine Maximalzeit geben sollte, solange die Schnittstelle aktiv ist. Ich 
würde das Thema gerne zurückstellen, ich denke es gibt momentan 
wichtigeres~

> Stichwort Zeitachse: Wie schaut es hier mit aktuellen Zeitangaben inkl.
> Datum aus? Wenn der Diagrammdarstellung noch was fehlt dann vor allem
> das... ;-)
Das seh ich ein, ist notiert.

> Der Start des Programms sollte mit dem aktuellen Default-Projekt
> erfolgen.
Ja, ich weiß. Dafür brauch ich aber ne neue Datei, das ist ja nicht in 
den Projektdateien zu speichern. Hier brauchts noch Geduld~

[Est Est E. (comvisu)]

rodnas schrieb:
> Vorschlag: die Möglichkeit in der Analoganzeige auch den Digitalwert
> darzustellen.
Das möchte ich eigentlich nicht. Du kannst dir ja einfach eine 
Digitalanzeige dazulegen. Den Rahmen kann man übrigens mit Breite= 0 
deaktivieren.

rodnas schrieb:
> Vorschlag:  Verschieben eines Objekts frei nach vorne oder nach hinten.
Das hab ich auch schon länger im Hinterkopf.

rodnas schrieb:
> Moby AVR schrieb: Nein, nicht die freien, sondern die schon belegten!
> Ich stimme zu!
Auch das ist eine gute Sache.

> Vorschlag: Option, Led blinken lassen
Wäre ein neues Element, sehe ich jetzt nicht als Priorität.


Moby A. schrieb:
> Für überflüssig halte ich (bitteschön, nur meine Meinung) die Angabe der
> Farben als Hex-Code.
Das ist dazu gedacht Farben (auch exotische) einfach kopieren zu können. 
Nachdem es schon implementiert ist, stellt es keinen Programmieraufwand 
mehr dar. Es stört aber nicht, nehme ich an?

[Moby A. (moby-project)]

Est Est E. schrieb:
> Was passiert wenn du den geänderten Wert mit Enter bestätigst? Hier
> sollte die Größe direkt angepasst werden. Erscheint die schwarze Fläche
> in diesem Fall?

Nein. Enter verhindert das auch!

> warum man der Aufzeichnung
> eine Maximalzeit geben sollte, solange die Schnittstelle aktiv ist. Ich
> würde das Thema gerne zurückstellen,

Kein Problem.

> Ja, ich weiß. Dafür brauch ich aber ne neue Datei, das ist ja nicht in
> den Projektdateien zu speichern. Hier brauchts noch Geduld~

Eine neue Datei? Nicht unbedingt, wenn das Default-Projekt mit einem 
bestimmten Namen im Programmverzeichnis erwartet wird...

> Das ist dazu gedacht Farben (auch exotische) einfach kopieren zu können.

Ach so. Also ich brauchs nicht. Die direkte Farbauswahl aus einem 
begrenzten Vorrat (so ein Diagramm enthält ja nicht viele Kurven) ist 
doch viel intuitiver. Stört aber nicht, lass Dich davon nicht aufhalten. 
Mein Ansinnen ist stets, die Dinge möglichst einfach, intuitiv und 
übersichtlich zu halten ;-)

[rodnas (Gast)]

Est Est Est schrieb:

rodnas schrieb:
> Vorschlag:  Verschieben eines Objekts frei nach vorne oder nach hinten.
Das hab ich auch schon länger im Hinterkopf.

Das bringt die Lösung für viele Darstellungsmöglichkeiten.

[F. F. (foldi)]

Est Est E. schrieb:
> Du hattest schon einen
> Mikrocontroller noch dazwischen, oder?

Schrieb ich doch. Die Ausgabe vom Arduino (ATmega328) über usb (auf 
COM4) auf das Terminal.

[rodnas (Gast)]

Erste UDP Versuch fehlgeschlagen :(

PC              192.168.0.102:6001

Modul           192.168.0.7:20108

Subnet Mask     255.255.255.0

Default Gateway 192.168.0.1

Ist egal wie das Modul als UDP Server oder Client konfiguriert.

[rodnas (Gast)]

Verbindung wird angezeigt, Pünktchen blink fleißig.

[Est Est E. (comvisu)]

F. F. schrieb:
> Schrieb ich doch. Die Ausgabe vom Arduino (ATmega328) über usb (auf
> COM4) auf das Terminal.
OK, jetzt hab ichs verstanden:)

rodnas schrieb:
> Erste UDP Versuch fehlgeschlagen :(
> Ist egal wie das Modul als UDP Server oder Client konfiguriert.
Konntest du die Schnittstelle denn verbinden? Als UDP-Empfänger die 
lokale IP-Adresse und einen beliebigen Kanal, dann müsste das schon mal 
funktionieren. Zu beachten ist, dass das Terminal mit UDP bisher nicht 
funktioniert! Will ich aber in der nächsten Version ändern.

Edit: Hab grad gesehen, dass beim Umwandeln von Steuerzeichen ein Fehler 
drin ist. Ich würde dir fast empfehlen mit dem UDP-Test noch zu warten, 
ich schau, dass ich bis morgen eine neue Version mit 
Terminalunterstützung für UDP fertig habe. Falls dus doch noch 
probierst, dann versuch die Befehle ohne Sonderzeichen zu senden.

[rodnas (Gast)]

Hier mal meine Einstellungen

[rodnas (Gast)]

Geduld als Gabe habe ich :-)

[rodnas (Gast)]

Übrigens, wie kann ich umschalten zwischen UDP und Seriell wenn ich zwei 
angeschlossene Systeme habe?

[ich (Gast)]

Autoscroll im Terminalfenster fehlt noch (bzw. geht nicht richtig)

[ich (Gast)]

Außerdem: man hat keinen Überblick was im internen Puffer los 
ist....wenn da irgendwann mal viele Daten ankommen, dann schaut man 
nicht mehr "realtime" -> passiert schon bei Daten aller 250 ms.

Man hat keine chance zu erkennen, dass dort alte Daten angezeigt 
werden....

[Est Est E. (comvisu)]

rodnas schrieb:
> Übrigens, wie kann ich umschalten zwischen UDP und Seriell wenn ich zwei
> angeschlossene Systeme habe?
Wie meinst du das? Wenn du UDP und Seriell gleichzeitig verwendest, dann 
werden auch Daten von beiden Schnittstellen angenommen, ggf. auch an die 
gleichen Kanäle. Bei Ausgaben werden die Befehle an beide Schnittstellen 
gesendet.

ich schrieb:
> Autoscroll im Terminalfenster fehlt noch (bzw. geht nicht richtig)
Das stimmt, das Terminal ist sehr rudimentär. Es war nur zum Einrichten 
der Kommunikation gedacht und sollte im normalen Betrieb nicht 
mitlaufen.

ich schrieb:
> Außerdem: man hat keinen Überblick was im internen Puffer los
> ist....wenn da irgendwann mal viele Daten ankommen, dann schaut man
> nicht mehr "realtime" -> passiert schon bei Daten aller 250 ms.
Realtime ist aber relativ. Wenn bis zur Anzeige eine Verzögerung von 
100ms auftritt, so ist das nach meiner Auffassung noch im Rahmen.

> -> passiert schon bei Daten aller 250 ms.
Wie hast du das gemessen? Das wären nur 4 Befehle pro Sekunde. Bis in 
den Bereich mehrerer tausend Befehle pro Sekunde (ist nur eine vage 
Erinnerung) sollte es noch zu keinem Aufstau kommen.
Zu beachten ist, dass die Anzeigen nur alle 0,4 Sekunden aktualisiert 
werden um auch bei hohen Datenraten den Rechner nicht mit sinnlosem 
Neuzeichnen der Anzeigen auszulasten. Dadurch wird auch die Lesbarkeit 
erhalten.

> Man hat keine chance zu erkennen, dass dort alte Daten angezeigt
> werden....
Das ist richtig, der einzige Indikator dafür ist die CPU-Auslastung... 
Ich habe jetzt aber auch keine Idee, wie man sonst noch einen Indikator 
bereitstellen könnte.

[rodnas (Gast)]

Ach so, ich dachte entweder - oder

[Moby A. (moby-project)]

Est Est E. schrieb:
> Realtime ist aber relativ. Wenn bis zur Anzeige eine Verzögerung von
> 100ms auftritt, so ist das nach meiner Auffassung noch im Rahmen.

Absolut. Visualisierung heißt schließlich: Ein Mensch schaut drauf.
Ein Highspeed-Datenaufzeichnungsprogramm kann hier schon wegen der 
langsameren ASCII-Übermittlung kein Ziel sein. Für SmartHome-Anwendungen 
jedenfalls sind Verzögerungen unter 1 Sekunde ohne Bedeutung, wenn es 
nur ums passive Sichtbarmachen von Werten geht. Fürs schnellere 
Reagieren ist der MC zuständig.

Est Est E. schrieb:
> Das stimmt, das Terminal ist sehr rudimentär. Es war nur zum Einrichten
> der Kommunikation gedacht und sollte im normalen Betrieb nicht
> mitlaufen.

Schade. Das hatte ich als laufenden Statustext-Melder schon eingeplant.

rodnas schrieb:
> Ach so, ich dachte entweder - oder

Na bloß gut, daß das parallel geht. So können Daten aus 
unterschiedlichsten Quellen zusammenlaufen!

[Est Est E. (comvisu)]

Moby A. schrieb:
> Est Est E. schrieb:
>> Das stimmt, das Terminal ist sehr rudimentär. Es war nur zum Einrichten
>> der Kommunikation gedacht und sollte im normalen Betrieb nicht
>> mitlaufen.
> Schade. Das hatte ich als laufenden Statustext-Melder schon eingeplant.
Für laufende Statusmeldungen ist eigentlich die Konsole (Eingänge auf 
Kanal #0) gedacht. Du willst ja normalerweise nicht die einzelnen 
Befehle sehen.


Moby A. schrieb:
> rodnas schrieb:
>> Ach so, ich dachte entweder - oder
> Na bloß gut, daß das parallel geht. So können Daten aus
> unterschiedlichsten Quellen zusammenlaufen!
Ich hab mir überlegt jeder Schnittstelle noch einen Kanalfilter zu 
spendieren, wo man einen Bereich angeben kann. Default wäre der ganze 
Bereich, also #1 bis #999. So könnte man insbesondere bei Ausgaben 
steuern, an welche Schnittstelle diese gehen soll. Konfiguration wäre in 
der jeweiligen Schnittstelle. Was sagt ihr dazu? Lohnend oder eher 
verwirrend?

[Moby A. (moby-project)]

Est Est E. schrieb:
> Für laufende Statusmeldungen ist eigentlich die Konsole (Eingänge auf
> Kanal #0)

Da hab ich jetzt glatt Terminal mit Konsole verwechselt, sorry ;-)

[rodnas (Gast)]

Est Est Est schrieb:

Ich hab mir überlegt jeder Schnittstelle noch einen Kanalfilter zu
spendieren,.......

Hört sich interessant an. So könnte man die "Feldgeräte" gezielt 
ansprechen.

[Moby A. (moby-project)]

Est Est E. schrieb:
> So könnte man insbesondere bei Ausgaben
> steuern, an welche Schnittstelle diese gehen soll.

Irgendwie sollte das natürlich steuerbar sein.
Freilich bedeutet das eine zusätzliche Fehlerquelle, wenn dann mal was 
nicht am Zielgerät ankommt. Aus diesem Grund würde ich zumindest die 
Angabe der Zielschnittstelle bei der Instrumentenkonfiguration (unter 
Signalausgang) für sinnvoller halten, da ist dann quasi alles notwendig 
Wissenswerte zum jeweiligen Ausgabeinstrument unter einem Dach.

Für den Fall wechselnder

rodnas schrieb:
> "Feldgeräte"

wär es unter Umständen von Vorteil, Kanäle als Bereich gesammelt 
umzuschalten. Das wär dann freilich besser in der 
Schnittstellenkonfiguration anzusiedeln. Einen Einsatzfall kann ich mir 
selbst dafür jetzt nicht vorstellen- ich habe mehr das 
stationäre/festverdrahtete Umfeld (ich meine, das ist der Regelfall) im 
Blick. Statt zum Beispiel die Zeichenausgabe erst mühsam offline/manuell 
in der Konfiguration umzuschalten mach ich mir lieber gleich zwei 
(entsprechend gerichtete) Instrumente betriebsfertig...

[Est Est E. (comvisu)]

Hier nun eine neue Version V0.32
- Das Terminal kann nun auch Daten aus der UDP-Schnittstelle anzeigen. 
Dafür muss die Schnittstelle 'UDP-Empfang' an erster Stelle in der 
Schnittstellenliste stehen. UDP-Packete dürfen nun auch Leerzeichen 
enthalten, das war vorher nicht der Fall. Wichtig bei UDP ist, dass ein 
Befehl nicht aus mehreren Packeten zusammengestückelt wird. Auserdem 
wird in jedem Packet nur der erste Befehl verarbeitet. Es muss also 
gelten: 1 Packet = 1 Befehl.

- Beim Zeitdiagramm und beim Vierfach-Zeitdiagramm erfolgt nun keine 
Anzeige der Aktualisierung mehr während gezoomt wird. Die Aufzeichnung 
läuft selbstverständlich dabei weiter.

- Die schwarzen Bereiche bei der Skalierung sollten nun behoben sein.

[Est Est E. (comvisu)]

Est Est E. schrieb:
> rodnas schrieb:
>> Erste UDP Versuch fehlgeschlagen :(
> Ich würde dir fast empfehlen mit dem UDP-Test noch zu warten,
Jetzt darfst du gerne mit der neuen Version weitertesten;-)
Wichtig ist: Ein Packet pro Befehl. Und natürlich darf auch keine 
Firewall die ankommenden Daten blockieren.
Meine Tests waren bisher zwischen zwei Rechnern, da ich keine 
Mikrocontrollerhardware mit Ethernet habe. Das sollte aber ja keinen 
großen Unterschied machen?

[rodnas (Gast)]

Der erste kleine Erfolg ist da. Terminal funktioniert mit UDP, aber nur 
ein einziger Wert wird in Instrumentenmodus übernommen und zwar der 
allererste Wert von der Übertragungsliste. Dieser wird als 
Digitalanzeige wahrgenommen, die parallel geschaltete Analoganzeige 
bleibt hiervon ungerührt.
Senden geht nicht.

[rodnas (Gast)]

Bei der Instrumentenkonfiguration "Zeichenausgabe" wird der Ausgabewert 
nicht abgespeichert.

[Moby A. (moby-project)]

Est Est E. schrieb:
> - Die schwarzen Bereiche bei der Skalierung sollten nun behoben sein.

Passt.

[rodnas (Gast)]

rodnas schrieb:

> Dieser wird als
Digitalanzeige wahrgenommen, die parallel geschaltete Analoganzeige
bleibt hiervon ungerührt.

Mea culpa....., beide Anzeigen funktionieren! (Das war pure Dummheit 
meinerseits.)

Nur die andere Kanäle nicht.

Beim Senden kommt Absturz.

[Est Est E. (comvisu)]

rodnas schrieb:
> Bei der Instrumentenkonfiguration "Zeichenausgabe" wird der Ausgabewert
> nicht abgespeichert.
Das stimmt, war bisher auch nicht vorgesehen. Wäre aber zu diskutieren.

rodnas schrieb:
> Mea culpa....., beide Anzeigen funktionieren!
Du jagst mir immer einen Schreck ein:-)

> Nur die andere Kanäle nicht.
Kannst du genauer beschreiben was passiert? Die Befehle mit anderen 
Kanälen sind auch im Terminal angekommen? Hast du eine oder mehrere 
UDP-Empfänger eingerichtet?

> Beim Senden kommt Absturz.
Gab es eine Fehlermeldung? Oder ist das Programm hängengeblieben?

Grüße

[Est Est E. (comvisu)]

Moby A. schrieb:
> Est Est E. schrieb:
>> So könnte man insbesondere bei Ausgaben
>> steuern, an welche Schnittstelle diese gehen soll.
> Irgendwie sollte das natürlich steuerbar sein.
> Freilich bedeutet das eine zusätzliche Fehlerquelle, wenn dann mal was
> nicht am Zielgerät ankommt. Aus diesem Grund würde ich zumindest die
> Angabe der Zielschnittstelle bei der Instrumentenkonfiguration (unter
> Signalausgang) für sinnvoller halten[...].
> Für den Fall wechselnder
> rodnas schrieb:
>> "Feldgeräte"
> wär es unter Umständen von Vorteil, Kanäle als Bereich gesammelt
> umzuschalten.
Mir scheint es gibt hier nicht den Königsweg.

Die Schnittstelle in der Instrumentenkonfiguration einzustellen ist 
zunächst vielleicht intuitiver. Es kann aber auch schnell ein 
Durcheinander an Kanälen entstehen. Dann ist die Frage, was soll mit den 
Zuordnungen passieren, wenn man eine Schnittstelle löscht. Man wird sie 
nicht einfach der nächsten Schnittstelle zuordnen können, das führt 
schnell zu Chaos. Eine einfache Durchnummerierung wird dann nicht 
reichen. Insgesamt ergibt sich also ein verhältnismäßig großer 
Programmieraufwand, wenn es am Schluss gut sein soll.

Bei der Bereichzuordnung ist das Problem, dass man für Kanäle, die an 
mehrere Teilnehmer gehen sollen, überlappende Bereiche definieren muss, 
was dann aber für mehr als zwei Schnittstellen nicht mehr funktioniert. 
Ansonsten wären zwei Bereiche für jede Schnittstelle nötig, was es 
wieder weniger intuitiv macht. Eine Möglichkeit wäre noch (z.B.) Kanal 
#0 bis #50 als Broadcast-Kanäle vorzusehen (fest einzuprogrammieren), 
welche dann an alle Schnittstellen gehen. Die übrigen sind über Bereiche 
einstellbar. Das wäre aber wieder etwas, was der Benutzer wissen muss...

Was sagt ihr dazu?

[frager (Gast)]

Kurze Frage: die neue, letzte Version ist 1,81 MB groß; die beiden 
vorhergehenden waren ca. 9 MB groß. Wie erklärt sich dieser große 
Unterschied?

[Est Est E. (comvisu)]

frager schrieb:
> Kurze Frage: die neue, letzte Version ist 1,81 MB groß; die beiden
> vorhergehenden waren ca. 9 MB groß. Wie erklärt sich dieser große
> Unterschied?
Und das sind ja sogar noch die gezippten Größen, bei den Exe verhält es 
sich 35MB zu 3,5MB. Der Grund sind die Debuggerinformationen der IDE. 
Ich hab vor der letzten Version den Knopf gefunden, diese abzuschalten~

[frager (Gast)]

Okay, danke.

[rodnas (Gast)]

rodnas schrieb:
> Bei der Instrumentenkonfiguration "Zeichenausgabe" wird der Ausgabewert
> nicht abgespeichert.
Das stimmt, war bisher auch nicht vorgesehen. Wäre aber zu diskutieren.
*****
Ich habe große Interesse dran. Das ist die schnellste Lösung 
zielgerichtete Befehle ohne Umweg auszugeben. Sozusagen fest kodiert.
*****
> Nur die andere Kanäle nicht.
Kannst du genauer beschreiben was passiert? Die Befehle mit anderen
Kanälen sind auch im Terminal angekommen? Hast du eine oder mehrere
UDP-Empfänger eingerichtet?
*****
Alle Befehle , alle Kanäle  kommen im Terminal an.
Ein UDP Gerät ist zur Zeit eingerichtet.
*****
> Beim Senden kommt Absturz.
Gab es eine Fehlermeldung? Oder ist das Programm hängengeblieben?
*****
Fehlermeldung siehe Bild "Senden"

[Moby A. (moby-project)]

Est Est E. schrieb:
> was soll mit den
> Zuordnungen passieren, wenn man eine Schnittstelle löscht.

Wie gesagt für mich kommt nur die stationäre festverdrahtete Anwendung 
in Frage- da werden keine dazu geplanten Schnittstellen einfach 
gelöscht.
Soo viele Instrumente passen nun auch nicht auf den Desktop... was mich 
aber gleich zur Idee bringt, im Programm mehrere wählbare 
Instrumente-Desktops (z.B. für verschiedene Einsatzorte im Smart Home 
;-) anzubieten! So ein einzelnes Diagramm nimmt doch schon ordentlich 
Platz weg.

> Bei der Bereichzuordnung ist das Problem,

... daß es in meinen Augen in jedem Fall zur weniger intuitiven Lösung 
führt.

Für den Fall der Schnittstellenlöschung würde ich kurzerhand irgendeine 
Form der Warnung im angezeigten Instrument vorschlagen. Die 
Konfigurierung des Schnittstellen-Ziels im Instrument vorausgesetzt.

> Insgesamt ergibt sich also ein verhältnismäßig großer
> Programmieraufwand, wenn es am Schluss gut sein soll.

So ist das leider meistens. Je einfacher die Bedienung, je besser der 
Programmierer die sinnvollen Einsatzbedingungen vorausahnt, desto 
komplexer der Unterbau. Viele manuelle Einstelloptionen sind dann oft 
die einfachere Lösung- für den Programmierer ;-)

[Einhart P. (einhart)]

Danke Est Est Est,

das Projekt sieht wirklich vielversprechend aus. Das sollte sich gut für 
die Visualisierung meiner Heizungs- und Haustechnikdaten eignen. Baust 
du wie Ulrich eine Laufzeitbegrenzung ein oder wird das Programm 
unbegrenzt laufen?

Gruß
Einhart

[frager (Gast)]

Einhart P. schrieb:
> Baust
> du wie Ulrich eine Laufzeitbegrenzung ein oder wird das Programm
> unbegrenzt laufen?

Was für eine Laufzeitbegrenzung? Davon habe ich noch nichts gehört ...

[Est Est E. (comvisu)]

rodnas schrieb:
> Fehlermeldung siehe Bild "Senden"
Hallo Rodnas,

das sind jetzt Fehler, die ich erstmal nachvollziehen muss. Ich habe 
vor, in das Terminal noch ein zweites Fenster zu setzen, welches nur die 
gefilterten Befehle zeigt. So kann man das Problem schon etwas 
einschränken. Das wird aber etwas dauern, ich muss dich also wieder um 
Geduld bitten!


Moby A. schrieb:
> Est Est E. schrieb:
>> was soll mit den
>> Zuordnungen passieren, wenn man eine Schnittstelle löscht.
> Wie gesagt für mich kommt nur die stationäre festverdrahtete Anwendung
> in Frage- da werden keine dazu geplanten Schnittstellen einfach
> gelöscht.
> Soo viele Instrumente passen nun auch nicht auf den Desktop... was mich
> aber gleich zur Idee bringt, im Programm mehrere wählbare
> Instrumente-Desktops (z.B. für verschiedene Einsatzorte im Smart Home
> ;-) anzubieten! So ein einzelnes Diagramm nimmt doch schon ordentlich
> Platz weg.
An mehrere Tabs hab ich auch schon gedacht, aber erstmal sind andere 
Funktionen wichtig. Auch das Thema Schnittstellen-Zuordnen werd ich 
vorerst zurückstellen.


Einhart P. schrieb:
> Danke Est Est Est,
>
> das Projekt sieht wirklich vielversprechend aus. Das sollte sich gut für
> die Visualisierung meiner Heizungs- und Haustechnikdaten eignen. Baust
> du wie Ulrich eine Laufzeitbegrenzung ein oder wird das Programm
> unbegrenzt laufen?
Wie ich weiter oben schon mal schrieb baue ich keine Begrenzungen 
bewusst ein, das gilt genauso für die Laufzeit. Und noch weniger möchte 
ich bestimmte Anwendungen ausschließen.
Allerdings: Seit Version V0.31 verwende ich einen 32-bit Timer, um die 
Kompatibilität für WinXP zu gewährleisten. Nach etwa 20 Tagen läuft 
dieser über und dann werden wohl verschiedene 'Phänomene' auftreten. Ich 
habe auf jeden Fall vor, dieses Problem auszumerzen. Bis wann - keine 
Ahnung. Wie es mit der Langzeitstabilität des Programms überhaupt 
aussieht muss sich auch erst zeigen.

[rodnas (Gast)]

Kein Problem :)

[Einhart P. (einhart)]

frager schrieb:
> Was für eine Laufzeitbegrenzung? Davon habe ich noch nichts gehört ...

Ulrich benutzt ein Tool, dass die Programmausführung nach ca. einem Jahr 
stoppt.

Est Est Est  schreibt:

Wie ich weiter oben schon mal schrieb baue ich keine Begrenzungen
bewusst ein, das gilt genauso für die Laufzeit. Und noch weniger möchte
ich bestimmte Anwendungen ausschließen.

Das ist für mich ein starkes Argument für Comvisu!

[Est Est E. (comvisu)]

Hier eine neue Version mit besagter Anzeige der erkannten Befehle im 
Terminal (siehe Bild). Dort wird auch gleich angezeigt, ob der Befehl 
verarbeitet wurde.
In den folgenden Fällen gilt er als nicht verarbeitet:
 - Syntaxfehler im Befehl (z.B. Kanalnummer fehlt)
 - Kein Instrument benutzt angegebenen Kanal
 - Kanal #0 bei deaktivierter Konsole
Bei UDP-Empfang wird nun das Paketende im Terminal mit einem Backslash 
('\') angezeigt.

Weitere Neuerungen sind:
- Z-Order durch Rechtsklick einstellbar
- Kopieren und Einfügen von Instrumenten
- Der Inhalt des Textfeldes in der "Zeichenausgabe" wird nun auch 
abgespeichert.

[F. F. (foldi)]

Habe jetzt nicht die Befehle von NetIO im Kopf gehabt, aber mit der IP 
und dem Port nimmt das Programm auch mit UDP (zeigt grün an) unter 
Windows 10 Kontakt auf.

[Est Est E. (comvisu)]

rodnas schrieb:
>> Nur die andere Kanäle nicht.

Hallo Rodnas,
kannst du es bitte nochmal versuchen, mit den neuen Terminalfunktionen 
sollte sich der Fehler jetzt besser eingrenzen lassen.

[Est Est E. (comvisu)]

F. F. schrieb:
> Habe jetzt nicht die Befehle von NetIO im Kopf gehabt, aber mit der IP
> und dem Port nimmt das Programm auch mit UDP (zeigt grün an) unter
> Windows 10 Kontakt auf.
Kannst du das etwas konkretisieren?

Beim UDP-Empfang ist nur die eigene IP-Adresse entscheidend. Beim 
UDP-Senden wird auch nicht überprüft, ob der Empfänger tatsächlich im 
Netz ist (So viel ich weiß ist das gar nicht möglich). Dass 'Verbunden' 
angezeigt wird, heißt also noch nicht viel.
Im Thema UDP bin ich auch nicht sehr firm, vielleicht kann jemand noch 
was dazu sagen.

[F. F. (foldi)]

Ein Bild sagt mehr als 1000 Worte.

Stelle gerade fest, da kann was nicht stimmen.
Habe das wohl vorher nicht eingestellt. Muss dann wohl immer grün 
zeigen, da es diese Adresse nicht gibt.

[Est Est E. (comvisu)]

F. F. schrieb:
> Stelle gerade fest, da kann was nicht stimmen.

Du hast recht, da war ein Fehler drin.
Man darf halt nicht nur die Funktionen testen, sondern auch die 
Fehlfunktionen:-)

Hier eine korrigierte Version. Wenn das Aufbauen des UDP-Sockets 
fehlschlägt, kann nicht verbunden werden.

[rodnas (Gast)]

Hallo Est Est Est,

jetzt habe ich UDP mit V034 getestet. Leider ohne Erfolg.

Die Backslash werden im Terminal angezeigt und wie ersichtlich ist wird 
ein Instrument anerkannt und verarbeitet. Ein Programmausschnitt ist 
auch hinzugefügt.
Ich komme nicht weiter mit UDP, da ich zur Zeit keine Möglichkeit sehe 
meinerseits das Programm zu beeinflussen.
Was mir noch auffiel, die scheinbar kürzere reine Zahlenübertragungen 
werden als komplette UDP Datagramm erfasst. (Progschnitt1)

Danke für deine Bemühungen.

rodnas

[Est Est E. (comvisu)]

rodnas schrieb:
> Was mir noch auffiel, die scheinbar kürzere reine Zahlenübertragungen
> werden als komplette UDP Datagramm erfasst. (Progschnitt1)
Das scheint mir das Problem daran zu sein. Wie ich oben geschrieben habe 
muss gelten: Nur ein Befehl pro Packet. Das heißt beim Packet:
\01110010 [...] #10F23.12 #10F23.12 #20F23.00 [...]\
                ^^^^^^^^^
wird nur der markierte Befehl angenommen.

Wie du bei Bascom ein neues Packet erzwingst weiß ich nicht. Du könntest 
einen zusätzlichen Strichpunkt versuchen, das erzeugt soviel ich weiß 
bei Bascom einen Zeilenumbruch:
Print "#10F1"; Temp1; ";" ;
                         ^^^
Ansonsten macht es vielleicht auch Sinn, von Comvisu-Seite alle Befehle 
aus einem Paket zu filtern. EDIT: Wird in der nächsten Version kommen.

Es ist auch noch ein Fehler beim Parsen drin, die Zeilen '28 28 28 28 28 
28 28 28' dürften nicht in den gefilterten Befehlen erscheinen. das 
schau ich mir noch an.

Grüße

[rodnas (Gast)]

also zusätzliche Semikolon helfen nicht.

[Est Est E. (comvisu)]

Ab sofort können auch mehrere Befehle in einem UDP-Paket verarbeitet 
werden.

[rodnas (Gast)]

UDP Datenübertragung vom µC funktioniert jetzt. Aber die Taster haben 
jetzt keine Funktion. Ich bekomme keine Rückmeldung mehr. Auch nicht 
über COM Verbindung.
Was ist Button 4 ? Bei Betätigung kommt Fehlermeldung.

[Est Est E. (comvisu)]

rodnas schrieb:
> UDP Datenübertragung vom µC funktioniert jetzt.
Freut mich. Vielleicht kannst du noch Screenshots reinstellen als 
Beispiel für Interessierte.

> Aber die Taster haben
> jetzt keine Funktion. Ich bekomme keine Rückmeldung mehr. Auch nicht
> über COM Verbindung.
Ich habe es extra nochmal getestet, sowohl bei COM als auch UPD 
funktioniert die Ausgabe bei mir. Kann auch was auf Mikrocontrollerseite 
nicht stimmen?

> Was ist Button 4 ? Bei Betätigung kommt Fehlermeldung.
Da war ich nachlässig, der gehört nicht dorthin. War nur für Tests.

[rodnas (Gast)]

UDP Empfang funktioniert, Senden nicht.

 COM Empfang und Senden funktionieren einwandfrei.

 Die Bilder 1,2,3 zeigen UDP Modus.
 Bild Terminal1 zeigt wie im COM Modus die Sendung vom PC erfasst wird.
 Die Betätigung den "(+)Auto" Taster (#50).
 Diese Handlung bei UDP kommt nicht durch.

Noch eine Bemerkung: die Reihenfolge Datei Laden und Schnittstelle 
aktivieren
muss so passieren wie hier steht, sonst Fehlfunktion / Absturz.

Gruss

[Est Est E. (comvisu)]

rodnas schrieb:
> UDP Empfang funktioniert, Senden nicht.
> COM Empfang und Senden funktionieren einwandfrei.
Habs mir nochmal genauer angeschaut, bei mir kommt beim Senden das erste 
Packet auch nicht an. Das ist zwischen zwei Rechnern jeweils mit der 
Comvisu. Das UDP-Thema ist leider recht neu für mich.

>  Die Bilder 1,2,3 zeigen UDP Modus.
>  Bild Terminal1 zeigt wie im COM Modus die Sendung vom PC erfasst wird.
Danke!
Was mir aufgefallen ist, es gibt die Ausgabe:
#50F1 Instrument(1) [...] #10F23.12; #10F23.12;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Der markierte Bereich wird als ein Befehl aufgefasst, das werd ich auch 
in der nächsten Version ändern, dass nur zwischen der letzten '#' und 
dem nächsten ';' der Befehl gefiltert wird.

> Noch eine Bemerkung: die Reihenfolge Datei Laden und Schnittstelle
> aktivieren
> muss so passieren wie hier steht, sonst Fehlfunktion / Absturz.
Du meinst wenn die Schnittstelle verbunden ist, führt ein Datei-Öffnen 
zum Absturz? Das besser ich aus.

[rodnas (Gast)]

Hallo Est Est Est,

ich habe UDP Sendeversuche gemacht mit einem externen Programm. "Packet 
Sender" heißt das Ding. Es funktioniert, die Datenpakete werden 
abgeschickt und die Rückmeldung kommt an. Parallelversuche mit Comvisu 
scheitern.

Gruss

[Est Est E. (comvisu)]

rodnas schrieb:
> Parallelversuche mit Comvisu scheitern.
Hm. Ich kann dir jetzt auch nichts dazu sagen. Ich schau bei mir 
nochmal, ob mir was auffällt.

Grüße

[rodnas (Gast)]

So habe ich versucht...

[Est Est E. (comvisu)]

Hast du mal mit Wireshark geschaut, was gesendet wird? Im Anhang ein 
Screenshot wenn ich mit der Comvisu '#13F1' sende ("Taster" mit Kanal 13 
konfiguriert).

@All, fällt euch in diesem Paket was auf?

Hab mir auch PacketSender installiert, in Wireshark tut sich aber 
nichts, ich konnte in der Schnelle nicht testen, ob überhaupt was 
rausgeht.
Für heut ist erstmal Schluss~

[rodnas (Gast)]

Ich habe auch mit Wireshark reingeschaut. Könnte sein, das bei Comvisu 
ist dynamische UDP Portzuweisung für Senden eingestellt? Diese kann 
natürlich nicht mit dem fest eingestellten Modul-Port kommunizieren.
Siehe: Bild Haiattacke

Das ist natürlich nur meine Meinung, aber es wäre einen Versuch wert zB. 
Port 6001 fest für Senden und Empfangen programmieren.(frei einstellbar 
unter Schnittstelle)

Packet Sender hat feste UDP Portzuweisung (6001) und sendet astrein.
Siehe: Bild Haiattacke1

[Est Est E. (comvisu)]

rodnas schrieb:
> Könnte sein, das bei Comvisu
> ist dynamische UDP Portzuweisung für Senden eingestellt? Diese kann
> natürlich nicht mit dem fest eingestellten Modul-Port kommunizieren.
Es ist so, dass fuers Senden ein eigener Socket aufgemacht wird. Idee 
war, dass auf die Weise mehrere Sendeschnittstellen eingerichtet werden 
koennen. Offensichtlich kann dann aber nicht der gleiche Absenderport 
verwendet werden. Ich schaus mir an.

[Est Est E. (comvisu)]

So, habe die UDP-Schnittstelle jetzt "umgebaut", Senden und Empfangen 
ist nicht mehr getrennt, sondern wird in einer Schnittstelle 
konfiguriert. Dadurch stimmt dann auch der Absender-Port.

Es gibt noch eine weitere Neuerung, es kann nun angezeigt werden, ob die 
Eingangsformel oder der Ausgangskanal korrekt definiert wurde. Wenn das 
Häckchen Kompilierstatus im Ausführen-Menüband gesetzt ist, dann nimmt 
der Rand der Anzeige eine der folgenden Farben an:
 grün: Ein- oder Ausgang definiert
 rot:  Ein- oder Ausgangsdefinition fehlerhaft
 grau: Keine Definition angegeben (passive Anzeige)
So kann man schnell sehen, ob es an der Formel liegt, wenn sich bei 
einzelnen Anzeigen nichts tut.

[rodnas (Gast)]

Hallo Est Est ESt,

UDP funktioniert auf Anhieb. :-)

[rodnas (Gast)]

Jetzt kommt eine Wiederholung,

Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die belegten
Kanäle aufzulisten.

Grüsse

[Est Est E. (comvisu)]

rodnas schrieb:
> Hallo Est Est ESt,
>
> UDP funktioniert auf Anhieb. :-)
Hallo Rodnas, das freut mich!

rodnas schrieb:
> Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die belegten
> Kanäle aufzulisten.
Scheint ja dringend zu sein :-)
Ok, kommt als nächstes~

[rodnas (Gast)]

Vielen Dank schon im Voraus :)

[Est Est E. (comvisu)]

Wie versprochen gibt es jetzt eine Liste mit den verwendeten Kanälen. Zu 
finden rechts im Bearbeiten-Menü.
Wenn man einen Kanal im Menü anklickt, werden die Instrumente, welche 
diesen Kanal verwenden, markiert.

Außerdem ist die LED-Anzeige jetzt überarbeitet mit bis zu 10 
Anzeigefarben. Auch die Farbe für den Wert 0 ist nun auswählbar. 
Zwischenwerte werden aufgerundet, d.h. der Schwellwert liegt nun bei 0; 
1; 2 etc. nicht wie zuvor bei 0,5.
So kann man die LED leichter auf einen Schwellwert einstellen um z.B. 
eine Warnanzeige zu implementieren. Ein Eingang "#5-120" und Anzahl 
Farben=1 bspw. zeigt bis zum Wert 120 auf Kanal 5 die Farbe für 0 an und 
darüber die Farbe für 1.

[rodnas (Gast)]

Hallo Est Est Est,

sehr gute und nützliche  Erweiterungen! Vielleicht eine Bemerkung zur 
Kanalmarkierung, ein agressievere Farbton würde die Erkennbarkeit 
aufstocken.


Gruss

rodnas

[rodnas (Gast)]

Vorschlag:
Ein Instrument wie Zeichenausgabe, aber mit F - Kodierung.
Die  Zeichenausgabe kann man zwar missbrauchen aber es wäre schöner und 
sinnvoller auch eine direkte Zahlenwertausgabe realisieren zu können.

[Est Est E. (comvisu)]

rodnas schrieb:
> sehr gute und nützliche  Erweiterungen! Vielleicht eine Bemerkung zur
> Kanalmarkierung, ein agressievere Farbton würde die Erkennbarkeit
> aufstocken.
Ich wollte es eigentlich nicht ganz so knallig. Ich kann auch die Breite 
vergrößern von 2 auf 3 Pixel, dann wird es auch auffälliger.

rodnas schrieb:
> Vorschlag:
> Ein Instrument wie Zeichenausgabe, aber mit F - Kodierung.
Ja, das ist gut. Vermutlich wäre wie bei der Digitalanzeige eine 
optionale Anzeige einer Einheit und eines Namens sinnvoll.

Zur Info, ich bereite gerade ein Anzeige für Bilder vor. Schalter stehen 
auch oben auf der Liste.

Grüße

[rodnas (Gast)]

Übrigens, die Einführung des LED-Schwellwertes ist genial, da spart man 
µC Speicher wenn es um Bildschirm-Visualisierung geht.

[Pastor Braune (Gast)]

Analoganzeige Horz. + Vertikal ?
und ich möchte gerne sowas wie im Anhang ;-)

[Est Est E. (comvisu)]

rodnas schrieb:
> Übrigens, die Einführung des LED-Schwellwertes ist genial, da spart man
> µC Speicher wenn es um Bildschirm-Visualisierung geht.
Der Schwellwert war von Anfang an da, aber eben bei 1/2 (0,5), was 
weniger intuitiv ist. Aber freut mich, dass es dir gefällt~

Pastor Braune schrieb:
> Analoganzeige Horz. + Vertikal ?
Eine vertikale Analoganzeige kommt auf jeden Fall noch, ist aber nicht 
an erster Priorität. Auch eine Balkenanzeige wird noch kommen.

> und ich möchte gerne sowas wie im Anhang ;-)
Wäre schön:-) Ich kann aber nicht sagen ob und wann...

[Est Est E. (comvisu)]

Eine neue Version mit gleich zwei neuen Instrumenten:
1. Bilderanzeige. Es können bis zu 10 Bilder in einer Anzeige geladen 
werden (png, bmp und/oder jpg) und über den Eingang mit ihrem Index 
angezeigt werden. Ist der Eingang null oder negativ, dann wird die 
Bildanzeige ausgeblendet, auch der Rahmen/Hintergrund.
Das Instrument kann auch als statische Anzeige für Bilder verwendet 
werden. Dazu einfach den Eingang frei lassen. Für die Verarbeitung der 
Schnittstellen entsteht dadurch kein zusätzlicher Aufwand.

2. Schalterleiste. Die Schalterleiste ist sehr flexibel aufgebaut. Es 
können zwischen 1 und 10 Schaltelemente in jeder Schalterleiste 
eingestellt werden, sowohl eine horizontale als auch vertikale Anordnung 
ist möglich. Im XOR-Modus ist immer nur ein Schalter angewählt, beim 
Drücken eines Schalters wird der vorige gelöst (Radioschaltleiste). Im 
Modus Schaltleiste können auch mehrere Schalter gleichzeitig gedrückt 
sein. Der Modus DIP-Schalter unterscheidet sich nur im Ausgang, hier 
wird bei jedem Drücken der Status der ganzen Schaltleiste gesendet.

Daneben war noch ein Fehler beim Speichern der LED-Anzeige, wenn mehrere 
Farben verwendet wurden.

[Moby A. (moby-project)]

Est Est E. schrieb:
> Eine neue Version mit gleich zwei neuen Instrumenten:
> 1. Bilderanzeige
> 2. Schalterleiste

Besten Dank. Sehr nützliche Erweiterungen. Evt. könnte man die 
Bilderanzeige- Möglichkeiten auch mit einem wechselbaren Hintergrundbild 
erweitern?
Für die multi- serielle Kommunikation könnte ich ein weiteres Feature 
sehr gut gebrauchen:
Eine Kontroll-Möglichkeit, (was) von welcher Quelle zu welcher 
Destination weitergesendet wird!
Eingehende UDP-Befehlssequenzen würde ich zum Beispiel sehr gerne 
zusätzlich zur visuellen Anzeige 1:1 unverfälscht an meinen BT-seriell 
angebundenen MC weiterleiten...

[Est Est E. (comvisu)]

Moby A. schrieb:
> Evt. könnte man die
> Bilderanzeige- Möglichkeiten auch mit einem wechselbaren Hintergrundbild
> erweitern?
Dazu habe ich mir auch schon Gedanken gemacht und bin auf zwei 
Möglichkeiten gekommen:
- Es wäre eine optionale Verriegelung für  jedes Instument denkbar, die 
in einer Liste mit allen platzierten Instrumenten ausgewählt wird. Im 
Editmodus wären diese nicht mehr klickbar und könnten nicht verschoben 
werden, verhalten sich also wie der Hintergrund. Somit könnte die 
Bilderanzeige auch als Hintergrund missbraucht werden.
- Eine Alternative wäre eben ein Button im Bearbeiten-Menü wo man den 
Hintergrund gezielt einstellt. Für die Bedienung ist das wohl 
intuitiver.

Mit "wechselbar" meinst du über die Schnittstelle? Das wäre natürlich 
wieder ein gewisser Mehraufwand...

Mehrere Oberflächen/Tabs will ich bald umsetzen.

> Für die multi- serielle Kommunikation könnte ich ein weiteres Feature
> sehr gut gebrauchen:
> Eine Kontroll-Möglichkeit, (was) von welcher Quelle zu welcher
> Destination weitergesendet wird!
> Eingehende UDP-Befehlssequenzen würde ich zum Beispiel sehr gerne
> zusätzlich zur visuellen Anzeige 1:1 unverfälscht zu meinem BT-seriell
> angebundenen MC weiterleiten...
Was ich auf jeden Fall vorhabe ist ein Instrument mit einem Ein- und 
Ausgang. Letzterer wird durch den Eingang getriggert und verwendet 
dessen Wert. Man kann damit dann also (auch) eine Weiterleitung eines 
Kanaleingangs an eine andere Schnittstelle realisieren. Allerdings 
natürlich nur für gültige Befehle mit Kanalnummer. Reicht das aus?

[Moby A. (moby-project)]

Est Est E. schrieb:
> Mit "wechselbar" meinst du über die Schnittstelle?

Ja. Das Ganze ließe sich für

> Mehrere Oberflächen/Tabs will ich bald umsetzen.

sogar noch weiterspinnen, indem der MC über die bzw. eine einzige 
Oberfläche samt angezeigter Instrumente gleich selbst entscheiden 
kann/darf und so die Organisation mehrerer Oberflächen über mehrere Tabs 
ggf. überflüssig würde ;-)

Egal. Sowohl ein einstellbares Hintergrundbild als auch mehrere fixe 
Tabs sind in jedem Fall schonmal  ein hilfreicher Fortschritt.

> Man kann damit dann also (auch) eine Weiterleitung eines
> Kanaleingangs an eine andere Schnittstelle realisieren. Allerdings
> natürlich nur für gültige Befehle mit Kanalnummer. Reicht das aus?

Mir auf jeden Fall. Mit dem MC kann man die Befehle doch locker ganz 
nach Bedarf auswerten.
Was sich damit erübrigt sind Splitter-Lösungen für serielle 
PC-Kommunikation: Entweder sind die nämlich heutzutage für Windows 
kostenlos, kompliziert, störanfällig oder eben einfach aber teuer mit 
entsprechender Software zu realisieren... Die Idee eines universellen 
"Weiterleitungs"- Instruments wäre schon mal keine dumme; mir hatte 
eigentlich nur vorgeschwebt, zu jeder Schnittstelle einfach eine 
Weiterleitungsmöglichkeit anzugeben. Du wirst am besten wissen, was 
jetzt den geringsten Aufwand macht.

[rodnas (Gast)]

Zuerst frohe restliche Osterstunden.

Lobenswerter Fortschritt!!!

Besonders die Schalter sind beeindruckend.
Eine Frage bzw. Vorschlag habe ich. Der DIP Schalter sendet bei jeder 
Betätigung? Meines Erachtens nach wäre vorteilhafter zusätzlich einen 
Sendetaster dazu ordnen, einen Code auf einmal senden zu können.


Gruss

rodnas

[Est Est E. (comvisu)]

Moby A. schrieb:
> Est Est E. schrieb:
>> Mit "wechselbar" meinst du über die Schnittstelle?
> Ja. Das Ganze ließe sich für
>> Mehrere Oberflächen/Tabs will ich bald umsetzen.
> sogar noch weiterspinnen, indem der MC über die bzw. eine einzige
> Oberfläche samt angezeigter Instrumente gleich selbst entscheiden
> kann/darf und so die Organisation mehrerer Oberflächen über mehrere Tabs
> ggf. überflüssig würde ;-)
Tabs will ich schon, allein schon um die Instrumente sauber anordnen zu 
können. Es soll aber möglich sein, den Tab über den MC zu wechseln. Wie 
das dann zu konfigurieren ist, muss ich noch schauen.

> Die Idee eines universellen
> "Weiterleitungs"- Instruments wäre schon mal keine dumme; mir hatte
> eigentlich nur vorgeschwebt, zu jeder Schnittstelle einfach eine
> Weiterleitungsmöglichkeit anzugeben. Du wirst am besten wissen, was
> jetzt den geringsten Aufwand macht.
Das Weiterleitungsinstrument mach ich auf jeden Fall, da es auch für 
andere Zwecke eingesetzt werden kann (z.B. ausgelagerte Berechnung), von 
daher wäre eine Weiterleitung direkt an der Schnittstelle ein 
zusätzlicher Aufwand. Aber mal schauen~


rodnas schrieb:
> Zuerst frohe restliche Osterstunden.
Ebenfalls:-)

> Eine Frage bzw. Vorschlag habe ich. Der DIP Schalter sendet bei jeder
> Betätigung? Meines Erachtens nach wäre vorteilhafter zusätzlich einen
> Sendetaster dazu ordnen, einen Code auf einmal senden zu können.
Ah, dann sollte für den DIP-Schalter wohl auch der letzt Schaltzustand 
abgespeichert werden. Erst dann ist ein getrennter Sendetaster sinnig. 
Wahrscheinlich sollte ich den DIP-Schalter doch in ein getrenntes 
Instrument auszulagern. Das Thema stell ich aber erstmal noch zurück. Du 
kannst mich gern in einiger Zeit nochmal dran erinnern.

[rodnas (Gast)]

Vermerk:

Die Mehrfach-Zeitdiagramm Instrumente speichern nicht den Kanal- 
aktiv/inaktiv Zustand korrekt ab. Bei Programmneueröffnung werden alle 
Kanäle als aktiv gesetzt.

[Est Est E. (comvisu)]

OK, schau ich mir an. Danke~

[rodnas (Gast)]

Hallo Est Est Est,

ist die Programmpflege auf Eis gelegt?

Grüsse

rodnas

[Est Est E. (comvisu)]

Nein, im Gegenteil, ich bin zu beschäftigt mit dem Programmieren~
In den nächsten Tagen gibts neue Funktionen:-)

Grüße

[Moby A. (moby-project)]

Est Est E. schrieb:
> In den nächsten Tagen gibts neue Funktionen:-)

Prima. Nach erfolgtem System-Wechsel kann ich bald mittesten ;-)
Für mich essentiell wird die Möglichkeit der Datenweiterleitung von UDP 
auf den MC-COM sein; alles andere langt mir im Prinzip schon.

P.S. Eigentlich gehört der Thread ja in die Projektesammlung...

[peter (Gast)]

Hallo, das ist ja ein Superprogramm.
Kann ich gut für mein Arduino Mega2560 und Arduino DUE einsetzen.

Danke.

Ich freue mich auf weitere Dinge die da rein kommen.

GRuss

[Est Est E. (comvisu)]

So, es geht weiter~

Version 0.40 mit folgenden Neuerungen:
- Es können mehrere Arbeitsblätter/Tabs angelegt werden. Alle werden 
durch die Schnittstellen beschickt. Die Anzahl an Blättern ist nicht 
beschränkt, getestet sind allerdings nur ein paar Blätter.

- Die Blätter können neben den Tabs auch per Befehl über die 
Schnittstelle ausgewählt, d.h. angezeigt, werden. Dazu gibt es eine neue 
Funktion "sheet(Argument)", welche in einem beliebigen Instrument 
(egal auf welchem Blatt) in die Eingangsformel geschrieben werden kann. 
Das Argument ist das anzuzeigende Blatt, indiziert beginnend mit der 
Eins. Definiert man bspw. den Eigang einer numerischen Anzeige mit 
"=sheet(#5)" dann kann man über Kanal 5 das Blatt auswählen, der Befehl 
"#5F2;" macht dann das zweite Blatt sichtbar.

- Es können nun Hintergrundbilder geladen werden, getrennt für jedes 
Blatt. Auch kann die hintergrundfarbe angepasst werden.

- Es steht die neue Funktion "if(Bedingung; ErgebnisWahr; 
ErgebnisFalsch)" zur Verfügung und es sind Vergleichsoperatoren 
("==","/=","<","<=",">" und ">=") verfügbar. Ein Eingang könnte lauten: 
"= if(#5>=100;#5;100)". Als Beispiel um einen Eingang mit dem 
Mindestwert 100 zu versehen.

- Funktion max() implementiert (siehe Dokumentation).

- In der Titelleiste und in der Tableiste wird der Name der geöffneten 
Projektdatei angezeigt.

- Der Fehler beim Speichern des Aktiv-/Inaktiv-Zustand im 
Mehrfachzeitdiagramm ist behoben.

[Est Est E. (comvisu)]

Moby A. schrieb:
> Prima. Nach erfolgtem System-Wechsel kann ich bald mittesten ;-)
:-)

> Für mich essentiell wird die Möglichkeit der Datenweiterleitung von UDP
> auf den MC-COM sein; alles andere langt mir im Prinzip schon.
War dieses Mal noch nicht dabei, aber bei der nächsten Version dann.

> P.S. Eigentlich gehört der Thread ja in die Projektesammlung...
Ich hatte den Thread in "µC & Elektronik" gestartet, wurde aber von 
einem Moderator hierher verschoben...


peter schrieb:
> Hallo, das ist ja ein Superprogramm.
> Kann ich gut für mein Arduino Mega2560 und Arduino DUE einsetzen.
Danke:) Ich freue mich auch immer über Screenshots.

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4544242:
> Auf die Schnelle zwei kleine optische Fehlerchen im Zusammenhang mit der
> Kanalliste:
>
> 1) Ohne belegte Kanäle/Instrumente kommt beim Klick auf Kanalliste eine
> unschöne Access violation.
Das ist natürlich schlecht, schau ich mir an.

> 2) Die Markierungsrahmen bei Auswahl in der Kanalliste werden alle ins
> aktuelle Sheet gezeichnet statt ggf. vorher einen Wechsel vorzunehmen
> wenn das Instrument auf einem anderen Sheet platziert ist.
Das Problem ist natürlich, wenn ein Kanal auf mehreren Blättern 
Verwendung findet, dass man ja nur ein Blatt anzeigen lassen kann. Ich 
überleg mir, was ich da machen könnte. Evtl. nur auf das erste Blatt mit 
Vorkommen zu springen. Die Markierung für die verdeckten Instrumente 
würde ich aber drin lassen, damit man gleich sieht, dass der Kanal auch 
noch auf anderen Blättern verwendet wird.

[Est Est E. (comvisu)]

Version 0.41 mit folgenden Neuerungen:

- Neues Instrument E/A-Kanal zum Weiterleiten von Befehlen an 
angeschlossene Geräte oder zum Auslagern von Berechnungen.

- Kanalfilter, optional für jede Schnittstelle getrennt einstellbar. 
Sowohl eingehende als auch ausgehende Befehle werden nur angenommen und 
gesendet, wenn sie im angegebene Bereich liegen. Kanal #0 bis #49 können 
nicht gefiltert werden, es werden alle Befehle angenommen und beim 
Senden an alle Schnittstellen geschickt ("Broadcast-Kanäle"). Ist der 
Kanalfilter deaktiviert, werden alle Befehle für diese Schnittstelle 
angenommen und alle Ausgänge (auch) an diese Schnittstelle gesendet.

- Verbindungstest im Schnittstellenblatt. Es ist nun ein Verbindungstest 
möglich, welcher anzeigt, welche Schnittstelle nicht verbunden werden 
kann.

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4550867:
> - E/A Kanal Instrument wird (wenn selektiert) beim Ausführen nicht
> ausgeblendet
Wenn der Kompilierstatus aktiviert ist (farbiger Rahmen je nachdem ob 
Formel gültig), wird dieser gezeigt bis die Schnittstelle verbunden ist. 
Entsprechend werden auch die "ausgeblendeten" Instrumente angezeigt. 
Sobald die Verbindung steht, werden sie dann wirklich ausgeblendet.

Übrigens gibt es einen Art Offline-Modus: Wenn keine Schnittstelle 
definiert ist (Default Schnittstelle löschen), kann man in der 
Ausführen-Oberfläche "Verbinden" drücken, dann startet die Aufzeichnung, 
d.h. die Zeitdiagramme laufen los, der Dateirekorder legt an/öffnet eine 
Datei, etc.. Dabei sieht man auch schön das Verhalten von ausgeblendeten 
Instrumenten, ohne dass man eine Schnittstelle verfügbar haben muss.

> - bei aktivierter Kanalliste kann die Hintergrund-Konfiguration nicht
> mehr aufgerufen werden
Danke, schau ich mir an!

> Braucht es denn für den Hintergrund eine eigene Taste?
> Im Prinzip langt es doch, dafür in einen instrumentfreien Bereich zu
> klicken !?
Dann hätte ich mir den Aufwand für den Hintergrund sparen können;-) Man 
kann ja auch mit der Bildanzeige ein Hintergrundbild verwirklichen.
Wenn man auf den Hintergrund klickt schließt sich ja der 
Eigenschafteneditor (egal welches Instrument offen war), wie ich denke 
eine recht intuitive Reaktion. Diese Funktion würde man verlieren, wenn 
stattdessen die Hintergrundeigenschaften aufgehen würden. Es wäre 
stattdessen ein getrennter Schließen-Button notwendig...
Daneben denke ich, dass man den Hintergrund nicht oft ändert und 
entsprechend eine Trennung zu den Instrumenten nicht schlecht ist. Aber 
ich bin auch für andere Ideen offen.

> Bzgl. der "Verfügbaren Schnittstellen" langt es doch, die mögliche
> Auswahl bei "Serielle Schnittstelle/Port" entsprechend zu beschränken !?
Schon, aber das wäre ein zusätzlicher Aufwand. Ich denke die Anzeige der 
verfügbaren Schnittstellen ist schon ein gewisser Luxus~~
Es soll auch keine Erschwernis zum Einstellen von Schnittstellen geben, 
die noch gar nicht angeschlossen/verfügbar sind.

> Für das Optionsmenü beim Rechtsklick auf Instrumente im Bearbeiten-Modus
> hätte ich noch den Vorschlag, dieses um die "Löschen" Funktion zu
> erweitern. Die explizite Entfernen-Taste ließe sich so auch noch
> einsparen !?
Der Rechtsklick-Eintrag ist eine gute Idee! Mit der Entfernen-Taste muss 
ich noch schauen. Das ganze Bearbeiten-Menü ist noch ein Provisorium, 
wahrscheinlich werde ich einige Instrumente zusammenfassen und in einem 
Untermenü auswählbar machen. Es zeigt sich ja jetzt schon ein gewisses 
Platzproblem. Symbole fehlen auch noch.

> Wäre es ggf. möglich, zumindest das untere Konfigurations-Panel im
> Ausführen-Modus im Interesse von mehr Instrumentenplatz ausblendbar zu
> machen? Die Funktionalität ließe sich doch auch in die Icon-Leiste
> verlagern !?
Ich tendiere eher zu einem echten Vollbild- bzw. Vollfenstermodus. Im 
Eck gibt es dann noch einen Button Verbinden/Trennen und einen zum 
Schließen des Vollbildes. Öffnen des Projektes über die Kommandozeile 
und starten im Vollbildmodus hab ich auf dem Schirm. Aber alles Schritt 
für Schritt.

> Ein wichtiges Instrument fehlt übrigens noch: Ein schöner Einsteller zur
> Vorgabe von Werten (Schieberegler) !
Das ist wahr~
Ich bin gerade an einer Balkenanzeige, die wird auch die Möglichkeit zur 
Ausgabe bieten. Kommt also bald.


Es freut mich, dass Interesse besteht!

Grüße

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4551898:
> Test-Ergebnis:
> -> UDP String wird in einem Instrument Fernanzeige angezeigt!
> -> String aus einem Instrument Zeichenausgabe wird auf der COM
> ausgegeben!
> -> UDP String wird aber leider nicht auf COM ausgegeben.
Achso, Zeichenketten werden für den E/A-Kanal bisher nicht unterstützt, 
nur Zahlenwerte ("F"). Hab ich ganz vergessen umzusetzen! Ich kümmer 
mich darum.

> Getestet mit Kanalnummer 1/50 ohne/mit aktiviertem Kanalfilter.
> Soweit ich im Bilde bin sollten doch zumindest die Kanalnummer-Inputs
> #1-49 mit aktiviertem Kanalfilter an alle Schnittstellen gehen?
#1-49 gehen immer an alle Schnittstellen. #50-999 gehen bei aktiviertem 
Kanalfilter an die Schnittstelle(n), wo der Kanal im eingestellten 
Bereich liegt, bei deaktiviertem Kanalfilter an alle Schnittstellen.

> Zweite Frage zum neuen E/A-Kanal Instrument: Inwieweit/wodurch ist
> dieses Instrument (lt.Konfigurations-Beschreibung) in der Lage, Daten
> von einer Schnittstelle an die andere weiterzuleiten, wenn doch als
> Parameter nur Kanalnummern zulässig sind? Vielleicht kannst Du das
> nochmal etwas erhellen.
Die Beschreibung ist vielleicht eine bisschen missverständlich, eine 
Kanal-Schnittstellenzuordnung kann nur über den Kanalfilter in der 
Schnittstelle erfolgen.
Ein eingehender Wert im E/A-Kanal löst die Berechnung aus und veranlasst 
die Ausgabe auf den angegebenen Kanal. Dieser Kanal/Befehl wird dann je 
nach Kanalfilter auf die entsprechenden Schnittstellen verteilt. Es kann 
also auch nur ein Kanal pro E/A-Kanal weitergeleitet werden
Beispiel:
COM1 mit Filter #50-99
COM2 mit Filter #100-149
/E/A-Kanal/ Eingang: #50; Ausgang #100.
Eingang #50F37; auf COM1 würde zur Ausgabe von #100F37; auf COM2 führen.

> Hintergrund der ganzen Sache: Verwende die Bedienoberfläche von
> http://netio.davideickhoff.de/de/ fürs Tablett und muß eingehende Werte
> unbedingt (auch) an den MC weiterleiten.
Verträgt sich das mit dem Format? Oder brauchst du eine Weiterleitung 
von Freitext?

>> Wenn man auf den Hintergrund klickt schließt sich ja der
>> Eigenschafteneditor (egal welches Instrument offen war), wie ich denke
>> eine recht intuitive Reaktion.
> Klickt man auf Instrumente, öffnet sich der entsprechende
> Konfigurations-Dialog. Klickt man auf den Hintergrund, öffnet sich halt
> der Dialog für den Hintergrund- so fände ich das eingängig.
>
>> Diese Funktion würde man verlieren, wenn
>> stattdessen die Hintergrundeigenschaften aufgehen würden.
>
> Nun, man klickt zur Sichtbarmachung der gesamten Bedienoberfläche
> einfach außerhalb dieses  Bereichs... Oder, noch eindeutiger, die
> Konfiguration hat ein kleines Schließen-Kreuz.
Hm, außerhalb bliebe nur noch die Menü-Leiste... Ich muss mir das noch 
überlegen. Stört der Extra-Button für die Hintergrundeinstellung so 
sehr?

>> Ich bin gerade an einer Balkenanzeige, die wird auch die Möglichkeit zur
>> Ausgabe bieten. Kommt also bald.
>
> Prima. So ist's recht ;-)
Sieht auch schon schick aus:-)

[Moby A. (moby-project)]

Guten Morgen,

danke für die Erläuterungen zur Weiterleitung.

Est Est E. schrieb:
> Achso, Zeichenketten werden für den E/A-Kanal bisher nicht unterstützt

Achso, und ich dachte, da wird beliebiges weitergeleitet...

> Verträgt sich das mit dem Format? Oder brauchst du eine Weiterleitung
> von Freitext?

Den Buttons in NetIO können beliebige Strings zugeordnet werden. Damit 
wäre zwar ebenso ein numerisches F-Kommando denkbar aber ich möchte das 
als dieselben Text-Kommandos
auch vom Instrument Zeichenausgabe ab PC an den MC/COMx absetzen können. 
Freitext wär auch nicht schlecht wenn es keinen großen Mehraufwand 
bedeutet, weil der von NetIO in Form einer eingebbaren Nachricht erzeugt 
werden kann.

> Stört der Extra-Button für die Hintergrundeinstellung so
> sehr?

Nein. Zumal die Oberfläche ja offensichtlich ohnehin noch ein 
Provisorium darstellt.
Ich mach mir nur Gedanken wie so ein Interface optimal gestaltet werden 
könnte.

[Est Est E. (comvisu)]

Moby A. schrieb:
> Est Est E. schrieb:
>> Achso, Zeichenketten werden für den E/A-Kanal bisher nicht unterstützt
> Achso, und ich dachte, da wird beliebiges weitergeleitet...
In der nächsten Version wird das dann auch so sein. Wie gesagt, hab ich 
einfach nicht dran gedacht...

>> Verträgt sich das mit dem Format? Oder brauchst du eine Weiterleitung
>> von Freitext?
> Freitext wär auch nicht schlecht wenn es keinen großen Mehraufwand
> bedeutet, weil der von NetIO in Form einer eingebbaren Nachricht erzeugt
> werden kann.
Das wäre schon was Größeres. Wenn keine Kanäle verarbeitet werden, 
müsste die Weiterleitung ja auf Schnittstellenebene stattfinden. Allein 
vom Ablauf wäre es schwierig, da die serielle Schnittstelle ja keine 
Packete kennt. Wenn die weitergeleiteten Bytes dann von einem Befehl 
zerhackt würden (z.B. Benutzer drückt gerade einen Knopf), hätte man von 
der Weiterleitung auch nichts. Das heißt, man bräuchte doch wieder ein 
Minimalprotokoll, welches Anfang und Ende markiert...

[rodnas (Gast)]

Guten Abend,

zur Erinnerung:

Anno....haben wir schon über ein F-kodiertes Ausgabegerät gesprochen 
ähnlich wie Zeichenausgabe mit S-Kodierung.

Gruss

rodnas

[Est Est E. (comvisu)]

rodnas schrieb:
> Anno....haben wir schon über ein F-kodiertes Ausgabegerät gesprochen
> ähnlich wie Zeichenausgabe mit S-Kodierung.
Hab ich auch nicht vergessen;-)
Wird auch bald kommen, aber eins nach dem Anderen~

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4553364:
> Moby A. schrieb im Beitrag #4553133:
>> P.S. Ich sehe gerade, daß z.B. ein #2F11; von UDP ebenfalls nicht an
>> COM durchgereicht wird (aber korrekt in der Digitalanzeige empfangen).
> Keine Panik, es wird weitergeleitet, hatte den E/A Kanal da nicht
> richtig konfiguriert. Der verweist nun nur von Kanal 2 auf Kanal 2...
Da bin ich ja beruhigt~ Wenn der gleiche Kanal angegeben ist, müsste 
trotzdem eine Ausgabe erfolgen, eben auf dem gleichen Kanal, quasi ein 
Echo.

>> Wenn die weitergeleiteten Bytes dann von einem Befehl
>> zerhackt würden (z.B. Benutzer drückt gerade einen Knopf), hätte man von
>> der Weiterleitung auch nichts.
> Das müsste dann aber schon sensationell zeitgleich sein- und selbst in
> diesem unwahrscheinlichen Fall drückt man halt nochmal ;-)
Es kommt natürlich auf die Anwendung drauf an. Wenn man zyklisch Daten 
überträgt (z.B. Sensordaten im 10tel Sekunden Rhythmus), passiert eine 
Überschneidung schnell. Zwar kann man sich sowieso nie drauf verlassen, 
dass alle Daten über die Schnittstelle richtig ankommen, aber einen 
Datensalat per Design will ich dann doch vermeiden...

[Est Est E. (comvisu)]

Version 0.42 mit folgenden Neuerungen:
- Neues Instrument Balkenanzeige. Das Instrument kann je nach 
ausgewähltem Modus als analoge Anzeige (Steuerung über Schnittstelle) 
von Zahlenwerten und/oder zur Ausgabe von Werten (Steuerung per Maus) 
verwendet werden. Der Balken kann horizontal und vertikal ausgerichtet 
werden. Einsatzmöglichkeiten sind die Anzeige von Messwerten, als 
Fortschrittsbalken, zum Einstellen von Parametern etc..

- Instrument E/A-Kanal kann nun auch Zeichenketten weiterleiten. Ist der 
Eingang mit einer Formel definiert, d.h. nicht nur ein Kanal, dann nimmt 
das Instrument entsprechend nur Zahlenwerte an. Ist als Eingang nur ein 
einzelner Kanal angegeben, funktioniert die Weiterleitung von 
Zahlenwerten und Zeichenketten auch gleichzeitig.

- Es gibt neue Funktionen, welche in allen numerischen Eingängen 
verwendet werden können: Sqrt, nRoot, eule, Log, Ln, abs, sin, cos, tan, 
arcsin, arccos, arctan, deg und rad.
Mehr Details dazu in der Dokumentation. Die Namen sind ja schon recht 
selbstredend.

- Löschen von Instrumenten im Kontext-Menü möglich
- Tastenkombination Speichern (Strg+S) und Öffnen (Strg+O) implementiert
- Diverse kleinere Ausbesserungen

[rodnas (Gast)]

Balkeninstrument: sehr schöne flexible Lösung!

Wünschenswert wäre beim Verstellen zum Senden den aktuellen Wert digital 
einblenden

Gruss

rodnas

[Est Est E. (comvisu)]

rodnas schrieb:
> Balkeninstrument: sehr schöne flexible Lösung!
War auch ein Haiden Aufwand;-)

> Wünschenswert wäre beim Verstellen zum Senden den aktuellen Wert digital
> einblenden
Hmm, wo im Instrument stellst du dir das vor? Es sollte ja nicht den 
Balken verdecken...

[rodnas (Gast)]

Nur temporär einblenden, während der Einstellung. So das beim Ziehen 
angezeigt wird und beim Loslassen, wenn die Datenübertragung ausgelöst 
ist  ausgeblendet wird. Die Anzeige könnte so sogar im Balkenbereich 
untergebracht werden.

Grüsse

rodnas

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4557969:
> Wenn sich nur hinter der großen Flexibilität nicht die beabsichtigte
> Einsparung eines separaten Einsteller-Instruments verbirgt... ;-)
Da hast du mich durchschaut...
Was ich mir aber vorstellen könnte, ist die Analoganzeige noch mit einem 
(optionalen) Schieber auszustatten. Die Problematik mit dem fehlenden 
Digitalwert bleibt dann aber genauso bestehen.

rodnas schrieb:
> Nur temporär einblenden, während der Einstellung. So das beim Ziehen
> angezeigt wird und beim Loslassen, wenn die Datenübertragung ausgelöst
> ist  ausgeblendet wird.
Vielleicht ist das doch eine gute Lösung, ich mach mir mal Gedanken 
dazu.

Moby A. schrieb im Beitrag #4557969:
> Nicht nur die jetzt fehlende Anzeige des aktuellen Einstellwerts,
Du meinst, es gehört auf jeden Fall eine Digitalanzeige dazu?

Ein Problem bei einem Einstellregler ist auch in welchen Stufen der Wert 
einstellbar sein soll.
Anhand der Pixel -> gibt krumme Werte
Anhand der Skala -> wahrscheinlich meißtens zu grob
Anhand einer separat einstellbaren Teilung -> nicht sehr intuitiv

Bei der Balkenanzeige ist das jetzt Balkenweise.


> Est Est E. schrieb:
>> Instrument E/A-Kanal kann nun auch Zeichenketten weiterleiten
>
> Getestet und für gut befunden!
:-) Freut mich

Als nächstes möchte ich mich an das Instrument zur numerischen 
Digitalausgabe machen. Scheint es euch sinnvoller, das als eigenes 
Instrument, oder einstellbar in die Digitalanzeige zu integrieren?

Grüße

[Est Est E. (comvisu)]

Da ist grad was durcheinandergeraten, also nochmal:

Moby A. schrieb im Beitrag #4557969:
> Mit diesen entscheidenden Fortschritten kann ich wohl nun langsam die
> Umprogrammierung des PC-Visualisierungs- Interfaces meiner MC-Steuerung
> in Angriff nehmen, denn:
> -> Von den Instrumenten können beliebig viele verwendet werden
> -> Es können unterschiedlichste Quellen gleichzeitig angezapft und in
> gleicher Weise wie Comvisu-Ausgaben an den MC weitergeleitet werden
> -> Das Programm bietet mit einer unbegrenzten Anzahl von
> Instrumenten-Desktops viel Platz und damit auch die Möglichkeit,
> funktionell sehr fein zu strukturieren
> -> Das Programm funktioniert ohne Einschränkungen zeitlich unbegrenzt!
Die Punkte kann ich so bestätigen und das wird auch so bleiben (keine 
Beschränkungen!). Wie es mit der Leistungsfähigkeit bei größeren 
Projekten aussieht muss sich aber erst zeigen. Große Tests konnte ich 
bisher nicht machen. Ich freu mich also auch in dieser Beziehung über 
Rückmeldungen!

[rodnas (Gast)]

Meines Erachtens die ideale Lösung ist wie Zeichenausgabe nur mit 
F-Kodierung. So ist das Erscheinungsbild kompatibel.

noch etwas fällt mir ein:
bei der Schnittstellenkonfigurierung kann man mehrere COM bzw. UDP 
Verbindungen einrichten. Die an der obersten Stelle ist aktiv. Diese 
Priorität sollte man wählbar machen da ein Wechsel jetzt mit Löschen 
verbunden ist. (oder bin ich zu doof)
Außerdem die Speicherung der Einstellungen ist noch nicht vollkommen. 
(UDP)

Grüsse

rodnas

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4558059:
> Ja. Besser diese Lösung als die umständlichere Variante, mit dem
> Balkeninstrument grafisch etwas einzustellen, Richtung ->MC zu schicken
> und dann mit dem MC-> den aktuell eingestellten Wert erst wieder via
> Comvisu ausgeben zu müssen... Die geplante numerische Zeichenausgabe
> erfüllt zwar den gleichen Zweck- aber nur auf Kosten reiner bequemer
> Maus-Bedienbarkeit.
Ok, ich integrier einen Schieber in die Analoganzeige und die 
Möglichkeit den zugehörigen Digitalwert anzeigen zu lassen (Neben dem 
Namen). Ein extra Instrument für die numerische Ausgabe soll es trotzdem 
geben. Einen Digitalwert für die Balkenanzeige spar ich mir dann aber.


>> Ein Problem bei einem Einstellregler ist auch in welchen Stufen der Wert
>> einstellbar sein soll.
>> Anhand der Pixel -> gibt krumme Werte
>> Anhand der Skala -> wahrscheinlich meißtens zu grob
>> Anhand einer separat einstellbaren Teilung -> nicht sehr intuitiv
>
> Der digitale Einstellwert korrespondiert einfach mit der grafischen
> Position im Einstellbereich- und dank aktueller digitaler Anzeige bzw.
> Skala bestehen keine Unklarheiten. Krumme Werte werden entsprechend der
> einzustellenden Abstufung auf/abgerundet. Stelle ich mir das zu einfach
> vor?
Das wäre ja dann die 3te Variante, anhand einer einstellbaren Teilung. 
Das halte ich auch für die beste Lösung.

rodnas schrieb:
> bei der Schnittstellenkonfigurierung kann man mehrere COM bzw. UDP
> Verbindungen einrichten. Die an der obersten Stelle ist aktiv. Diese
> Priorität sollte man wählbar machen da ein Wechsel jetzt mit Löschen
> verbunden ist. (oder bin ich zu doof)
> Außerdem die Speicherung der Einstellungen ist noch nicht vollkommen.
> (UDP)
Wie Moby gesagt hat, hat das ja nur fürs Terminal ein Auswirkung. Ich 
wollt auch mal eine Auswahlbox integrieren, dass man im Terminal die 
relevante Schnittstelle auswählen kann. Hab ich aber wieder vergessen, 
mal schauen wann ich dazu komme.

Die UDP-Einstellungen sollten funktionieren, habs grad nochmal getestet. 
Wichtig ist, dass man vor dem Speichern der Einstellungen das 
Editierfeld verlassen hat oder mit Enter bestätigt, sonst ist die letzte 
Änderung unter Umständen noch nicht übernommen (wird anschließend aber 
übernommen).

[Moby A. (moby-project)]

Est Est E. schrieb:
> Ok, ich integrier einen Schieber in die Analoganzeige und die
> Möglichkeit den zugehörigen Digitalwert anzeigen zu lassen (Neben dem
> Namen).

Das wäre eine Möglichkeit. Hauptsache ein Wert lässt sich maustechnisch 
und mit Rückmeldung ausgeben.

[rodnas (Gast)]

Guten Abend,

1. Frage: besteht die Möglichkeit die Instrumente mit der Option 
ausstatten, am Display frei nach "Vorne" oder nach "Hinten" zu setzen?
So könnte man schöne platzsparende Kombiinstrumente "bauen" ohne 
Beschränkungen.

2. Frage: existiert eine allgemein gültige Syntax zur 
Eingangsbeschaltung mit Mathefunktionen? zB. #5^(1/2) funktioniert aber 
#5 sqrt  #5sqrt #5(sqrt) oder #5 (sqrt) nicht.

Grüsse

rodnas

[Carl D. (jcw2)]

Einfacher Trick:
Handbuch lesen, da steht:
sqrt(#5)
Genau so wie man es erwarten würde.
Du bist nicht zufällig HP-Taschenrechner-Geschädigt?    ;-)

[rodnas (Gast)]

Es geht um die Nummerische Digitalanzeige und nicht um das 
Ein-Ausgabegerät.

[Est Est E. (comvisu)]

rodnas schrieb:
> Guten Abend,
> 1. Frage: besteht die Möglichkeit die Instrumente mit der Option
> ausstatten, am Display frei nach "Vorne" oder nach "Hinten" zu setzen?
> So könnte man schöne platzsparende Kombiinstrumente "bauen" ohne
> Beschränkungen.
Das ist schon implementiert (wenns das ist, was du meinst). Einfach mit 
der rechten Maustaste auf das entsprechende Instrument klicken und "nach 
vorne" oder "nach hinten" klicken. Für das Instrument bedeutet das 
jeweils ganz nach vorne bzw. hinten. Stufenweise ist nicht möglich, 
ich denke, das brauchts auch nicht.


> 2. Frage: existiert eine allgemein gültige Syntax zur
> Eingangsbeschaltung mit Mathefunktionen? zB. #5^(1/2) funktioniert aber
> #5 sqrt  #5sqrt #5(sqrt) oder #5 (sqrt) nicht.

Carl D. schrieb:
> Einfacher Trick:
> Handbuch lesen, da steht:
> sqrt(#5)
> Genau so wie man es erwarten würde.
Genau, die Syntax gilt so für alle Funktionen und für alle numerischen 
Eingänge. Stringeingänge können keine Formel verarbeiten.
Numerische Eingänge sind alle, welche einen Befehl mit "F"-Formatierung 
annehmen. Man kann Funktionen natürlich auch schachteln,z.B.

if(#5>0;sqrt(#5);0))

rodnas schrieb:
> Es geht um die Nummerische Digitalanzeige und nicht um das
> Ein-Ausgabegerät.
Beim Eingang gibt es zwischen diesen Instrumenten keinen Unterschied.

PS: Hab grad noch einen Fehler entdeckt, Vorzeichen-Minus in Eingängen 
führen zu falschen Ergebnissen. Das Rechenzeichen-Minus ist davon nicht 
betroffen. Bei der nächsten Version wird es dann behoben sein.

[Est Est E. (comvisu)]

Version 0.43 mit folgenden Neuerungen:
- Neues Instrument 'Numerische Ausgabe'. Funktion wie die Digitalanzeige 
nur in umgekehrter Richtung.
- Analoganzeige ist erweitert mit einem optionalen Schieberegler. 
Außerdem kann die Anzeige nun horizontal oder vertikal ausgerichtet 
werden und der Wert kann digital angezeigt werden. Die Einstellschritte 
beim Schieberegler können eingestellt werden, standardmäßig sind es 20 
Schritte.
- Angepasstes Menü, die Instrumente (Hinzufügen) sind jetzt gruppiert.

[rodnas (Gast)]

Einfach SUPER!!!

[rodnas (Gast)]

Jetzt kommt die Bearbeitung der Schnittstelle? :-)

Danke Est Est Est

Grüsse

rodnas

[Est Est E. (comvisu)]

rodnas schrieb:
> Einfach SUPER!!!
:-)

rodnas schrieb:
> Jetzt kommt die Bearbeitung der Schnittstelle? :-)
Was meinst du damit?
Die Auswahlmöglichkeit für das Terminal?

Grüße

[rodnas (Gast)]

Genau.
Wenn man mehrere Einträge hat, dann mit einem Klick eine Auswahl treffen 
kann. Eventuell Parallelbetrieb für UDP-UDP bzw. UDP-UART

[rodnas (Gast)]

Beim Wechsel Ausführen > Bearbeiten kam die Fehlermeldung und Absturz.
Programm beenden ist nur über Prozessbeendung möglich.

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4573861:
> Ganz fehlerfrei scheint der Analogschieber noch nicht zu sein:
> Die Zeigerfarbe lässt sich nur für den Eingabemodus festlegen ?!
Ja, die Zeigerfarbe lässt sich nur für den Eingang festlegen. Der 
Schiebezeiger hat (zur besseren Unterscheidung) Konturen. Das für 
beliebige Farben umzusetzen ist deutlich schwieriger.

rodnas schrieb:
> Genau.
> Wenn man mehrere Einträge hat, dann mit einem Klick eine Auswahl treffen
> kann.
OK.
> Eventuell Parallelbetrieb für UDP-UDP bzw. UDP-UART
Was meinst du damit? Kannst du das ein bisschen präzisieren?

rodnas schrieb:
> Beim Wechsel Ausführen > Bearbeiten kam die Fehlermeldung und Absturz.
> Programm beenden ist nur über Prozessbeendung möglich.
Oh, oh.
Auf den ersten Blick sagt mir der Fehler nichts. Kannst du beschreiben, 
was du gemacht hast: War die Schnittstelle zu diesem Zeitpunkt noch 
verbunden, wenn ja, welche Schnittstelle(n) waren das? COM? UDP? Sind 
kontinuierlich Daten eingegangen?
Ist der Fehler reproduzierbar?

EDIT: Es scheint was mit dem Senden auf der seriellen Schnittstelle zu 
tun haben. Hast du exzessiv Daten gesendet, sodass die Schnittstelle 
evtl. nicht hinterhergekommen ist?

[rodnas (Gast)]

Die Fehlermeldung: COM war in Betrieb, bewusst, also per Hand ausgelöst 
keine Daten gesendet. Getaktete Sendeinstrument ist noch nicht 
implementiert also ich denke das durch die Umschaltung bedingte 
Unterbrechung der COM Schnittstelle war der Auslöser. Übrigens, es kam 
schon mehrmals vor aber jetzt konnte ich eine Handlung zuordnen.

[rodnas (Gast)]

> Eventuell Parallelbetrieb für UDP-UDP bzw. UDP-UART
> Was meinst du damit? Kannst du das ein bisschen präzisieren?

Ich dachte zB. 2 µC der 1. ist auf COM der 2. ist auf UDP getrimmt 
speisen ihre Daten in den Rechner ein. Nur eine laienhafte Gedanke. 
Zugegeben ich bin kein Programmierer, nur Konsumierer. :-(

[Est Est E. (comvisu)]

rodnas schrieb:
> Die Fehlermeldung: COM war in Betrieb, bewusst, also per Hand ausgelöst
> keine Daten gesendet. Getaktete Sendeinstrument ist noch nicht
> implementiert also ich denke das durch die Umschaltung bedingte
> Unterbrechung der COM Schnittstelle war der Auslöser. Übrigens, es kam
> schon mehrmals vor aber jetzt konnte ich eine Handlung zuordnen.
Aber nachstellen kannst du es nicht, oder? D.h. es tritt nur sporadisch 
auf?

rodnas schrieb:
> Ich dachte zB. 2 µC der 1. ist auf COM der 2. ist auf UDP getrimmt
> speisen ihre Daten in den Rechner ein. Nur eine laienhafte Gedanke.
> Zugegeben ich bin kein Programmierer, nur Konsumierer. :-(
Beim Terminal ist das Problem, dass sich Befehle von unterschiedlichen 
Schnittstellen überschneiden können. Außerdem müssten die 
unterschiedlichen Datenquellen auch irgendwie gekennzeichnet sein. Was 
ein großer Aufwand für meines Erachtens einen minimalen (bis keinen) 
Nutzen ist. Was eine Möglichkeit wäre, ist die gefilterten Befehle aller 
Schnittstellen zu zeigen, aber da besteht wieder das Problem mit der 
Zuordnung zur jeweiligen Schnittstelle...
Im Normalbetrieb, wenn die Kommunikation mal fertig eingerichtet ist, 
braucht man das Terminal doch gar nicht mehr.

[rodnas (Gast)]

Der erwähnte Fehler ist nicht reproduzierbar.

Bei der Schnittstelle, im Grunde genommen wichtig ist nur die 
Möglichkeit der schnelle Prioritätswahl.

[rodnas (Gast)]

Jetzt eben habe ich wieder die Fehlermeldung gehabt. Wie du vermutet 
hast, jetzt nach mehrmaligen Sendeversuch und ein Trennvorgang.

[Est Est E. (comvisu)]

rodnas schrieb:
> Jetzt eben habe ich wieder die Fehlermeldung gehabt. Wie du vermutet
> hast, jetzt nach mehrmaligen Sendeversuch und ein Trennvorgang.
Ich hab den Fehler gefunden. Sollte mit der nächsten version dann 
behoben sein.

[rodnas (Gast)]

Guten Morgen.

ich habe ein Problem. Wenn ich mit dem Analoganzeige/Schieber einen 
Single Wert sende zB. 24,1 - 24,9  wird bei mir immer nur als Integer 
Wert 24 anerkannt (verarbeitet, zurückgemeldet). Nachkommastelle 1 
eingestellt.

rodnas

[rodnas (Gast)]

Jetzt habe ich entdeckt. Dezimalzeichen wird als Komma gesendet, 
vermutlich deshalb wird abgeschnitten.

[rodnas (Gast)]

Besteht die Möglichkeit in der Konfigurationsmodi diesbezüglich eine 
frei Wahl treffen?

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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.

[rodnas (Gast)]

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

[rodnas (Gast)]

> Bemerkung: Bildanzeige funktioniert nicht mehr.

Entschuldigung, meine eigene Dummheit war die Ursache.

Gruß

rodnas

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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.

[rodnas (Gast)]

Instrument Numerische Ausgabe: Die eingestellte Wert wird nicht 
abgespeichert.

[Est Est E. (comvisu)]

Es gibt jetzt auch eine Linuxversion, dazu habe ich einen neuen Thread 
aufgemacht, Download dort:

Beitrag "Comvisu für Linux"

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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~

[Werner A. (gnuopfer)]

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 !

[Est Est E. (comvisu)]

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:-)

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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:-)

[rodnas (Gast)]

Hallo Est Est Est,

alle Achtung, wieder super Leistung!

Danke

rodnas

[Est Est E. (comvisu)]

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

[Est Est E. (comvisu)]

Moby A. schrieb im Beitrag #4640685:
> Habe gerade nochmal die Zeichenausgabe getestet
OK, das Problem tritt bei mir auch auf, ich schau mirs an.

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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

[Est Est E. (comvisu)]

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.

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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.

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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.

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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

[hallo (Gast)]

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?

[Est Est E. (comvisu)]

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.

[Alex (Gast)]

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

[Est Est E. (comvisu)]

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

[Alex (Gast)]

Alles klar, Vielen Dank.

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

Gut, dass du mich erinnerst. Ich fang grad mal damit an~

[Est Est E. (comvisu)]

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ß~

[rodnas (Gast)]

Ehre, wem Ehre gebührt!

Lob, Lob, Lob

rodnas

[Est Est E. (comvisu)]

Danke :-)

[Alex (Gast)]

Perfekt. Danke.

[rodnas (Gast)]

Hallo Est Est Est,

Wäre der Aufwand zu groß für LED-s bzw. Fernanzeige eine zuschaltbare 
Blinkfähigkeit anzuheften?

Grüße

rodnas

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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

[Est Est E. (comvisu)]

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.

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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.

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

Alles klar, dann hab ichs soweit verstanden und versuch mich mal daran~

Grüße

[Est Est E. (comvisu)]

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?

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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?

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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~

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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?

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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.

[http (Gast)]

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.

[Est Est E. (comvisu)]

Gibt es dann sonst etwas, das gegen POST und die Übertragung der Befehle 
im Dateibereich sprechen würde?

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

Hallo Est Est Est,


Lookup-Tabelle

Wertetabelle: Fehler beim Laden der Datei


Grüße

rodnas

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

Es funktioniert!!! :)
Jetzt habe ich mit Windows Editor erstellt.
Früher mit Open Office aber auch als txt abgespeichert und 
fehlgeschlagen.

Danke!

rodnas

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

Rodnas, vielen Dank!

Ebenso ein gutes Neues!

[Tom W. (Gast)]

Auch von mir die besten Wünsche. Muss mich jetzt mir dem Proggi mal 
befassen!

[J. S. (engineer)]

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.

[Udo (Gast)]

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!

[Est Est E. (comvisu)]

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!

[rodnas (Gast)]

Hallo Est Est Est,

es wäre nicht schlecht beim Terminal einen ein-ausschaltbare 
Zeilenumbruch hinzufügen.

Gruß

rodnas

[J. S. (engineer)]

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.

[Est Est E. (comvisu)]

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

[Weinga U. (weinga-unity)]

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

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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

[H. S. (Gast)]

Gibt es das auch für Linux?

[Est Est E. (comvisu)]

Unter
Beitrag "Re: Comvisu für Linux"
oder
http://comvisu.de

[Weinga U. (weinga-unity)]

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.

[H. S. (Gast)]

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.

[Est Est E. (comvisu)]

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~

[Lutz H. (luhe)]

Es gibt keinen Artikel über Comvisu,
dadurch ist die Information schwer zu finden.

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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~

[R. Manfred B. (pwgdrx)]

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ß

[Est Est E. (comvisu)]

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.

[R. Manfred B. (pwgdrx)]

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ß

[Est Est E. (comvisu)]

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

[Cihan S. (cihan_s)]

Ist eine UDP Unterstützung geplant?

[Est Est E. (comvisu)]

UDP wird bereits seit der Version 0.3 unterstützt. Einfach mal die 
aktuelle Version testen~

[Sebastian__ (Gast)]

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

[Est Est E. (comvisu)]

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

[Sebastian__ (Gast)]

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.

[Est Est E. (comvisu)]

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 :-)

[Sebastian__ (Gast)]

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

[Sebastian__ (Gast)]

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.

[Est Est E. (comvisu)]

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

[Est Est E. (comvisu)]

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

[Tobias K. (kurzschluss81)]

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.

[Est Est E. (comvisu)]

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

[H. S. (Gast)]

Welche Einsatzgebiete gäbe es, wo "zwei Instanzen kommunizieren"??

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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.

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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?

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[H. S. (Gast)]

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.

[Est Est E. (comvisu)]

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?

[Günter (galileo14)]

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.

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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.

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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!

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

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

[Weinga U. (weinga-unity)]

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 :-)

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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

[H. S. (Gast)]

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?

[Est Est E. (comvisu)]

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.

[Günter (galileo14)]

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

[H. S. (Gast)]

Für mich wäre das auch interessant. Das Programm kann man sich dann auch 
ruhig ein paar Euros kosten lassen!

[Est Est E. (comvisu)]

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.

[H. S. (Gast)]

In unserem Fall wäre es vermutlich durchaus eine kommerzielle Nutzung.

[Est Est E. (comvisu)]

Dann schreib mich mal an, wir werden uns sicher auf etwas einigen.
webmaster (ät) comvisu.de

Viele Grüße

[Sebastian (Gast)]

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

[Est Est E. (comvisu)]

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

[Sebastian (Gast)]

Hallo Est Est Est,

ja, das Problem ist klar reproduzierbar.

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

Hallo Est Est Est,

gute Beschreibung, danke!

So probiere ich es.

Günter

[Günter (galileo14)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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~

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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~

[Günter (galileo14)]

Super. Vielen Dank schon mal. Bin gespannt auf die nächste Version. 
Aber: kein Streß! Laß Dir Zeit.

Günter

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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.

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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.

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[rodnas (Gast)]

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.

[Waldemar N. (waldemarn)]

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!

[Günter (galileo14)]

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

[Heiko (Gast)]

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?

[rodnas (Gast)]

Hallo Heiko,

theoretisch ist machbar. Hintergrundbild ist deine Gleisanlage. Taster, 
Schalter, LED nach Bedarf einsetzen  und dein Programm ComVisu gerecht 
anpassen.

Gruß

[Günter (galileo14)]

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

[Karl Z. (griffin27)]

subscribe

[Karl Z. (griffin27)]

@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 :)

[Georg B. (georgb)]

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

[Est Est E. (comvisu)]

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~

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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~

[Ulrich K. (klappstuhl_1)]

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

[Est Est E. (comvisu)]

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

[Ulrich K. (klappstuhl_1)]

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. (klappstuhl_1)]

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

[Est Est E. (comvisu)]

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

[Ulrich (Gast)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

Das freut mich zu hören, danke für die Rückmeldung!

[Est Est E. (comvisu)]

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"

[Günter (galileo14)]

Hallo Est,

toll, da freue ich mich drauf. Werds demnächst testen, und du hörst von 
mir.

Danke!

Viele Grüße
Günter

[rodnas (Gast)]

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

[rodnas (Gast)]

Hallo Est Est Est,

bei Taktausgabe wird Ausgabewert zeigen nicht abgespeichert.

Grüße

rodnas

[Olaf T. (olaf_t)]

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

[Est Est E. (comvisu)]

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.

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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.

[rodnas (Gast)]

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.

[Ralf H. (hilti68)]

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

[Est Est E. (comvisu)]

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

[Ralf H. (hilti68)]

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

[Est Est E. (comvisu)]

Hallo Ralf,

implementiert ist es schon, habe aber sonst noch ein paar Sachen 
geändert, was noch nicht abgeschlossen ist. Also dauert noch etwas.

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

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.

[rodnas (Gast)]

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

[rodnas (Gast)]

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

[Est Est E. (comvisu)]

Hallo rodnas,

bzgl. Textblöcke, stattdessen kannst du die Fernanzeige verwenden, 
einfach den gewünschten Text als Initialwert setzen und den Eingang 
freilassen, das verlangsamt dann auch nicht die Verarbeitung bei 
eingehenden Befehlen.

Die LED-Leite stimmt doch? In deinem dritten Beipiel möchtest du 
scheinbar die Zahl als Binärzahl interpretiert haben, das geht nicht. 
Deine 1001101 is für die Comvisu die Dezimalzahl 1.001.101, also 
Einemilliontausendeinhunderteins. Binär entspricht das dem Wert 
0b1111'01000110'10001101, die LED-Leiste zeigt dann die letzten Stellen 
an.

Es gibt heut noch eine neue Version, den zuvor besprochenen Zeitgeber 
habe ich jetzt nicht eingebaut, da gab es Komplikationen...

[Est Est E. (comvisu)]

Neue Version Comvisu V1.80:
- Ausgangstriggerung: Ab dieser Version werden auch ausgehende Werte in 
die Kanalspeicher geschrieben und führen zur Neuberechnung von 
abhängigen Instrumenten. Dadurch ist eine Vernetzung von Instrumenten 
möglich. Bisher waren ausgehende Kanäle von eingehenden unabhängig. 
Achtung, dadurch ist keine Rückwärtskompatibilität gegeben bei 
Kanälnummern die gleichzeitig als Ein- und Ausgang verwendet wurden. 
Also am Besten alte Projekte gleich daraufhin prüfen.
- Die Kanalliste zeigt nun ein- und ausgehende Kanäle gemeinsam an. 
Außerdem lässt sich für jeden Kanal ein Kommentar eintragen.
- Die Schalterleiste lässt sich nun über einen Steuerkanal fernsteuern.
- Einige Umbauten im Programminneren, die bei der Benutzung keine 
Auswirkung haben sollten.
- Linuxversion nun auf dem neueren QT5 basierend

[rodnas (Gast)]

Hallo Est Est E. ,

Neue Version Comvisu V1.80 gibt's nur in 64 Bit?

Grüße

Rodnas

[Est Est E. (comvisu)]

Ja, brauchst du denn eine 32-Bit-Version?

[rodnas (Gast)]

Ja,unbedingt.

rodnas

PS. Noch eine Bemerkung: Das Zeitdiagramm nach längerem Gebrauch 
verliert die Synchronisation zur PC Zeit. Hilfe ist nur durch Trennen - 
Verbinden möglich.

[Est Est E. (comvisu)]

Mit welcher Windows-Version bist du unterwegs? Ich würde gern Win XP aus 
der Kompatibilität rausschmeißen.

[rodnas (Gast)]

W10_32Bit_neuste Update.

Grüße

rodnas

[Est Est E. (comvisu)]

Es gibt jetzt auch eine 32-Bit-Version, Systemvoraussetzung ab Win 
Vista. Kann auf der Homepage comvisu.de runtergeladen werden. Ich hab 
sie jetzt nicht hier eingestellt um kein Durcheinander zu verursachen.

Wegen dem Diagramm, teste bitte zuerst ob das Problem bei der aktuellen 
Version auch auftritt.

Viele Grüße~

[rodnas (Gast)]

Zuerst, vielen Dank

und sofort eine Frage. Wäre es möglich die Schalterleiste erweitern 
(Anzahl von Schalter) besonders in XOR Modi? So das man mehr als 10 
Befehle aussenden kann?

Grüße
rodnas

[Est Est E. (comvisu)]

Um wieviele geht es denn? Intern ist ein festes Array hinterlegt, das 
wollte ich nicht übertrieben groß machen. Auch wenn heutzutage ja der 
Speicher im Grunde keine Rolle mehr spielt...

[rodnas (Gast)]

Mit 20 wäre ich vollkommen zufrieden. Mein Problem ist das die Schalter 
feste Zuordnung haben 0-9 und so mit einer zweiten Leiste komme ich 
nicht auf 10-20.

Grüße

rodnas

[Est Est E. (comvisu)]

Ja, das kann ich machen. Wird aber dauern, da ich jetzt dafür keine neue 
Version ziehe.

[rodnas (Gast)]

Weitere Frage zur Schalterleiste. Das erste Glied wird immer "gedrückt 
ausgeliefert". Meine Meinung nach wäre die neutrale Stellung (nicht 
gedrückt) besser.

Grüsse

rodnas

[Est Est E. (comvisu)]

Das liegt daran, das der XOR-Modus voreingestellt ist und da gibt es ja 
nicht die Möglichkeit, dass keine Schaltfläche gedrückt ist. Wenn man es 
in den anderen Moden anders braucht, kann man ja den Initialwert setzen. 
Ich hab das jetzt auch etwas angepasst, damit man gleich sieht, was der 
Wert für Auswirkungen hat.

[rodnas (Gast)]

Für heute die letzte Frage:)

Wäre es möglich den Dateirecorder im laufenden Betrieb ein und 
ausschalten?

[Est Est E. (comvisu)]

Eher nicht, das scheint mir schon ne ausgefallene Anforderung zu sein.

[Jochen B. (brummbaehr)]

Moin,

ich habe da ein Problem mit der V1.60 auf einem älteren Windows XP 
Laptop.

Angeschlossen ist ein Arduino-Nano Clone an USB mit CH340G Chip.
Es ist nicht möglich mit Comvisu Daten in Richtung Arduino zu senden.

Im Terminal die Spalte "Gesendete Befehle" bleibt leer wenn ich im 
Textinstrument "Zeichenausgabe" etwas sende.
Erst wenn ich die Verbindung über den Button Schnittstelle "Trennen" 
trenne, dann wird der Wert unter "Gesendete Befehle" angezeigt.

Auf meinem PC mit Win10 64 funktioniert das wunderbar.
Ist das ein bekanntes Problem? Gibt es da eine Abhilfe oder hat jemand 
einen Tip?

Gruß
Jochen

Edit: Mit dem Seriellen Monitor der Arduino IDE funktioniert das Senden 
an den Nano.

[Est Est E. (comvisu)]

Also mit XP hab ich keine Erfahrungen. Hat es denn mit V1.50 noch 
funktioniert?

[Jochen B. (brummbaehr)]

Ich habe die Version V1.10 und V1.60 bei beiden gleiches Verhalten.
V1.50 finde ich wo?

Gruß
Jochen

[Est Est E. (comvisu)]

Sorry, hab nicht jede Version veröffentlicht. Die V1.10 ist dann quasi 
der Vorgänger. Hätte es dort funktioniert, hätte ich nach den Änderungen 
schauen können.

[rodnas (Gast)]

Hallo Est Est E.,

Wäre es möglich im Terminalfenster Zeilenumbruch realisieren?
Eventuell mit Zeilennummer.

Grüße

rodnas

PS.
Update? :-)

[Est Est E. (comvisu)]

Hallo rodnas,

den Zeilenumbruch habe ich implementiert, ist dann in der nächsten 
Version verfügbar.

[rodnas (Gast)]

Hallo Est Est E,

Ist eine Android Version auch geplant?

Grüße

rodnas

[Est Est E. (comvisu)]

Nein, ist nicht geplant. Ich hab mich zwar mal darin versucht, aber der 
Umbau ist zu aufwendig.

[rodnas (Gast)]

Hallo Est Est E,

kommt noch Update nach Wunschliste, mit Feinschliff?

Ansonsten ist das Programm kolossal.

Grüße

rodnas

[Est Est E. (comvisu)]

Ja, es gibt noch Updates :)

[rodnas (Gast)]

Es hört sich gut an :)

[Sandor (rodnas)]

Hallo Est Est E.,

Wäre es möglich ein Instrument bereit zu stellen, welches mehrere 
Ausgänge (z.B. 0-9) mit unterschiedlichen Werten zyklisch bedienen kann, 
vergleichbar mit Taktausgabe?

Grüße
Sandor

[Est Est E. (comvisu)]

Hallo Sandor,

du könntest doch einfach mehrere Taktausgaben verwenden? Vielleicht 
ließe sich auch mit einer Taktausgabe in Verbindung mit E-A-Kanälen was 
machen?

[Sandor (rodnas)]

Hallo Est Est E.,

das war eine gute Empfehlung!!! So konnte ich was brauchbares 
zusammenfädeln.
Was noch vorteilhaft sein könnte, wenn der Ausgabewert vom E/A-Kanal 
auch sichtbar wäre. Man wird auch gierig: bei der Taktausgabe die feste 
Taktzeit alternativ durch eine Variable ersetzen die dann die Taktung je 
nach Bedarf fortlaufend ändern kann? Z.B der Wert eines Eingangskanal?

Grüße
Sandor

[Est Est E. (comvisu)]

Sandor schrieb:
> Was noch vorteilhaft sein könnte, wenn der Ausgabewert vom E/A-Kanal
> auch sichtbar wäre.

Man kann ja den Ausgang wieder in einem anderen Instrument anzeigen 
lassen, siehe Anhang.

>  Man wird auch gierig: bei der Taktausgabe die feste
> Taktzeit alternativ durch eine Variable ersetzen die dann die Taktung je
> nach Bedarf fortlaufend ändern kann? Z.B der Wert eines Eingangskanal?

Was wäre die Anwendung? Man kann sich natürlich Vieles vorstellen, aber 
es ist klar, man kommt da schon an Grenzen mit einer solchen graphischen 
Konfiguration. Letztlich soll das Programm ja auch nicht überladen sein.

[Günter (galileo14)]

Hallo Est Est,

will mich auch wieder mal melden. Ich verwende ja Comvisu (neueste 
Version 1.8 für RaspBerryPi) für die Visualisierung einiger 
Betriebsdaten meiner Heizungs/Solaranlage, siehe Screenshots. Das 
funktioniert prima und läßt eigentlich keine Wünsche offen.

Beim Loggen der Zeitverläufe habe ich aber immer wieder Probleme, die 
Zeit abzulesen bzw. das Datum, speziell dann, wenn man zurückblättert.

Programmierst du die Diagrammanzeige selbst oder wird da eine Bibliothek 
benutzt, sodaß es schwierig für dich wäre, das Layout zu ändern? Meine 
Anregung wäre (für ein zukünftiges Release, eilt ja nicht), die 
Beschriftung zweizeilig auszuführen, etwa in einer oberen Zeile die 
Uhrzeit und darunter die Datumsangabe.

Kannst ja mal darüber nachdenken. In jedem Fall ist Comvisu ein super 
Programm. Danke für deine Mühe.

Viele Grüße
Günter

[Est Est E. (comvisu)]

Hallo Günter,

ja, ich sehe was du meinst. Für das Diagramm verwende ich eine 
Komponente, das Format lässt sich trotzdem anpassen. Nur wie realistisch 
eine zweizeilige Anzeige ist, müsste ich erst schauen. Ich habe mir das 
jetzt auf jeden Fall mal notiert. Also mal sehen :)

[Günter (galileo14)]

Prima, danke schon mal.

[Günter (galileo14)]

Hallo Est Est,

nochmals eine Frage zu den Diagrammen: kann man deren Daten irgendwie 
abspeichern, oder wäre eine Programmerweiterung möglich, damit man deren 
Daten abspeichern und später wieder aufrufen kann?

Viele Grüße
Günter

[Est Est E. (comvisu)]

Hallo Günter,

da habe ich auch schon darüber nachgedacht. Ein Problem ist die 
Zeitbasis. Für absolute Zeiten mit Datum ginge es ja, ggf. hat man halt 
Lücken im Diagramm. Für Kurven, die bei t=0 starten wird es schwieriger, 
das vernünftig zu machen. Auch ist die Frage, wie man mit veränderten 
Diagrammkanälen umgeht.

Bisher ist das Instrument Dateirecorder die einzige Möglichkeit, Daten 
abspeichern zu lassen.

Grüße~

[Günter (galileo14)]

Hallo Est,

okay, das leuchtet ein. Mit Dateirecorder habe ich mich noch nicht 
befaßt, das tue ich jetzt. Interessiert mich, was da wie gespeichert 
wird.

Danke!

Viele Grüße
Günter

[Günter (galileo14)]

Hallo Est Est,

ich habe den Dateirekorder nun getestet bzw. in meine 
Heizungsüberwachung eingebaut. Funktioniert gut. Danke!

Dabei sind mir einige Dinge aufgefallen. Die Sache läuft bei mir ja auf 
einem RaspBerryPi (ARM), der ist kürzlich wegen Stromausfalls um 
Mitternacht ausgefallen; nach Stromrückkehr hatte er neu gebootet, aber 
ComVisu startet natürlich nicht von alleine (Uhrzeit hätte auch nicht 
gestimmt, aber die ist nicht so wichtig). Da muß ich noch nach einer 
Autostart-Lösung suchen.

Daher habe ich jetzt mal die "Einstellungen" und die 
Kommandozeilenparameter näher angeschaut. In den "Einstellungen" habe 
ich nun für Modus "Ausführen" eingestellt. Und als 
Kommandozeilenparameter habe ich "-WindowMaximized" und "-Connect" 
angegeben. Das Fenster ist okay, aber das automatische Verbinden 
funktioniert nicht. Mache ich etwas falsch oder gibt es da - evt. nur 
bei der ARM-Version - ein Problem?

Wäre schön, wenn evt. das WindowMaximized und das automatische Connect 
in den Einstellungen definiert werden könnte, dann bräuchte man diese 
Kommandozeilenparameter nicht, so der Connect dann funktionieren würde.

Noch etwas fiel mir auf: Beim Programmstart wird die letzte definierte 
Registerkarte angezeigt. Lieber wäre mir, es würde die erste definierte 
Registerkarte angezeigt werden. Könnte man dafür evt. auch eine 
Kommandozeilenoption oder eine Einstellungsoption vorsehen bei einer 
nächsten Version?

Nichts davon eilt. Aber vielleicht magst du da mal draufschauen.

Vielen Dank.

Viele Grüße
Günter

[Est Est E. (comvisu)]

Günter R. schrieb:
> Und als
> Kommandozeilenparameter habe ich "-WindowMaximized" und "-Connect"
> angegeben. Das Fenster ist okay, aber das automatische Verbinden
> funktioniert nicht. Mache ich etwas falsch oder gibt es da - evt. nur
> bei der ARM-Version - ein Problem?

Der Connect-Parameter funktioniert nur, wenn man in der Kommandozeile 
auch eine Projektdatei übergibt. Ich vermute, du hast dich auf die 
Einstellung "Letztes Projekt laden" verlassen?

Comvisu.exe test2.visu -WindowMaximized -Connect

Die Kommandozeile hat bei mir unter Windows funktioniert, einen 
Raspberry habe ich gerade keinen aufgebaut.

> Wäre schön, wenn evt. das WindowMaximized und das automatische Connect
> in den Einstellungen definiert werden könnte, dann bräuchte man diese
> Kommandozeilenparameter nicht, so der Connect dann funktionieren würde.
Ja, sollte kein Problem sein.

> Noch etwas fiel mir auf: Beim Programmstart wird die letzte definierte
> Registerkarte angezeigt.
Stimmt, das ist ein Programmfehler, normal sollte immer das erste Blatt 
angezeigt werden. Ich schau danach!

Viele Grüße~

[Günter (galileo14)]

Hallo Est Est,

danke für die Hinweise.

Ja, ich hatte die Einstellung "Letztes Projekt laden." (ist nun 
ausgeschaltet). Nun habe ich die komplette Kommandozeile so eingetippt, 
wie du es vorgegeben hast, und damit funktioniert der Connect perfekt.

Danke!

Gruß, Günter

[Claudio F. (zunge)]

Hi Est Est

Danke für ComVisu... erlösst mich bei vielen Sachen von Labview ...

eine Frage: ich möchte gerne ComVisu für die visualisierung der 
Telemetriedaten eines Roboters verwenden. Dafür würde ich gerne eine 
Draufsicht des Roboters als Hintergrundbild verwenden. Irgendwie schaffe 
ich es nicht ein Bild da reinzuladen. Gibt's da irgendwelche 
Einschränkungen für das Bildformat?

Ich verwende die aktuellste (?) Version 1.80 unter Windows ...

Gruess Claudio

[Est Est E. (comvisu)]

Also jpg, png und bmp sollten alle funktionieren. Du kannst mir ja mal 
dein Bild zuschicken, dann probiere ich es aus.

[Claudio F. (zunge)]

bekommst ne Mail ... Danke ...

[Est Est E. (comvisu)]

Wie per Mail besprochen und falls jemand anderes über dieses Problem 
stolpert: Der Dateidialog gibt einen relativen Pfad zurück, wenn die 
Bilddatei im gleichen Ordner wie das Projekt, also die .visu-Datei, 
liegt. Und dann kann das Bild u.U. nicht angezeigt werden. Als Abhilfe 
kann man den vollständigen Pfad händisch eingeben. (Oder eben an anderer 
Stelle speichern.)

[Reinhard (Firma: priv) (reno1)]

Hallo,
ich nutze ComVisu schon sehr lange auch auf dem Raspberry -3N . Nun habe 
ich den Raspi neu aufgesetzt und bekomme ComvisuV180ARMV6LinuxQT4 nicht 
zum laufen. Auch die Installation des Dev mit:   sudo apt-get install 
libqtwebkit4
klappt nicht. Auch die 2. Variante nicht ? sudo apt-get install 
libqt4pas-dev.
Was mache ich falsch oder gibt es ein anderses Paket.
Es wäre schade nicht meht mit dem Raspi arbeiten zu können. Danke für 
entsprechende Antworten

[Est Est E. (comvisu)]

QT4 scheint nicht mehr auf den Repositories bereitgestellt zu werden. Du 
kannst mal versuchen, das händisch runterzuladen und zu installieren. 
Ich weiß nicht ob es funktioniert, insbesondere wenn noch andere 
Abhängigkeiten bestehen und die Prozessurarchitektur muss ja auch 
passen.

Hier im Link gibt es Package (u.a.) für ARMHF, das würde ich mal 
probieren. Andere kennen sich da besser aus als ich, vielleicht kann 
jemand was dazu sagen.

https://packages.debian.org/buster/libqtwebkit4

Sonst müsste ich auf QT5 umsteigen, habe gerade aber wenig Zeit.

[Günter (galileo14)]

Hallo Est Est Est,

ich befasse mich gerade wieder mal mit meiner Heizungssteuerung. Da 
kürzlich Zeitumstellung war, fiel mir heute eine Diskrepanz auf zw. den 
Uhrzeiten des Systems und in der "Oszilloskopenanzeige", siehe 
Screenshot. In letzterer scheint die Zeit nicht umgestellt zu sein 
(unten in der Skala, 18:29 Uhr), in der Systemzeile oben rechts jedoch 
schon (17:29 Uhr) das Programm läuft hier auf einem RaspBerryPi, also 
die ARM-Version 1.80, die letzte/aktuelle).

Kann es sein, daß Comvisu irgendwie seine eigene Zeit pflegt und nicht 
mitbekommt, wenn Linux automatisch auf Winterzeit umstellt?

Gruß, Günter

[Sandor (rodnas)]

Hallo Est Est E.,

Wäre es möglich im Terminalfenster Zeilenumbruch realisieren?
Eventuell mit Zeilennummer.

Grüße

rodnas

von Est Est E. (comvisu)31.10.2022 11:45


Hallo rodnas,

den Zeilenumbruch habe ich implementiert, ist dann in der nächsten
Version verfügbar.

Wann kommt die nächste Version?

Grüße
Sandor

PS: Das Programm ist unschlagbar.

[Est Est E. (comvisu)]

Günter schrieb:
> Kann es sein, daß Comvisu irgendwie seine eigene Zeit pflegt und nicht
> mitbekommt, wenn Linux automatisch auf Winterzeit umstellt?
Die Zeit wird vom Betriebssystem abgefragt, mit der Pascal-Funktion 
Now(). Soviel ich weiß, gibt das die lokale Zeit zurück, sollte also die 
Zeitumstellung mitmachen. Wird immernoch eine falsche Zeit angezeigt?

Sandor schrieb:
> Wann kommt die nächste Version?

Schwer zu sagen :)
Aber ich kann mal schauen dass ich vom aktuellen Stand eine neue Version 
veröffentliche eben mit den paar kleineren Änderungen.

[Sandor (rodnas)]

Hallo Est Est E.

Super! Ich bin schon aufgeregt wie beim Öffnen des  Adventskalenders.

Grüße

Sandor

[Günter (galileo14)]

Est Est E. schrieb:
> Günter schrieb:
>> Kann es sein, daß Comvisu irgendwie seine eigene Zeit pflegt und nicht
>> mitbekommt, wenn Linux automatisch auf Winterzeit umstellt?
> Die Zeit wird vom Betriebssystem abgefragt, mit der Pascal-Funktion
> Now(). Soviel ich weiß, gibt das die lokale Zeit zurück, sollte also die
> Zeitumstellung mitmachen. Wird immernoch eine falsche Zeit angezeigt?

Hallo Est Est Est,

die Zeit wird jetzt richtig angezeigt, aber der Raspi ist in der 
Zwischenzeit neu gebootet worden, da er gelegentlich abstürzt (liegt 
aber wohl nicht an Comvisu). Kann daher nicht wirklich etwas Relevantes 
dazu sagen.

Ich kann aber in den nächsten Tagen mal dennoch neu booten und dem Raspi 
eine Zeit kurz vor der letzten Zeitumstellung einstellen und somit das 
Ganze nochmal wiederholen und eine Weile laufen lassen, dann sehe ich 
ja, was passiert. Dazu melde ich mich demnächst.


Sandor schrieb:
>
> PS: Das Programm ist unschlagbar.

Dem kann ich mich voll anschließen.

Viele Grüße
Günter

[Sandor (rodnas)]

Hallo Est Est E.,

Das Konsoleninstrument braucht wie die andere Instrumente eine 
Nachkommastellen-Beschränkung. (wenn es möglich ist)

Grüße

Sandor

[Sandor (rodnas)]

Hallo Est Est E.,

Wäre es möglich im Terminalfenster Zeilenumbruch realisieren?
Eventuell mit Zeilennummer.
Grüße
rodnas
von Est Est E. (comvisu)31.10.2022 11:45
Hallo rodnas,
den Zeilenumbruch habe ich implementiert, ist dann in der nächsten
Version verfügbar.
Wann kommt die nächste Version?
Grüße
Sandor
PS: Das Programm ist unschlagbar.

Keine Forderung nur Erinnerung :)