In meinem Hausbusprojekt hat sich Modbus als Suboptimal herausgestellt. Die verdrahtung Aufwändig, Spannungsversorgung zusätzlich nötig... Ich möchte jetzt eine bessere lösung finden. Die eierlegende Busmilchsau würde folgende Kriterien für mich erfüllen: - Bidirektional - 2-50 Teilnehmer - Transceiver nicht zu teuer - Versorgung über datenleitung, sagen wir mal 5W - kurze reaktionszeiten, max 100ms - mittlere datenrate, ca. 10kbps - möglichst freizügige topologieauswahl - mittlere reichweite, 50m leitungslänge - elektrisch robust gegen einstrahlungen und kurzschluss - automatische adressierung Ich vermute all das gibt es nicht. Bisher dachte ich über verschiedene systeme nach: CAN + Kollisionsauflösung - Verdrahtung (4-Adern inkl spannungsversorgung, abschluss, topologie) Funk auch das will ich nicht ausschließen. + Leitungen dann nur für dezentrale DC-Spannungsversorgung nötig - Transceiverchip - reichweite, zuverlässigkeit KNX ich finde das selfbusprojekt recht interessant + bewährt in der Haustechnik + einfache verdrahtung + versorgung auf der datenleitung (jedoch recht hohe spannung) + offenes Projekt zum nachbauen vorhanden - Seltsame konfigurationstechnik - standart nicht offen (dokumente habe ich jedoch) AS-Interface + bewährte industrietechnik + 24V auf dem bus + einfache verdrahtung + einfache adressierung - beschränkt auf rechtwenige teilnehmer -standart nicht offen NMRA-DCC Kenne ich von früher aus der modellbahn + einfachster transmitter + receiver + simples protokoll + richtig leistung auf dem bus ( 200W) - logisch für andere anwendung konzipiert - bidirektionalität nur schlechte krücke - EMV- katastrophe Dann dachte ich noch über eine neue lösung nach. Irgendwas zwischen 10base2 und 802.3af, eventuell direkt mit Ethernetübertragertrafos, jedoch etwas langsamer. Oder sehr niederfrequente töne, richtig über schwingkreise und trafos ein- und auskoppeln. Was würdet ihr bevorzugen oder hat jemand einen weiteren Vorschlag?
Powerline Ethernet?
Gast
#5733092
Klingt nach LIN Bus bis auf die 5W, die sind utopisch.
Hallo. Ich stand vor dem gleichen Problem wie du (habe meine Bachelor Arbeit darüber geschrieben) und bin bei CAN oder genauer gesagt bei CANopen hängen geblieben, da die beiden zusätzlichen Adern nicht wirklich ein Problem nd. Man hat dadurch die Möglichkeit, die Versorgungen nach Verteilerbereiche aufzuteilen und das funktioniert sehr gut. Bei größeren Verbrauchern versorge ich per Bus nur den Transceiver, die restliche Elektronik wird extra Versorgt. Bei 20kBit/s ist auch die Topologie nicht wirklich ausschlaggebend, da kann man auch mal wo abzweigen. Ein paar Infos zu den Geräten findest du hier: http://www.kreuzers.home.dic.at/elektronik/E_CANopen.php Christian_RX7
Gast
#5733217
Christian K. schrieb: > da die beiden zusätzlichen Adern nicht wirklich ein > Problem nd Entweder man verlegt ein Kabel oder nicht, wenn ja, spielt es doch keine Rolle, ob da 2, 3 oder 4 Drähte drin sind. Ausser in den ganz wenigen Fällen, wo so ein Kabel schon liegt und verwendet werden muss - aber selbst ein uraltes Telefonkabel hat 4 Adern. Georg
georg schrieb: > Entweder man verlegt ein Kabel oder nicht, Gbt es eigentlich Hausbussysteme, bei der die Daten allein über die normale 230V-Netzleitung geschickt werden, also ohne zusätzliche Kabel?
Gibt es, oder besser gab es: KNX Powerline Geräte dafür hat aber meines Wissens nur noch ABB / Busch Jäger im Programm. Inbetriebnahme ist eine Katastrophe, selbst im Vergleich zu KNX TP. Christian_RX7
Harald W. schrieb: > Gbt es eigentlich Hausbussysteme, bei der die Daten allein über die > normale 230V-Netzleitung geschickt werden, also ohne zusätzliche Kabel? Die wären ähnlich aufwändig wie "richtiges" Power LAN - denn man braucht relativ große und teure Netzfilter Komponenten.
Flip B. schrieb: > CAN > + Kollisionsauflösung > - Verdrahtung (4-Adern inkl spannungsversorgung, abschluss, topologie) georg schrieb: > Entweder man verlegt ein Kabel oder nicht, wenn ja, spielt es doch keine > Rolle, ob da 2, 3 oder 4 Drähte drin sind. LOL. Stimme ich voll zu. Wo ist da ein Problem, ob 4 oder sogar 6 Drähte als Reserve für ev. zukünftige Erweiterungen oder Umstieg auf ein anderes Protokoll ?
Ich formuliere das mal anders: Auf dem zusätzlichen Spannungsversorgungspaar fällt etwas spannung ab. Jetzt habe ich schon CAT5 mit 2x4 leitern liegen, allerdings in recht hochohmiger aluausführung. Durch die verschobene Masse auch schon bei kleineren strömen, musste ich die transceiver jeweils galvanisch trennen und über ein weiteres päärchen versorgen. Beim 2-draht-bus macht das alles nichts aus, nur die betriebsspannung wird geringer, denn die daten werden sowieso ac-gekoppelt. Ein 2-drahtbus könnte mehrere leiter paralell verwenden für niedrigeren spannungsfall.
Gast
#5733477
Harald W. schrieb: > Gbt es eigentlich Hausbussysteme, bei der die Daten allein über die > normale 230V-Netzleitung geschickt werden, also ohne zusätzliche Kabel? Schau dir mal DigitalStrom an ... https://www.digitalstrom.ch/
Flip B. schrieb: > Durch die verschobene Masse auch schon bei > kleineren strömen, musste ich die transceiver jeweils galvanisch trennen > und über ein weiteres päärchen versorgen. Nö. Schau Dir mal obigen Ausschnitt aus dem PCA82C251 Datenblatt an. D.h. der Receiver arbeitet von CANL = -7V bis CANH = 12V. Ein Ground-Shift von +/-5V ist also völlig problemlos.
Angehängte Dateien:
-
CAN_Voltage.png
(12 KB)
C.F. schrieb: > Harald W. schrieb: >> Gbt es eigentlich Hausbussysteme, bei der die Daten allein über die >> normale 230V-Netzleitung geschickt werden, also ohne zusätzliche Kabel? > > Schau dir mal DigitalStrom an ... > > https://www.digitalstrom.ch/ ...habe vor einigen Jahren das Haus meiner Tochter mit LCN installiert: Bus ist eine zusätzliche Leitung in der Standard-230VAC Verkabelung (statt 3x1,5² 4x1,5²) https://www.lcn.eu/newsletter/2019/01/newsletter_01_2019.html Gruß Horst
Modbus RTU?
Gast
#5733729
Peter D. schrieb: > Flip B. schrieb: >> Durch die verschobene Masse auch schon bei >> kleineren strömen, musste ich die transceiver jeweils galvanisch trennen >> und über ein weiteres päärchen versorgen. > > Nö. > Schau Dir mal obigen Ausschnitt aus dem PCA82C251 Datenblatt an. > D.h. der Receiver arbeitet von CANL = -7V bis CANH = 12V. > Ein Ground-Shift von +/-5V ist also völlig problemlos. Das Problem verstehe ich jetzt nicht. Für die Spannungsversorgung muss doch je eine Ader für z.B. 12V oder 24V und eine für GND verwendet werden. Bei höheren Strömen ggf. je zwei Adern. Zusätzlich könnte man noch den eventuell vorhandenen Schirm als zusätzliche Masse verwenden. Somit hat man ein ausreichendes Bezugspotential für den CAN-Bus und keine / minimale Masseverschiebung.
Gast
#5734638
Ich trage mich auch mit diesem Gedanken und tendiere zum CAN-Bus.
Gast
#5734650
Flip B. schrieb: > Auf dem zusätzlichen Spannungsversorgungspaar fällt etwas spannung ab. > Jetzt habe ich schon CAT5 mit 2x4 leitern liegen, allerdings in recht > hochohmiger aluausführung. Den Spannungsabfall auf der Versorgungsleitung kannst du deutlich reduzieren, indem du mit hoher Spannung auf der Leitung arbeitest. DC/DC-Wandler zum Runtersetzen beim Verbraucher gibt es für ein paar Cent.
Jens schrieb: > Das Problem verstehe ich jetzt nicht. Das soll bedeuten, man braucht erst dann eine galvanische Trennung des Transceivers, wenn der Abfall auf der GND-Leitung >7V beträgt.
Ich arbeite schon mit 24 bzw 48v, doch ohne trennung liegen im einschaltmoment bis alle kapazitäten geladen sind fast 1/2 spannung an gnd an. Das killte gelegentlich die transceiver trotz schutzschaltung.
Flip B. schrieb: > Ich arbeite schon mit 24 bzw 48v, doch ohne trennung liegen im > einschaltmoment bis alle kapazitäten geladen sind fast 1/2 spannung an > gnd an. Wenn Du keine speziellen Stecker mit voreilenden Powerpins hast, können die 48V beim Stecken anliegen, der PCA80C251 verträgt aber nur 36V. Mit 24V hab ich aber noch keinen PCA80C251 gekillt (DB9 Stecker).
Gast
#5734898
Hallo, als drahtgebundenen Bus würde ich immer RS485 empfehlen. Die Zeichen der Zeit stehen aber ganz klar auf WLAN (ESP8266, MQTT, NodeRed, ...) Damit sparst Du Dir auf jeden Fall Kabel und es gibt ne Menge günstiger Geräte (Sonoff, usw) und vieles (nicht alles) ist fertig ohne viel gefrickel nutzbar. Gruß Ralf
Mir fällt da noch OneWire ein. Der erfüllt -so weit ich sehe- die Anforderungen und wird m.W. auch in der Gebäudetechnik verwendet. Die Chips kann man kaufen oder auch per Mikrocontroller emulieren. Außer dem engen ACK-Timing kein Problem, Doku und Applikationen gibt es im Netz reichlich.
Gast
#5734956
Flip B. schrieb: > NMRA-DCC > Kenne ich von früher aus der modellbahn > > + einfachster transmitter + receiver > + simples protokoll > + richtig leistung auf dem bus ( 200W) > - logisch für andere anwendung konzipiert > - bidirektionalität nur schlechte krücke > - EMV- katastrophe Inzwischen gibt es DCC mit RailCom+, damit bleibt nur der Nachteil EMV-Katastrophe. Trotzdem würde ich auch eher W-Lan oder PoE oder PowerLAN empfehlen, das dürfte am wenigsten kompliziert sein. Weitere Vorteile: - Darüber kommst du auch mit dem Notebook ins Internet, was bei RailCom wohl eher unwahrscheinlich ist. - Mehr als 16.384 Notebook-User können gleichzeitig ins Internet. - Du brauchst dir keinen Verdrahtungsstandard auszudenken, nimm einfach RJ45 und so.
ich schätze IP-Networking ist zu leistungshungrig für einige einfache geräte. viele sind nur taster oder einzelne pwm-ausgänge.
Um Signale auf die 230V aufzumodulieren gibt es seit Jahrzehnten schon fertige IC-Bausteine, weiß nicht mehr ab die von Philips waren. Es gibt doch diese Bücherreihe mit glaub 10 Bänden wo nur Schaltungen aufgeführt sind, dart habe ich so einen Baustein mal beschrieben gesehen. Ich empfehle dir EIB/KNX Kabel (2 Leitungen für Daten und 2 für die Versorgung) das darf durch seine Isolierstärke und Festigkeit zusammen mit der 230V Leitung verlegt werden. Also kann da schonmal keine Versicherung meckern und weiterhin würde ich mit einer https://de.wikipedia.org/wiki/Kleinspannung#Sicherheitskleinspannung arbeiten, wenn du dann etwas schalten willst mit Optokopplern, Optotriacs, Relais usw. arbeiten, die 230V sind ja nicht weit weg.
Die PLC Chips sind von der idee schön, ich möchte nur aus energiespargedanken nicht so viele netzteile laufen haben, lieber ein zentrales, solarunterstützt. Zusätzlich kommt da preis und verfügbarkeit etwas schlecht. Ich mache mich mal an Freebus/selfbus oder funk.
Flip B. schrieb: > solarunterstützt Pack halt ein Panel mehr aufs Dach, dann musst du nicht um jedes mA kämpfen.
Gast
#5735805
Ich habe bei einem ähnlichen Projekt auf CAN gesetzt. Flip B. schrieb: > - Verdrahtung (4-Adern inkl spannungsversorgung, abschluss, topologie) Spannungsversorgung: Für fast jeden Bus brauchst du separate Spannungsversorgung(en). Ob du jetzt 2,3 oder 4 Leitungen ziehst ist IMHO völlig egal. Abschluss: 2*120 Ohm kosten nicht die Welt :P Topologie: CAN ist zwar für Linientopologie ausgelegt. Aber dir reichen ja schon 10 kb/s. Dann können auch Stichleitungen relativ lang werden. Mache den Abschluss einfach an die zwei maximal weit entfernten Knoten. Ein plus für CAN ist ganz klar die billige Umsetzung. Die Transceiver kosten quasi nichts, sind bewährt und robust. Controller gibt es entweder extern, oder man nimmt einen uC mit CAN. Eigentlich hat jede uC-Familie (AVR, PIC, STM32Fxxx, PIC32, usw.) mindestens einen Chip, der auch CAN kann. Die Spannungsversorgung habe ich so realisiert, dass die Knoten alle einen Schaltregler haben, mit weiter Eingangsspannung. Ich fahre 24V. Da sind dann die Ströme gering genug, dass über die Leitung nicht alles verloren geht und ich kann noch einige Aktoren steuern. Für den Standby der Knoten ist noch ein Linearregler drauf, der die Schaltung im idle mit Strom versorgt. In diesem Zustand ziehen die Knoten sehr wenig Strom (<<1 mA) und es braucht weniger Energie einen Linearregler zu nehmen als den Buck-Wandler laufen zu lassen. Im Idle werden nur die CAN Transceiver versorgt, damit die keinen Mist auf dem Bus machen, und der uC im Sleep Modus. Sollte eine CAN-Message ankommen, wird auf Schaltregler umgeschaltet und die Aufgabe erledigt. Nach einer Pause von 10 Sekunden ohne CAN-Kommunikation gehen alle wieder in den Sleep.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.