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

[Ranseyer]

Der MAX487 ist einwandfrei im Rahmen seiner Specs...
(Zu Fakes kann ich nichts sagen)

Die TI Chips scheinen mir auch OK. Allerdings habe ich da recht wenig Erfahrung.

Die Vor- und Nachteile laut Datenblatt soller weiter vorne stehen. Denke von Betauser (?).

[Beta-User]

Denke von Betauser (?).

An "normalen" RS485-Chips hatte ich nur MAX485/487(?) im Einsatz. Als weiteren CAN-Transceiver dann noch irgendeinen NXP/Philips-Chip (TJA-irgendwas), der aber hohe Baudraten braucht und daher den MCP2551 "zum Opfer gefallen" ist.
Mehr Erfahrung ist hier nicht vorhanden...

[PeMue]

Hallo zusammen,

eine Frage: wie verkabelt ihr RS485? Als Bus ohne Stichleitung? Welche max. Länge? Nur A+B oder auch mit GND? Wenn GND, dann mit Widerstand (ich meine 20 - 100 Ohm) in der GND Leitung?

Danke für eine kurze Info.

Gruß und schönen Feiertag.

Peter

[Ranseyer]

Ich mache das so: https://wiki.fhem.de/wiki/Easy-RS485-Bus
(allerdings im Moment noch mit 12V und angepassten Widerständen. Faulheitsbedingt über zwei 8 polige RJ-45 Buchsen und LAN-Kabel. Ein bisschen Murksen war bisher noch nie ein Problem. Aber ich versuche trotzdem das ganze relativ Bus-Artig zu haben. GND und 12V führe ich auch mit. Das widerspricht natürlich dem Prinzip "Potentialfrei"... )

[rob]

... bin mit den CAN-Transceivern des Typs MCP2551 ganz zufrieden und würde auch Einsteigern immer raten ... die einzubauen.

Hallo @Beta-User:
Ich bin im Breadboard-Stadium mit den üblichen Max-Madulen und würde für produktiven Einsatz Deinen Rat gern befolgen.
z.B. würde ich zu solchen Dingern lt. Deinem Post #80 greifen (https://forum.fhem.de/index.php/topic,84814.msg810492.html#msg810492), weil fertige Platine

Im Post #88 hast Du ja den Anschluss für HW-Serial nebst einbinden im Sketch beschrieben (dankeschön )

Für SoftSerial hätte ich mir diesen Anschluss zusammengereimt:
Arduino D8 <-------> CRX MCP2551
Arduino D9 <-------> CTX MCP2551

Und fürs Mischen von max485 und MSP2551 am Bus (oder darf man das garnicht?) hätte ich es so gedacht:
RS485 A-Line <----> CANH MCP2551
RS485 B-Line <----> CANL MCP2551

Hab ich mir Nonsens überlegt?

Vielen Dank und beste Grüße
rob

[Beta-User]

Hi rob (und auch ein Hallo an alle anderen "CAN"-Interessierten ),
nachdem das ganze auf ein gewisses Interesse stößt, ein paar etwas ausführlichere  Anmerkungen zu der "CAN"-Lösung - einige Anmerkungen hatte ich auch heute morgen schon ins Wiki eingetragen, kann das aber gerne dann auch vervollständigen:

- Eine "echte" CAN-Lösung würde eigentlich aus zwei Chipsets bestehen, nämlich einem Controller-Chip (z.B. MCP2515) und einem Transceiver-Chip. Von den Transceivern kenne ich den MCP2551 und den TJA1050. In der Bucht findet man daher auch China-Ware, die den MCP2515 mit einem der beiden anderen auf einem Board vereinen. Beide Transceiver kann man auch noch kaufen, es gibt aber Nachfolgemodelle, der MCP2551 ist wohl schon seit 2014 EOL, hat aber den großen Vorteil, dass man den mit (für heutige CAN-Technik) moderaten Datenraten betreiben kann. Der TJA1050 kann nur ab 56k Baud.
Ich komme eher von der Ecke "hatte Ausfälle" her, brauche keine hohen Datenraten und habe eher den Verdacht, dass lange Kabel und hohe Datenraten ggf. eher wieder Ausfälle bedeuten könnten (zu langsam ist aber auch nichts...!), außerdem ist sotfwareserial@ATMega32 begrenzt auf 56k. Daher halte ich einen Transceiver, der eher zwischen den "MySensors-üblichen" 9600 Baud und den 56k kann für "universeller", selbst wenn er EOL ist. Daher würde ich mir (bzw. habe schon lange) eben ein paar MCP2551 auf Reserve in den Keller legen und "gut ist...". (Außerdem dürften höhere Datenraten deutlich mehr Strom brauchen bzw. besser abgestimmte Widerstände; bestimmt schreibt hier gleich einer unserer "Theoretiker" was dazu ...)

- Aus dem "üblichen CAN-Chipset" wird nur der Transceiverbaustein benötigt (ergibt sich implizit ja aus allem, was hier schon geschrieben wurde).
Der wird "ganz normal" an die jeweilige serielle Schnittstelle der MCU angebunden (also im Prinzip ein "drop-in-replacement" für den MAX485).
Die Unterschiede:
-- es wird kein Interrupt/Enable-PIN benötigt
-- Man muß darauf achten, das CAN-hi immer auf CAN-hi geht (bzw. -lo nach -lo)
Einsteigern empfehle ich daher, erst mit 3 MAX zu starten, und das dann auf dem Breadboard umzubauen, und zwar einen Transceiver nach dem anderen. Dann ist man sicher, dass die Verkabelung paßt...
(Für ein Bild mir einer gut erkennbaren Verkabelung von 3 Nodes@MCP2551@softwareserial (oder gemischt) für's Wiki wäre der nächste bestimmt sehr glücklich, will aber das grade aber selbst nicht umbedingt aufbauen müssen... Das würde aber vermutlich mehr helfen als mein ganzes Geschreibsel hier ).

- Was noch helfen würde:
Wenn jemand mal austesten würde, wie die Verbindungen mit höheren hardwareserial-Verbindungen@höheren Datenraten (112k+) auf längere Strecken sind (bitte unter Angabe der Daten zu den Widerständen, GND-Verbindungen usw. (!!)... ).
Irgendwer hatte hier im Forum bzw. auf den MySensors-Seiten mal gepostet, wie man die Debug-Ausgaben auf softwareserial umbiegt; für Debugging wären kleinere Baud-Raten ja kein so großes Problem... (Das ist nur von den Sketchen her etwas mehr Vorbereitung wie c&p aus den Standardsketchen...)

Hoffe, das hilft den diversen offenen und verdeckten Fragern etwas weiter. (Ihr könnt gerne eure Fragen dazu hier stellen...).

[KarlHeinz2000]

Ich hatte mal hier geschrieben, wie man die Debug Ausgaben umleiten kann:

https://forum.fhem.de/index.php/topic,84814.msg775200.html#msg775200

Hilfreich ist auch ein ESP mit esp-link drauf. Damit kann man schön debug von entfernten nodes im Betrieb machen (braucht halt WLAN).
RS485 sniffen geht damit auch gut (einfach am RX Pin vom MAX... (3.3V!)).

[Beta-User]

Danke für's wieder-vorholen. Hab's direkt ins Wiki eingebaut, nachdem hier doch neuerdings wieder reges Interesse an RS485 (bzw. verkabelten Lösungen) besteht...

[rob]

...Leider ist die Wikispaces-Seite zu den MAX-Modulen (https://arduino-info.wikispaces.com/RS485-Modules) nicht mehr verfügbar...

Du hast es aber im Fhem-Wiki ohnehin schon gut aufbereit. Danke Dir 

Viele Grüße
rob

[Beta-User]

Danke für die nette Rückmeldung!

Komisch ist nur: auch betr. die nRF24L+ gab es bei arduino-info eine Seite. Die scheint - im Unterschied zu der MAX485-Seite - aber mehr oder weniger komplett umgezogen zu sein...

[Ranseyer]

nachdem hier doch neuerdings wieder reges Interesse an RS485 (bzw. verkabelten Lösungen) besteht...

Kommen 'se dann doch langsam zur Vernunft 

Danke für deinen unermüdlichen Einsatz im Wiki usw. ! 

[Beta-User]

Kommen 'se dann doch langsam zur Vernunft 

Danke für deinen unermüdlichen Einsatz im Wiki usw. ! 

Gerne! (Mache es mir selbst ja auch einfacher, wenn alle erforderlichen Quellen an einem Ort sind...)
Aber ohne passende Platinen wäre das immer noch nicht als "einsteigerfreundlich" zu bezeichnen, und ohne "gewissen Testhardware" etc. wären manche Software-Teile auch nicht in's Modul gekommen . Danke zurück also!

[RichardCZ]

Wobei mich ja leichte bis mittelschwere Epilepsieanfälle beim Durchlesen dieser Lektüre heimgesucht haben:
https://forum.mysensors.org/topic/5051/rs485-stress-test

5% Fehlerrate, kein ACK? Ok - ist 2016, und ich bin noch nicht auf dem Laufenden was ab da noch passiert ist.
https://forum.mysensors.org/topic/5327/can-bus-transport-implementation-for-mys

Thread hört auch irgendwie "mittendrin" auf.

Ich hatte jetzt irgendwie einen Mords Reed-Solomon oder mindestens Hamming erwartet, aber nüscht dergleichen.

[Beta-User]

Ähm, also: den SOH-Count vor dem Senden kann man seit längerem im Sketch einstellen (da hat "jemand" einen patch eingereicht, soweit ich mich entsinne, das ist einer der Gründe, warum ich die Zusammenarbeit via github auch nicht nur toll finde...).

FHEM unterstützt auch ACKs (bzw. neuerdings muß man hier wohl "echo" sagen, da ACK als Begrifflichkeit in den MyS-Libs jetzt auf Hardware beschränkt ist, die das selbst liefert - nRF24L+, z.B. ). Ich habe das nicht tiefer verfolgt, weil ich mit den Ergebnissen soweit zufrieden war, würde zur Vertiefung aber mal vorschlagen, du schaust dir die Patches rund um die Einführung des "echo" an; das sieht mir stark danach aus, als gäbe es da einen Zusammenhang. Und nach dem Lesen des Threads habe ich auch wieder eine Idee, warum ich unbedingt Hardware-Serial haben wollte und mein GW mit einem Arduino Pro Micro betreibe .

[RichardCZ]

Und nach dem Lesen des Threads habe ich auch wieder eine Idee, warum ich unbedingt Hardware-Serial haben wollte und mein GW mit einem Arduino Pro Micro betreibe .

Ok. Dann hoffe ich ja mal dass der eingebaute CAN meiner Black Pills auch unterstützt wird und wohltuend wirkt.

Zum Hardware Serial: Prinzipiell könnte man da dann "im Produktivbetrieb" doch auch den vom normalen Nano nehmen - ist man eben die DebugSerialKonsole los, aber das macht ja nix wenn das Ding an Ort und Stelle werkelt - oder?