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

[rob]

Danke Euch für die Blumen + Rückmeldungen   

So geht das optisch etwas unter, oder?

Stimmt - im Edit hab ich es angepasst. Die Beschriftungen sind alle schlecht erkennbar - da lässt Fritzing Wünsche offen. Mal schauen was da noch geht.

Wegen CAN brauch ich noch ein bisschen, weil der MCP2551-Baustein in Fritzing nicht richtig passt. Bin aber dran.

Viele Grüße
rob

[Beta-User]

Danke für das mit der Beschriftung. Das paßt jetzt!

Dann paßt das auch zeitlich gut dazu:

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?).

Nope, jedenfalls für den MCP2551: https://www.sparkfun.com/datasheets/DevTools/Arduino/MCP2551.pdf Der braucht also zwischen 4,5 und 5,5V, Table 1-2 auf S. 4.

Für den "erweiterten" Nachfolger MCP2562 sieht das nicht anders aus, wenn ich das hier richtig interpretiere. Der hat aber den Vorteil, dass die serielle Seite zur MCU hin noch "gedrosselt" werden kann, man also z.B. nur mit 1.8 oder 3.3V betrieben werden kann (falls jemand das z.B. an einen ESP8266 hängen wollte ...). Der STM32-Core müßte an der Stelle sowieso auch 5V vertragen (to be checked).

[Schotty]

..wenn ich mir eine winzig kleine 'kritische' Anmerkung erlauben darf: Ich persönlich mag die Breadboard-Darstellung einfach nicht und ziehe 'normale' Verkabelungsansichten vor, auch wenn die dann auf den ersten Blick vielleicht etwas unübersichtlicher aussehen. Ist aber vermutlich reine Geschmackssache und dürfte auch darin begründet sein, dass ich Breadboards per se einfach *igitt* finde..

Bzgl Beschriftung bei Fritzing:
Schön, dass es mir nicht alleine so geht - das finde ich nämlich auch suboptimal (bin aber auch definitiv kein Fritzing-Experte!).. 


Bzgl 12V & 24V @MCP25xx:
Ich denke, da muss zwischen der Spannung an RX,TX, VDD etc und der CAN(H/L)-Spannung unterschieden werden (wenn ich mich jetzt nicht irre!). Bzgl Letzterem: Wenn eine reine Busverkabelung ohne GND-Verbindung stattfindet, könnte das hier evtl noch interessant und beachtenswert sein: https://microchipsupport.force.com/s/article/MCP2551---MCP2561--no-ground-connection-between-CAN-nodes

[Beta-User]

Ja, das mit der "richtigen" Darstellung ist nicht ganz so einfach... Da hat jeder so seine Vorlieben und jede Darstellung hat vermutlich unter verschiedenene Gesichtspunkten ihre Vor- und Nachteile.

Ihr könnt mir gerne Rückmeldung geben, ob der jetzt im Wiki gelegte "Darstellugnspfad" der richtige ist: Da sind jetzt alle (vorhandenen) Verkabelungsvarianten als Galerie hinterlegt, so dass sich recht einfach weitere Varianten ergänzen (und vergleichen) lassen. (Dass es systematisch ein gewisser Vorgriff ist, kann man m.E. verschmerzen).

Was das GND-Thema angeht, scheint CAN (und der outdated MCP2551...) grade ein paar Punkte gemacht zu haben . (Ich meine, das wäre mir bisher nicht bekannt gewesen, bzw. gekonnt überlesen/vergessen/verdrängt). Könnte es bei nächster Gelegenheit ins Wiki schaffen, darf aber auch gerne mal jemand anders übernehmen .

[Ranseyer]

Klingt auch gut.... laut Datenblatt sollte der LM 1117 Regler aber max. 15 Volt Eingangsspannung bekommen...

Hmm, Gute Frage. Ich hab massig 12V Netzteile herumliegen und sonst hätte ich auch lieber 24V genommen.

Von den *1117-ern liebe ich diese hier: https://www.ebay.de/itm/10-Stuck-10-pieces-LD1117DT50-LDO-5-0V-1-3A-max-SMD-DPAK-AMS1117-1117-NEW/281529082393
Die waren bisher alle original und perfekt. Das mit den 15V im Datenblatt sehe ich auch gerade (wieder).

Bei ausreichend Interesse würde ich nochmals überlegen welchen Regler wir damals für höhere Spannungen ausgesucht hatten...

PS: Ich habe mir diesen Terminator selbst nie gebaut weil die einzige Quelle (Rei***t) ca. 1€ für einen einzigen RJ45 Lötstecker verlangte...

[rob]

..wenn ich mir eine winzig kleine 'kritische' Anmerkung erlauben darf: Ich persönlich mag die Breadboard-Darstellung einfach nicht und ziehe 'normale' Verkabelungsansichten vor...

klar darfst Du, wo kämen wir auch hin, wenn sich keiner mehr was sagen traut 
Es steckt auch keine tiefere Überzeugung dahinter, dass ich die verstrahlten Steckbretter genommen hab. Ich hatte einfach damit losgelegt. Kann ich gerne ändern, dann ist es im Wiki auch einheitlicher.

...bin aber auch definitiv kein Fritzing-Experte!).. 

Ich noch weniger. Ist tatsächlich mein Erstlingswerk.

...Ihr könnt mir gerne Rückmeldung geben, ob der jetzt im Wiki gelegte "Darstellugnspfad" der richtige ist...

Also für mich schaut es super aus. Die Ergänzungen passen gut daneben und man muss zum betroffenen Thema RS485/CAN nicht viel runter scrollen. Schön kompakt.


Das MCP-Modul habe ich mit Inkscape kurzerhand selber entwerfen müssen, weil ich keine fertige Parts-Datei für Fritzing fand. Jetzt wäre aber der erste Wurf für diese Variante griffbereit:
- 12V zentral eingespeist
- MCP2551-Module als Transceiver
- GW Arduino Nano und Nodes Pro Micro (5V-Variante)
- 4-adriges Kabel zu den Nodes
- HWSerial

Ich hab knallhart die Max gegen MCP ausgetauscht und hoffentlich keinen Elektrostuss aufgemalt. Rückmeldungen/ Wünsche wieder gerne.
Sobald final, könnte noch dies interessant sein: ggf. umbauen, von den Steckbrettern weg und 24V-Variante dazu, indem die R1-3-Werte in Klammern stehen könnten.

Tatsächlich ist mir in meiner Grafik der Step-Down-Wandler LZ14203 noch ein Dorn im Auge. Der ist da nur, weil ich in Fritzing nix besseres fand. Kann zwar bis 42V, nur zu kaufen gibt´s ihn wohl nicht.
Wohler wäre mir, wenn wir uns hier auf ein gängigeres Modell einigen könnten, das auch für 24V gleich passt. Das male ich auch gerne nach.

Aktive Terminierung und onboard-CAN á la Maple bzw. Alternativmodule sind ja noch in der Findung, aber das kann man ja ebenfalls noch vormerken.

Vielen Dank für Eure Inputs und beste Grüße
rob

Edit:
- Step Down Wandler LM2576HV eingefügt
- GW und Node1-n=Pro Micro, Last Node=Pro Mini; mit Hinweis
- Verpolung beseitigt

[KarlHeinz2000]

Wegen Terminierung: Ich kenne es nur aus dem KFZ. Da sind die pullup/pulldown nach 5V/GND sehr unüblich. Normalerweise am Anfang und Ende 120R zw CAN_H und CAN_L. Die Knoten dazwischen bekommen einen hochohmigen Busabschluss im Bereich 2..10kR. Normalerweise macht man das auch als Split-Terminierung, d.h. 2x60R in Reihe zw CAN_H und _L und am Punkt zw den Widerständen 4,7..22nF nach GND, auch bei hochohmigen Widerständen. Und falls es starke Störungen gibt noch eine Common Mode Drossel vor dem Transceiver.

[RichardCZ]

Tatsächlich ist mir in meiner Grafik der Step-Down-Wandler LZ14203 noch ein Dorn im Auge. Der ist da nur, weil ich in Fritzing nix besseres fand. Kann zwar bis 42V, nur zu kaufen gibt´s ihn wohl nicht.
Wohler wäre mir, wenn wir uns hier auf ein gängigeres Modell einigen könnten, das auch für 24V gleich passt. Das male ich auch gerne nach.

Ich habe mir die hier besorgt:

https://www.continental.sg/step-down/products/dc-dc-step-down-buck-converter-5-60v-to-1-25-26v-20w-3a-lm2576hv

können alles von 5-60V fressen, Kostenpunkt irgendwas 4-5 EUR Hab's gebraucht weil mein DC System hier eben bis 60V kann/könnte.
Im Normalfall bei 54-55V

[Beta-User]

Die LM2576hv-Module wäre wohl eine gute Alternative, falls die sich im Praxiseinsatz bewähren, die, die ich im Einsatz habe, sind LM2596-basiert (aber die "kleinere" Variante, k.A., welche genau). Letzteren (LM2596) gäbe es auch in einer HV-Variante.

Was CAN bzw. das Widerstands- und Terminierungsthema da angeht:
- Terminierung: Ich kann bestätigen, dass es jedenfalls bis zu meiner Leitungslänge grundsätzlich auch ohne pullup/down geht; allerdings hatte ich das nur kurz im Testbetrieb. Das mit dem Kondensator usw. ist mir neu, vielleicht kann das ja mal jemand mit einem langen Kabel austesten? (Im Kfz. hat man ja typischerweise eher viele, aber tendenziell nicht ganz so lange Kabel und eine recht gute gemeinsame Masse).
- Je mehr man sich damit beschäftigt, desto mehr ist die Variante mit den CAN-Transceivern von der elektrischen Seite her eine valide Sache. Es werden einfach viele typische Fehlerquellen bereits in silicon ausgeschaltet, oder täuscht mich das?
- Was die SPI-CAN-Fragen ("echtes CAN") angeht, bin ich die Tage auch über mind. eine Stelle gestolpert, an der sinngemäß stand, das CAN auch nicht gleich CAN sei, und es auch dort diverse Protokolle gäbe, mit denen die eigentliche Nutzlast dann letztendlich verpackt wird. Da genau das das ist, was das MySensors-Framework letztlich tut, stellt sich mir die Frage, ob eine "Verpackung der Verpackung" überhaupt Sinn macht? Tendiere zu einem "jein": Es macht nur dann Sinn, wenn die "innere Verpackung" nicht gut ist. Wenn (!) das (noch) der Fall sein sollte, wäre es aber m.E. (auch im Interesse der "normalen RS485-Nutzer") besser ggf. vorhandene Schwachstellen am RS485-Transportlayer zu fixen statt noch eine Baustelle aufzumachen...



Zu der "CAN"-Grafik:
Die ist optisch ansprechend, aber inhaltlich bzw. didaktisch "verbesserungswürdig".

- Ein Nano ist ATMega328-basiert und hat daher nur eine serielle Hardwareschnittstelle, nur der Pro Micro (ATMega32U) hat zwei. Beim Nano gehen die RX/TX-PINS daher auch an den USB-seriell-Wandler, auf USB brauchen wir aber den Verkehr zum Controller (FHEM) und können daher nicht gleichzeitig die RS485-Strecke damit ansteuern.
- Ein Pro Micro ist daher (m.E.) eine sehr gute Wahl für das Gateway, man darf nur nicht erwarten, dass sich der zu 100% gleich verhält wie ein Nano, wenn man (beim Starten) den Datenverkehr über die USB-Schnittstelle (z.B. mit dem Seriellen Monitor der Arduino-IDE) betrachtet. (Im laufenden Betrieb ist das was anderes).
- Man kann die Pro Micro auch für die Nodes nehmen. Ist zwar teurer, aber man kann dann ganz normal über die USB-Schnittstelle debugging-Ausgaben haben. Von daher kann der 1-n-Teil bleiben, ich würde aber den Hinweis dazu machen, dass das genausogut Pro Mini sein können ohne debugging.
- Als letzte Node würde ich zur Illustration auch genau so einen Pro Mini darstellen.

Grundsätzlich muß "jemand" dann wohl den Text im Wiki aufbohren und ggf. Sketch-Auszüge für das Hardware-Serial-basierte Zeug mitliefern (z.B. scheint der splash-screen ein Problem zu sein, das hatte ich bis gestern auch nicht mehr auf dem Schirm, es steht nur in meinen Sketchen...).

[KarlHeinz2000]

Mysensor in CAN zu verpacken macht in meinen Augen keinen Sinn. Wenn (ein) CAN Protokoll genutzt werden soll, dann braucht man kein Mysensor mehr. Das bringt das CAN Protokoll alles mit (und noch viel mehr). Allerdings ist das auch viel mehr Aufwand. Ich weiß nicht, ob das noch sinnvoll auf einem kleinen Arduino läuft; würde wohl  gleich einen uC mit integriertem CAN Controller nehmen.
Ich finde an Mysensor schön, dass es einfach ist, Funk und Kabel geht und ich in FHEM nicht noch eine Schnittstelle brauche.

Bei RS485 ist mir nicht so richtig klar was passiert, wenn FHEM nicht erfolgreich senden konnte und wie dann eine Reaktion aussieht.
Aktuell läuft bei mir RS485 ohne jegliche Fehlerüberwachung. Manchmal sehe ich auf meinem Display, dass etwas fehlt bzw. nicht richtig angekommen sein muss.

[Beta-User]

Bei RS485 ist mir nicht so richtig klar was passiert, wenn FHEM nicht erfolgreich senden konnte und wie dann eine Reaktion aussieht.
Aktuell läuft bei mir RS485 ohne jegliche Fehlerüberwachung. Manchmal sehe ich auf meinem Display, dass etwas fehlt bzw. nicht richtig angekommen sein muss.

Falls etwas ankommen muß, gibt es die Möglichkeit, mit ACK-Anforderung zu senden. Dann versucht FHEM immer wieder (mit steigenden Zeitabständen), die Nachricht erneut rauszusenden, bis die Bestätigung kommt - ganz unabhängig vom Transport Layer.

Was verlorene Messages angeht: Ich überwache auch nur, ob die Verbindung da ist, indem die Nodes regelmäßig einen heartbeat schicken. Das paßt soweit, für weitere Details habe ich mich daher bisher nicht so sehr interessiert und kenne dieses Phänomen so nicht.
Generell (falls du das nicht woanders schon geschrieben hast) wäre interessant, wie dein Bus in etwa aussieht (#Nodes, MAX485, ~Länge des Kabels, ~# der Children/Node) (Das betrifft ggf. auch noch andere Mitnutzer: wäre ganz nett, wenn wir da einen gewissen Überblick bekommen würden, aber eigentlich gehört das ja ins MySensors-Forum ).

Ich habe auch das Thema "buffer" nochmal recherchiert: Dazu gibt es zwar eine Einstellung, die ist aber ausschließlich auf nRF24 bezogen. Daher wäre in jedem Fall mal meine Empfehlung Pausen einzuplanen bei einer größeren Zahl vom Messages, die man versenden will (meine "Lieblings-Ausfall-Node" bzw. beim kruezenden Datenverkehr gerne beteiligt war eine, die auf einen Rutsch 12-15 Werte auf den Bus haut. Kommt mir zwar eigentlich nicht viel vor, aber so war's halt...).

[KarlHeinz2000]

Ich habe nur einen kleinen Bus, 3 Nodes + GW, 10..15m Kabel (Telefon, Cat7, ...), dezentral versorgt. 4x MAX... Treiber. 120R am Anfang/Ende. Ein Node liest Wasser und Elt Zähler und sendet relativ oft, einer nur Temperatur und einer hat ein Display.
Generell läuft das seit 5 Jahren stabil. Ich merke nur am Display das manchmal/selten Infos fehlen. Nicht so richtig zuverlässig läuft die Interaktion mit den Tasten am Display. Taste gedrückt -> keine (vollständige) Reaktion am Display. Da gibt es vermutlich kreuzende Daten. Ich habe das aber nie genauer untersucht... Auf FHEM Seite bräuchte ich etwas, dass die Kommunikation bündelt. Jetzt sende ich die Nachricht einfach raus und gut. Wenn ich ACK nutzen sollte, brauche ich etwas das den ACK auf timeout überwacht und dann Fehler meldet? nochmal sendet? Dann nächste Nachricht, ... Bastelt man sich das mit DOIF/notify/at oder gibt es da schon was?
Beim Display habe ich den RX Buffer vergrößert. Es gab Problem beim lesen von SD Karte und vielen RX Nachrichten. Ist eher ein spezielles Problem.

[Beta-User]

Hübsches Display !

Hmm, also bei der Bus-Länge sollte es eigentlich keine Probleme geben, auch ohne pullup/down...

Um das etwas im Detail zu verstehen, wäre noch interessant, wer wann was an wen sendet.

Optionen:
- Von FHEM an Nodes setzt man einfach am MYSENSORS_DEVICE das requestAck-Attribut. FHEM übernimmt den Rest bzw. man kann - bei Unzustellbarkeit - ein weiteres "timeout"-Event erzeugen, indem man noch den passenden Timer setzt (timeoutAck).
- Nodes an FHEM bzw. an andere Nodes geht anders: Da kann man das "echo"-Flag bei der Sendeanweisung im Sketch setzen (früher ACK genannt). Weiß leider grade nicht, wie dann die interne Handhabung auf der Node ist; vermutlich ähnlich bzw. dann nur via Debug zu sehen.
(Falls du also die Temperatur-Node direkt an das Display senden läßt, könnte das zur Verbesserung beitragen).

Beim Display habe ich den RX Buffer vergrößert. [...]

Hast du da den Code-Schnipsel für? Und eine Größenordnung, was das Speicher kostet? Ich hatte auch im Ohr, dass das möglich ist, aber leider gestern die Quelle nicht gefunden bzw. nur den Hinweis, dass das nur bei nRF geht...
Wie hat sich das mit den "Problemen" geäußer?

[KarlHeinz2000]

Der RX Buffer bei RS485 ist der Buffer der seriellen Schnittstelle.
Leider kann man das im Sketch nicht umstellen, sondern nur hart in HardwareSerial.h
Ich hatte da Probleme die richtige HardwareSerial.h zu finden, es waren mehrere auf meinem Rechner...
Den Effekt am besten prüfen, ob beim Kompillieren wirklich mehr RAM verbraucht wird.

Früher war das File hier:
C:\Users\....\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.11\cores\arduino\HardwareSerial.h

Mit dem letzten Update war es plötzlich hier:
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial.h

Code Auswählen Erweitern

#define SERIAL_RX_BUFFER_SIZE 256

[Beta-User]

Danke!

Eigentlich wäre es doch Arduino-üblich, dass man das Flag im Sketch setzen kann? Müßte halt vor der include für mysensors.h stehen? Mal sehen, vielleicht teste ich damit mal bei Gelegenheit rum... (Sowas klappt halt leider nicht immer; auch mit den PINS von AltSoftSerial geht das z.B. nicht, warum auch immer.)