Serielle Kommunikation (RTS) und Windows 7

Ich bin der Entwicklung Delphi-Anwendung auf Delphi 2010, XE und RAD Studio unter Windows 7. Mein Antrag spricht über den seriellen port non-stop. Ich bin mit AsyncPro für Delphi 2010. Serielle Kommunikation und alles andere auf dem computer entwickle ich mit funktioniert Super ohne jedes problem. Aber wenn meine release-version meiner Applikation läuft auf einem anderen Windows 7 system, serielle Kommunikation komplett fehlschlägt. Wir sondierten die serielle Kommunikation selbst, nach einer Antwort und fand heraus, dass die Anforderung zum Senden (RTS) - Zeile nicht gelöscht wird, direkt nach dem Absenden der bytes, in der Erwägung, dass auf meinem computer Entwicklung RTS-Linie gefallen ist korrekt.

Selbst wenn ich explizit fallen die RTS-Leitung auf low oder false, Zustand, RTS-line nicht drop sofort, aber nach gut 15 Millisekunden. So, serielle Kommunikation, der auf meine version ist zu Versagen.

Fehlen mir wichtige Informationen über Windows 7 und serielle Kommunikation Fragen?

UPDATE: ich habe gerade den Fehler gefunden, mit meinem Aysncpro 5.0 für Delphi XE. Es ist merkwürdig. Wenn mein Delphi XE-IDE geöffnet ist oder läuft, mein Programm ist die Kommunikation einwandfrei. Wenn ich auf Herunterfahren oder schließen, mein Delphi XE IDE, während mein Programm läuft, das gleiche Programm, nicht sehr gut kommunizieren, oder es mal aus.

Glockenspiel in, wenn Sie eine Idee haben, warum es geschieht.

Jede Hilfe wird geschätzt.

Danke,

  • Wie gesagt, AsyncPro, ist das, was passiert ist. 🙂 Jetzt weißt du es ist ein bug in der async pro. Ihre Unfähigkeit zu bekommen, die TComPort-demo arbeiten, ist wahrscheinlich einfach und trivial zu überwinden. Eine Frage stellen über das, und ich werde eine funktionsfähige demo für Sie.
  • Ist Ihre Anwendung unter Einsatz von BPLs (Laufzeit-packages)?
InformationsquelleAutor ThN | 2011-05-26
  1. 5

    Klingt wie eine timer-Auflösung problem für mich. Ich hatte das gleiche problem beim schreiben auf ein USB-FTDI-Treiber mit einem Ereignis-basierten timer mit timeSetEvent()... Wenn Delphi geladen, es ändert sich die timer-Auflösung kleiner als 20ms, was meine app funktionieren. Wenn die IDE nicht ausgeführt ich konnte nicht Dinge arbeiten unter 20ms +/- 5ms (der Standard-Windows-Auflösung glaube ich).

    Um das problem zu beheben, ich nenne timeBeginPeriod(1) im thread um die minimale systemweite timer-Auflösung.

    Ich glaube, das wirkt sich auf die Auflösung des anderen zeitbasierte Ereignisse, weil ich besser als +/-5ms Genauigkeit auf andere (nicht-multimedia-timer) warten Ereignisse in meiner app verwenden, wenn ich timeBeginPeriod().

    Also, was ich Vorschlage, ist, dass irgendwo in den AsyncPro code es einige Zeit, Ereignis oder rufen Sie zurück... Das wäre betroffen von Delphi ändern der timer-Auflösung, wenn es geladen wird. Versuchen Sie anrufen timeBeginPeriod(1) irgendwo in deiner app, wenn es startet und sehen, ob gab es eine Veränderung.

    Oh, und vergessen Sie nicht, rufen timeEndPeriod(1) wenn Ihre app beendet wird.

    N@

    • Interessant. Auf der Embarcadero-Gruppen gab es ein weiteres Problem mit der Zeit - threads zu nehmen schien 15-30 ms zu bekommen, geplant auf app startup. Ich habe nie bemerkt, weil ich immer mir beim Start & nie kündigen oder machen Sie nicht mehr. Nur aus Interesse, ich habe eine GetTickCount in einer thread-ctor in meiner aktuellen app und einen anderen AGB an der Spitze der "execute" - Methode. Sicher genug, als meine Benutzeroberfläche angezeigt, der Unterschied, ich hab '15'. Irgendwann habe ich versucht, läuft meine app außerhalb der IDE - '0'. Ich hatte nie das unangenehme hantieren mit der system-Zeit mit D5!
    • Hmm.. meine serial port code nicht eine explizite Timer, nur dass COMMTIMEOUTS Dingens. Ich habe keine Probleme mit hardware flow control, also vielleicht haben Sie Recht. Mal auseinander zu nehmen Apro?
    • Keine Notwendigkeit für die Timer, die ein " Sleep(1)' warten 15.625 ms (mit gemeinsamer hardware) mit dem Standard-Auflösung, ~1ms mit der besten Auflösung. Nicht besonders im Zusammenhang mit Delphi zu, wie Nat wies darauf hin, es system-wide. Sobald eine Anwendung setzt eine höhere Auflösung, andere nutzen es auch. Der OP könnte das gleiche Beobachtung mit, f.ich. MSN messenger oder Windows Media Player oder was auch immer anstelle von der Delphi-IDE.
    • Wirklich interessant. Ich hatte noch nie viel Glück-spielen mit dieser Einstellung. Auch eine erhöhte Auflösung der Timer nur macht Windows-Leistung etwas mehr nützlich.
    • Nun, es ist sicherlich macht meine app ausführen sehr gut, ich bekomme einen Daten-frame, der auf mein USB-Gerät 40 mal pro Sekunde mit +/-1ms Genauigkeit auch auf Alter hardware, und während der Ausführung von mehreren sound-streams mit (die schrecklich Ressourcen-hungrig) DirectShow-api.
    • In der Tat, jede app, ändert die Auflösung erstellen kann, die gleiche Wirkung. Es ist wohl einer der wenigen api-aufrufen Links, dass eine app das ändern kann, kann direkt auf andere apps. Nicht wirklich schlecht, aber es macht es schwer zu Debuggen, manchmal Dinge!
    • sehr interessant in der Tat. Ihr ein Lebensretter. Ich bin glücklich gefunden zu haben Stackoverflow. Ich fügte hinzu, timeBeginPeriod in onShow-Ereignis und timeEndPriod innerhalb onFormCloseQuery und es funktioniert. Ich habe sogar mein system neu gestartet und begann mein Programm frisch vor dem Start alles anders.
    • Nur für den Fall Leute Fragen, wo diese Verfahren kommen aus, Sie sind aus dem MMSystem-Unit.
    • BEOBACHTUNG Nachdem Sie die änderungen vorgenommen und es läuft für eine Weile, bemerkte ich, dass einmal in eine Weile RTS-Leitung bleibt für 15 MS oder länger. So, meine serielle Kommunikation mal sagen, für alle 50.000 eine gute Kommunikation gibt es mindestens 100 timeouts. Dachte ich sollte etwas sagen über dass. Nochmals vielen Dank für die Hilfe.
    • Doe überrascht mich nicht überhaupt! Es würde verhindern, dass eine Reihe von Mechanismen, die verwendet werden, damit der Prozessor auf Gas runter.

    InformationsquelleAutor Nat
  2. 5

    Letzten paar Male, die ich sah zufällig unerklärlichen Mist wie ich, alles versucht, und war nicht in der Lage, es zu lösen, für Monate.

    Fand ich zwei verschiedene Ursachen:

    1. ASYNC Professional hat einige seltsame Störungen, dass ich nicht in der Lage war zu lösen, also ließ ich es und zog in TComPort.

    2. Fand ich alle Arten von seltsamen flow-control-Fehler im USB-Treiber. Ich fand FTDI Chipsatz-USB-zu-Seriell-zuverlässiger als andere.

    Den Debug-build nicht habe das problem könnte sein, zwei Dinge:

    1. Gewissen zeitlichen Veränderungen Ursache das USB-Gerät, Treiber wurde nicht, nicht zu scheitern.

    2. Du eigentlich irgendeine Art von thread-problem, wie eine race condition, die zu Ihrem ASync Pro-Komponenten Durcheinander in einer Weise, dass sieht aus wie etwas passiert, um Ihre port -, aber eigentlich ist es ASYNC pro.

    Die einfachste Sache zu tun ist, um zu versuchen, es mit einem anderen USB-zu-Seriell-adapter, und wenn das nicht Ihr problem lösen, ich wäre versucht zu ziehen AsyncPro, die ich auch schon viele verschiedene Probleme mit, und entweder schreiben Sie Ihre eigenen seriellen port class, oder verwenden Sie TComPort. Ich habe auch einige Zeit lang Erfahrung mit der Verwendung von TThread, die einen com-Anschluss verwendet "reader/writer" - Klasse und habe festgestellt, dass dies der zuverlässigste Weg zu gehen, denn Sie können zwicken low-level-Elemente, die von der Win32-overlapped-IO-Aufrufe, die direkt auf Ihre Bedürfnisse, und auch sicher sein, dass Sie nicht über einige zusätzliche Komplexität/overhead-immer im Weg. (AsyncPro die Komplexität und den Aufwand, eine bedeutende potentielle Quelle für Fehler.)

    • Die Sache ist die, Warren P, wir haben AsyncPro für die letzten 7 Jahre ohne ein problem, bis zu Windows 7. Unsere software ist so ziemlich etabliert. Also, wir werden nicht erwartet jeden Mist ein Problem mit Asyncpro 2010. Die Tatsache, dass Aysncpro funktioniert perfekt auf meinem windows-7-Entwicklung-computer und nicht für andere Windows-7-system bedeutet, dass es einen Unterschied in der Treiber-oder hardware-Fehler aufgetreten ist. Ich bin gerade auf der Suche nach Anregung oder Idee für eine Lösung. Danke.
    • +1 für TComPort. Ich habe AsyncPro Jahren aber begonnen, die Probleme mit W7.
    • Was änderte es für mich war nicht Windows 7, es war das Ende der integrierten seriellen Schnittstellen und die Allgegenwärtigkeit von USB-zu-Seriell-Adapter. Ich hatte nie Probleme mit AsyncPro, bis die Wechselfälle der seine Handhabung von flow-control-Signalisierung, und ähnliche Fragen, wurden vermischt mit Blätterteig usb-Treiber. Es ist auch nicht ungewöhnlich, um Probleme aufgrund einer fehlerhaften USB-KABEL. Ich habe Probleme gehen Weg von ändern das USB-KABEL heraus.
    • Gut, ich habe versucht, TComport und die demo gar nicht auf meinem windows 7-computer. Ich denke, TComport ist zu einfach für meine Anwendung. Mein Programm kommuniziert im RS485-Modus mit DTR aktiviert, auf dem SerialPort. Das Programm ist nicht das senden und empfangen von acii-Zeichen, sondern bytes oder hex-Werte. Soweit Asyncpro betroffen ist, ist es möglich, dass es problem bei der Kommunikation, da der Benutzer angemeldet ist, der kein administrator ist. Auf meinem PC habe, bin ich der einzige user und auch der administrator.
    • TComPort ist in der Tat perfekt für RS485, und das ist genau das, was ich verwendet für. Komplizierter code (AsyncPro) nur führt zu Problemen in RS485.
    • Ja. Ich habe nicht verwendet alle Komponenten werden nun für einige Jahre. Ich habe nur noch in einem seriellen Gerät habe ich vor Ewigkeiten geschrieben hatte, verwendet ein TThread + IO-completion-Rückruf, viel die gleiche wie deins, denke ich. Er arbeitete auf W2k und funktioniert immer noch auf D2009/W7 ohne code-änderung, außer Zeichenfolge>ANSIstring und viele wanings über implizite Konvertierung<g>
    • Sorry für die Verspätung meiner Antwort. Naja, ich glaube, ich könnte mit TComport anstelle von Asyncpro, aber wenn ich versuche, führen sogar Ihre demo-Anwendung, es würde nicht senden senden auch aus einem einzelnen byte oder ein bit. Ich überprüfte alles, um sicherzustellen, dass ich nicht irgendwelche Fehler. Dennoch ist es TComport fehlgeschlagen, aber wenn ich Asyncpro es sendet Pakete aber die RTS-Leitung bleibt, bis ein länger als erwartet.
    • So überspringen Sie beide Komponenten, und schreiben Sie Ihre eigenen Win32-API-Aufrufe. Es ist NICHT schwer! Datei öffnen, schreiben, Datei-handle, schließen Sie die Datei. Schwer? Nein.

    InformationsquelleAutor Warren P
  3. 1

    Dies ist ein Treiber-problem auf dem anderen Rechner, oder? Hardware-flow-control funktioniert gut auf meinem W7-test box als gut, (und Vista-Entwicklung-Maschine). Wenn Ihr Apro hat die DCB richtig, und es klingt, wie es tut, weil der Ihre "manuelle" tests, die Treiber sollte Arbeit...

    15ms für eine 'manuelle' RTS ändern von Benutzer-Modus ist traurig, aber überhaupt nicht ungewöhnlich auf Windows - das ist, warum die Treiber sollte es tun.

    Rgds,
    Martin

    • nachdem er mindestens einen ganzen Tag testen und testen. Ich habe den Fehler gefunden. Mein Programm kommuniziert richtig, wenn der Delphi-IDE ausgeführt wird, aber nicht, wenn es heruntergefahren ist. Irgendwie eine wichtige Bibliothek oder Datei verknüpft, um die Delphi-IDE geladen wird am start von einer Hinrichtung. Diese Datei ist notwendig für mein Programm zu kommunizieren, richtig zu. Nach dem Neustart mein system, habe ich begonnen, meine Bewerbung und es nicht von alleine laufen, es sei denn, der Delphi-IDE ausgeführt wird. Was denkst du, ist der Grund.
    • <seufz> einem anderen IDE lustig:( ich habe aufgehört zu laufen, etwas anderes als die tatsächlichen manuelle Debuggen aus der IDE. Ich habe früher hit " F9 " am Ende des Tages und zu sehen, ob meine app noch ausgeführt wurde, in den morgen. Jetzt finde ich die EXE mit dem explorer und führen Sie es fromm gibt. Die IDE ist sicherlich spritzt ein paar DLL mit threads über 'F9', sondern was Sie tun könnten, um Einfluss auf die Funktionalität des COM ports ich habe keine Ahnung, fürchte ich. Noch eine weitere Sache für mich, misstrauisch zu sein, also danke, auch wenn ich keine Antwort für Sie!
    InformationsquelleAutor Martin James
Schreibe einen Kommentar