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

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

Vorheriges Thema - Nächstes Thema

Beta-User

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

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

#1
@ 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.

Ranseyer

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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Brasletti

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.

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

#5
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!

Ranseyer

>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
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

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)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Brasletti

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.

Brasletti

@beta-user:
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.

Beta-User

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 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 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!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

#11
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 unter 12 Fail-Safe Biasing)

Hier nochwas zum Kondensator in Serie https://www.mikrocontroller.net/articles/Wellenwiderstand#AC-Terminierung

Brasletti

@ Beta-User: ich hab nochmal das Bild korrigiert ;)

Beta-User

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 ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Brasletti

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

Auf Seite 8 ist ein schönes Diagramm!