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