Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

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

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

Vorheriges Thema - Nächstes Thema

Brasletti

Mach mal nen Screenshot vom Rechner, kann das grad nicht nachvollziehen :)

Ranseyer

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

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Ω)

Beta-User

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
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

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)

Beta-User

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

Was für Sensoren hast du da nochmal im Einsatz auf den vier Nodes?

Beta-User

#37
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 ::) .
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

Beta-User

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


Beta-User

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

Beta-User

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

Ranseyer

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

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!

Beta-User

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