RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

Begonnen von Beta-User, 22 Februar 2018, 15:14:12

Vorheriges Thema - Nächstes Thema

Beta-User

Yep, meine Nodes sind alle Hardware-Serial-Nodes, allerdings praktisch alle auf Pro Mini-Basis. Den USB-Chip braucht man in der Regel doch vor Ort nicht, ist nur Balast und macht das ganze setup größer... Direkt vor Ort kannst du da eh' nichts anschließen, wenn die Stromversorgung zentral läuft (bzw. nur TX/RX!).

Und betr. Debugging: siehe die Beiträge von KarlHeinz2000 zum Thema "Umleiten" ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

#136
@Beta-User
Anhand der Infos ausm Wiki + Fred würde ich gern das Wiring an einem weiteren Beispiel konkretisieren. Ich habe in Fritzing diese Variante nach meinem Verständnis entworfen:
- 12V zentral eingespeist
- Max485-Module als Transceiver
- GW Arduino Nano und Nodes Pro Micro (5V-Variante)
- 4-adriges Kabel zu den Nodes
- SoftSerial (für den Anfang)
- 1 Elko je Node z.B. 220uF zum Stabilisieren
- b. Node1 wäre R7 zu entfernen


Im Gegensatz zur Spannungsversorgung im Kabel (rot) dürften auf dem Bus (A/B - gelb/grün) 5V anliegen, keine 12V. Würde man den Bus auch mit 12V betreiben wollen, müssten am Node vorm Max485-Modul jeweils Level-Shifter oder Optokoppler verwendet werden, um A/B vor Ort wieder auf 5V runterzukriegen. Korrekt?

Ich habe es etwas umständlich verdrahtet, um die Nodes klarer zu trennen und d. 4-adrige Kabel besser darzustellen. Widerstände habe ich sonst belassen (R7-Node1 muss man sich wegdenken), da diese je nach Berechnung sehr individuell ausfallen können. Verbesserungswünsche pflege ich gerne ein (und aktualisiere diesen Post).

Nächster Schritt wäre m.M.n  - darstellen mit einem Node@MCP2551 und dann mit hw-serial. Das MCP-Modul soll ja direkt mit 12V (Vcc + Bus) arbeiten können (stimmt das überhaupt?).

Danke und viele Grüße
rob

Edit:
- weniger GND
- berechnete u. gerundete Widerstände R1 - R3 am Buseingang (am Gateway) --> R5- R7 müsste man sich wegdenken
- Schirmung angedeutet und mit 12-GND verbunden
- Spannungswandler f. Nodes eingefügt (LMZ14203 - hab in Fritzing nix besseres gefunden --> da müsste man sich ggf. nochmals festlegen)
- etwas eingeenglischt
- NodeN und Last_Node kenntlich gemacht
- Widerstände auf den Transceivern entfernt, an Letzter Node R4 120Ohm eingefügt, Notes ergänzt
- Beschriftungen GW+Nodes leserlicher


Beta-User

Vorab mal: das sieht jedenfalls mal übersichtlich aus!

Anmerkungen in der Sache:
Zu viel: GND-Verbindung zwischen Node und der 12V-GND. Das würde ich getrennt halten (PeMue hatte mal nach einem Widerstand gefragt, das könnte man evtl. testen; bei mir ist da gar keine Verbindung).

Zu wenig (?) bzw. anders:
- MMn. sollte irgendwo an einem der Busenden (bei mir: Node n) je noch ein Widerstand zwischen A+12V bzw. B+GND verbaut werden; zur Berechnung bitte das Tool benutzen; kann grade nicht sagen, was da bei mir verbaut ist. (Wie Ranseyer irgendwo geschrieben hatte: das kann auch ohne klappen und ist dann stromsparender) Original sind auf jedem Modul 10k oder 20k (?) drauf, was irgendwann auch eine suboptimale Gemengelage ergibt (oder waren das die Werte von den TJA1050-Modulen? *kopfkatz*).
- (wohl eher ein zeichnerisches Thema: Schirmung um A+B auf 12V-GND, das 1x jede Teilstrecke)

Stromversorgung: Das ist über die internen Spannungswandler (AMS10irgendwas?) einigermaßen ineffizient, ich habe daher stepdowns verbaut (ziemlich billige, die in etwa aussahen wie diese, da muß man auch vorher messen, ob und was die liefern! Hatte gefühlt 30% Ausschuß, weil der "einstellbare Widerstand" nicht einstellbar war...).

Da ich erst von den MAXen her herkam, habe ich die Nodes so ausgelegt, dass die für die MAX-Module paßten. Hat zur Folge, dass die MCP2551 (als Ersatz für den Ersatz) nie auf 12V ausgetestet wurden. Wäre aber eine interessante Sache, wenn das klappt, düfte das effizienter sein als der Betrieb über die runtergepegelten 5V (das iVm. passenden Platinen, die gute und schnelle Klemmverbindungen auch für das an GPIO angeschlossene Zeug ermöglichen => vielleicht mache ich dann meine Dosen doch bei irgendeiner fernen zukünftigen Gelegenheit nochmal auf und verkable alles nochmal hübsch und ordentlich?!? ::) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

#138
Es gibt viele Wege ans Ziel. Und alle sind ein Kompromiss.

Zitat- 12V zentral eingespeist
Macht häufig Sinn. Oder eben auch 24V weil weniger Verlust.

Zitat- Max485-Module als Transceiver
Bei wenigen Nodes Ok. Dass die Module riesig sind hast du sicher selbst gesehen...
Ansonsten Max487 = Pinkompatibel oder gleich die CAN Chips.

ZitatWürde man den Bus auch mit 12V betreiben wollen, müssten am Node vorm Max485-Modul jeweils Level-Shifter oder Optokoppler verwendet werden, um A/B vor Ort wieder auf 5V runterzukriegen. Korrekt?
Nö, denke ich nicht. Du müsstest dazu das Blockschaltbild des RS485 oder CAN Chip mit dem des gewünschten Level-Shifters vergleichen, dann solltes sich rasch herausstellen das kann nicht gehen. RS485 ist potentialfrei und Relevant ist die Differenz.

Die häufigste Frage scheint die Terminierung zu sein...

A) Ohne Denken zu müssen kann man stumpf 120 Ohm zwischen A und B packen

B) Widerstandsnetzwerk wie bei Homematic Wired ist schon intelligenter. Muster: https://wiki.fhem.de/wiki/Easy-RS485-Bus

C) Mann kann am Ende auch einen Spannungsregler verbauen und damit "aktiv terminieren". Auf dem selben Kabel wie dem Bus hat man z.B. noch 12V und GND. Der *1117 Regler wird kaum belastet und erzeugt 5V. Er zieht damit über einen Widerstand den Bus auf 5V. Die Idee war von Brasletti. Hab ich auch schon gemacht. Vorteil dabei ist, dass egal ist ob man z.B. 12 oder 24 auf dem Buskabel mitführt, und man muss auch bei der Anwendung wenig nachdenken...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

rob

Zitat von: Beta-User am 12 Mai 2020, 15:31:04
Zu viel: GND-Verbindung zwischen Node und der 12V-GND.
Ich habs kurzerhand nummeriert. Welche Nummern meinst genau?

Viele Grüße
rob

PS: Die Übersichtlichkeit darf aber keinen Stuss verbreiten  ;D Ich pass den Rest gleich noch an.

Beta-User

@rob: Nummer 2.

@Ranseyer:
Da war in dem Post eine Klammer zu wenig, daher der Edit (reine Formatierungsfrage).
C) verstehe ich nicht, hört sich aber interessant an.

@all
(Irgendwo da draußen in den Untiefen des WWW (und auch hier im Forum mal kurz angerissen) gab's auch noch die Variante, die Buskabel direkt zur Stromversorgung zu nutzen. Da liegen lege artis afaik auch (in übergragungsfreien Zeiten stabile) 2V an, die man "upcyceln" können müßte. Ist aber für einen Schrauber wie mich höhere Magie; sowas mag aber vielleicht großen Sinn machen, wenn man wirklich große Kabellängen hat und einzelne Nodes versorgen muß...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

loetmeister

Zitat von: Ranseyer am 12 Mai 2020, 16:09:36
C) Mann kann am Ende auch einen Spannungsregler verbauen und damit "aktiv terminieren". Auf dem selben Kabel wie dem Bus hat man z.B. noch 12V und GND. Der *1117 Regler wird kaum belastet und erzeugt 5V. Er zieht damit über einen Widerstand den Bus auf 5V. Die Idee war von Brasletti. Hab ich auch schon gemacht. Vorteil dabei ist, dass egal ist ob man z.B. 12 oder 24 auf dem Buskabel mitführt, und man muss auch bei der Anwendung wenig nachdenken...
Klingt auch gut.... laut Datenblatt sollte der LM 1117 Regler aber max. 15 Volt Eingangsspannung bekommen...
Die schnöden 78(L)05 max 20V. Wie würde das für 24v aussehen?
Vermutlich wäre ein DC-DC Wandler bei der großen Spannungsdifferenz besser? Oder ein paar mA mit Spannungsteiler abzweigen und den Linerarregler dahinter?  ???

Gruß,
Thomas

rob

Danke für Eure Rückmeldungen. Habs in der Grafik angepasst (s. Edit dort).

Zitat von: Ranseyer am 12 Mai 2020, 16:09:36
...C) Mann kann am Ende auch einen Spannungsregler verbauen und damit "aktiv terminieren"...
Ich male gern alles rein wenn ich wüsste, wie das aussehen muss. Ansonsten bin ich da schlicht überfordert  :o

Wenn es mit dem Max485 eher in die Sackgasse führt, dann macht es ggf. mehr Sinn gleich allein die CAN-Beispiele zu visualisieren?
Vorschlagsweise einmal 12V und einmal 24V mit jeweils "aktiver Terminierung".

Viele Grüße
rob

Beta-User

Zu der Grafik evtl. noch: In der, die jetzt im Wiki ist, ist eine ... -Verbindung für n Nodes. Finde ich besser (weiß aber eh' noch nicht, ob ich nicht einfach beide Grafiken ins Wiki reinmachen soll?).

RS485 "classic" ist mMn. keine Sackgasse. Das funktioniert, was fehlt, ist eine innerhalb des Systems automatisierte Lösung, falls eine Node hängenbleibt. Schaltet man aber bei ausbleibenden Messages einfach den Strom von der zentralen Versorgung ab, läuft alles wieder.
Eine Anmerkung noch zu meinen damaligen Problemen: Ich habe eher wenige Nodes, die aber teils viele Werte kurz nacheinander auf den Bus schieben. Meine momentant Theorie dazu wäre, dass schlicht und ergreifend der Message-Buffer auf den Nodes nicht ausgereicht hat, um gleichzeitiges Senden und Empfangen in der Menge zu verarbeiten... Es gab nämlich eine gewisse Korrelation zwischen den Ausfällen und dem Überschneiden von "Sendeperioden" mindestens zweier Nodes. Hätte ich das an der Stelle anders konzipiert, wäre das evtl. auch mit den MAX485 völlig ok gewesen.

So sehe ich die CAN-Transceiver als empfehlenswerte Verbesserung, aber nicht als Notwendigkeit an.

Eine passende/geänderte Grafik dazu wäre aber natürlich super (bzw. zwei softwareserial+hardwareserial)!

Es scheint übrigens durchaus einige RS485-Nutzer (@MAX) zu geben, wenn ich das eine oder andere an Rückmeldung bzw. Frage im MySensors-Forum richtig deute.

Noch eine interessante News von da: Es wird zukünftig "Multi-Protocol-Gateways" geben :) . Siehe die Ankündigung Something's cooking in the MySensors labs...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Wenn Du die Grafik ins Wiki nehmen möchtest ehrt mich das sehr.  :)
Es soll natürlich keine Bildkonkurrenz entstehen. Ich möchte nur ein - drei gängige/ solide Varianten visualisieren  - ggf. hilft es ja Einsteigern wie mir. Ich habs in obigem Post aktualisiert.
Wenn es passt, würde ich das als Basis nehmen für HW-serial/CAN.

Wegen "classic": Ist anscheinend genau wie Ranseyer schon schrieb: Viele Wege führen zum Ziel. Ist auch wichtig zu wissen, dass es nicht die eine Ultra-Variante gibt, sondern von den Anforderungen/ Gegebenheiten abhängen kann was für einen passt.

Viele Grüße
rob

Beta-User

#145
Mit einiger Wahrscheinlichkeit ist es auch für den ursprünglichen Autor der aktuellen Grafik völlig ok, wenn wir hier eine gewisse "Konkurrenz" haben - er hat das auch eher für sich gemacht ;) . Und ins Wiki kommt, was weiterhilft... (so ist auch die erste vor nicht allzu langer Zeit da gelandet, scheint ja zu wirken ;D ).

Mit Node "n" war die letzte gemeint, die dazwischenzuhängen hilft mMn. nicht weiter. Da du "vorne" am Bus die Widerstände genau reingezeichnet hattest, wäre es evtl. besser, das mit den 120Ohm (?) auch am Ende nicht nur im Text zu erläutern?

EDIT: vermutlich macht das mit Node N doch Sinn, wegen der Schirmung und so. Ist zwar dann auch viel, was auf der Grafik ist, aber eben nicht "too much". (Eher könnte man das andeuten, dass es noch weitere geben kann, indem man das "gestapelt" andeutet? Aber irgendwann "ist auch gut").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

#146
Zitat von: Beta-User am 13 Mai 2020, 11:40:48
...scheint ja zu wirken ;D ) ...
so isses  ;D  :o

Zitat von: Beta-User am 13 Mai 2020, 11:40:48
...besser, das mit den 120Ohm (?) auch am Ende nicht nur im Text zu erläutern?
erledigt, hab die Zwischen-Nodes auf eine reduziert (s.Edit)

Edit: Ups, jetzt hatte ich Dein Edit nicht mitgekriegt. Hattest aber Recht: die Zwischen-Nodes nochmals zu unterscheiden, war unsinnig. GW, ZW-Node und End-Node ist übersichtlicher :)

Viele Grüße
rob

Beta-User

So (mit der 1-n) isses m.E. sehr gut!

In die Richtung also: no action required, sorry für den Edit!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Schotty

Zitat von: Beta-User am 13 Mai 2020, 11:40:48
Mit einiger Wahrscheinlichkeit ist es auch für den ursprünglichen Autor der aktuellen Grafik völlig ok, wenn wir hier eine gewisse "Konkurrenz" haben - er hat das auch eher für sich gemacht ;) .
Absolut! Freut mich, dass sich noch jmd die Mühe für CAN gemacht hat - sieht schick aus @rob! :)
Ich hätte auch meine Fritzing-Datei einstellen können wenn es hilfreich gewesen wäre (habe den Thread leider erst gestern Abd (wieder-)entdeckt und Beta-User hatte mich gerade benachrichtigt), aber das scheint ja nicht mehr nötig zu sein. Falls doch gewünscht: Bitte eben melden.. ;)
Gruß
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Vorab mal an der Stelle noch ein Danke @Schotty für die aktuelle Version im Wiki!

(was @rob da gezeichnet hat ist auch erst mal RS485 "classic", RS485-hardwareserial bzw. "CAN" ist erst angekündigt).

War grade am überlegen, ob ich das auch schon so ins Wiki mit übernehmen sollte, hätte aber vorher doch noch eine kleine Bitte an @rob: Kannst du die Beschriftung "Gateway" &Co irgendwie noch besser "Highlighten". So geht das optisch etwas unter, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files