Christians Technikseite RS-485-Busankoppler

Aufgrund meiner bereits fast 15-jährigen Tätigkeit im Bereich der Gebäudeautomation, traue ich mich zu behaupten, dass ich die Schwachstellen und Unzulänglichkeiten verschiedenster Systeme kenne. Daraus entstand die Idee, eines eigenen Systems, welches bestehende Systeme in den Schatten stellt.
Die zur Zeit am Markt befindlichen Gebäudeautomatisierungssysteme und deren zugrunde liegende Lösungsansätze, können in mehrerlei Hinsicht, als nicht optimal betrachtet werden. Weit verbreitete, herstellerübergreifende Bussysteme wie zum Beispiel KNX überzeugen durch ihre Kompatibilität, der einfachen Verdrahtung und den vielen am Markt befindlichen Komponenten. Im Bereich der Sonderlösungen und Bewältigung von komplexen Aufgaben kommen sie ohne eine übergeordnete, zentrale Steuerung nicht aus. Diese zentrale Intelligenz wird oft in der Form einer SPS ausgeführt, welche durch hohe Rechenleistung und Software- Flexibilität besticht. Die Kopplung dieser beiden Systeme führt zu einer massiven Steigerung der Anlagenkomplexität sowie des damit verbundenen Engineering-Aufwands. Die ausschließliche Nutzung einer SPS scheitert am massiven Verkabelungsaufwand durch die zentrale Positionierung in Verbindung mit der parallelen Anbindung von Peripherie-Geräten. Ein erster Schritt in Richtung zentrale Steuerung und einfache Anbindung der Sensoren, wurde mit dem RS485-Busankoppler bewerkstelligt. Dieses System wurde nochmals grundlegend überdacht und auf CANopen umgestellt.

Technische Grundlagen.

Das System basiert auf CANopen, einem auf CAN aufbauenden Industriestandard. Die Verwendung eines weit verbreiteten Standards hat viele Vorteile. Die Hauptgründe für die Verwendung waren einerseits die direkte Kommunikation mit SPSen und die Möglichkeit einer nahezu vollautomatischen Inbetriebnahme der Geräte. Diese Führt etwa zu einer Halbierung der Installations- und Inbetriebnahmezeit, im Vergleich mit derzeit verfügbaren Systemen. Für Steuerungen, welche CANopen nicht nativ unterstützen, wurde ein Gateway entwickelt. CANopen beschreibt den verwendeten Grundstandard, welcher durch sogenannte Geräteprofile erweitert und spezifiziert wird. In diesem Fall kommt das Geräteprfil CiA-401 für IO-Module zum Einsatz, da es für den geplanten Einsatzzweck (im Gebäude verteilte IOs) hervorragend geeignet ist.

Kommunikation.

Im Internet findet man sehr viele Unterlagen zu CANopen, selbst die Spezifikationen sind einfach erhältlich. Daher möchte ich nur kurz die wichtigsten Punkte zusammenfassen. Für weitere Informationen empfehle ich die CiA-301 und CiA-401.
Bei CANopen kommen hauptsächlich folgende Kommunikationsarten zum Einsatz:

SDO (Service Data Object):

Hierbei werden Daten zwischen zwei Teilnehmern, anhand eines Server-Client-Modells, ausgetauscht. Somit kann auf Daten des sogenannten Objektverzeichnisses zugegriffen werden. Im Objektverzeichniss sind alle relevanten Datenpunkte enthalten, welche zur Indentifikation und Konfiguration der Module benötigt werden. Ein Eintrag des Objektverzeichnisses wird mit einem 16 Bit Index und einem 8 Bit Subindex adressiert. Die Anordnung der Daten ist in der CiA-301 und CiA-401 Spezifikation festgehalten und ermöglicht eine weitgehend automatisierte Einrichtung der Module.

PDO (Process Data Object):

Mit den Prozessdatenobjekten werden, wie der Name vermuten lässt, Daten des Prozesses, also der Sensoren und Aktoren, übertragen. Diese Übertragung erfolgt mit normalen CAN-Telegrammen und daher unbestätigt. CANopen sieht für jedes Gerät bis zu 512 Sende- und Empfangs-PDOs vor. Für jede CAN-ID darf es genau einen PDO-Producer (Erzeuger) geben und es können bis zu 8 Byte Nutzdaten übertragen werden, welche von keinem, einem oder mehreren PDO-Consumern (Empfängern) empfangen und verarbeitet werden. Ebenfalls direkt vom CAN übernommen wurde die Möglichkeit, dass ein PDO-Consumer einen PDO-producer dazu veranlasst seinen aktuellen Status auf den Bus zu senden und ihn somit allen PDO-Consumern zur Verfügung stellt. Dieser Mechanismus wird als Read-PDO-Protokoll bezeichnet.

NMT (Networt Management):

Das CANopen Netzwerkmanagement geht von einem CANopen Netzwerkmanager, welcher normalerweise durch die übergeordnete Steuerung (SPS) realisiert wird, aus und unterhält zu jedem Gerät im Netzwerk eine Client-Server-Verbindung. Seine wichtigsten Funktionen bestehen aus der Funktionsüberwachung der Nodes und deren kontrollierten Start/Stopp. Die Funktionsüberwachung erfolgt bei meinen Modulen mittels Heartbeat Nachrichten. Hierbei erzeugt jeder Node zyklisch ein Heartbeat-Telegramm, andere Nodes und/oder der Netzwerkmanager überwachen diese Telegramme.

Verkabelung.

Derzeitige Hardware.

Gateway.

Das Gateway ermöglicht die Anbindung der CANopen Geräte an Steuerungen welche von sich aus CANopen nicht unterstützen. Das Modul sitzt im Verteiler, vorzugsweise nahe das Netzteils und übernimmt die Funktionalität des Bus-Masters. So überwacht es die Funktion der Nodes und Puffert alle aktuellen IO-Abbilder. Zusätzlich liegen alle Konfigurationsdaten im Gateway, welche beim Systemstart an die Nodes übertragen werden. Dies ermöglicht den Austausch eines defekten Nodes, ohne das System neu konfigurieren zu müssen. Die Anbindung an die übergeordnete Steuerung erfolgt per LAN (UDP) oder UART (TTL oder RS232).

Unterputz-IO-Modul.

Das Modul ist konzipiert um hinter einen Elektronik-Taster (Aussehen eines KNX-Tasters aber mit offenen Klemmen) in einer Unterputzdose Platz zu finden.

Hutschienen-IO-Modul.

Der große Bruder des Unterputz-IO-Moduls.
In einem 4 TE breiten Hutschienenmodul wird geballte Funktionalität geboten:

Tastsensor.

Der Tastsensor basiert auf den Teilen von haus-bus.de und bietet folgende Funktionen:

Inbetriebnahme.

Auf einer Steuerung, welche CANopen direkt unterstützt, ist die Inbetriebnahme direkt aus der SPS-Software möglich und beschränkt sich auf das Einstellen der Busgeschwindigkeit und Abwarten bis der Busscan abgeschlossen ist, dann sind die Geräte wie IOs der SPS ansprechbar.

Wie die Anbindung an eine Steuerung, welche CANopen nicht unterstützt, abläuft, wird im Video anhand eines Loxone Miniservers gezeigt.

Kommentare.

Kommentare (3)

Sortierung

5/5 (2)

Lucas (Östereich) sagt...

Welches Gateway verwendest sie, und haben sie die CANopen Master Konfigurator selbst programmiert?

Antworten

Permalink

Berichten

22 Februar 2021 00.05

Peter Bauhuis (Deutschland) sagt...

Hallo,
Ausführung und Handhabung gefällt mir sehr gut
was würden die Module kosten

Grüße

Admin:

Hallo Peter.
Zur Zeit kann ich es noch nicht genau sagen, da für die Serie noch einige Punkte offen sind. Angestrebt sind etwa 50,- bis 60,- je Modul (IO-Modul, Taster), das Hutschienenmodul wird je nach Ausstattung zwischen 200,- und 300,- liegen. Alles als Fertiggerät versteht sich.
Christian

Antworten

Permalink

Berichten

2 August 2017 06.54