Liebes Forum, ich habe einen Aufbau, bei dem ein räumlich weit verzweigtes "USB-Netz" aufgebaut wird. Nach folgendem Schema: PC <-> USB/Kat6-Wandler <-> Kat6-Kabel1 <-> Kat6/USB-Wandler <-> USB-Kabel-1m <-> USB-Hub <-> USB/Kat6-Wandler <-> Kat6-Kabel2 <->Kat6/USB-Wandler <-> USB-Kabel-1m <-> Meßgerät Das Problem ist, daß es im Laboraufbau funktioniert, wenn das Kabel1 kurz ist, aber im Feldeinsatz geht es dann leider nicht. Daher vermute ich, daß es sich um ein Laufzeitproblem handelt. Lt. Norm erlaubt USB ca. 5m lange Kabel und fünf Ebenen von USB-Hubs, was einer maximalen Länge von 30m entsprechen würde. *Gibt es eine Möglichkeit die Laufzeit zwischen PC und Endgerät zu messen?* Die Wandler sind erforderlich, weil die Entfernungen zu groß sind. Mit den Wandlern sind lt. Hersteller Kabellängen bis 60m überbrückbar; die werden hier aber nicht erreicht. PS: Und bitte keine Diskussion, daß USB nicht geeignet wäre. Mir ist schon bewußt, daß es ein grenzwertiger Aufbau ist, aber der ist nun einmal leider gewünscht. Wandler: Digitus 70141 USB-Hub: 64039
Meines Erachtens nach kann Dir da keiner helfen, außer der Hersteller der USB-CAT Wandler. Die 5m Beschränkung resultiert aus den 1.5ns Verzögerung zwischen Daten und ACK/NACK. Diese gilt aber nur auf den USB-USB Segmenten, da die Repeater die Pakete als HUBs entgegen nehmen. Die ACKen das Paket gegenüber dem Sender und erwarten dann ein ACK von dem, der das Paket dann von ihnen entgegen nimmt. Was spricht gegen echtes USB over Ethernet? Da kannst Du die 300m Ethernet voll machen und von 4 USB2.0 bis hin zu 12(?) USB-C Devices direkt anschließen. Alles eine Preisfrage.
Tja, wenn die Diskussion nicht gewünscht ist, dass das gar nicht geht, dann ist es ziemlich sinnlos hier irgend etwas weiter zu schreiben. Viel Spaß mit dem Abfall. Wenn man den Standard und die Physik ignoriert, dann hat man halt Freude.
Ulrich schrieb: > Meines Erachtens nach kann Dir da keiner helfen, außer der > Hersteller > der USB-CAT Wandler. Die 5m Beschränkung resultiert aus den 1.5ns > Verzögerung zwischen Daten und ACK/NACK. Diese gilt aber nur auf den > USB-USB Segmenten, da die Repeater die Pakete als HUBs entgegen nehmen. > Die ACKen das Paket gegenüber dem Sender und erwarten dann ein ACK von > dem, der das Paket dann von ihnen entgegen nimmt. > > Was spricht gegen echtes USB over Ethernet? Da kannst Du die 300m > Ethernet voll machen und von 4 USB2.0 bis hin zu 12(?) USB-C Devices > direkt anschließen. Alles eine Preisfrage. Ich hatte vermutet, daß die Wandler jeweils auch "Hubs" darstellen. Dann wären also tatsächlich 5 Hubs in der Kette, also die Maximalzahl. USB over Ethernet war auch in der Vorüberlegung. Aber wir brauchen (zunächst) 8 USB-Meßgeräte an verschiedenen räumlichen Orten, also würde man 8 USB-over-Ethernet-Geräte benötigen. Abgesehen vom Preis ist doch die Frage, ob das dann noch mit der vorhandenen Software funktionieren würde, die eben alle Geräte als USB erwartet. Und wir hatten den Hersteller natürlich vorher gefragt, ob er eine solche Lösung für denkbar halten würde. Antwort: ja. Und wie gesagt, es funktioniert im Testaufbau ja auch, aber irgendwie ist die Kabelgesamtlänge dann in der Summe wohl doch irgendwie zu hoch. Und natürlich haben die Kollegen das Zeugs natürlich schon gekauft. ;-) Plan B wäre, den PC direkt mit dem Hub zu verbinden, dann würden wenigstens 2 der 5 Hubs entfallen.
:
Bearbeitet durch User
Svensson schrieb: > Das Problem ist, daß es im Laboraufbau funktioniert, wenn das Kabel1 > kurz ist, aber im Feldeinsatz geht es dann leider nicht. Und was ist, wenn beim Laboraufbau das Kabel 1 ebenfalls lang ist? Nicht, dass da im Feld einfach nur sowas "Simples" wie Störungen oder eine Potentialverschiebung reinfunken...
:
Bearbeitet durch Moderator
Vermuten hilft leider nicht. Ein USB->Kat6-Wandler und zurück bedeutet, dass es nur mit ganz wenigen Geräten funktionieren kann, für die der Hersteller von diesem Schwachsinn seinen Mülladapter speziell hingebogen hat. Die Umwandlung in ein anderes Format bedeutet eine deutliche Verzögerung, die verhindert, dass die Zeiten für die Signalisierung auf dem Bus eingehalten werden können. Darum tun diese Mülladpater i.d.R. so, als wenn sie der Host oder das Gerät wären und übertragen die Datenpakete mit deutlicher Verzögerung. Ist völlig egal was irgend jemand davon hält, eingekauft hat, glaubt oder seine Großmutter für eine Schuhgröße hat, sobal man mit diesen Dingern versucht etwas zu betreiben, das nur ein Bisschen anders ist, als der Hersteller geträumt hat, geht nichts mehr. Die einzige saubere Option den USB weg vom Rechner zu verlegen ist der USB-Server, also ein Gerät in dem der Hostcontroller drin ist und dieser über Ethernet angesprochen wird. Das ist auch auf der Softwareseite kompatibel, weil die Software einfach nur das USB-Device sieht und sich nicht darum kümmern muss, wie der Hostcontroller angesprochen wird, das machen die drunter liegenden Treiber.
Svensson schrieb: > Das Problem ist, daß es im Laboraufbau funktioniert, wenn das Kabel1 > kurz ist, aber im Feldeinsatz geht es dann leider nicht. > Daher vermute ich, daß es sich um ein Laufzeitproblem handelt. Lt. Norm > erlaubt USB ca. 5m lange Kabel und fünf Ebenen von USB-Hubs, was einer > maximalen Länge von 30m entsprechen würde. Hast Du das originale USB 2.0 Standarddokument tätsächlich gelesen und verstanden? Nicht irgendwelche Sekundärliteratur, sondern den originalen Standard? Dann wüsstest Du, dass da an keine Stelle etwas von 5m drin steht. Das einzige, was definiert ist, sind die maximalen Laufzeiten (721 Bitzeiten roundtrip delay) und die maximale Dämpfung. > *Gibt es eine Möglichkeit die Laufzeit zwischen PC und Endgerät zu > messen?* Mit einem passenden Oszi und geeigneten Tastköpfen mit wenig Eingangskapazität geht das schon. > Die Wandler sind erforderlich, weil die Entfernungen zu groß sind. Mit > den Wandlern sind lt. Hersteller Kabellängen bis 60m überbrückbar; die > werden hier aber nicht erreicht. Diese Wandler sind aus meiner Erfahrung heraus nicht wirklich langzeitstabil. Erfolgversprechender ist eine andere Lösung: USB Device Server. Die werden in der unmittelbaren Nähe des USB Devices positioniert und per LAN angesteuert, und ein Treiber auf dem Host bindet den als USB Hostcontroller ein. Die kritische USB-Strecke kann dadurch kur bleiben, und beim LAN gibt es keine ernsthaften Längenbeschränkungen. Über Glasfaser bekommst Du Kilometer an Strecke hin. So sieht das aus. https://www.silextechnology.com/connectivity-solutions/usb-network-connectivity/ds-700 fchk
Guido K. schrieb: > Die einzige saubere Option den USB weg vom Rechner zu verlegen ist der > USB-Server, also ein Gerät in dem der Hostcontroller drin ist und dieser > über Ethernet angesprochen wird. Das ist auch auf der Softwareseite > kompatibel, weil die Software einfach nur das USB-Device sieht und sich > nicht darum kümmern muss, wie der Hostcontroller angesprochen wird, das > machen die drunter liegenden Treiber. Das ist nicht der einzige Weg. Der Hostcontroller muss vor Ort hin, in kurzer Entfernung zum USB-Device. Das ist klar, ansonsten kriegst Du das nicht zuverlässig gelöst und es geht nur manchmal. Wie der Hostcontroller dort angebunden wird ist flexibel. Es gibt z.B. auch Lösungen die PCIe über Glasfaser übertragen, ohne Umweg über Ethernet: https://www.adnaco.biz/collections/s3b Vorteil im Vergleich zu Netzwerk-basierten Lösungen ist die deutlich niedrigere Latenz.
:
Bearbeitet durch User
Gerd E. schrieb: > Wie der Hostcontroller dort angebunden wird ist flexibel. Es gibt z.B. > auch Lösungen die PCIe über Glasfaser übertragen, ohne Umweg über > Ethernet Ja, Korinthe voll mittig getroffen ;) Klar, es ist für diese Methode ziemlich egal was für ein Kommunikationsmedium bis zum Hostcontroller benutzt wird. Wichtig ist der Punkt, dass der Hostcontroller bei den Devices ist. Ich frage mich immer, warum so viele Leute den USB mit einem LAN verwechseln.
Frank K. schrieb: > Hast Du das originale USB 2.0 Standarddokument tätsächlich gelesen und > verstanden? Nicht irgendwelche Sekundärliteratur, sondern den originalen > Standard? Dann wüsstest Du, dass da an keine Stelle etwas von 5m drin > steht. Das einzige, was definiert ist, sind die maximalen Laufzeiten > (721 Bitzeiten roundtrip delay) und die maximale Dämpfung. Natürlich nicht, ich bin doch kein Masochist. > Diese Wandler sind aus meiner Erfahrung heraus nicht wirklich > langzeitstabil. Erfolgversprechender ist eine andere Lösung: USB Device > Server. Das muß auch nicht langzeitstabil sein, sind eher temporäre Versuchsaufbauten. Also mit USB-Printservern habe ich jede Menge schlechter Erfahrungen gemacht. Von wegen geräteunabhängige Treiber... Lothar M. schrieb: > Nicht, dass da im Feld einfach nur sowas "Simples" wie Störungen oder > eine Potentialverschiebung reinfunken... Ich werde morgen das alles noch einmal durchmessen. Allerdings funktioniert es ja, wenn ich den PC direkt an den USB-Hub anschliesse; daher vermute ich schon, daß die Leitungen selbst in Ordnung sind. Gerd E. schrieb: > Der Hostcontroller muss vor Ort hin, in kurzer Entfernung zum > USB-Device. Das geht eben nicht, weil die Räume nicht für PCs geeignet sind (üble Salzwasser Atmosphäre). Möglich wäre jedoch den PC in das Rack mit dem USB-Hub zu verlegen, dann würde man sich eine Strecke und zwei Wandler sparen. Guido K. schrieb: > Ich frage mich immer, warum so viele Leute den USB mit einem LAN > verwechseln. Ich verwechsele gar nichts. :-) Wir haben auch eine Lösung über TCP/IP, aber die soll hier eben nicht verwendet werden. :-(
Svensson schrieb: > Allerdings > funktioniert es ja, wenn ich den PC direkt an den USB-Hub anschliesse; > daher vermute ich schon, daß die Leitungen selbst in Ordnung sind. Du änderst bei deinen Versuchen mehrere Parameter gleichzeitig, und Parameter A löst dein Problem, du meinst aber das es Parameter B sei -> bumm. Dein Laboraufbau muss in der exakt gleichen Konstellation sein wie im Produktivbetrieb, d.h. gleiche Kabel, gleiche Längen, gleiche Geräte. Und wenn das dann auf einem sauberen Tisch funktioniert, schön alles nebeneinander liegend, dann weißt du: dein Aufbau ist scheiße. also: Strippen in den Schrank legen, aber alles andere bleibt aus. Tut immer noch? OK, jetzt mal eine Maschine einschalten... Tut immer noch? Dann die nächste... So lange bis es nicht mehr geht. Dann weißt du: die Kabellänge ist ok, es sind die Störungen. Oder: es geht schon auf dem Tisch nicht mehr. Da sind es die hochqualitativen Adapter auf nicht vorgesehene Medien. Aber das merkst du natürlich nicht, weil du ja andere, kürzere Kabel benutzt oder die Adapter gar nicht erst verwendest. That said: Es gibt unter dem Namen VirtualHere eine Lösung, die dir zumindest zum Testen kostenlos einen USB-LAN-Adapter spendiert, wenn du irgendwo z.B. einen RPi oder ein vergleichbares Gerät (Odroid, Nanopi, Bananapi) liegen hast. Es gibt auch einen Client für Windows, und es funktioniert hinreichend gut auch mit "komischen" Geräten, und auch via WLAN. Wenn das dann funktioniert, kannst du über einen professionellen USB-Deviceserver nachdenken, z.B. von W&T https://www.wut.de/e-53www-15-inde-000.php
Jens M. schrieb: > Dein Laboraufbau muss in der exakt gleichen Konstellation sein wie im > Produktivbetrieb, d.h. gleiche Kabel, gleiche Längen, gleiche Geräte. > Und wenn das dann auf einem sauberen Tisch funktioniert, schön alles > nebeneinander liegend, dann weißt du: dein Aufbau ist scheiße. Das geht nicht, da Kat6-Kabel1 und Kabel2 fest verlegte Netzwerkverkabelung ist, die ich natürlich nicht simulieren kann. > also: Strippen in den Schrank legen, aber alles andere bleibt aus. > Tut immer noch? > OK, jetzt mal eine Maschine einschalten... Tut immer noch? > Dann die nächste... > So lange bis es nicht mehr geht. > Dann weißt du: die Kabellänge ist ok, es sind die Störungen. Auch das ist unmöglich, da es sich um eine Umgebung handelt, in der andere Maschinen immer laufen müssen. Und ja, die Umgebung ist sicherlich "störungsverseucht", denn es handelt sich nicht nur um eine Art Industriegebiet, sondern wir selbst haben noch jede Menge Technik. Die Geräte von WuT wären sicherlich ganz interessant, aber das wäre dann keine Plug'n'Play-Lösung mehr...
Svensson schrieb: > Ich hatte vermutet, daß die Wandler jeweils auch "Hubs" darstellen. Ist es denn so?
Svensson schrieb: >> Der Hostcontroller muss vor Ort hin, in kurzer Entfernung zum >> USB-Device. > > Das geht eben nicht, weil die Räume nicht für PCs geeignet sind (üble > Salzwasser Atmosphäre). Der USB-Hostcontroller muss eben nicht im PC selbst eingebaut sein. Siehe die Netzwerklösung von Frank oder die PCIe-over-Fiber-Lösung von mir oben. Der USB-Hostcontroller muss aber nah beim USB-Device sein wenn es zuverlässig sein soll.
Welche USB CAT Wandler setzt ihr ein? Da gibt's massive Unterschiede. Sehr gut aber teuer sind die von Icron. Lindy ist eher so lala, NewNex klappt auch gut. Neulich haben wir mal den AV Access U3EX100 gekauft, geht auch erstaunlich gut. Der ganze billige Kram für unter 150€ taugt eigentlich gar nix. USB Netzwerk Server geht auch mit dem Raspi, je nach Endgerät kann das gut klappen.
Svensson schrieb: > Das geht nicht, da Kat6-Kabel1 und Kabel2 fest verlegte > Netzwerkverkabelung ist, die ich natürlich nicht simulieren kann. Tja, dann nicht. Dann bleibt der Versuch kaputt und du musst damit leben. Vielleicht sind die Kabel auch im Eimer, angebohrt oder geknickt. Svensson schrieb: > Auch das ist unmöglich, da es sich um eine Umgebung handelt, in der > andere Maschinen immer laufen müssen. Keine Pause, keine "Das muss aber jetzt mal sein"? Tja, dann ist der Versuch kaputt. Du brauchst teurere vernünftige Hardware mit Support, und die werden dir bei Problemen ähnliches sagen... Svensson schrieb: > Die Geräte von WuT wären sicherlich ganz interessant, aber das wäre dann > keine Plug'n'Play-Lösung mehr... Wenn "den Treiber auf dem PC installieren" zu viel ist: tja, dann bleibt der Versuch kaputt. Ändere deinen Aufbau.... Du bist wie meine Katze: die kommt auch an und will gekrault werden, aber nicht das man sie anfasst.
Christian R. schrieb: > Welche USB CAT Wandler setzt ihr ein? Wie oben geschrieben den Digitus 70141. > USB Netzwerk Server geht auch mit dem Raspi Solche Lösung kommt nicht in Frage. Dann wäre es schon schlauer das bestehende TCP/IP-Meßssystem für die neuen Sensoren anzupassen (Prototyp gibt es bereits dafür). Aber genau das war ja nicht gewünscht, es sollte eine gekaufte Lösung sein.
Svensson schrieb: > Solche Lösung kommt nicht in Frage. Dann sind die Rahmenbedingungen so idiotisch, daß das Problem nicht lösbar ist.
Svensson schrieb: > Wie oben geschrieben den Digitus 70141. Hab ich dann wohl überlesen. Aus Erfahrung mit ähnlichen Preisklassen: Viel Glück!
Svensson schrieb: > Digitus 70141. hatte ich über bestimmt 2 Jahre im Einsatz. Devices waren USB-seriell Wandler, Host erst ein Raspi4, später ein Dell Wyse 5070. Dazwischen ca. 20m Cat7. Ergebnis: Am Raspi ging die Verbindung alle paar Tage verloren (brauchte dann einen reboot, den ich halt automatisiert habe). Am Dell später das gleiche alle paar Wochen. Fazit: Außerhalb von unwichtigen Hobby-Basteleien vollkommen ungeeignet. Jetzt hängt da vor Ort ein ESP32 mit LAN und der läuft quasi jahrelang durch.
Tja, wenn die Aufgabenstellung ist etwas zu machen, das nicht funktionieren kann, dann ist das halt so. Fazit ist: Es funktioniert so gut, wie die Vorgaben es erlauben.
Ist Glasfaser USB keine Alternative? Edit: wurde schon genannt.
:
Bearbeitet durch User
USB 2.0 über Glasfaser geht zwar prinzipiell (haben hier Icron und Unibrain Erfahrung), aber ist auch nicht besser als CAT Kabel. Problem an 2.0 ist die bidirektionale Datenübertragung. Für eine zuverlässige Extension muss das Protokoll aufgedröselt werden. Daher spielen die Dinger Hub, und physisch ist der Hub dann geteilt, dazwischen halt CAT oder Faser. Aber selbst beim teuren Icron ist das nicht 100% stabil. Was hingegen nahezu problemlos geht, ist USB 3 über Glasfaser, denn da hat man für TX und RX getrennte Leitungspaare, das geht dann völlig ohne Protokoll-Schweinerein. Es gab mal einen teuren Icron, der hatte auf Host Seite nur USB 3 und am Remote Hub dann einen Transaction Translator. Das hatte auch gut funktioniert. Aber die haben ja kaum noch was im Angebot.
Christian R. schrieb: > USB 2.0 über Glasfaser geht zwar prinzipiell (haben hier Icron und > Unibrain Erfahrung), aber ist auch nicht besser als CAT Kabel. Problem > an 2.0 ist die bidirektionale Datenübertragung. Für eine zuverlässige > Extension muss das Protokoll aufgedröselt werden. Daher spielen die > Dinger Hub, und physisch ist der Hub dann geteilt, dazwischen halt CAT > oder Faser. Aber selbst beim teuren Icron ist das nicht 100% stabil. Neben den Protokollumsetzungen ist das Problem die Signallaufzeit. USB ist für lange Signallaufzeiten einfach nicht gedacht. Das merkt man dann schnell an der Stabilität. > Was hingegen nahezu problemlos geht, ist USB 3 über Glasfaser, denn da > hat man für TX und RX getrennte Leitungspaare, das geht dann völlig ohne > Protokoll-Schweinerein. Nein, auch bei USB 3 SS kommst Du sehr schnell an die maximal erlaubten Antwortzeiten heran und darüber. Da ist zwar zwischen den Vorgaben aus dem Standard und dem, was die Implementation dann in der Praxis macht oft noch genug Luft, aber eng ists trotzdem. Die einzig wirklich saubere Lösung ist PCIe über Glasfaser laufen zu lassen und dann nah beim USB-Device einen USB-Hostcontroller aufzustellen. PCIe ist was die Laufzeiten angeht ganz entspannt und daher wird das so dann zuverlässig. Nachteil ist halt dass Du das auf der Seite des PCs nicht in eine USB-Buchse stecken kannst, sondern einen PCIe-Slot für brauchst. Fertiges Produkt was das so umsetzt siehe oben. Für Selbstbau-Variante siehe https://www.youtube.com/watch?v=XaDa9bBucEI , ist aber wohl noch nicht fertig.
:
Bearbeitet durch User
Svensson schrieb: > Das geht nicht, da Kat6-Kabel1 und Kabel2 fest verlegte > Netzwerkverkabelung ist, die ich natürlich nicht simulieren kann. Der Verkauf von Netzwerkkabel auf Kabeltrommeln ist mittlerweile eingestellt? Oh Moment, nein, die gibt es immer noch https://www.kabelscheune.de/Kabeltrommeln/Netzwerk-Kabeltrommel-Cat-6a-Verlaengerungskabel-60-m.html Ich war schon kurz verwirrt. Von echten Simulatoren reden wir jetzt mal nicht. Da kann einem bei den Preisen schon mal schwindelig werden. Wobei, passive "Simulatoren" müsste es schon für ein paar Hundert Euro geben. Aber ich vermute mal, dass ist schon viel zu teuer. Obwohl ich mich schon frage warum man in einer Umgebung mit offensichtlich Mission-Critical Maschinen die 24/7 laufen müssen mit USB-Basteleien anfängt. > Auch das ist unmöglich, da es sich um eine Umgebung handelt, in der > andere Maschinen immer laufen müssen. Jetzt mal Butter bei die Fische. Stammt die Idee von dir und du hast dich zu weit aus dem Fenster gelehnt? Dann ist es vielleicht Zeit den Gang nach Canossa anzutreten. Oder kommt die von so einem Super-Schlauen? Dann wird es Zeit das Problem zurück zur Quelle zu schieben.
So, ein weiterer Zwischenstand. Die Netzwerk-Verkabelung ist okay. Die Kabellängen betragen 15, 20.3 und 30 Meter. Gerd E. schrieb: > Die einzig wirklich saubere Lösung ist PCIe über Glasfaser laufen zu > lassen und dann nah beim USB-Device einen USB-Hostcontroller > aufzustellen. Nette Idee, aber dann müßten Glasfasern neu gezogen werden - ein extrem großer Aufwand. Deshalb gab es ja die Idee, das bestehende Kat.6-Netzwerk zu nutzen. Hannes J. schrieb: > Stammt die Idee von dir und du hast > dich zu weit aus dem Fenster gelehnt? > Oder kommt die von so einem Super-Schlauen? Nein, das war nicht meine Idee. Ich hatte von Anfang an Bedenken, weil ich weiß, daß USB gerne einmal "zickig" ist. Und ja, die zu verwendenden Meßgeräte wurden von "oben" vorgegeben. Und natürlich sollte es schnell gehen und möglichst nichts kosten. Aber, was soll ich sagen. Ich habe den PC in die Netzwerkzentrale verlegt, so daß er direkt mit dem USB-HUB verbunden ist - und es läuft jetzt. Das Schema sieht jetzt so aus: PC <-> USB-Kabel-1m <-> USB-Hub <-> USB/Kat6-Wandler <-> Kat6-Netzwerk <-> Kat6/USB-Wandler <-> USB-Kabel-1m <-> Meßgerät Jetzt ist das Ganze erst einmal im Testbetrieb. Schaun 'mer 'mal. Gerd E. schrieb: > Neben den Protokollumsetzungen ist das Problem die Signallaufzeit. USB > ist für lange Signallaufzeiten einfach nicht gedacht. Das merkt man dann > schnell an der Stabilität. Das vermute ich auch. Ich hatte ursprünglich gedacht, daß vielleicht nur die Spannungspegel angehoben werden und vielleicht mit differentiellen Spannungen gearbeitet würde, um Potentialverschiebungen zu umschiffen, aber anscheinend gibt es doch Protokollumsetzungen, die natürlich eine gewisse Laufzeitverlängerung bedingen, selbst wenn da schnelle ASICs im Einsatz sind. Zwei solcher Umsetzungen sind dann ganz offenbar zu viel Verzögerung. Wenn es tatsächlich an der Signallaufzeit liegen sollte, dann wäre die Glasfaser auch nicht besser, da die Lichtgeschwindigkeit eine Konstante ist.
Hannes J. schrieb: > Obwohl ich mich > schon frage warum man in einer Umgebung mit offensichtlich > Mission-Critical Maschinen die 24/7 laufen müssen mit USB-Basteleien > anfängt. Das ist eine Fehlinterpretation. Ich habe gesagt, daß es in der unmittelbaren Umgebung Maschinen gibt, die 24/7 laufen bzw. auf deren Betrieb ich keinen Einfluß habe. Und selbst, wenn unsere Anlagen 24/7 laufen (was sie tatsächlich tun) so gibt es immer Teile, die kritisch sind und solche Teile, die es eben nicht sind. Zur Steuerung von kritischen Teilen würde ich wohl kein USB einsetzen, wenn sich das irgendwie vermeiden ließe. Und bei dem hier geschilderten Problem handelt es sich um zusätzliche "nice-to-have-Technik" zur Kontrolle/Dokumentation/was-weiß-denn-ich.
Nach dem Überfliegen des Threads hätte ich noch eine ganz simple Frage. Bekommen die Messsensoren auch über USB ihre Versorgungsspannung geliefert?
Svensson schrieb: > da die Lichtgeschwindigkeit eine Konstante ist. Fast, aber im Medium ist die Lichtgeschwindigkeit dann doch kleiner als im Vakuum. ;)
Dieter D. schrieb: > Nach dem Überfliegen des Threads hätte ich noch eine ganz simple Frage. > Bekommen die Messsensoren auch über USB ihre Versorgungsspannung > geliefert? Ja, das tun sie. Deshalb habe ich bei den Umwandlerpaaren darauf geachtet solche zu nehmen, deren Empfänger über externe Netzteile mit Strom versorgt werden, so daß sie auch USB-powered-Geräte betreiben können. Die Sender (die Begrifflichkeiten sind etwas irreführend, da USB natürlich bidirektional ist) werden vom USB-HUB mit Strom versorgt. Glücklicherweise ist das alles so konstruiert, daß alles mit der geringen Leistung von Standard-USB auskommt (die Netzteile haben 5V/1A).
Svensson schrieb: > Empfänger über externe Netzteile mit Strom versorgt werden Ah, da hatte ich nicht richtig hingeschaut. Meine (negativen) Erfahrungen bezogen sich auf die einfachere Variante von Digitus, die auch nur USB1.1 überträgt.
Moin, ich vermute mal, dass wir hier ein Problem des Massepotentials haben. Netzwerkkabel legen gerne den Schirm auf beiden Seiten auf. Damit erhalten wir eine große Brummschleife. Deshalb geht es im Labor, aber in der Praxis nicht. Das gleiche Problem kenne ich aus der Praxis mit RS232, CAN und purem Ethernet. Wahrscheinlich sind alle Netzgeräte einfache, ungeerdete Steckernetzteile, oder? Vielleicht sollten wir mal in diese Richtung diskutieren. Gruß Olaf
Moin, > ungeerdete Steckernetzteile Jepp, sind naturlich Steckernetzteile ohne Erdung. Auf Grund der geringen Baugröße werden das wohl SNT sein. Auch der 19" HUB hat ein Steckernetzteil, dessen Bauform ist zwar größer, aber ich meine auch da gab es keinen PE. > Netzwerkkabel legen gerne den Schirm auf beiden Seiten auf. Das hat zwar eine Fachfirma gebaut, aber ich gehe auch davon aus. Die 19" Racks sind ohnehin geerdet, ebenso die Kabeltrassen. In diesem Fall sitzen die Netzwerkdosen aber in "Brüstungskanälen" aus Edelstahl, die vermutlich auch geerdet sind. Sofern also die Trägerplatte der Netzwerkdosen irgendwie an das Metall der Kanäle kommt, dann dürfte der Schirm auf beiden Seiten auf PE liegen. Ich denke aber, das sollte kein Problem sein, da bei der Übertragung vermutlich nur die TP-Adern benutzt werden und auf beiden Seiten GND nicht mit PE verbunden ist. Die Meßgeräte sind vollständig in Kunstoff gehüllt und werden rein über USB mit Strom versorgt. Ich vermute tatsächlich eine Art "Timeout-Problem" auf der USB-Verbindung, denn der PC erkennt schon, daß man da irgendwelche USB-Geräte anschließt, kann sie aber nicht richtig erkennen und entfernt sie dann wieder. Das Spielchen wiederholt sich dann alle paar Sekunden.
Svensson schrieb: > Wenn es tatsächlich an der Signallaufzeit liegen sollte, dann wäre die > Glasfaser auch nicht besser, da die Lichtgeschwindigkeit eine Konstante > ist. Es liegt daran, dass die Daten "umgepackt" werden müssen, damit man sie über die lange Strecke transportieren kann. Dazu muss auf der Seite des Rechners die Zauberbüchse erst mal das Datenpaket entgegen nehmen, dann umpacken, über die lange Leitung schicken, die zweite Zauberbüchse packt es wieder aus und schickt es an das Gerät weiter. Doof dabei ist, dass das Gerät aber gleich in den Bitzellen nach dem Datenpaket die Bestätigung schicken muss, da gibt es keinen Mechanismus, mit dem signalisiert werden kann, dass das Gerät grade noch nachdenkt. Der ACK wird in Hardware erzeugt und erfolgt sofort. Darum versuchen die Zauberbüchsen oft solche Dinge wie auf einer Seite so zu tun, als ob sie das Gerät wären und auf der anderen Seite so zu tun, als ob sie der Host wären. Und das geht dann ganz häufig in die Hose. Darum benutzt man solchen Krempel nicht.
Nachdem ich die lange Lyrik überflogen habe, stellt sich mir die grundsätzliche, einfache Frage: Hat es im Probeaufbau ALLES zusammengesteckt schon mal funktioniert? J/N? Dann wird es weniger an der Laufzeit liegen, sondern eher an Massproblemen und Störeinstrahlungen, wenn dieselben Kabel dann draußen nicht funktionieren. Ein kurzes Kabel als Test reicht nicht! Ansonsten wird die Analyse natürlich mühsamer.
:
Bearbeitet durch User
Svensson schrieb: > Aber, was soll ich sagen. Ich habe den PC in die Netzwerkzentrale > verlegt, so daß er direkt mit dem USB-HUB verbunden ist - und es läuft > jetzt. Das Schema sieht jetzt so aus: > > PC <-> USB-Kabel-1m <-> USB-Hub <-> USB/Kat6-Wandler <-> Kat6-Netzwerk > <-> Kat6/USB-Wandler <-> USB-Kabel-1m <-> Meßgerät > > Jetzt ist das Ganze erst einmal im Testbetrieb. Schaun 'mer 'mal. Warten wir ab, was bei dem Test heraus kommt. Nie wieder Messgeräte mit USB, ich verwende selbst Privat nur Geräte mit entweder Ethernet oder einen Ethernet/IEEE488 Adapter. Es heiß ja nicht um Sonst USBääh ;P Bei ca 40 angeschlossenen Messgeräten ist USB eine Schlacht aus HUBs und Ethernet so viel praktischer. Abgesehen davon kann man mit dem Ethernet Setup auch mit dem Notebook auf dem Schoß in der Sonne sitzen und seinen Code entwickeln oder Versuche fahren, ohne an den Labortisch gefesselt zu sein. Ich drücke für den Versuch die Daumen und würde mich über Rückmeldung freuen, ob es denn zuverlässig funktioniert.
> Nachdem ich die lange Lyrik überflogen habe Schreibt man knapp, dann wird genörgelt, daß es Salamitaktik wäre; schreibt man ausführlich, dann ist es auch nicht allen recht... Lu schrieb: > Hat es im Probeaufbau ALLES > zusammengesteckt schon mal funktioniert? J/N? Ja, hat es. Allerdings waren es - naturgemäß - kurze Patchkabel statt langer Verlegekabel, deren Norm ich erst einmal nachsehen müßte. Und es funktioniert mit der geänderten Version auch in der Praxis. Ulrich schrieb: > Nie wieder Messgeräte mit USB, ich verwende selbst Privat nur Geräte mit > entweder Ethernet oder einen Ethernet/IEEE488 Adapter. Es heiß ja nicht > um Sonst USBääh ;P Hier waren die Meßgeräte bereits vorgegeben. Und leider haben heute sehr viele - auch teure - Meßgeräte nur noch eine USB-Schnttstelle. Das gilt gerade auch für viele Labormeßgeräte, da hat man dann keine Wahl. Es sind hier auch keine 40 Meßgeräte, sondern vermutlich nur 8 mit dann jeweils 8 Sensoren, also 64 Sensoren. Ansonsten bevorzuge ich auch eine Lösung über TCP/IP, weil das einfach besser räumlich skaliert und letztlich sogar auch preiswerter ist, weil es eine Netzwerkverkabelung fast überall gibt. Wir haben/hatten auch schon analoges Telefon, Video und sogar analoge Signale über das Kat6 transportiert, weil das Kat5/6/7 Kabel in den meisten Fällen viel günstiger ist als irgendwelche anderen (Steuer-)Kabelvarianten. Ulrich schrieb: > Ich drücke für den Versuch die Daumen und würde mich über Rückmeldung > freuen, ob es denn zuverlässig funktioniert. Mache ich, denn ein Forum dient schließlich zum Informationsaustausch. Und vielleicht benötigt irgendjemand noch einmal so eine Lösung.
Svensson schrieb: > Es sind hier auch keine 40 Meßgeräte, sondern vermutlich nur 8 mit dann > jeweils 8 Sensoren, also 64 Sensoren. Und wie weit sind die einzelnen Messgeräte voneinander entfernt?
Sicher, ich habe da eine völlig andere Konfiguration, das gebe ich zu. Bei mir sind die "Sensoren" im Umkreis der Tischplatte gebunden und daher ist die Verkabelung theoretisch auch per USB problemlos möglich. Wenn ich aber lese, in was für einer Umgebung Eure Messgeräte stehen, dann frage ich mich, ob man nicht besser Sensoren mit einem entsprechenden industriellen Bus genommen hätte und deren Messauswertung an einer anderen Stelle vorgenommen hätte... Aber ja, hätte hätte Fahrradkette, der Vertrieb hatte schon zugesagt, der Einkauf schon bestellt und die Entwicklung muss nun sehen, wie man das verklöppelt. Ich kenn's, ich kenn's ;) Danke, für die Rückmeldung, dass es nun geht.
Das Problem ist nicht USB, sondern die falsche Verwendung. Ist so, als wenn man mit einer Zange eine Schraube in eine Betonwand schlagen will und sich dann beschwert, dass die Schraube nichts taugt.
Ulrich schrieb: > Wenn ich aber lese, in was für einer Umgebung Eure Messgeräte stehen, > dann frage ich mich, ob man nicht besser Sensoren mit einem > entsprechenden industriellen Bus genommen hätte und deren Messauswertung > an einer anderen Stelle vorgenommen hätte... Die Auswertung erfolgt auch jetzt in einem der beiden halbwegs "normalen" Räume, deshalb ja die langen Leitungen. Nun bei dem anderen Meßsystem waren wohl die Sensoren das Problem. Angeblich IP68 und aus V2A-Edelstahl. Nach massiver Korrosion und anscheinend Wassereintritt (= zahlreiche Ausfälle) hat der Hersteller das geändert auf IP66 und "Edelstahl". Tja, das ist dann "Made in Germany" und führt zu langen Gesichtern... Ich kann mir das eigentlich nur so erklären, daß es zu so einem Vertrauensverlust geführt hat, daß man sich dem anderen System, das man schon kannte und das nachweislich funktioniert (wenn auch anders eingesetzt) zugewandt hat.
Svensson schrieb: > Nun bei dem anderen Meßsystem waren wohl die Sensoren das Problem. > Angeblich IP68 und aus V2A-Edelstahl. Nach massiver Korrosion und > anscheinend Wassereintritt (= zahlreiche Ausfälle) hat der Hersteller Aus meiner Marinezeit und auch durch meine Arbeit bei einem großen Schaltschrankhersteller weiß ich, bei Salzwasser rostet sogar Plastik. V2A ist da nicht genug, es muss V4A sein. Und selbst V4A hält nicht ewig. Selbst im heimischen Pool ist V2A keine dauerhafte Lösung, wenn Chlor im Spiel ist.
Falls es Masseprobleme sind, würde ich versuchsweise einen USB Isolator einsetzen. Wenns nachher funktioniert, war es ein Masseproblem.
Ulrich schrieb: > V2A ist da nicht genug, es muss V4A sein Ja, das ist richtig. V2A hält nur eine begrenzte Zeit, die hier aber ausgereicht hätte. Leider hat sich die "Edelstahlhülle" - vermutlich des Zuliefers aus Fernost - als Stahlqualität unterhalb von V2A entpuppt. Und offenbar haben alle Sensorhersteller den gleichen Zulieferer...
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.