FHEM Forum

Verschiedenes => Bastelecke => MySensors => Thema gestartet von: Beta-User am 22 Februar 2018, 15:14:12

Titel: RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 22 Februar 2018, 15:14:12
Mal wieder was neues zum Thema aufgegabelt, hat zwar nicht nur mit der Baudrate zu tun, wollte es euch aber nicht vorenthalten:
https://forum.mysensors.org/post/86147 (https://forum.mysensors.org/post/86147)

Bin mal gespannt, ob das wirklich was bringt, aber die Kurzfassung wäre die:
Statt MAX48x-Transceivern verwendet man TJA1050 oder MCP2551 (PIN2 würde frei). Der TJA zwingt einem eine Baudrate von 57600 auf, was die obere Grenze von softserial@16MHz zu sein scheint. Dafür wäre aber das Problem gelöst, dass irgendwas den Bus auf Dauer-High zieht.

Wird etwas dauern, aber für den Fall, das jemand die Stichhaltigkeit des Konzepts mit den anderen Transceivern prüfen kann, der da auch den notwendigen theoretischen Hintergrund hat, und ein Mischen unterschiedlicher Transceiver (Standard RS485 und diese) wäre

@Ranseyer vielleicht der Vorschlag, auf den Platinen dann statt des MAX487 einen MCP2551 vorzusehen? Kostet unwesentlich mehr, und ist leider nicht PIN-kompatibel, kommt dafür aber auch mit 9600 Baud klar...
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Brasletti am 22 Februar 2018, 18:15:17
@ Beta-User: Speist du Busspannung extern ein?

Edit: Alternativ Chip für max487, 6LB184 von Ti ist pin kompatibel ESD geschützt und verträgt  400-W Peak ebenfalls 128 nodes (wird von eltako verbaut) und ist gleich teuer wie ein max487 nicht ESD geschützt bei ALI.

Aber ich denke man bekommt den Max487 zum laufen sonst würde der ja nicht verkauft und eingesetzt werden.
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Ranseyer am 22 Februar 2018, 19:26:30
Ich würde mir das gerne mal in Ruhe ausführlicher durchlesen.

Aber zwei für mich gleichwertige Theorien:
Theorie 1: Mein HDMI Eingang am Monitor ist defekt weil ich am Treiber XY eingestellt habe
Theorie 2: Alle RS485 Chips von M.....m sind Müll

Was ich damit meine: Nur weil es Gerüchte gibt würde ich mal nicht so schnell handeln. Der 6LB184 sieht ja auch nicht schlecht aus und es gibt 50 Stück für rund 10€
Maxim hat bestimmt nicht nur 100 Varianten an RS485 Chips.

PS: Mal von Fälschung abgesehen, klar kann man die Chips auch selbst killen.


Zitat von oben:
ZitatIch würde mir das gerne mal in Ruhe ausführlicher durchlesen.


Aber Input ist immer gut. Danke an Betauser.

PS: Ich komme gerade nicht so zu den Sachen wie ich möchte...
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Brasletti am 22 Februar 2018, 19:29:06
Gerade noch mal nachgelesen, das wäre dann auch ein Wechsel zum CAN-Bus mit diesen Chips. Buslänge ist dann maximal bei 250 kbit/s 270m.
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Beta-User am 22 Februar 2018, 22:41:14
Zur Bus-Spannungs-Versorgung:
(Das ist ein guter Punkt, sollte ich mir nach dem Versetzen der Widerstände ans GW nochmal intensiver ansehen...)
Mein Setup besteht derzeit durchgängig aus LC-Tech-Modulen, auf denen statt der MAX485 MAX487 aufgelötet sind. Am GW sind Pullpup- und Pulldown-Widerstände (SMD) à 440Ohm verbaut (R6 und R7, wenn ich das richtig im Kopf habe), die wesentlichen Potentialanteile kommen also darüber von USB. Die 120Ohm sind nur noch am GW und Busende vorhanden. Die meisten anderen Widerstände (R6 und R7) sind von den Modulen runter, was also an sonstiger Spannung da reinkommt, geht evtl. noch über noch nicht beseitigte Restbestände dieser Widerstände (das sind lt. Aufdruck 20k, gemessen hatte ich aber teilweise effektiv auf einer Seite 10k) . Vielleicht sollte ich die auch noch runterwerfen (wo überhaupt noch vorhanden).

Was die Protokollfrage angeht, hatte ich das so verstanden, dass mit diesen anderen Transceivern gerade nicht das  CAN-Protokoll genutzt wird, sondern "nur" die Abschaltfunktion für DE, damit der Bus auch im Fehlerfall der Arduinos frei bleibt, ansonsten sollte auch ein Mischbetrieb mit den MAX gehen. Mal sehen, ob das grundsätzlich funktioniert, Module habe ich jedenfalls mal geordert... Was die Kabellänge angeht, bin ich völlig ratlos, "an sich" war ich stumpf davon ausgegangen, dass die physische Signaldefinition ja gleich ist, sich also nichts grundsätzliches ändert. Aber mit der "Beschränkung" auf 270m könnte ich erst mal sehr gut leben ;) .

Aber nochmal: eigentlich verstehe ich von den ganzen Themen deutlich zu wenig, um behaupten zu können, dass diese Verwendung anderer Transceivermodule eine gute Idee ist. Die "Wegrationalisierung" der DE-PIN's ist jedenfalls erst mal etwas, was mir einleuchtet ::) . In so einer Situation  mach' ich gerne mal auch wegen eines sehr glaubhaften Gerüchts einen Schnellschuß, wenn es effektiv hilft, was plausibleres dazu ist mir jedenfalls seit längerem nciht mehr über den Weg gelaufen.

Wenn sich also jemand damit befaßt, der das auch wirklich versteht, kann es nicht schaden, ich mach' gerne den Tester, wenn ich zum Löten komme und mir die Lust nicht vorher ausgeht...

Gruß, Beta-User
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Brasletti am 22 Februar 2018, 23:38:28
Ich würde erst mal mit einer stabilen Busspeisespannung versuchen.

Dazu wie auf dem Bild mit dem Max die eine Seite Terminieren VCC und GND dann halt vom 5V Netzteil und die andere Seite vom Bus 120ohm.

Zu den Modulen: Sie sind nicht kompatibel mit rs485 also nicht kombinierbar mit den Max Chips!
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Ranseyer am 23 Februar 2018, 08:35:11
>Ich würde erst mal mit einer stabilen Busspeisespannung versuchen.

Absolut. Ich glaub ich schreibe am WE endlich mal einen Post wie man den Bus pysikalisch aufbauen könnte.
Musterplatinen habe sowohl ich hier als auch Brasletti. Die Grundidee war RJ45 Buchsen+ Kabel zu wenden. (Also einfach in eine LAN Verkabelung zu integrieren, Alternativ 4 polige Buchsenleiste)

Den verlinkten Thread kannte ich nicht. Habe aber auch nichts neues herausgelesen.
Natürlich ist wohl richtig dass RS485 nicht für mehrfache Master gedacht ist, man sollte also theoretisch alle Nodes abfragen und diese dürfen nur Antworten wenn diese gefragt werden.
MySensors sehe ich eher als Funkprotokoll, Bei Funkverbindungen sind verlorene Pakete normal, und daher ist es super dass MySensors das ausgleicht.

Das was wir über RS485 machen ist ja auch nichts anderes als funken... Jeder Node plappert wenn er gerade Lust dazu hat. Dabei geht mal ein Paket verloren, und das Protokoll gleicht das aus.
Soweit sollten wir uns einig sein.

Wenn wir jetzt noch HomematicWired und DMX ansehen ist klar dass diese funktionieren. Die Frage die ich nicht beantworten kann ist ob dort der Master die Nodes pollt oder jeder plappern darf wie er möchte.

Zweite Frage ist ob einzelne Chips HW Probleme bekommen wenn mehrere Nodes gleichzeitig senden und was der Grund dafür ist.
Wenn es also Probleme wie beschrieben gibt sehe ich nur die Möglichkeit mit einer ganz sauber definierten Umgebung zu arbeiten/testen. Sauber aufgebaut, vorerst kein Stern, sondern der Bus als Kette, sauber terminiert siehe Brasletti.

Genau das will ich (und denke auch Brasletti) mit einem Set an Sensoren und Doku "Plug&Play" erreichen. PS: Da die Wiki Seite zum Bus bisher unvollständig und ohne Bilder ist und erbärmlich aussieht bsiher auch noch kein Link darauf: https://wiki.fhem.de/wiki/Easy-RS485-Bus
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Ranseyer am 23 Februar 2018, 08:41:08
Zitat6LB184 von Ti ist pin kompatibel ESD geschützt und verträgt  400-W Peak

Ich bestelle mir mal ein paar, und könnte dann auch einige abgeben. 


Zum Thema CAN:
Es spricht ja nix dageben den HW Layer zu verwenden und trotzdem das mySensors Protokoll. Hat jemand schon gelesen ob irgend jemand die Funktion mit MySensors bestätigt hat ? (Mir kam das eher so vor als Test noch ausstehen)
Titel: Antw:Antw:RS485 Default Geschwindigkeit ?
Beitrag von: Brasletti am 23 Februar 2018, 08:54:04
Moin,
von den Ti's würde ich auch welche zum testen nehmen.

Mit der RS485 Integration aus MySensors wird das glaube ich nichts mit Can, funktioniert ja prinzipiell anders. Denke da müsste nen anderer Code noch her.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 09:35:56
@beta-user:
https://www.mikrocontroller.net/articles/RS-485 (https://www.mikrocontroller.net/articles/RS-485) hier steht auch noch was zu den Widerständen. Die Pullups sollten wohl 1kOhm sein wenn keine Terminierung vorhanden. Weiter steht hier, was ich sehr interessant finde, das die 120ohm Terminierung ein Stromfresser ist und mit einem in Serie geschalteten 0,1µF Kondensator verbessert werden kann (evtl reicht der Strom vom USB nicht als stabile Spannungsversorgung des Busses).

Und wichtig: "Die Masse als Referenz sollte man IMMER im Kabel mitführen, auch wenn es scheinbar oft auch ohne funktioniert." Also min. 3 Kabel.

Das System, welches Ranseyer und ich gerade versuchen zu optimieren, hat dann eine zentrale Stromversorgung (12V) für "alle" angeschlossenen Sensoren (Masse und Versorgungsspannung werden immer mitgeführt!) und der Bus kann wenn man die dazugehörigen Busabschlüsse verwendet auf beiden Seiten einfach erweitert werden.

@Ranseyer: Auf der Seite steht noch was über Failsave, meinst du wir sollten die 1kOhm Widerstände dazu auf jedem Modul bestücken? Hört sich eigentlich plausibel an.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 09:50:26
Habs mal aufgesplittet, hat ja nur noch am Rande was mit Baudrate zu tun...

Zitat von: Brasletti am 23 Februar 2018, 09:35:56
@beta-user:
https://www.mikrocontroller.net/articles/RS-485 (https://www.mikrocontroller.net/articles/RS-485) hier steht auch noch was zu den Widerständen. Die Pullups sollten wohl 1kOhm sein wenn keine Terminierung vorhanden. Weiter steht hier, was ich sehr interessant finde, das die 120ohm Terminierung ein Stromfresser ist und mit einem in Serie geschalteten 0,1µF Kondensator verbessert werden kann (evtl reicht der Strom vom USB nicht als stabile Spannungsversorgung des Busses).

S.u., war grade am Tippen...

Zitat von: Brasletti am 22 Februar 2018, 23:38:28
Ich würde erst mal mit einer stabilen Busspeisespannung versuchen.

Dazu wie auf dem Bild mit dem Max die eine Seite Terminieren VCC und GND dann halt vom 5V Netzteil und die andere Seite vom Bus 120ohm.
Stimme dem grundsätzlich voll zu...

Habe heute morgen nach 3 Wochen Dauerbetrieb nochmal gemessen (irgendwo nach ca. 40% der Kabellänge, ausgehend vom GW): 0,3V zwischen A+B, das ist noch etwas zu viel. 0,2V war die "magic number"...

Was die Auslegung angeht, kann ich jetzt entweder hergehen und wirklich am entgegengesetzten Ende zum GW ein Modul mit den Abschlußwiderständen hinhängen und die überflüssigen R's am GW wieder entfernen.

Dabei stellt sich zum einen die Frage, ob ich wie von Brasletti vorgeschlagen die 120 Ohm drauf lasse oder nicht. Tendiere erst mal dazu, das wäre auch das, was sich aus dem hier http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp ergibt, wobei ich dann zu etwas höheren Werten für die Pull-Widerstände tendieren würde (1k); damit sollte sich nach meinen rudimentären Elektronikkenntnissen ein niedrigerer Spannungswert zwischen A und B einstellen...
Dan Bemowski hat hier (https://forum.mysensors.org/post/75693) eine Grafik ohne den zweiten (120Ohm +/-) Widerstand am Master gepostet. Wenn's nicht mit geht, teste ich ggf. auch mal ohne.

An sich ist es aber so, dass da zumindest kein großes Problem mehr bei der elektrischen Auslegung des Bus mehr sein kann, es laufen immerhin 2 (eher 3, aber die eine sendet zu selten, umd das effektiv beurteilen zu können) Nodes recht stabil und senden fröhlich vor sich hin. Bei der derzeit noch immer "zuverlässig" ständig ausfallenden Node vermute ich einen HW-Defekt des Arduino (ist leider nicht gesockelt - da werde ich die HW wohl erst mal tauschen, bevor ich wieder die Kommunikationsebene verdächtige...

Zum anderen kann ich die 5V dann (bei Verlegung weg vom GW) auch über ein LMS1117-Modul (mit Kondensatoren) separat aus den 12V holen statt das von USB abzuzwacken oder ein weiteres Netzteil irgendwo zusätzlich einzubauen. Oder gibt es da grundsätzliche Einwände?
Da habe ich dann auch eher Raum für den vorgeschlagenen Kondensator in Reihe zum R=120Ohm.

Zitat von: Brasletti am 23 Februar 2018, 08:54:04
Mit der RS485 Integration aus MySensors wird das glaube ich nichts mit Can, funktioniert ja prinzipiell anders. Denke da müsste nen anderer Code noch her.
Sehe ich auch so, die spannende Frage bleibt eigentlich die, ob der "Mißbrauch" der CAN-Module möglich ist, wie das von @kimot als problemlos dargestellt wurde. Zumindest für kürzere Busse wäre es deutlich anwenderfreundlicher, wenn hängenbleibende Nodes nicht den Bus auf Dauerhigh ziehen würden.

Zitat von: Brasletti am 23 Februar 2018, 09:35:56
@beta-user:
Und wichtig: "Die Masse als Referenz sollte man IMMER im Kabel mitführen, auch wenn es scheinbar oft auch ohne funktioniert." Also min. 3 Kabel.
Behalte ich im Hinterkopf!

Insgesamt sehe ich aber Licht am Ende des Tunnels ;) .

Danke für eure Unterstützung!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 11:32:39
Zitat von: Beta-User am 23 Februar 2018, 09:50:26

Zum anderen kann ich die 5V dann (bei Verlegung weg vom GW) auch über ein LMS1117-Modul (mit Kondensatoren) separat aus den 12V holen statt das von USB abzuzwacken oder ein weiteres Netzteil irgendwo zusätzlich einzubauen. Oder gibt es da grundsätzliche Einwände?


Wenn du am letzten Node ein "stärkeres" Netzteil verwendest von dem du dann mit einem 1117/5V Regler den Notwendigen Strom abzwacken kannst sollte das dann so ausschauen:



                                              ______5V______
                                              |            |
                                             1117/5V      330Ω (750Ω laut Ti)
A  ___________________________________________|____________|
  |      |        |         |        |        |            |
120Ω     GW      NODE1    NODE2    NODE3    NODE4         150Ω (130Ω laut Ti)
  |      | |      | |       | |      | |      | |          |
  |      | |      | |       | |      | |      | |         0,1µF
  |______|_)______|_)_______|_)______|_)______|_)__________|
B          |        |         |        |        |          |
           |        |         |        |        |         330Ω (750Ω laut Ti)
GND________|________|_________|________|________|__________|



Wegen den Failsafe-Widerständen habe ich nochmals nachgelesen, man braucht diese eigentlich nur ein mal pro Bus. Du kannst also dann auf allen Modulen die Pullups/Pulldowns und Abschlusswiderstände runterschmeißen (Bzw. auf dem GW den 120Ω drauf lassen). (siehe hier http://www.ti.com/lit/an/snla049b/snla049b.pdf (http://www.ti.com/lit/an/snla049b/snla049b.pdf) unter 12 Fail-Safe Biasing)

Hier nochwas zum Kondensator in Serie https://www.mikrocontroller.net/articles/Wellenwiderstand#AC-Terminierung (https://www.mikrocontroller.net/articles/Wellenwiderstand#AC-Terminierung)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 11:44:07
@ Beta-User: ich hab nochmal das Bild korrigiert ;)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 11:50:02
Zitat von: Brasletti am 23 Februar 2018, 11:44:07
@ Beta-User: ich hab nochmal das Bild korrigiert ;)
Die Striche "von B nach unten" kommen mir auch nicht ganz richtig vor. Die Verbindung von B nach GND sollte es doch nur einmal geben (über den Pulldown), oder?

Werde vermutlich mal nachschauen, was mein überschaubares Widerstandssortiment so hergibt, aber die 750Ohm, die Ti empfiehlt, gefallen mir eigentlich sehr gut.

Die 12V habe ich aus einer stärkeren zentralen Verteilung, über die (eigentlich) auch alle Nodes versorgt werden sollen (eine ist noch separat). Die Leitung bis zur letzten Node ist also etwas länger, aber das sollte schon gehen.

Jedenfalls ist das Bild jetzt noch klarer ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 11:56:17
Hast recht, die sind in meinem Eifer entstanden  ;)  Wird korrigiert...

Zum Stromverbrauch hab ich noch was gefunden von Maxim https://pdfserv.maximintegrated.com/en/an/AN1090.pdf (https://pdfserv.maximintegrated.com/en/an/AN1090.pdf)

Auf Seite 8 ist ein schönes Diagramm!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 12:00:09
Evtl. erst mal mit hohem Stromverbrauch (ohne Kondensator) testen und dann mit verschiedenen Kondensatoren ausprobieren.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2018, 14:48:13
Zitathttps://www.mikrocontroller.net/articles/Wellenwiderstand#AC-Terminierung

Das ist aber ein heißes Eisen...

Denke man könnte das bei künftigen Platinen wie folgt einplanen: ein geschlossener SMD Jumper zum aufschneiden über dem Platz eines 0805 Kondensators.
Also im Normalfall nicht genutzt, und auch kein Bedarf eine Brück zu schliessen wenn man es traditionell machen will.

ZitatZum Stromverbrauch hab ich noch was gefunden von Maxim https://pdfserv.maximintegrated.com/en/an/AN1090.pdf
Danke, das ist cool!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 14:59:56
AC-Terminierung ist denke ich auf jeden Fall experimentell, daher auch der Hinweis erst mal ohne testen!
Umsetzen würde ich ich es auch wenn da mehr Interesse besteht bzw. auf künftigen Platinenversionen wie du sagst mit einem SMD Jumper.

Aber wie du auf dem Diagramm auf Seite 8 siehst gibt es da doch Stromsparpotential ;)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 15:18:16
Zitat von: Ranseyer am 23 Februar 2018, 14:48:13
Das ist aber ein heißes Eisen...
Denke man könnte das bei künftigen Platinen wie folgt einplanen: ein geschlossener SMD Jumper zum aufschneiden über dem Platz eines 0805 Kondensators.
Also im Normalfall nicht genutzt, und auch kein Bedarf eine Brück zu schliessen wenn man es traditionell machen will.
Die Jungs von eQ-3 werden schon ihre Gründe haben, warum die für HM-Wired wieder was anderes und eine ganz eigene Art der Busterminierung machen ::) .

Da aber der benötigte Kondensatorwert ziemlich stabil zu sein scheint, spricht eigentlich alles dafür, das wie vorgeschlagen erst mal als Option vorzusehen und dann - sollte sich das als zuverlässig erweisen - kann man immer noch hergehen, und das für neue Platinen standardmäßig öffnen und den Kondensator als Standard vorsehen (bzw. wer will, kann ja dann immer noch eine Lötbrücke drüber legen).

Wenn ich (hoffentlich am WE) dazu komme, das Busende und das GW umzubauen, mache ich das jedenfalls so, dass als Option auch der Kondensator noch Platz findet.

Was die LC-Tech-Modulen angeht: Neben den MAX und den besprochenen drei Widerständen sind da auch noch zwei Kondensatoren mit drauf, und dann noch je ein 1k-Widerstand zwischen den 3/4 Arduino-PINs und den Ein- und Ausgängen.
Da ich bisher die Module benutzt habe, aber auch noch separate MAX487 rumliegen habe und das GW eh' nochmal anfassen muß und die Empfehlung sein soll, die Module nicht zu verwenden:
- sollte ich auch wieder 1k zwischen Arduino-Pin und MAX einplanen? (Sorry, steht bestimmt irgendwo anders geschrieben...)
- sollte man noch was wegen der Kondensatoren tun? Also auf den vorhanden Modulen noch was runterwerfen bzw. (außerhalb des Abschlußblocks) noch was zusätzlich vorsehen?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 15:40:39
Zu den 1K Widerständen sag ich jetzt mal, da müsste man im mySensors Code nachschauen, wahrscheinlich werden die internen Pullups des Atmegas verwendet. Sollte das der Fall sein könntest du die auch von deinen Modulen runter schmeißen. 

Ich würde sie erst mal drauf lassen, auf dieser Seite (uC<->Max487) hat ja alles funktioniert.
Den Kondensator kannst du drauf lassen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2018, 15:56:24
Zitatund die Empfehlung sein soll, die Module nicht zu verwenden:
Das hab ich voerst in dem Thread zu einem universellen Bus geschrieben.

Grund: Man kann kaum sinnvoll 10 solche Module an einen Bus hängen.

1. Somit sehe ich keinen Vorteil mehr an dem Modul wenn man eh etwas änder muss.
2. Müsstest Du wenn du die Teile trotzdem nutzen willst mal einen kompletten Schaltplan malen (oder suchen) um diese restlos zu verstehen, ansonsten weisst du bei einem Fehler nie woran es liegt.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 23 Februar 2018, 16:07:16
Schaltplan gibt es auf jeden Fall hier http://yourduino.com/docs/MAX485-Module-Sch1.jpg (http://yourduino.com/docs/MAX485-Module-Sch1.jpg)
Die 1K Wiederstände sind Pullups und die Kondensatoren wohl zur Spannungsstabilisierung. Da kennt sich Ranseyer besser aus!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 16:14:54
(Jetzt hat sich das wieder überschnitten, ihr seid aber schnell)...

Die 1k bleiben klar auf den Modulen, aber evtl. baue ich das Modul an der letzten Node aus und ersetze es durch einen kompletten "Eigenbau".

Um die Auslegung dieses Eigenbaus ging es mir eigentlich, und dabei stellen sich die Fragen, ob die 1k wieder drauf sollen und ggf. (welche?) Kondensatoren. Entsprechendes gilt, wenn ich das HW-Serial-ProMicro-GW doch nochmal anfasse.
Zu den Widerständen: Da es Pullups sind und ich zu faul bin, den MySensors-Code mal eben so in der Tiefe zu analysieren (in /hal/transport/RS485/MyTransportRS485.cpp bzw. MyTransportHAL.h taucht jedenfalls nichts mit pullup auf), dürfte es zielführend sein, diese Widerstände vorzusehen, auch wenn sich anders verdrahtet zu sein scheinen, als ich das erst angenommen hatte.
Zu den Kondensatoren: Werde mal versuchen zu messen, mit was wir es zu tun haben. Vielleicht hat da jemand ja in dieselbe Richtung gedacht (der 2., der nur bei einer der Typen abgebildet ist, aber bei meinen immer drauf) dürfte die Spannungsversorgung stützen. Könnte also Sinn machen, das zu kopieren...


@Ranseyer
Was die LC-Tech-Module und die Skepsis dazu angeht:
(Noch einen) Schaltplan und weitere Infos gibt es hier: https://arduino-info.wikispaces.com/RS485-Modules (https://arduino-info.wikispaces.com/RS485-Modules)
Solange es auch für Einsteiger "nur" darum geht, Widerstände runterzuwerfen ist das m.E. noch ok, und mehr als 32 Nodes wird auch kaum einer betreiben. Ist vermutlich (auch zum Debuggen) einfacher, als "Hühnerfutter" auf Platinen zu verteilen, deren Schaltplan man (noch) nicht verstandenen hat. Voraussetzung wäre aber, dass man sich bei mehr als drei Nodes dann einfach folgende drei Schritte machen kann:
- einen (komplizierteren) Busabschluß zusammenbauen,
- den 120Ohm am GW beibehalten und nur die anderen beiden eliminieren
- und beim Rest schlicht alle Widerstände R5-7 auslöten.

Das Umlöten auf MAX487 bzw. andere pinkompatible ist auch nicht sooo schwierig, habe ich als Groblöter auch hinbekommen...

Just my2ct
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2018, 16:24:03
Im Prinzip ist ja nur R7 mit den 120Ohm böse.

Alles andere unnötig (wenn im Arduino die Pins richtig konfiguriert sind).
Wobei 10 und 20KOhm ja recht hoch sind und kaum ins Gewicht fallen. (Aber 10*10KOhm bei 10 Modulen parallel wären waren halt nur noch 1KOhm und irgendwann mal gibts dann bestimmt Kummer ab ner gewissen Menge)

PS: Denke mit nett beschrifteten Platinen ist es einfacher. Aber wir sind ja ein freies Land...

PPS: Wenn man den Schaltplan studiert sieht man die die beiden Kondensatoren nichts mit dem Bus zu tun haben sonden nur die Versorgungsspannung etwas verbessern sollen. Die LED könnte auch weg, aber was solls...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 16:33:47
War nicht böse gemeint, und mein Beitrag war zwei mal fast fertig, wodurch ich immer noch was angeflickt habe (das mit den Kondensatoren habe ich dann auch gesehen, aber wieder was löschen?)...

Die Idee, einfach zu handhabende Platinen zu haben ist gut!
Vor allem dann, wenn man nebenbei das Thema der Zahl der Teilnehmer noch verkleinert usw... Also weiter so!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2018, 17:05:31
ZitatIm Prinzip ist ja nur R7 mit den 120Ohm böse.
Ähm, das war auch nicht böse gemeint!

Alles ist gut, und jeder soll bastel wie er will... !
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2018, 17:13:27
Zitat von: Ranseyer am 23 Februar 2018, 17:05:31
Alles ist gut, und jeder soll bastel wie er will... !
::) Mach ich eh' ;D ;D
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 24 Februar 2018, 08:26:52
Damit wir mal etwas diskutieren können hier mal je ein Bild des Signals vom Max487.
(GND ist natürlich zusätzlich zu A+B verbunden und die Messung jeweils gegen GND)

A) Das Signal ganz ohne Terminierung direkt am Sensor gemessen
B) Das Signal mit 150Ohm terminiert und mit je 330 Ohm nach GND und Plus gezogen

Da sieht man schon mal deutlich den Einfluss.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 24 Februar 2018, 10:59:16
Interessant finde ich das "null" Signal ohne Pullup/Pulldown.

Ich hab da auch noch was bezüglich der Kabel und dem spezifischen Wellenwiderstand gefunden:

Beispielhaft einige Werte für verschiedene Kabeltypen aus microcontroller.net:
-Koaxialkabel RG58 und RG174, 50Ω
-Koaxialkabel RG59, 75Ω;
-Twisted Pair CAT3/5/7 für Ethernet, 100Ω
-Flachbandkabel, 150Ω typ.
-Leiterbahnen auf Platinen mit 30...150Ω

Und noch ein Zitat von dort "Eine Leitung wird mit einem ohmschen Widerstand terminiert, welcher den gleichen Wert wie der Wellenwiderstand aufweist."

Meine Frage ist jetzt, ob es nicht Sinn macht auf 100Ω Terminierung (Pullup/Terminator/Pulldown:~330Ω/120Ω/330Ω) umzusteigen wenn wir uns einig sind Twisted Pair Kabel zu verwenden?

Berechnet mit http://dcs-bios.a10c.de/rs485-resistors.html (http://dcs-bios.a10c.de/rs485-resistors.html)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 24 Februar 2018, 12:15:28
Zitat"Eine Leitung wird mit einem ohmschen Widerstand terminiert, welcher den gleichen Wert wie der Wellenwiderstand aufweist."

So soll es sein. Aber 20% hin oder her...
Wenn ich mit 105Ohm rechne bei dem Online Rechner komme ich wieder auf 120Ohm...

Da wird es sich doch stärker auswirken wenn man korrekt beide Enden terminiert...  8)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 24 Februar 2018, 12:23:21
Mach mal nen Screenshot vom Rechner, kann das grad nicht nachvollziehen :)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 24 Februar 2018, 12:27:44
So zum Beispiel
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 24 Februar 2018, 13:04:01
Sieht bei mir auch so aus ;) So wie ich das verstanden hab am passiven Ende RT1=100Ω (bei uns aktuell 120Ω) und am Ende mit der Speisung (Pullup/Pulldown=330Ω) RT2=118~120Ω(bei uns aktuell 130Ω)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 24 Februar 2018, 13:41:52
Kurz mal praktische Zwischenergebnisse, nachdem ich grade den Lötkolben heiß habe:

Rahmenbedingungen: immer noch die LC-Platinen auf MAX487 umgebaut, R5/6 ist noch auf einem Modul, ansonsten sind alle Widerstände runter, bis auf je 120Ohm am letzten im Bus und am GW (Busbeginn). GW hat im Moment noch die 440-er Widerstände drauf, das kommt als nächstes (s.u.), die letzte Node hat jetzt 750Ohm (statt bisher die 20k Standard).

Die Spannung A-B ist damit auf 0,41V hoch (von 0,32V), im Moment sind aber alle Module on. Bei der Tauschaktion habe ich immer nur die Module getauscht, an denen ich gelötet habe (4. und 5. Stelle auf dem Bus). Node 4 habe ich die Tage mehrfach durch einen Druck auf die Reset-Taste versucht, on zu bringen.

Im Moment sind alle Nodes on (Node 2 war bislang off) und senden wie sie sollen. Das ist schon mal gut.

Für den Ausfall der Nodes nach einer gewissen Zeit hätte ich also auch die folgende Erklärungsmöglichkeit anzubieten:
Die interne Abschaltung hat  zugeschlagen und daher lassen sich die Nodes nur wieder ans Netz bringen, wenn man den MAX auch kurz stromlos macht. Dann funktioniert das solange, bis die MAXe wieder zu heiß werden, was vornehmlich dann passiert, wenn viele Werte nacheinander gesendet werden sollen (was erklärt, dass die BME-Node am längsten mitmacht). Das Wäremethema wiederum hängt mit der (zu hohen) Spannung auf dem Bus zwischen A und B zusammen, gegen die der MAX anarbeiten muß.

Werde jetzt also das GW unter den Lötkolben nehmen und dort R5/6 runterwerfen. Dann sollte die Spannung A-B bei unter 0,1V liegen; damit sollten die MAX gut klarkommen.

Wenn das so paßt, würde ich dafür votieren, höhere Werte für die Pull-Widerstände vorzusehen (also eher die Ti-Werte zu verwenden, oder sogar noch höher). Das dürfte sich doch auch positiv auf den Strombedarf auswirken, oder?

Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 24 Februar 2018, 14:03:47
So wie ich das verstanden hab sollte man an den Nodes busseitig am max gar keine Pullwiderstände haben da kapitulieren ansonsen irgendwann die Treiber. Wenn du dir den Rechner aus meinem vorigen Beispiel anschaust schreibt Thomas Kugelstadt, Senior Applications Engineer at Texas Instruments der wert der Pullups am Busende sollte bei einem "Failsafe" RS485 Bus den wert von 469Ω nicht überschreiten (die wiedersprechen sich wohl manchmal)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 24 Februar 2018, 15:13:27
Soweit die Theorie...
Das will nicht so recht in meinen Kopf, warum niedrigere Werte gut sein sollen für die Pull-R's. Das führt doch dazu, dass die Spannung im idle-Zustand deutlich höher liegt als die 0,2V, die eine Dauer-1 sind, oder übersehe ich da was grundlegendes?
Die Dauer-1 könnte vor allem deswegen nicht optimal sein, weil bei der MySensors-Lösung - anders als von der Spec an sich vorgesehen - ja kein wirklicher Master da ist, der Sendezeit zuweist. Kollissionen kommen daher evtl. viel häufiger vor und das führt dann zu den beschriebenen Sypmtomen? 

Aktuelle Praxiserfahrung: Node 2 ist arduino-seitig ziemlich schnell mal abgestürzt (schnelles LED-Blinken - war das nicht das Zeichen für zu wenig Saft?!?) und hat den Bus auf 2,5V gezogen, dann ging wieder gar nix mehr...
Es sieht so aus, als hätte das (oder eine andere Aktion aus den letzten zwei Stunden) zur Folge gehabt, das der MAX am GW zu heiß geworden war - da ist Isolierband zwischen dem Modul und dem Arduino auf das Modul geklebt, und das war verschmort. Das kann natürlich auf früher passiert sein, aber  m.E. ist das eher unwahrscheinlich. In jedem Fall stammt die Schmorstelle aus den letzten drei Wochen.

Mit den 750Ohm und keinen Pull-R's am GW hatte ich ansonsten standardmäßig 0,2V, also eigentlich immer noch zu viel.

Jetzt habe ich eben mal testweise 2,2k für R5/6 am Busende verwendet, damit liegt die Spannung A-B bei 0,08V. Alle Nodes sind im Moment online und senden (3 und 4 waren immer unter Spannung, ich hatte nur Node 1 und 2 resettet und Node 5, da am Busende).

Jetzt lasse ich erst mal das Modul mit den 2,2kOhm-R's im Einsatz und geh' alle Nodes nochmal durch wg. der überflüssigen 20k-Widerstände.

Mal schauen, wo die nächste Baustelle aufgeht bzw. wie lange es so funktioniert...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 24 Februar 2018, 15:20:34
Was für Sensoren hast du da nochmal im Einsatz auf den vier Nodes?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 24 Februar 2018, 15:58:09
Auf die Schnelle so ungefähr ;) :

Node 1:
11*DS18B20 auf 3 PINs (alle 5 min)
3*Bewegungsmelder (derzeit nur einer angeschlossen - so ein "Radar"-Dingens)
1 Relay
1 Zähler (interrupt-basiert)

Node 2:
7*DS18B20, ebenfalls 3 PINs (wenn nix besonderes ist: alle 5 min)
1 Servo (derzeit nicht angeschlossen)
1 Relay
1 Zähler

Node 3: BME280 mit Temp/Hum/Pressure/Forecast, sendet jede Minute (vorrangig, damit ich einen "heartbeat" habe, ob der Bus ok ist)

Node 4:
4 Relays
2 DS18B20 (alle 3 Min)

Node 5:
2 Bewegungsmelder (einer derzeit angeschlossen, wieder "Radar")
1 Relay

Nur die Node 4 und das GW hängen nicht an der 12V-Versorgung.


Zum Rest:
Ein Modul hatte ich noch mit den 20k-R's, das habe ich "gesäubert", jetzt liegt A-B auf 0,13V-Niveau, (Busende mit 2,2k).

Jetzt mache ich mich nochmal dran, das Pro-Micro-GW zu reaktivieren, wenn sonst erst mal alles sendet, wie es soll ;) .

Bis dahin: Danke nochmal für den Schubser Richtung Busdesign, auf den Gedanke, dass die Chips eine Selbstabschaltung haben, die manche beobachteten Effekte einleuchtend macht, wäre ich sonst nicht gekommen ::) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 25 Februar 2018, 14:41:29
Zitat von: Beta-User am 24 Februar 2018, 15:13:27
Jetzt lasse ich erst mal das Modul mit den 2,2kOhm-R's im Einsatz und geh' alle Nodes nochmal durch wg. der überflüssigen 20k-Widerstände.

Mal schauen, wo die nächste Baustelle aufgeht bzw. wie lange es so funktioniert...
Zwischeninfo: Funktionierte nicht besonders lange. Node 2 hatte gestern abend kurz nach halb elf genug, Node 4 hat sich sogar noch früher verabschiedet und auch Node 5 meldete keine Bewegung heute morgen, obwohl definitiv jemand dort war. Spannung A-B lag bei 0,07V. Nach einem Neustart der Node 2 war dann wieder für einige Zeit gut, aber dann wieder dasselbe. Nodes 1 und 3 laufen und laufen wie vorher auch schon. Das Dauer-schnell-Blinken bei Node 2 hatte ich übrigens nicht wieder.
Jetzt neige ich dazu, mal noch höhere R-Werte zu nehmen (4,7k, die habe ich halt grade da). Aber die Zuversicht ist nicht besonders groß, dass das wirklich was bringt.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 25 Februar 2018, 14:50:13
Waren das die, die sonst auch gestreikt haben?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 25 Februar 2018, 15:23:18
Ja.

Ich kann auch keine wirkliche Regel erkennen, die m.E. auf irgendeinene gemeinsame Ursache hinweisen würde:
Weder sind das die nur am Busende, noch haben die dieselbe bzw. alle eine andere Spannungsversorgung, noch ist am Sketch irgendetwas außergewöhnlich.
Habe vorher nochmal nachgesehen, Node 1 und Node 2 senden zwar viele Werte, aber bei beiden sind zwischen den einzelnen Sendungen kurze wait() drin (40ms bzw. 50ms). Das sind beides auch HW-serial-Nodes, ebenso wie Node 4. Node 3 und 5 sind altsoftserial-Nodes. Die beiden haben auch einen zusätzlichen 1117-5V-Wandler.

Jetzt teste ich mal mein ProMicro-GW (ein wait(2000) in preHwInit(), und man sieht dieselbe Startausgabe wie bei einem Nano :) ), dann löte ich den neuen End-Baustein und zum Schluß drehe ich die Baudrate mal noch weiter nach oben.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 25 Februar 2018, 16:58:06
So, das GW wollte nicht (das blieb auf disconnected?), und mit dem 4,7k-Endbaustein läuft der Bus gerade mal wieder. Alle Nodes senden, mal schauen, wie lange...

Das mit der Baudrate mache ich dann bei anderer Gelegenheit mal.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 25 Februar 2018, 18:52:56
Ich habe gerade getestet was die MAX487 aushalten ...

Startpunkt war mal ein extra Testnetz mit Sensoren aufzubauen.
Also habe ich die Platine vom dritten Kasten genommen mit AMS1117 / 5V versehen...

Um den AMS 1117 zu testen habe ich mal knapp 13V angelegt (15V ist das Maximum)
Aushalten soll der angeblich 1W Verlustleistung.
Bei 20mA *8V zum verheizen wäre das knapp 0,2Watt. Aus irgendeinem Grund sah ich im Augenwinkel abe mal spontan 2-3 Ampere Strom und anschliessend wurde der Max487 mit 12V versorgt. => tot. Selbes Experiment nochmals mit früherem Abbruch, Spannung nur auf 5,8V angestiegen => auch der MAX487 tot...

Ich mache mal einen neuen Tread zu gefälschten Bauteilen auf um zu klären warum der Aufdruck der Spannungsregler nicht soo hochwertig ist...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 25 Februar 2018, 19:40:01
Ein schöner Verteiler für nen sternförmigen Bus:
https://de.aliexpress.com/item/DIN-Rail-Mount-RJ45-Module-RJ45-8P8C-Jack-9-Way-Buss-Breakout-Board-Terminal-Block-Connector/32794351655.html

(Würde ich dringend davon abraten bei den aktuellen Diskussionen! -trotzdem schick...)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 26 Februar 2018, 07:44:16
Grummel, das wird ja immer noch blöder, wenn man jedes Bauteil nochmal vor dem Verbau testen muß...

Angeblich sollte der MAX 485 12V vertragen, ist das bei dem MAX487 weniger?

Was mein setup angeht: ich wäre jetzt davon ausgegangen, dass eine Node mit einem falschen AMS1117 dann auf der 5V-Schiene so viel zuviel abbekommt, dass der Arduino hops geht - meine senden aber nach einem Poweroff dann wieder für eine gewisse Zeit, und dann ist erst eine ganze Zeit später wieder Schluß.

Das trifft übrigens auch auf den 4,7kOhm-Abschluß zu. Die Zeit bis zur letzten Sendung meiner beiden speziellen Nodes war ca. 6 Stunden, die letzte Sendung von Node 2 erfolgte 17 min. nach Node 4, Node 5 lebte heute morgen noch, das ist immerhin ein Fortschritt (ich sollte mal noch einen zyklischen Wert dazupacken, dann ist das leichter zu monitoren...).

Die zeitliche Nähe könnte auf ein Busproblem oder ein ähnliches elektrisches Problem hindeuten, allerdings sehe ich grade, dass Node 2 2 Min. vor dem Ausfall von Node 4 einen reboot hatte?!? Da werde ich (mindestens) diese beiden Nodes doch besser nochmal einer Generalüberprüfung unterziehen...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 27 Februar 2018, 18:15:25
Ist vielleicht hier OT, aber einen neuen Thread wollte ich auch nicht unbedingt aufmachen:
Wegen des beobachteten spontanen Reboots, habe ich jetzt mal das log aus Februar ausgewertet (um das besser zu monitoren, sind jetzt alle MySensors-Nodes in einem logfile vereint).

Das Ergebnis ist irgendwie nichtssagend, aber eben auch nicht lustig:
Die Nodes 2 (ID: 102) und 4 (ID: 101) fallen nicht nur immer wieder mal wieder aus, sondern haben auch die Angewohnheit, zwischendurch mal neu zu starten, manchmal nach einer gewissen offline-Zeit, manchmal auch nur "einfach so". Mind. 5 reboots für die ID 102, 4 für 101 (davon einige die letzten 48h).

Wenn man überhaupt ein Muster erkennen kann, dann evtl. das, dass man im zeitlichen Umfeld zu den tatsächlichen Sendungen bzw. dem erwarteten Zeitpunkt von neuen Werten Kollissionen mit anderen Nodes vermuten könnte.
Meine Spekulationen dazu poste ich gerne mal gesondert, aber ich werde wohl zum einen noch die 7,5k-Variante ausprobieren (seit den 4,7k könnte man unterstellen, dass Nodes eher "wiederkommen") und zum anderen noch überall wait()-Anweisungen einbauen (manche Nodes senden noch 2-3 Werte auf einen Rutsch.

Seltsam finde ich auch, dass gerade die Nodes mit den niedrigsten Nummern (oder ohne 0 bis 3 in der Nummerierung?) scheinbar nicht diese Symptomatik aufweisen.

Vielleicht hat ja sonst jemand noch eine Idee...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 27 Februar 2018, 22:26:39
Einbruch der Spannung am Node ? (47 oder 100uF oder so Kondensator an einem Node zum Test verbauen...)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pula am 28 Februar 2018, 00:05:34
Woo, woo...
Ihr Jungs (und Mädels?) seid aber high sophisticated unterwegs, da bin ich leider ausgestiegen.
Da ich für meine MySensor-Nodes EIB-Kabel verlegt habe und noch 3 Pins frei habe (weil derzeit nur als Spannungsversorgung), überlege ich, auf ein verkabeltes Bus-Sytem umzusteigen. Aber was Ihr hier schreibt, ist mir um einige Größenordnungen zu hoch :-(
Vielleicht mag mal jemand von Euch das zusammenfassen?
Cheers,
Pula
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 28 Februar 2018, 07:45:50
@Ranseyer: Hatte zwar insbesondere an der 102 (pro mini) auch noch einen weiteren AMS1117 in Modulform drauf gemacht. Da sind auf der Versorgungs- und 5V-Seite auch je Kondensatoren drauf. Aber scheinbar brauchen die MAXe doch richtig Saft...
Danke für den Tip, werde berichten!

@Pula:
Was genau willst du wissen bzw. was ist zu hoch? In Kurzform:
- RS485@MySensors funktioniert im Prinzip wie "normales" MySensors, nur dass man eben in den Sketchen den Kommunikationslayer tauscht. Einzige echte Besonderheit ist, dass man die Node-Id im Sketch festlegen muß. Schau dazu die Beispielsketche@MySensors.org an (GW+Motion, meine ich, sind am Namen zu erkennen).
- 2 bzw. 3 Adern sind erforderlich (A, B und ggf. (zu empfehlen) GND)
- Verkabelung kannst du auf MySensors.org nachsehen, was wir hier diskutieren, ist die Frage, wie die Widerstandswerte an der letzten Node bzw. als Busabschluss aussehen sollen und welche Transceiver man am besten nutzen sollte (und ggf. wie schnell die Daten übermitteln).

Zum Testen, wenn du nicht so viel löten willst (ohne geht es nicht!): Die LC-Electronics-Module vom MAX485 auf MAX487 umlöten (geht erst mal auch so mit MAX485), dann aber die meisten Widerstände auslöten (GW+Busabschluß behalten je den 120-Ohm Widerstand, meine Tendenz wäre dann, R5 und R6 bei den Modulen eher höher zu wählen, als sich das eigentlich nach dem verlinkten Widerstandsrechner ergeben würde (4,4kOhm bzw. 7,5kOhm statt ca. 400Ohm). Aber da beginnt die Magie (scheinbar bin ich im Moment der einzige, der wirklich einige Meter Kabel verlegt hat und das unter Echtbedingungen testen kann; leider bin ich aber weder der Held beim Löten noch in der theoretischen elektr. Auslegung solcher Sachen...).
Sehr wichtig scheint dabei zu sein, dass die MAX48x genug Spannung bekommen, sonst gehen die vom Netz und stören ggf. die gesamte Kommunikation - das ist dann nicht besonders erfreulich.

Wenn Ranseyer seine Platinen fertig hat, wäre es vermutlich besser, die zu nehmen und ggf. auch andere Transceiver (die scheinen in der Regel PIN-kompatibel zu sein, das sollte sich also ggf. tauschen lassen).

Zur Erläuterung noch zu den diskutierten CAN-Bausteinen:
Ich hatte häufiger den Fall, dass einer der Arduinos seinen Baustein auf Dauersenden geschalten hatte (DE high). Dann geht nichts mehr. Die CAN-Bausteine erkennen sowas und geben den Bus dann selbständig wieder frei. Die Frage ist nur, ob das einen anderen Kommunikationslayer in den Sketchen erfordert, oder ob das "einfach so" geht (wenn, dann muß man aber andere Bausteine/Platinen verwenden, die IC's sind nicht pin-kompatibel).

Ich hoffe, ich habe dazu nichts unterschlagen. Wenn es dann mal zuverlässig tut, ergänze ich auch den Einsteiger-Guide im Wiki (wenn es jemand jetzt schon besser weiß und zuverlässig am laufen hat: nur zu!).

Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 28 Februar 2018, 10:12:06
ZitatWenn Ranseyer seine Platinen fertig hat, wäre es vermutlich besser, die zu nehmen

Ich habe genügen Varianten in der Schublade um alles zu testen... => bei Interesse PN!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 28 Februar 2018, 10:29:53
@beta-user: hast du die Nodes und das GW jetzt alle an einer gemeinsamen Masse? Lies dazu mal https://www.mikrocontroller.net/topic/306725#new (https://www.mikrocontroller.net/topic/306725#new) (must halt filtern, ist auch etwas Mist dabei) Evtl. ist das ja auch ein Grund für deine Schwierigkeiten.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 28 Februar 2018, 11:21:46
@Brasletti:
Steht auf der todo-Liste, bisher tanzen Node 3 und das GW noch aus der Reihe.

(Auch wenn ich im Moment eher noch die Probleme jeweils auf den einzelnen Nodes sehe, weil ja immerhin seit einigen Wochen 2 Nodes + GW sauber miteinander kommunizieren und jedenfalls seit Verwendung der höheren R-Werte nicht mehr der ganze Bus ausgefallen war).

Da aber die Einbeziehung von Node 3 ein größerer Umbau wäre (leider im Kalten), muß das noch etwas warten, zumal mich (und ggf. auch andere) auch interessiert, welche Einzelmaßnahme denn wirklich zu Verbesserungen führt. An sich war aber schon immer der Plan, auch diese Node an die zentrale 12V-Versorgung anzuklemmen, dann wäre auch da GND auf einem einheitlichen Potential, und eine Ader für das GW findet sich dann auch noch ;) .

Prio 1 ist m.E. daher der Einbau der Kondensatoren, das schadet jedenfalls nicht. Die Spannungsversorgung hatte ich eh' schon länger in Verdacht (deswegen hatte ich teilweise ja auch die zusätzlichen 1117 eingebaut). Mir war offen gestanden allerdings bis dato nicht klar, wieviel Strom die MAX48x-e tatsächlich ziehen, wenn sie richtig am "arbeiten" sind. Prio 2 wäre dann, zu vermeiden, dass es zu längeren Kollissionsphasen kommt.

Zu den Platinen:
Habe zwei der 1. Generation mit den teilweise invertierten Beschriftungen im Einsatz :D , nochmal Danke @Ranseyer!
Die anderen (1, 2 und 5) sind umgebaute nRF-Nodes, da habe ich im Moment wenig Lust, alles nochmal zusammenzulöten. Siehe Post #38: Da sind einige Leitungen dran, deswegen ist es auch nicht so easy, die einfach mal abzuklemmen und dran rumzulöten... Bin ja froh, dass wenigstens die Arduinos und Transceivermodule ganz überwiegend gesockelt sind, dann geht wenigstens das Umflashen halbwegs flott. Nur Node 3 wollte ich diesbezüglich nochmal anfassen, aber da soll auch noch einiges an Funktionalität dazukommen ::) , was aber waren kann bis wieder Frühjahr ist.

Generell würde ich aber noch für zukünftige Platinen-Versionen vorschlagen, HW-serial statt altsoftserial-PIN 8/9 als Option vorzusehen. Könnte eine Lötbrücke sein, die man halt schneidet (weg von 8/9) bzw. brückt (zu RX/TX). Ist der code fertig, braucht man ja keine debug-Ausgaben mehr bzw. uU. reicht der Speicher sonst nicht (BME280 mit forecasting ist schon recht eng...).
Oder eben einen ProMicro statt des ProMini vorzusehen, wenn wir das wollten und erfolgreich getestet haben.
An STM32F1 oä. als Basis mag ich gar nicht denken (wäre aber in der Planung für Node 6 ;) ).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 28 Februar 2018, 12:26:41
Zu der GND-Diskussion noch als Merkposten: https://www.mikrocontroller.net/topic/306725?reply_to=3299668#postform
ZitatIch habe bisher gute Erfahrungen (mit industriellen Drehgebern per SSI
Protokoll) damit gemacht, das der Master den GND niederohmig verband und
die Slaves per Widerstand die Masse gegen ihren GND zogen (ca. 1k-10k).
SSI läuft allerdings zwar differentiell, benutzt aber verschiedene
Pärchen für Clock, und den Hin- und Rückweg. (Insgesamt also 3 Pärchen)

Das sieht mir vom Prinzip her nach einem Weg aus, meine Bauchschmerzen beim GND des GW zu unterdrücken, sollte es bis dahin nicht funktioniert haben ::) . Also einfach dort einen Widerstand (beginnend mit 10k) einbauen..
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 28 Februar 2018, 17:40:42
ZitatHW-serial statt altsoftserial-PIN 8/9 als Option vorzusehen
Haben wir in den aktuellen Versionen die in der Schublade liegen schon drin !
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 01 März 2018, 11:13:44
Zitat von: Ranseyer am 28 Februar 2018, 17:40:42
Haben wir in den aktuellen Versionen die in der Schublade liegen schon drin !
...hätte ich mir eigentlich denken können ;) ...

Zu den Kondensatoren: habe gestern abend bei Node 2, 4 und 5 mal je einen Elko 100uF direkt an die Sockel für die LC-Module angelötet. Das brachte leider keine spürbare Verbesserung  :( . Insbesondere Node 2 hatte heute auch schon wieder (mind.) einen spontanen Reboot, Node 4 ist über Nacht auch wieder offline gegangen.

Dann werde ich mich am WE wohl mal warm anziehen und auch Node 4 noch mit auf die 12V aufklemmen ::) , dann haben alle bis auf das GW einen gemeinsamen GND.

Dennoch würde ich weiter darauf tippen, dass es eher etwas mit dem Code zu tun hat. ixquick liefert bei der Suche nach dauer-schnellblinkenden Arduinos nämlich nicht "zuwenig Saft", sondern u.a. auch mind. einen Hinweis, dass es sich um eine Art Speicherüberlauf handeln könnte bzw. um einen auf den Bootloader verweisenden fehlerhaften pointer (was immer das heisst ??? ).
Step 2 wäre dann der Versuch, die Sendungen noch etwas weiter zu entzerren (wait() einfügen bzw. die Zeiten noch etwas verlängern).

Schaun' wir mal, dann sehn' wir mal...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 01 März 2018, 11:39:02
Senden die anderen Nodes denn weiter wenn ein Node abschmiert? Hört sich für mich so an als würde der Bus weiterlaufen, oder?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 01 März 2018, 12:10:03
Jedenfalls seit der Erhöhung der Widerstandswerte am Busende auf 1k und höher hatte ich _keine_ Komplettausfälle mehr.

Vorher schon, was aber vermutlich daran lag, dass eine Node ihren MAX auf Dauersenden gezogen hatte (DE high). Ich habe auch teilweise immer mal wieder gemessen, da war auch erkennbar, dass die Spannung A-B immer weiter nach oben gegangen ist, bis eben am Ende ca. 2,5V erreicht waren. War die betreffende Node dann kurz ohne Spannung, ging häufig zumindest ein Teil der Nodes wieder online (am verläßlichsten die BME280-Node (98=Node 3, altsoftserial auf Ranseyer-Platine)
Am WE hatte ich mehrfach gemessen, die Werte habe ich ja gepostet. Von daher auch meine Annahme, dass der Bus von der elektrischen Seite her jetzt an sich in Ordnung zu sein scheint.

Ist immer schwierig, im Nachhinein zu rekonstruieren, was passiert ist, und an was es dann im einzelnen wirklich lag. Ziemlich am Anfang war es mal so gewesen, dass immer die 98 (Node 1) abgeschmiert ist. Da ist ein Bewegungsmelder dran, und die Logik hat der Arduino dann teilweise noch Stunden nach der letzten Meldung über den Bus sauber ausgeführt, bis dann irgendwann auch da Ende Gelände war. Daher auch die Vermutung, dass es sich evtl. um ein Speicherproblem handeln könnte.

Vielleicht hat das ganze auch (teilweise) mit dem hier zu tun: https://github.com/mysensors/MySensors/issues/954. Auch da scheint es so zu sein, dass sich die Kommunikation irgendwann verabschiedet hat, der uC aber weiter lief. Dann wäre es in den Untiefen des MySensors-Codes oder darin verwendeter libs verborgen...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 März 2018, 16:04:33
Ich nutze jetzt auch die HW Serial für RS485. Allerdings gab es Probleme beim Programmieren des Arduino (ProMini), da der RX vom Bustreiber gegen den FTDI vom Programmieradapter gearbeitet hat. Ging nicht!
Lösung bei mir: Den /RE an einen Port und über 10k auf 5V. Während Reset/Programmieren ist der Port auf input und der Pullup schaltet den Receiver aus. In der Anwendung (Setup) wird der Port auf Output Low gesetzt und dann nicht mehr geändert. So geht es bei mir. Kostet halt einen Port...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 02 März 2018, 16:11:43
Zitat von: KarlHeinz2000 am 02 März 2018, 16:04:33
Kostet halt einen Port...
Na ja, effektiv gewinnst du einen (8 und 9 werden ja frei) und eine ganze Menge Speicher.
Danke für's posten dieser Lösung!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 02 März 2018, 16:19:25
Also wenn ich das richtig verstanden hab schaltest du im Sketch den RS485 Chip dann zu sobald der Sketch läuft, oder? Interessanter Ansatz!! Würde einem beim häufigen Flashen auf jeden Fall den Griff zum Lötkolben ersparen ;)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 März 2018, 16:27:21
@Brasletti: ja, so ist es.

@Beta-User: Ich spare leider keinen Pin, da die debug Ausgabe über AltSoftSerial auf pin8/9 läuft 8)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 02 März 2018, 16:33:19
Zitat von: KarlHeinz2000 am 02 März 2018, 16:27:21
@Brasletti: ja, so ist es.

@Beta-User: Ich spare leider keinen Pin, da die debug Ausgabe über AltSoftSerial auf pin8/9 läuft 8)
Na ja, zur Not muß man halt (mind.) einen Port-Extender nehmen oder auf die Debug-Ausgaben verzichten (das ist ja vermutlich eh' das längerfristige Ziel, sonst wäre die Übung nur dem Verdacht geschuldet, dass die altsoftserial-lib iVm. RS485 mit ein Grund ist, warum es Probleme geben kann).

Bisher hatte ich meine Arduinos + die Module ganz einfach gesockelt, da gab es das Problem auch nicht ;) . Habe aber auch den Bauraum dazu...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 März 2018, 16:56:22
Ganz ohne debuggen bekomme ich die Sachen eigentlich nicht ans Laufen  :-\
Und zu der HW-Serial habe ich mehr Vertauen, da ich die Latenzzeiten der ganzen Arduino Libs in einem voll gepackten Sketch nicht abschätzen kann, gerade wenn andere IRQ aktiv sind.

Allerdings läuft ein einfacher SW-serial Node auch seit längerem ohne Probleme.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 02 März 2018, 17:04:24
Zitat von: KarlHeinz2000 am 02 März 2018, 16:56:22
Ganz ohne debuggen bekomme ich die Sachen eigentlich nicht ans Laufen  :-\
...damit bist du nicht alleine...
Aber der Ansatz ist interessant, erst mal mit SW-Serial zu debuggen. Ausschalten kann man das später immer noch. Hast du mal ein einfaches Beispiel dazu? (Kann auch gerne bei "Interessante Sketche..." sein)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 März 2018, 17:07:28
Ist zum Glück nicht schwer  :)
Melde mich später von daheim noch mal.

EDIT:

So, schnell mal zusammenkopiert.
Die Ausgaben der MYS lib kommen automatisch raus. Die eigenen Ausgaben dann hier mit altSerial.print();


#include <AltSoftSerial.h>

#define MY_DEBUG              //MYSENSOR lib

#define MY_BAUD_RATE (9600)                      //MYS debug, braucht man das wirklich?
#define MY_SPLASH_SCREEN_DISABLED        //MYS bug, SPLASH SCREEN kommt sonst auf RS485 raus

#define MY_DEBUGDEVICE altSerial

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 9600

#define MY_RS485_HWSERIAL Serial

AltSoftSerial altSerial;

#include <MySensors.h>

void before()
{
  altSerial.begin(9600);

  altSerial.print(bla);
  altSerial.println(blub);
}
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 04 März 2018, 15:38:53
@KarlHeinz2000:
Danke für die Infos.

Bei der Gelegenheit auch noch ein Update zu meinem Bus-Thema: Jedenfalls seit etwas mehr als 5h hatte ich keine spontanen Reboots oder sonstigen wesentlichen Ausfälle mehr :) .

Das Hauptproblem bei der Node 2 (#102) scheint der Arduino gewesen zu sein: Den hatte ich jetzt wieder getauscht, nachdem ich (auch bei dem) den Code dahingehend geändert hatte, dass zwischen allen Sendungen eine Pause (aktuell: 100ms) drin ist. Wie es ausschaut, hat diese Node dann auch den Rest aus dem Tritt gebracht. Dann hat Node 5 eine neue Nummer (statt ID 103 jetzt ID 99).

Wenn es weiter stabil läuft, würde ich sagen, dass es vermutlich mit einem nicht defekten Pro Mini ausreichend gewesen wäre, den Kondensator einzubauen. Aber jetzt sind die Denkpausen drin, jetzt bleibt das auch so...

Ich werde berichten, wenn es doch noch wieder Schwierigkeiten geben sollte.

Jetzt kann es dann mit weiteren Nodes weitergehen (da war doch noch was mit RFID ;) ).

Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Brasletti am 04 März 2018, 15:49:41
Das hört sich doch mal vielversprechende an ;) , bin sehr gespannt ob er jetzt stabil läuft.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 04 März 2018, 16:13:56
...zu früh gefreut, #102 hat sich just in dem Moment zum letzten Mal gemeldet, als ich das geschrieben habe...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 15 März 2018, 16:47:23
Wie bereitet man die RS485 Signale auf ? (z.B. einen Stern ohne schlechtes Gewissen aufbauen...)

Die Musiker wissen es ! Danke an Björn (https://forum.fhem.de/index.php/topic,85299.0.html) !

Darüber habe ich entdeckt:
https://www.pcdimmer.de/images/stories/Schematics/old/pcdimmerdmx512splitter.png (https://www.pcdimmer.de/images/stories/Schematics/old/pcdimmerdmx512splitter.png) oder http://www.ulrichradig.de/home/index.php/dmx/dmx-splitter-booster (http://www.ulrichradig.de/home/index.php/dmx/dmx-splitter-booster)
Das finde ich spannend zur Aufbereitung eine RS485 Signals in manchen Fällen...


Also "einfach" ein paar potentialfreie Spannungen auftreiben , pro Anschluss ein RS485 IC +Optokoppler. (Und hoffen/besser:wissen dass der Optokoppler passt)


Beispiel siehe Anlage
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 16 März 2018, 08:50:42
Hier mal noch was aus dem professionellen DMX Bereich, mit entsprechend Schutzdioden und C's für den rauhen Bühneneinsatz:
https://www.controlbooth.com/media/martin-atomic-3000-schematic.29/full?d=1439974851

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 22 April 2018, 08:01:16
Da zwischenzeitlich die CAN-Module angekommen sind und ich gestern jedenfalls mal Zeit hatte für einige Lötarbeiten einen kurzen Zwischenstand dazu:

Jedenfalls an HW-Serial kann man diese Art Transceiver tatsächlich verwenden. Jedenfalls läuft einer meiner Nodes seit gestern nachmittag mit einem TJA1050-Modul - gemischt auf dem Bus mit den bisher verwendeten MAX487. Ob man das als "Durchbruch" bezeichnen kann, wage ich aber zu bezweifeln, außerdem benötigt dieser Transceiver @57600 Baud, also die Oberkante dessen, was mit SW-Serial geht (so jedenfalls mein aktueller Kenntnisstand).

Alles andere wird einige Tests brauchen, also erwartet bitte keine schnellen weiteren Rückmeldungen...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 22 April 2018, 09:57:12
Mein Bus läuft übrigens seit rund drei Wochen Stabil mit 4 Nodes und rauhem Umgang (ein Node als Motion-Detector der ständig Datenmüll übeträgt, und zeitweise ohne Gateway wegen Umbau am Server)

Ich bin in eine andere Richtung am Überlegen: Reduktion auf 19.200 Baud und weglassen der Abschlusswiderstände um trotz hoher Buslänge einen schlampigen und stromsparenden Bus zu erlauben. (Bus, Stern und  Mischformen)
Hab dazu eine Formel gefunden um das Thema Reflexion zu berechenen aber die will ich erst noch besser verstehen...

Nach der Varinate wie bei Homematic wäre aber dass man ein kleines Widerstandsnetzwerk braucht, und dieses bei 12V anders aussieht aus z.B. bei 24V.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 April 2018, 17:46:31
Zitat von: Ranseyer am 22 April 2018, 09:57:12
Mein Bus läuft übrigens seit rund drei Wochen Stabil mit 4 Nodes und rauhem Umgang (ein Node als Motion-Detector der ständig Datenmüll übeträgt, und zeitweise ohne Gateway wegen Umbau am Server)
Das klingt gut! Nutzt du schon unsere neuen Überwachungsmöglichkeiten, bzw. warum bist du sonst einfach sicher, dass du ggf. auch reboots etc. mitbekommst?

Datenrate runter ist vermutlich auch nicht verkehrt, ich habe auch gestern testweise mal 2 der CAN-Module von TJA1050 auf MCP2551 umgelötet - das Ergebnis bisher ist genauso durchwachsen, aber ja, grundsätzlich funktionieren auch diese Chips (die dann mit CAN-Transceivern auch geringere Datenraten ermöglichen würden).

Bin mal auf deine weiteren Erkenntnisse gespannt und werde vermutlich nochmal grundlegend renovieren (und messen), angefangen beim Netzteil, vielleicht spuckt mir doch das irgendwo dazwischen. Hat jemand eine Empfehlung für die zentrale Versorgung? Sollte zweckmäßigerweise irgendwas zwischen 7V und 12V liefern, es hängen aktuell "nur" 5 Nodes dran (die aber teilweise mit einiger Sensorik, aber nix besonders stromhungriges wie Gassensoren; nicht mal den Servo habe ich grade in Betrieb)...

Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 April 2018, 18:16:12
ZitatNutzt du schon unsere neuen Überwachungsmöglichkeiten, bzw. warum bist du sonst einfach sicher, dass du ggf. auch reboots etc. mitbekommst?

Nee das nutze ich noch nicht. Hättest Du nen Link was genau da einzustellen/ patchen wäre ?
Die Aussage kommt daher dass es rockstable läuft ohne Eingriffe.

Im nächsten Post reiche ich mal die Berechnung nach...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 April 2018, 18:26:45
Hier die Berechnung und Überlegungen zum Thema RS485 ohne Terminierung...
(Da ich mir relativ sicher bin dass auch hier im Forum zum Thema HM-Wired einiges a´n Jägerlaitein kursiert hab ich mal etwas länger überlegt und 2-3 Varianten durchgerechnet...
Mir scheint das folgende daher im Moment recht plausibel)



ZitatZitat: Bei 9600 Baud auf dem Bus haben wir ~0.1ms pro Signalflanke, sagen wir 50% maximale Anstiegzeit == 50us, Ausbreitungsgeschwindigkeit 21cm/ns. Faustregel: Einfache Laufzeit durch das Kabel maximal 1/6 der maximalen Anstiegzeit. 50us/6=8.3us, maximal mögliche Kabellänge 21cm * 1000 * 8.3 == 174300cm == 1743m. Ab dann sollte man anfangen, sich Gedanken um Reflexionen und Terminierung zu machen.
Quelle: https://homematic-forum.de/forum/viewtopic.php?f=31&t=24736 (die Geschwindikeit mit 9600 Baud ist m.E. aber falsch in dem Fall)


Das ganze auf 19.200 Baud umgerechnet:

Bei 19200 Baud auf dem Bus ergibt sich ein Zeitfenster von ~50us pro Signalflanke, bei 50% maximale Anstiegzeit == 25us, Ausbreitungsgeschwindigkeit 21cm/ns.
Mit der angenommenen Faustregel: Einfache Laufzeit durch das Kabel maximal 1/6 der maximalen Anstiegzeit. 25us/6=4,2us, maximal mögliche Kabellänge 21cm * 1000 * 4.2 == 88200cm == 882m.
====
=> ergibt sichere 500 Meter...

Frage: Mag mal noch ein dritter checken ob das mit den Einheiten passt, nicht dass um Faktor 1000 daneben liegt...


Nehmen wir das Widerstandsnetzwerk bei HM: 
+24V --- 22K---A---5K6---GND
B---4K7---GND
(Quelle: https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss)

Ergibt ~5V an A und B wird nach GND gezogen


Davon würde ich ableiten bei 12V:
+12V --- 6K8---A---4K7---GND
B---4K7---GND
Ergibt wieder ca. ~5V an A  (ggf statt 4K7 weniger = weniger als 5V)   und B wird nach GND gezogen


Wäre noch die Frage ob die Arduinos alle stabil 19.200 können. Mir fällt jetzt kein Gegenargument ein. Habe aber im Forum schon gegenteiliges gelesen, glaube nur nicht so recht dran.

Jedenfalls werde ich mal diese Möglichkeit in einer nächsten Platine vorsehen... (Und die ist dann zum Thema STM32)
Das Widerstandsnetzwerk gehört m.E. dann am besten ganz extern, oder ins Gateway.

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 24 April 2018, 09:35:42
OK, für weniger rechenaffine Menschen, die mehr auf trial und error stehen:
Im Ergebnis sollte ich einfach mal alle Widerstände runterwerfen, mit Ausnahme von 2 4k7-Widerständen an einem der Busenden?

(da ich sowieso fast alle R's runter habe und irgendwo noch ein LC-Tech-MAX487-Modul mit 4k7-Widerständen rumliegt, wäre das kein großes Ding)...

Werde ich mal angehen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 24 April 2018, 17:54:15
Hmm, ... Ich wollte dir jetzt nicht persönlich sagen was du tun sollst ;)

Mein Post ist prinzipiell auch nichts großartig neues. Bei einem schnellen und langen Bus muss terminiert werden.

Grund: Die Drähte bilden eine Kapazität diese muss aufgeladen oder entladen werden bei einem Pegelwechsel.

Nun ist meine Idee halt dass bis 500m mit weniger Speed trotz schlampigerem Aufbau (Misch-Stern) ein stabiler Bus möglich sein sollte.

Du könntest mal das Homematic Bild im Wiki anschauen, da machen die Jungs mit dem Spannungsteiler 5V, und die zweite Leitung wird Richtung GND gezogen.


Probieren schadet nicht. Mir ging es eher um Grundlagen. Bei meinem Aufbau war das einzige Problem bisher die Spannungsversorgung. Da muss man in jedem Fall etwas mitdenken.
zum Test kann du die Widerstände an beliebiger Stelle plazieren.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 24 April 2018, 17:59:52
Zitat von: Ranseyer am 24 April 2018, 17:54:15
Hmm, ... Ich wollte dir jetzt nicht persönlich sagen was du tun sollst ;)
Schon klar, dass das hier allg. gilt, und dass ich das ggf. auch auf "eigene Gefahr" mache...
Wir werden sehen. :)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 29 April 2018, 10:40:42
Kurze Zwischeninfo:

Habe vorhin dann einfach mal das "Endmodul" gegen ein CAN-Modul ohne Widerstände getauscht. Funktioniert jedenfalls kurzfristig auch so, die einzigen Widerstände am Bus sind dabei die am GW (auf MAX487 umgelötetes LC-Tech-Modul).

Baudrate ist noch @57600, Kabellänge grob geschätzt irgend was zwischen 30 und 40m. Im Einsatz ist (fast) alles, was ich an Transceivern so rumliegen habe: MAX487, TJA1050 und MCP2551, allerdings sind grade nur 3 Nodes online.

Wie es aussieht, benötigen die CAN-Module halt HW-serial, aber das stört mich eigentlich nicht weiter außer dem Umstand, dass ich dazu etwas umlöten muß und ggf. mittelfristig ein anderes GW einsetzen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 25 Mai 2018, 20:36:32
Mal wieder ein update zu dem topic, leider habe ich  auch keine wirklichen Durchbrüche zu berichten :( .
- Den gemeinsamen Ground hatte ich verbunden, aber zwischenzeitlich wieder unterbrochen: Bei einer Spannungsunterbrechung auf der 12V-Schiene und Wiederanschalten war (mind) FHEMWEB reproduzierbar nicht mehr zu erreichen. Das unabhängig davon, ob ich mein "normales" Netzteil verwendet habe mit nur einem Euro-Stecker oder ein anderes mit Schuko-Stecker.
Auch solange GND verbunden war, kam es zu Ausfällen, keine wesentliche Änderung der Dauer bis zum Ausfall oä..
- Dann habe ich den Rest der Nodes und das GW (@Pro Micro :D ) vollends auf HW-Serial umgestellt und die Baudrate auf 19200 runter genommen. Da ich jetzt nur noch MCP2551-Transceiver im Einsatz habe, ist auch die DE-PIN-Funktionalität deaktiviert.

- Zum Einsatz kommt eine modifizierte 10_-Device.pm, mit der man heartbeats anfordern kann und diese auch für "alive" auswerten. Daher kann ich jetzt recht gut nachvollziehen, ob das GW nicht mehr durchkommt, oder nur einzelne Nodes ein Problem haben usw. Leider helfen mir diese Optionen nur bedingt: Es läßt sich kein wirkliches Muster erkennen :( , es handelt sich jedenfalls in der Regel nicht um ein "eigentliches" Bus-Problem, da einzelne Nodes, wenn ich sie resette in der Regel einfach wieder den Betrieb aufnehmen... Andererseits liegen die Ausfälle einzelner Nodes gerne nahe beieinander (2 innerhalb 15 Min und so).
-Widerstandswerte habe ich auch hin und her probiert:-- 120 Ohm je nur am GW und Busende-- zuletzt war CANlo-4.7k-GND und GND-4.7-CANhi-10k (bzw. 14.7k)-12V => 6-8 Stunden, bis die letzte nicht mehr will, da hatte ich die 120 Ohm am Busende auch mal weggelassen
-- aktuell: je 2.2k CANlo-GND und CANhi-5VDas werde ich ggf. nochmal reduzieren und auch die Baudrate ggf. auf 9600 runternehmen (kann aber sein, dass das auch für den MCP2551 zu lange dauert, bis ein Signalwechsel kommt)

Für alle derzeit angeschlossenen 4 Nodes zeigt mein Meßgerät beim Start ca. 3.5W an, dann 2.5W. Wenn irgendwas sendet, geht es wieder kurzzeitig auf 3.5W hoch. Auch hier scheinbar also keine offensichtlichen Unregelmäßigkeiten.
Vielleicht hat ja jemand noch eine Idee...
Ansonsten erst mal schönes Wochenende!
Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 11 Juni 2018, 15:01:53
So, noch ein update :) .
Am WE hatte ich etwas Zeit und Ruhe, außerdem waren zwischenzeitlich ein 5V-Netzteil, Ersatzarduinos sowie weitere CAN-Module (MCP2551, Aufbau wie im Bild unten) angekommen.

Bis dato war an einen stabilen Regelbetrieb eigentlich nicht zu denken, zwei Nodes (die jetzt eigentlich gebraucht werden) waren bis dato vom Netz.

Als erstes wurde das 12V-Netzteil gegen 5V getauscht. Zu meiner Überraschung war dann zwar der Leerverbrauch des Netzteils geringfügig höher, aber nach dem Wiederanklemmen der (unveränderten!) Nodes war er ca. 1W geringer als vorher. Das ist schon mal erfreulich. Alle verbliebenen Nodes haben dann erst mal wieder gesendet, auch erfreulich.

Dann die erste Node mit einem neuen Pro Mini versehen, den LMS1117 für 12V->5V runter und die Spannungsversorgung auf der Node umgelötet, angeschlossen und beim Flashen den alten Code, aber mit der Änderung aus dem Pull-Request #1142 (https://github.com/mysensors/MySensors/pull/1142) verwendet (ansonsten ist die Lib auf einem 2.3.0-alfa Stand von vor ein paar Wochen).

Als nächstes dann die 5. Node umgelötet (LMS1117 runter), zum Einsatz des og. Moduls vorbereitet und den Arduino geflasht (wieder mit #1142). Angeschlossen: Lief nicht :( . Dann CRX und CTX vertauscht (also Arduino RX nach Modul CRX und TX nach CTX) => online :) .

Pause gemacht und gefreut. Einige Zeit später: die drei "alten" Nodes offline :( , die beiden "neuen" sendeten artig weiter Daten bzw. einen heartbeat :) .
OK. Schlußfolgerung: Entweder es waren die Spannungswandler, die das Problem verursacht haben, und die müssen einfach bei den anderen Nodes noch runter, oder es sind die paar Zeilen Code.

Also habe ich an einer nur die Spannungsversorgung umgelötet und wollte dann eine Zweite nur mit der Codeänderung beglücken. Ersteres funktionierte erst mal problemlos, aber bei der, die nur den geänderten Code bekommen sollte, stand dann offensichtlich nicht mehr genug Saft für einen stabilen Betrieb zur Verfügung. Da muß ich also nochmal ran, die fällt auch im Moment alle Paar Stunden aus und kann auch nicht angepingt werden (keine Reaktion auf heartbeat request).
ABER: Alle anderen laufen seither :) , auch wenn noch nicht alle Sensorik wieder angeklemmt ist (das mache ich dann nach und nach, wenn die Kommunikationsebene verläßlich funktioniert).

Zusammengefaßtes aktuelles Setup also:
- 19200 Baud- ausschließlich MCP2551 als Transceiver, die "alten" umgelötete TJA-Module, eine Node mit dem abgebildeten Modul
- Alle mit HW-Serial ohne DE-PIN-Definition
- GW: ungepatchter Pro Micro, versorgt via USB
- Spannungsversorgung alle anderen Nodes über ein zentrales 5V-Netzteil
- GND ist bei allen über die zentrale Versorgung identisch, mit Ausnahme des GW(-EDIT: GND - 2kOhm - CANlo - 120 Ohm - CANhi - 2kOhm - 5V am Busende).

Jetzt werden jedenfalls erst mal die Spannungswandler auf den verbliebenen Nodes noch ausgelötet und dann wird sich zeigen, ob und wann welche Nodes wieder nicht mehr wollen.
Bin mal gespannt, wann ich das nächste Mal hier öffentlich weine ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 12 Juni 2018, 08:53:49
Hallo Beta-USer,
.
dann hoffe ich mal dass es dabei bleibt.

Mein Stand ist inzwischen folgender:
-Der RS485 Bus existiert nun schon ewig und wird sehr viel kommerziell genutzt, auch in der Industrie
-bei mir läuft der superstabil
-natürlich kann es Umsetzungsprobleme geben (z.B. Kabel, Verbindungen, Versorgung, Störungen und fehlende Maßnahmen dazu)

Zweitens könnte ich mir vorstellen dass wir noch immer ein SW Problem haben:
ZitatDa nicht mehrere Sender gleichzeitig auf die Leitung aufgeschaltet sein dürfen, muss der jeweilige Sender nach Bedarf eingeschaltet werden (Halbduplex). Dies wird auf Protokollebene definiert. Der Sender steuert das differentielle Leitungspaar voll aus, d.h. geht unbelastet auf 0V/Vcc, wobei es 3.3V, sowie 5V Bausteine gibt. Unter Last nimmt die Amplitude dann ab. Der Empfänger braucht minimal 70mV Differenzspannung in einem Gleichtaktbereich von -7...+12V. Es gibt auch Bausteine mit höheren Gleichtaktspannungen.
Quelle: https://www.mikrocontroller.net/articles/RS-485

Frage: Hast Du evtl nen Schaltplan zu dem abgebildeten Modul oder ne kurze Beschreibung was da warum drauf ist ? (Angeschlossen hast du nur die ersten vier Pins ? VCC bis CRX?)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Juni 2018, 10:17:03
Moin,

wenn ich nicht überzeugt wäre, _dass_ es gehen _muss_, würde ich nicht so hartnäckig dran bleiben ;) .
Und ganz sicher ist es so, dass ich mir manche Probleme selber gemacht habe und deswegen hin und wieder im Kreis gelaufen bin, ohne die wahre(n) Ursache(n) zu finden.
Zitat von: Ranseyer am 12 Juni 2018, 08:53:49Zweitens könnte ich mir vorstellen dass wir noch immer ein SW Problem haben.
Es gibt dazu ja auch längere Diskussionen auf MySensors.org, ob RS485(@MAX48x) denn wirklich funktionieren kann und ob man nicht eine andere kabelgebundene Lösung bevorzugen sollte. Das Grundproblem ist eben, dass klassisches RS485 kein Multi-Master-Konzept ist, wie es für die bisherige Struktur von MySensors erforderlich wäre. Von daher ist das Thema Collission-Detection nach allem, was ich dazu gelesen habe von zentraler Bedeutung.

Was meine bisherigen Erfahrungen angeht, läßt sich eine gewisse Tendenz feststellen: Sehr häufig lagen die Ausfälle der Nodes zeitlich eng beieinander. Das kann eigentlich nur dadurch kommen, dass entweder der Bus elektrisch ein Problem hat (insbesondere: eine Node auf Dauer-Sendung oder ein "weglaufender" GND) oder alle Nodes wegen irgendetwas die eigene Kommunikation eingestellt haben, was wiederum elektrische (Abschaltung wg. Hitze) oder logische (Code) Ursachen haben kann.
Das mögliche Dauer-High durch hängengebliebene einzelne Arduinos sollte seit Umstellung auf CAN-Transceiver faktisch ausgeschlossen sein. Tatsächlich war es jedenfalls die letzte Zeit, teilweise aber auch schon vorher, in der Regel möglich, einzelne Nodes bzw. alle nacheinander wieder online zu bringen, indem man den Reset-Knopf drückte. Das sollte eigentlich die Transceiver auch nicht stromlos gemacht haben (die hängen/hingen direkt hinter den 12V-5V-Wandlern), was noch mehr dafür spricht, dass es ein Problem auf den Arduinos ist. Das läßt auch darauf schließen, dass es nicht mit der Frage der korrekten GND-Verbindung zusammenhing/-hängt.

Damit bleibt die wahrscheinlichste Ursache ein fehlerhafter Umgang mit zeitgleichen Sendungen bzw. Sendungsversuchen auf dem Bus.

ZitatFrage: Hast Du evtl nen Schaltplan zu dem abgebildeten Modul oder ne kurze Beschreibung was da warum drauf ist ? (Angeschlossen hast du nur die ersten vier Pins ? VCC bis CRX?)
Schaltplan habe ich keinen, aber die Belegung dieser Module ist eh' minimalsitisch, gute Bilder wären hier (https://www.amazon.de/MCP2551-High-Speed-CAN-Modul/dp/B079SZJYCJ/ref=sr_1_1?s=industrial&ie=UTF8&qid=1528789595&sr=1-1&keywords=mcp2551) zu finden. Auch auf den TJA-Modulen ist nicht wirklich viel drauf, Bild hier (https://www.amazon.de/LIUXINDA-MK-praktische-k%C3%B6nnen-Controller-Interface/dp/B07DK4KKGC/ref=sr_1_fkmr0_1?s=industrial&ie=UTF8&qid=1528789862&sr=1-1-fkmr0&keywords=tja+can), aber eben R121 bei den Zwischennodes runter und MCP2551 statt des TJA.
Angeschlossen ist immer Arduino:5V, GND, Rx, Tx <-> Modul 5V, GND, RX bzw. CTX, TX bzw. CRX. Und dann eben noch die Bus-Anschlüsse zum Bus hin (muß nochmal prüfen, ob die gemoddeten TJA-Module wirklich Rx-TX-vertauscht anzuschließen sind, aber egal, der Teil scheint ja zu funktionieren, und wenn man es falsch macht, funktioniert es auch kurzfristig nie ::) ).

Aktueller Zwischenstand übrigens:
Gestern abend sind dann pünktlich nach dem Abendessen die beiden Nodes mit dem "alten" Code ausgefallen (eine davon schon auf 5V-Versorgung umgebaut). Daher haben die jetzt auch noch die 4 Zeilen zusätzlich erhalten. Bisher senden sie artig, mal schauen, wie lange...

Gruß, Beta-User
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Juni 2018, 11:12:33
Hallo zusammen,

weiterhin alles online :) .

Bei Gelegenheit werde ich dann mal testen, ob die MCP2551-CAN-Transceiver auch mit AltSoftSerial können (dann wird vielleicht auch das mit der RFID-Leser-Node endlich was...).
Das wäre super, weil man dann "das beste aus allen Welten" hätte. Einziger Nachteil, den ich sonst (neben dem obigen offenen Punkt mit AltSoftSerial) bisher an der CAN-Lösung sehe: die Message-Length ist begrenzt; das scheint aber für die normale MySensors-Funktionalität irrelevant zu sein.
Weiterer Vorteil: PIN2 wird auch noch frei - damit kann man am Nano/Pro Mini beide "echte" Interrupt-PINs anders nutzen!

Da hier noch ca. 10 von den Dingern als SOIC-8 rumliegen (sind aber leider nicht PIN-kompatibel mit MAX48x, passen also nicht auf die bisherigen Platinen): Wenn jemand testen möchte, bitte um Adresse per PN (für ernsthafte Tester bis 5 St. umsonst). 
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 13 Juni 2018, 12:19:40
Ich hab ernsthaftes Interesse, habe aber selbst ein paar bestellt, und werde diese nur auf Platinen verbauen. (Und bis ich diese da habe habe ich sicher auch die Chips)

Evtl. passe ich diese darauf an:
https://github.com/ranseyer/MySensors-HW/blob/master/Experimental/GW-Sens-RS485-ProMicro/top-01.png
Die ist echt winzig geworden und trotzdem sehr mächtig.
((Und dann kommt wieder die Frage auf: Mega32U4 und MySensors... - Ich habs noch nicht probiert, Ansonsten müsste der ProMini drauf))
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Juni 2018, 12:42:50
Sieht cool aus!
Als GW nutze ich übrigens auch einen ProMicro mit HW-Serial. Ist optisch aber deutlich provisorischer, meine "Lötfähigkeiten" sind ja hinlänglich berüchtigt... Das Problem ist "nur", dass man einen Reset-Taster braucht, um den Bootloader zu starten, und die Erfolgskontrolle des Flashens ist etwas diffiziler. Aber ansonsten funktioniert das problemfrei (seit einigen Wochen, wann das war hatte ich in dem anderen Post zum ProMicro gepostet, oder?).

(Das GW hat übrigens als einziges den Patch noch nicht...)

Also wenn du die Option hast, irgendwo den Taster (https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/troubleshooting-and-faq#ts-reset) noch draufzudesignen, wäre das vermutlich hilfreich, und nach dem 120-er Widerstand habe ich jetzt nicht gesucht (GW+letzte Node).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 13 Juni 2018, 16:44:08
RX/TX wird laut hier nicht gekreuzt (siehst Du das auch so ?):

ZitatName Pin Function
1 TXD Transmit Data Input
2 VSS Ground
3 VDD Supply Voltage
4 RXD Receive Data Output
5 VREF Reference Output Voltage
6 CANL CAN Low-Level Voltage I/O
7 CANH CAN High-Level Voltage I/O
8 RS Slope-Control Input
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 13 Juni 2018, 17:08:29
Magst Du den Schaltplan mal inspizieren ? (unnötige Widerstände machen nix! Ich denke es müssen trotzdem welche runter damit das Routing möglich wird...)

Wenn routbar würde ich auch noch Jumper für Softserial einbauen. (Gibt es dazu schon vorgeschlagene Pins?)

Grüße

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Juni 2018, 20:10:50
Den Schaltplan schaue ich demnächst gerne mal in Ruhe an, vorab mal ein Foto von meinem "Zweit-Pro-Micro-GW".
Daran ist gut zu erkennen, dass doch TX an TX und RX an RX geht (zu den lila MCP2551-Modulen hatte ich das ja bereits geschrieben und vorhin nochmal nachgesehen). Das sollte also passen, auf dem Modul messe ich je 0 Ohm von TX <-> PIN1 und RX<->PIN4 des Chips.

Was AltSoftSerial angeht, ist das beim 328p auf PIN 8 und PIN 9 festgelegt, beim Pro Micro würde ich darüber nicht diskutieren und immer HW-Serial1 verwenden... Debug ist via USB doch eigentlich immer einfacher, oder? Ansonsten wären die PINS aus der AltSoftSerial-lib auszulesen.
Code für den Pro Micro - da sind die PINs erwähnt, kommt aus dem Orginal-Sketch, behaupte ich mal:
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* DESCRIPTION
* The RS485 Gateway prints data received from sensors on the serial link.
* The gateway accepts input on seral which will be sent out on
* the RS485 link.
*
* Wire connections (OPTIONAL):
* - Inclusion button should be connected between digital pin 3 and GND
* - RX/TX/ERR leds need to be connected between +5V (anode) and digital pin 6/5/4 with resistor 270-330R in a series
*
* LEDs (OPTIONAL):
* - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
* - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
* - ERR (red) - fast blink on error during transmission error or recieve crc error
*
* If your Arduino board has additional serial ports
* you can use to connect the RS485 module.
* Otherwise, the gateway uses AltSoftSerial to handle two serial
* links on one Arduino. Use the following pins for RS485 link
*
*  Board          Transmit  Receive   PWM Unusable
* -----          --------  -------   ------------
* Teensy 3.0 & 3.1  21        20         22
* Teensy 2.0         9        10       (none)
* Teensy++ 2.0      25         4       26, 27
* Arduino Uno        9         8         10
* Arduino Leonardo   5        13       (none)
* Arduino Mega      46        48       44, 45
* Wiring-S           5         6          4
* Sanguino          13        14         12
*
*/

// Enable debug prints to serial monitor
#define MY_DEBUG
#define   MY_SPECIAL_DEBUG

// Enable RS485 transport layer
#define MY_RS485

// Define this to enables DE-pin management on defined pin
//#define MY_RS485_DE_PIN 2

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 19200 //57600 //9600 57600

// Enable this if RS485 is connected to a hardware serial port
//#define MY_SERIALDEVICE Serial
//#define USBCON
#define MY_RS485_HWSERIAL Serial1
//#define BOARD_ID_STR            "RS485_MySensors_ProMicro_GW"

// Enable serial gateway
#define MY_GATEWAY_SERIAL
//#define MY_DEBUGDEVICE Serial
//#define MY_SERIALDEVICE Serial2
//#define MY_REPEATER_FEATURE
//#define IMANUFACTURER Test

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3

// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
#define MY_DEFAULT_ERR_LED_PIN 17  // Error led pin
#define MY_DEFAULT_RX_LED_PIN  30 //5  // Receive led pin
#define MY_DEFAULT_TX_LED_PIN  17 //6  // the PCB, on board LED

#include <MySensors.h>
//#define MY_SERIALDEVICE Serial

void preHwInit() {
  wait(5000);
}

void setup()
{
  // Setup locally attached sensors
  //MY_SERIALDEVICE.println(F("Serial GW"));
}

void presentation()
{
    // Present locally attached sensors
}

void loop()
{
    //#define MY_SERIALDEVICE Serial
    /*MY_SERIALDEVICE.println(millis());
  wait(4200);
    MY_SERIALDEVICE.available();
    // Send locally attached sensor data here*/
}


Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 13 Juni 2018, 20:19:05
Alles klar, dann lass ich die Softserial Sache bleiben, das PCB ist eh schon recht voll. Ich will das nicht ohne Not ausreizen.

Schau dann doch lieber gleich das aktuelle an:
https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-CAN-ProMicro
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 14 Juni 2018, 10:46:20
Moin,

ein paar Fragen/Anmerkungen zum Schaltplan:
(Du weißt aber schon, dass das nicht zu meinen Kernkometenzen gehört, oder?!? Also nicht lachen, wenn's völlig daneben ist *grins*)

- 3.3V: Einen Regler habe ich nicht so richtig ausgemacht; soll das "IC2" sein? (Dann müßte aber der 3.3V-VCC-Ausgang separat ausgewiesen/geroutet werden, oder?)
- ATSHA: Macht der hierdrauf Sinn? Und evtl. hätten wir dann doch Probleme mit der Message Length (müßte man prüfen), da die verschlüsselten Nachrichten bei nRF24 jedenfalls das maximale der Payload ausnutzen.
- Option, den Busabschluß draufzulöten? Also SMD-Widerstände GND-B und 5V-A (??)?
- Das "unten links" verstehe ich nicht so recht; wenn das eine Sicherung mit Brückenoption ist, müßte der Eingang doch "IN" sein (kommend vom Connector) und "UREG" out?

Aber die Anschlüße des MCP sehen für meine Augen ok aus...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 14 Juni 2018, 15:32:51
Ich würde gerne später Antworten. Aber vorab:

Wir reden vom CAN Bus, und du schlägst die Option vor den Bus auf GND und VCC zu pullen ?
Das würde heissen CAN_L nach GND und CAN_H auf VCC ? (Der Wert wäre ja erst mal egal und ich würde 680R in den Schaltplan schreiben)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 14 Juni 2018, 16:11:52
Laß dir Zeit!
Schon richtig: Der im Moment bei mir installierte Bus hat neben 120 Ohm am GW und an der letzten Node noch zwei weitere Widerstände à 2.000 Ohm.

Genau mit diesem Hardware-Setup läuft es jetzt seit Anfang der Woche stabil...

Und zur Klarstellung nochmal: Eine Zeitlang hatte ich MAX485, MAX487, TJA1050 und MCP2551 bei 57600 Baud in einem gemischten Betrieb, wobei das GW Software-Serial nutzte. Ich bin ziemlich sicher, dass - neben dem Stabilisieren der Spannungsversorgung (da waren einige LMS1117 kaputt) - alleine der Patch ausgereicht hätte, um damit einen problemfreien Betrieb zu haben. Der Kommunikationslayer an sich war jedenfalls funktional.

Spannend ist jetzt aus meiner Sicht nur, ob

- auch ein Software-Serial-Betrieb mit den CAN-Transceivern klappen würde und
- die MCP2551 auch bei 9600 Baud noch funktionieren ;) .

Werde ich beides bei Gelegenheit - mit oder ohne Grill - mal testen :P . Wenn weiter keine negativen Vorkommnisse mehr sind, würde ich dann irgendwann mal bei Gelegenheit die gesammelten Erkenntnisse in's Wiki (Abschnitt im Starter-Guide?) packen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 14 Juni 2018, 17:31:16
Zitat- 3.3V: Einen Regler habe ich nicht so richtig ausgemacht; soll das "IC2" sein? (Dann müßte aber der 3.3V-VCC-Ausgang separat ausgewiesen/geroutet werden, oder?)
Habe ich jetzt auch noch spendiert. (neu)

Zitat- ATSHA: Macht der hierdrauf Sinn? Und evtl. hätten wir dann doch Probleme mit der Message Length (müßte man prüfen), da die verschlüsselten Nachrichten bei nRF24 jedenfalls das maximale der Payload ausnutzen.
Ist weg. Der macht m.E immer Sinn. Aber man sollte die Kirche im Dorf lassen und seinen Kabeln vertrauen.

Zitat- Option, den Busabschluß draufzulöten? Also SMD-Widerstände GND-B und 5V-A (??)?
Neu: Wieder mit Pull gedöns...

Zitat- Das "unten links" verstehe ich nicht so recht; wenn das eine Sicherung mit Brückenoption ist, müßte der Eingang doch "IN" sein (kommend vom Connector) und "UREG" out?
Ich habs mal etwas verständlicher gemalt. Von der Funktion her hat sich nix geändert. Nur die Hohlbuchse muss dran glauben (Heul!)



Das Ergebnis gefällt mir schon ganz gut. Denke davon lass ich mal ein paar produzieren.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 14 Juni 2018, 18:14:58
Vielleicht noch eine Sache: Da ich zwischenzeitlich wieder 5V statt 12V verteile: Jedenfalls bei mittleren Kabellängen wäre das evtl. eine Option entweder eine Ader aus den verbliebenen als 5V-Option vorzusehen, oder RAW zu kappen und nach UREG zu 5V zu brücken, oder?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 14 Juni 2018, 18:36:48
Find ich gut und bau ich ein.

Allerdings wäre ich dafür lieber 48V (m.E. leider teuerer) zu verteilen statt 5V. Da hast du weniger Verluste und kannst somit auf der selben Leitung mehr Energie übertragen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 15 Juni 2018, 08:54:11
Btw. Eine Platine für beide Chips ist kein Problem. Ich denke ich werf lieber bei größeren Versionen die DIL Bauart runter und ersetze diesen Chip durch das CAN Teil.
Ich denk ich würde das erst mal so lassen: https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-CAN-ProMicro
(ggf. minimale Optimierung der Beschrifung, aber das sehe eigentlich erst für eine spätere V0.2)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 15 Juni 2018, 16:56:33
URL geändert, leichte Anpassung. Wenns dabei bleibt, dann ggf noch etwas bessere Beschriftung...
https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-RS485-CAN-ProMicro
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Juni 2018, 17:22:16
Hab jetzt nicht nochmal intensiv drüber gesehen, aber das Ding sieht schnuckelig aus, ist ja wirklich winzig.
Was die Beschriftung angeht, könnte insbesondere klarer gemacht werden, wo die 3.3V dann abzugreifen sind? Auf den top/bot.png's kann ich das nicht so richtig ablesen, gehe aber davon aus, dass der "kleine" in der Mitte für 3.3V ist und der große auf bot.png links angeordnet, oder?

Zu der zentralen Versorgung: Du hast schon recht, 5V sind auch nicht sooo das Gelbe vom Ei, mehr wäre eigentlich besser. Dazu hätte ich noch folgende Idee: Recht weit verbreitet sind z.B. die LM2596S-Module. Da kannst du mit allem möglichen rein (bis 30V, meine ich), die passende Ausgangsspannung muß halt eingestellt werden.
Wenn jetzt die Teile an sich ok sind (habe da auf die Schnelle keine weiteren Infos zu) und auch mechanisch von allen Quellen identisch, könnte man die optional als Huckepack-Steckmodul drunter klemmen. Sind halt relativ groß...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Juni 2018, 18:10:50
Nachtrag: Buck Converter scheint es auch in deutlich kleiner zu geben; da wir hier keinen HF-Teil haben, dürfte das eigentlich die bessere Variante sein, hier einen (optional) reinzudesignen.

Effizienter... Habe nur auf die Schnelle keinen gefunden, der so einen großen Bereich abdeckt, aber z.B. https://www.ebay.de/itm/1-2-5X-DC-DC-4V-12-24V-To-5V-3A-Adjustable-Step-Down-Power-Module-Buck-Converter/272718668610?hash=item3f7f4ca342:m:m6kjPR7ItoH4BMSybE6CUig scheint denselben "footprint" zu haben wie einige andere, die bis 23V vertragen. Wären 4 Pins, die (nach unten?) noch vorzusehen wären, Bemaßung kenne ich aber leider nicht.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 15 Juni 2018, 23:53:37
Genau den kannst Du doch am Ende links verbauen... (Ist evtl nicht so doll dokumentiert, neues hat in dem knappen Design eher keinen Platz mehr...)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 16 Juni 2018, 13:52:20
...hätte ich mir eigentlich ja denken können ;D .
Beschriften würde vermutlich den Einstieg für Interessierte erleichtern ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 17 Juni 2018, 12:10:43
Zitat von: Beta-User am 14 Juni 2018, 16:11:52
Spannend ist jetzt aus meiner Sicht nur, ob

- auch ein Software-Serial-Betrieb mit den CAN-Transceivern klappen würde und
- die MCP2551 auch bei 9600 Baud noch funktionieren ;) .
So, kurze Rückmeldung zum ersten Test dazu: beides scheint problemlos zu funktionieren.
Ergänzend die Info: Im Unterschied zu den MAX48x mögen die MCP2551 es nicht, wenn man die Kanäle irgendwo vertauscht, es muß strikt CANhi auf CANhi gehen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 17 Juni 2018, 12:13:03
Zitatmögen die MCP2551 es nicht, wenn man die Kanäle irgendwo vertauscht

Verabschiesen sich diese dann feige aus dem Leben ?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 17 Juni 2018, 13:16:19
Ganz so drastisch ist es nicht. Einfach keine Kommunikation....
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 19 Juni 2018, 13:37:51
Zitat von: Beta-User am 14 Juni 2018, 16:11:52
Wenn weiter keine negativen Vorkommnisse mehr sind, würde ich dann irgendwann mal bei Gelegenheit die gesammelten Erkenntnisse in's Wiki (Abschnitt im Starter-Guide?) packen.
Keine Vorkommnisse bisher, daher hier die Zusammenfassung: https://wiki.fhem.de/wiki/MySensors_Starter_Guide#Tips_und_Tricks_zu_MySensors-RS485
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2019, 16:55:27
Ich habe mal das Wiki etwas ergänzt mit 2 Bildern und etwas Text. Auch für mich selbst zum Nachlesen...

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

(Somit kann meine Skizze ins Altpapier 8))
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: PeMue am 23 Februar 2019, 17:31:33
Zitat von: Ranseyer am 23 Februar 2019, 16:55:27
Ich habe mal das Wiki etwas ergänzt mit 2 Bildern und etwas Text.
-e, hab's aber schon geändert  ;)

Gruß Peter
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2019, 18:31:10
Zitat von: Beta-User am 14 Juni 2018, 18:14:58
Vielleicht noch eine Sache: Da ich zwischenzeitlich wieder 5V statt 12V verteile
Mal wieder ein Zwischenstand, wenn ihr hier sowieso mal wieder am Leichenfleddern seid: Mein Bus läuft an sich Super-stabil, aber die 5V sind nicht das gelbe vom Ei. Einfach zu viel Verluste über die Leitungslänge, so dass ich eine bestimmte Node immer mal wieder neu starten muß (dusseligerweise steigt da meistens nur der BME280 aus (der hängt für I2C völlig spezifikationswidrig an einem ca. 3m langen Kabel und das auch noch "im Freien" (unter der Abdeckung des Außentemp-fühlers der Heizung)), der heartbeat kommt aber trotzdem schön sauber und regelmäßig...).
Werde daher wieder auf 12V gehen und lokal die 5V erzeugen (wollte ich eigentlich heute min. in Teilen umrüsten, aber das vertrackte autocreate wollte nicht wie es sollte), vielleicht dann heute abend noch?

Neulich gab es übrigens bei MySensors einen Thread, in dem die lokal erforderliche Spannung über den Bus geholt wurde; vielleicht mag jemand anders das bei Interesse suchen? Fand ich vom Gedanken her klasse (wenn auch völlig gegen den von vielen als essentiell angesehenen Ansatz, GND mitzuführen).

Gelobt sei, was funktioniert :) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 23 Februar 2019, 18:51:45
Zitat-e, hab's aber schon geändert
Danke, das war wiederlich ! 8)


Zitatbei MySensors einen Thread, in dem die lokal erforderliche Spannung über den Bus geholt wurde
Wie meinst Du das ? Ich habe gernell mehr Saft auf dem "Bus" und versorge damit die Nodes. Dabei verbrate entweder die Differenz über AMS1117 und Co. Oder halt ein Stepdown-Regler bei höherem Verbrauch.

Und in welche Richtung soll der Beitrag gehen ?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2019, 19:06:55
Zitat von: Ranseyer am 23 Februar 2019, 18:51:45
Und in welche Richtung soll der Beitrag gehen ?
Ging darum, dass da nur A+B genutzt wurden und die Nodes aus der Differenzspannung versorgt wurden, soweit ich das verstanden habe. Also nur 2 Adern, nicht 4....
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 23 Februar 2019, 19:13:54
Müßte rund um das Dokument hier sein:

http://www.ti.com/lit/ug/tidu993/tidu993.pdf

Sowas ähnliches wie ein parasitärer 1-wire Bus, nur halt auf RS485-Basis...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 24 Februar 2019, 08:29:33
Zitat von: Beta-User am 23 Februar 2019, 19:06:55
Ging darum, dass da nur A+B genutzt wurden und die Nodes aus der Differenzspannung versorgt wurden, soweit ich das verstanden habe. Also nur 2 Adern, nicht 4....


Ahh, OK. Das ist ja das Grundprinzip von RS485. Eine überlagerte Spannung ist egal. Die nutzen das aus.

-Der Kondensator soll das die Daten möglichst unverändert zum Transceiver durchlassen
-Die Drosselspule hält das Datensignal weitgehend fern von Spannungsregler.

Soweit so klar. Mir irritiert nur das Testboard von TI mit den vielen Varianten die man durchspielen kann und dann mit dem Oszi messen wie groß jeweils die Verschlechterung ist. Ich würde das machen wenn nur zwei Drähte vorhanden sind. Telefonkabel haben aber vier. Und wenn man neu verkabel würde ich unbedingt ab CAT5 Kabel verlegen. Da hat man noch mehr Luft...

Wenn man das ganze ca. so wie POE betrachtet könnte man eine simple Platine bauen für das ein und auskoppeln der Spannung. Das Problem sehe ich am ehesten bei der Drossel. Da müsste man von Anfang an wissen welche mechanische Größe...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: PeMue am 03 Dezember 2019, 16:06:16
Hallo zusammen,

ich habe jetzt alle Seiten überflogen, bin mir aber echt unschlüssig, welchen RS485 Baustein ihr nehmt/empfehlt (kein CAN). Er sollte 3,3 V Versorgung haben und zum MAX485 kompatibel sein.

Danke für eine kurze Info.

Gruß Peter
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 03 Dezember 2019, 17:06:15
Ich hab eine Hand davon: https://www.mouser.de/ProductDetail/Maxim-Integrated/MAX3430CSA?qs=sGAEpiMZZMtk5jbcouIbSxgIiqv8VXz4y0gxbfbKQZA%3D
Die sollten deine Anforderungen erfüllen.

Die waren aber recht teuer. Daher bin ich eher auf dem Tripp: Die nehme ich nur für STM32. Bei AVR hab ich nur 5V und passende Sensoren.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: PeMue am 03 Dezember 2019, 17:28:22
Zitat von: Ranseyer am 03 Dezember 2019, 17:06:15
Ich hab eine Hand davon: https://www.mouser.de/ProductDetail/Maxim-Integrated/MAX3430CSA?qs=sGAEpiMZZMtk5jbcouIbSxgIiqv8VXz4y0gxbfbKQZA%3D
Ok, die habe ich auch hier. Aber ich werde mal diesen hier https://www.reichelt.de/rs485-422-1-treiber-1-empfaenger-so-8-sp-3485-enl-p166271.html?&trstct=pos_0 probieren, mal sehen, wie der funktioniert ...

Danke + Gruß

Peter
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: loetmeister am 30 April 2020, 14:29:20
Hallo an die Runde.
Ich wollte nicht zwei Themen wieder Aufwärmen, aber hier wurden ja einige Treiber-Chips genauer unter die Lupe genommen. Welche RS485 chips/bzw. Anschlussvarianten haben sich als zuverlässig erwiesen?

Die Probleme mit den MAX487, lag das an der Spannungsversorgung oder waren die chips, welche die maximale Spannung nicht ausgehalten hatten fakes? (Ranseyer hatte da getestet...)

Ich hab MAX487 (angeblich ECSA) aus China verbaut, da sind mir nun zwei gestorben, was ich nicht nachvollziehen kann.
Ähnlich hier:
https://forum.fhem.de/index.php/topic,86573.0.html


Ich würde statt Maxim MAX487 mal die Ti 5LBC184 versuchen... was mir dann aus China geliefert wird steht aber ja auch in den Sternen...  ???


Gruß,
Thomas
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 30 April 2020, 14:51:38
Nun ja, ich für meinen Teil bin mit den CAN-Transceivern des Typs MCP2551 ganz zufrieden und würde auch Einsteigern immer raten, direkt nach den ersten breadboard-Tests mit den "normalen" MAX-Transceivern (zum Kennenlernen des Prinzips) stattdessen die einzubauen.

Also falls du die Option hast, das dahin umzubauen: Just do it! Du bekommst damit auch noch einen interrupt-fähigen PIN frei, ist auch nicht schlecht.

Es gibt nur leider (noch) keine schönen Platinen dafür... (die sind nicht PIN-kompatibel zu den MAX). Ich kenne aber mindestens noch zwei andere User, die am Einsteigen sind und an "RS485" Interesse hätten und dabei auch CAN-Transceiver vermutlich gerne nehmen würden. Vielleicht kann ja einer unserer Platinenexperten mal einen Aufruf machen...? (Ich bin erst mal raus, meine funktionieren auch mit "wilder Verkabelung")

Falls das jemand vorantreiben will: ich meine noch ein paar DIPs rumliegen zu haben und auch wenige Module. Letztere sind meine "Reserve", gegen Ersatzbestellung auf in einigen Wochen kann ich davon welche zur Verfügung stellen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 30 April 2020, 15:49:30
ZitatEs gibt nur leider (noch) keine schönen Platinen dafür...

Das weiss ich nicht...

Ich habe Prototypen herumliegen, komme aber schon lange nicht zum Testen !
Also wer technisch fit ist, könnte ja mal eine PN senden...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: loetmeister am 30 April 2020, 18:20:58
Hallo,

ok, danke. Da ich mich bereits (weitestgehend) festgelegt habe und Platinen erstellt habe, würde ich nach einem PIN-kompatiblen Ersatz zum MAX schauen.
Daher auch die frage ob jemand den Texas Instruments 5LBC184 länger im Einsatz hat und sagen kann ob er mehr aushält als der MAX487 . :)

Gruß,
Thomas
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 30 April 2020, 18:59:22
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 (?).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 30 April 2020, 19:25:44
Zitat von: Ranseyer am 30 April 2020, 18:59:22
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...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: PeMue am 01 Mai 2020, 13:32:17
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 01 Mai 2020, 15:01:17
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"... )
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 07 Mai 2020, 12:18:34
Zitat von: Beta-User am 30 April 2020, 14:51:38
... 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 (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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 07 Mai 2020, 13:59:52
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...).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 11 Mai 2020, 11:52:10
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!)).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 11 Mai 2020, 12:12:30
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...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 11 Mai 2020, 13:12:38
Zitat von: Beta-User
...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  8)

Viele Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 11 Mai 2020, 13:24:11
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...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 11 Mai 2020, 16:30:14
Zitatnachdem hier doch neuerdings wieder reges Interesse an RS485 (bzw. verkabelten Lösungen) besteht...

Kommen 'se dann doch langsam zur Vernunft  8) 8) 8)

Danke für deinen unermüdlichen Einsatz im Wiki usw. !  ::)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 11 Mai 2020, 16:37:46
Zitat von: Ranseyer am 11 Mai 2020, 16:30:14
Kommen 'se dann doch langsam zur Vernunft  8) 8) 8)
8) ;D ::) 8)

ZitatDanke 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!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: RichardCZ am 12 Mai 2020, 08:27:38
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Mai 2020, 09:12:46
Ä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 ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: RichardCZ am 12 Mai 2020, 09:19:51
Zitat von: Beta-User am 12 Mai 2020, 09:12:46
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?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Mai 2020, 09:40:20
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" ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 12 Mai 2020, 14:57:31
@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

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Mai 2020, 15:31:04
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 (https://www.ebay.de/itm/5PCS-Mini-Buck-Converter-DC-DC-12-24V-To-5V-3A-Adjustable-Step-Down-Power-Module/272718624682?hash=item3f7f4bf7aa:g:af8AAOSwpONZQkus), 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?!? ::) ).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 12 Mai 2020, 16:09:36
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 (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...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 12 Mai 2020, 17:15:57
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Mai 2020, 17:37:35
@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ß...)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: loetmeister am 12 Mai 2020, 18:43:11
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 12 Mai 2020, 19:45:24
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Mai 2020, 08:22:10
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... (https://forum.mysensors.org/topic/11135/something-s-cooking-in-the-mysensors-labs)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 13 Mai 2020, 10:13:21
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag 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 ;) . 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").
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 13 Mai 2020, 13:40:42
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Mai 2020, 14:00:16
So (mit der 1-n) isses m.E. sehr gut!

In die Richtung also: no action required, sorry für den Edit!
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 13 Mai 2020, 14:17:41
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ß
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Mai 2020, 14:32:23
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?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 13 Mai 2020, 15:29:21
Danke Euch für die Blumen + Rückmeldungen  :-*  :-*

Zitat von: Beta-User am 13 Mai 2020, 14:32:23
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Mai 2020, 15:36:19
Danke für das mit der Beschriftung. Das paßt jetzt!

Dann paßt das auch zeitlich gut dazu:
Zitat von: rob am 12 Mai 2020, 14:57:31
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 (http://ww1.microchip.com/downloads/en/devicedoc/20005167c.pdf) 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).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 13 Mai 2020, 15:52:38
..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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 13 Mai 2020, 16:12:56
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 8) . (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 ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 13 Mai 2020, 20:56:51
Zitat von: loetmeister am 12 Mai 2020, 18:43:11
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...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 14 Mai 2020, 20:02:57
Zitat von: Schotty am 13 Mai 2020, 15:52:38
..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.

Zitat von: Schotty am 13 Mai 2020, 15:52:38
...bin aber auch definitiv kein Fritzing-Experte!)..  ::)
Ich noch weniger. Ist tatsächlich mein Erstlingswerk.

Zitat von: Beta-User am 13 Mai 2020, 16:12:56
...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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 14 Mai 2020, 21:16:32
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: RichardCZ am 14 Mai 2020, 21:19:53
Zitat von: rob am 14 Mai 2020, 20:02:57
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Mai 2020, 09:40:36
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...).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 15 Mai 2020, 10:42:58
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Mai 2020, 11:05:07
Zitat von: KarlHeinz2000 am 15 Mai 2020, 10:42:58
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...).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 15 Mai 2020, 13:41:31
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Mai 2020, 14:01:12
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).

Zitat von: KarlHeinz2000 am 15 Mai 2020, 13:41:31
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?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 15 Mai 2020, 14:15:18
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

#define SERIAL_RX_BUFFER_SIZE 256

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Mai 2020, 14:28:11
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.)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 15 Mai 2020, 14:33:16
Der RX Buffer kommt von Arduino IDE. Da hat man im Sketch keinen Einfluss (mehr).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 15 Mai 2020, 14:41:19
Hab zu dem Thema noch das hier gefunden:
https://arduino.stackexchange.com/questions/1726/how-does-the-arduino-handle-serial-buffer-overflow
ZitatFor a software serial port in SoftwareSerial.h (https://github.com/arduino/Arduino/blob/master/libraries/SoftwareSerial/SoftwareSerial.h) the receiver buffer size _SS_MAX_RX_BUFF is defined as 64 bytes. In both cases it stops attempting to insert received data into the queue when it is full, so you could get a mix to old and new data depending on how you're retrieving data from the queue. Ideally it would be best to ensure the buffer always gets emptied in a prompt manner to avoid the buffer filling. Maybe take a look at timers and implementing a simple state machine if your problem is related to other code blocking the main loop.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 15 Mai 2020, 20:59:46
Die Änderungen sind soweit drin. Hat ein wenig gedauert, weil ich den LM2576HV noch nachmalen musste. Rest siehe Edit. :)

Viele Grüße
rob

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 16 Mai 2020, 07:32:37
@rob:
Auch das sieht wieder gut aus, und funktiional scheint das auch soweit zu passen (war kurz unsicher wg. Verbindung RX-CRX und TX-CTX, aber zum Glück hatte ich von dem GW ein Bild gemacht und das ins Wiki gepackt...).

Allerdings finde ich die Optik des GW's etwas unglücklich. Konkret sollte m.E. die USB-Buchse in etwa an derselben Stelle sein wie beim Nano. Außerdem finde ich es leichter, wenn die Stomversorgung "verwinkelt" ist, statt die TX/RX-Linien. Falls zu wenig Platz ist, könnte man evtl die MCP-Boards insgesamt etwas weiter nach oben verschieben, aber eigentlich müsste das noch so passen.

Was die Versorgung von Node-n + Last angeht, fällt mir grade auf, das die VCC-Verbindung auf RAW geht. Das mag zwar sicherer sein, aber hinter einem gut eingestellten Step-Down müßte insgesamt eigentlich auch VCC als Eingang ok sein? Alles andere führt nur zu weiteren leichten Verlusten... Oder übersehe ich da was?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 16 Mai 2020, 09:18:49
Vorweg: Ich habe jetzt nicht den kompletten Thread noch einmal gelesen, also falls mein folgendes Geschreibsel schon diskutiert wurde und somit hinfällig ist, seht es mir bitte nach, wenn ich das hier nochmal zur Sprache bringe.. ;)

Mir persönlich 'gefallen' die in der Abbildung beschriebenen errechneten Widerstandswerte nicht so richtig, insbesondere der für R3.
Es ist für einen Anfänger m.E. viel zu verwirrend und erzeugt lediglich Unsicherheiten. Zumal in der Abbildung der Widerstandswert bei R4 dann wiederum 120Ohm beträgt (btw: afaik sollten die Terminierungswiderstände immer gleich groß sein?!) und auf den gängigen Modulen meist sowieso 120Ohm verbaut sind. 
Ich würde daher 'empfehlen', es bei besagten 120Ohm an beiden Seiten zu belassen.

Die standardmäßig angegebenen 120Ohm sind nicht in Stein gemeißelt, sie kommen daher, dass in ISO11898 die Verwendung von Kabeln mit einer Impedanz von 120Ohm 'empfohlen/vorausgesetzt' wird. Aber auch dort wird eine Spanne angegeben (s. bspw. ISO 11898-2, Kap. 7.5), der letztliche Wert ist von mehreren Faktoren abhängig.

Streng genommen müsste bereits bei den gerne genutzten CAT-Kabeln ein anderer Wert gewählt werden, nämlich meist 100Ohm, da dies i.d.R. die Impedanz dieses Kabeltyps ist, zu dem der Wert der Terminierungswiderstände passen sollte. Für uns 'Normalanwender' ist das aber m.A.n. vernachlässigbar.
Wenn man jedoch nun schon eine Berechnung der Abschlusswiderstände einbringt, dann sollte man wohl auch das Thema galvanische Trennung aufgreifen - was aber für den Anfänger mit den gängigen Modulen ebenfalls wieder etwas zu kompliziert und verwirrend sein mag und für den 'normalen' Anwendungsfall u.U. overdosed ist.

Gemäß dem KISS-Prinzip sollte es imho also bei den Standardwerten und dem typischen 'plug&play'-Szenario mit den gängigen Modulen bleiben, alles andere würde an dieser Stelle (= in der Abbildung, ansonsten können solche Themen natürlich gerne irgendwo erwähnt werden!) m.A.n. eher 'stören' bzw. verwirren..

Just my 1/2Euro ;)   
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 16 Mai 2020, 09:38:34
Sehr guter Einwurf!

Vielleicht noch eine etwas allgemeinere Anmerkung zum Thema Wiki-Artikel/Starter-Guide:
Ich habe den damals "on the fly" (angelehnt an das EnOcean-Muster) erstellt, nachdem ich die ersten Hürden soweit genommen hatte und dann später nur noch erweitert/ergänzt, wenn halt was neues dazukam. Der ist aber keineswegs "heilig", schon gleich nicht, was diese ganzen Schaltungsthemen angeht. Da bin ich einfach (ziemlicher) noob und habe eher experimentelles "Wissen".

Daher:
- Wer sinnvolle Ergänzungen/Querverweise hat und die notwendigen Rechte, direkt ins Wiki zu schreiben: just do it (v.a. @Ranseyer), ich fühle mich schlicht nicht in der Lage, das "unfallfrei" ins Wiki zu übersetzen, was da zu Bus, Terminierung usw. steht...
- Guideline sollte das sein, was Schotty schreibt: KISS, default-Werte verwenden, die "jeder" in der Grabbelkiste hat bzw. die mit den Modulen automatisch kommen, Optimierungen usw. dann im Text erwähnen;
- Wer keine Wiki-Rechte hat: Bei Interesse einfach an Peter (die Adresse ist über die Wiki-Hauptseite verlinkt) wenden, oder dann einfach Textvorschläge hier oder (wenn keine teechnischen Fragen zu klären sind besser!) im Wiki-Bereich einstellen; gerne mit Formatierung, notfalls aber einfach als simplen Text.

Es macht m.E. mehr Sinn, wenn die Leute das v.a. bzgl. RS485 zusammentragen, die sich aktuell damit befassen, wie wenn ich jetzt auch noch dazu wieder meine Kiste aus dem Keller hole; wollte eigentlich ein paar andere Instruktionen irgendwann mal weiter schreiben ;) .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 16 Mai 2020, 18:55:59
Optische Dinge sind kein Thema und flink gemacht. Der gedrehte Micro ist dem Steckboard geschuldet und es wurde bereits festgestellt, dass Steckboards nicht gut sind. Ich wollte eh noch optisch angleichen, vom Steckboard weg und die Buck-Converter ersetzen.

Das größere Problem scheint jedoch inhaltlicher Natur (Optik alleine bringt keine Punkte). Dort steckt wohl der Teufel im Detail. Ich meinte ganz gut durchgestiegen zu sein, aber jetzt stehe ich aufm Schlauch.  :o

Die 130Ohm stammen ja aus dem Calculator (R1 u. R2 auch; http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp (http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp)). Eingegeben 12V und 120Ohm, Rest belassen (siehe unten im Bild). Weil das Ergebnis nicht passt, heißt es m.E. alles zurück auf Anfang:
Im ersten Bild mit Max485 bleiben am GW-Transceiver u. Last Node also doch wieder die Standard-Widerstände. Den Extra-Krams mit 12V, externen Widerständen usw. braucht es dann nicht mehr. Im Prinzip brauchen es das Bild nicht, weil im Original vom Wiki bereits alles drin ist und das neue Bildchen nichts Nennenswertes hinzuträgt.

Schwieriger wird es bei den CAN-Dingern. Die haben ja keinen PullUp/PullDown on Board. Die vom Calculator passen nicht. Was male ich dann da hin? Auch die Busabschlüsse sollen eh ganz anders gemacht werden.
Wahrscheinlich macht es gar keinen Sinn irgendwas bildhaft festzuhalten (zu viele Wege/ Kompromisse). War ja auch auf meinem Mist gewachsen und jetzt kostet es Euch unnötig Zeit u. Diskussion. Das war nicht meine Absicht. Meine Absicht war es Klarheit zu schaffen, was so nicht erreichbar scheint.

MySensors@RS485 ist schwieriger als ich dachte. Kabelgebunden gehts auch mit dem Ethernet-GW, ohne Widerstands- und Transceiver-Fragen. Oder halt 1-Wire. Mist, jetzt hab ich die CAN-Module umsonst geordert.  :'(

Die zwei Bilder würde ich vorerst rausnehmen, um nicht falsche Infos unnötig weiter zu verbreiten. @Beta_User: ich kann es auch ausm Wiki nehmen, dann brauchst Dich darum nicht kümmern.

Vielen Dank für Eure Rückmeldungen und beste Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 16 Mai 2020, 20:12:47
Hi rob,
oh man, jetzt habe ich ein schlechtes Gewissen, ich wollte dich nicht demotivieren!!

Bzgl Widerstandswerte: Mein Geschreibsel bezog sich erstmal auf CAN, weil ich die Bemerkung heute Morgen in deiner schönen(!) Grafik hier https://forum.fhem.de/index.php/topic,84814.msg1054219.html#msg1054219 gesehen hatte. Bzgl RS485 hatte ich gar nicht geguckt, sorry..
Afaik ist das mit den gleich-großen Widerständen eigtl auch bei RS485 der Fall, aber (auch) da kann ich mich irren! Ist alles nur angelesen, ich bin diesbzgl kein Experte!

Bild bzgl RS485: Deine MAX485-Module sind deutlich schicker als meine und eine Breadboard-Darstellung mag ein anderer User vielleicht/bestimmt lieber, insofern finde ich es überhaupt nicht überflüssig! Kann/sollte m.A.n. also ruhig drinbleiben. Aber auch da (jetzt gerade nachgesehen ;) ) würde ich vorschlagen, die Bemerkung hinsichtlich der abweichenden Widerstandswerte rauszunehmen.
Aus dem ganz einfachen Grund, dass a) die fertigen MAX485-Module i.d.R. bereits mit 120Ohm-SMDs bestückt sind und es b) wie bei CAN erwähnt m.A.n. eher verwirrend ist, wenn da abweichende Werte aufgeführt werden. (Jetzt mal unabhängig davon, dass ich bei meiner Grafik auch die Standard-R7 mit 120Ohm 'drin' habe.)

Ich hatte mich (weil ich eine regelrechte Odyssee hinter mir habe, was die finale Inbetriebnahme anging - Fehler lag allerdings *ganz* woanders: die Steckdose war mit dem Lichtschalter oben an der Kellertür gekoppelt  ::)  >:(  :-X ) mit dem Kram eine ganze Weile beschäftigt und viel gelesen, anfangs bzgl RS485, später dann aber mehr bzgl CAN, weil Beta-User mir freundlicherweise auch MCP2551er geschickt hatte und ich irgendwann dachte 'hmmm, vielleicht liegt der Fehler ja bei RS485 selbst'.
Ohne jetzt groß ausschweifen zu wollen: Unterm Strich scheint es so zu sein, dass das ganze in unseren Anwendungsfällen eigtl eher 'vernachlässigbar' ist. Je größer (Kabellängen, Anzahl Nodes etc), komplexer (auch hinsichtlich Verkabelung) und schneller (Übertragungsrate) die komplette (Bus-)Installation wird, desto kritischer wird es u.U. auch mit solchen Feinheiten wie den Terminierungswiderständen.
Auch bei RS485 wird ja gerne normales CAT-Kabel genutzt (mit 100Ohm Impedanz) und es läuft meist trotzdem mit den 120er Widerständen. Es gibt auch genügend User, die keinerlei Schirmung benutzen, GND nicht verbinden etc und bei denen es auch ohne Probleme läuft. Bei anderen wiederum macht dann aber durchaus auch mal ein gewisser Potentialunterschied oder die mangelnde EMV-gerechte Auslegung Probleme.   
Wer wirklich tiefer in die Materie einsteigt und eben nicht die 'normalen' Module einsetzen, sondern alles selbst zusammenbauen will, der wird/sollte sich dann sowieso mit den weiteren Feinheiten auseinandersetzen. Dazu gehören m.E. dann eben auch die unterschiedlichen Widerstandsgrößen, eine EMV-gerechte Installation, galvanische Trennung etc.pp.
Das ist aber für den Einsteiger (und darum geht es hier doch erstmal prinzipiell) alles viel zu viel.

MySensors@RS485 ist nicht schwieriger als du dachtest, lass dich bitte von meinem Beitrag open nicht abschrecken oder verunsichern! Nachdem ich dann nach einigen Wochen (naja, streng genommen Monaten  >:( ) und unendlich vielen Varianten und Fehlersuchen dann mal auf das eigentliche Problem mit dem erwähnten Lichtschalter gekommen bin, habe ich kurzerhand meine Nanos und RS485-Module wieder aus der Kiste geholt, das (mittlerweile gelegte) LAN-Kabel als Busleitung mißbraucht und voilà, innerhalb kurzer Zeit lief alles problemlos. Sollte die Installation wachsen, werde ich sicherlich auch auf CAN umsteigen, aber bisher ist bei meiner Mini-Installation mit 3 RS485-Modulen (1GW, 2Nodes), AltSoftSerial@Nano und 9600kbps alles problemlos. Stromversorgung der einzelnen Nanos via jeweiliger USB-Buchse, lediglich A+B und GND habe ich verbunden. Und so dürfte der 'normale' Einsteigerbeginn eben aussehen: Günstige Nanos und RS485-Module bestellen, Strippe ziehen, verkabeln und flashen und dann 'erst mal gucken'. Wenn dann Probleme auftauchen, fragt man entweder hier oder im MySensors nach (jaaa, schon klar - natürlich erst, wenn man nach eigener Recherche nicht weiter kommt..   ;) ).

Bzgl PullUp/Down & Busabschlüsse @CAN: Sooo viel schwieriger im Sinne von 'anders' ist es da eigtl auch nicht (jedenfalls für uns Normalos), die Systeme sind sich recht ähnlich (was die physische Seite angeht).
Auch da gilt m.A.n. aber erstmal: KISS. Der 'normale' Einsteiger wird sich erstmal ein paar fertige Module kaufen (btw: Welche hast du dir bestellt?), anschließen und fertig. Ob und welche Widerstände da drauf sind und wie die Terminierung dort realisiert ist, ist dabei erstmal zweitrangig. Wichtig ist der Hinweis, dass nur am jeweils ersten und letzten Modul die Abschlusswiderstände drauf sind. Das reicht für den Einstieg.

Als 'richtiger' Bus ist eigtl auch eine Verkabelung vorgesehen, bei denen die Teilnehmer wirklich 'hintereinander' angeschlossen sind, stubs/Stichleitungen sollten möglichst vermieden werden. Aber auch das ist relativ, es sind je nach Installation auch durchaus stubs problemlos verwendbar. Es ist eben nur wichtig zu wissen, wie es prinzipiell eigtl aussehen sollte, damit man es hinterher bei der Fehlersuche etwas leichter hat. Aber das wird man bei der dann meist eh notwendigen Recherche früher oder später auch herausfinden. Für den Einsteiger reicht m.A.n. der Hinweis "alle Nodes sind in Reihe am Bus anzuschließen, Stichleitungen sollten möglichst vermieden werden" oder sowas in der Art. Aber das wird im Wiki von Beta-User ja vermutlich schon drin stehen (hab's jetzt aktuell nicht nochmal komplett gelesen ;) ).

Wer wirklich eigene Schaltungen aufbauen und eben keine fertigen Module verwenden will, der wird früher oder später bspw. auch darauf stoßen, dass die MCP2551er eigtl nicht mehr verwendet werden sollten, sondern die Nachfolger MCP2561 und MCP2562 eingesetzt werden sollten. Unterschiede sind in den application notes und Datenblättern zu finden, kann ich aber bei Gelegenheit sonst hier auch gerne irgendwann nochmal kurz aufführen, wenn das von Interesse ist. Aber da auf den gängigen Modulen (TJA lasse ich jetzt mal außen vor) sowieso noch die alten MCP2551er verbaut sind, ist auch das für den 'Normalo' uninteressant/irrelevant.

Ganz kurz bzgl der Widerstände @CAN:
- PullUp/Down:
Bei den fertigen Modulen sind (zumindest bei einigen Modellen) teils durchaus PullUps/Downs vorzufinden (ich meine jetzt extern verbaute, nicht welche innerhalb der Transceiver selbst). Auch im KFZ-Bereich werden die von einigen Autobauern (den Namen 'VW' hatte ich diesbzgl mal irgendwo gelesen) wohl durchaus verwendet. Sinn von den Teilen ist (Achtung: rein aus dem Gedächtnis, kann also durchaus fehlerbehaftet sein! ;) ) wohl, den Störabstand zu vergrößern, weil so eine Art 'definierter' Zustand in Ruhe erzielt werden kann. Auch können so Kurzschlüsse auf dem Bus (bessser?) erkannt werden. So habe ich es mir zumindest stark vereinfacht gemerkt - bitte nicht schlagen, wenn es nicht den Kern der Sache trifft.. ;)

- Abschlusswiderstand/Terminierung an den jeweiligen Busenden: Prinzipiell auch wie bei RS485, ein (erstmal) 120Ohm-Widerstand hängt zwischen CAN-H & CAN-L. Es gibt aber (auch hier) noch die 'fancy' Varianten, bei denen (einfach ausgedrückt) anstelle eines 120ers bspw je ein 60Ohm-Widerstand pro Leitung verwendet wird (also insg. 2 Widerstände). Nennt sich 'biased split termination' (und ist iirc teilweise auch bei gängigen Modulen vorzufinden). Zusätzlich kann man da dann auch noch nen Kondensator und was-weiß-ich-nicht-noch-alles verbauen, aber auch das führt erstmal zu weit.

Ich hoffe, ich habe dich jetzt etwas 'beruhigen' und ein wenig für Klarheit sorgen können. Falls ich die Sache nur verschlimmert habe: duck-und-wech..  ;D   

Gruß
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 16 Mai 2020, 20:53:42
Zitat von: Schotty am 16 Mai 2020, 20:12:47
...jetzt habe ich ein schlechtes Gewissen, ich wollte dich nicht demotivieren!!
Falls ich die Sache nur verschlimmert habe...
Hallo Schotty.

Brauchst Du ehrlich nicht zu haben. Ich bin auch nicht demotiviert. Nix verschlimmert, im Gegenteil: super klar gestellt. Alles gut  ;D
Ich denke, ich weiß jetzt wie ich weiter machen kann. Ich möchte diesen Fred jedoch weniger okkupieren, damit es mehr um Technik gehen kann. Der Grafikkrams ist ja nur ein Randthema.

Viele Grüße
rob

PS: Meine Bilderchen müsst Ihr nicht jedes Mal loben, um mich zu motivieren. Ich machs gerne und wenns gefällt freu ich mich natürlich, aber ich muss damit nicht im Mittelpunkt stehen :D
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 16 Mai 2020, 20:55:30
..nur noch eine ganz kurze anmerkung bzgl des von dir verlinkten widerstandsrechners für rs485: 100m ist ja schon echt ne hausnummer. wenn ich da mal 20m eingebe, kommen ca 122ohm raus, bei 50m ca 125ohm. den unterschied bzgl 130 vs 120 finde ich jetzt auch nicht sooooo groß (bin aber auch kein elektroniker ;) ),als dass man da nun zwingend drauf hinweisen und die leute zum smd-braten animieren müsste. bei anderem awg-wert des kabels sieht das ganze dann auch schon wieder aus. cat5 wird sicherlich auch eher 'mal eben' verwendet werden, als cat7, also müsste man das dann streng genommen auch wieder berücksichtigen, etc.pp.
ich hatte jetzt bei mir auch ganz einfaches cat5 genommen,einfach weil ich das noch in entspr länge liegen hatte und erstmal testen wollte (am anfang in der ersten euphorie hatte ich auch schon ne 50m bzw 100m-rolle cat7-verlegekabel und zig bauteile für galvanische trennung etc im warenkorb,dann aber zum glück doch nicht gleich bestellt ;) ). wie gesagt, funzt bisher problemlos mit den standard rs485-modulen und 120ohm am anfang und ende..
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 16 Mai 2020, 21:02:29
Gute arbeit muss und sollte doch auch gerne mal gelobt und anerkannt werden, das kommt heutzutage doch eh schon viel zu kurz  :D

Ich bin zwar nicht der TE,aber von okkupieren kann m.A.n. nicht die Rede sein. Es geht doch ums Thema, also ist (zumindest für mich ;) ) sowieso alles gut! Und gerade, wenn du da was fürs Wiki erstellst, dann sollten etwaige Unklarheiten doch eh besprochen und idealerweise beseitigt werden! Also halte uns gerne auf dem Laufenden - meine Meinung..

Welche CAN-Module hattest du dir denn jetzt eigtl bestellt?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 16 Mai 2020, 21:15:30
Zitat von: Schotty am 16 Mai 2020, 21:02:29
Welche CAN-Module hattest du dir denn jetzt eigtl bestellt?
die frechen Dinger hier https://www.ebay.de/itm/NEW-MCP2551-High-Speed-CAN-Communicate-Protocol-Controller-Bus-Interface-Module/401132415647 (https://www.ebay.de/itm/NEW-MCP2551-High-Speed-CAN-Communicate-Protocol-Controller-Bus-Interface-Module/401132415647) Ich meine, solche hatte Beta-User auch einmal verlinkt gehabt.

Ja, ich halte Euch gerne auf dem Laufenden.

Viele Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 17 Mai 2020, 07:39:13
Yep, jedenfalls auf den ersten Blick sehen die aus wie die, die ich jetzt hier rumliegen habe. (Die meisten meiner Nodes sind aber mehrfach umgelötet und "beherbergen" MCP2551-Chips auf umgelöteten TJA1050-Platinen, die adaptiert sind auf die typischen RS485-Module...). Nur die, die ich neu aufgebaut habe, haben die "lila" Module - was bis dato immer stressfrei ging.

Kurz zusammengefaßt daher zu dem Bus-Thema meine These: Was für RS485-Module paßt, stört auch die CAN-Transceiver nicht ;) .

Und es ist auch ok, wenn hier teils Wiki-Themen usw. auftauchen. Der TE bin ich (und könnte eigentlich ein "gelöst" davor machen? Wir tappen da nämlich m.E. deutlich nicht mehr im Dunkeln bzw. mein setup funktioniert trotz meiner Mehrfachadaptionen...!)

Was die "verwende den Nachfolger"-Frage angeht: Es ist ok, wenn der Hersteller sagt, er hätte was neues (stromsparenderes, btw), und dessen Verwendung empfiehlt, aber das heißt doch noch lange nicht, dass die alten Murks waren, oder? Wie dem auch sei, ich habe jetzt auch mal ein paar "nackige" MCP2562 bestellt, damit ich ggf. mitreden kann... War eben noch finanziell verkraftbar (unter 50ct/St., mal sehen, wann ich ggf nach Eintreffen mal Muße zum Löten habe. Aber fertige Module gibt es damit eben leider (noch) nicht, und zu den Baudraten findet sich jedenfalls im Datenblatt nur eine Obergrenze, oder übersehe ich mal wieder was?).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 17 Mai 2020, 08:32:52
Für die Selberlöter@CAN anbei noch ein Bild von einem umgelöteten TJA-Modul und einem "nativen" MCP2551-Modul.

Bei dem TJA-Modul war afaik mal ein 120-Ohm-R drauf gewesen (R3), jedenfalls gehen die beiden Verbindungen zu CANH/CANL. Auf dem "nativen" sind die (per default unbestückten) Lötpunkte für R2 und C2 zu erkennen, beide verbinden CANH und CANL. Der Rest ist RX/TX-LED und ein Spannungsstabilisation, also keine großen Geheimnisse und bei Bedarf mit einem "nackigen" IC mMn. recht stressfrei nachzubauen...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 17 Mai 2020, 10:26:24
Zitat von: Beta-User am 17 Mai 2020, 07:39:13
Was die "verwende den Nachfolger"-Frage angeht: Es ist ok, wenn der Hersteller sagt, er hätte was neues (stromsparenderes, btw), und dessen Verwendung empfiehlt, aber das heißt doch noch lange nicht, dass die alten Murks waren, oder?
Nein, habe ich aber doch so auch nie behauptet/gesagt?!

Zitat
Wie dem auch sei, ich habe jetzt auch mal ein paar "nackige" MCP2562 bestellt, damit ich ggf. mitreden kann...
Naja, wirklich viel 'mitzureden' gibt's da wohl nicht, denn von den Unterschieden wirst du/wir im normalen Anwendungsszenario vermutlich nicht viel merken..
Zitat aus dem Migration-Sheet: "Although major improvements have been made, resulting in increased EMC performance and much lower current consumption, the differences in using the MCP2561 versus the MCP2551 are minor."
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 17 Mai 2020, 10:51:58
Zitat von: Beta-User am 16 Mai 2020, 09:38:34
- Wer sinnvolle Ergänzungen/Querverweise hat und die notwendigen Rechte, direkt ins Wiki zu schreiben: just do it (v.a. @Ranseyer), ich fühle mich schlicht nicht in der Lage, das "unfallfrei" ins Wiki zu übersetzen, was da zu


Hi,

ich halte mich aus dem Thread /Wiki in letzter Zeit weitgehend raus. Einerseits ist für mich alles geklärt. Anderseits teile ich nicht alle Meinungen hier, und habe auch relativ wenig Zeit.

Prinzipiell ist jeder Beitrag und jede Aktivität super.


-Aber RS485 hat m.E. mit MySensors nichts zu tun. Das wäre absolut einen eigenen Wiki Artikel wert.
-Leitungen für "Funkverbindungen" sollen durchgängig den selben Wellenwiderstand haben und auch unbedingt mit genau diesem terminiert werden, dann gibt es nirgendwo Reflektionen.
-RS485 betreibt man nicht mit 1MBit, dann würde ich es doch gleich mit 9600 / 19200 Baud betreiben. Anfangs in diesem Thread habe ich mal berechnet: 800-900m bei 19200 Baud funktionieren ohne die 120 Ohm Abschlusswiderstände. Die kann man also einfach weglassen.
-Problem bleibt: Die Busleitung verläuft lange und parallel. Somit bildet die Leitung einen Kondensator. Wenn also die Leitung umgepolt werden soll, muss diese geladen oder entladen werden. Das kostet Zeit, die Signale "verwaschen" (Signalflanken gehen mehr und mehr verloren) und es bringt den RS485 Chip ggf. auch ein bisschen mehr zum schwitzen.
-Somit ist für mich die beste und einfachste Lösung das Widerstandsnetzwerk analog zu Homematic-Wired an eine beliebige Stelle im Bus zu platzieren. Damit wird dann der Treiber-Chip unterstützt und die Leitungen schneller und vor allem sicherer auf Ihre Pegel gezogen.
-Da ich kein religiöser Prediger bin, reicht es mir dass ich selbst damit zufrieden bin. Falls allerdings jemand fragen wollte, würde ich jedem genau diese Methode empfehlen. Zumindest bei 24V ist die HM-Wired Variante nicht nur tausendfach erbrobt. Die 12V Variante ist allerdings relativ eng davon abgeleitet: https://wiki.fhem.de/wiki/Easy-RS485-Bus#Terminierung (Hier finden sich die Widerstandswerte für 12 + 24V)

PS: Das sollte alles zutreffen unabhängig vom RS485 / CAN Chip...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 18 Mai 2020, 10:13:34
@Ranseyer: Danke nochmal für den Hinweis auf die "Easy"-Terminierung. Scheint mir auch (sehr) valide, habe daher jetzt einen Hinweis auf den ganzen Artikel im Guide reingenommen (da könnte man die Baustelle mal abbauen, oder?).

Zitat von: Schotty am 17 Mai 2020, 10:26:24
Nein, habe ich aber doch so auch nie behauptet/gesagt?!
Wer hatte behauptet, du hättest was mit dem "outdated"-Hinweis zu tun ;D ?

Was die Austauschbarkeit angeht: Da die CAN-Transceiver ganz andere typische Anwendungfelder haben, ist mMn. nicht unbedingt sichergestellt, dass die Nachfolger wirklich auch mit den niedrigeren Baudarten laufen. Daran hatte der Autor des Hinweises auf die "minor changes" uU. gar nicht gedacht... (Wir werden sehen ;D .)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 18 Mai 2020, 10:34:05
Zitat von: Beta-User am 18 Mai 2020, 10:13:34
Wer hatte behauptet, du hättest was mit dem "outdated"-Hinweis zu tun ;D ?

Naja, das:
Zitat von: Beta-User am 17 Mai 2020, 07:39:13
Was die "verwende den Nachfolger"-Frage angeht: Es ist ok, wenn der Hersteller sagt, er hätte was neues (stromsparenderes, btw), und dessen Verwendung empfiehlt, aber das heißt doch noch lange nicht, dass die alten Murks waren, oder?
klang für mich so, als wenn das auf den Satz "der wird früher oder später bspw. auch darauf stoßen, dass die MCP2551er eigtl nicht mehr verwendet werden sollten, sondern die Nachfolger MCP2561 und MCP2562 eingesetzt werden sollten" in meinem langen Geschreibsel davor bezogen gewesen wäre. Aber dann ist ja alles gut ;)

Beachten sollte man bei einem drop-in-replacement für die MCP2551er m.A.n. noch die jeweils geänderten Funktionen von Pin 5 bei den MCP2561/2ern und damit einhergehende etwaige Änderungen an der Schaltung, aber das ist ja vermutlich auch nichts neues, wenn man sich das Migration-Sheet und die Datenblätter ansieht.
Dann mal viel Spaß beim Testen, ich bin gespannt..   
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 18 Mai 2020, 18:14:44
Anbei werfe ich mal diese Bilderchen in den Ring. Steckbretter sind weg und KISS as possible  ;D  Ins Wiki kann ich es auch reinsetzen, falls gewünscht. Ansonsten kann ich die Übersichten noch etwas reifen lassen.

Ich habe die anderen zwei Posts mit den Bildern auf Draft gesetzt. Dort wollte ich nicht weiter editieren, weil man da sonst nicht mehr durchsieht.

Viele Grüße
rob

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 19 Mai 2020, 08:22:37
So ist es auch hübsch!

Inhaltlich:
- Kannst du die Verbindung DE-RE optisch besser hervorheben? Das geht mMn. etwas unter, wenn die über das MAX-Modul läuft, von oben her als "normale" Kabelabzweigung wäre vermutlich klarer.
- Irgendwie ist mir R7 an "Node 1" entgangen. Der sollte da selbstredend auch noch weg (dto. der etwas verwirrende Hinweis in der CAN-Transceiver-Variante).
- Die Hinweise auf "Nano" sind teilweise komisch, da (in der Regel) ein Pro Mini abgebildet ist (dto. in der CAN-Variante, da ist bei der letzten Pro Micro genannt).

Wunsch:
Die MAX-Variante mit dem Widerstandsnetzwerk wie von @Ranseyer vorgeschlagen. Dann kommen (nach meinem Verständnis) _alle_ Widerstände von den Modulen, und es muß einen (? In https://wiki.fhem.de/wiki/Easy-RS485-Bus sind zwei erwähnt?) Busabschluss geben, wobei @12V dann entsprechend meinen bescheidenen Physik-Kenntnissen statt der 22k 11k stehen müßten? (@rob: Eilt nicht, kannst du ja ggf. auch austesten, wenn die CAN-Transceiver ohne R da sind.).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 19 Mai 2020, 21:46:51
Es fällt mir nicht leicht die Infos auf die Reihe zu bringen. Einerseits alle extra Widerstände weglassen und nix weglöten (plug'n'play, nicht verwirrend), andererseits Widerstände bzw. Widerstandsnetzwerk einbauen (wofür verbaute R's weg müssten, wenn max485-Module im Einsatz). Ich versuch es trotzdem mal ;)

Hatte hin und her überlegt, R7 an Node1 zu belassen und im CAN-Schema R1/R2 wegzulassen. Andererseits sind im Orig-Wiki-Bild Hinweise, R7 am Anfang/Ende zu lassen und von Zwischen-Nodes R7 zu entfernen. Hab mich nicht getraut und doch bildlich u. textlich am Wiki-Original orientiert.

Zitat von: Ranseyer am 17 Mai 2020, 10:51:58
Anfangs in diesem Thread habe ich mal berechnet: 800-900m bei 19200 Baud funktionieren ohne die 120 Ohm Abschlusswiderstände. Die kann man also einfach weglassen.
...PS: Das sollte alles zutreffen unabhängig vom RS485 / CAN Chip...
OK weglassen. Müsste fürs MAX-Schema dann gelten, dass Einsteiger doch überall R5-R7 runterlöten und stattdessen drei Widerstände 4K7, 5K6 und 22K (f. 24V) "irgendwo" einbauen sollen (CAN analog, nur dass da nix abgelötet werden muss)? Nackte max485/487 sind ja kein plug'n'play.
"Irgendwo" bedeutet wahrscheinlich egal, ob am Anfang, Ende oder in der Mitte vom Bus. Vorschlag: am GW, weil die Nodes meist mit Sensorik "voller" sind.

Zitat von: Ranseyer am 17 Mai 2020, 10:51:58
Die 12V Variante ist allerdings relativ eng davon abgeleitet: https://wiki.fhem.de/wiki/Easy-RS485-Bus#Terminierung (Hier finden sich die Widerstandswerte für 12 + 24V)
Die 12V-Variante hab ich dort leider nicht gefunden. Ansonsten hat Beta-User bereits 11K vorgeschlagen (ca. 4V). Vielleicht gingen auch 8K2Ohm (ca. 4,9V)? Ich hab keine Ahnung.

Egal welcher Widerstand für 12V gelten soll: 24V und 12V wird in einer Grafik ggf. verwirrend. Mit vier Grafiken lösbar: 12V MAX+CAN; 24V MAX+CAN (ggf. zu viel im Wiki)?

Hat natürlich Zeit. Ich geh denken und teste erstmal ein wenig  :)

Viele Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 20 Mai 2020, 08:47:06
Zitat von: rob am 19 Mai 2020, 21:46:51
Hatte hin und her überlegt, R7 an Node1 zu belassen und im CAN-Schema R1/R2 wegzulassen. Andererseits sind im Orig-Wiki-Bild Hinweise, R7 am Anfang/Ende zu lassen und von Zwischen-Nodes R7 zu entfernen. Hab mich nicht getraut und doch bildlich u. textlich am Wiki-Original orientiert.
OK weglassen.

Das ist kein 'Original', das ist nur ne Skizze von mir und keineswegs in Stein gemeißelt! ;)
Ich finde deine Abbildungen schicker, also wenn du Zeit und Lust hast, dann kannst du gerne eine Neuauflage von meinem Bild mit den Nanos machen und es damit ersetzen, dann sehen alle gleich aus!
Ich hatte damals auf die Schnelle auch nicht das MAX485-Bild gefunden, was du benutzt hast und daher unten nochmal die Bezeichnungen bzgl DE etc hingeschrieben, bei deinen Bildern sind die ja bereits auf den Modulabbildungen vorhanden. Ist auch nochmal übersichtlicher. 
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 20 Mai 2020, 09:25:22
Zitat von: rob am 19 Mai 2020, 21:46:51
Es fällt mir nicht leicht die Infos auf die Reihe zu bringen. Einerseits alle extra Widerstände weglassen und nix weglöten (plug'n'play, nicht verwirrend), andererseits Widerstände bzw. Widerstandsnetzwerk einbauen (wofür verbaute R's weg müssten, wenn max485-Module im Einsatz). Ich versuch es trotzdem mal ;)
Hatte hin und her überlegt, R7 an Node1 zu belassen
Vorab: R7 an Node 1 sollte (in V 1.3) noch weg. Es dürfte zwar bei 3*120Ohm noch funktionieren, aber das ist nicht entsprechend Spec. Die CAN-Variante paßt soweit und ist seit gestern auch schon im Wiki eingebaut. Ausdrückliches Danke dafür, finde das auch sehr schick (und zu 100% informativ)!

Was das Rumpfriemeln an den MAX-Modulen angeht: Ja, das ist und bleibt für den Einsteiger irritierend, ganz egal, wie rum man das darstellt oder angeht. "Komplette Module" für p&p kaufen und dann was weglöten...? Ist nicht das, was sich der komplette noob erhofft, aber besser was weglöten, wie Hühnerfutter suchen müssen ;D .

MMn. ist es so: zum erste Erfahrungen sammeln, nimmt man die "fertigen" MAX-Module. Klappt das soweit (auf dem Steckbrett), kann man sich dran machen, Nodes "für's echte Leben" zu konzipieren. Und da kommen dann z.B. die Platinen von @Ranseyer und das Widerstandsnetzwerk ins Spiel: Da verwendet man nämlich "nackte" IC's, packt ggf. noch einen Kondensator im Miniaturformat dazu und verstöpselt das ganze mit sauber gecrimpten Steckern ;) . Auch das ist Easy, aber wer diese Variante haben will, muß und wird sowieso anders planen wie der, der nur "irgendwo" mal eben schnell eine "normale" Funk-MySensors-Node hinpacken will bzw. muß.

Zitat
stattdessen drei Widerstände 4K7, 5K6 und 22K (f. 24V) "irgendwo" einbauen sollen (CAN analog, nur dass da nix abgelötet werden muss)? Nackte max485/487 sind ja kein plug'n'play.
"Irgendwo" bedeutet wahrscheinlich egal, ob am Anfang, Ende oder in der Mitte vom Bus. Vorschlag: am GW, weil die Nodes meist mit Sensorik "voller" sind.
Irgendwo ist wahrscheinlich egal; die geringsten Verluste hat man vermutlich, wenn es beim Netzteil wäre. Irgendwie ist "Busabschluss" verwirrend, das deutet von der Wortwahl her auf das Ende der Kabelstrecke hin...
ZitatDie 12V-Variante hab ich dort leider nicht gefunden. Ansonsten hat Beta-User bereits 11K vorgeschlagen (ca. 4V). Vielleicht gingen auch 8K2Ohm (ca. 4,9V)? Ich hab keine Ahnung.
(Das war ein Schludrigkeits-Rechenfehler, die ca. 8k sind selbstredend passender.)

Zitat
Egal welcher Widerstand für 12V gelten soll: 24V und 12V wird in einer Grafik ggf. verwirrend. Mit vier Grafiken lösbar: 12V MAX+CAN; 24V MAX+CAN (ggf. zu viel im Wiki)?
Agreed, eine Variante (iVm. dem Verweis auf den Hauptartikel zum "Easy-Bus") ist mMn. völlig ausreichend, kannst dir gerne aussuchen, ob 12V oder 24V.

Und wie bereits geschrieben: das muß nicht sofort im Wiki landen, es reicht auch später noch; wer grade Interesse an dem Thema hat, liest hier ja sowieso mit...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 06 Juli 2020, 15:25:45
Zitat von: Schotty am 13 Mai 2020, 14:17:41
Ich hätte auch meine Fritzing-Datei einstellen ... aber das scheint ja nicht mehr nötig zu sein. Falls doch gewünscht: Bitte eben melden.. ;)
Hallo Schotty.

Wär super, dann würde ich das Design vereinheitlichen :) Ich möchte deshalb gern Dein Angebot annehmen und Dich bitten, die Datei einzustellen.
Mit der anderen Übersicht mache ich dann weiter und würde den einigermaßen stabilen Stand auch meinerseits zur Verfügung stellen wollen.

Vielen Dank und beste Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Schotty am 07 Juli 2020, 07:36:32
Moin rob,
hier die gewünschte Datei.
Gruß
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 08 Juli 2020, 14:48:48
Ich hab Schottys File reingenommen und die zwei Versionen mit Widerstandsnetzwerk erstellt (12V u. 24V). @Schotty: Vielen Dank :)

Dummerweise komme ich nicht zum Testen der MCP-Module, weil meine Step-Down-Wandler irgendwo zw. CN und DE festsitzen. Jedenfalls haben die MCP-Module tatsächlich je einen Widerstand und eine Kapazität an CANL u. CANH hängen.
Weil die zwei Widerstandswerte mit je 100Ohm recht klein sind, müssten man sie auf den Modulen belassen können, ohne am Widerstandsnetzwerk ändern zu müssen. Die beiden Kapazitäten liegen bei gemessen knapp 1nF - sollten auch nicht weiter stören.

Viele Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 08 Juli 2020, 16:09:16
Thx, hab's (ohne eingehende Prüfung im Detail, was die Widerstandswerte angeht) im Wiki in die Gallerie aufgenommen und in dem Zuge dann auch das evtl. verwirrende Foto meines Breadboard-GW's rausgeworen.

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 09 Juli 2020, 14:39:03
Die Widerstandswerte hatte ich aus Ranseyers Wiki-Eintrag rausgeklaut (https://wiki.fhem.de/wiki/Easy-RS485-Bus (https://wiki.fhem.de/wiki/Easy-RS485-Bus)) und für 12V wie hier bespr. der 22K durch 8.2K ersetzt. Sollte was nicht passen ändere ich es natürlich ab.

Anbei nun die Fritzing-Dateien, aus welchen ich die Bilder generiert hatte (gepflegt ist die Steckbrettsicht). Das erste Bildchen der Galerie könnte m.E. weg, weil ich das eigentl. durch MySensors_RS485_Max485_SoftSerialv1.3.png ersetzt angeboten hatte. Sicherheitshalber nochmal anbei.

Viele Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 09 Juli 2020, 15:12:38
Ups, sorry, die V 1.3 ist mir irgendwie durchgerutscht.

Jetzt ist es drin, und ich habe es auch drin gelassen, denn in der Variante mit den LED's sieht man die DE-RE-Verbindung nicht ganz so deutlich.

(Nett, wie das jetzt so hübsch einheitlich nebeneinander dargestellt ist. Fehlen nur noch deine step-down, damit du auch praktisch loslegen kannst :) ).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 29 März 2021, 15:35:49
Hi,

wie habt ihr den Bus mit den MCP2551 nun laufen?

Mein Bus ist teils HW, teils serial mit 19200 Baud.

- Mein Testaufbau mit nur 2x 120 Ohm hat funktioniert (Länge ca. 1m).
- Das GW mit einer 20 cm entfernten Node lief ohne Terminierung problemlos.
- Die Nodes, eine Richtung ca. 12m und andere Richtung ca. 25m haben geredet (beidseitig 120 Ohm). Je weiter weg, um so weniger kam aber an (4 Nodes in Reihe, GW hängt dazwischen).
- Beim GW nur mit der 20 cm entfernten Node und der entfernten Termination (andere Nodes ohne Strom), hat sich der Bus aufgehängt.
- Umbau des GWs auf 12V und entsprechende Terminierung aus Wiki, redet nicht einmal die 20cm entfernte Node mehr.

Aktuell ist alles auf 12V-Versorgung. falls machbar würde ich gerne die Terminierung wieder auf die 5V beziehen, so dass ich die anderen Nodes auch mal abschalten kann. GW kann mit 5V und 12V.

@Beta-User: Du hast noch die 2x 120 Ohm am Ende und je 2 kOhm CanH -> 5V, CanL -> GND?


Danke und Gruß
Bernd
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 29 März 2021, 17:59:40
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 29 März 2021, 18:12:05
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
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 29 März 2021, 18:41:54
https://wiki.fhem.de/wiki/Easy-RS485-Bus
(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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 29 März 2021, 19:58:19
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 29 März 2021, 21:52:21
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:
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


Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 29 März 2021, 22:12:23
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)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 30 März 2021, 13:44:37
Hier mal für Interressierte:
https://www.kfztech.de/kfztechnik/elo/can/can_grundlagen_1.htm (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  :)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag 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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 31 März 2021, 13:36:32
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 02 April 2021, 19:26:04
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag 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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 02 April 2021, 19:56:00
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag 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)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 02 April 2021, 20:46:38
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?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 April 2021, 20:48:58
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.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 02 April 2021, 20:54:35
Zitat von: KarlHeinz2000 am 02 April 2021, 20:48:58
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.

Ähhm, GW läuft mit Softserial (Nano) :o

Beim Testen mit kurzen Leitungen hatte ich die Probleme nicht. Da waren die Sensormessungen alle paar Sekunden.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 02 April 2021, 20:57:19
Auf dem GW kann man die Zahl der gepufferten Nachrichten irgendwie erhöhen, ist aber kompliziert, soweit ich mich entsinne.

SOH würde ich erst mal auf das GW beschränken.

Ansonsten habe ich den Start der Arduinos entzerrt, die warten alle unterschiedlich lang, bis sie versuchen, sich ins Netz einzubuchen...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 02 April 2021, 21:02:54
Zitat von: Beta-User am 02 April 2021, 20:57:19
Auf dem GW kann man die Zahl der gepufferten Nachrichten irgendwie erhöhen, ist aber kompliziert, soweit ich mich entsinne.

SOH würde ich erst mal auf das GW beschränken.

Ansonsten habe ich den Start der Arduinos entzerrt, die warten alle unterschiedlich lang, bis sie versuchen, sich ins Netz einzubuchen...

OK, danke.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 02 April 2021, 23:51:55
Zitat von: frober am 02 April 2021, 20:54:35
Ähhm, GW läuft mit Softserial (Nano) :o
Bei mir auch. Der USB link läuft aber über Hardware serial. Da hilft es, damit der Rx Buffer nicht überläuft. In die 64 Byte Standard Buffer passen w/c 1,5 Nachrichten. Bei meinem Baud-Unterschied von >1:10 konnte ich von fhem aus max 3 lange Nachrichten direkt nacheinander senden bis zum Überlauf. Hängt auch etwas an der fhem Performance. Mit 256 Byte Buffer komme ich gut klar. Die Grenzen hab ich noch nicht getestet.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 03 April 2021, 08:09:05
Danke euch beiden.

Ich werde beides umsetzen, ich denke das ist der richtige Weg. Mal sehen, ob ich heute noch dazu komme...

Seit gestern ca. 16 Uhr läuft die Kommunikation, ohne Eingriff (senden aus Fhem) stabil. :)



Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 03 April 2021, 19:14:43
Wenn ich das so sehe, müsste ich es doch auch im Sketch definieren können!?

HardwareSerial.h
#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif


GW mit neuen Einstellungen geflasht, mal gespannt wie weit ich ihn nun stressen kann bevor der Bus wieder abstürzt. ;D

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: KarlHeinz2000 am 03 April 2021, 19:26:13
Zitat von: frober am 03 April 2021, 19:14:43
Wenn ich das so sehe, müsste ich es doch auch im Sketch definieren können!?
Geht leider nicht.
Schau dir mal den benutzten RAM nach dem compile an, da sieht man es...
Irgendwie kann man in einem extra Tab precompiler Optionen definieren. Damit müsste es gehen. Ich weiß aber nicht wie :-(
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 05 April 2021, 12:57:23
Der Bus läuft stabil, solange ich von Fhem keine Befehle sende, Abläufe starte.
Läuft sogar mit nur einem Endwiderstand (120 Ohm) problemlos.

TX und RX Buffer von 256 und SOH 3 am GW hat bisher nichts gebracht.
Bei fast allen Nodes habe ich nun SOH 3 und nach jedem send/recieve ein wait(100) (Ausnahme die Node direkt am GW ist unverändert, da diese nur Sensordaten sendet und das bisher problemlos).
Auch habe ich die Starts der Nodes über ein wait am Anfang von presentation entzerrt.

Sobald mehrere Nachrichten nacheinander, trotz wait(100) gesendet werden bleibt der Bus meist hängen.
Nach einem reboot des GW läuft wieder alles.

Z.B. lasse ich meine Relais zeitgesteuert laufen. Das Setzen von percentage und danach Schalten des Relais ist ok. Nach Ablauf der Zeit sendet die Nodes "Relais off" und nach wait(100) "percentage 0" und das kommt schon nicht mehr an, der Bus hängt. Genauso schalte ich 2 Relais nacheinander über eine andere Node, Relais1 off, Relais2 on mit wait(100). Die 2. Nachricht kommt auch nicht an, Bus hängt. >:(

Beim  send des Relaisstatus ist ACK aktiviert und es wird auch der erfolgreiche Empfang kontrolliert und evt. neu gesendet (3x nach je 1s).

Davor hatte ich wait von 20 bzw. 40, kein Unterschied  :o
Wie weit kann/soll ich noch erhöhen, falls das überhaut noch eine Auswirkung hat?
Im MySensor-Forum hat einer geschrieben, dass es immer ein wait(150) setzt, allerdings war das mit Radio.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 05 April 2021, 20:32:41
Neue Erkenntnisse: das hängt sehr wahrscheinlich beim send mit der ACK-Anforderung.
Ist hier Fhem zu "langsam", zu viele Daten in kurzer Zeit?

Beim "manuellen" Bodenfeuchte messen funktioniert alles, von Anfang an, ohne Absturz.
Ich setzte aus Fhem V_LOCK_STATUS auf on, Feuchte wird gemessen, gesendet und V_LOCK_STATUS wieder auf aus gesetzt. Alles ohne ACK.

Eigentlich kommt doch nur die gleiche Nachricht mit ACK vom Empfänger (Fhem oder GW?) zurück und wird per receive empfangen. Dauert das alles so lange, dass der Bus ab und an abstürzt?

Hmm, ich wollte eigentlich sicher gehen, dass alles zuverlässig funktioniert.
Schaltet von euch jemand Relais incl. Rückmeldung (Zeitschaltung o.ä.) zuverlässig?

Nachtrag:
ACK kann nicht (nur) der Auslöser sein. Die Node mit den 2 Relais nacheinander hat kein ACK beim send und trotzdem die gleichen Probleme.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 06 April 2021, 19:08:25
Ich habe nun aktiv mal mit dem Schalten den Relais gespielt. Der Bus oder das GW ist jedes mal abgestürzt.

Logauszug:

2021.04.05 10:15:08 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59000 without FD
2021.04.05 10:15:08 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:705 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.05 12:12:05 1: RMDIR: ./restoreDir/save/2021-04-02
2021.04.05 12:14:30 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59204 without FD
2021.04.05 12:14:30 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.05 12:14:47 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59204 without FD
2021.04.05 12:14:47 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
.
.
.
2021.04.06 18:43:13 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:43:13 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:43:48 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:43:48 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:45:13 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:45:13 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:45:24 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65529 without FD
2021.04.06 18:45:24 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:46:20 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:46:20 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:46:34 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:46:34 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:46:55 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65487 without FD
2021.04.06 18:46:55 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:47:02 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65487 without FD
2021.04.06 18:47:02 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
 

Die Webaddr ist der PC oder Laptop, von dem ich gesteuert habe.
Was bedeuten die Meldungen von MySensors?

Vereinzelt finde ich auch weiter Logs:

2021.04.05 19:47:39 3: MYSENSORS: ignoring internal-msg from unknown radioId 1, childId 255 for I_DISCOVER_RESPONSE

2021.04.05 19:48:32 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MYSENSORS_DEVICE.pm line 794.


FVERSION 10_MYSENSORS_DEVICE.pm:0.237770/2021-02-20
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 06 April 2021, 21:33:02
Hmm, also der erste Teil kommt eigentlich aus FHEMWEB. Da werden gets abgesetzt, aber bis die Antworten kommen, gibt's die aufrufende FHEMWEB-Seite nicht mehr. Sieht insgesamt irgendwie verbogen aus.

Die Meldung "ignoring internal-msg from" kommt jedenfalls nur, wenn  GW und Node irgendwie nicht zusammenpassen, sei es, dass das IODev falsch ist, sei es, dass irgendwelche NodeID's erfunden würden oder sowas in die Richtung. Falls du mehrere GW's hast, kannst du ja als erstes mal checken, ob es da Überschneidungen gibt. Allen voran bei der Node 1.


Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 06 April 2021, 22:19:51
Zitat von: Beta-User am 06 April 2021, 21:33:02
Hmm, also der erste Teil kommt eigentlich aus FHEMWEB. Da werden gets abgesetzt, aber bis die Antworten kommen, gibt's die aufrufende FHEMWEB-Seite nicht mehr. Sieht insgesamt irgendwie verbogen aus.
OK, das könnte ich, mit reload der Seite, verursacht haben, wenn vom heartbeat keine Antwort kam. Werde ich nochmal überprüfen.

Zitat
Die Meldung "ignoring internal-msg from" kommt jedenfalls nur, wenn  GW und Node irgendwie nicht zusammenpassen, sei es, dass das IODev falsch ist, sei es, dass irgendwelche NodeID's erfunden würden oder sowas in die Richtung. Falls du mehrere GW's hast, kannst du ja als erstes mal checken, ob es da Überschneidungen gibt. Allen voran bei der Node 1.

Ich habe nur einen GW und den mit RS485.
NodeIDs erfunden, hmm, fehlerhafte Daten auf dem Bus?

Kann das mit den Abstürzen zutun haben und wie kann ich es am besten debuggen?
Kann ich in Fhem den Datenverkehr mit loggen?
Wobei ich wahrscheinlich besser auf dem Bus mit lese, aber wie, zw. Arduino und CAN?

Irgendwie habe ich das Gefühl, das das Aufhängen des Buses nicht von Kollisionen verursacht wird.
Das manuellen Anstoßen der Feuchtemessung dauert keine Sekunde bis alle Nachrichten da sind, ohne Absturz.
Das Schalten der Relais funktioniert fast nie ohne Hänger >:(
Am Sketch kann es eigentlich nicht hängen. Test hat funktioniert und der Bus hângt meist direkt nach dem Absetzen des Befehls aus Fhem.
In wenigen Fällen hat es aber schon funktioniert.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 07 April 2021, 09:20:34
Zitat von: frober am 06 April 2021, 22:19:51
OK, das könnte ich, mit reload der Seite, verursacht haben, wenn vom heartbeat keine Antwort kam. Werde ich nochmal überprüfen.
Klingt plausibel

ZitatIch habe nur einen GW und den mit RS485.
NodeIDs erfunden, hmm, fehlerhafte Daten auf dem Bus?
Dann sollte es zumindest kein GW-Zuordnungsproblem geben. Kaputte Daten könnte sein, aber vom Bauchgefühl her steckt da eher was anderes dahinter. Die Nodes haben alle eine manuell vergebene ID?

ZitatKann das mit den Abstürzen zutun haben
Woran machst du fest, dass der Bus "abgestürzt" ist? Nach meinem Verständnis hieße das, dass irgendwas den Bus auf "Dauer-high" zieht (>ca. 2.5V) , was aber eigentlich durch die CAN-Bausteine nie dauerhaft der Fall sein sollte. Wenn das doch passiert, stimmt m.E. irgendwas an der Verkabelung nicht und/oder mind. einer der Bausteine ist kaputt.
Falls einer der Bausteine es nicht schafft, "gute" Daten auf den Bus zu schreiben, könnte es evtl. an der Stromversorgung liegen (bin da aber nicht vertieft drin, ist eher Bauchgefühl).

Zitatund wie kann ich es am besten debuggen? [...]
Die Daten direkt auf dem Bus oder hinter dem CAN-Baustein abzugreifen, ist wenig aufschlussreich, das ist "Kauderwelsch" (soweit ich mich entsinne, hatte ich mal einen Seriell-USB-Wandler hinter einen MCP2551 geklemmt). Was aber gehen sollte, ist eine Repeater-Node mit auf den Bus zu hängen, da sollte dann alles via USB ausgegeben werden, was so an Daten über den Bus geht - ganz ähnlich wie bei Funk.

Falls du die Option hast, das GW gegen eines mit Hardware-Serial zu tauschen, würde ich das mal angehen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 07 April 2021, 09:59:14
Problem gelöst :D

Eigentlich darf ich es nicht verraten, sonst werde ich verhauen ;) (man sollte auf Beta-User hören 8))
Problem ist, wenn im Test alles funktioniert, dann denkt man im produktiven Einsatz nicht soweit...

Im GW hatte ich Relais definiert, die ich nur selten schalte. Daher dachte ich, das macht keine Probleme, da es den GW nicht belastet/blockiert.
Anscheinend kommt dieser damit aber nicht klar, wenn Relais auf den Nodes geschaltet werden. Irgendwas hängt dann.
Letzte Erkenntnis war, dass nichts "abstürzt", er reichte das USB-Kabel zum Raspi kurz abzuziehen und die Kommunikation läuft wieder. Kein reboot etc.

Da von diesen Relais nur eins in Gebrauch war, werde ich dies anders an Fhem anbinden, mal schauen...

Danke für eure Unterstützung.

Und nun "duck und weg" ;D
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 07 April 2021, 10:13:20
So ganz verstanden habe ich das Problem bzw. die Lösung noch nicht. Ich habe auch einige Relais bzw. SSR's an diversen Nodes im Einsatz... Die Versorgung dieser Nodes ist aber über die zentrale 12V-Strecke, so dass ausreichend Saft da sein sollte, um die jeweils zu schalten, ohne die Kommunikation in den Abgrund zu ziehen...

Ansonsten freut es mich ja sehr, wenn man auf mich hört, aber ich weiß (leider, zum Glück, ...) auch nicht alles :P .
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 07 April 2021, 11:50:58
@frober: Interessant. Danke für die Info.

Dass man das GW nicht zum Aktor machen soll, hatte ich zwischendrin auch mal beiläufig gelesen. Aber so drastische Wirkung hätte ich nicht erwartet. Höchstens, dass das Relais halt mitschaltet, auch wenn ein Node gemeint war.

VG
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 07 April 2021, 12:01:24
Zitat von: Beta-User am 07 April 2021, 10:13:20
So ganz verstanden habe ich das Problem bzw. die Lösung noch nicht. Ich habe auch einige Relais bzw. SSR's an diversen Nodes im Einsatz... Die Versorgung dieser Nodes ist aber über die zentrale 12V-Strecke, so dass ausreichend Saft da sein sollte, um die jeweils zu schalten, ohne die Kommunikation in den Abgrund zu ziehen...

Ansonsten freut es mich ja sehr, wenn man auf mich hört, aber ich weiß (leider, zum Glück, ...) auch nicht alles :P .

Mit der Stromversorgung hat es nichts zu tun, an den Nodes sind Photomos verbaut.

Das Problem waren die definierten Relais in der Node0 (Gateway). Da hatte ich anfangs Probleme, da diese mit den Relais der anderen  Nodes geschaltet wurden. Erst nach ändern der ChildID hat es im Test funktioniert.
Nun hatte das GW aber anscheinend Probleme damit.

Wie du schon angemahnt hattest, GW ist GW, das sollte keine weiteren Aufgaben erledigen.

Evtl. funktioniert es, wenn man receive im GW besser eingrenzt, damit nur die ChildIDs für die Node0 verarbeitet werden.
Jetzt muss es erstmal laufen, damit ich meinen Rasen säen kann....

Vielleicht probiere ich es Mal, wenn ich mehr Zeit habe...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 07 April 2021, 12:03:34
Zitat von: rob am 07 April 2021, 11:50:58
@frober: Interessant. Danke für die Info.

Dass man das GW nicht zum Aktor machen soll, hatte ich zwischendrin auch mal beiläufig gelesen. Aber so drastische Wirkung hätte ich nicht erwartet. Höchstens, dass das Relais halt mitschaltet, auch wenn ein Node gemeint war.

VG
rob

Das mit dem Mitschalten kannst du über eine noch nicht verwendete ChildID verhindern.
Wie eben schon geschrieben, hilft es vielleicht die empfangenen Nachrichten besser zu filtern.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 07 April 2021, 12:11:58
Nach den ganzen Erkenntnissen, sollte das Wiki angepasst werden.
Ich werde mich Mal anmelden und die Tage versuchen etwas einzubringen.

Wäre toll, wenn die  Grafiken auch angepasst werden könnten.
- CAN nur mit 120 Ohm am jeweiligen Ende.
- Terminierung auf 12 oder 24V nur für RS485 (MAX485 etc.)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 07 April 2021, 13:14:58
Zitat von: frober am 07 April 2021, 12:11:58
Nach den ganzen Erkenntnissen, sollte das Wiki angepasst werden.
Ich werde mich Mal anmelden und die Tage versuchen etwas einzubringen.
Gerne! Werde mich da aber erst mal zurückhalten, ich habe im Moment wohl einfach zu wenig aktuelle praktische und theoretische Kenntnisse...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 09 April 2021, 09:37:14
Zitat von: rob am 29 März 2021, 21:52:21
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...
So, Krams ist da und verbaut. Node konnte ich gestern nach div. Tests erfolgreich in Betrieb nehmen  :D Hat ja nur ein Jahr gedauert  ::) Aufbau beruht auf Empfehlungen von Ranseyer u. Beta-User. HW-serial, 24V mit Widerstandsnetzwerk, MCP-Module, Abschluss m. 120Ohm nur am Node, ferngespeist (analog letztes Bild im Wiki).
Die Node löst meinen EspEasy am Eingang ab (5 Aktoren, 6 Sensoren, Wiegand-Rfid). Läuft bis jetzt stabil u. reagiert schön flink.
Next Step ist dann die Garagensteuerung abzulösen. Mal schauen, wie lange das wieder dauert  ;D

Viele Grüße
rob

Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 09 April 2021, 10:59:30
Zitat von: rob am 09 April 2021, 09:37:14
So, Krams ist da und verbaut. Node konnte ich gestern nach div. Tests erfolgreich in Betrieb nehmen  :D Hat ja nur ein Jahr gedauert  ::) Aufbau beruht auf Empfehlungen von Ranseyer u. Beta-User. HW-serial, 24V mit Widerstandsnetzwerk, MCP-Module, Abschluss m. 120Ohm nur am Node, ferngespeist (analog letztes Bild im Wiki).
Die Node löst meinen EspEasy am Eingang ab (5 Aktoren, 6 Sensoren, Wiegand-Rfid). Läuft bis jetzt stabil u. reagiert schön flink.
Next Step ist dann die Garagensteuerung abzulösen. Mal schauen, wie lange das wieder dauert  ;D

Viele Grüße
rob

Das mag auf kurzer Distanz funktionieren.
Wichtig ist zw. CanH und CanL ~0V und H-VCC/L-GND ~2,5V

Bei mir hat das Widerstandsnetzwerk die Werte verzerrt. Ich habe NUR 120Ohm an beiden Enden.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 09 April 2021, 11:30:33
@frober:
Hast Du Erfahrungswerte sammeln können wieviel als "kurz" gilt und ab wann ungefähr mehr Aufwand nötig wird?
Aktuell habe ich ja nur eine Node mit ca. 16m Leitung. Wenn die nächste hinzukommt, würde sich die Leitungslänge schon verdoppeln. Wäre natürlich spannend eine Art "best practise" im Wiki zu haben - wie Du schon geschrieben hattest ;)

Vielen Dank und beste Grüße
rob
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 09 April 2021, 11:52:23
Zitat von: rob am 09 April 2021, 11:30:33
@frober:
Hast Du Erfahrungswerte sammeln können wieviel als "kurz" gilt und ab wann ungefähr mehr Aufwand nötig wird?
Aktuell habe ich ja nur eine Node mit ca. 16m Leitung. Wenn die nächste hinzukommt, würde sich die Leitungslänge schon verdoppeln. Wäre natürlich spannend eine Art "best practise" im Wiki zu haben - wie Du schon geschrieben hattest ;)

Vielen Dank und beste Grüße
rob

Ich habe ca. 45m. Wo die Grenze ist kann ich nicht beurteilen.
Die CAN- Receiver können im Highspeed 1Mbit/s ohne Widerstandsnetzwerk! Nur die 120Ohm sind wg. Reflektionen wichtig.
Das Kabel sollte verdrillt sein, ist bei mir nicht 'perfekt' -> Telefonkabel.

Lt. Wiki sind so bei 500kbit/s bis zu 100m, bei 125kbit/s 500m möglich.
Die Geschwindigkeit wird meines Wissens nach automatisch ausgehandelt.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 23 Oktober 2021, 19:02:37
So, mal eine Zusammenfassung von mir:

Meine Nodes laufen stabil, kein Ausfall, zuverlässige Übertragung usw.

Aufbau:
Gateway ohne Zusatzfunktion (loop() ist leer)
4 Nodes, Gesamtlänge ca. 45m


Mit dieser Konfiguration hatte ich, durch einen nachträglich eingebauten Bug 8), mehrere Datenübertragungen pro Sekunde über mehrere Tage ohne Probleme.


Bzgl. MCP2551 und High-Speed (Rs-PIN auf VCC) das betrifft auch den TJA1050 (kann nur High-Speed), das funktioniert evtl. mit vernünftig geschirmten und verdrillten Kabel (z.B. Cat7).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 12 Dezember 2021, 12:42:53
Ich habe die Diskussion bzgl. der Verwendung von CAN-Transceiver-Chips anstelle RS485-Transceivern mit Interesse verfolgt und plane das auch so zu tun. Nutzt ihr hier denn die Vorteile der entsprechenden Bauteile? Da das MySensors-Protokoll das nicht berücksichtigt wohl nicht, oder habe ich was übersehen?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 12 Dezember 2021, 16:25:16
Erst einmal Willkommen im Forum.

Welche Vorteile meinst du?
Die Fehlerverarbeitung bezgl. Störfaktoren machen die Chips selbständig.
Ein Vorteil ist die einfachere Terminierung.

Ansonsten, MySensors unterstützt die CAN-Receiver mWn nicht.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 12 Dezember 2021, 16:37:00
Wenn mit RS485-Transceivern Kollisionen auftreten, kannst du das auf Sender-Seite nicht erkennen. Bzw. nur durch Ausbleiben eines Acknowledge oder durch die Rückmeldung eines anderen Busteilnehmers. Mit CAN-Transceivern kann der Sender es selbst feststellen, indem er auf dem Rx rückliest und vergleicht. Setzt aber eben voraus, dass das in der SW so umgesetzt ist.

Welche Fehlerverarbeitung meinst du?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 12 Dezember 2021, 16:45:12
Zitat von: pikim am 12 Dezember 2021, 16:37:00

Welche Fehlerverarbeitung meinst du?

Störfaktoren auf der Leitung durch z.B. "Elektrosmog".  Bei Kollisionen bin ich mir nicht sicher, da war ich der Meinung, dass die das auch selbständig machen.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 12 Dezember 2021, 17:03:19
Hinsichtlich Störungen dürften die nicht viel besser sein als RS485-Treiber. Kollisionen behandeln sie nicht. Das macht der CAN-Controller (z.B. MCP2515 via SPI oder die im Mikrocontroller verbauten).
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Dezember 2021, 17:16:58
Hatte Probleme mit "Dauer-high"-Zuständen. Das passiert mit can-Bausteinen nicht.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 12 Dezember 2021, 18:59:30
Das dürfte durch einzelne Busteilnehmer passiert sein, die sich mit aktivem DE-Pin aufgehängt hatten, kann das sein? CAN-Transceiver verhindern das durch einen internen Timer.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Beta-User am 12 Dezember 2021, 19:12:42
...ebend. Genau darum ging es ursprünglich mal...
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 12 Dezember 2021, 19:47:44
Genau. Und ein anderer großer Vorteil ist, dass Kollisionen erkannt werden können, indem ständig das Gesendete mit dem Empfangenen verglichen wird. Bei richtigem CAN passiert das Bit für Bit - das geht mit UART leider nicht.

Meiner Meinung nach sollte die Kollisionerkennung aber funktionieren wenn jeder Teilnehmer, der etwas senden will, als erstes seine ID/Adresse sendet und gleichzeitig empfängt. Hat er genau das empfangen was er gesendet hat, dann ist der Bus frei und er kann die eigentlichen Daten senden. Hat er etwas anderes empfangen, dann hat gleichzeitig ein anderer Teilnehmer begonnen zu senden. Über die ID findet damit auch eine Priorisierung statt: je niedriger die ID, desto höher die Priorität des Teilnehmers. Die ID darf logischerweise nicht 2x vergeben werden.

Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: frober am 13 Dezember 2021, 19:13:00
Zitat von: pikim am 12 Dezember 2021, 19:47:44
Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?
Von meiner Seite habe ich im Moment keinen Bedarf und gerade andere Projekte am laufen.
Wie es zukünftig ausschaut, man weiß ja nie. ;)

Bezgl. Protokoll, das betrifft doch eher MySensors direkt und müsste dann im Kontroller (Node/GW) verarbeitet werden und weniger auf der Fhemseite.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: pikim am 13 Dezember 2021, 19:37:02
Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 17 Dezember 2021, 08:48:26
Zitat von: pikim am 13 Dezember 2021, 19:37:02
Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.


Das ist doch eine gute Sache!


(Warum mir der Ist-Stand gut genug war ? -mySensors war ja ursprünglich ein reines Funk Protokoll. Und beim Funken sind Kollisionen vollkommen normal und werden vom Protokoll ausgeregelt...)
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 17 Dezember 2021, 09:02:22
@Ranseyer: Das Thema "aktive Terminierung" würde mich auch noch reizen. Hättest Du Muße das doch noch anzugehen? Oder macht das keinen Sinn mehr?
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: Ranseyer am 04 Mai 2022, 18:24:37
Hi Rob, im Moment eher nicht...
Hast du hier krass starken Bedarf, oder warum fragst du ?
(Die Geschichte ist ja immer ein Kompromiss, und wenn es stabil läuft würde ich nichts ändern. Manchmal sind Sachen nach Verbesserung schlechter bis kaputt :-) )


Aber hier gibt es überigens zum geliebten Bus einen Sehr umfassenden und verständlichen Artikel: https://hackaday.com/2022/04/05/hacker-dictionary-rs-485-will-go-the-distance/
Titel: Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
Beitrag von: rob am 06 Mai 2022, 22:18:44
Kein starker Bedarf, eher eine Mischung aus Neugier und dem Bedürfnis es von vornherein "richtig" machen zu wollen. Basst scho :)
Aktuell habe ich das Widerstandsnetzwerk im Einsatz, ohne Einschränkungen/ Ausfälle. Ich frage, weil ich Irgendwann deutlich verlängern muss. Sollte es dann zu Problemen kommen, kann ich u.a. auf frobers Erfahrungsberichte hier zurückgreifen.
Ich hätte gemeint ein aktiver Abschluss wäre das Optimum. Danke für die Klarstellung :)

VG
rob