uC und geeigneter Bus

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Hallo zusammen,

ich habe kFC%rzlich einen Thread bzgl. uC und RollE4%densteuerung
eingestellt.
Ihr habt mich FC%berzeugt, das ganze mit einem Bussystem zu erledigen.

Nochmal kurz die Ausgangsituation:
Ich habe in einem Neubau 10 Zimmer mit el. RolllE4%den. In jedem Zimmer
sind 1, 2 oder max. 3 RollE4%den. In jedem Zimmer existiert eine Dose, in=

die:
1. von jedem Rollokasten ein Rohr,
2. von der Schalterbatterie (neben der TFC%r) ein Rohr,
3. und von einem Sternpunkt im Keller ein Rohr
hineingeht.
Am Sternpunkt im Keller soll eine Steuerung mit uC aufgebaut werden, die
die Tastersignale auswertet und die RollE4%den ansteuert.

Ich habe also von jedem Raum eine Rohrverbindung zum Sternpunkt im
Keller.
Ich mF6%chte vom Sternpunkt aus zu jeder Dose (1x pro Raum) je eine
Busleitung legen. Und in der Dose einen Slave aufbauen. =


Die LE4%nge des Busses ist max. 30m. Welcher Bus wE4%re dafFC%r am besten=

geeignet?
Er soll einfach sein und auch gut diagnostizierbar. =


Vielen Dank fFC%r euer Tips!

MfG
JFC%rgen

Re: uC und geeigneter Bus


JFC%rgen Leeb schrieb:
Quoted text here. Click to load it

Hallo,

ich wFC%rde fFC%r sowas RS485 verwenden, serielle DC%bertragung und ein M=
aster20%
-Slave Protokoll wie z.B. Modbus. Da dFC%rfen Slaves aber nur nach20%
Aufforderung durch den Master senden, es mFC%ssen also alle Slaves vom20%
Master zyklisch abgefragt werden um die Tastersignale zu erfassen.
Aber bei einem Master und 10 Slaves sollte das kein Problem sein, auch20%
bei 30 Slaves nicht.
Asynchrone DC%bertragung mit 100 kBaud FC%ber 30 m ist mit RS485 kein Pro=
blem.
Einen Bus mit Kollisionserkennung und -auflF6%sung sollte hier nicht nF6%
tig20%
sein, so spart man sich einiges an Hard- und Softwareaufwand.

Bye


Re: uC und geeigneter Bus
Dankeschoen fFC%r Deine Antwort!

 =

Quoted text here. Click to load it
An sowas habe ich auch gedacht. Nur das Modbusprotokoll kenne ich nicht.

Re: uC und geeigneter Bus
Quoted text here. Click to load it

Ja, aber das Polling würde doch schon recht viel Energie vergeuden. Wenn
alle Systeme von einem zentralen Punkt versorgt werden sollen, dann
sollte man darauf achten, diesen Punkt nicht übermäßig zu belasten. Also
schickt man die Controller schlafen, so lange nix passiert. Die Taster
für die Rolläden können ja auf Interruptleitungen liegen, oder über I2C
und einen PCF8274 angeschlossen werden, der bei jedeer Änderung eines
Einganngs den Controller weckt.

Dazu kommt, dass man ohnehin ein Mehrbyte-Protokoll verwenden sollte, um
das ganze Programmiererisch einfach zu halten, auf Bit-Schiebereien zu
verzichten und die spätere Erweiterung zu ermöglichen. Also sende ich
Schalter-Nr., Funktion, CRC.
Damit kann man zwei Wege gehen:
1. Es gibt einen zentralen Controller, der die Wünsche der Schalter in
Funktionen beim Ziel ( Rolladen, Lampe) übersetzt, also die Zuordnung
übernimmt.
2. Es gibt keinen Controller und alle Aktoren ( Rolläden und Lampen)
hören auf das Netz und fischen die für sie relevanten Daten raus. Damit
muss aber jeder Aktor separat einem oder mehreren Schaltern zugeordnet
werden.

Im Normalfall würde der Schalter also sein 3-Byte Protokoll senden und
auf eine Bestätigung warten. Kommt diese nicht, so wartet er eine
'zufällige' Zeit und sendet die Aufforderung nocheinmal. Wenn auch beim
dritten Senden keine Antwort kommt, dann ist er halt beleidigt und tut nix.

Im Fall, dass es keine Kollision gibt würde in 1. der zentrale
Controller, in 2. der angesprochene Aktor eine Bestätigung senden und
der Schalter weiß, das alles gut ist.

Quoted text here. Click to load it
Ich denke, es gibt ohne einfache Kollisionserkennung per CRC mehr Ärger
als Kopfzerbrechen für die Programmierung eines einfachen CRC.
Schalter-Code + Funktions-Code = CRC.

Gruß,

Ulrich


Re: uC und geeigneter Bus

Quoted text here. Click to load it

Gut diagnostizierbar ist das normale serielle Protokoll, wie es auch
für RS232 verwendet wird (8N1).

Es hängt ein wenig davon ab, wie viele Adern Dein Kabel hat, dass Du
einziehen willst und ob Du eine zentrale Stromversorgung Deiner
Elektronik (vom Sternpunkt) aus willst oder jeweils einen kleinen
Trafo setzen möchtest. Sicher möchtest Du noch mit den Schaltern die
Rolllädem steuern, wenn Deine Elektronik mal ausfällt. Das ganze ist
also nicht mal ebend am Wochenende zu machen.


Als Bussystem würde ich RS485 vorschlagen. Am Sternpunkt einfach über
Open-Collector zusammen schalten und an den Prozessor (als
Punkt<->Punkt Verbindung). Das läßt sich mit einem Laptop und einem
RS485->RS232 Wandler gut debuggen.

Abhängig wie viele Adern Du nun hast ist halb- oder vollduplex
möglich. Wenn nur 4 Adern zur Verfügung (Telefonkabel), die Versorgung
vom Sternpunkt kommt und man sich die lästige Umschaltung bei RS485
sparen will, kann man auch CAN-Treiber verwenden ( PCA 82C251T mein
Favorit).

Tschö
  Dirk

Re: uC und geeigneter Bus
DankeschF6%n fFC%r Deine Antwort!

Quoted text here. Click to load it

RS232 wE4%re mir ganz recht. Aber gibts da keine Probleme mit der LE4%nge=
?


Quoted text here. Click to load it
Eine Zentrale Stromversorgung wE4%re mir am liebsten. So spart man sich
die Verlustleistung bei jedem Trafo. Am Sternpunkt wFC%rde ich ein etwas
grF6%DFeres Schaltnetzteil aufbauen.


Quoted text here. Click to load it
Irgend ein Sicherheitskonzept stelle ich mir schon vor. Z.B. das man das
Relais in der Dose  FC%berbrFC%cken kann.


Quoted text here. Click to load it
Welche Umschaltung? Ich bin mit RS485 nicht so vertraut.

Re: uC und geeigneter Bus

JFC%rgen Leeb schrieb:
Quoted text here. Click to load it

Hallo,

wenn man nicht die V24 Treiber fFC%r +- 12 V, sondern die differentiellen=
20%
Treiber und EmpfE4%nger fFC%r RS485 benutzt nicht, da sind auch 100 m20%
mF6%glich, ja sogar auch 1000 m.
Quoted text here. Click to load it


Die Aktivierung des Treibers. Es sind ja etliche Treiber zusammen am20%
gleichen Bus, aber immer nur einer darf senden, alle anderen mFC%ssen im =

hochohmigen Zustand sein.

Bye


Re: uC und geeigneter Bus

Quoted text here. Click to load it

Du mußt unterscheiden zwischen physikalischem Layer (RS232 /RS485 /
RS422 / CAN usw) und dem Prozokoll. Den physikalischem Layer kann man
mit einfachen Chips (MAX232 usw) umsetzen,  das Protokoll würde ich
bei allen gleich lassen, weil für deren Umsetzung braucht's wieder
einen programmierten Controller.

Quoted text here. Click to load it

Du hast natürlich auch Leitungsverluste bei den dünnen Kabel. Ein
dickes 5 Volt Netzteil im Sternpunkt und dann 100m weiter ein paar
Relais schalten, das wird nix. Du solltest in den Sternpunkt ein 24V
Netzteil setzen und an den Endpunkten einen kleinen Schaltregler. Als
Endpunkt reicht ein PIC12C508. 2 Pins für serielle Übertragung, 2 Pins
für hoch/runter (Solid-State-Relais  SSR). mit den Tastern am
Rollladen kannst Du den die SSRs überbrücken (Veriegelung beachten).

Wenn ich nochmal genau darüber nachdenke und Du nicht zu anspruchsvoll
bist, dann kannst Du den Rückkanal eigendlich weglassen.

Wenn Du nur sicherstellen willst, das Deine Rollläden zu einer
bestimmten Zeit hoch/runter fahren, dann reicht es eigendlich auch,
wenn Du die SSRs bei den Rollläden plazierst und die darin enthaltenen
Optokoppler  von Sternpunkt über eine Stromschleife ansteuerst. Das
würde das Ganze enorm vereinfachen. Rückmeldung wäre unter Umständen
auch mäglich.


Bei einem 4 adrigem Kabel könnte man 2 Adern verwenden um die SSRs
anzusteuern (antiparallel). Die restlichen 2 Adern könnten die
Rückmeldung der Taster am Rolladen (Optokoppler [LED am Netz ohne
Trafo...]) sein (antiparallel mit Wechselsrom).

Dann brauchst Du an den Endpunkten keine Controller und auch kein
Protokoll/Netzwerk.

Quoted text here. Click to load it

Veriegelung beachten!
Quoted text here. Click to load it


RS485 auf 2 Leitungen braucht eine Richtungsumschaltung - CAN nicht.

Tschö
   Dirk

Re: uC und geeigneter Bus
  > Welche Umschaltung? Ich bin mit RS485 nicht so vertraut.

Fuer dich genuegt z.B. der Baustein LTC 485 CN8. Im Daten-
blatt steht alles drin. Du musst halt ansonsten nur jedem
deiner Slaves eine Adresse zuordnen. Ansonsten hat Uwe
alles notwendige gesagt.
Die 8051er haben sogar standardmaessig einen besonderen
Modus fuer solche Faelle. Aber eine eigene Software
(Adressenueberpruefung durch die Slaves) tut es auch.

Mit Gruss
Joachim Riehn

Re: uC und geeigneter Bus
Quoted text here. Click to load it
Es gibt für Gebäude "handelsübliche" Bussysteme.
International LON von Echelon. Hierzulande stärker EIB von Siemens.
Beide haben den Nachteil teuer zu sein und entsprechende Einarbeitung
zu erfordern.
Wenn man aber langfrsitig in dem Bereich rumtut kann es sinnvoll sein
sich mit sowas anzufreunden.

MfG  JRD

Re: uC und geeigneter Bus

Quoted text here. Click to load it

Das ist das Problem. Das Protokoll von EIB ist simpel und jederzeit in
eigene Microcontroller Projekte zu implementieren. Aber die
Schnittstrellenumsetzung ist aufwändig und wenn es klein sein soll, dann
muß man auf die Bausteine von Siemens zurückgreifen. Und die sind recht
teuer. IIch weiß nichteinmal, ob man die überhaupt einzeln bekommt.

Interessante wäre zudem zu erfahren, ob es auch kostengünstig eine
einfache oder fertige Möglichkeit gibt, die Daten via 230V zu
übertragen. Die in den mir bekannten Unterlagen über EIB-Systeme
verwendeten Modulatoren sind immer die von Siemens. Gibt es da keine
preiswertere Alternative?

Das Protokoll wird bei Siemens mit einer einem MCS51er vorgeschalteten
Hardware verbastelt. Nach ersten Einschätzungen sollte es aber durch
einen AVR komplett emulierbar sein. Daher wäre nur noch der
Modulator-Teil zu lösen.

Bitte versteht es nicht wieder falsch. Preiswert heißt, durch ein
Hobby-Buidget finanzierbar. Wenn es aufs Geld nicht ankäme, würde ich
mein Haus komplett in EIB von der Stange ausrüsten.

Quoted text here. Click to load it
Es schadet generell nicht verschiedene Quellen und Informationen zu
einem Thema zu sammeln. Schließlich muss das Rad ja nicht jedesmal neu
erfunden werden. Es ist also nie verkehrt aus dem zu lernen, was andere
schon ausgetüftelt haben und sich dann aufs eigentliche Problem zu
konzentrieren.

Gruß,

Ulrich


Re: uC und geeigneter Bus
Quoted text here. Click to load it
Anfangs gabs Controller ( 68HC11 ) plus Anschaltung auf Leiterplatte
von Siemens/Regensburg bei Distributor Eurodis/Enatechnik.
Rohe Baugruppen scheinen aber bei EIB nie gängig geworden zu sein.

Quoted text here. Click to load it
Eine der kleineren EIB-Firmen ( Busch-Jäger ? ) hat da mal
rumentwickelt. Allerdings dürfte Powerline für LON gängiger sein.
Dort kann man die Anschaltung dafür als Modul beziehen.
  Jedoch: alle kleben hierzulande wohl zwangsweise an der hiesigen
unsicheren Schmalband-FSK Spec ( vgl. passende ICs von ST ) die
per Norm verordnet wird.
Wenn man die 220V isoliert hat, also nicht z.B. auf Steckdosen
führt, würde das aber funktionieren.
  Powerline für LON im Ausland verwendet spread spectrum und ist
damit robuster. FSK haben sie vorher auch ausprobiert und wieder
aufgegeben.

MfG JRD

Re: uC und geeigneter Bus


Quoted text here. Click to load it

Es gibt über Eurodis/Enatech auch eine sogenannten TP-UART IC der die
umsetzung von TTL Pegel auf den zweidraht EIB-Bus macht. Ein bisschen
drumherum braucht man auch noch. Die bekommt man IMHO auch einzeln.

--
Andreas Hezel
__________________________________________________________
We've slightly trimmed the long signature. Click to see the full one.
Re: uC und geeigneter Bus

Quoted text here. Click to load it
Das ist mir klar!

 =

Quoted text here. Click to load it
Es sollte nur der Master (Sternpunkt) mit den Slaves kommunizieren.
Die Slaves untereinander nicht.


Quoted text here. Click to load it
Warum wE4%re ein Stern verboten, wenn auch die Slaves untereinander
kommunizieren muessten?

Re: uC und geeigneter Bus


JFC%rgen Leeb schrieb:

Quoted text here. Click to load it

Hallo,

der Stern ist deshalb verboten weil RS485 mit20%
LeitungsabschlusswiderstE4%nden an jedem Ende der Leitung betrieben werde=
n20%
soll, aber mehr als zwei AbschlusswiderstE4%nde sind eine zu hohe20%
Belastung. Ausserdem gE4%be es beim Stern WellenwiderstandssprFC%nge im20%
Zentrum des Sterns.

Bye


Re: uC und geeigneter Bus
Also,

ich würde auf einen "richtigen" Bus verzichten, da ja nur 3 Zustände
übertragen werden müssen:

Rauf/Runter/Halt

Die Steuerung im Raum müsste dann, die Tastendrücke auswerten und die
Signale vom Zentralpunkt. Zu übertragen zum Zentralpunkt wären:

Hin: alles Rauf/Runter
Zurück: alles Rauf Runter

Denke, dass sich die paar Bits auch so einfach auf 2 Adern
übertragen lassen(ein Takt, ein Signal), schnell muss das Ganze ja nicht
sein.

In der Zentral bräuchte mann dann nur einen Kontroller mit 10 I/Os, einen
für jeden Raum.

Henning




Re: uC und geeigneter Bus

Quoted text here. Click to load it

Hallo!

Quoted text here. Click to load it

Ich habe vor, sowas auch zu machen, allerdings geht's bei mir um eine
Altbausanierung. Die Verkabelung wurde schon gemacht, 5-adrige
230V-Leitung, gemischter Bus-Stern. Das sind meine Rahmenbedingungen.

Ich werd' in der ersten Stufe (weil's schnell gehen muß) nur eine zentrale
AUF/ZU-Steuerung vorsehen. Dazu nehme ich die 2 freien Adern und schalte 2
Relais mit Dioden antiparallel.

In einer 2. Stufe hab' ich mir dann einen AVR vorgestellt, der Zeitabhängig
die Rollos auf/zumachen kann, aber nur alle zugleich.

In der endgültigen Ausbaustufe soll dann jedes Fenster getrennt angesteuert
werden können. Nach einigen Recherchen hab' ich mich für die 1-Wire Linie
von Dallas entschieden (besonders das Teil mit 8bit IO). Die haben einen
riesigen Vorteil: man bekommt gratis Samples. Mit SW aus dem Netz hab' ich
innerhalb eines Tages die Abfrage von den DS18S20 hinbekommen, die ich auch
gleich mitbestellt habe. Das habe ich dann an einem 50m-Bund des verbauten
Kabels probiert, funktioniert einwandfrei. Ohne Tricks, bei Dallas gäb's
auch einen speziellen Treiberbaustein, den man an eine RS232-Schnittstelle
bauen kann, der sollte auch schwierigere Situationen verkraften.

Ich würde vorschlagen, wir tun uns zusammen und versuchen nicht, jeder für
sich das Rad zu entwickeln.

Grüße,
Christof


Site Timeline