ich habe manchmal Übertragungsprobleme mit einem RS485-USB-Stick. Bisher habe ich den Raspi aus- und eingeschaltet. ich möchte das etwas automatisieren.
Dazu habe ich das Programm uhubctl gefunden. Dies gibt als Hubs dies aus:
Wie komme ich jetzt von diesem Pfad auf den Hub 1-1.1, welches ich beim Abschalten ("uhubctl -a off -l 1-1.1 -p 4") angebe?
Nach -usb- kommen nur zwei Einsen vor. Ist die erste Zahl nach -usb- noch um eins zu erhöhen?
ich habe manchmal Übertragungsprobleme mit einem RS485-USB-Stick.
Bevor ich so ein Problem mit aus- und wieder einschalten, egal wie automatisiert, anfange zu umschiffen, würde ich erst mal schauen ob man da nicht besser an der Wurzel ansetzen kann.
Wie äußern sich die Probleme genau?
Ist die Übertragung auf USB-Ebene gestört oder auf RS485-Ebene? Oder ist das noch nicht so ganz eindeutig?
Was siehst Du im Moment der Probleme im syslog/messages/systemd-journal?
ich habe manchmal Übertragungsprobleme mit einem RS485-USB-Stick.
Bevor ich so ein Problem mit aus- und wieder einschalten, egal wie
automatisiert, anfange zu umschiffen, würde ich erst mal schauen ob man
da nicht besser an der Wurzel ansetzen kann.
...
Mit der Fehlersuche kann man viel Zeit verbringen, ohne am Ende schlauer
zu sein.
Es würde ja evtl. schon reichen, den zugehörigen Treiber einmal zu
entladen, etwas zu warten, und dann den Treiber wieder neu zu laden.
Bei einem Linux sollte das ein rmmod/insmod bewerkstelligen.
Beim Windows tut es ein devcon restart...
Hier treten solche Probleme ganz typisch dann auf, wenn eine
Applikation "A" das Gerät benutzt hat, beendet wird, und anschliessend
sofort von Applikation "B" benutzt werden soll.
Es kann sicher auch nicht schaden, mal einen anderen USB-Hub zu
probieren, oder direkt an den Root-Hub anzuschliessen.
Ein Pi4 oder Pi5 hat mehr als genug echte UARTs. Die darf man auch benutzen und hat damit in einem Schritt auch USB als Fehlerquelle komplett eliminiert. Idealerweise nimmt man dafür nicht UART0 (GPIO14/15) und auch nicht den Mini-UART UART1 beim Pi4, sondern einen der anderen UARTs.
Wie äußern sich die Probleme genau?
Ist die Übertragung auf USB-Ebene gestört oder auf RS485-Ebene? Oder ist
das noch nicht so ganz eindeutig?
Bei der betroffenen Leitung geht es um die Abfrage der Akkus von Pylontech, es sind 4 Stück, alle mit eigener Adresse die nacheinander abgefragt werden. Immer mal wieder liefert ein Akku keine Daten, und manchmal auch alle 4 nicht. Dann hilft der Neustart des USB-Sticks.
Was siehst Du im Moment der Probleme im syslog/messages/systemd-journal?
Keine Daten im Log, es kommt einfach keine Antwort auf die Abfrage.
Ein Pi4 oder Pi5 hat mehr als genug echte UARTs. Die darf man auch
benutzen und hat damit in einem Schritt auch USB als Fehlerquelle
Bei dem Preis der RS485-USB-Sticks baue ich keine RS485-Wandler mehr selbst. Außerdem brauche ich einige (insgesamt 6) isolierte RS485/RS232-Anbindungen. Jedes Gerät hat ein anderes Protokoll oder andere Geschwindigkeit.
Ein Pi4 oder Pi5 hat mehr als genug echte UARTs. Die darf man auch
benutzen
Aber welche davon kann einen RS485-Treiber ansteuern? Willst Du das etwa in Software mit einer GPIO-Leitung machen?
Im Raspberry Pi gibt es UARTs vom Typ PL011, die sind 16550-kompatibel. Und die haben keine Hardwareunterstützung, um RS48-Treiber anzusteuern (Sender-/Empfängerumschaltung)
Vernünftige UARTs können das in Hardware, und zu den vernünftigen UARTs gehört die im FT232.
Der Threadstarter könnte versuchen, statt den USB-Hub zurückzusetzen, nur den (namenlosen) USB-RS485-Adapter zurückzusetzen - das geht genauso mit usbctl.
Ein Pi4 oder Pi5 hat mehr als genug echte UARTs. Die darf man auch
benutzen
Aber welche davon kann einen RS485-Treiber ansteuern? Willst Du das etwa
in Software mit einer GPIO-Leitung machen?
Im Raspberry Pi gibt es UARTs vom Typ PL011, die sind 16550-kompatibel.
Und die haben keine Hardwareunterstützung, um RS48-Treiber anzusteuern
(Sender-/Empfängerumschaltung)
Der Raspi ist über einen USB-Isolator mit den Hub Verbunden, die Raspis
sind mir z.Z. zu teuer um den ersetzen zu müssen.
Frank K. schrieb:
Ein Pi4 oder Pi5 hat mehr als genug echte UARTs. Die darf man auch
benutzen und hat damit in einem Schritt auch USB als Fehlerquelle
Bei dem Preis der RS485-USB-Sticks baue ich keine RS485-Wandler mehr
selbst. Außerdem brauche ich einige (insgesamt 6) isolierte
RS485/RS232-Anbindungen. Jedes Gerät hat ein anderes Protokoll oder
andere Geschwindigkeit.
Heißt also: die einzelnen Busse sind untereinander nicht potentialgetrennt. Das ist unklug und könnte Ursache des Problems sein. Besser wäre es, die Isolation zwischen UART und Transceiver zu setzen oder gleich einen isolierten Transceiver wie den ADM2861E zu verwenden.
https://www.analog.com/en/products/ADM2861E.html
Im übrigen hoffe ich, dass Du nicht nur das differentielle Adernpaar, sondern auch GND durchverbunden hast.
Hast Du auch Failsafe-Widerstände an deinen Bussen?
Einfach nur den USB-Adaper zu resetten ist Pfusch. Wenn das ganze regelmäßig aussteigt, ist da was faul, und Du solltest die Ursache beheben. Das kann auch heißen, dass Du zu billig gekauft hast und Deine USB-RS485-Adapter Mist sind ("waren ja günstig"), oder dass die Verdrahtung nicht regelkonform ist.
Der Threadstarter könnte versuchen, statt den USB-Hub zurückzusetzen,
nur den (namenlosen) USB-RS485-Adapter zurückzusetzen - das geht genauso
mit usbctl.
Ein 18 Jahres altes Programm zu selbst zu übersetzen?
Immer mal wieder liefert ein Akku keine Daten, und
manchmal auch alle 4 nicht. Dann hilft der Neustart des USB-Sticks.
Da ist etwas faul mit der Hardware und der Neustart ist nur ein schlechter Workaround.
2 Punkte könnte ich mir vorstellen:
gefälschte USB-UART-Wandler. Die Prolific PL2303 sind berüchtigt dafür dass es fast nur Fälschungen auf dem Markt gibt. Prolific hat dann irgendwann den Windows-Treiber für alle alten Modelle geblockt, sowohl Fälschungen als auch echte. Ich habs nicht mehr 100% im Kopf, aber ich glaube die PID 0x2303 waren die alten mit den vielen Fälschungen und die neuen sind 0x23A3. Unter Linux hast Du natürlich kein Problem mit den Treibern. Aber die Fälschungen machen dennoch gerne Ärger durch Aussetzer und Übertragungsprobleme.
Common-Mode-Probleme zwischen den einzelnen Adaptern. Du hast wie ich das verstehe eine galvanische Isolation zwischen Raspi und vielen Bus-Adaptern. Aber eben keine Isolation zwischen den Bussen untereinander. Und da kann es abhängig von der Anwendung und Verkabelung durchaus auch mal etwas "rumpeln" und dann stürzt ein Adapter in Folge ab. Das kann dann durchaus ein Vorbote von "brennt durch" sein, daher würde ich wenn das öfters passiert das Thema ernst nehmen und das sauber lösen.
Probier doch mal einen der Adapter neu zu kaufen in gesicherter Qualität ohne Gefahr von Fälschungen. Dann schauen ob der noch abstürzt. Wenn weiterhin, dann bei diesem einen einen separaten Isolator davor. Treten dann noch Probleme auf? Wenn nein, dann diese Lösung überall ausrollen.
