Autor Thema: RS485: Busauslegung und alternativ: CAN-Treiber-Chips?  (Gelesen 10145 mal)

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 132
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #60 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)

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #61 am: 02 März 2018, 16:33:19 »
@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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 132
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #62 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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #63 am: 02 März 2018, 17:04:24 »
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)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 132
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #64 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);
}
« Letzte Änderung: 02 März 2018, 22:01:31 von KarlHeinz2000 »

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #65 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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Brasletti

  • Full Member
  • ***
  • Beiträge: 210
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #66 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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #67 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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1548
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #68 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 !

Darüber habe ich entdeckt:
https://www.pcdimmer.de/images/stories/Schematics/old/pcdimmerdmx512splitter.png oder 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
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!

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 132
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #69 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


Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #70 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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1548
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #71 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.
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!

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 7961
  • eigentlich eher user wie "developer"
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #72 am: 23 April 2018, 17:46:31 »
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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1548
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #73 am: 23 April 2018, 18:16:12 »
Zitat
Nutzt 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...
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!

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1548
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #74 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)



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

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!

 

decade-submarginal