Modbus Software

[Fritzler]

Da ich Daheim immer mehr (Eigenbau) Modbusgeräte habe brauch ich auch eine kleine Software zum "mal eben" auslesen und setzen von Registern/Coils.
Eine kurze Internetrecherche ergab nix zufriedenstellendes.

Also alles muss man selber machen!

So ein Register(Satz) kann ja verschiedene Darestellungsformen haben:
- Größe (U16b/S16b/U32b/S32b/float/double)
- Startadresse
- Endianess
- LSB (ist das LSB 1 der Zahl oder zB 0,001)
- Einheit (freier String)
- Name (freier String)
- Nachkommastellen (man will sich ja nicht alle 8 Standardstellen von double aufn Bildschirm zaubern)

Jedenfalls soll das mal so aussehen:


Was ist da zu sehen?
Erstmal gibts verschiedene Tabs für:
- Modbus Einstellungen (ASCI/RTU/TCP/UDP)
- Coils
- Discrete Inputs
- Input Register
- Holding Register

Der Tab Inhalt der Register ist dargestellt.
Die Funktionen sidn recht gleich, bis auf, dass die INputregister natürlich nicht schreibbare sind.

Zunächst wird die Adresse der/des Registers angezeigt und die Endianess.
Danach kommt der eingestellte Name.
Die Rohwerte werden auch angezeigt, als HEX/DEC/OCT/CHAR.
Danach kommt die Interpretierung, die auch editierbar ist (wer hat schon das float Format im Kopf?).
Editierte Werte werden gelb dargestellt und sind rücksetzbar.

Danach kommen Buttons um ein einzelnes Register/Wertesatz zu lesen/schreiben.
Danach Tickboxes welche Register(Sätze) beim globalen R/W berücksichtigt werden sollen.

Loggen soll auch möglich sein, dazu wird angetickt was geloggt werden soll.
Ein automatischer Loginterval kann eingestellt werden, sowie ein Dateipfad um es auch per csv abzulegen.

Weiterhin sind Einträge editierbar bzw ganz löschbar.
Die ANzeigereihenfolge kann auch geändert werden, das muss ja nicht stur nach Adresse gehen.

Daher noch ein paar Fragen (deswegen schreib ich hier):
Gibts bereits ein "Industriestandard" Configformat, welches die oben genannten Einstellungen Register -> Wert definiert?
Gibts noch Anregungen was es noch braucht?
Noch ein paar GUI Empfehlungen?

------
Inzwischen ist es ja schon halbwegs fertig.
Link: https://git.fritzler-avr.de/fritzler/mo ... -/releases

[sukram]

Ich persönlich habe meine Modbus Haustechnik an einem FHEM Server hängen. Da kann ich nach Bedarf Register und Coils eintragen (Achtung off-by-one Fehler je nach Interface/Gerät) und die werden in individuellen Intervallen abgefragt und auf Wunsch in eine PostgreSQL Datenbank geko-ääh gespeichert. Web-UI, Graphenerzeugung alles schon mit drin. Und kommt bei moderaten Abfrageintervallen auch mit sehr wenig Ressourcen aus.

[Fritzler]

Ja, das nutzt man dann wenn alles läuft.

Aber man will ja auch mal während der Softwareentwicklung auf dem Modbusgerät was senden/lesen.
Bzw direkt nen Graphen von was sehen ohne gleich was in eine DB zu schieben.
Dafür soll diese Software sein.

Eine weitere Modbus Software ist soeben fertig geworden.
Ein Bootloader für STM32 über Modbus.



Der Bootloader und die Firmware nutzen die gleichen EEPROM/Flash Zellen für die Modbusconfig.
Sonst gehts ja nicht

Der Bootloader läd aus welche alte SW drauf läuft.
Weiterhin weis er auch auf welcher CPU er läuft und kommuniziert das über Modbus.
Auf PC Seite kann dann aus der elf ausgelesen werden für welche CPU das ist (sonst läufts ja ned) und ob die Pointer/größen stimmen.

[Hightech]

Das kennst du?
https://pymodbus.readthedocs.io/en/late ... /REPL.html

[Stefan]

Mit PyQt könnte man eine GUI drüberlegen und dein MB-Bootloader als Modul laden. Sehr schick übrigens!

[j.o.e]

Gibts bereits ein "Industriestandard" Configformat, welches die oben genannten Einstellungen Register -> Wert definiert?

Ich denke, XML oder JSON könntest Dir mal ansehen.
Meist bastle ich mir aber was zusammen und merke dann am Schluss, wie blöd ich war und dass ich's besser gleich 'richtig' gemacht hätte ...

[Fritzler]

Das kennst du?
https://pymodbus.readthedocs.io/en/late ... /REPL.html

pymodbus wird ja schon unter der Haube genutzt.
Das im Link ist also quasi nochn TUI drüber?
Scheint aber nciht alle Einstellungen zu haben, die ich so will.

Mit PyQt

Aus irgendwelchen Gründen hab ich bisher pyTK genutzt und umlernen will ich jetzt nicht nochmal.
Oder sprechen da jetz riesengroße Gründe dafür?

Ich denke, XML oder JSON könntest Dir mal ansehen.

Das ist nur das Format, mir gehts um die Inhaltsdefinition.
Bisher wollt ich yaml nutzen, btw.

[nero]

Simply Modbus
Ablaufsteuerungen mit pymodbus

Aber wie dus gemacht hast is natürlich stilechter.

[Stefan]

Nicht das ich wüsste. Persönlich finde ich die Guis von PyQt deutlich schicker als die von tk. Für QT gibt es auch den qt designer, damit kann man programmiersprachenunabhängig eine GUI beschreiben. Letzteres kann man dann z.B. unter C/C++/PyQT einbinden.

[m3rt0n]

Ich hab die Tage unserem Werksstudenten über die Schulter geschaut und wurde gleich mit ner Frage zu Modbus gefangen für 1-2 Stunden.
Auf ner Siemens S7-1500...warum tut man sich das freiwillig an?
Dazu kam dass er mit Programmbausteinen von ner externen Firma arbeiten musste, die hatte unteranderem als Übergabeschnittstelle ein array of 46000 word. Nein, kein Schreibfehler...
Hat das was mit der maximalen Datenmenge zu tun die bei maximaler Slavezahl zusammen kommen kann?

[Fritzler]

Nicht das ich wüsste. Persönlich finde ich die Guis von PyQt deutlich schicker als die von tk. Für QT gibt es auch den qt designer, damit kann man programmiersprachenunabhängig eine GUI beschreiben. Letzteres kann man dann z.B. unter C/C++/PyQT einbinden.

Hab mal eben nachgesehen, das holt sich mehr OS style rein, das sieht dann wie Win7 aus und nicht nach Gnome2

Ich hab die Tage unserem Werksstudenten über die Schulter geschaut und wurde gleich mit ner Frage zu Modbus gefangen für 1-2 Stunden.
Auf ner Siemens S7-1500...warum tut man sich das freiwillig an?

Welche Studienrichtung denn?
Warum man sich Miesens antut weis ich aber auch nicht, geht der auch Abends gerne ins SM Studio?

Dazu kam dass er mit Programmbausteinen von ner externen Firma arbeiten musste, die hatte unteranderem als Übergabeschnittstelle ein array of 46000 word. Nein, kein Schreibfehler...
Hat das was mit der maximalen Datenmenge zu tun die bei maximaler Slavezahl zusammen kommen kann?

Da könnt ich mir vorstellen, dass dies die Werte für Holding/Inputregister sind.
Allerdings direkt einmal reingekotzt und veränderbar, hä?
Meine Modbus slave lib auf dem STM32 arbeitet mit Callbacks.
Eigentlich könnt ich die mal veröffentlichen.
Die ist aber in C++, dafür sehr modular, da lässt sich schnell ein anderer UART ranknüppern.

[Fritzler]

Ich überlege ja grade ob ich links noch ein Treeview hinpacke, damit mehrere Geräte ladbar sind.
Dann muss man nicht mit dem load config Button die ganze Zeit rumspielen.

Die Idee weiter oben, das Bootloaderfrontend mit reinzunehmen, wird auch gemacht.
Das kommt dann als Extratab rein.
Warum sollte das auch weiterhin eine Extrasoftware sein.

edit:
Da hab ich mal ein öffentliches Repo auf meinem Gitlab erstellt falls mir wer nachspionieren möchte
https://git.fritzler-avr.de/fritzler/modbus-software

[m3rt0n]

Welche Studienrichtung denn?
Warum man sich Miesens antut weis ich aber auch nicht, geht der auch Abends gerne ins SM Studio?

Miesens ist halt immer noch DER Industriestandard weil die meisten Kunden das wollen oder weil der einzige "Programmierer" Horst vom Kunden gerade mal damit umgehen kann, andere Steuerungen kennen die nicht.

Keine Ahnung, wir haben laufend irgendwelche Inder die irgend nen Kram prorgammieren und testen, studiert wohl in Würzburg.
Er ist aber auch ein bisschen eine arme Sau weil er angefangenes und extern programmiertes zusammenführen und ergänzen darf.

Die eigentliche Problemstellung weswegen ich da mit dran saß war, dass er innerhalb des Arrays auf ein word pointern müsste um die Schnittstelle so zu verwenden wie angedacht, das ist aber offensichtlich bei Siemens unmöglich oder liegt weit außerhalb meines Wissens im TIA. Startadresse des arrays geht. Er hats dann mit einem zusätzlichen move- befehl in den Adressbereich geschoben, nicht schön aber funktioniert.

[Fritzler]

Da bräucht ich mal noch ne kleine Namensabgrenzungsidee.

Die Software wird haben:
Workspacedatei, diese enthält Einstellungen zum Loggen und welche Geräte (Devices) in den Baum gehängt wurden.
Eine "Device"datei enthält die Modbuseinstellungen (wie IP/RTU Einstellungen) sowie eine Registerconfig.
Das kann ich aber nicht Registerconfig nennen, wils auch Coils und Discrete Inputs gibt, Devicefile ist auch schon vergeben.
Da komm ich grade auf keinen ordentlichen englischen Namen.
Hat da wer ne Idee?

Er ist aber auch ein bisschen eine arme Sau weil er angefangenes und extern programmiertes zusammenführen und ergänzen darf.

Bei sonem Ranz würd ichs aber wegwerfen und selber neumachen, das geht schneller
Als ein Kollege indischen Modbuscode reparieren sollte hab ich ihm auch mal ganz leise meinen Modbus C++ Code aufs Netzlaufwerk geschoben

dass er innerhalb des Arrays auf ein word pointern müsste um die Schnittstelle so zu verwenden wie angedacht, das ist aber offensichtlich bei Siemens unmöglich oder liegt weit außerhalb meines Wissens im TIA.

TIA?
Irgendwas böses properitäres was nix kann und einen einschränkt?
Wenn ich sowas machen müsste würd ich direkt kündigen

[sukram]

Registerconfig - Device Setup?

TIA ist die allein glücklichmachende Universallösung für Probleme, die man ohne Siemens nie gehabt hätte. Kurz: die aktuelle Iteration (Geschmacksverirrung?) der Entwicklungsumgebung für S7 Steuerungen.

Wobei Codesys, insbesondere in Sachen intuitiver UI, auch nicht der Weisheit letzter Schluss ist, aber hier wird neben Wago, Beckhoff, x86/ARM Linux, RPI auch etliche andere Hersteller unterstützt - sofern man eben die Lizenz dafür kauft.

[Fritzler]

Registerconfig - Device Setup?

Device Setup und Device Config sind auch etwas zu nah beieinander.
Namensfindung kann ich wirklich garnicht

[m3rt0n]

TIA ist die allein glücklichmachende Universallösung für Probleme, die man ohne Siemens nie gehabt hätte. Kurz: die aktuelle Iteration (Geschmacksverirrung?) der Entwicklungsumgebung für S7 Steuerungen.

Gut ausgedrückt, TIA heisst "Totally Integrated Automation" (auf so einen Namen kann nur ein altgedientes deutsches Unternehmen kommen )
und ist die unter neuer GUI zusammengefasste Programmierumgebung für Miesenssteuerungen. Früher wars mal Step7 für die Logik und WinCC für die HMI. Irrsinnig Ressourcenhungrig und lahm, aber schön bunt und halbwegs intuitiv wenns nicht zu kompliziert wird.

[sirell]

Siemens hat nicht nur Probleme bei der Benutzbarkeit...
CVSS 7+

[Fritzler]

Es geht weiter.
Heute hab ich mal den "Device Tree" implementiert.
Schließlich ist dies ein zentrales Element der Software, wenn nicht sogar das Zentralste.
Hier sind alle Geräte aufgelistet.
Ein Klick auf ein Gerät (Auswahl) blendet dann die Inhalte in dem Tabbereich ein.
Die Geräte sind in der Reihenfolge änderbar.
Natürlich lasen sich auch neue anlegen oder ein Gerät kopieren.
Man hat ja eventuell 2 Netzteile und nur die Adresse ändert sich, da willste ja nicht alles neu eintippen.
Löschen geht auch und deswegen hat das Programm jetzt auch eine Undo Funktion.
Wär ja blöd wenne was ausversehen löscht und dann ist es für immer weg.


Weiterhin resizen sich jetzt die Widgets wenn der Nutzer am Fenster zerrt.


Die Tage davor hatte ich mir die inneren Datenstrukturen überlegt, das sieht jetzt so aus:


Bevors jetzt sichtbar weitergeht brauch ich den Parser des Workspace und der Geräte.
Da hab ich mich jetzt für XML umentschieden.
Dann das kann je Nach geräteanzahl und deren Registerdefinitionen doch etwas größer werden.
Das kann dann so aussehen:

Code: Alles auswählen

<?xml version="1.0"?>
<workspace>
	
	<header>
		<version>0.1.0.0</version>
		<name>Workspace contains everything</name>
	</header>
	
	<logsettings>
		
	</logsettings>
	
	<device>
		<name>E-Last</name>
		<location>Werkbank</location>
		<iid>100</iid>
		<connection>
			<mode>rtu</mode>
		</connection>
		<elements>
			<coil name="Bootloader">
				<addr>0</addr>
			</coil>
			<holding name="Strom">
				<addr>42</addr>
			</holding>
		</elements>
	</device>
	
	<device>
		<name>Wasserstand</name>
		<location>Balkon</location>
		<iid>101</iid>
		<connection>
			<mode>rtu</mode>
		</connection>
		<elements>
			<coil name="Bootloader">
				<addr>0</addr>
			</coil>
			<holding name="Wasserstand">
				<addr>2</addr>
			</holding>
		</elements>
	</device>
	
</workspace>

[Fritzler]

Könnt ihr mir mal bitte ein paar Modbusgeräte vorschlagen?
Da möchte ich mal in die Dokus gucken wie denn so die Endianess bei den Registern aussieht.
Vor allem bei 32Bit oder 64bit Auslesungen (2/4 Register).
Ich hab hier alles nur selber gebaut

Das ist ja ziemlich wildwüchsig.
Die Übertragung von Modbus ist zwar auf Big-Endian fetgenagelt und damit eigentlich auch die 2 Byte eines Registers.
Aber auch das wird ja wohl tlw. nicht eingehalten.

Was kann passieren:
Registerauslesereihenfolge kann sich ändern.
Die Byterihenfolge im Register kann sich ändern.
Da kricht man dochn Föhn!

[sukram]

Wago 750er Modelle. Da ändern sich die Registeradressen je nach Bestückung an I/O Karten, bei den SPSn kommen noch direkte Kommunikations und Statusregister dazu. Dann war da noch was mit Einzelbits (Coils), die werden bei der Adressberechnung hinter die Register geschoben. Ausserdem überlappen sich in Schreibrichtung Adressbereiche - wenn man auf die Inputs schreibt, wird das auf die Output umgebogen. Gleichzeitig haben die Output aber einen zweiten Adressblock, um dort schreiben und rücklesen zu können. Ich bin mir nicht sicher, ob das Standard oder eine Wagosache ist.

Saia ALD1 bzw ALE3. Die größten Register sind 32 Bit.

Bei FHEM (Modul ModbusRegister) hat man da ein langes Dropdown Menü um von INT/Word/D/3/QWord bis Real inbeiden Endianess sowie Date/Time/DT auszuwählen.
QWord nutze ich z.b. um die 1Wire ID auszugeben.

[bastelheini]

Könnt ihr mir mal bitte ein paar Modbusgeräte vorschlagen?

https://bg-etech.de/download/manual/SDM ... bus-DE.pdf

[Fritzler]

Ausserdem überlappen sich in Schreibrichtung Adressbereiche - wenn man auf die Inputs schreibt, wird das auf die Output umgebogen.

Inputregister write landet in den Holdingregister?
Aua!
Eigentlich sollte das schon die Modbuslib aufm PC abfangen
Laut Standard gibts da ne Exception: "was willst du eigentlich?!?!?"

Bei FHEM (Modul ModbusRegister) hat man da ein langes Dropdown Menü um von INT/Word/D/3/QWord bis Real inbeiden Endianess sowie Date/Time/DT auszuwählen.
QWord nutze ich z.b. um die 1Wire ID auszugeben.

Ja, alles mögliche kannste bir mir auch auswählen: signed/unsigned 16/32/64/float/double
Das habe ich frei definierbar gelöst, es gibt einen Endianstring, die Position einer Bytezahl wann sie gelesen wird und die Zahl selber in welches Byte am PC die kommt.
Nur wird keine Sau "76543210" hinschreiben wollen ins Programm, sondern das ist die interne Schicht und als Fallback wenn wer "mixed endian" angibt.
Wer weis was sich Hersteller manchmal ausdenken.
Mir gehts eben um Vordefinitionen welche als Dropdown auswhählbar sind.
Engere Auswahl des Endian:
Little
Litte Byteswap
Big
Big Byteswap

Die Vorgeschlagenen geräte guck ich mir dann mal an.

https://bg-etech.de/download/manual/SDM ... bus-DE.pdf

Geil...
Die schreiben einfach float hin bei 1.9, aber nicht in welcher Reihenfolge man die 2x16Bit register auslesen muss.

[Fritzler]

Jetzt mal angefangen das Holding Register Tab zu füllen, so solls aussehen.
Ein Klick auf Add (bzw später edit) öffnet das kleine Fensterchen.


So, da hab ich mich dazu entschieden nicht mit endianess Begriffen um mich zu werfen, sondern:
up, down und mixed.
Damit ist die Registerreihenfolge gemeint.
up -> Register mit höherer Adresse enthält höhere Werte.
down natürlich einmal andersrum.
Falls dann im Register noch was vertauscht sein sollte gibts noch ein Byteswap.
Das Ganze wird dann auch noch unten angezeigt:


Richtig verrückt wirds dannbei mixed, da lässt sich alels frei auswählen

[Fritzler]

Ha!
Endlich auch mal Lebenszeichen auf dem Modbus!

Hier mal der erste Versuch ein DPS5005 auszulesen:


Was mir bei dem China NT direkt mal aufgefallen ist:
Da werden auch Holding Register als readonly deklariert, eigentlich sind die immer R/W.
Sonst wärs ja ein Input Register.
Somit wird da noch ne neue Einstellung fällig.

Wo auchnoch mehr arbeit lauert:
Bei meinem Wasserstandssensor muss erst ein Coil bit geflippt werden vorm Lesen.
Damit nur dann der Sensor bestromt wird wenn nötig.
Da brauch ich ja noch etwas scripting "was muss vor dem eigentlichen Register lesen/schreiben noch so passieren".
Viel solls nicht werden:
https://git.fritzler-avr.de/fritzler/mo ... ipting.odt

[Fritzler]

Das DPS5005 nutzt ja auch enums, also einem Zahlenwert im Register ist ein Sring zugewiesen (Overprotect status zB).
Mein Bootloader hat ja auch nen enum, den der genutzten CPUs.
Also heute enums eingebaut:


Enums werden dann als drop down menü angezeigt zum Setzen von Werten.

Hier werden die verfügbaren enums und dessen Werte angezeigt:


Leider kann der TK Treeview nur anzeigen und nicht editieren, daher muss ich wohl noch hiermit experimentieren:
https://github.com/ragardner/tksheet

[Fritzler]

Es ging wieder weiter.

Sämtliche Dateioperationen sind implementiert.
Workspace/Device speichern/laden in verschiedenen Ausführungen.
Da gabs ne kleine Möglichkeitsexplosion wegen Devices, die im Workspace abgelegt werden oder nur relative Pfade zu einer Devicedatei.
Da es im File Menü daher zu viel geworden wäre, hab ichs noch aufgetrennt:


Damit im Devicetree zu sehen ist was denn nun "contained" oder relativ ist gibts noch Icons:


Was ich fast noch vergessen hatte war Register zu schreiben
Dabei ist mir aufgefallen, dass das DPS5005 keine Fehlermeldung über Modbus ausgibt, wenn man den Strom auf zB 6A setzt, es aber nur 5,1 A kann.
Dann stellt das NT eiskalt 0A ein.
Also hab ich noch eine min/max Vorabfrage implementiert, sodass sowas nicht passieren kann:

Das DPS5005 tut dies auch wenn man eine UOut > Uin einstellt.
Da muss ich mir noch was dynamisches überlegen, aber das Chinading braucht immer so lange für ne Modbus Antwort :/

Dann hab ich noch mit den Bits angefangen.
Coils lassen sich auch "oneclick" = live setzen.
Wär doch etwas nervig erst das Bit zu setzen und dann auf W zu klicken.

[Fritzler]

So, jetzt sind auch die enums fertig.
Mit dem Tabellenwidget ging das ganz geschmeidig.
Am Kontextmenü des Treeview musst ich länger rumfummeln



Es lässt sich natürlich ein neues und leeres enum anlegen.
Ein Enum kann kopiert werden, danach lassen sich dann einzelne Einträge editieren.
Ein Enum kann zu einem anderen Device kopiert werden.

In der Tabelle kann man wild rumeditieren und dann abspeichern.

[Fritzler]

In nem Nachbarfred wollt ja wer Modbus sniffen.
Das ist ein Usecase, den ich noch garnicht auf dem Schirm hatte.
Wenn was auf dem Bus rumzickt will mans ja villeicht auch direkt sehen mit nem Sniffer.

Daher habe ich mir mal ein paar Gedanken gemacht wie das in der GUI aussehen könnte:


Ein Frame wird angezeigt als ein TK Frame und in dem ist eine Tabelle.
Die Slave ID wird zum Namen des Geräts aufgelöst (Wenn im Workspace vorhanden).
Dann wird der Function Code zu einem lesbaren Namen übersetzt.
Danach kommt die Startadresse, diese kannste dann nur als uint16t zusammenfasse.
Genau wie die Anzahl der zu lesenden Register.

Bei der Antwort kann ich aus der vorhergehenden Startadresse ausrechnen welche Register denn nun gellesen wurden.
Damit kann ich aus einer Gerätebeschreibung im Workspace den Registernamen auslesen.
Sowie den Wert direkt als interpretierten Wert anzeigen.

So!
Jetzt kommts aber zu nem Problem.
Weil immer klar ist wer Busmaster ist, lässt sich das den Frames nicht anerkennen.
Der Funktion Code ist für Anfrage und Antwort immer gleich.
Bei den Registern ist das noch einfach rauszufinden.
Die Antwort eines read hat immer eine ungleiche Anzahl an Bytes nach dem Funktion Code, da das Bytecount Feld imemr 1 Byte lang ist und Register eben 2 Byte.

Bei Read Coils wirds lustig.
Da ist dieses grade/ungrade Bytezahl spielchen nicht möglich.
Da muss ich dann imemr gucken obs den Funkcode schon vorher gab und raten.
Ist dann nur blöd wenn man den Sniffer genau zwischen den biden Frames einschaltet

pymodbus hätte direkt noch ein Beispiel für sowas.
Die rufen einfach den Server und Client Decoder gleichzeitig auf.
Einer von beiden wird schon was sinnvolles zurückgeben
-> https://pymodbus.readthedocs.io/en/v1.3 ... arser.html
Aber ob das immer zuverlässig funzt?

[kpwn]

Pymodbus hatte ich benutzt und es hat zumindest bei mir damit funktioniert.
Dafür hatte ich Probleme mit manchen Kabel. Wahrscheinlich unglückliche Kombination aus der Länge und fehlenden Abschlusswiederständen. Morgen kommen da Mal 120 Ohm vorne und hinten dran.

[Fritzler]

Pymodbus hatte ich benutzt und es hat zumindest bei mir damit funktioniert.
Dafür hatte ich Probleme mit manchen Kabel. Wahrscheinlich unglückliche Kombination aus der Länge und fehlenden Abschlusswiederständen. Morgen kommen da Mal 120 Ohm vorne und hinten dran.

Es braucht nicht nur bschlusswiderlinge, sondern auch welche für den Bias falls kein RS485 IC im Sendemodus ist.
Sonst kommt es zu sporadischen 0 Bits und der UART rastet aus.
https://de.wikipedia.org/wiki/Datei:Rs4 ... nation.svg
(Nur beim Master nötig!)

[kpwn]

Ich hoffe das die bias Wiederstände in meinen USB-RS485 wandlern dabei sind. Wirkte aber so, da die fehler konstant waren. Entweder lief es perfekt oder überhaupt nicht.

[Bastelbruder]

Die Abschlußwiderstände haben in den Wandlern absolut nichts zu suchen und sind sehr wahrscheinlich auch nicht drin.
Die beiden Widerstände sind elementarer Bestandteil der (fast jeder*) Busleitung und gehören an deren Anfang und Ende.

Leitungstheorie - warum heißt die eigentlich Theorie - ist Voodoo.

* Sobald eine Leitung etwa 1/4 der Wellenlänge der höchsten Übertragungsfrequenz (oder länger) ist, braucht man Abschlußwiderstände. Und aufpassen, der Strom hat in isolierten Leitungen deutlich weniger Geschwindigkeit als in Luftisolierten Freileitungen.