USB Seriell Adapter bringt mein Programm zum Absturz

[v2afrank]

Hallo,
ich habe hier ein seltsames Problem mit einem USB Seriell Adapter von Digitus.
Und zwar habe ich ein Programm geschrieben, welches über die serielle Schnittstelle mit unserer Hardware kommuniziert. Ich benutze dazu die Async Pro Komponenten. Das Programm läuft jetzt auch schon seit mehreren Jahren ohne Probleme bei der Kommunikation zu haben.
Jetzt häufen sich aber die Klagen von Kunden die den Digitus Konverter benutzen, dass das Programm abstürzt. Ich habe mir jetzt auch so einen Konverter besorgt und kann das Problem mehr oder weniger nachvollziehen. Und zwar habe ich mir eine Schleife gebaut, die 100 mal das gleiche ausliest. Mal komme ich durch, mal bleibt das Programm auch schon beim ersten mal stehen. Es ist also nicht vorhersagbar reproduzierbar. Ich habe jetzt schon zwei Stellen gefunden an denen mein Programm hängen bleibt. Zum einem ist es eine Stelle bei der ich darauf warte dass der Outbuffer geleert ist

Delphi-Quellcode:

while (ApdComPort1.OutBuffUsed<>0)

und beim simplen Schließen des Ports

Delphi-Quellcode:

ApdComPort1.Open:=false;

Wie gesagt, bei physikalisch vorhandenen Schnittstellen funktioniert der Code einwandfrei, weswegen ich hier auch nicht mehr zeige, aber bei diesem Digitus habe ich ein Problem.
Meine Vermutung geht dahin, dass unsere Hardware Signale auf irgendeine Leitung des Kabels sendet, was den Digitus Konverter aus der Bahn wirft. (Diese Vermutung wird auch dadurch bestärkt, dass ich eine Hardare dazwischen gesetzt habe die nur RxD und TxD durchlässt). Da man den Fehler aber nicht sauber reproduzieren kann, bin ich mir nicht sicher ob ich Ihn in diesem Fall vielleicht einfach nicht gesehen habe.
Letztendlich ist mir auch egal, woher der Fehler kommt, da wir unsere Hardware wahrscheinlich nicht ändern werden, aber ich hätte gerne das mein Programm weiterhin bedienbar beleibt bzw. eine Fehlermeldung bringt. Bei dem while (ApdComPort1.OutBuffUsed<>0 kann ich mir ja noch vorstellen dass ich mir eine Endlosschleife im Fehlerfall gebaut habe, aber beim Port.Open fehlt mir die Idee.

Darum hat einer von Euch eine Idee, wie ich der Sache auf den Grund gehen kann ? Ich erhalte keine Exception und das Programm reagiert einfach nicht mehr. Auf einem unserer XP Rechner geht es sogar so weit dass der ganze Rechner ausgeschaltet werden muss, da sich das Programm noch nicht einmal mehr vom Taskmanager beenden läßt. Mit meinem Windows 7 Rechner kann ich den Prozess zumindest immer abschiessen. Ich bin für jede Idee dankbar und werde es testen, obwohl ich momentan mich kaum trauen würde zu sagen, jetzt ist der Fehler behoben.

[Bernhard Geyer]

Wird schon auf die neueste Sourceforg-AsnyPro verwendet?

[MeierZwoo]

Nach meinen Erfahrungen mit diesen USB/Seriell/Parallel-Adaptern diverser Hersteller kann ich nur raten, von denen die Finger zu lassen und eine passende Schnittstellenkarte einzubauen bzw. wenn die Ports auf dem MB vorhanden sind, diese per SlotAdapter nach aussen zu führen. Für Lappis gibt es auch passende PCMCIA-Adapter.

Leider glauben die meisten Hardware-Hersteller wie auch Händler, daß diese "veralteten" Schnittstellen eh niemand mehr benutzt.

Da Windows den direkten Zugriff auf die Hardware-Adressen und Puffer dieser Schnittstellen eh nicht mehr zuläßt, wird die Kette der Datenweitergabe bei Adapern an USB immer länger und fehleranfälliger - zumal bei diesen USB-Adaptern bei jedem Win-Start der Treiber neu initialisiert wird.

[sx2008]

Zitat:

Zitat von MeierZwoo (Beitrag 1205448)

Nach meinen Erfahrungen mit diesen USB/Seriell/Parallel-Adaptern diverser Hersteller kann ich nur raten,

Nach meinen Erfahrungen ist es so, dass es gute und schlechte USB-Serial-Adapter gibt.
Man muss nur die guten Hersteller finden und dabei bleiben.
Ich kann dir leider keinen "guten" nennen, weil ich das Problem an den Service verdrängt habe.

Ein wichtiger Unterschied ist z.B. ob es im USB-Adapter eine Seriennummer gibt oder nicht.
Ein Adapter mit eindeutiger Seriennummer wird z.B. an jeder USB-Buchse wiedererkannt.
Windows weiss dann dass der Adapter mit dieser best. Nummer z.B. für COM4 zuständig ist.
Ohne Seriennummer muss man den Adapten immer an der gleichen Buchse anstecken.

[yogie]

Hallo,

das kommt mir sehr bekannt vor. Ich kenne die Probleme bei der Verwendung von
eigener Hardware mit USB Chips von FTTDI (und auch mit USB Adaptern). Die Treiber
sind da auch nicht wasserdicht. Was auch gerne schief geht : falls eine USB Verbindung
gesteckt wird und das Gerät schon Daten senndetm besteht WIN darauf, daß es sich um eine Maus
handeln muß.

Leider kannn ich keinen Tip geben, auch ich verwende seit vielen Jahren AsyncPro.
Der Wechsel auf eine andere Toolbox behebt die Probleme jdenfalls nicht.

[Chemiker]

Hallo,

habe die gleichen Erfahrungen gemacht musste einige Adapter ausprobieren, bis einer zuverlässig funktionierte. Allerdings gab es nur Probleme mit den Daten die Übertragen worden sind, dass Programm oder der ganze PC ist nicht abgestürzt.

Bis bald
Chemiker

[MeierZwoo]

Zitat:

Zitat von sx2008 (Beitrag 1205455)

Ein wichtiger Unterschied ist z.B. ob es im USB-Adapter eine Seriennummer gibt oder nicht.
Ein Adapter mit eindeutiger Seriennummer wird z.B. an jeder USB-Buchse wiedererkannt.
Windows weiss dann dass der Adapter mit dieser best. Nummer z.B. für COM4 zuständig ist.
Ohne Seriennummer muss man den Adapten immer an der gleichen Buchse anstecken.

Dieser Hinweis erscheint mir logisch und sehr hilfreich. Nur: leider sind die Produktbeschreibungen bei den Händlern so schlecht (bei parallelen steht oft nicht einmal bi- / unidirectional bei), daß wohl wider nur kaufen, testen (SN evtl. auslesen), wegwerfen übrig bleibt.

[zeras]

Zitat:

Zitat von yogie (Beitrag 1205482)

Hallo,

Ich kenne die Probleme bei der Verwendung von
eigener Hardware mit USB Chips von FTTDI (und auch mit USB Adaptern). Die Treiber
sind da auch nicht wasserdicht.

Ich habe die Erfahrung gemacht, dass die FTDI Chips laufen, aber andere Hersteller nicht. Wenn wir solche nutzen, dann nehmen wir die mit dem FTDI Chip. Kaufe aber auch nicht die billigsten, denn der Treiber ist das Entscheidende dabei.
Ich weiß zwar nicht, welche Baudrate du nutzt, aber besser ist es, wenn die nicht so hoch ist. Wenn möglich, dann vielleicht 19200 nehmen. Dann sollte alles OK sein.

[v2afrank]

Danke erst mal für die wenig ermutenden Worte. Als baudrate benutzen wir 9600 bzw. 38400 Baud. Ich habe auch einen anderen USB Adapter der bisher Problemlos läuft.
Das Problem was ich nur habe, ich kann ja eigentlich keinen Adapter guten Gewissens empfehlen. Die User setzen sehr viele unterschiedliche Laptops und Betriebssysteme ein. Wahrscheinlich kann ich denen nur empfehlen verschiedene Adapter zu testen und den nehemen der bei ihm funktioniert.
Auf Dauer wollen wir sowieso unsere Hardware mit USB anstelle von RS232 ausstatten, bis sich das komplett durchgezeogen hat wird es aber noch einige Jahre dauern.

[sx2008]

Zitat:

Zitat von zeras (Beitrag 1205508)

Ich habe die Erfahrung gemacht, dass die FTDI Chips laufen, aber andere Hersteller nicht.

Ich habe da noch eine Seite gefunden, die deine Erfahrung bestätigt und weitere interessante Infos hat:
http://www.usconverters.com/index.ph...age=page&id=62..

Weiterhin ist bei USB -> Serial Adaptern noch zu beachten, dass Pausen und Abstände zwischen den einzelnen Bytes nicht korrekt übertragen werden können.
Das heisst wenn man z.B. beim Senden eine kleine Pause zwischen jedem einzelnen Byte lässt auf der RS232-Seite evtl. gleich 8 Bytes direkt hintereinander geschickt werden.
Oder das RS-232 Geräte schickt zwei kurze Antworten in einem zeitlichen Abstand, dann kann es sein, dass auf PC-Seite beiden Antworten in einem Block ankommen.
Es ist wichtig dass das Protokoll robust ist und nicht von Pausen abhängig ist.
Ein robustes Protokoll hat z.B. folgenden Aufbau:

Code:

<STX>Nutzdaten1<ETX><STX>Nutzdaten2<ETX>

<STX> = Start-of-Text Zeichen
<ETX> = End-of-Text Zeichen
Da die RS232-Verbindung ungesichert ist, wäre ein zusätzliches Checksum-Byte auch empfehlenswert.