Und dann gab es (ca. 1985 :-) noch eine Registrierkasse (ANKER oder ADS) die auf ihrer seriellen Schnittstelle eine 'wohldefinierte' Pause von 'ca. 5 - 8 Millisekunden' zwischen den einzelnen Kommando-_Records_ haben wollte.
Auf einem KAYPRO (4 MHz Z80) war das überhaupt kein Problem; auf dem PC / AT unter MSDOS auch keines. Aber dann unter Windows...
Und it heutigen USB-Teilen könnte das bei solchen Anforderungen auch zu Problemen kommen,
Nur Rx- und Tx-Daten; keine Handshake-Signale nötig, IIRC
Das wiederum ist völlig normal und richtig, wenn es einen PE Anschluss gibt, muss der auch benutzt werden und die Rechnermasse muss mit PE verbunden sein. Typisch liegt der -pol auf Masse.
Dass das zu 'Brummschleifen' führen kann, ist ein anderes Blatt.
Und bei Deinen kurzen Kabellängen von 2m, dürfte das nicht das geringste Problem machen. Wenn doch, ist da was ganz übles in der Installation vermurkts worden.
So einen Müll kenne ich auch von DEC, die schickten seinerzeit hinter jedem und 5-10 :-( Konnte man einstellen in der config (oder wie das damals hiess)
Das üble an den ist es, dass das die üblichen Checksummen nicht veränderte, bloss die Zeichenanzahl im Protokoll stimmte nicht mehr.
Und dann in Kombination mit Siemens 3964R Protokoll... Da hab ich nachgewiesen, dass SIEMENS und TANDEM die (eigenen) Protokolle nicht eingehalten haben. War lange, teuer und nervig, aber als man mir Produktionsausfall und Unkenntnis unterschieben wollte, wurde ich halt bockig. Schöne Stundenzettel geschrieben und abzeichnen lassen. Den Dr. XXXXX, der das verbockt hat und sich weigerte, endlich Vernunft anzunehmen... war irgendwann von der Gehaltsliste verschwunden und ich hab meine IIRC 25kDM für Wartezeit/Inbetriebnahme/Consulting bekommen :-)
Ich hab auch den Bau eines kleinen (Z80 2,5 MHz; 9600Bd) bezahlt bekommen, der in dem Werk/Konzern alle SIEMENS und Tandem Rechner aufs Kreuz legen konnte :-)
Aber ein netzversorgtes Laptop darf ohne galvanische Trennung angestöpselt werden? Ist ja schön, wenn dabei NUR das Laptop die Grätsche macht, könnte aber ja auch mal ne Anlagenkomponente sein...
Wie gesagt - in Zukunft nur noch galvanisch getrennte USB-Konverter benutzen, und den Rest der Probleme mit COM-Ports etc. dann separat davon behandeln, dann wird sich das auch in den Griff kriegen bzw. auf einige wenige Sonderfälle reduzieren lassen
da geht es um Anlagen der Gebäudeinstallation. Die Distanz von dem D-sub Stecker zu dem nächsten PE kann elektrisch hunderte von metern sein. Die Anlagen werden nur an einem Ort geerdet, die Bedienpanels , die sich auch zwei Häuser weiter befinden können sind floating. So ist es nunmal, die Anlagen sind so geprüft und zugelassen und genau so von diversen Fachstellen zugelassen.
Ja, im Prinzip schon, aber die haben den Prozess dann abgeworfen, weil die Kommunikation nicht mehr funzte :-o
Was nutz Dir ein NonStop Rechner(cluster) wenn es nix mehr zu rechnen gibt. Na gut, er kann sich um andere Prozesse kümmern. Aber ist nicht wirklich lustig, wenn der Rollgang steht, weil nix geht, das zieht Kreise :-)
Zusammengefaßt: Das Timing kann man komplett vergessen. Da USB, soweit ich weiß, in Zeitscheiben bedient wird, kommt jedes Gerät nur so ca. alle Millisekunde dran.
Bei FTDIChip gibt es eine Application-Note, die die Besonderheiten, wie ich finde, recht gut erklärt:
formatting link
Kurz: Alles, was Timing präziser als diese Zeit erwartet, wird nicht zuverlässig funktionieren. Das einzige, was dennoch geht, ist die serielle Übertragung selbst, da hier der USB-Serial-Chip das Timing auf der seriellen Seite kontrolliert.
Insbesonders sollte auch die Flußkontrolle (Handshake) funktionieren: Das ist nämlich zumindest bei den FTDI-Chips auch in der Chip-Hardware implementiert. (aus dem Linux-treiber-Quellcode: /* Set flow control */ /* Note device also supports DTR/CD (ugh) and Xon/Xoff in hardware*/ if (cflag & CRTSCTS) {
Bei selbstgebauen USB-Geräten mit FTDI benutze ich deshalb auch _immer_ RTS/CTS-Handshake. Dann ist garantiert, daß nie Zeichen verloren gehen. Wenn der Microcontroller oder der PC zu beschäftigt sind, hält er halt die Übertragung an.
Also nochmal: Hardware-Handshake funktioniert bei mir (sehr gut!) mit USB- Geräten und ist wegen der größeren Latenzen sogar eher wichtiger als bei direktem RS232. Was nicht funktioniert, ist, wenn irgendeine der Statusleitungen für etwas anderes außer der ihr zugedachten Flußkontrolle gebraucht werden, was zudem noch zeitkritisch ist. Ebenfalls geht es schief, wenn das _Timing_ der seriell übertragenen Daten kritisch ist (also z.B. innerhalb von x ms eine Antwort erfolgen muß).
Falls Du Geräte hast, die so etwas machen, gibt es schlicht und einfach mit einem USB-Seriell-Konverter keine Chance (und vermutlich mit einem echten Com-Port unter Windows auch nicht, da auch da das Timing nicht strikt garantiert ist).
So kompliziert ist es auch nicht: Die Schnittstellensignale wie auch die anderen Einstellungen werden alle ~ ms zwischen USB-Master und Slave abgeglichen, Daten werden mit einer eigenen Flußkontrolle in Paketen übertragen und der USB-Serial-Chip am anderen Ende des Kabels spielt spielt einfach wieder "Terminalprogramm" mit seiner seriellen Schnittstelle, die er entsprechend den Vorgaben konfiguriert. Auf Timing wird dabei keine Rücksicht genommen.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.