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!
:
Verschoben durch User
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;-)
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.
Eine Webseite ist in Planung, das wird aber noch etwas Zeit brauchen.
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.
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 ;-)
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?
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!
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!
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.
(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?
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.
:
Bearbeitet durch User
So kommt es herüber, jetzt ohne Leerzeichen vor und nach dem Strichpunkt, aber keine Änderung.
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.
Mit welcher Programmiersprache hast Du ComVisu gemacht? Ist es auch mit Delphi wie VirtualComInstruments?
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.
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.
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!
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.
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.
Okay, super, danke. Ich teste es gerne auf XP, wenn du eine neue Version zur Verfügung stellst.
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.
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 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.
Das kleine Kästchen blinkt, manuelle Triggerung, wie empfohlen, hilft nicht weiter nur der manuelle Anteil wird angenommen.
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:
1 | Print "#10F5;#10F5;#10F5;" |
Ob dann was durchkommt... Ich kann mir es echt nicht erklären.
so kommt durch. Also der Fehler liegt bei mir. Ich muss mir etwas einfallen lassen, wie ich die Print Ausgabe formatiere.
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.
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.
Moby A. schrieb: > Zuweilen bleibt der erweiterte Bereich eine Weile schwarz, Das ist natürlich nicht schön. Ich kümmer mich darum.
Kann man irgendwie die minimal mögliche Abtastrate anzeigen lassen?
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.
@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?
:
Bearbeitet durch User
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.
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.
Fiat Lux! Und es ward Licht. :-) Es funktioniert !!!!!!!!!! V.031 Syntax: Print "#10F" ; Probe ; ";" Danke Est Est Est :-) Jetzt Feintuning
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".
Prinzipiell toll das es ein neues Programm gibt. Aber wieder nur für Windows :( Hat das jemand schon mal mit wine probiert? Jonas
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?
Hab gerade in wikipedia gelesen, dass Lazarus auch für Linux kompilieren kann? Kann jemand was dazu schreiben der sich damit auskennt? Gruß Jonas
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.
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
[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:
1 | $ yaourt Lazarus |
2 | 1 community/fpc-src 3.0.0-1 [installed] |
3 | Sources for the FreePascal compiler (required by the Lazarus IDE) |
4 | 2 community/lazarus 1.6.0-1 [installed] |
5 | Delphi-like IDE for FreePascal common files |
6 | 3 community/lazarus-gtk2 1.6.0-1 |
7 | Delphi-like IDE for FreePascal gtk2 version |
8 | 4 community/lazarus-qt 1.6.0-1 |
9 | 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.
1 | AutoReset is a feature that allows you to upload the compiled sketch to |
2 | the Arduino board without pressing the reset switch. The way it works is |
3 | by sending a reset signal (GND) to the reset pin using the DTR signal on |
4 | 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]
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
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?
Hallo, wenn du mir die den Code zu Verfügung stellst würde ich es mal versuchen eine Linux Version zu basteln. Gruß Jonas
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.
Kann man iwie eine art look up table integrieren? ansonsten gefällt mir das programm gut:)
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)?
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)
Ergänzung: wie fütter ich die Tabelle: Ideal wäre natürlich, wenn man die vorher aus einer csv Datei oä. reinlädt
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 :)
Nicht übel, sprach der Dübel. Man sollte es aber ins WIKI schieben und nur eine Softwareversion online haben.
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.
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.
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.
:
Bearbeitet durch User
Da gehtes bei komplizierten Rechnungen manchmal Platzund Taktmäßig nicht
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
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 !?
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?
:
Bearbeitet durch User
Ein Vorschlag: Wäre nicht schlecht die Leds Grundfarbe auch individuell einstellen zu können.
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.
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
:
Bearbeitet durch User
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"
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.
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
:
Bearbeitet durch User
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 ;-)
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
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.
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
:
Bearbeitet durch User
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 :)
Vorschlag: die Möglichkeit in der Analoganzeige auch den Digitalwert darzustellen.
Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die noch freie Kanäle aufzulisten.
Vorschlag: Verschieben eines Objekts frei nach vorne oder nach hinten.
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.
Moby AVR schrieb: Nein, nicht die freien, sondern die schon belegten! Ich stimme zu! Vorschlag: Option, Led blinken lassen
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~
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?
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 ;-)
:
Bearbeitet durch User
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.
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.
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.
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.
:
Bearbeitet durch User
Übrigens, wie kann ich umschalten zwischen UDP und Seriell wenn ich zwei angeschlossene Systeme habe?
Autoscroll im Terminalfenster fehlt noch (bzw. geht nicht richtig)
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....
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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?
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 ;-)
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.
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...
:
Bearbeitet durch User
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. 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?
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.
Bei der Instrumentenkonfiguration "Zeichenausgabe" wird der Ausgabewert nicht abgespeichert.
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.
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
:
Bearbeitet durch User
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?
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?
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~
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"
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 ;-)
:
Bearbeitet durch User
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
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 ...
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.
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!
:
Bearbeitet durch User
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.
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.
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.
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.
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.
:
Bearbeitet durch User
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.
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
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
:
Bearbeitet durch User
Ab sofort können auch mehrere Befehle in einem UDP-Paket verarbeitet werden.
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.
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.
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
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.
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
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
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~
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
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.
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.
Jetzt kommt eine Wiederholung, Vorschlag: Ein neuer Button im Bereich "Bearbeiten" um die belegten Kanäle aufzulisten. Grüsse
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~
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.
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
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.
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
Übrigens, die Einführung des LED-Schwellwertes ist genial, da spart man µC Speicher wenn es um Bildschirm-Visualisierung geht.
Analoganzeige Horz. + Vertikal ? und ich möchte gerne sowas wie im Anhang ;-)
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...
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.
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...
:
Bearbeitet durch User
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?
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.
:
Bearbeitet durch User
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
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.
Vermerk: Die Mehrfach-Zeitdiagramm Instrumente speichern nicht den Kanal- aktiv/inaktiv Zustand korrekt ab. Bei Programmneueröffnung werden alle Kanäle als aktiv gesetzt.
Hallo Est Est Est, ist die Programmpflege auf Eis gelegt? Grüsse rodnas
Nein, im Gegenteil, ich bin zu beschäftigt mit dem Programmieren~ In den nächsten Tagen gibts neue Funktionen:-) Grüße
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...
:
Bearbeitet durch User
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
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.
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.
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.
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.
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
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:-)
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.
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...
Guten Abend, zur Erinnerung: Anno....haben wir schon über ein F-kodiertes Ausgabegerät gesprochen ähnlich wie Zeichenausgabe mit S-Kodierung. Gruss rodnas
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~
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...
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
Balkeninstrument: sehr schöne flexible Lösung! Wünschenswert wäre beim Verstellen zum Senden den aktuellen Wert digital einblenden Gruss rodnas
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...
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
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
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!
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
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).
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.
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
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? ;-)
Es geht um die Nummerische Digitalanzeige und nicht um das Ein-Ausgabegerät.
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.
1 | 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.
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.
Jetzt kommt die Bearbeitung der Schnittstelle? :-) Danke Est Est Est Grüsse rodnas
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
Genau. Wenn man mehrere Einträge hat, dann mit einem Klick eine Auswahl treffen kann. Eventuell Parallelbetrieb für UDP-UDP bzw. UDP-UART
Beim Wechsel Ausführen > Bearbeiten kam die Fehlermeldung und Absturz. Programm beenden ist nur über Prozessbeendung möglich.
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?
:
Bearbeitet durch User
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.
> 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. :-(
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.
Der erwähnte Fehler ist nicht reproduzierbar. Bei der Schnittstelle, im Grunde genommen wichtig ist nur die Möglichkeit der schnelle Prioritätswahl.
Jetzt eben habe ich wieder die Fehlermeldung gehabt. Wie du vermutet hast, jetzt nach mehrmaligen Sendeversuch und ein Trennvorgang.
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.
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
Jetzt habe ich entdeckt. Dezimalzeichen wird als Komma gesendet, vermutlich deshalb wird abgeschnitten.
Besteht die Möglichkeit in der Konfigurationsmodi diesbezüglich eine frei Wahl treffen?
rodnas schrieb: > Besteht die Möglichkeit in der Konfigurationsmodi diesbezüglich eine > frei Wahl treffen? Die Festlegung, ob Punkt oder Komma das Dezimaltrennzeichen ist, wird vom Betriebssystem übernommen (Regionseinstellungen). Bei Eingängen wird beides akzeptiert. Ich schau mal, ob ich das noch einstellbar machen kann.
Es geht weiter mit Version V0.44 mit folgenden Neuerungen: - Vollbildmodus und Vollfenstermodus implementiert, welche im Ausführen-Menü oder per Kommandozeilenparameter gestartet werden können. - Die Projektdatei kann beim Starten der Comvisu über Kommandozeile übergeben werden. Das ermöglicht auch die Dateiendungszuordnung in der Windows-Systemsteuerung, sodass Projekte per Doppelklick im Explorer geöffnet werden können. Die Kommandozeilenparameter "-Connect", "-FullScreen", "-FullWindow" und "-RunMode" sind selbserklärend, Details finden sich in der aktualisierten Dokumentation (im Zip). - Überarbeitetes Terminal mit der Anzeige aller (Ascii-) Zeichen, auch der Steuerzeichen und zusätzlicher Anzeige des Codes in hexadezimaler Schreibweise. Der Umbruch funktioniert nun sauber. - Auswahlmöglichkeit der anzuzeigenden Schnittstelle im Terminal. - Sporadisch auftretender Fehler beim Schließen der COM-Schnittstelle behoben.
Guten Morgen Est Est Est, danke für die Weiterentwicklung. Bemerkung: Bildanzeige funktioniert nicht mehr. Frage: Noch nicht probiert deshalb die Frage. Die Schnittstellenumschaltung für Terminal gilt jetzt auch für die Ausführungsmodus? Gruß rodnas
> Bemerkung: Bildanzeige funktioniert nicht mehr.
Entschuldigung, meine eigene Dummheit war die Ursache.
Gruß
rodnas
Währe es möglich die feste Kommastellen bei Analoganzeige/Schieber so zu realisieren wie bei der Nummerische Digitalanzeige? Ich meine diese zusätzliches Kontrollkästchen. rodnas
rodnas schrieb: > Guten Morgen Est Est Est, Guten Morgen~ > Frage: Noch nicht probiert deshalb die Frage. Die > Schnittstellenumschaltung für Terminal gilt jetzt auch für die > Ausführungsmodus? Nein, die Schnittstellenumschaltung gilt nur für das Terminal. Für den Hauptbildschirm ist eine solche Umschaltmöglichkeit in meinen Augen auch nicht so sinnvoll. Dort werden ja alle Schnittstellen verarbeitet. Entweder man braucht eine Schnittstelle oder nicht. Und zum Testen kann man ja die nicht benötigten Schnittstellen einfach löschen (z.B. nach abspeichern unter anderem Namen). Was ich mir aber vorstellen könnte, ist die Möglichkeit, Schnittstellen in der Liste deaktivierbar zu machen, das wäre evtl. interessant, wenn man einen Teilnehmer gerade nicht angesteckt hat. Moby A. schrieb im Beitrag #4600486: > Est Est Est, das war wieder ausgezeichnete Arbeit, ich bin begeistert! > Wieder ein gewaltiger Schritt nach vorne! Das ist schon eine richtig > runde Sache geworden. Soweit ich bislang testen konnte funktioniert > auch alles wie beschrieben. Fullscreen + beliebig viele Tabs, das ist > konkurrenzlos ! Danke, danke:-) > Zwei Frage noch > - zum Hintergrundbild: Lässt sich das im Fenstermodus ohne viel Arbeit > eventuell noch mit der Fenstergröße mitskalieren? Das schau ich mir mal an, sollte machbar sein. > - zur LED-Form: Wären runde Bauelementformen aufwendig umzusetzen? Vom Aufwand kann ich es noch nicht richtig abschätzen, deshalb hab ich es bisher auch noch nicht in Angriff genommen. Mal sehen, wann ich dazu komme.
rodnas schrieb: > Währe es möglich die feste Kommastellen bei Analoganzeige/Schieber so zu > realisieren wie bei der Nummerische Digitalanzeige? Ich meine diese > zusätzliches Kontrollkästchen. Ja, das ist kein Problem, ich baus bei der nächsten Version mit ein. EDIT: Die Einstellung würde sich dann auf den "Numerischen Wert" und auch auf die Skalenbeschriftung auswirken.
:
Bearbeitet durch User
Instrument Numerische Ausgabe: Die eingestellte Wert wird nicht abgespeichert.
Es gibt jetzt auch eine Linuxversion, dazu habe ich einen neuen Thread aufgemacht, Download dort: Beitrag "Comvisu für Linux"
Guten Tag Est Est Est, ich hätte einen Vorschlag, ein Instrument womit man zyklisch Daten senden kann. Also mit einstellbaren Intervalle z.B. von 10ms bis eine Stunde. Sozusagen eine getriggerte Numerische Ausgabe bzw. Taster. Gruß rodnas
rodnas schrieb: > Guten Tag Est Est Est, > > ich hätte einen Vorschlag, ein Instrument womit man zyklisch Daten > senden kann. Also mit einstellbaren Intervalle z.B. von 10ms bis eine > Stunde. > Sozusagen eine getriggerte Numerische Ausgabe bzw. Taster. Daran habe ich auch schon gedacht. Wo ich noch hänge, ist, dass es evtl. auch interessant sein könnte, (zyklisch) Werte zu schicken. Mal schauen, wie ich das Einbauen kann. rodnas schrieb: > Instrument Numerische Ausgabe: Die eingestellte Wert wird nicht > abgespeichert. Das hab ich mir schon notiert~
Hi, Ich hab deine Software mal ausprobiert, unter Windows & Linux. Und wie es mit neuen Usern so ist, hab ich gleich mal was zum herumjammern :-) - Leider funktioniert die Konsole über eine UDP-Verbindung nicht. Das Zeilende des Strings (\n) wird ignoriert und durch Leerzeichen ersetzt (in Terminal & Konsole). Das ist lt. Thread wohl schon länger ein Thema. - Ab und zu (bei bestimmten Stringwerten?) stolpert die Linuxversion mit folgender Fehlermeldung: ComvisuV045: xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Verbesserungsvorschläge: - Bei den Kurven-Widgets kann die Schriftart & Textfarbe nicht eingestellt werden (bei anderen Widgets gehts). - Einstellbare Font für die Konsole. - Recorder für die Konsole. MaW: Einfach die Texte die daherkommen (optional) in ein logfile mitschreiben. Ansonsten finde ich die Anwendung super, sie füllt genau die Lücke zwischen Debugausgaben und einer grossen, teuren und komplexen Prozessvisualisierung. Weiter so !
Werner A. schrieb: > Ich hab deine Software mal ausprobiert, unter Windows & Linux. > Und wie es mit neuen Usern so ist, hab ich gleich mal was zum > herumjammern :-) Kritik ist natürlich immer willkommen~ > - Leider funktioniert die Konsole über eine UDP-Verbindung nicht. > Das Zeilende des Strings (\n) wird ignoriert und durch Leerzeichen > ersetzt (in Terminal & Konsole). Das ist lt. Thread wohl schon länger > ein Thema. Habs grad nochmal probiert. Der Umbruch mit \n sollte eigentlich funktionieren. Kann es sein, dass dein Compiler für den µC das \n in das Steuerzeichen Zeilenumbruch (Ascii 0x0D) übersetzt hat? An der Stelle ist dann tatsächlich noch ein Fehler in der UDP-Schnittstelle, Steuerzeichen werden als Leerzeichen behandelt. Ich schau, dass in der nächsten Version dann auch Steuerzeichen als Umbruch akzeptiert werden (und der Fehler behoben). Bei der seriellen Schnittstelle könnte es sogar schon funktionieren. > - Ab und zu (bei bestimmten Stringwerten?) stolpert die Linuxversion mit > folgender Fehlermeldung: > ComvisuV045: xcb_io.c:165: dequeue_pending_request: Assertion > `!xcb_xlib_unknown_req_in_deq' failed. Passiert das mit eingeschaltener Konsole? Und nur mit eingeschaltener Konsole? > Verbesserungsvorschläge: > - Bei den Kurven-Widgets kann die Schriftart & Textfarbe nicht > eingestellt werden (bei anderen Widgets gehts). Ja, das ist sinnvoll. Idee war den Eigenschafteneditor kompakt zu halten. Ich bau es noch ein. > - Einstellbare Font für die Konsole. OK. > - Recorder für die Konsole. MaW: Einfach die Texte die daherkommen > (optional) in ein logfile mitschreiben. Ist sicher auch sinnvoll. Wird notiert~ > Ansonsten finde ich die Anwendung super, sie füllt genau die Lücke > zwischen Debugausgaben und einer grossen, teuren und komplexen > Prozessvisualisierung. > Weiter so ! Danke:-)
Neue Version V0.5. - Für das Menü können jetzt als Sprache statt Deutsch auch Englisch oder Chinesisch eingestellt werden. Die Auswahl erfolgt über das Menü oder per Kommandozeilenparameter beim Starten des Programms ("-lang=de", "-lang=en" und "-lang=zh"). - Es gab diverse interne Probleme insbesondere bei Verwendung mehrerer Schnittstellen, aber auch in der Terminal- und Konsolenausgabe, welche jetzt soweit behoben sind. - In den Diagramm-Instrumenten lässt sich nun die Schriftart/-Größe einstellen. - Für die Konsole lässt sich nun die Schriftart einstellen - Aufzeichnung der Konsole in eine Datei möglich. - Numerische Ausgabe speichert Eingabefeld mit ab. - Analoganzeige: Digitalwert und Skalenwerte können nun mit fester Anzahl an Nachkommastellen angezeigt werden. - Passive Befehle nun möglich, d.h. der Befehl löst keine Berechnung für die abhängigen Instrumente aus, sondern schreibt den Kanalwert nur in den entsprechenden Kanalspeicher. Passive Befehle sind solche mit vorangestelltem Schrägstrich "/". Z.B.: "/#5F12;" schreibt den Wert 12 in den Speicher von Kanal 5, aktualisiert aber keine Instrumente. Das ist sinnvoll, wenn ein Instrument von mehr als einem Kanal abhängt und daher "Zwischenwerte" zu falschen Werten führen würden. Beispiel: Eingang =#5*#6 darf bei sich gleichzeitig ändernden Werten für die Eingänge #5 und #6 nur einmal berechnet werden. Die Befehlsfolge "/#5F__;#6F__;" ermöglicht das. - Bewegen im Bearbeitenmodus bei gedrückter Steuerungstaste bewegt das Instrument nun gerastert in 10er Schritten.
Moby A. schrieb im Beitrag #4634429: > Die englische und vor allem chinesische Sprach-Erweiterung sind ja ein > echter Genie-Streich! Was für eine Markt-Erweiterung! ;-) Jetzt muss ich nur noch ein chinesisches Mikrocontroller.net finden:-)
Hallo Est Est Est, alle Achtung, wieder super Leistung! Danke rodnas
Moby A. schrieb im Beitrag #4640027:
> Die Instrumenten-Abmaße lassen sich nicht mehr frei ändern.
Habs grad getestet, geht eigentlich schon. Welche Instrumente lassen
sich bei dir nicht in der Größe ändern?
Grüße
Moby A. schrieb im Beitrag #4640685:
> Habe gerade nochmal die Zeichenausgabe getestet
OK, das Problem tritt bei mir auch auf, ich schau mirs an.
Moby A. schrieb im Beitrag #4641038: > Stichwort Tasterinstrument: Wäre es möglich, diesem einen "freien" > Rückgabewert zuordnen zu können, d.h. beliebige numerische Werte, > insbesondere aber auch Zeichenketten? Das sollte kein Problem sein, dann gibt es 2 zusätzliche Modi, Freitext als Zahl und Freitext als Zeichen.
Version V051: - Fehler beim Ändern der Größen behoben, betroffene Instrumente: Fernanzeige, Zeichenausgabe, Mehrfachzeitdiagramm. - Tasterinstrument kann nun optional auch einen frei definierbaren Text/Zahl senden
Moby A. schrieb im Beitrag #4642354: > Und das bei dem Wetter! Ja, einen Sonnenbrand hab ich mir heute auch schon geholt~ > Dafür ist es natürlich essentiell, > alle benötigten Instrumente samt endgültiger Codes zu kennen. Es kommen ja eigentlich immer nur Funktionen hinzu, du kannst dich also zumindest darauf verlassen, was schon verfügbar ist. Was ich auf jeden Fall noch vorhabe, ist ein Konsoleninstrument, d.h. ruhig ein Kanal pro Schnittstelle dafür freihalten. > Wenn ich das richtig sehe sind damit nun > x-beliebig viele Taster möglich geworden und es langt für alle ein > einziger Kanal, weil sich jetzt alle über ihre Rückgabewerte > unterscheiden lassen !? Stimmt, so weit hab ich gar nicht gedacht :-) Dann kann man jetzt die Taster einfach durchnummerieren oder sogar per Namen unterscheiden.
Hallo, ich habe jetzt unter Linux das Programm probiert und nach einem kleinen Problem (siehe Beitrag "Comvisu für Linux") hat es auch funktioniert. Interessant ist die Syntax für die serielle Kommunikation. Vor einigen Jahren haben ein Kollege und ich was ähnliches gemacht. Die Protokolle sind fast ident. Mir würde diese Art von Anwendungen als Web-Server vorschweben/sehr gefallen. Dann wäre es auch netzwerk- und handytauglich: COM AJAX/WebSockets [Arduino...]<--->[node.js WebServer]<--------------->[Browser] Aber leider wegen mangelnder Zeit + Bedarf verfolge ich momentan die Idee aktiv nicht weiter. Ein Demo/Grundgerüst eines Workshops, den ich gehalten habe, ist im Anhang. Vielleicht interessiert dich auch dieser Ansatz. Lg, Klaus
Weinga U. schrieb: > Hallo, > > ich habe jetzt unter Linux das Programm probiert und nach einem kleinen > Problem (siehe Beitrag "Comvisu für Linux") hat es > auch funktioniert. > > Interessant ist die Syntax für die serielle Kommunikation. Vor einigen > Jahren haben ein Kollege und ich was ähnliches gemacht. Die Protokolle > sind fast ident. > > Mir würde diese Art von Anwendungen als Web-Server vorschweben/sehr > gefallen. Dann wäre es auch netzwerk- und handytauglich: > > COM AJAX/WebSockets > [Arduino...]<--->[node.js WebServer]<--------------->[Browser] > > Aber leider wegen mangelnder Zeit + Bedarf verfolge ich momentan die > Idee aktiv nicht weiter. Hallo Klaus, das Programm habe ich dahingehend entworfen, um ein Hilfsmittel für die µC-Programmierung zu haben, insbesondere für Schaltungen mit Sensoren etc. Daher gibt es auch ein explizites Konsolenfenster mit fester Kanalzuordnung (minimaler Einrichtaufwand). Oder per Default verschiedene Farben für die Bearbeiten- und Ausführenoberfläche anstatt verschiedene Farben pro Blatt. Für die Benutzung als User-Interface kann man sich das ja dann trotzdem nach eigenem Gusto einrichten. Für die oben genannte Anwendung ist aber ein klassisches PC-Programm am Geeignetsten. Man braucht keinen Server einrichten usw. Eine Erweiterung für eine Browserdarstellung wäre sicher nützlich und wünschenswert, aber dann doch ein Riesenaufwand, da ja dann beide Systeme bedient werden müssen, insbesondere die Grafik muss dann getrennt erzeugt werden. D.h. für mich ist das nicht machbar.
Hallo Est Est Est, die Zielgruppe deiner Anwendung ist mir klar. Die Idee mit nodejs wäre gleich eine reine Web-Anwendung, die auch lokal natürlich wie ein Programm verwendet werden kann. D.h. man startet die Nodejs Anwendung mit >node comvisu.js und verbindet sich im Browser mit 127.0.0.1 und sieht dort auch die Signale oder was auch immer. nodejs ist der Web-Server und arbeitet als Kommandozeilenprogramm. Es managed die serielle Schnittstelle und liefert alle Daten und Dateien an den Browser der gerade anfragt. Ein Demo wie gesagt in meiner ZIP Datei. Den Vorteil, den deine Lösung hat, ist die standalone EXE. nodejs Anwendungen kann man auch packen, das habe ich aber noch nicht probiert. Dann wäre es auch standalone. Schön finde ich, dass du mehrere Comports und UDP unterstützt. 1. Frage: Die Signalplots, sind die Punkte resampled? 2. Frage: Beim Datarecorder: können mehrere Signale in einer Datei aufgezeichnet werden? Danke. Klaus
Weinga U. schrieb: > Die Idee mit nodejs wäre > gleich eine reine Web-Anwendung, die auch lokal natürlich wie ein > Programm verwendet werden kann. > D.h. man startet die Nodejs Anwendung mit > >node comvisu.js > und verbindet sich im Browser mit 127.0.0.1 und sieht dort auch die > Signale oder was auch immer. > nodejs ist der Web-Server und arbeitet als Kommandozeilenprogramm. Es > managed die serielle Schnittstelle und liefert alle Daten und Dateien an > den Browser der gerade anfragt. Ein Demo wie gesagt in meiner ZIP Datei. Ah Ok, da hatte ich dich nicht richtig verstanden. Ehrlich gesagt habe ich gewisse Vorbehalte gegenüber Web-Anwendungen. Mir ist einfach noch keine begegnet, welche sowohl umfangreich ist als auch ordentlich bedienbar wäre. Insofern habe ich mich auch noch nicht in diese Richtung informiert/eingearbeitet. Deine Demo hab ich runtergeladen, wie kann ich die Demo starten? > Den Vorteil, den deine Lösung hat, ist die standalone EXE. nodejs > Anwendungen kann man auch packen, das habe ich aber noch nicht probiert. > Dann wäre es auch standalone. Ja, eine Exe läuft einfach, man braucht keinen passenden Browser, scripting erlauben etc. > 1. Frage: Die Signalplots, sind die Punkte resampled? Eingehende Befehle werden verarbeitet/berechnet und in den Instrumentenspeicher geschrieben. Dieser Speicher wird vom Diagramm selbst in einer einstellbaren Periode abgetastet. So kann man die Datenmenge an seine Aufnahmedauer anpassen. Außerdem ist die CPU-Auslastung für die Abtastung im Grunde immer gleich (keine Überraschungen). Dafür verliert man aber Werte, wenn zwischen je einer Abtastung zwei oder mehr neue Werte reinkommen. > 2. Frage: Beim Datarecorder: können mehrere Signale in einer Datei > aufgezeichnet werden? Bisher nicht, das steht aber ganz oben auf meiner Liste! Bisher lassen sich auch nur Zahlenwerte speichern.
Ich will jetzt nicht diesen Thread offtopicen, aber mein Demo kannst du starten wie folgt: 1. nodejs downloaden und installieren https://nodejs.org 2. Konsole im workshopserver verzeichnis öffnen 3. "npm install" ausführen, dann werden zusätzliche pakete downgeloaded 4. "node server.js" ausführen 5. Browser öffnen und 127.0.0.1:8080 eingeben (optional mit Hardwaresupport) 6. Arduino Software einspielen 7. in server.js den comport einstellen: /dev/ttyUSB0 ändern in \\.\COMx 8. Schritt 4 und 5 ausführen. Ich hoffe, ich habe nichts übersehen. Lg, Klaus
Neue Version V0.60 - Das Zeitdiagramm ist weitgehend überarbeitet, es sind jetzt bis zu 10 Kurven in einem Diagramm möglich und es können bis zu 6 Y-Skalenbereiche konfiguriert und die Kurven zugeordnet werden. Achsenbeschriftungen sind nun auch möglich. Es gibt außerdem einen definierbaren Steuerkanal, über welchen das Diagramm über die Schnittstelle zurückgesetzt werden kann. Die Befehle (als Zeichenkette S) lauten "Clear" und "Reset". Das Zeitdiagramm kann nun maximal 100.000 Punkte aufzeichnen, darüber hinaus werden jeweils die ältesten 5000 Punkte gelöscht. Dadurch wird auch bei einer langen Aufzeichnung eine Überlastung verhindert. - Neues Instrument XY-Diagramm bei welchem der X- und Y-Wert über getrennt über zwei Eingänge übermittelt wird. Bei jedem Eingang über den X-Kanal wird ein Punkt gezeichnet, entsprechend muss zuerst der Y-Wert und dann der X-Wert übertragen werden. - Diverse kleinere Änderungen. Für das Zeitdiagramm gibt es nur erstmals keine direkte Rückwärtskompatibilität mehr. Zwar wird das Diagramm geladen, aber die Werte für den Eingang, die Achsenbereiche und die Kurvenfarbe werden nicht übernommen. Desweiteren können Diagramme, welche mit der neuen Version gespeichert wurden, nicht in alten Versionen geöffnet werden. In dem Fall kommt es zu einem Absturz. Der zugrundeliegende Fehler ist nun behoben, für die alten Versionen kann das aber natürlich nicht mehr rückwirkend angepasst werden. Das aber nur am Rande, es sollte sowieso keinen Grund geben, auf eine alte Version zurückzugehen. Ich hab nun endlich auch eine Homepage eingerichtet, ein Download ist auch dort möglich: www.comvisu.de Edit: Für das Zeitdiagramm lässt sich für die X-Achse nun auch die aktuelle Uhrzeit und das Datum anzeigen
:
Bearbeitet durch User
Sehr schön. Gerade entdeckt. Freue mich schon darauf wieder aufer Arbeit zu sein um es aus zu testen. Gibts inzwischen eine Webseite? Du könntest ein bisschen Werbung vertragen wie die Downloadzahlen zeigen. Werds mal herumsprechen. Wird ab Version 1 verkauft?
hallo schrieb: > Gibts inzwischen eine Webseite? Ja, hab ich grad im letzten Beitrag verkündet (ich weiß, ist mittlerweile ein langer Thread): http://www.comvisu.de > Du könntest ein bisschen Werbung vertragen wie die Downloadzahlen > zeigen. Werds mal herumsprechen. Werbung wäre auf jeden Fall nicht schlecht! Die Möglichkeiten sind schon weitgehend, ich denke man kanns guten Gewissens weiterempfehlen. > Wird ab Version 1 verkauft? Wie geschrieben stell ich das Programm Privatleuten sowieso immer kostenlos zur Verfügung. Und kommerzielle Interessenten haben sich bisher nicht gemeldet, von daher... nein. Dass ich auf Version 1 hinarbeite hat damit zu tun, dass jetzt die Erweiterung der Funktionalität im Vordergrund steht und auch Inkompatibilitäten zwischen Versionen auftreten können. Für die einzelnen Versionen teste ich meistens nur die Dinge, wo ich auch direkt etwas geändert habe. Dabei passieren schon auch mal Schnitzer. Version 1 soll dann quasi ein 'Stable Release' sein.
Ich finde das Programm richtig gut und echt hilfreich. Gerade durch die Verwendung von Formeln ist es recht gut zu konfigurieren. Allerdings hätte ich einen Wunsch. Ich würde es gut finden, wenn in den UDP-Socket-Einstellungen unter eigene Adresse auch die aktuell eigenen IP-Addressen aufgeführt wären. Es scheint mir so, dass "192.168.2.8" aktuell nur als Platzhalter dient. Grüße Alex
Alex schrieb: > Es scheint mir so, dass "192.168.2.8" aktuell nur als Platzhalter dient. Das ist richtig, es soll nur zeigen, wie die Adresse in etwa aussehen sollte. > Allerdings hätte ich einen Wunsch. Ich würde es gut finden, wenn in den > UDP-Socket-Einstellungen unter eigene Adresse auch die aktuell eigenen > IP-Addressen aufgeführt wären. Ich hatte mir das früher schonmal angeschaut. Die Schnittstellenbibliothek stellt aber keine Möglichkeit zur Verfügung nur IP4-Adressen anzuzeigen. Gut, die IP6-Adressen schaden wohl auch nicht... ich schau danach~ Grüße
Hallo Est Est Est, meine besten Wünsche zur Weiterentwicklung! Kleine Bemerkung: Die Beschriftung der Zeitachse zeigt bei mir nur Punkt an, anstatt Doppelpunkt. Gruß rodnas
Hallo rodnas! rodnas schrieb: > Kleine Bemerkung: Die Beschriftung der Zeitachse zeigt bei mir nur Punkt > an, anstatt Doppelpunkt. Du meinst in der Datum/Uhrzeit-Darstellung? Der Punkt ist hier Absicht, da es sich um die Trennung Minuten und Sekunden (mm.ss) handelt. Die Voreinstellung des Diagrammbereichs sind ja 20 Sekunden. Der Punkt als Trennzeichen ist zur Unterscheidung gegenüber Stunden und Minuten (hh:mm). Einfach Rauszoomen (Ctrl+Scrollen) oder Diagrammgrenzen größer einstellen, dann wird es klarer. Das Trennzeichen für Millisekunden ist auch ein Punkt, hat aber immer 3 Stellen dahinter (mm.zzz). Grüße
Guten Morgen Est Est Est, vor etwa 3 Monaten haben wir uns über ein Instrument mit der Fähigkeit zyklisch Daten senden zu können unterhalten. Ist diese Gedanke zur Reife gekommen? Gruß rodnas
Neue Version V0.7: - Neues Instrument Getaktete Ausgabe. Das Instrument gibt zyklisch Werte aus, die Periode ist einstellbar ab mindestens 0,1 Sekunden. Für den Wert kann eine Konstante oder eine Berechnungsformel angegeben werden. Im Gegensatz zu "normalen" Eingängen wird der Wert immer beim Senden berechnet und nicht durch etwaige Eingänge getriggert. Damit kann beispielsweise die aktuelle Uhrzeit mit der Funktion time() übermittelt werden. - Neue Funktionen time(), date() und datetime(). Gibt jeweils die aktuelle Uhrzeit als Zahlenwert im Format hhmmss, YYYYMMDD bzw. YYYYMMDDhhmmss zurück. - Überarbeitets Instrument Dateirekorder. Der Eingang verarbeitet nun sowohl Zahlenwerte als auch Zeichenketten. Außerdem können nun bis zu 10 Werte in eine Datei aufgezeichent werden, die hintereinander, d.h. als Spalten, angeordnet werden. Zu beachten ist, dass immer dann eine neue und komplette Zeile in die Datei geschrieben wird, wenn ein Wert auf dem ersten Kanal eingeht. D.h. die anderen Kanäle müssen zuerst bedient werden. - In der Schnittstellenanzeige für UDP-Verbindungen werden nun die verfügbaren lokalen IP-Adressen angezeigt, sowohl IP4- als auch IP6-Adressen. Bei Klick auf die Adresse wird diese für die Schnittstelle übernommen. Die "Klickübernahme" ist jetzt auch für die seriellen Schnittstellen (nur in der Windowsversion) implementiert. Viel Spaß~
Hallo Est Est Est, Wäre der Aufwand zu groß für LED-s bzw. Fernanzeige eine zuschaltbare Blinkfähigkeit anzuheften? Grüße rodnas
Ein Gedankenspiel: Ein Matrix Instrument welches von der Taktausgabe gezielt schrittweise oder zufällig lesbar ist und dessen Inhalt an µC weitergeleitet wird. Gruß rodnas
rodnas schrieb: > Wäre der Aufwand zu groß für LED-s bzw. Fernanzeige eine zuschaltbare > Blinkfähigkeit anzuheften? Hallo Rodnas, Ich hab schon ein neues LED-Instrument vorgesehen, welches nur Impulse ausgibt (Ist sogar schon fertig~). Ein Modus 'Dauer-Blinken' für die normale LED wär aber vielleicht zusätzlich auch nicht schlecht. rodnas schrieb: > Ein Gedankenspiel: > Ein Matrix Instrument welches von der Taktausgabe gezielt schrittweise > oder zufällig lesbar ist und dessen Inhalt an µC weitergeleitet wird. Mit Matrix meinst du eine Lookup-Tabelle, oder? Das wurde weiter oben im Thread schon mal angesprochen. Die Umsetzung ist aber nicht ganz einfach, für jede Lookup-Tabelle müsste dann eine Funktion zum Abrufen bereitgestellt werden, was einen Eingriff in den Parser bedeutet... Also eher nicht, aber ich behalts im Hinterkopf. Grüße
Neue Version V0.80: - Neues Instrument BlinkLED. Die LED leuchtet immer auf, wenn ein Wert größer Null eingeht. Ist die LED bei Eingang bereits in einem Blinkvorgang, so wird genau ein Impuls in direktem Anschluss an die Pausenzeit berücksichtigt, d.h. ein neuer Blinkvorgang gestartet. So wird bei vielen kontinuierlichen Impulsen trotzdem ein gleichmäßiges Blinken erreicht. Einsatz z.B. als 'Online'-Anzeige oder zum Darstellen von Schnittstellenaktivität etc. - Neues Instrument LED-Leiste zur binären Anzeige von Zahlen. Einsatz z.B. zur Darstellung von Portzuständen - Neues Instrument Tongeber. Gibt einen Signalton mit einstellbarer Frequenz aus. Modi Dauerton, Intervallton und Einzelimpuls einstellbar. In der Linuxversion funktioniert die Tonausgabe nicht, d.h. das Instrument ist unter Linux nicht funktionstüchtig (verursacht aber auch keinen Fehler). - E/A-Kanal jetzt mit Sendeanimation, um zu sehen, ob Werte verarbeitet werden.
Hallo Est Est Est, danke für deine Arbeit. Ich verwende dein Programm sehr gerne. Folgende Feature-Requests bzw. Ideen hätte ich (einfach zum Nachdenken). Ich verstehe, dass diese auch komplexer sind als Led EIN/AUS. 1) Comvisu kann HTTP Requests an einen Server machen, wo ebenfalls die Daten in beiden Richtungen ausgetauscht werden können (selbe Format). D.h. eine neue Verbindungsart mit URL und einer Zykluszeit für die Requests. Eine schnelle Kommunikation kann man so natürlich nicht machen. HTTPS bitte auch nicht vergessen. 2) Eine Möglichkeit SVGs zu verwenden, wo in den Transformationen (Drehung, Schieben) die Formeln mit #5 z.B. drinnen Stehen. So könnte man Animationen machen. Das SVG selbst muss natürlich in einem anderen Programm erstellt werden. Keine Ahnung, ob dein GUI Toolkit das gut unterstützt. 3) Der µC selbst kann die GUI an comvisu schicken und so die Visu aufbauen. Dann hat man immer die richtige Anzeige zum richtigen Projekt. Ich denke es würde reichen, wenn comvisu das ganze als BASE64 exportieren und importieren kann. Der µC schickt das dann beim Einschalten rüber (oder so ähnlich :-) ) Lg
Hallo Weinga Unity, die Vorschläge hören sich gut an. Sind aber, wie du ja auch schon bemerkt hast, keine Kleinigkeiten. Ich schau mir auf jeden Fall mal an, was für die Umsetzung in etwa nötig wäre und hab auch gleich ein paar Fragen~ Zu 1) In dem Bereich kenn ich mich nicht gerade aus, vielleicht kannst du es noch ein bisschen konkrekter ausführen. Wenn ich es richtig verstehe, wird beim HTTP-Request keine Verbindung gehalten, sondern nur solange die Abfrage ausgeführt wird? Das heißt, dass wenn man in der Comvisu auf "Verbinden" geht, dann auch keine Verbindung aufgebaut werden würde, sondern immer nur dann, wenn tatsächlich eine Anfrage gesendet werden soll, und zwar für jede Anfrage einzeln. Eine Anfrage wäre dann das Senden eines Wertes, z.B. über ein Tasterinstrument. Statt "GET ..." würde dann z.B. "#5F1;" in der Anfrage stehen. Geht das überhaupt? Oder müsste der Befehl in den Datenteil der Anfrage? Der Server würde dann innerhalb eines Timeouts ggf. auf die Anfrage mit einem Befehl antworten. Die Antwort wird dann ganz normal als ein eingehender Befehl verarbeitet. Das heißt, der Server kann selber nur auf Anforderung Senden. Zu 3) Ein Problem dabei ist allerdings, dass die Schnittstelle ja schon verbunden und damit auch eingerichtet sein muss, um die Daten senden zu können. Was ich mir als einfachere Alternative vorstellen könnte, ist, über einen speziellen Befehl den Pfad der .visu-Datei zu senden, die dann geladen wird. Funktioniert dann halt nur am gleichen Rechner.
Hallo Est Est Est, 1) Ja, man macht je Request eine Verbindung auf, die wieder geschlossen wird. Du müsstest einen GET-Request machen und im URI https://test.cc?data=#5F10.3;#2F30,4; Kannst du Daten zum Server schicken. In Response (Dateibereich) kannst du dann Daten empfangen. Auch wieder ein String. Server kann so selber nichts senden. 3) Das Problem wurde mir auch kurz nach meinem Betirag bewusst... Lg
Alles klar, dann hab ichs soweit verstanden und versuch mich mal daran~ Grüße
Ich hab jetzt mit dem URL-Request ein bisschen rumprobiert, scheint für HTTP auch soweit zu funktionieren. Weinga U. schrieb: > HTTPS bitte auch nicht vergessen. Genau das hat sich als Problem rausgestellt. Bibliotheken für verschlüsselte Verbindungen habe ich nur solche gefunden, welche als DLL eingebunden werden, d.h. das würde das jetzige Konzept einer Stand-Alone-EXE kippen, was ich aber nicht möchte. Das heißt die Frage ist jetzt, wäre eine URL-Request auch ohne Verschlüsselung noch interessant? Oder kennt jemand eine SSL-Bibliothek für Lazarus, welche statisches Linken erlaubt?
Hallo Est Est Est, HTTP ohne (s) wird auch akzeptiert :-) Ich wollte damit ausdrucken, dass (wenn möglich) HTTPS auch gleich mit implementiert wird. D.h. du hast schon was funktionsfähiges hinbekommen? Lg
Weinga U. schrieb: > D.h. du hast schon was funktionsfähiges hinbekommen? Ja, ein URL-Request hab ich hinbekommen, ist aber noch nicht in die Comvisu integriert. Mir fehlt auch die Möglichkeit zu testen, ob der Dateibereich richtig ankommt. Vielleicht kannst du testweise einen Server einrichten, an den ich Anfragen schicken kann und der einfach ein Echo schickt? Oder Kanal+1, wie auch immer. Sollten (Ziel-)Portnummern einstellbar sein, oder geht man da sowieso immer über den Standardport? Grüße
URL mit Port-Nummer ist sicher hilfreich. Ich kann dir sicher einen kleinen Server mit node.js machen, den du lokal bei dir dann laufen lassen kannst. Wann ist eher das Problem. Gib mir etwas Zeit. Lg
Ich dachte eher an einen (deinen) Server online :-) Naja, ich implementier und teste die URL-Anfrage mal so weit ich komm, dann sehen wir weiter. Vielleicht findet sich auch sonst jemand, der eine Echo-Funktion in seiner Seite kurz einbauen kann?
Hallo Est Est Est, ich habe einen kleinen Echo-Server mit node.js geschrieben. 1) nodejs.org downloaden 2) Datei im Anhang downloaden 3) Terminal öffnen im Ordner mit der server.js Datei 4) Starten mit >node ./server.js serverport=8080 5) Browser öffnen und eingeben: http://127.0.0.1:8080/echo?comvisu=%235F12,3;%236F32,3; %23 ist das # Symbol im URL Ich habe nach einem nodejs Dienst gesucht und auch gefunden. Aber ich kenn mich mit dem Web-Interface nicht aus :-) Lg
Hallo Weinga Unity, Unsere Bemühungen haben sich jetzt ein bisschen überschnitten, ich hab in der Zwischenzeit schon eine erste Implementierung gemacht gehabt. Im Protokoll gibt es einen kleinen Unterschied, und zwar habe ich es so umgesetzt, dass beim Senden der Befehl im Dokument/Dateibereich übermittelt wird und nicht hinter dem Fragezeichen mit in der URL steckt. Vorteil ist, dass das Format in beide Richtungen gleich ist und die URL tatsächlich 1:1 wie in den Schnittstelleneinstellungen aufgerufen wird. Spricht da etwas dagegen, es so zu machen? Vollständig testen konnte ich meine Lösung bisher nicht, den Ausgang habe ich mir mit WireShark angeschaut und für den Eingang eine Datei mit Inhalt "#0STestRequest" auf meine Webseite gestellt. Hat soweit beides funktioniert. Viele Grüße~
Hallo Est Est Est, entweder irre ich mich jetzt total, aber es gibt ja keinen HTTP-Request (GET, PUT, POST), der es offiziell erlaubt, Daten in beide Richtungen über den Dokument/Dateibereich zu schicken. Deswegen schicke ich die Daten immer über den URL zum Server und die Daten vom Server zum Client im Dokument/Dateibereich. Und alles über einen GET Request. Aber ich kann mich auch irren. Lg
Alles klar, habs jetzt verstanden, die Schnittstelle würde es ermöglichen, aber standardkonform wäre es dann nicht mehr. Dann bau ichs entsprechend um. Ist gut, dass wir darüber gesprochen haben~~ Grüße NACHTRAG: Wenn ich das richtig seh, sind einige Zeichen in der URL nicht erlaubt, d.h. ich muss sie dann ersetzen, wie du es mit der Raute "#" gemacht hast?
:
Bearbeitet durch User
Hallo Est Est Est, ja, das ist immer so eine Sache mit den Zeichen und du siehst das richtig. Darum haben sich auch BASE64 und ähnliches bewährt. D.h. bei Strings musst du aufpassen im URL. Lg
Hallo Weinga Unity, jetzt habe ich nochmal weitergesucht, so ganz zufrieden bin ich noch nicht. Es sind doch einige Zeichen, welche nicht erlaubt sind. Eine zusätzliche Problematik sind dann wohl Unicode-Zeichen. Über Daten im Dateibereich würde sich das vereinfachen, auch bei der Gegenstelle. Laut englischer Wikipedia kann POST in beiden Richtungen einen Body (=Dateibereich?) enthalten. https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Summary_table Aber für mich ist das hier Neuland, d.h. ich lass mich auch überzeugen.
Das ist auch so. Ein POST-Request sendet Daten zum Server mit dem selben Verfahren, mit dem der Server antwortet. URL's haben ja nicht nur "Zeichen-Einschränkungen", sondern machen auch "Probleme", wenn mal etwas mehr Daten mitkommen sollen.
Gibt es dann sonst etwas, das gegen POST und die Übertragung der Befehle im Dateibereich sprechen würde?
Neue Version V0.90 mit folgenden Neuerungen: - Neue Schnittstellenart: URL-Request. Wie in den letzten Beiträgen besprochen lassen sich nun URL-Anfragen durchführen. Es wird die Methode "POST" verwendet und der Sendebefehl in den Dateibereich (Body) der Anfrage gepackt. Der Dateibereich der Antwort vom Server wird dann als Eingang verarbeitet, eine leere Antwort wird ignoriert. Als URL kann eine IP mit zugehörigem Port oder eine "echte" URL angegeben werden, z.B. "comvisu.de/TestRequest". SSL-Anfragen (https) sind nicht möglich. Beim Verbinden wird als Verbindungstest eine "GET"-Anfrage gesendet. - Neues Instrument Lookup-Tabelle Das Instrument Lookup-Tabelle stellt zur Benutzung durch andere Instrumente eine Funktion zur Verfügung, als Funktionsargument wird der Indexwert übergeben. Der Name der Funktion ist in den Eigenschaften der Lookup-Tabelle zu definieren. Die Anzahl an LUT-Instrumenten ist nicht beschränkt und es können quasi beliebige Namen verwendet werden. Die Indexwerte können wahlweise gerundet oder interpoliert werden. - Neue Funktionen (speicherwertig): COUNT,LAST,Z,SEQMIN,SEQMAX,FLOATAVG Speicherwertige Funktionen ist eine neue Kategorie an Funktionen, im Gegensatz zu den bisherigen Funktionen haben sie für jede Verwendung eigene Speicher. So zählt die Funktion COUNT beispielsweise bei jedem Aufruf um eins hoch, und zwar für jedes Instrument getrennt. Details zu den Funktionen sind in der Doku beschrieben. Wenn es Wünsche für weitere Funktionen gibt einfach sagen:-) - Neue Funktionen ANS und Null ANS gibt den Wert des letzten Ergebnisses zurück, sinnvoll zur Berechnung von Filtern. Null gibt unabhängig von den Funktionsargumenten den Wert 0 zurück, äquivalent zu 0* (Null mal...). So zählt Beispielsweise ein Eingang "count()+null(#5)" (Äquivalent zu "count()+0*#5") jeden eingehenden Befehl auf Kanal #5. - Zeitdiagramm löst nun bei jeder Abtastung eine Berechnung aus. Das kostet zwar Rechenzeit, aber so können Funktionen zur Filterung eingesetzt werden, zum Beispiel mit gleitendem Mittelwert (FLOATAVG). - Fehler in XYTimeChart beseitigt Wie immer gibt es auch eine Linuxversion, siehe Beitrag "Re: Comvisu für Linux" Downloads auch unter http://Comvisu.de
Hallo Est Est Est, Lookup-Tabelle Wertetabelle: Fehler beim Laden der Datei Grüße rodnas
Das deutet auf einen Fehler im Dateiformat hin, probier mal die angehängte LUT aus, oder schicke mir deine zum testen. Die beiden Spalten müssen durch ein Tab oder durch e i n Leerzeichen getrennt sein. Grüße
Es funktioniert!!! :) Jetzt habe ich mit Windows Editor erstellt. Früher mit Open Office aber auch als txt abgespeichert und fehlgeschlagen. Danke! rodnas
Hallo Est Est Est, Ich wünsche Dir einen guten Rutsch ins neue Jahr, viel Glück, Gesundheit und Erfolg und Lust das Programm weiter zu entwickeln was Du uns geschenkt hast. Danke nochmals Rodnas
Auch von mir die besten Wünsche. Muss mich jetzt mir dem Proggi mal befassen!
Bei mir ist es jetzt schon schon zweimal abgestürzt. Habe allerdings eine Spezial-CPU auf Win7. Werde es mal auf einem anderen PC testen, ob das da auch so ist. Aber mal was zur Funktion, mit dem Hinweis, daß Ich das noch nicht 100% getestet habe und es sein kann, dass das eine oder andere schon realisert ist. Was es vielleicht noch bräuchte, um damit effektiv arbeiten zu können: - ein ab- und einschaltbares Raster zum Platzieren der Bauteile - automatisches Andocken an Nachbarn, wenn man z.B. zwei Tasten platziert, damit sie nicht überlappen und dicht sitzen - wählbare ICONs, also eine eigene Grafik in einer Standardgröße, zum Beispiel der des Tasters, um selber designen zu können - Einen Schalter, der richtig einrastet, gfs in Form von zwei zu malenden Bitmaps - Slider wie bei einem Mischpult in ausreichender Größe - ein eigenes Hintergrundbild in Vollbildgrösse, das man laden kann - Umschalten auf Vollbild beim Aktivbetrieb, ohne irgendwelche Menüs - Drehknöpfe , die die Position mit einem Strich anzeigen - vom user platzierte Umschaltknöpfe im Bild, mit denen man Seiten wechseln kann, dafür keine Tabs mehr - eine einfache Textausgabe mit wählbarer Farbe aber transparentem Hintergrund Gebaut werden soll sowas: http://www.96khz.org/doc/vasynthesispolymorph.htm Für die Schalter und Taster würde es reichen, wenn man ein "EIN"-Bild hinterlegen kann, dass über die Bitmap im Hintergrund gelegt wird. Der Benutzer muss dann den Hintergrund mit "Aus"-Bild malen. Der weniger versierte Benutzer könnte dann einfach normale Geräte fotografieren und den gedrückten Knopf als Bild nehmen. Bei den slidern und Drehknöpfen wäre wichtig, das sie sofort bei Änderung des Wertes den neuen Senden, damit das Gerät reagieren kann. Die müssten eigentlich nur die Mausposition auswerten, die in dem Bereich des Elementes liegt und dann schauen, oder Knopf angefasst wurde. Bild einblenden ginge mit einem Offset des Bedienknopfes vor transparentem Hintergrund. Wäre in meinem Fall gfs. für den professionellen Einsatz und dürfte ein bissl was kosten.
Jürgen S. schrieb: > Was es vielleicht noch bräuchte, um damit effektiv arbeiten zu können: Dem möchte ich mich voll und ganz anschließen- und noch runde LED-Formen ergänzen. Wünschen wir Est Est Est viel Tatkraft für dieses Jahr! Danke für das jetzt schon überaus nützliche Programm!