Hallo wir verwenden die standard USB->RS232 Kabelpeitschen. Wie zuverlässig sind die denn bei euch? Nach mehr als 4 Stunden hängt sich meine Software oder Windows 10 auf. Sind keine großen Daten und es wird immer bis zu 5Mb geschrieben und dann neue Datei. Ich habe keine Ahnung warum. Kann auch sein das Windows probleme hat. Viele Grüße
Marco K. schrieb: > standard USB->RS232 Kabelpeitschen Man gut, dass es auf der ganzen weiten Welt nur einen einzigen Typen davon gibt!
Marco K. schrieb: > Wie zuverlässig sind die denn bei euch? Die mit FT232 sind zuverlässig. Marco K. schrieb: > Nach mehr als 4 Stunden hängt sich meine Software oder Windows 10 auf. Keine Probleme im 24/7-Betrieb. Marco K. schrieb: > Ich habe keine Ahnung warum. Was benutzt ihr denn genau für Adapter?
Hmmm schrieb: > Die mit FT232 sind zuverlässig Kann ich nur bestätigen. Bei einwandfreier SW laufen die Dinger 24/7 ohne jeglichen Zeichenverlust bis Mbit (115k back to back in jedem Fall). Wir haben über 10 Jahre so viele im Einsatz, dass ich da keine Typen aufzählen möchte. Ich probiere aber gerne welche aus, wenn gewünscht
Bei einigen Kunden laufen Analyse-Geräte tagelang mit ICUSB2321F von Startech.com. Soweit nie Probleme damit. Der hat FTDI FT232 drin - und als Bonus immer den selben COM-Port, auch wenn er an einem anderen USB-Port hängt.
Und Finger weg von FTDI FT232, die sich mit Seriennummer 00000000 melden... mfg mf
Angehängte Dateien:
Ich kenne das Problem, dass die COM-Verbindung nach einer unbestimmten Zeit (i.d.R. einige Stunden) auf einmal wegbricht, obwohl dauerhaft kommuniziert wird (wenn auch mit geringen Datenraten und -mengen) und der COM-Port noch im Geräte-Manager gelistet ist. Meiner Erfahrung nach hilft folgendes weiter: - Im Geräte-Manager alle USB-Geräte durchklicken (Root-Hubs, Hostcontroller etc.). Bei einigen Geräten gibt es den Tab "Energieverwaltung". Dort den Haken "Computer kann das Gerät ausschalten, um Energie zu sparen" entfernen. Theoretisch sollte es reichen, den Haken nur bei dem Hub/Controller zu entfernen, an dem der COM-Port Adapter hängt. Ich gehe auf Nummer sicher und entferne das Häkchen überall. - Alle COM-Ports im Geräte-Manager durchklicken und hier ebenfalls prüfen, ob der Tab "Energieverwaltung" vorhanden ist. Falls ja, das Häkchen dort auch entfernen. - PC neustarten und prüfen, ob die Kommunikation jetzt stabil funktioniert.
Danke Marvin, das wird der erste Schritt sein der mir selbst nicht in den Kopf kam
Die Zuverlaessigkeit haengt immer ein bisschen ab was man darueber treibt. Bloed sind alte Sachen mit Protokollen aus den 80ern oder so wo teilweise Byteweise ausgetauscht wird und es einzuhaltende Antwortzeiten gibt. Dann kann man eventuell mit der Buffergroesse rumspielen. Es kann auch sinnvoll sein keinen alten FTDI zu verwenden sondern einen moderneren der USB 2.0 macht weil da die Zykluszeiten von 1ms auf 0.125ms runter gegangen sind. Sehr charmant sind auch Sonderloesungen die aus irgendwelchen Gruenden mit den Steuerleitungen rumklappern. Und ansonsten, Datenlogger. .-) Vanye
Vanye R. schrieb: > Bloed sind alte Sachen mit Protokollen aus den 80ern oder > so wo teilweise Byteweise ausgetauscht wird und es einzuhaltende > Antwortzeiten gibt. Ja, das hasse ich auch. Protokolle dürfen immer nur zustandsgesteuert sein, aber nie zeitgesteuert. Nur dann kann mal Protokolle über andere Interfaces zuverlässig tunneln.
Peter D. schrieb: > Protokolle dürfen immer nur zustandsgesteuert sein, aber nie > zeitgesteuert. Naja, sehr viele Protokolle haben (enge) Timeouts. Ganz besonders wenn man nur eine bidirektionale Leitung / Shared Medium hat. Wenn keine Antwort kommt muss man halt irgendwann mal davon ausgehen dass die Gegenstelle "tot" ist und die Leitung frei machen können für andere Teilnehmer. Gern möchte man auch sofort eine Rückmeldung haben ob überhaupt was ankommt, wie die ACK-Bits bei I²C oder CAN, um die Stabilität des Systems zu garantieren (Fehlerzähler & automatische Abschaltung). Protokolle wie CAN, I²C oder auch USB kann man aber trotzdem tunneln. Allerdings müssen die Adapter dafür smart sein und die schnellen Antworten direkt senden können. z.B. die üblichen USB-CAN-Adapter senden selbst das ACK-Bit, ohne dass der PC sie dazu anweisen müsste. Ein USB-Serial-Adapter kann das von sich aus üblicherweise nicht (bis auf ggf. die Handshake-Leitungen), weil er das Protokoll nicht kennt. Man könnte aber problemlos einen "smarten" USB-Serial-Adapter bauen, der spezifisch für eine Anwendung/Protokoll die zeitkritischen Dinge selbst abhandelt. Dazu muss dann aber auch die PC-Seite angepasst werden.
:
Bearbeitet durch User
Dankeschön für die Rückmeldungen, bisher war es immer Onboard oder PCI Karten. nur mit diesen USB haben wir die Probleme, da ist auch der Hersteller egal. Wir haben einige ausprobiert und mir war schon fast klar dass es an Windows liegt. Mit dem Selben Programm unter Wine in Linux könnte ich es nochmal Probieren. Wie geschrieben es geht eine ganze Zeit lang (etwa3H) und dann wird nichts mehr aufgezeichnet. 9600Baud konstant
Bruno V. schrieb: > Ich probiere aber gerne welche aus, wenn gewünscht Mir würden die Hersteller schon reichen, ich habe gerade die Schaltpläne vom gegen Gerät bekommen und da ist nur die TXD in benutzung, daher keine Handshakes und ich kann das Gerät auch nicht ansprechen. Würde erklären warum Windows da zickt.
Marco K. schrieb: > Mir würden die Hersteller schon reichen, Momentan nutze ich https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-4x-rs-232-digitus-da-70159-p136305.html Seit 20 Jahren "USB-2COM", die sehen so aus (nur in blau und ohne Meilhaus-Aufdruck und damals deutlich billiger) https://www.meilhaus.de/usb-2com.htm Aber wie gesagt, die werden meist mit direkter windows-seriell-programmierung benutzt ("CreateFile"). Da gibt es 0 Verluste unter Windows, wenn die Puffer entsprechend groß sind.
:
Bearbeitet durch User
Hallo, hatte das gleiche Problem wie Maro, bei der Umstellung von Win 7 auf Win 10. Problem: unter Win 10 wurde com.sys geändert ! Abhilfe bei mir: PCI Express COM-Karte Gruß Walter
Marco K. schrieb: > Schaltpläne vom gegen Gerät bekommen und da ist nur die TXD in > benutzung, daher keine Handshakes und ich kann das Gerät auch nicht > ansprechen. Würde erklären warum Windows da zickt. Windows tut das, was Du konfigurierst. Wenn kein Handshake stattfinden soll, musst Du das beim SetCommState() berücksichtigen. Marco K. schrieb: > Mir würden die Hersteller schon reichen Der Hersteller des Adapters sagt wenig aus, da können auch je nach Modell unterschiedliche ICs verbaut werden. Wenn angegeben wird, dass ein FTDI-Chip drinsteckt, und Du keinen Billigramsch mit einer Fälschung kaufst, passt das schon. Ich habe häufig diesen verwendet: https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61460-p78847.html
> Wie geschrieben es geht eine ganze Zeit lang (etwa3H) > und dann wird nichts mehr aufgezeichnet. Das ist keine Fehlerbeschreibung. Du musst mindestens den Datenstrom vom Betriebsystem aus mitloggen oder wenn du damit nicht weiterkommst dann extern. Und Linux ist vielleicht vom Zeitverhalten ein kleines bisschen besser, aber auch da kannst du solche Probleme haben. Vanye
Marco K. schrieb: > Dankeschön für die Rückmeldungen, > bisher war es immer Onboard oder PCI Karten. > nur mit diesen USB haben wir die Probleme, > da ist auch der Hersteller egal. Ich weiß nicht, ob die Leute hier wirklich schon USB-Adapter über viele Wochen oder gar Monate betrieben haben. Egal, ob COM, Tastatur oder ISDN, uns hat USB im Dauerbetrieb immer Ärger bereitet. OnBoard auf $03F8 / $02F8 ("legacy") haben immer funktioniert, aber gibt es kaum noch. Bei PCI oder USB kommen Treiber dazwischen. Mit PCI-Karten hatten wir auch schon Zoff, dessen Ursache ich nicht kenne. Die wurden dann ausschließlich von perle gekauft, furchtbar teuer, aber stabile Treiber. https://www.perlesystems.de
Manfred P. schrieb: > Ich weiß nicht, ob die Leute hier wirklich schon USB-Adapter über viele > Wochen oder gar Monate betrieben haben. Ja, wirklich. Und das nicht nur über Monate, sondern über viele Jahre im Dauerbetrieb. Manfred P. schrieb: > uns hat USB im Dauerbetrieb immer Ärger bereitet Murks-Hardware verwendet?
Momentan nutze ich https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-4x-rs-232-logilink-au0032-p132371.html der seit ca. zwei Jahren 7/24 läuft. Dabei mußte ich 2 oder 3x kurz die USB-Verbindung trennen, weil er hing, aber sonst läufts.
Manfred P. schrieb: > Ich weiß nicht, ob die Leute hier wirklich schon USB-Adapter über viele > Wochen oder gar Monate betrieben haben. Ja, haben sie. Funktionieren ohne zu mucksen auch Jahre(!) im Dauerbetrieb.
Ich werde es anders lösen und den Datenlogger Selbst bauen. Selbst der FTDI spinnt bei uns.
Marco K. schrieb: > Selbst der FTDI spinnt bei uns. Das wird nicht "der FTDI" sein, sondern die schlecht geschriebene Software, die mit ihm redet. Es ist möglich, Software mit der normalen Win32-API für serielle Schnittstellen so zu schreiben, daß sie jahrelang(!) im Dauerbetrieb mit FTDI-USB-Bridges stabil und fehlerfrei funktioniert. btdt.
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.