BCU1 oder BCU2?

[OStein]

Hallo Forum,

die Hersteller von EIB-Hardware scheinen ja inzwischen fast komplett auf BCU2 umgestellt zu haben - ausser Gira, die brauchen die BCU2 nur für die FT1.2-Schnittstelle (laut ihrem Katalog).
Kann mir jemand den technischen Hintergrund dazu erklären? Wieso z.B. braucht Merten für seinen MF-Taster mit RTR die BCU2 und Gira nicht? Fairerweise muss man sagen, dass die BCU2 bei Gira auch deutlich teurer ist als bei allen anderen... oder ist BCU2 nicht gleich BCU2 (jetzt mal von der Herstellerkennung abgesehen...)? Meine Befürchtung ist halt, dass wenn ich jetzt 20 BCU1's kaufe und irgendwann den Taster/BWM wechseln will, ich gleich eine neue BCU kaufen muss...
Sehr verwirrend das alles...

Gruss,
Oliver

[Dieter Koch]

Hallo Oliver

Der EIB hat mit der BCU 1 angefangen. In dieser ist eine bestimmte Datenmenge zu speichern. Früher gab es da keine Probleme. Aber schon mit der Einführung von etwas komplexeren Geräten mußten sich die Hersteller etwas einfallen lassen. Das taten sie, in dem sie einen Co-Prozessor mit wesentlich höherem Speichervolumen hinter die BCU 1 hängten. Die BCU 2 gab es noch nicht. In diesem Fall arbeitet die BCU 1 eigentlich nur als Schnittstelle zwischen EIB und dem Co-Prozessor. Irgendwann kam dann eine große bedeutenden deutsche Industriefirma aus Regensburg auf die Idee die BCU 2 zu entwickeln. Diese hat viel mehr Speichermöglichkeit als die ältere BCU 1. Mit der ersten BCU 2 gab es einen Haufen Anlaufschwierigkeiten, die jetzt aber mit der neusten BCU 2 verschwunden.

Die Hersteller gehen nun getrennte Wege:
Die INSTA-Gruppe (JUNG; GIRA; BERKER) nimmt weiterhin nur die BCU 1 mit angeflanschten Co-Prozessor. Der kann theoretisch beliebig groß sein. Geräte mit BCU 2 Technologie aus diesen Häusern sind OEM-Produkte, die aus marktpolitischen Gründen mit in das Portfolio aufgenommen wurden.

Andere Hersteller (SIEMENS; MERTEN, BJ/ABB) setzen auf die BCU 2-Technik. Sie nutzen für ihre Geräte den erhöhten Speicherplatz direkt in der BCU. Für Produkte, die einen nicht so hohen Speicherplatz benötigen, wird weiterhin die BCU 1 gebraucht.
Ob es jetzt auch Produkte die eine BCU2 mit angeflanschten Co-Prozessor gibt, kann ich nicht sagen. Ich denke mir aber, daß diese Vorgehensweise unwirtschaftlich ist. Die BCU 2 ist teurer als die BCU 1. Dann nehmen sie eben eine BCU1 mit beliebigen Co-Prozessor.

Auf dein Beispiel RTR MERTEN/Gira geantwortet:
MERTEN nutzt ja die BCU2 bei diesem Produkt. Du kann also die Appllikation in den BA einladen.
Bei GIRA muß der Aufsastz beim Laden de Applikation auf dem BA stecken, da der größte Teil der Applikation, wenn nicht alles, in den CO-Prozessor durchgereicht wird. Nach dem Renovieren müssen die alten Oberteile wieder auf genau die richtigen Unterteile gesteckt werden. Das ist auch der Grund, warum JUNG bei ihrem RTR BA und Oberteil in einer Einheit montiert haben.

Alexander und Ralf mögen mich korrigieren, wenn ich etwas falsch geschrieben habe.

Gruß
Dieter

[OStein]

Hallo Dieter,

vielen Dank für Deinen ausführlichen und interessanten Beitrag! So hat mir das noch keiner erklärt So langsam wird mir klar:

- warum Gira ein ETS-Plug-In für seine neueren Devices braucht (RTR) und Merten das mit "Bordmitteln" der ETS macht und warum mit einem "flashbaren" (lies: updatefähig=zukunftssicher) Gerät geworben wird, obwohl die Applikation doch bei jedem EIB-Gerät "updatefähig" ist - aber eben nur, wenn sie in der BCU sitzt ;-)

- warum bei GIRA die BCU2 so teuer ist im Vergleich zu Merten/BJ/ABB/Siemens ... (OEM)

Kleine Frage am Rande: ist die BCU2 eigentlich 100% abwärtskompatibel zur BCU1? d.h. tut ein Bewegungsmelder oder Tastsensor, der für BCU1 designt ist, auch an der BCU2?

Gruss,
Oliver

[S. De Bruyne]

BCU 2 has indeed been designed to be 100 % downwards compatible to BCU 1. BCU 2 can then be running in "compatibility mode".

However, mostly one simply buys the BCU that fits to the application module and the application program that one wants to use.

This compatibility mode was nice in the beginning, when there were more application programs for BCU 1 than for BCU 2. But at tha time, BCU 2 was also remarkably more expensive than BCU 1. So, it is/was rarely done.

[OStein]

Dear Mr. DeBruyne,

thanks for the info. I was just wondering, if I need a total of 20 BCU's and 15 of them have to be BCU2, wouldn't it make sense to make them all BCU2 to be able to change the application modules lateron...

Oliver

[tommy]

Hallo!

Ein interessantes Thema, nichtwahr!
Zum großen Teil stimmt alles, was weiter oben geschrieben wurde, jedoch bleibt ein wichtiger Aspekt unberücksichtigt.
Auch die BCU2 hat einen im Vergleich zu einem Co-Prozessor sehr geringen Speicherplatz. Applikationen von Geräten wie z. B. das MT701, ein Info-Display2 oder auch der Gira TS 2+ hätte in ihrer Gesamtheit niemals in einen BCU2-Speicher gepasst! Der Einsatz eines zweiten Applikationscontrollers ist bei solchen Geräten unumgänglich. Und wenn man diesen zweiten Controller eh einsetzen muss, verzichtet man auf die teure BCU2 und bedient sich der BCU1, welche im übrigen auch heute noch zuverlässiger arbeitet und für diesen Zweck die selben Dienste leistet!
Und wenn man Flash-programmierbare Applikationscontroller verwendet, muss man auf ein Plug-In zurückgreifen, da die ETS (noch) keine Flash-Prohgrammierung beherscht.
Die allermeisten komplexen Geräte verschiedener Hersteller, die mit der BCU2 funktionieren, haben auch einen zweiten Controller integriert. Die BCU2 wird dabei meist nur deshalb verwendet, weil sie einen größeren Speicherplatz für die Tabellen (Objekttabellle, Gruppenadressen, etc.) hat. Die Applikation selbst, oder ein großer Teil davon, ist dann im zweiten - nicht über den Bus flasharen - Controller untergebracht. Ein einfaches Update der Anwendungsapplikation ist deshalb nicht möglich.
Nur so am Rande!