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

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

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: frober am 29 März 2021, 15:35:49
@Beta-User: Du hast noch die 2x 120 Ohm am Ende und je 2 kOhm CanH -> 5V, CanL -> GND?
...soweit ich mich entsinnen kann, ist schon eine Weile her...

Grundsätzlich meine ich aber, dass der Aufbau mit dem Widerstandsnetzwerk nach dem Vorschlag von Ranseyer der Weisheit letzter Schluss gewesen wäre - ganz unabhängig von der Frage, welche Art Transceiverbaustein man nutzt.
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

#196
ZitatGrundsätzlich meine ich aber, dass der Aufbau mit dem Widerstandsnetzwerk nach dem Vorschlag von Ranseyer der Weisheit letzter Schluss gewesen wäre

Ich finde meine Ideen immer gut 8)  (nee das stimmt nicht  :o)
Aber was für den Ansatz von unten spricht ist, dass viele kommerzielle das genau so, oder sinngemäß so machen.
(Hatte damals ja auch einiges herumgerechnet. Theoretisch könnte manchmal der Ansatz von Brasletti noch besser sein. Wir hatten auch über aktive Terminierung nachgedacht und dazu auch ein Platinchen mit einem Spannungsregler produzieren lassen. Was mich daran gestört hat: Der dazu nötige RJ45 Stecker für Platinenmontage kostete bei Reichelt ca. 1€, und das fand ich unverschämt, daher habe ich das selbst nicht genutzt, und auch nicht benötigt)

Das ist mein offizieller Stand woran ich wenig Lust hatte weiter zu arbeiten wegen knapper Resonanz: https://wiki.fhem.de/wiki/Easy-RS485-Bus



Ed: hier die aktive Terminierung: https://github.com/ranseyer/home-automatics/blob/master/RS485-Termination-Brasletti/bot.png
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!

frober

#197
https://wiki.fhem.de/wiki/Easy-RS485-Bus


So habe ich das zum Schluss auch gehabt, nur für 12V. Dann wollte selbst die Node in der Nähe nicht mehr reden >:(

Kann ich das auch mit den beiden 120 Ohm kombinieren für die CAN-Chips?
Ich habe knapp 4V zw. H und L.

Was mir noch aufgefallen das ist, meine MCPs sind auf Fullspeed gelaufen, vielleicht war das das Problem. Hab sie jetzt mit 10k auf Grund gezogen.

Edit: Die MCP habe ich direkt verbaut, nicht als Breadboard.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

Bei CAN sollte eine Terminierung zw H und L schon ran. Im Gegensatz zu RS485 können die CAN Treiber (z.B. MCP2551) nur den dominaten Pegel treiben, d.h. bei rezessiv muss der Busabschluss die Differenz zw H und L auf nahe 0V ziehen.
Nominale CAN Pegel gegen GND:
Rezessiv: H und L auf ca. 2.5V (Differenz 0V)
Dominant: L<1.5V, H>3,5V

Bei RS485 haben die Treiber PushPull Stufen und können beide Pegel aktiv treiben.

rob

Hab mich seit ca. 1 Jahr immer wieder mit dem Thema beschäftigt und scheiterte jedes Mal wieder wegen was anderem  :(
Mal fehlten Bauteile, mal passende Crimp-Werkzeuge und dann wieder Gehäuse (brauch Hutschiene). Wollte einfach vom Versuchsaufbau weg. Dachte nicht, dass das so aufwändig sein kann. In meiner Not habe ich Platinen "designt", damit endlich saubere Kontaktierungen möglich sind und wo ich div. Steckverbinder drauflöten kann. Naja, genug gejammert  :-X

Meine trial and error Versuche brachten vor ca. 2 Wochen diese Erkenntnisse:

  • die im Wiki reingemalten hw-Varianten mit Widerstandsnetzwerk und MCP zeigen an der letzten Node bildlich keinen 120Ohm-Abschluss
    --> das hat auch bei mir schon im Versuchsaufbau nicht funktioniert (hatte die 24V Geschichte aufgebaut)
  • letztes MCP-Modul will bei mir immer terminiert werden, so wie es im Wiki im Text drunter steht, sonst geht nix - selbst nicht mit Widerstandsnetzwerk, wenn die Leine nur 4cm kurz ist, nur eine Node dran hängt und der Speed bei 9600 liegt
  • meine MCP-Module sind ggü. den Max485-Modulen sehr zickig - nach vertauschen von CANH/CANL im Mischbetrieb mit Max485 machen sie erstmal nichts mehr und als letzte Node ohne 120ohm eben auch nicht
  • der Mischbetrieb zw. MCP-Modul und Max485-Modul muss bei mir so aussehen: 
    GW mit Max485 - End-Node mit Max485 und dazwischen eine Node mit MCP2551
    --> CANL muss nach Line A und CANH muss nach Line B
  • die Max-Module waren sehr fehlertolerant, der Aufbau mit denen lief eigentl. immer
  • für hw-serial muss z.B. bei Arduino pro mini dies explizit im Code berücksichtigt werden - auskommentieren von "#define MY_DEBUG" reicht nicht, "#define MY_DISABLED_SERIAL" muss zusätzlich rein
  • alle Nodes müssen bei mir die selbe Baudrate haben: 57600 klappt gut, auch mit MCP-Modul
  • längstes bisher getestetes Kabel: 6m mit RJ11-Westernstecker (da geht bestimmt noch mehr)
Meine Erfahrungen decken sich also mit dem, was auch KarlHeinz2000 schreibt. Vermutlich sind meine Erkenntnisse aber nix nennenswertes, weil eh schon immer klar (nur halt mir nicht  ::) ). Vielleicht nützen sie trotzdem etwas.

Mein GW ist nun fertig. Die erste Node fast. Ich wollte eigentl. berichten, wenn wenigstens die zwei stabil zusammenarbeiten. Aber ich warte mal wieder auf eintrudelnde Bestellungen...

Viele Grüße
rob



Ranseyer

Zitat von: KarlHeinz2000 am 29 März 2021, 19:58:19
Im Gegensatz zu RS485 können die CAN Treiber (z.B. MCP2551) nur den dominaten Pegel treiben, d.h. bei rezessiv muss der Busabschluss die Differenz zw H und L auf nahe 0V ziehen.

Danke für die sehr kompetente Rückmeldung. Gut dass ich mich bisher vor allem auf die Max487 focussiert hatte. Damit hatte ich über Jahre kaum Probleme und auch wenig Grund die CAN Sachen voran zu treiben. Damit wird manches was so diskutiert wurde plausibel...

PS: Die DMX Leute kennen sich auch ganz gut mit RS485 aus, und die haben auch noch stabile Stecker...  8) (Da könnte man auch einiges lernen wenn die Zeit dazu hat und deren oft diskrete Schaltungen anschaut)
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!

frober

Hier mal für Interressierte:
https://www.kfztech.de/kfztechnik/elo/can/can_grundlagen_1.htm

Ganz unten CAN-Komfort erklärt, warum H/L zu den Max verdreht werden muss.
Da wird mir auch klar, warum das mit der Terminierung auf 12V nicht funktioniert hat.

Nur erklärt es mir nicht, warum es mit 2 x 120 Ohm am jeweiligen Ende nicht reicht. :o

@ KarlHeinz2000, danke für den Stups  :)
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

Ich denke Mischverbau von RS485 und CAN ist nicht gut.
Die üblichen CAN Transceiver sind alle für High Speed CAN, d.h. 2,5V rezessiv.
Die RS485 Treiber haben eine Ausgangsdifferenzspannung A-B von >+/-1,5V lt. Norm.
Im Datenblatt vom MCP2551 wird aber die rezessive Differenzspannung am Eingang mit -1..0,5V angegeben. Somit wird der MCP2551 mit den RS485 Treibern überfahren (Auswirkung unklar).
Versuchen kann man mal einen TJA1042 o.ä., da steht was von -4V (vobei das Datenblatt nicht ganz eindeutig an der Stelle ist). Beim TLE6250 habe ich keine Angabe gefunden. Das sind noch zwei typische Kandidaten. Vielleicht verhalten die sich besser.

frober

Zitat von: KarlHeinz2000 am 31 März 2021, 10:10:35
Ich denke Mischverbau von RS485 und CAN ist nicht gut.
Die üblichen CAN Transceiver sind alle für High Speed CAN, d.h. 2,5V rezessiv.
Die RS485 Treiber haben eine Ausgangsdifferenzspannung A-B von >+/-1,5V lt. Norm.
Im Datenblatt vom MCP2551 wird aber die rezessive Differenzspannung am Eingang mit -1..0,5V angegeben. Somit wird der MCP2551 mit den RS485 Treibern überfahren (Auswirkung unklar).
Versuchen kann man mal einen TJA1042 o.ä., da steht was von -4V (vobei das Datenblatt nicht ganz eindeutig an der Stelle ist). Beim TLE6250 habe ich keine Angabe gefunden. Das sind noch zwei typische Kandidaten. Vielleicht verhalten die sich besser.

Ich habe nur MCP2551, nach einem Test am GW mit Terminierung aus Bsp. 12 V plus der 2 x 120 Ohm hat die Node in der Nähe wieder kommuniziert (kurze Leitung).
Spannung H/L ca. 2,5-2,6V ->GNG/VCC, Diff 0,03V sollte erstmal passen.

Produktiv hat es noch nicht funktioniert, BUS hat sich aufgehängt. Messe heute nochmal die Spannungen an allen Nodes vor Ort und schalte diese einzel zu.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Aktuell läuft der Bus, nur die 2x 120 Ohm am Ende nicht mehr. Einzige Änderung zum ersten Versuch, der Rs-PIN am MCP2551 ist über 10k auf Grund.

Ab und zu hängt es sich noch, wenn zu viele Daten kommen, das Betrifft auch den Start der Nodes. Nach einem Reset des GW läuft wieder alles.

Kann es sein, das das GW die Daten nicht schnell genug abnimmt/verarbeitet?
Bringt es etwas, den Widerstand am Rs zu erhöhen (geringere Flankensteilheit, bessere Fehlertoleranz, geringere Geschwindigkeit beim CAN)?

zusätzliche Terminierung mit 2,2k  CanH -> VCC und CanL -> GND hat keine Verbesserung gebracht.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

Den Rx/TX Buffer im GW vergrößern hilft auf jeden Fall. Zumindest war das bei mir ein Problem. Anbindung an fhem mit 115kb, RS485 mit 9600. Da ging bei vielen Daten von fhem einiges verloren...
Aufgehängt hatte sich aber nichts.

frober

Zitat von: KarlHeinz2000 am 02 April 2021, 19:47:07
Den Rx/TX Buffer im GW vergrößern hilft auf jeden Fall. Zumindest war das bei mir ein Problem. Anbindung an fhem mit 115kb, RS485 mit 9600. Da ging bei vielen Daten von fhem einiges verloren...
Aufgehängt hatte sich aber nichts.

Fhem habe ich auch mit 115kb, RS485 mit 19200. Den Buffer setze ich im Sketch, wo?
Daten sind soweit vorhanden, vielleicht hilft es ja trotzdem.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Aus den Untiefen meiner ersten Problemlösungsversuche mit RS485: Mal den SOH-Count am GW erhöhen? (Ist ein Parameter im Sketch)
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

frober

Zitat von: Beta-User am 02 April 2021, 20:03:32
Aus den Untiefen meiner ersten Problemlösungsversuche mit RS485: Mal den SOH-Count am GW erhöhen? (Ist ein Parameter im Sketch)

OK, habe nachgelesen.
Muss ich das dann im GW und jeder Node definieren?
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

KarlHeinz2000

Den Buffer RX/TX musst du direkt in der hwserial.cpp (?) im arduino Ordner ändern. Im sketch geht das nicht. Schadet auf jeden Fall nicht. RAM ist beim GW kein Problem.
Bin leider nicht vor Ort und kann den Pfad nicht raussuchen.
Mit SOH habe ich noch nicht gespielt.