KM-Bus Interface

Inhalt





Grundsätzliches

Ziel ist es, ein dem Optolink-Logging ähnliches Logging an dem KM-Bus zu bewerkstelligen.

Achtung:

Bitte Vorsicht walten lassen, wenn am KM-Bus gearbeitet wird !
Ich empfehle, einen dedizierten M-Busbaustein (z.B. ST...) und Optokoppler zu verwenden.
Ihr seid elektrisch mit der Heizungssteuerung verbunden und könnt diese beschädigen !

Das Protokoll der Optolinkschnittstelle ist wesentlich mächtiger was den Zugriff auf die Steuerung angeht (direktes schreiben und lesen von RAM und Ports), ist aber durch die Optische Trennung leichter zu handeln.

Beim KM-Bus ist es umgekehrt:
Die Kommandos erachte ich (persönlich, keine Garantie auf Richtigkeit) als eher unkritisch, da sie nicht tief in das System eingreifen.
Kritisch ist hier eher die Tatsache, daß elektrisch auf dem Bus rumgenagelt wird. Also bitte Vorsicht !

Auch bei M-Bus Baustein und optischer Trennung: man kann immernoch den Bus lahmlegen. Die Anlage wird man wohl nicht aus dem Tritt bringen (soweit ich das bisher sehen kann), aber angeschlossene Teilnehmer können im schlimmsten Fall nicht mehr kommunizieren (was durchaus noch erträglich ist).




Hardware

1. Passiv:

Vorteile:
  • es muß nur gelesen werden
  • kein Eingriff in den Bus
  • geringer Hardware Aufwand
  • geringer Software Aufwand

Nachteile:
  • Es muß ein Gerät am Bus hängen, welches die notwendigen Daten erhält (z.B. eine Vitotrol)
  • es ist äußerst uncool !

Ein ganz einfaches Interface (read only) sieht wie folgt aus:
KMB_simple_IF2.JPG
Das war mein erstes Testinterface.
Der Anschluß KM-Bus mit mit dem Stecker 145 1,2 Verbunden (Polung beachten !)
VCC ist die Betriebsspannung meines Zielsystems.
Am Anschluß CPU kann ich direkt auf die UART eines Mikrocontrollers oder über einen Pegelwandler oder USB-Seriell Baustein an den PC gehen.

Wie auch immer: Mit 1200 8E1 bekomme ich alle Telegramme des Bus-Masters mit.

2.Aktiv

Vorteile:
  • Mehr Möglichkeiten (z.B. Einstellungen änder am Steuergerät)
  • Mehr Daten verfügbar (?)
  • Kein weiterer KM-Bus Teilnehmer nötig
  • Mehrere Geräte können Emuliert werden


Nachteile:
  • höherer Hardware Aufwand
  • höherer Software Aufwand
  • Eingriff in den Bus

Und da wir alle nicht hier sind weil das Leben einfach ist, ist die aktive Variante natürlich Mittel der Wahl !

Ich verwende hierbei den ST-Baustein vom Funktionserweiterungsmodul. Neben dem ST-MBus-Interface sind auch noch 2 Optokoppler mit drauf.
Das ganze ist also schön galvanisch getrennt (und passt in eine Streichholzschachtel - wer sowas noch kennt).
Als einfache Eigenbau-Variante kann man natürlich auch obige Schaltung verwenden, erweitert durch einen ebenso einfachen Sendemechanismus:KMB_RXTX_IF2.JPG


ACHTUNG: nur ein Vorschlag. Habe diese Schaltung noch nicht getestet. Bitte auch die M-Bus-Spec mit beachten.
Zumindest ist der Widerstand R5 anzupassen um die Strom-Differenz zu erzeugen. Ggf. sind beide Signale auf der CPU Seite zu invertieren.




Software

Wie oben beschrieben sendet der Master ca. alle 5 Minuten Telegramme um die ID aller möglichen Teilnehmer abzufragen.
Wenn ein Teilnehmer angeschlossen ist muß er quasi sofort auf das Telegramm antworten.

Und hier sehe ich die Problematik:

vermutlich ist es in einem "Nicht Echtzeit-Betriebssystem" (Windows, Linux) nicht immer möglich rechtzeitig zu antworten.
Ich verwende daher einen externen Mikrocontroller, der die Buskommunikation macht und zur Zeit zum PC hin eine Optolink Schnittstelle emuliert.
Somit ist es möglich, die Bestehende PC SW zu verwenden.

Wenn ein Gerät an den KM-Bus angeschlossen wird passiert folgendes:
("Log" der Kommunikation zwischen Vitotronik 200KW2 und Vitotrol)
  • Master sendet Read-ID command (0x33 auf Adresse 0xF8, Länge 0x04)
  • Slave antwortet mit seiner ID (0xB3..)

Das ganze passiert ca. 5 Mal.
Dann liest der Master 1 Byte von Adresse 0. Wenn das "1" ist, schreibt er auf Adresse 0x0A.
Danach sendet der Master regelmäßig:

  1. sehr oft: PING. Damit gibt er dem Slave die Möglichkeit, Daten zu senden
  2. oft: Datensatz 0x19 mit den Daten 0xFF 0x90
  3. ca. alle 70 Sekunden: Datensatz 0x1D: Temperaturen, Pumen- und Fehlerstati (harharhar !)

Die Software macht nun folgendes:
Es gibt eine ISR (Interrupt Service Routine) welche folgende Aufgagben übernimmt:
  • Telegramm empfangen
  • CRC upaten
  • Empfänger Klasse, SubKlasse und CRC überprüfen
  • Automatische Antwort für PING anstoßen (wird über FIFO und TX ISR ausgeführt)
  • Daten in speziellen Puffer kopieren und MAIN informieren (Flag)

Diese ISR ist das Herzstück.

Main macht folgendes:
  • warten auf das Daten-Ready-Flag
  • Auswerten und Aufbereiten der Daten
  • Schnittstelle zum PC auf Basis des "Optolink" Protokolls

Soviel zum Logging. Die bisherige PC SW läßt sich komplett einsetzen (was das Loggen betrifft).




Ausblick

Denkbar für einen weiteren Ausbauf:
  • virtual Vitotrol (WEB): eine Webseite, welche eine Vitotrol emuliert
  • DCF-77 als KM-Bus Teilnehmer
  • Vitocom über den PC (e-mail, SMS, etc.)

Um noch an das AVR-LAN-Interface anzuknüpfen:

Ein KM <-> LAN (oder/und Seriell etc.) Interface:

zum KM-Bus:
Kommunikation wie oben besprochen, nur für mehrere Geräte.

zum LAN, UART,etc.:

einzelne Geräte werden als Slots abgebildet.
Jedem Slot kann ein Datensatz, bestehend aus Klass, SubKlass und ID zugewiesen werden.
Ist ein Slot so belegt, verhält sich das Interface gegenüber dem KM-Bus wie ein solches Gerät:
Es antwortet also auf alle Anfragen bezüglich Klass/SubKlass dieses Gerätes.
Dafür wird für jedes Gerät ein entsprechenden Speicher angelget.

Ein Client über LAN etc. kann sich also einen Slot "buchen" und darüber Daten mit dem Master (Vitotronic) austauschen.
Vorteil ist, das die einzelnen Klients nicht das "aufwändigere" KM-Bus Protokoll mit den zugehöreigen Timings sprechen müssen sondern "einfach" eine Verbingund zum LAN-Interface aufbauen und dort Daten abladen oder aufnehmen.


ES GIBT VIEL ZU TUN.... und das ist auch gut so !