![]() |
V24 (RS232) Problem beim Übergang von Windows 9x auf Window
Kommunikation über die V24 (RS232)
Problem beim Übergang von Windows 9x auf Windows XP Applikation: Ein mit Delphi kodiertes Programm unterhält eine Kommunikation mit einer externen Elektronik. Die einzelne Messagelänge (Blocklänge) beträgt 71 Byte. Die Länge der Antwort beträgt 2 Byte. Es werden 873 Blöcke übertragen. Protokolldaten: 57600,8,n,1, kein Hardwarehandshake Die serielle Kommuniation läuft in einem Tread. Die Hauptapplikation führt währenddessen keine weiteren Funktionen aus. Die Übertragungszeit eines Blockes beträgt ca. 13 mS (theoretisch und messtechnisch überprüft) Die Verarbeitungszeit im externen µC beträgt ca. 20 mS (messtechnisch überprüft) Dh. vom ersten Bit aus der seriellen Schnittstelle TX, bis zur Messung des letzten Bits der 2 Byte - Antwort RX vergehen ca. 33 mS. Die Übertragung ist nach 38 - 40 Sekunden abgeschlossen. Die resultierende Verarbeitung im Pc ergibt sich zu 13 - 15 mS. Soweit so gut. Diese Ergebnisse konnte ich auf sieben PC's unter einem Betriebssystem W9x testen. Die PC's hatten Taktraten von 300 MHz bis zu 2400 MHz. Die Verarbeitungsgeschwindigkeiten blieben identisch. Problem: Die Applikation läuft auf Rechnern mit den Betriebssystemen W2k und WXP absolut langsam (vier Testrechner). Bei einer Priorität tpnormal ist die Übertragung nach ca 250 Sekunden abgeschlossen. Die resultierende Verarbeitung im Pc ergibt sich zu ca 267 mS. Bei einer Priorität tphighest ist die Übertragung nach ca 300 Sekunden abgeschlossen. Die resultierende Verarbeitung im Pc ergibt sich zu ca 320 mS. Bei einer Priorität tpidle ist die Übertragung nach ca 100 Sekunden abgeschlossen. Die resultierende Verarbeitung im Pc ergibt sich zu ca 87 mS. Da ich auch Datenmengen > 500k übertragen muß, stehe ich bei Anwendung unter W2k oder WXP vor einem großen Problem. Fragen an die Gemeinschaft: Wieso tritt bei den Betriebssystemen ein so großer Zeitunterschied auf? Wieso dauert die Übertragung länger wenn die Priorität höher gesetzt wurde? (Ich habe alle Stufen probiert -> Je höher desto langsamer) :wall: Wie kann ich die Übertragung beschleunigen? p.s. Das Prog. wurde unter Delphi 2.0dev und 6.0 getestet. Ergebnis identisch. MfG. Uwe |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hallo,
habe seleber mit diversen Tücken bei RS232 gekämpft, was kommt für die eigentliche Übertragung zum Einsatz ? Ich habe mal bei der Portierung einer fremden Software mit einem WIN internen Timer Probleme gehabt, es gab dann eine Lösung, der ich aber nicht weiter auf den Grund gegangen bin. Auszug : DLLHandle := LoadLibrary ('winmm.dll'); if DLLHandle <> 0 then begin timeBeginPeriod := GetProcAddress (DLLHandle, 'timeBeginPeriod'); timeEndPeriod := GetProcAddress (DLLHandle, 'timeEndPeriod'); end; |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Ich vermute mal, Du machst bei der seriellen Kommunikation was falsch. Ich habe selbst ein Programm unter Win9x bis Win2K ohne Probleme laufen.
Viele Grüße |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hi,
ich nutze eine RS232 - lib für Delphi 2.0 "comdrv32". Ich wäre sehr daran interessiert auch andere Lib's kennen zu lernen. Wenn Du gute Erfahrungen mit einer gemacht hast, wüßte ich schon gerne die Bezeichnung und die Quellenangabe. MfG. Uwe |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hi,
![]() gibts so wie es aussieht auch für D2, kann aber nicht viel dazu sagen, da ich die Version für D7 hab. Aber mMn die ameinfachsten zu handhabenden der ComPort-Komponenten. |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hmm...,
selbst geschrieben und nur mit den in meinem Programm notwendigen Funktionen ausgestattet. Kann ich momentan nicht sagen, ob es Dir was nützt. Viele Grüße |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hallo,
vielen Dank für die schnellen Antworten. @Daniel Ich habe mir die Daten gezogen und werde die Integration einmal umsetzen und testen. @yogie Danke für den Beitrag. Zum Einsatz kommt "comdrv32", aber ich probiere noch weitere, siehe oben (Vorschläge werden ernst genommen) @Delphianer Ich habe etliche Applikation die für Testumgebungen oder Steuerungsanwendungen die V24 nutzen unter W9x und WXP sauber laufen. Dies ist aber die erste Anwendung, bei der ich im Softwarehandshake größere Files übertragen muß. Eine fehlerhafte Bedienung der Kommunikation kann ja durchaus vorliegen, nobody is perfect, aber wie kann dies dazu führen, daß sich die Priorität negativ auf die Geschwindigkeit auswirkt => tptimecritical ist am langsamsten???? Manchmal sind die selbstgeschriebenen Routinen Dank Minimalismus die besten. Wie gesagt, ausprobieren würde ich fast alles. MfG. Uwe |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Moin Uwe,
auch wenn ich damit keine Erfahrungen habe: Es gäbe auch noch TurboPower Async Professional. Ehemals eine, sowiet ich weiss, recht teure Komponentensammlung, jetzt bei Sourceforge.net zu finden. |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Hallo,
danke für die schnelle Reaktion Chris. Ich lade mir gerade die Files und werde auch diese Lib integrieren und testen. Morgen werden wir noch mal versuchen folgende Zeiten zu messen: 1. physikalischen Empfang der 2 Byte - Message am RS232 - Port bis zum erkennen des Software events "Daten valid" 2. Daten valid bis Befehl "Daten senden" 3. Befehl "Daten senden" bis messbare Bits am ser. Port. Danach können wir ja genauer abschätzen wo die ca. 250 mS verloren gehen. Vielleicht hilft uns da bei der Lösungssuche. Aber ich hoffe ja der Wechsel der Lib bringts. MfG. Uwe |
Re: V24 (RS232) Problem beim Übergang von Windows 9x auf Wi
Habe manchen Kampf mit der RS232-Schnittstelle ausgefochten und bin nach vielen Tests auf
eine professionelle, aber absolut einfache und übersichtliche Fertiglösung gestoßen: Windows Standard Serial Communication (WSC) von Marshallsoft ( ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz