Hallo, ich würde mich über ein paar Tipps freuen, die helfen, mein Problem zu lösen. Das ist vorhanden: Konsolen-Software Source-Code geschrieben in Turbo-C unter win95. Über die Tastatur sind Zahlen eintippbar. Diese Zahlen stellen Befehle dar. Diese Befehlszahlen reichen von 3 bis 151. Nach dem Eintippen des Befehls und ENTER werden 11 Byte unterbrechungsfrei über eine COM-Schnittstelle des PCs (9600 BAUD…) an eine CNC-Elektronik geschickt. Diese reagiert mit einer bekannten Quittung usw. Das Protokoll ist bekannt. Meine Vorstellung für eine neue Software unter WIN10: Auf dem PC-Bildschirm sind die Bef‘s als kleine „Bef-Schalter“ sichtbar, die mit der Mouse angeklickt werden können. Beim Anklicken werden die 11 Byte unterbrechungsfrei mit der entsp. Info gesendet und das Programm erledigt den Rest. Oder es gibt ein kleines Eingabefeld, in das ich die Bef.-Nummer eingeben kann und dann mit einem Start-Botton wird der Bef. an die CNC geschickt. Auch eine Konsolenanwendung ist denkbar, wie mom. realisiert. Mein Problem: 1. Einen zu kaufenden USB-COMPORT-ADAPTER, der diese 11 Byte unterbrechungsfrei an die CNC sendet und auch Daten von der CNC empfängt. 2. Ist das mit der kostenlosen VISUAL STUDIO 2022 Umgebung zu schaffen? 3. Welche Prog.-Sprache würdet ihr nehmen (C oder BASIC, vorausgesetzt das geht mit der kostenlosen VISUAL STUDIO 2022 Umgebung)? Kenntnisse: In VISUAL STUDIO 2022 habe ich eine C-Konsolenanwendung geschrieben, die aus einem File ein Kennwort sucht, und nach dem Finden den TEXT nach dem Kennwort ausgibt. Frühere Erfahrungen mit USB-COMPORT-ADAPTER und der zugehörigen Software (MFC), die beim Senden der 11 Bytes zwischendrin eine Pause einlegte, was die CNC als Fehler interpretierte. Dieses Problem wurde damals nicht gelöst, und deswegen wurde die Sache abgebrochen. Danke für Antworten. VG Walter
Walter L. schrieb: > Konsolen-Software Source-Code geschrieben in Turbo-C unter win95. Das ist also einfach ein DOS-Programm. Walter L. schrieb: > Frühere Erfahrungen mit USB-COMPORT-ADAPTER und der zugehörigen Software > (MFC), die beim Senden der 11 Bytes zwischendrin eine Pause einlegte, > was die CNC als Fehler interpretierte. Dieses Problem wurde damals nicht > gelöst, und deswegen wurde die Sache abgebrochen. Hätte man aber lösen können. Wenn man mit der seriellen Schnittstelle auf die falsche Weise umgeht, passiert sowas, macht mans richtig, passiert das nicht. Hast Du den Quelltext von dem damaligen Versuch noch?
>Hast Du den Quelltext von dem damaligen Versuch noch?
Nein.
In WIN10 V1809 (2018) hat sich da wohl einiges getan. Siehe
Serieller USB-Treiber (Usbser.sys)
VG Walter
Das hat man doch in VB6 in einer Stunde zusammengeklickt. :) Das haben sogar Elektor-Autoren geschafft. Fuer die RS-232 gibt es eine DLL fuer VB6.
Walter L. schrieb: > In WIN10 V1809 (2018) hat sich da wohl einiges getan. Siehe > Serieller USB-Treiber (Usbser.sys) Das ist völlig irrelevant. Komplett falsche Fährte. USB-Seriell-Adapter lassen sich unter Windows schon sehr, sehr viel länger ohne Probleme verwenden. Die meisten nutzen eh' nicht den von MS zur Verfügung gestellten Standardgeräteklassentreiber, sondern ihren eigenen proprietären, denn die meisten USB-Seriell-Adapter sind keine CDC-Devices. So ist es bei SiLabs, FTDI, WinChipHead, Prolific ...
Wenn die Befehlszahlen alle bekannt sind, würde ich eine Listbox in VB nehmen. Die Klicks in der Listbox kann man ja auch abfragen. Oder auch eine Gridbox, wenn noch mehr Infos über die entsprechende Befehlszahl angezeigt werden sollen. Das spart halt durch das vertikale Scrollen einiges an Platz. Man könnte auch eine Groupbox mit Radiobuttons nehmen. Kommt halt ganz auf deinen Geschmack und Platz an. Da geht ja einiges. Auch Auswahlboxen würden sich evtl. eignen. Als Konsolenanwendung würde ich das nicht mehr machen.
:
Bearbeitet durch User
ich habe hier ein paar cp210x liegen. Aber damit wollte ich nun nicht mit anfangen zu basteln. Welchen USB-COMPORT-Adapter kann man kaufen? VG Walter
Ich merke schon. Es geht in Richtung VB. VB müßte ich aber dann mir neu aneignen. Wenn ich das so lese mit "Groupbox mit Radiobuttons ...." Da wäre mir doch C lieber. Oder jemand hat ein VB-Beispielcode, den ich in Visaul Studio VB reincopieren kann. Dann muss aber auch der entsprechende USB_COM_ADABTER bekannt sein. VG Walter
Walter L. schrieb: > Da wäre mir doch C lieber. Ne grafische Oberfläche mit C ist aber dann schon sehr ambitioniert, wenn das überhaupt funktioniert. Wenn es eine grafische Oberfläche werden soll dann führt eigentlich kein Weg an einer passenden IDE, wo man die Oberfläche in wenigen Minuten zusammen geklickt hat vorbei. Ob das am Ende z.B. Qt mit C++, Visualstudio (C#, .NET), Delphi/Lazarus (Pascal) oder eben auch VB wird ist für's erste erst mal egal. Das Zusammenbauen der GUI funktioniert bei allen so ziemlich gleich. Der unvermeidbare Code der zum Auswerten der Klickevents nötig ist, ist je nach Programmiersprache natürlich unterschiedlich, aber kein Teufelswerk. Ich kann das jetzt mal auf die Schnelle für Delphi erläutern. Da braucht es im Wesentlichen eine Liste, wo die ganzen Befehle namentlich drin stehen. Die Liste gibt es fix und fertig als Komponente, d.h. man zieht sie einfach auf ein Formular. Für das Füllen der Liste mit Einträgen gibt es einen Inplaceeditor der Komponente. Jeder Eintrag hat je nach Position in der Liste eine Nummer beginnend bei 0. Jetzt muß man nur noch definieren was passieren soll, wenn man auf so einen Eintrag klickt. Dafür gibt es eine vorgefertigte Eventfunktion, die man nur noch mit dem gewünschten Code füllen muß, also Nummer des Eintrags ermitteln und die Nummer dann einfach über die serielle Schnittstelle senden. Für die serielle Schnittstelle gibt es auch Komponenten mit allen was dazu gehört (auch Terminalkomponente, da könnte man sehen was die CNC antwortet). Die serielle Schnittstellenkomponente funktioniert mit allen vom PC angezeigten Schnittstellen.
:
Bearbeitet durch User
Walter L. schrieb: > Da wäre mir doch C lieber. Na gut, wenn du ja schon mit C klarkommst oder kannst, nimm dir halt einen C-Compiler und bau dir deine Anwendung zusammen. Aber, wenn du noch nie eine GUI programmiert hast, wird das so oder so schwierig für dich. Sicher, man kann solche Buttons auch in einer Konsole- Anwendung nachempfinden, indem man einfach farbige Kästchen malt und die Mauskoordinaten entsprechend abfragt. Bloß wird das für ca. 100 Buttons ein riesiger Aufwand. Oder such dir eine Sprache, mit der du am besten klar kommst. VB hat halt den Vorteil, daß man seine GUI (Bedienoberfläche) zusammenklickt. VB stellt dir dann automatisch die Button-Klicks als Unterprogramme bereit, die du dann nur noch mit Leben füllen brauchst (Befehl senden). Ist ja heutzutage kein Hexenwerk mehr. Was den Adapter betrifft : am besten einer mit FTDI-Chip. Persönlich kann ich den Digitus empfehlen. https://www.amazon.de/DIGITUS-70156-Typ-Konverter-Verl%C3%A4ngerungskabel/dp/B0030IT780/ref=asc_df_B0030IT780?tag=bingshoppin0b-21&linkCode=df0&hvadid=80814161469019&hvnetw=o&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4584413736836314&psc=1 Und die cp210x - Treiber sind ja auch gut.
:
Bearbeitet durch User
Ich programmiere in Delphi und benutze nur Adapter mit FTDI Chip, dann im COM Treiber die Empfang und Sendebuffer auf 64 Byte stellen und die Polling Zeit über USB auf 2ms, dann das Protokoll mit 11 Byte in den Buffer schreiben und die kommen lückenlos am Empfänger an. Benutze als COM Treiber in Delphi dann CPORT, zwar mit eigenen Erweiterungen aber der normale sollte auch klappen
Walter L. schrieb: > Welchen USB-COMPORT-Adapter kann man kaufen? Irgendwas mit FTDI-Chip, die sind i.d.R. stressfrei. Aber besser nicht billig bei Aliexpress kaufen, die Treiber des Herstellers mögen keine gefälschten FT232. Hans schrieb: > Ne grafische Oberfläche mit C ist aber dann schon sehr ambitioniert, > wenn das überhaupt funktioniert. Das geht ohne Probleme, aber dafür muss man sich mit der Windows-API befassen. Definitiv kein Anfängerprojekt.
Hmmm schrieb: > Das geht ohne Probleme, aber dafür muss man sich mit der Windows-API > befassen. Definitiv kein Anfängerprojekt. Daher sollte er sich auch eine Sprache nehmen, die die Windows-API weitestgehend kapselt (versteckt). Wenn er sich damit auch noch rumschlagen muß, wird das nichts. Zuerst müssen wir ja mal wissen, wie der Wissensstand von Walter L. ist. Oder hat er überhaupt schon mal programmiert.
Th S. schrieb: > benutze nur Adapter mit FTDI Chip, dann > im COM Treiber die Empfang und Sendebuffer auf 64 Byte stellen und die > Polling Zeit über USB auf 2ms, dann das Protokoll mit 11 Byte in den > Buffer schreiben und die kommen lückenlos am Empfänger an. Also bei der COM-Port Komponente von Delphi, mußte ich noch nie irgendwelche Klimmzüge machen. Da funktionieren i.d.R. alle seriellen Ports die unter Windows angezeigt werden problemlos. Was mir aber im Zusammenhang mit Ansteuerung externer Gerätschaften über eine beliebige Schnittstelle (LAN, RS232 etc.) aufgefallen ist, das es Probleme gibt wenn für die benutzte Schnittstelle irgendwelche Energiesparmodi aktiv sind. Da ist es mir schon öfter passiert das die Verbindung abbricht, weil Windows der Meinung war die Schnittstelle temporär abzuschalten, weil sie ja eh nichts macht. Speziell in Richtung von extern zum PC ist mir das aufgefallen, kann aber auch in die andere Richtung zu Problemen führen. Ich bin bisher immer gut damit gefahren den jegliche Energiesparmodi für diese Schnittstellen im Gerätemanager zu deaktivieren - hat mich bisher auch nicht in den finanziellen Ruin getrieben. Das bloß mal so als Denkanstoß, wo man auch mal bei Problemen nachschauen sollte.
Walter L. schrieb: > Ich merke schon. Es geht in Richtung VB. > VB müßte ich aber dann mir neu aneignen. > Wenn ich das so lese mit "Groupbox mit Radiobuttons ...." > > Da wäre mir doch C lieber. > > Oder jemand hat ein VB-Beispielcode, den ich in Visaul Studio VB > reincopieren kann. Dann muss aber auch der entsprechende USB_COM_ADABTER > bekannt sein. > > VG Walter Das kannst du auch in VS in 10 Minuten zusammenklicken. Die serielle Schnittstelle hat schon seit Ewigkeiten einen Zeichenbuffer, der zumindest 16 Bytes gross ist. Die ganzen USB <-> RS232 Konverter haben auch einen Buffer, der allerdings viel grösser ist. Du musst nach jedem 11 Byte Befehl "Flush Buffer" ausführen, sonst wartet der USB Kontroller bis sein interner Buffer überläuft, und schreibt dann halbe Kommandos. Das Timing ist übrigens sehr reproduzierbar auf < 1 ms unter Win10. Ich habe mir den Spass gemacht, und dir eine Win32 Anwendung mit 32 Buttons zusammengeklickt. Das hat kürzer gedauert, als diesen Beitrag zu verfassen. Die Buttons sind aber im Help Dialog drinnen. Den Dialog kannst du beim Start ausfüren. Jetzt musst du nur noch jeden Button mit einer SendCommando() Funktion versehen, und beim Programmstart die Serielle Schnittstelle mit OpenFile aufmachen. Die 11 Bytes schreibst du dann mit WriteFile() in die RS232.
Hans schrieb: > Wenn es eine grafische Oberfläche werden soll dann führt eigentlich kein > Weg an einer passenden IDE, wo man die Oberfläche in wenigen Minuten > zusammen geklickt hat vorbei. Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben und ist universeller unterwegs als mit klicki bunti.
Ich habe dir noch ein Update gemacht, jeder der 32 Buttons ist mit einer Funktion verbunden, die einen String in ein Edit-Control reinschreibt. Das kannst du als Startpunkt verwenden, wenn du möchtest. Gruss, Udo
Man könnte auch den Open Watcom Compiler nutzen. DOS geht zwar nicht mehr ohne EMU, aber 32 Bit. Dos-Konsole-Code kann man auch über den 32bit-Linker in 32Bit-ProtectedMode übersetzen.
Re D. schrieb: > Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben > und ist universeller unterwegs als mit klicki bunti. Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein Widget auf ein Formular ziehe - träum weiter.
Danke Udo, ich versuche das am Wochenende und melde mich dann... VG Walter
Simples HTML-File mit Buttons und Javascript?
1 | const port = await navigator.serial.requestPort(); |
2 | await port.open({ baudRate: 9600 }); |
3 | ...
|
4 | <button onclick="sendCommand(1,'ABC123xxx')">Command 1</button> |
Billiges Mikrocontroller-Board (Arduino?) mit physischen Buttons versehen und per UART die Befehle rausschicken? Ist dann garantiert präzises Timing ohne Probleme durch den USB-Adapter und funktioniert auch ohne PC...
Hallo UDO, RS232Cmd.vcproj gestartet. Ergebniss: Fenster öffnet sich mit nichts drin, kein Botton. Ist das so gepalnt? Visual Studio sagt folgendes: Erstellen gestartet... 1>------ Erstellen gestartet: Projekt: RS232Cmd, Konfiguration: Release Win32 ------ 1>D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.Analysis.p rops(24,5): warning MSB4211: Die Eigenschaft "MsvcAnalysisPluginPath" wird zum ersten Mal auf einen Wert festgelegt, doch dieser wurde bereits in "D:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CodeAnalysis.E xtensions.props (33,5)" verwendet. 1>stdafx.cpp 1>RS232Cmd.cpp 1>Code wird generiert. 1>Previous IPDB not found, fall back to full compilation. 1>All 6 functions were compiled because no usable IPDB/IOBJ from previous compilation was found. 1>Codegenerierung ist abgeschlossen. 1>RS232Cmd.vcxproj -> D:\TEMP_HS\RS232Cmd\RS232Cmd\Release\RS232Cmd.exe ========== Build: 1 erfolgreich, 0 Fehler, 0 aktuell, 0 übersprungen VG Walter
Rufe das Help Menü auf. Ich habe die Buttons in den Help Dialog reingetan. Ich habe dir noch schnell ein Program gemacht, das mit dem Button-Dialog startet. Ist im Anhang. Da gibt es jetzt eine Funktion WriteRS232(), die schreibt das Kommando in das Terminal. Da musst du das richtige Handle auf die RS232 einsetzen.
:
Bearbeitet durch User
Walter L. schrieb: > Auf dem PC-Bildschirm sind die Bef‘s als kleine „Bef-Schalter“ sichtbar, > die mit der Mouse angeklickt werden können. Beim Anklicken werden die 11 > Byte unterbrechungsfrei mit der entsp. Info gesendet und das Programm > erledigt den Rest. Hier wäre ein bisschen mehr Information zum "Rest" sinnvoll. > 2. Ist das mit der kostenlosen VISUAL STUDIO 2022 Umgebung zu > schaffen? Ja. > 3. Welche Prog.-Sprache würdet ihr nehmen (C oder BASIC, vorausgesetzt > das geht mit der kostenlosen VISUAL STUDIO 2022 Umgebung)? Ich würde eine Sprache mit folgenden Eigenschaften empfehlen: 1. Du kannst sie oder bist daran interessiert, sie zu lernen. 2. Es ist damit ohne Verrenkungen möglich, eine GUI oder einen Webservice zu entwickeln. 3. Die Sprache (und eventuell die GUI-Library) ist plattform-unabhängig, so daß Dir die Geschichte nicht im Wege steht, wenn Du irgendwann mal auf einen Mac, ein Linuxsystem (etwa einen RasPi oder einen passenden Industrierechner) wechseln möchtest. Man weiß ja nie... Meine ganz persönliche erste Wahl für so etwas wäre Go(lang) mit Gofiber, wenn ich einen Webservice entwickeln wollte, oder entweder Python oder C++ mit Qt, wenn es eine native GUI-Anwendung werden soll. Was für einen Webservice spricht: Du kannst Deine Buttons und alles Weitere ganz einfach mit HTML erstellen und mit CSS hübsch machen. Wenn ein bisschen Interaktivität notwendig ist (siehe dazu oben unter dem Hinweis "Rest") sind allerdings leider JavaScript und eventuell Websockets das Mittel der Wahl. Aber gut, das sind die Möglichkeiten, die ich in Betracht ziehen würde, und natürlich davon beeinflußt, daß ich die genannten Sprachen und Technologien bereits kenne. Für Dich kann die Wahl natürlich anders aussehen, aber dennoch solltest Du Dir möglicherweise die Frage stellen, ob ein Webservice für Dich in Frage kommen könnte.
Niklas G. schrieb: > Billiges Mikrocontroller-Board (Arduino?) mit physischen Buttons > versehen und per UART die Befehle rausschicken? Ist dann garantiert > präzises Timing ohne Probleme durch den USB-Adapter und funktioniert > auch ohne PC... War auch meine erste Idee, eine Tastatur-Matrix z.B. https://www.ebay.de/itm/174939241575, ein X-duino (wenn Du C kannst, findest Du Dich schnell zurecht) oder ein beliebiger ESP, nach Wunsch noch ein OLED- oder LCD, das geht doch ganz schnell. Wenn Deine CNC echte RS232-Level braucht (+-12V), noch ein MAX3232.
Von der Perspektive der schrittweisen Entwicklung wäre es vielleicht hilfreich, sich eines der Petzold-Bücher zu schnappen, und schauen, wie ein einfacher Button da eingerichtet wird. Das muss man sich natürlich erstmal ansehen, und verdauen - ist aber beim CP üblicherweise sehr gut erklärt. Eines der Probleme ist auch, wie kompatibel ist der (alte) Code aktuell noch. Ein anderes, dass es die Bücher wohl nicht mehr aktuell gibt. Mit etwas Glück findet man was zum Ausleihen in einer Uni-Bib. Wichtig ist, "CP" mit C zu bekommen. Die anderen Bücher sind auch interessant - aber dann auch keine schrittweise Hilfe mehr. Die nächste Ebene wäre dann .NET-Programmierung. Eine andere Überlegung/Perspektive wäre das was Ein.T oben geschrieben hat. Dann hat man auch eine Möglichkeit, Echtzeit-freundlichere Betriebssysteme einzusetzen. (https://www.acontis.com/de/windows-and-realtime-Why-RT-Linux-is-the-Best-Solution-for-Adding-Real-time-Capabilities-to-Windows.html)
Rbx schrieb: > Eines der Probleme ist auch, wie kompatibel ist der (alte) Code aktuell > noch. Die grundlegende Art und Weise, mit der Win32-API mit seriellen Schnittstellen zu kommunizieren (Port öffnen, Baudrate etc. einstellen, Daten senden und empfangen), hat sich in den letzten drei Jahrzehnten nicht geändert. Und wenn man aus irgendwelchen Gründen daran glaubt, daß es mit USB-Seriell-Adaptern aber Probleme geben muss, dann nimmt man halt einen von FTDI und spricht den nicht über die Win32-API, sondern mit den von FTDI zur Verfügung gestellten Funktionen der FTD2XX-DLL an. Dokumentation dafür gibts hier: https://ftdichip.com/wp-content/uploads/2023/09/D2XX_Programmers_Guide.pdf
Rbx schrieb: > Eine andere Überlegung/Perspektive wäre das was Ein.T oben geschrieben > hat. > Dann hat man auch eine Möglichkeit, Echtzeit-freundlichere > Betriebssysteme einzusetzen. Hmmm, ich bin unsicher, ob diese Idee zielführend ist. Der Typ schlägt einen Webservice in Golang vor. Das heisst, dann wäre dabei auch noch ein Netzwerk mit all seinen Komplexitäten und Unzuverlässigkeiten beteiligt. Ich kenne ein paar recht zuverlässige, aber nur wenige echtzeitfähige Netzwerktechnologien, deren Gemeinsamkeit beachtliche Kosten sind. Ich glaube auch nicht (vielleicht wissen die anwesenden Fachleute dazu mehr), dass es harte Echtzeit benötigt, um einen Puffer von wenigen Bytes auf eine Serielle Schnettstille zu schreiben und eine Antwort davon zu erhalten. Zur grössten Not würde ich mir einen RasPi nehmen, per Kernelparameter "isolcpus" einen oder zwei CPU-Kerne vom normalen Prozeßscheduler ausnehmen und mein Programm dann mit taskset(1) auf diese Kerne zwingen, so dass das Programm nicht vom Systemkernel unterbrochen werden kann. Dass dazu zusätzlich auch noch RT-Patches benötigt werden, halte ich für unwahrscheinlich (natürlich lasse ich mich immer gerne eines Besseren belehren). Für einen einfachen Webservice in Golang habe ich hier einmal etwas aus einer anderen Software gebaut und angehangen. Da ist (noch?) nichts Serielles drin und es benutzt (IMHO) ein paar ganz schicke Tricks, zeigt aber ganz gut, wie mittels Golang ein kleiner, einfacher und enorm schneller Webservice gebaut werden kann. Von dem, was Ein Typ vorschlägt, weiche ich allerdings ab, denn meine Templates bleiben (noch?) externe Dateien, die ebenfalls deployt werden müssten. Mit dem Go-Modul "embed" würden sie sich aber auch leicht fix in das Executable integrieren lassen -- das habe ich zwar schon einmal erfolgreich gemacht, war jetzt gerade aber zu faul dazu. :) Achtung, ich habe ganz bewußt kein Executable hineingelegt, einerseits wegen dessen Grösse und andererseits aus Sicherheitsgründen. Für jemanden, der eine halbwegs aktuelle Go-Entwicklungsumgebung (ab Version 1.21 aufwärts), make(1) installiert und der keine Angst davor hat, Befehle auf einer Kommandozeile einzugeben, sollte das aber eine leichte Übung sein:
1 | 1. Zip-Datei entpacken |
2 | 2. In das entpackte Verzeichnis wechseln |
3 | 3. "make" aufrufen |
Wenn dabei Probleme auftreten sollten, bitte hier melden, dann helfe ich natürlich gerne bei der Behebung. Wenn keine Probleme auftreten:
1 | 4. Programm mit "./sercmd" starten |
2 | 5. Im Webbrowser "http://localhost:8000/" aufrufen |
Wer zusätzlich noch den Komprimierer upx(1) installiert hat, kann mit "make compress" eine komprimierte Version des Executable erzeugen. Das Make-Target "windows" erzeugt (auch unter Linux) ein Windows-kompatibles Executable, und das Target "compress-windows" ein Windows-Executable, das zudem komprimiert und deswegen relativ klein ist. Ohne Komprimierung sind die Executables hier 7,6 für die Linux- und 9,5 MB für die Windows-Version gross. PS: Bevor sich die Damen und Herren "ich weiss alles, vor allem besser" jetzt darüber echauffieren, dass die Executables doch bitte kleiner sein könnten: bitte bedenkt, dass das statisch gelinkte Executables sind, die die gesamte Go-Runtime und zudem einen Webserver enthalten, der je nach Benchmark sogar schneller und ressourcenschonender als der beliebte nginx ist. :)
Sheeva P. schrieb: > Ich glaube auch nicht (vielleicht wissen die anwesenden Fachleute dazu > mehr), dass es harte Echtzeit benötigt, um einen Puffer von wenigen > Bytes auf eine Serielle Schnettstille zu schreiben und eine Antwort > davon zu erhalten. Braucht es natürlich nicht. Man sollte nur nicht versuchen, zu viele Softwareabstrationsschichten zwischen die Win32-API (durch die letztlich jeder Schnittstellenzugriff erfolgt) und das eigentliche Programm zu stopfen.
Hans schrieb: > Re D. schrieb: >> Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben >> und ist universeller unterwegs als mit klicki bunti. > > Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein > Widget auf ein Formular ziehe - träum weiter. Ein Widget auf ein Form zu ziehen ist ja keine Kunst, das geht schnell. Anfangs sieht auch alles leicht aus, einfach die GUI zusammen klicken, an den vorgesehen Stellen die eigenen Funktionen oder Methoden klimpern, fertig. Aber wenn das Ganze dann auch noch annehmbar aussehen, oder sogar wiederverwendbar sein oder automatisch generiert werden soll, ist das Ganze plötzlich gar nicht mehr ganz so einfach und leicht und schnell wie anfangs gedacht. Und wehe Du willst etwas bewerkstelligen, das die Entwickler Deiner Widgets nicht bedacht haben... dann hast eventuell sogar ein echtes Problem und kannst im übelsten aller üblen Fälle den Buildprozess Deines Werkzeugs hacken. BTDT, und das war nicht einmal ansatzweise vergnügungssteuerpflichtig.
Mit C# und WinUI geht sowas auch recht gut, da sind die Frameworks auch vorinstalliert und man bekommt Installer/Uninstaller integriert, es funktioniert mit Touchscreen und wäre sogar mit dem Microsoft Store kompatibel und auch ARM-Windows.
Rbx schrieb: > Man könnte auch den Open Watcom Compiler nutzen. DOS geht zwar nicht > mehr ohne EMU, aber 32 Bit. Dos-Konsole-Code kann man auch über den > 32bit-Linker in 32Bit-ProtectedMode übersetzen. Natürlich kann man das machen, und für Leute, die sich mit dem Compiler gut auskennen, ist das vielleicht auch eine feine Sache. Aber wir schreiben mittlerweile das Jahr 2024. Es gibt andere frei verfügbare Compiler für C und C++, allen voran sicherlich GCC und LLVM. Warum sollte sich jemand für ein neues Projekt ausgerechnet den Open Watcom aussuchen und sich damit im Prinzip eine Altlast an die Backe kleben? Ok, ich weiß, das ist ein feines Stück Software und meine Aussagen lesen sich viel negativer als meine Meinung tatsächlich ist, und Open Watcom wird auch von einem kleinen Team von Galliern in einem "Dorf der Unbeugsamen" immer noch weiter entwickelt. Aber ich frage mich leider trotzdem nach dem tieferen Sinn, solche Exoten für neue Projekte einzusetzen. Das zieht doch sekundäre Probleme nach sich: wenig aktuelle Dokumentation und Unterstützung aus einer kleinen Community, weniger gute Anpassungen an aktuelle Hardware... und das ist ja nur der Anfang. Insofern, bitte sei doch so lieb und erklär' mir (bitte besonders langsam und ausführlich, ich bin ja nicht mehr der Jüngste): welchen Vorteil hätte es für den TO, OpenWatcom zu benutzen? Welche Nachteile hätte er zu gewärtigen? Und inwieweit würden die Vorteile für ihn die Nachteile überwiegen? Lieben Dank.
Udo K. schrieb: > Ich habe dir noch ein Update gemacht, jeder der 32 Buttons ist mit einer > Funktion verbunden, die einen String in ein Edit-Control reinschreibt. > Das kannst du als Startpunkt verwenden, wenn du möchtest. Wow, das ist wirklich absolut beeindruckend! Danke dafür, daß Du die Eier hast, etwas zu entwickeln und hier einzustellen, das finde ich richtig gut (auch wenn ich Cpp-Code für Windows nicht lesen kann). Danke!
Harald K. schrieb: > Man sollte nur nicht versuchen, zu viele > Softwareabstrationsschichten zwischen die Win32-API (durch die letztlich > jeder Schnittstellenzugriff erfolgt) und das eigentliche Programm zu > stopfen. Zu Microsoft Windows kann ich (*1) nichts sagen, und verlasse mich daher natürlich auf Dein fachmännisches Urteil. (*1) "Leider" oder "glücklicherweise", wer weiss das schon. :-)
Niklas G. schrieb: > Mit C# und WinUI geht sowas auch recht gut, da sind die Frameworks auch > vorinstalliert und man bekommt Installer/Uninstaller integriert, es > funktioniert mit Touchscreen und wäre sogar mit dem Microsoft Store > kompatibel und auch ARM-Windows. Ja, da habe ich keine Zweifel. Was Entwicklungswerkzeuge angeht, waren die Leute bei Microsoft immer sehr gut, weil sie schon vor Jahrzehnten verstanden haben, dass man Benutzer über Software und Softwareentwickler über Werkzeuge anziehen kann. Deswegen investiert Microsoft auch so viel in diesem Bereich, beispielsweise Powershell, Mono, WSL2, Iron Python und Visual Studio Code, um nur einige bekanntere Beispiele zu nennen. Angelegentlich muss man auch feststellen, dass Microsoft in diesen Bereichen traditionell Vorsprünge gegenüber seinen Wettbewerbern hat. Eine konsistente API für System und Applikationen, na klar, das hat was. Anständige Werkzeuge wie Visual Studio, sogar kostenlos: yay. Ich verstehe das sehr gut. Aber trotzdem ist das nicht meine Welt und wird es auch nicht mehr. Ich bin glücklich mit UNIXoiden, heutzutage mit Linux. Alles gut, oder? :-)
Walter L. schrieb: > Ich merke schon. Es geht in Richtung VB. > VB müßte ich aber dann mir neu aneignen. > Wenn ich das so lese mit "Groupbox mit Radiobuttons ...." Genau da liegt ja schon das Problem, egal jetzt welche Sprache für WIN der TO nutzen möchte. Wenn man die grundlegenden Elemente schon nicht kennt, obwohl man fast täglich in WIN mit ihnen arbeitet ? Er meint wohl, daß die GUI-Elemente nur bei VB drin sind. Jedenfalls scheint das mit einem Windowsprogramm eher schwierig für ihn zu werden. Es läuft dahin hinaus, wie schon so oft gesehen (ob hier im Forum oder andere), daß das Projekt schlußendlich beim ihm in der Tonne landet.
Hans schrieb: > Also bei der COM-Port Komponente von Delphi, mußte ich noch nie > irgendwelche Klimmzüge machen. Da funktionieren i.d.R. alle seriellen > Ports die unter Windows angezeigt werden problemlos. Benutzt aber auch nur das COMM-Api. Damit hast du letztlich exakt dasselbe, als wenn du es mit einer .NET-Sprache machst (egal ob C# oder VB.net). Der SerialPort aus dem .net-Framework setzt letztlich auch nur auf dieses seit Urzeiten bekannte COMM-Api auf. Warum auch nicht? Warum sollte man etwas, was einfach und logisch ist und seit Jahrzehnten problemlos funktioniert, durch was anderes ersetzen wollen?
HAllo Udo, danke für deine konstuktive HILFE. Habe dir eine PN geschickt. VG Walter
Walter L. schrieb: > HAllo Udo, > > danke für deine konstuktive HILFE. > > Habe dir eine PN geschickt. > > VG Walter Falls du das nicht verstanden hast: auch der prähistorische C-Kram von Udo K. nutzt letztlich nur das COMM-Api... Einfach deshalb, weil es unter WindowsNT niemals einen anderen als diesen Weg gab und jedes Windows, was in den letzten zwei Jahrzehnten relevant wurde, ein Erbe von Windows-NT ist. Bei den DOS-basierten Windows-Versionen (1,2,3.x, 95, 98 und ME) gab es noch die Möglichkeit, am OS vorbei auf die Hardware der COM-Ports zuzugreifen, das aber natürlich nur auf die mit echter UART-Hardware. Für virtuelle COM-Ports (z.B. über USB bereitgestellt) war auch bei diesen Krüppel-Windows-Versionen der Zugriff auf das COMM-Api beschränkt. Maximal ging was über IOCTL-Funktionen des Treibers, die aber fast nie dokumentiert waren.
Hallo, ich habe aus 2013 einen cp210x angeschlossen. Im Gerätemanager taucht com5 auf. Soweit ich das hier verstanden habe, ist so eine Anwendung mit Visual Studio 2022 in 30 Minuten programmiert, eine Konsolenanwendung in 10 Minuten. Mir würde zunächst schon eine Konsolenanwendung reichen (um da reinzukommen) die 11 Bytes unterbrechungsfrei sendet und danach sofort 1 bis 16 Byte empfängt. Danach Pause von 1 Sek oder länger. MODE COMx:9600,N,8,1. Keine handshake leitungen. Danke für ein Beispiel. VG Walter
Angehängte Dateien:
-
wxWidgets.png
110 KB
Hans schrieb: > Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein > Widget auf ein Formular ziehe - träum weiter. Der Ratschlag lautet: Nicht über Dinge reden von denen man keine Ahnung hat. Ach ja, zum Schluss lässt man sich den Code generieren.
:
Bearbeitet durch User
Ein Betriebssystem-unabhängiges Beispiel mit Qt in C++ http://stefanfrings.de/serial_io/index.html#qtexample
Was die RS232 betrifft, wäre noch zu klären, wie die CNC den Input haben möchte. Eine Zahl zwischen 3 und 151 kann man ja unterschiedlich interpretieren. Wenn ich jetzt die 151 senden möchte, habe ich als Hexzahl die 97 oder kann die Ziffern auch hintereinander einzeln senden : 1,5,1 Im ersten Fall sind es nur 1 Byte und im zweiten Fall sind es 3. Da der Byterahmen ja 11 Bytes groß ist, fehlen da noch einige Bytes, entweder als Füllbytes oder mit sonstigen Infos oder gar beides. Da braucht man dann schon entweder eine Beschreibung von der Hardware oder den Quellcode des Programms. Eine andere Frage ist, wieviele Befehle gibt es ? Der Wertebereich des TO läßt eher 148 (3-151) vermuten oder sind es weniger ? Desweiteren muß man daran denken, daß sich da 2 Welten treffen. Einmal ASCII (OEM) bei der Hardware und zweitens ANSI in der Windowswelt. Damals konnte ich auch keine Antwort von meinem AVR empfangen. Erst, als ich beim Programmieren des AVR ein Chr$(0) an den String anhängte, empfing ich den auch in meiner Windows-Sprache. Soll heißen, wenn die Hardware kein abschließendes Nullbyte dranhängt, muß man es als Bytesequenz empfangen und händisch ein Nullbyte dranhängen, um es etwa in einem MultiEdit darstellen zu können. Das sind halt so Stolpersteine.
@hbrill Alles irrellvant. Aber ein Bsp. für sie, der BEf3 Byte 0 1 2 3 4 5 6 7 8 9 10 3 0 0 0 0 0 0 0 0 0 3 alles dezimal. Das zente Byte ist die Summen über 0 bis 9. Und die CNC will das so, und nicht anders. In der jetzige C-Software läuft das so. Also, wo ist der 10 Min. Bsp.-Code hbrill? Danke. VG Walter
Walter L. schrieb: > 0 1 2 3 4 5 6 7 8 9 10 > > 3 0 0 0 0 0 0 0 0 0 3 Das sind mit ENTER in der Windows-Welt aber 12 (zwölf) Bytes und nicht 11. In Windows wird ENTER mit CR LF übergeben, also 0xD 0xA
:
Bearbeitet durch User
Uxdx nix... Von Enter LF und CR war keine Rede. Lesen, und, wo ist dein code? VG walter
Sheeva P. schrieb: > Insofern, bitte sei doch so lieb und erklär' mir (bitte besonders > langsam und ausführlich, ich bin ja nicht mehr der Jüngste): welchen > Vorteil hätte es für den TO, OpenWatcom zu benutzen? Welche Nachteile > hätte er zu gewärtigen? Und inwieweit würden die Vorteile für ihn die > Nachteile überwiegen? Lieben Dank. Möchtest du die Antwort als a) geschätzter Forenteilnehmer oder b) Mitglied einer Kaste, die mir das Skyrimspielen auf Linux vermiest/vermurkst? Ich biete nur eine zur Auswahl. Beide Antworten gehen mehr oder weniger ins OT - aber da möchtest du ja auch unbedingt hin? @Walter: eventuell ist die Setup-Beschreibung oben doch etwas zu sehr eingegrenzt. Die Frage hinsichtlich der Softwarelösung ist eventuell auch etwas zu grob ohne Einsicht in problematische Code-Felder im bereits vorhandenem Programmcode.
Walter L. schrieb: > Also, wo ist der 10 Min. Bsp.-Code hbrill? Das war wohl ein anderer, der dir das versprochen hat : Udo K. schrieb: > Das kannst du auch in VS in 10 Minuten zusammenklicken. Außerdem kann ich auch gar kein C und arbeite auch nicht mit VS. Da meine Basicsprache nur Strings schicken und empfangen kann, müßte ich erst eine entsprechende DLL finden, die auch Speicherbereiche senden und empfangen kann. Also die erste (0.Byte) 3 ist der Befehl und das 10.Byte ist die Summe, also auch 3. Wäre bei einem Befehl z.b. 125 1 2 5 0 0 0 0 0 0 0 8 oder bei 88 : 8 8 0 0 0 0 0 0 0 1 6 Sehe ich das so richtig ?
Macht zu das Ding. Bei so vielen Honk-ytonks wird das nix mehr. VG Walter
Ja, besser zu machen. Da es ja Befehle von 3 bis 151 gibt, erschließt es sich mir nicht, wie ich eine zweistellige Zahl (Summe) in einem einzigen Byte unterbringen kann. Irgendwas ist da nicht richtig. Ich bin da mal auch raus.
Ein un. Byte umfasst den Zahlenbereich von 0 bis 255. Wieso passt 155 nicht in ein Byte, hbrill?
Der TE möchte, dass ihm geholfen wird, pöbelt aber gebetsmühlenartig mit dummen Fragen "wo ist der Code" rum. Da sehe ich keine Sympathie, einem solchen Menschen zu helfen, der frech nur Forderungen hat.
Uxdx Hilfe kommt vom codebeispiel, den der TE in C wünscht, sonst nix. Auch sie haben nix konstruktives geliefert.
Es sind ein paar Sachen nicht ganz klar: 9600Baud ist eine Ewigkeit fuer einen aktuellen Computer, insbesondere weil ja RS232 das eigene Timing macht. Da das Ding ja fuers Geschaeft ist, waere ein Industrie-PC (oder zwei PCs mit seriellen Port als Reserve) angesagt. Raus war ich bei ersten Absatz: > Diese reagiert mit einer bekannten Quittung usw. Das Protokoll > ist bekannt. Zeige das Protokoll, dann haette man reden koennen.
dbstw ich kann nix daran ändern das da Ihnen was nicht klar ist. Es werde nun mal immer 10 Bytes plus ein byte checksumme an die uart der Steuerung gesendet. Punkt. Das erstes Byte ist der Bef.....
Walter L. schrieb: > Ein un. Byte umfasst den Zahlenbereich von 0 bis 255. > Wieso passt 155 nicht in ein Byte, hbrill? Schon mal was von einer ASCII bzw. ANSI Tabelle gehört ? Ein Chr$(155) ist NICHT die Zahl 155. Die 0 - 255 sind Indexe, wo das in der Tabelle steht. Ein Chr$(65) ergibt z.b. ein großes A . Die indexe 48 - 57 enthalten die Ziffern 0 - 9. Stell dirs halt vor, wie ein Array mit 256 Zeichen, wobei die ersten 32 nicht druckbar sind. Und überlege mal : 1 Byte fürs Kommando und 1 Byte für die Checksumme. Da sind 9 von den 11 Bytes unnütz, würde also auch in einen 2-Byte-Rahmen passen. Aber ich lasse es lieber bei soviel Unkenntnis.
:
Bearbeitet durch User
Heinz B. schrieb: > Aber ich lasse es lieber bei soviel Unkenntnis. Das ist auch besser. Die Unkenntnis ist jedenfalls nicht auf der Seite des TO. Das ist die höflichste Umschreibung, die mir einfiel. Es ist für jeden, der auf diesem Gebiet arbeitet, auf den ersten Blick ersichtlich, daß es sich um ein binäres Protokoll handelt, das nichts mit ASCII-Zeichen zu tun hat. Dementsprechende Bemerkungen sind einfach nur überflüssig. Just my 2 cents
Rbx schrieb: > Möchtest du die Antwort als > a) geschätzter Forenteilnehmer > oder > b) Mitglied einer Kaste, die mir das Skyrimspielen auf Linux > vermiest/vermurkst? Warum so giftig? Du hattest den OpenWatcom-Compiler empfohlen und ich habe lediglich gefragt, welche Vorteile Du darin für den TO siehst. Du wirst ja schließlich Gründe dafür haben warum Du ein Werkzeug empfiehlst, das nicht einmal Code für aktuelle Prozessoren erzeugen kann, wenn ich Deine Aussage richtig gelesen und verstanden habe. Davon abgesehen will Dir vermutlich niemand das Spielen von Skyrim vermiesen oder vermurksen, ich jedenfalls habe nicht diese Absicht. Ich halte es nur für wenig zielführend, daß Du den Zustand und die Qualität von Linux immer wieder ausgerechnet anhand eines Spiels beurteilen möchtest, das für ein vollkommen anderes Betriebssystem entwickelt worden ist.
Danke kseege. Also hier noch einmal: ich habe aus 2013 einen cp210x angeschlossen. Im Gerätemanager taucht com5 auf. Soweit ich das hier verstanden habe, ist so eine Anwendung mit Visual Studio 2022 in C++ oder C# oder VB in 30 Minuten programmiert, eine Konsolenanwendung in 10 Minuten. Mir würde zunächst schon eine Konsolenanwendung reichen (um da reinzukommen) die 11 Bytes unterbrechungsfrei sendet und danach sofort 1 bis 16 Byte empfängt. MODE COMx:9600,N,8,1. Keine handshake leitungen. Danke für ein Beispiel. VG Walter
Ich hatte mal vor etlichen Jahren was ähnliches für eine 8fach Relaiskarte vom großen C in (X)Profan gemacht. Da brauchte ich einen 4-Byte Rahmen. Ist jetzt allerdings in einem BASIC - Dialekt. Hier mal das wesentliche. Evtl. kannst du ja das relevante rauslesen und analog für C umsetzen. Ich denke mal, daß das bei deiner Hardware recht ähnlich funktioniert.
1 | Proc GetComInput |
2 | Parameters id% |
3 | Declare in$ |
4 | in$ = ReadCom$(f%,8) ' 8 Zeichen einlesen |
5 | Case Len(in$):SetText statusbar%, "Antwort : " + Str$(ord(in$)) |
6 | EndProc |
7 | |
8 | Proc Senden |
9 | ' 4 Byte - Rahmen zum Senden erstellen |
10 | Pruefsumme% = XOR(XOR(kommando%, adresse%), daten%) |
11 | send$ = Chr$(kommando%) + Chr$(adresse%) + Chr$(daten%) + Chr$(Pruefsumme%) |
12 | WriteCom(f%, send$) |
13 | ComError(f%) |
14 | GetComInput(f%) |
15 | Sleep 1000 |
16 | EndProc |
Da du ja schon ein anderes Konsolenprogramm gemacht hast, dürfte es dir ja nicht schwer fallen. Die Schnittstellennr. + Einstellungen kannst du ja vorerst fest lassen. Ansonsten brauchst du ja nur eine Schleife, in der das Kommando entgegen genommen, in den Rahmen gesetzt und gesendet wird. Die Bytes 1 - 9 scheinen ja leer bzw. 0 zu bleiben, sodaß als 10. Byte ja nur der Wert des Kommandos übergeben wird. Die leeren Bytes würde ich als Chr$(48) belegen, sodaß bei einem Kommando 155 der zu sendende String send$ wie folgt zu belegen ist :
1 | send$ = Chr$(kommando) + Chr$(48) + Chr$(48) + Chr$(48) +Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(kommando) |
Das mußt du halt selber ausprobieren. Oder reicht statt Chr$(48) ein Chr$(0) ? Das ist jedenfalls mein Wissen, das ich hiermit mit dir teilen kann.
Sheeva P. schrieb: > Ich halte es nur für wenig zielführend, daß Du den Zustand und die > Qualität von Linux immer wieder ausgerechnet anhand eines Spiels > beurteilen möchtest, das für ein vollkommen anderes Betriebssystem > entwickelt worden ist. Die Motoren von Mercedes sind auch ganz schlecht, weil keiner davon in meinen Berlingo passt.
Frag mal im Freepascal Forum, da bastelt dir das sicher jemand kostenlos, als Programmierübung oder versuch es selbst mit lazarus / freepascalhttps://www.lazarus-ide.org/
Walter L. schrieb: > Mir würde zunächst schon eine Konsolenanwendung reichen (um da > reinzukommen) > die > 11 Bytes > unterbrechungsfrei sendet und danach sofort > 1 bis 16 Byte empfängt. > MODE COMx:9600,N,8,1. Aus meiner (natürlich unmaßgeblichen) Sicht ist das Eingeben und Absenden tatsächlich in 10 Minuten zu machen, wenn man seinen Compiler in- und auswendig kennt und nirgendwo etwas nachschlagen muß. Für mich würde ich in TCL 20 Minuten und in C das Dreifache veranschlagen. Das eigentliche Problem liegt aus meiner Sicht im Empfang der Antwort. Woher weiß das Programm, daß die Antwort vollständig ist? Dazu hast Du noch nichts angegeben. Die logische Folge wäre, daß man das mit einem Timeout realisiert. Dann muß man die Antworten scannen, ungültige aussortieren und die gültigen verarbeiten. Das kann leicht mal 2 Tage dauern, je nach Kompexität der Antworten. Die fertige Konsolenanwendung kann ich nicht liefern, weil der letzte Microsoft-C-Compiler, den ich benutzt habe, die Version 3.0 von ca.1984 ist, die noch älter als Turbo-C ist. Außerdem ist microcontroller.net ein Forum zur Unterstützung der Selbsthilfe, kein Lieferant kostenloser Software. Wie wäre es, wenn Du einfach anfängst und den Code so einfach wie möglich hältst, damit er leicht verstanden werden kann und den dann hier vorstellst und nach Verbesserungen fragst? Da Du in C programmieren kannst und die "basics" des UART-Transfers offensichtlich gut verstanden hast, solltest Du das bequem wuppen können, auch ohne Vorgabe (die einen auch ganz leicht in unnötige Komplexität führen kann). Aus meiner Sicht ist z.B. die Lösung, 148 Buttons für 148 Befehle zu realisieren, einfach lebensfremd. Ein Eingabefeld, in das man den Befehl dezimal eintippt und nach dem "Enter" abschickt, erscheint mir erheblich einfacher zu sein. Aber das ist Geschmackssache. Gruß Klaus (der soundsovielte)
Heinz B. schrieb: > Das mußt du halt selber ausprobieren. Oder reicht statt Chr$(48) ein > Chr$(0) ? Ratespielchen mit Halbwissen. Warum soll man sich sowas antun? Und dann noch die falsche Checksum in > send$ = Chr$(kommando) + Chr$(48) + Chr$(48) + Chr$(48) +Chr$(48) + > Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(kommando) Warum führst Du den TO auf falsch Fährten? Dummheit oder Absicht? Just my 2 cents
Steve van de Grens schrieb: > Sheeva P. schrieb: >> Ich halte es nur für wenig zielführend, daß Du den Zustand und die >> Qualität von Linux immer wieder ausgerechnet anhand eines Spiels >> beurteilen möchtest, das für ein vollkommen anderes Betriebssystem >> entwickelt worden ist. > > Die Motoren von Mercedes sind auch ganz schlecht, weil keiner davon in > meinen Berlingo passt. Im Fall von Rbx ist es ja eher so, daß der Berlingo schlecht ist, weil die Motoren von Mercedes nicht hineinpassen... aber ich glaub, das ist nur ein marginales Detail Deines Gleichnisses.
Hier mal ein Beispiel wie man bequem Daten sendet und empfängt. Zu einer graphischen Oberfläche hatte ich ja weiter oben schon etwas geschrieben. Ich sehe das jetzt nicht als sooooo schwierig an.
1 | #!/usr/bin/python3
|
2 | # -*- coding: UTF-8 -*-
|
3 | # vim:fileencoding=UTF-8:ts=4
|
4 | |
5 | from serial import Serial, EIGHTBITS, PARITY_NONE, STOPBITS_ONE |
6 | |
7 | port = '/dev/ttyACM0' |
8 | speed = 9600 |
9 | timeout = 0.1 # in seconds |
10 | with Serial(port, speed, EIGHTBITS, PARITY_NONE, STOPBITS_ONE, timeout=timeout) as ser: |
11 | # prepare data_out
|
12 | data_out = bytearray(11) |
13 | data_out[0] = 13 # CR |
14 | data_out[1] = 10 # LF |
15 | data_out[2] = 4 # Ctrl-D |
16 | # checksum
|
17 | data_out[10] = sum(data_out[0:10]) % 256 |
18 | # send data
|
19 | ser.write(data_out) |
20 | # receive up to 16 bytes into data_in
|
21 | data_in = [] |
22 | for numbytes in range(16): |
23 | byte = ser.read() # receive ONE byte |
24 | if len(byte) == 0: # test timeout |
25 | break # break for loop prematurely |
26 | byte = byte[0] # uses the first byte only (of one byte received) |
27 | data_in.append(byte) # append to data_in array |
28 | print('>>>', data_in) |
29 | |
30 | # >>> [13, 10, 77, 80, 89, 58, 32, 115, 111, 102, 116, 32, 114, 101, 98, 111]
|
Ich habe ja keine Ahnung davon, aber bevor ich anfange haette ich gerne die Protokollbeschreibung (und nicht die Interpretation des TOs!). Wie erkennt die Maschine (der Empfaenger) den Anfang des Kommandos, wie ist Rueckmeldung aufgebaut. Wie sind die Parameter nach dem Kommando aufgebaut, wie wird die Pruefsumme erstellt (Nur ein Byte ist bei 10 Bytes nicht ausreichend, bei der Summe sind zwei Bytes noetig). Wenn der TO das nicht weiss: Vielleicht gibt es ja einen Hersteller und ein Typenschild, man koennte eine Suchmaschine benutzen um Informationen zu finden. Wenn man dann die Suchmaschine schon gestartet hat, koennte man mit den Suchbegriffen "Visual basic serial port example" bei Microsoft die Programmbeispiele finden. Dort kann man auch den Event-Handler fuer den Empfang (der noch nicht definiert ist) finden. Ich persoenlich finde "C# serial port example" schoener, aber vielleicht habe ich einfach genug Basic im Leben programmiert. Und man kann auch sehr einfach die GUI erstellen (Visual Studio ist schon nicht schlecht). Vielleicht koennte der TO auch mal zeigen, was er gemacht und probiert hat, denn man koennte dieses alte Bonmot herausholen (aus Beitrag "Re: Hilfe bei Z80 Opcodes"): > Und nein, dieses Forum ist zwar hilfreich, aber es ist kein > Cola-Automat, wo man auf den Knopf drückt und schon kommt der Pappbecher > mit dem fertigen Drink heraus. Etwas eigene Arbeit (auch > Einarbeitungsarbeit in den Z80) wäre vonnöten gewesen, schließlich ist > es DEINE Maschine, die jetzt doof herumsteht und nicht mehr benutzbar > ist. Viele Gruesse, schoenes WE
Hallo, ich danke für alle konstruktiven Beträge. Allen kann ich mom. nun nicht gezielt antworten. Zur Info.: Die Steuerung der CNC habe ich bis 1998 entwickelt. Jetzt war die CNC defekt (Maschinenteil) und ist wieder Rep. Das Prog. ist für den SERVICE gedacht gewesen... Es ist eine Privatangelegenheit... Mom. bin ich dabei den damalige RS232_Versuch mit VISUAL 6 zu finden... Ich melde mich, wenn ich da was zeigen kann. VG Walter
Klaus S. schrieb: > Ratespielchen mit Halbwissen. Warum soll man sich sowas antun? Und dann > noch die falsche Checksum in Mit solchem Halbwissen und Ratespielchen hatte ich damals erst die Platine in Win zum Laufen gebracht. Da war auch nur ein uraltes MS-DOS Programm und etwas QuickBasic-Quelltext dabei. Da der TO damals die Steuerung selbst entwickelte, wird es doch wohl für ihn ein Leichtes sein, die richtige Bytesequenz zu schicken. Die Antwort der CNC kann er ja einfach empfangen. So schnell kann der den nächsten Befehl gar nicht tippen, daß er dafür einen Timeout bräuchte. Daß er die CNC selber entwickelte wußten wir ja bis jetzt gar nicht. Warum läßt er uns dann ewig herumraten ? Zumindest ein kleines Konsoleprogramm wird er dann doch hin bekommen. Das Forum hier ist ja nicht da, um mundfertiges zu presentieren. Ein wenig Hand anlegen muß er da schon selber. Und wenn das läuft, kann er immer noch mit einer GUI anfangen. Wenn er dann unbedingt Buttons haben will, ist so ein GUI-Designer nicht gut geeignet. Da bekommt er für jeden Button eine Eventprozedur. Das wird dann ein Monster an Quellcode. Da ist es besser, die Buttons in einer Schleife zu erstellen und das jeweilige Handle in ein Array zu legen. In der Ereignisschleife wird dann in einer extra Schleife der Klick abgefragt. Natürlich muß die Sprache das auch unterstützen.
Heinz B. schrieb: > Und wenn das läuft, kann er immer noch mit einer GUI anfangen. > Wenn er dann unbedingt Buttons haben will, ist so ein GUI-Designer > nicht gut geeignet. Da bekommt er für jeden Button eine Eventprozedur. > Das wird dann ein Monster an Quellcode. Ich weiß ja nicht womit du arbeitest, aber hier bei mir können Hunderte von Buttons präzise einen Event auslösen und ihren Index übergeben. Das wird dann ein Winzling an Quellcode.
Heinz B. schrieb: > Das Forum hier ist ja nicht da, um mundfertiges zu presentieren. Wirklich nicht? Na sowas aber auch!
Angehängte Dateien:
-
MultiButtons.png
7,7 KB
Norbert schrieb: > Ich weiß ja nicht womit du arbeitest, aber hier bei mir können Hunderte > von Buttons präzise einen Event auslösen und ihren Index übergeben. Das > wird dann ein Winzling an Quellcode. Ich dachte, das wäre bei VB so. Sorry. Bei mir macht das auch nur 36 Zeilen Quellcode incl. Auslesen des Handle und des Textes und Anzeigen in der Statusbar.
:
Bearbeitet durch User
Heinz B. schrieb: > Mit solchem Halbwissen und Ratespielchen hatte ich damals erst die > Platine > in Win zum Laufen gebracht. Da war auch nur ein uraltes MS-DOS Programm > und etwas QuickBasic-Quelltext dabei. Das ist das Positive an Dir, Du kannst mit Fummeln und Ausprobieren was zum Funktionieren bringen. Heinz B. schrieb: > Die > Antwort der CNC kann er ja einfach empfangen. So schnell kann der > den nächsten Befehl gar nicht tippen, daß er dafür einen Timeout > bräuchte. Das ist das Negative an Dir. Du behauptest im Brustton der Überzeugung Dinge, die nach meinem Wissen grottenfalsch sind. Eine Antwort kann vom Programm nur dann als vollständig erkannt werden, wenn entweder 1.) die Länge der Antwort vorher bekannt ist 2.) ein Endezeichen vereinbart ist 3.) eine Zeitüberschreitung erkannt wird Da 1.) und 2.) nicht erfüllt sind, bleibt nur 3.). Egal ob über einen automatischen Timeout in der Funktion oder durch permanentes Polling der Länge und Erkennen der ausbleibenden Änderung. Gruß Klaus (der soundsovielte)
Verehrte Community, das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11 Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück). Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die Kithara Real Time Suite ein, um das Problem zu lösen. Da mir die Kithara Real Time Suite nicht zur Verfügung steht werde ich einen kleinen Controller nehmen, der dieses kleine aber entscheidenden Schlagloch ausbügelt. Bei gegebener Zeit berichte ich gerne über die Lösung. VG Walter
Das Problem wird wohl mit einem USB Serial/CDC Adapter nicht auftreten, weil da immer bis zu 64 Bytes im Block übertragen werden. Deine 11 Bytes passen da rein. Windows hat keinen Grund, die 11 Bytes zu splitten, solange dein Programm sie auch in einem Stück sendet, gefolgt von einem flush oder Warten auf Antwort.
:
Bearbeitet durch User
Klaus S. schrieb: > Das ist das Negative an Dir. Du behauptest im Brustton der Überzeugung > Dinge, die nach meinem Wissen grottenfalsch sind. Eine Antwort kann vom > Programm nur dann als vollständig erkannt werden, wenn entweder > 1.) die Länge der Antwort vorher bekannt ist > 2.) ein Endezeichen vereinbart ist > 3.) eine Zeitüberschreitung erkannt wird Das sind ja Grundlagen, die man vorraussetzt. Das ist auch bei jeder Doku der RS232 im Netz dabei. zu 1. Klar, die Längen der Antworten können immer variieren, deswegen auch der Puffer. Natürlich muß der Empfangspuffer groß genug sein. Die 1024 Bytes genügen im allgemeinen. Solche Hardware gibt ja sicherlich keine Romane zurück. Normalerweise weiß man in etwa die Höchstlänge. Demnach richtet man sich den Puffer ein und liest ihn auch ganz aus. Danach kann man den sogar mit der API PurgeCom löschen, damit keine Restdaten zurück bleiben. zu 2. Da der TO die Hardware und somit die Software darauf selber gebaut hat, weiß er auch das Endezeichen, das die Hardware zurück gibt. zu 3. hatte ich noch bei keiner Hardware. Im Gegenteil : Wenn man ca. 200 - 300 ms nach dem Senden mit dem Lesen wartet ist das ok. Das Timeout wird dann relevant, wenn periodisch und automatisch in ganz kurzen Abständen gesendet wird. Aber da würde ich lieber die Handshake-Leitungen in Betracht ziehen.
Stephan S. schrieb: > Walter L. schrieb: >> 0 1 2 3 4 5 6 7 8 9 10 >> >> 3 0 0 0 0 0 0 0 0 0 3 > > Das sind mit ENTER in der Windows-Welt aber 12 (zwölf) Bytes und nicht > 11. In Windows wird ENTER mit CR LF übergeben, also 0xD 0xA Das ist offensichtlich ein binäres Protokoll, kein Textprotokoll. Dementsprechend spielen irgendwelche Zeilenende-Zeichen keinerlei Rolle. Es gibt keinerlei Zeilen.
Heinz B. schrieb: > zu 3. hatte ich noch bei keiner Hardware. Im Gegenteil : Wenn man > ca. 200 - 300 ms nach dem Senden mit dem Lesen wartet ist das ok. > Das Timeout wird dann relevant, wenn periodisch und automatisch > in ganz kurzen Abständen gesendet wird. Aber da würde ich lieber > die Handshake-Leitungen in Betracht ziehen. Dann ist das ein Streit um des Kaisers Bart. Für mich ist "300 ms warten" ein Timeout und die Handshake-Leitung eine vereinbarte Endekennung. Damit sind wir uns wohl in der Sache, aber nicht in der Benamsung einig. Mir geht es einfach nur darum, daß spätere Leser nicht auf falsche Fährten gesetzt werden. Gruß Klaus (der soundsovielte)
Walter L. schrieb: > das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11 > Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück). Das passiert, wenn man wirklich Zeichen für Zeichen sendet. Da kann schonmal ein Taskwechsel dazwischen hauen und die Sache für 10ms oder mehr unterbrechen. So ist das nunmal bei Multitasking-Systemen. Sowas konnte aber sogar unter DOS passieren, obwohl das kein MT-System ist. TSR-Programme (AKA: "Hintergrundprogramme") machten es möglich. Die ergeben (zusammen mit dem eigentlichen Programm) auch so eine Art Multitasking-System. Funktioniert im Prinzip genauso, wie Programme auf kleinen µC, die Interrupts nutzen. Aber die Lösung ist natürlich einfach und logisch: Man schreibt eben nicht jedes Zeichen einzeln, sondern übergibt einen 11 Byte großen Buffer zum Schreiben an den Gerätetreiber. Das nennt sich asynchrones IO. Damit alleine ist zwar, genau genommen, die Unterbrechungsfreiheit immer noch nicht sicher gestellt, aber hier hilft die geringe Größe der Nachricht. Die ist so klein, dass sie garantiert sowohl in den Hardwarepuffer eines echten COM-Ports passt (jedenfalls, wenn man es nicht gerade mit einem ziemlich historischen Rechner mit 8250-UART zu tun hat) als auch in den Sendebuffer des Hosts für ein USB-CDC-Device. > Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die > Kithara Real Time Suite ein, um das Problem zu lösen. Die hatten entweder keine Ahnung oder sie wollten es besonders gut und "zukunftssicher" machen. Nötig ist das hier nicht. Unter der günstigen Randbedingung der geringen Nachrichtengröße kann man das allein mit dem Win32-COMM-Api völlig problemlos umzusetzen. Benutzt man den SerialPort des .net-Frameworks, wird es noch einfacher. Das benutzt nämlich von Hause aus asynchrones IO. Sprich: hier brauchst du bloß ein 11 Byte großes Array erzeugen, mit dem gewünschten Inhalt zu füllen und dann die Write-Methode des SerialPorts (in der Überschreibung für ein Byte-Array) aufrufen und der Drops ist gelutscht.
Der TO wird wohl eher Probleme mit dem Stringende-Zeichen bekommen, wenn das was als Windowsprogramm werden soll. Das hatte ich vor Jahren mit meinem selbst programmierten AVR auch. Da bin ich fast verzweifelt. An den String, den ich mit dem AVR senden wollte, ein Chr$(0) in BASCOM drangehängt, und schon ging es. Ich muß auch dazu sagen, daß meine Programmier- sprache für Windows nur Strings über die RS232 senden und empfangen konnte. Ich denke mal nicht, daß der TO damals (1998) daran gedacht hatte, zumal das damals über ein DOS-Programm betrieben wurde. Da muß er schauen, ob seine Sprache auch Speicherbereiche senden und empfangen kann. So ein Speicherbereich läßt sich ja einfach in einen String mit Nullbyte am Ende konvertieren. Da er die Hardware ja selber baute, könnte er sie ja auch softwaremäßig updaten. Das ginge dann auch.
:
Bearbeitet durch User
Wenn mich eines an diesem Forum fasziniert, dann sind es die ›Annahmen‹ die sich einige ausdenken um ein gegebenes Problem in ihre eigene spezielle Gedankenwelt zu transponieren.
Walter L. schrieb: > das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11 > Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück). Das klingt nach Humbug. Auch 2003 konnte man unter Windows über eine serielle Schnittstelle elf Bytes so ausgeben, daß sie ohne Unterbrechung ausgegeben wurde. Ohne große Klimmzüge, einfach durch Nutzung der Win32-API. > Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die > Kithara Real Time Suite ein, um das Problem zu lösen. Kann man natürlich machen, um seine elementare Unfähigkeit in der Nutzung der Win32-API zuzudecken, und es klingt sehr, sehr beeindruckend. "Real Time". Klar. Braucht man für elf Bytes. Bei 9600 Baud. O weh.
Heinz B. schrieb: > Der TO wird wohl eher Probleme mit dem Stringende-Zeichen > bekommen, wenn das was als Windowsprogramm werden soll. Windows interessiert sich nicht dafür, was das für Daten sind. Wäre auch fatal, wenn es so wäre, weil WriteFile() für deutlich mehr als nur serielle Kommunikation verwendet wird. Heinz B. schrieb: > Ich muß auch dazu sagen, daß meine Programmier- > sprache für Windows nur Strings über die RS232 senden und empfangen > konnte. Dann lag das Problem dort.
Walter L. schrieb: > 0 1 2 3 4 5 6 7 8 9 10 > > 3 0 0 0 0 0 0 0 0 0 3 > > alles dezimal. Es ist immer noch nicht klar, ob eine 3 eine '3' ist oder 0x03. Wird der Befehl 89 mit 0x59 binär codiert, mit '89' als ASCII, mit 0x08 0x09, mit '089' oder mit 0x00 0x08 0x09 (die Befehle gehen ja bis 151)? Da sollte der TE mal endlich Stellung nehmen.
Norbert schrieb: > Wenn mich eines an diesem Forum fasziniert, dann sind es die ›Annahmen‹ > die sich einige ausdenken um ein gegebenes Problem in ihre eigene > spezielle Gedankenwelt zu transponieren. Techniker sind eben nicht so phantasielos, wie man manchmal meinen möchte. Vielen Dank übrigens für das Python-Programm. Da ich gerade darin dilettiere, kam es mir wie gerufen. Gruß Klaus (der soundsovielte)
Dir L.S. schrieb: > ist immer noch nicht klar, ob eine 3 eine '3' ist oder 0x03. Schade für dich, allen anderen längst.
Hmmm schrieb: > Windows interessiert sich nicht dafür, was das für Daten sind. Wäre auch > fatal, wenn es so wäre, weil WriteFile() für deutlich mehr als nur > serielle Kommunikation verwendet wird. Und bei ReadFile() auch. Wenn ein Chr$(0) am Stringende da ist, liest es das mit, andernfalls eben nicht. Und das ist ja auch nicht das Thema. Das liegt eher an den 2 Welten (Controller-Welt vs. Windows-Welt). Weil nullterminierte Strings mittlerweile Standard sind, klappt das dann auch nicht, wenn der Mikrocontroller kein Chr$(0) dranhängt. Die Programmiersprache erkennt den String dann nicht. So einfach ist das. Dann geht es, wie oben schon erwähnt, nur über einen Speicherbereich.
:
Bearbeitet durch User
kirnbichler Wo ist der Nachweis. Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden, CP2102, COM5). VG Walter
Heinz B. schrieb: > Das liegt eher an den 2 Welten (Controller-Welt vs. Windows-Welt). Das ist bei Dir eher BASIC-Welt vs. richtige Welt. Windows will einen Pointer und die Anzahl zu sendender Bytes, der Inhalt ist völlig egal. Nur die Byte Order kann natürlich bei übertragenen Werten mit >8 Bit Ärger machen, wenn man sich darüber keine Gedanken macht, aber auch die ist dem Betriebssystem egal und betrifft nur Deine Anwendung. Heinz B. schrieb: > Weil nullterminierte > Strings mittlerweile Standard sind, klappt das dann auch nicht, wenn > der Mikrocontroller kein Chr$(0) dranhängt. Wenn Du mit einer Murks-Sprache arbeitest, die sowas erwartet, mag das stimmen. Üblich ist das jedenfalls nicht, selbst bei menschenlesbaren Protokollen hängt man vielleicht noch CR und/oder LF dran, aber eher kein 0x00. Intern kann man selbstverständlich mit nullterminierten Strings arbeiten, aber man sendet sie nicht mit.
Walter L. schrieb: > Wo ist der Nachweis. > Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier > einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden, > CP2102, COM5). Er will halt keine stinkenfaulen Hassler unterstützen. Genausowenig, wie ich das will oder jeder andere, der tatsächlich was vom Problem versteht. Du hast alles an Hilfe bekommen, was nötig ist, um selber ohne große Probleme eine Lösung zu implementieren. Sogar mit mehreren möglichen Ansätzen. Wenn du wenigstens grundlegend willig und fähig wärest, selber zu programmieren. Das ist aber offensichtlich nicht der Fall. Du willst dein konkretes Problem für lau von Anderen erledigen lassen. Also ein Scheiß-Parasit. Sowas mag echt niemand...
Walter L. schrieb: > kirnbichler > > Wo ist der Nachweis. > Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier > einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden, > CP2102, COM5). > > VG Walter Wo ist Dein Ansatz, Dein Versuch? Du kannst nicht erwarten, dass jemand fuer Dich arbeitet. Oder Muenzen einwerfen (dann aber das Protokoll und Lastenheft vorlegen). Hast Du denn die Beispiel von Microsoft mal ausprobiert und kannst berichten? Nein? Auch gut. P.S.: Warum hat diese Schoene Forum-Software keine Kill-File?
:
Bearbeitet durch User
Jetzt kommen von hinten durch die Brust ins Auge die Dollarzeichen in die Augen. Was kosten die 10 Minuten? Um von vornherein Klarheit bei diesen tollen Hechten zu schaffen: Es gilt in diesen Fälle die alte Kaufmenschregel, erst die Ware, dann das Geld... VG Walter
Walter L. schrieb: > Was kosten die 10 Minuten? 10 Minuten kosten 10 Minuten. Allerdings kenne ich so viele Menschen, denen ich lieber 10 Minuten meiner Zeit schenke als dir.
Hoffentlich verstößt das nicht gegen Forumsregeln.. Ich schlage vor: Gefliefert wird zunächst ein EXE-File. Eingebbar muss die COMSCHNITSTELLE sein. Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes, usw. VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102. Den EXE-file starte ich auf einem isolierten PC... Die Daten leite ich in einen Kontroller, der den lückenlosen Strom der 11 Bytes prüft. Schaun wir mal. VG Walter
Walter L. schrieb: > Heiße Luft Mehr bekommst du nach diesem Auftritt hier auch nicht mehr. Walter L. schrieb: > Pause 10mSek +-1mSek, Ah, eine neue Scheibe der Salami.
Walter L. schrieb: > Pause 10mSek +-1mSek Darauf würde ich mich insbesondere über USB nicht verlassen. Walter L. schrieb: > VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102. Kein VS und in C. Walter L. schrieb: > Den EXE-file starte ich auf einem isolierten PC... COM-Port als Parameter, z.B. "comtest COM5". Viel Spass!
Hmmm schrieb: > Walter L. schrieb: >> Pause 10mSek +-1mSek > > Darauf würde ich mich insbesondere über USB nicht verlassen. > > Walter L. schrieb: >> VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102. > > Kein VS und in C. > > Walter L. schrieb: >> Den EXE-file starte ich auf einem isolierten PC... > > COM-Port als Parameter, z.B. "comtest COM5". Viel Spass! Ich würde mal davon ausgehen, dass das nicht wirklich den Intentionen dieses Hasslers entspricht ;o) Der hat ganz sicher viel von dem unerwähnt gelassen, was er eigentlich will. Das erste Anzeichen dafür war natürlich, dass er das (ihm offensichtlich bekannten) Protokoll nicht offengelegt hat. Es ist davon auszugehen, dass in diesem 11Byte-Paket eine Prüfsumme steckt, die mehr als ein Byte umfasst. Und es ist davon auszugehen, dass die vielen Nullbytes längst nicht bei jedem Kommando Null sein werden, sondern Parameter des Kommandos sind. Dieser Typ ist einfach nur ein Nassauer. Aber sogar als solcher: dramatisch inkompetent. Der wird nix mehr, nichtmal Manager...
Hmmm schrieb: > Das ist bei Dir eher BASIC-Welt vs. richtige Welt. Windows will einen > Pointer und die Anzahl zu sendender Bytes, der Inhalt ist völlig egal. Also ich hatte bis jetzt auf keinem Mikrocontroller ein MS-DOS oder Windows oder sonst was gefunden. Das einzig gemeinsame ist der ASCII (OEM) Zeichensatz und das war es. Und außerdem geht es hier nicht ums Senden sondern ums Empfangen. Wenn die Sprache halt nur Strings senden/empfangen kann, muß man halt mit der Windows-API und Speicherbereichen oder entspr. DLL arbeiten. Das habe ich ja jetzt schon öfter angedeutet. Und einen Speicherbereich bzw. Pointer darauf kannst du auch nicht einfach ausgeben. Die Zeichen darin muß man mal zuerst in eine Stringvariable kopieren. Und dann bist du wieder dort, wo du warst. Da ist es egal, ob BASIC, C oder sonstige Sprache. Das funktioniert überall gleich. Ich gebe hier mal ein Stichwort aus den Anfangsjahren von Windows : DELPHI + DLL erstellen + Strings (PascalString vs. TCHAR)
Heinz B. schrieb: > Wenn die Sprache halt nur Strings senden/empfangen kann dann ist entweder der Horizont seines Anwenders zu beschränkt oder die Programmiersprache für den Anwendungszweck völlig ungeeignet. Ich vermute ersteres.
Schaut mal z.b. hier : https://www.c-howto.de/tutorial/strings-zeichenketten/nullterminiert/ Vielleicht fällt bei euch dann der Groschen. Oder nehmt mal die renomierte Sprache DELPHI. Dort ist es besonders krass. Warum halten die sich nicht einfach nur an Standards ? Man könnte jetzt in dem Zusammenhang noch mehrere Sachen nennen, z.b. UTF8 bzw. UNICODE, wo eine ähnliche Problematik besteht. Das ist zwar heute standardisiert, war es aber nicht seit Anfang an. Aber dafür seit ihr wahrscheinlich zu jung und habt es erst gar nicht mitbekommen. Und dafür ist euer Horizont wiederrum zu beschränkt, weil ihr einfach gar nicht wißt, was unter der Haube geschieht. Damit ist das Thema für mich erledigt.
:
Bearbeitet durch User
Heinz B. schrieb: > Vielleicht fällt bei euch dann der Groschen. Du bellst den komplett falschen Baum an. Es geht überhaupt nicht um Strings, es geht nur um elf dämliche Bytes. Tatsächlich aber geht es um etwas noch ganz anderes, was der tolle Threadstarter als Salamischeibe gerade vorhin erst rausgerückt hat: Walter L. schrieb: > Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes, usw. Nämlich daß hier eine Sendepause von 10 +/- 1 msec gefordert wird. Die kann zwar ein Windows selbst durchaus hinbekommen (wenn man weiß, wie man die Timergranularität verändert), aber die sind mit einem USB-Seriell-Adapter aufgrund der Funktionsweise von USB durchaus eine Herausforderung.
Heinz B. schrieb: > Und dafür ist euer Horizont wiederrum zu beschränkt, weil ihr > einfach gar nicht wißt, was unter der Haube geschieht. Schreibt einer, der offensichtlich zu blöd dafür ist, 11 beliebige Bytes über eine serielle Schnittstelle zu schicken. Kannst du dir nicht ausdenken sowas... Heinz B. schrieb: > Damit ist das Thema für mich erledigt. Das ist eine gute Nachricht.
Harald K. schrieb: > Die kann zwar ein Windows selbst durchaus hinbekommen (wenn man weiß, > wie man die Timergranularität verändert), aber die sind mit einem > USB-Seriell-Adapter aufgrund der Funktionsweise von USB durchaus eine > Herausforderung. Ein weiteres Problem ist der FIFO. Zwischen WriteFile() und "letztes Stopbit gesendet" vergeht also viel Zeit, die kaum exakt bestimmbar ist. Im Fall von RS485 habe ich das seinerzeit gelöst, indem ich das eigene Echo gelesen (und das Timing nicht zu eng gemacht) habe, aber das scheidet hier ja aus. Allerdings passt die komische 10ms-Anforderung auch nicht zur früheren Aussage, dass eine Antwort vom Gerät kommen soll.
Hmmm schrieb: > Wenn Du mit einer Murks-Sprache arbeitest, die sowas erwartet ... Ich kann mir kaum vorstellen, dass sein Basic Dialekt keine Byte-Arrays unterstützt. > Intern kann man selbstverständlich mit nullterminierten Strings > arbeiten Was in Basic allerdings ungewöhnlich wäre, denn da haben Zeichenketten das normalerweise nicht. Stattdessen haben sie eine Längen-Angabe.
:
Bearbeitet durch User
Beitrag #7655711 wurde vom Autor gelöscht.
Heinz B. schrieb: > Und einen Speicherbereich bzw. Pointer darauf kannst du auch nicht > einfach ausgeben. Die Zeichen darin muß man mal zuerst in eine > Stringvariable kopieren. Und dann bist du wieder dort, wo du warst. > Da ist es egal, ob BASIC, C oder sonstige Sprache. Das funktioniert > überall gleich. Nein, das funktioniert eben nicht in jeder Sprache gleich. Wie bereits korrekt angemerkt wurde, erwartet die Windows API (ebenso wie Linux) einen Zeiger auf die Bytes und eine Längenangabe. Das betrifft letztendlich alle mir bekannten Programmiersprachen. Wer auch immer etwas andere als eine Anzahl von byte senden will, benutzt (eventuell unbewusst) Hilfsfunktionen, die darauf aufbauen. Visual Basic kann nicht nur Strings senden, sondern auch eine Anzahl von Bytes. > Public Sub Write (buffer As Byte(), offset As Integer, count As Integer)
Klaus schrieb: > Schreibt einer, der offensichtlich zu blöd dafür ist, 11 beliebige Bytes > über eine serielle Schnittstelle zu schicken. Darum geht es ja gar nicht. Dann halt nochmal : Ob die Sprache nur Strings schicken kann, ist doch egal. In einen String bekommt man auch pro Stelle ein Byte unter. Unter der Haube schreibt sie auch mit der WriteFile - API. Ob ich nun selber einen Speicherbereich allociere oder die Sprache macht das vorm Senden intern. Die nimmt einfach den String entgegen, ermittelt die Länge des Strings, allociert entsprechend Speicher, schreibt den Stringinhalt rein und schickt mit WriteFile an die Schnittstelle. Im Grunde genommen ist es für den Nutzer eine Vereinfachung, da er nicht noch zuerst Speicher allocieren und füllen muß, sondern den String sofort mit der Funktion der Sprache wegschicken kann. Das hintere Nullbyte vom String interessiert da gar nicht. Und genauso geht es auch anders rum. Die kochen alle nur mit Wasser und erfinden nicht jedes mal das Rad neu.
Beitrag #7655719 wurde vom Autor gelöscht.
Heinz B. schrieb: > Ob die Sprache nur Strings schicken kann, ist doch egal. In einen > String bekommt man auch pro Stelle ein Byte unter. Ja, aber die Null Bytes mitten drin sind beim Null-Terminierten Strings problematisch, eben weil sie bei einigen Programmiersprachen das Ende des Strings kennzeichnen. Man nimmt hier bitteschön Byte-Arrays. Das geht auch in Basic.
Heinz B. schrieb: > Dann halt nochmal : Wie oft willst du noch bestätigen, dass du keine Ahnung hast?
Hmmm schrieb: > Ein weiteres Problem ist der FIFO. Zwischen WriteFile() und "letztes > Stopbit gesendet" vergeht also viel Zeit, die kaum exakt bestimmbar ist. Fifos lassen sich abschalten. Auch bei USB-Seriell-Bridges. Ausreichend präzise funktionierende Timer vorausgesetzt, könnte man auch bei Beginn der Übertragung einen solchen Timer aufziehen, der nach x Bytezeiten auslöst. Wie lang eine Bytezeit ist, sollte man ausrechnen können ... > Im Fall von RS485 habe ich das seinerzeit gelöst, indem ich das eigene > Echo gelesen (und das Timing nicht zu eng gemacht) habe, aber das > scheidet hier ja aus. Das ist ja nun völlig überflüssig, seitdem es UARTs mit Hardwareunterstützung für RS485 gibt - und jede etwas bessere USB-UART-Bridge hat die, so z.B. FTDI. Da muss man sich nicht selbst um die Sender-/Empfänger-Umschaltung kümmern. Und wenn man (in der vorderen Altsteinzeit) mit 8250/16450 gearbeitet hat, musste man halt auf die Kombination von THRE und TEMT im LSR warten.
Harald K. schrieb: > Ausreichend präzise funktionierende Timer vorausgesetzt, könnte man auch > bei Beginn der Übertragung einen solchen Timer aufziehen, der nach x > Bytezeiten auslöst. Klar, kann man alles tun, aber für +-1ms würde ich unter Windows mit USB-Seriell-Adapter nicht meine Hand ins Feuer legen wollen. Das wäre eher etwas für einen externen Controller. Harald K. schrieb: > Das ist ja nun völlig überflüssig, seitdem es UARTs mit > Hardwareunterstützung für RS485 gibt - und jede etwas bessere > USB-UART-Bridge hat die, so z.B. FTDI. Deshalb schrieb ich "seinerzeit", das ist über 20 Jahre her. Heute würde ich mir das dank FT232 nicht mehr antun. Harald K. schrieb: > Und wenn man (in der vorderen Altsteinzeit) mit 8250/16450 gearbeitet > hat, musste man halt auf die Kombination von THRE und TEMT im LSR > warten. War im Mittelalter, daher 16C550A unter Windows NT. Die Echo-Methode funktionierte tadellos.
Hmmm schrieb: > War im Mittelalter, daher 16C550A unter Windows NT. Die Echo-Methode > funktionierte tadellos. Der aber hatte die gleichen Register, und das Fifo ließ sich abschalten. Allerdings - das ging natürlich nur auf Devicetreiberebene, die Win32-API hat dir da wenig Möglichkeiten gegeben. Und mit dem DDK zu hantieren, war immer schon eine Art des Masochismus, keine Frage.
@Hmmm comtest.exe fkt nicht. Getestet auf einem LABTOP mit XP. Sicher liegt es an XP, da ist jetzt eine völlig andere CPU drin. Die Platte habe ich neu formatiert. Was halten die tollen Hechte von public class SerialPort : System.ComponentModel.Component und public void Write (char[] buffer, int offset, int count); Und das P... nicht vergessen.
Walter L. schrieb: > comtest.exe fkt nicht. Bitte etwas präziser. Walter L. schrieb: > Getestet auf einem LABTOP mit XP. Sicher liegt es > an XP, da ist jetzt eine völlig andere CPU drin. Das sollte theoretisch sogar unter Windows 98 laufen. Walter L. schrieb: > Was halten die tollen Hechte von Da bekommt man so richtig Lust, Dir zu helfen.
@Hmmm Wo nix erscheint, kann man auch nix präzisieren, sonst hätte... Ich erwarte hier kein Hilfe mehr. Schon gemerkt?
Walter L. schrieb: > Wo nix erscheint, kann man auch nix präzisieren, sonst hätte... Nicht vom Command Prompt gestartet? Das ist eine Consolenanwendung, schon vergessen? Lässt sich hier übrigens problemlos in einer XP-VM starten. Walter L. schrieb: > Ich erwarte hier kein Hilfe mehr. > Schon gemerkt? Du willst nur noch trollen?
:
Bearbeitet durch User
Hmmm schrieb: > Walter L. schrieb: >> Pause 10mSek +-1mSek > > Darauf würde ich mich insbesondere über USB nicht verlassen. > Mit dem CP2102 unter Win11 macht dein Progrämmchen bei mir ca. 4.2ms Pausen zwischen den Paketen.
:
Bearbeitet durch User
Klaus schrieb: > Mit dem CP2102 unter Win11 macht dein Progrämmchen bei mir ca. 4.2ms > Pausen zwischen den Paketen. Ich sende die Pakete stumpf mit 10ms Delay zwischen den WriteFile()-Calls, der Abstand könnte also je nach Chip und Treiber erheblich abweichen. Bei einem Onboard-16550 gibt es vermutlich gar keinen Abstand, weil das erste Paket direkt im FIFO landet und das zweite vor den knapp 11.5ms, die die Übertragung braucht, nachgeschoben wird.
:
Bearbeitet durch User
Hmmm schrieb: > Ich sende die Pakete stumpf mit 10ms Delay zwischen den > WriteFile()-Calls, der Abstand könnte also je nach Chip und Treiber > erheblich abweichen. Naja, da elf Bytes bei 9600,8n1 auf der Leitung etwa 11.5 msec brauchen, geht da beim Timing offenbar was schief. Hast Du Dich denn um die Timergranularität gekümmert? Die beträgt unter heutigem Windows 10 msec, d.h. ist deutlich zu grob, um Wartezeiten von 10 msec irgendwie zuverlässig hinzubekommen. Man kann die Timergranularität aus Usermode-Programmen verändern, das geht mit den "Multimedia"-Timerfunktionen. Ein Aufruf von timeBeginPeriod genügt. https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod Damit lässt sich die Timergranularität auf 1 msec verringern.
Harald K. schrieb: > Hast Du Dich denn um die Timergranularität gekümmert? Nein, mir war seine neue Anforderung mit den exakten Delays schlichtweg egal, weil sie nicht zur angeblichen Anwendung (11 Bytes ohne Unterbrechungen senden, dann kommt erstmal eine Antwort) passt. Harald K. schrieb: > Die beträgt unter heutigem Windows 10 msec Ungenaues Windows-Timing wäre eine Möglichkeit. Ein weiterer Punkt ist, wie lange WriteFile() blockt.
Walter L. schrieb: > und danach sofort > 1 bis 16 Byte empfängt. > Danach Pause von 1 Sek oder länger. Walter L. schrieb: > Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes Ja, ja. Bis zu 16 Bytes empfangen in max 10+1ms über 9600baud. Wie lange soll dieser Schwachsinn hier noch weiter gehen?
Hmmm schrieb: > Ein weiterer Punkt ist, > wie lange WriteFile() blockt. Muss es gar nicht, es gibt schließlich Overlapped-IO.
Harald K. schrieb: > es gibt schließlich Overlapped-IO. Und das puffert dann beliebig viele Daten, bevor die schließlich auf der Schnittstelle landen?
Klaus schrieb: >> es gibt schließlich Overlapped-IO. > > Und das puffert dann beliebig viele Daten, bevor die schließlich auf der > Schnittstelle landen? Das verwendet den Buffer, den du der Funktion übergiebst. Du darfst den Buffer erst wieder anfassen, wenn alle Daten geschrieben worden sind. Overlapped-IO ist hier völlig unnötig. Aber lass den Thread doch endlich sterben, der TE erfindet seine Probleme, der hat seinen Spass daran wenn alle hier hüpfen.
LOL was für ein Thread. Die serielle Schnittstelle, 2024, für manche immer noch Voodootechnik.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.