Forum: Haus & Smart Home Logamatic 2107 Schnittstelle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von IngoF (Gast)


Lesenswert?

Würde ja auch gerne was neues erzählen :o(

... dummerweise funktioniert mein Programm auf dem PIC im MPLAB-Debugger 
einwandfrei aber nicht im Betrieb. Und meinen Debugmode im PIC selber 
mit PicKit3 kann ich im MPlab nicht aktivieren.

Falls irgendjemand irgendwann eine Idee haben könnte wie man in den 
Debugmode beim PIC18F258 kommt wäre ich für jeden Hinweis dankbar. 
Vielleicht verirrt sich ja mal ein PIC-Nutzer in diesen Thread ;o)

Rudi schrieb:
> Ich suche jetzt eigentlich noch eine Isolationsmöglichkeit für die
> RX/TX-Leitung. Durch die 2-Draht Lösung gibt es nicht mehr viel Strom.

@Rudi,
meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht 
jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller?
Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein...

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

Hallo,

ich habe keinen PIC aber schau mal dort, evtl. ist es das schon:

Beitrag "Debugging mit PICKIT3?"


IngoF schrieb:
> meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht
> jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller?
> Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein...

Ja, eine galvanische Trennung. Mit LDO und Optokoppler funktioniert es 
bei mir nicht mehr, der Bus spinnt dann rum (mit der 2-Draht Variante). 
Mit der 3-Draht Variante habe ich es nur mit einem Funktionsgenerator 
und externer VCC probiert. Offensichtlich reicht der Strom nicht aus.

von Rudi (Gast)


Lesenswert?

Hallo,

mal etwas Semi-OT. Wurde bei euch in der Logomax schonmal der Lüfter für 
den Brenner getauscht ? Nach einer längeren Wartungsarbeit gabs nur 6L / 
229 und keine Flamme. Der Lüfter ist auch etwas laut, meinte der 
freundliche Heizungsfachmann. Nach mehreren Versuchen der 
Heizungsanlage, von Flamme an auf Fehlermeldung, lief es dann irgendwann 
wieder wie geschmiert.


Grüße.

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

hi rudi,

was hast du denn genau für ein gerät? logamax ist nur so eine art 
familienname für wandhängende heizgeräte.

@ all
bei der gelegenheit möchte ich mich auch gleich in sachen ems an bord 
melden. im gegensatz zu den meisten hier, habe ich nicht das ziel daten 
zu loggen, sondern meinen Brennwertkessel (gb142) durch die vorgabe eine 
brennerleistung anzusteuern. am ende soll eine außentemperaturgeführte 
rücklaufregelung dabei herauskommen.

ich habe vor das telegramm des moduls em10 zu ermitteln um es dann mit 
einem avr zu emulieren. das em10 hat die fähigkeit ein ems-heizgerät 
temperatur- oder leistungsgeführt anzusteuern, wobei es selbst ein 0-10v 
signal als führungsgröße hat.

an dieser stelle auf jeden fall schon mal einen herzlichen dank an die 
beiden ems-hauptakteure rudi und ingo. soweit wäre ich aus mangel an 
equipment und know-how nie gekommen.

ich arbeite übrigens seit 18 jahren als servicetechniker des 
werkskundendienstes von buderus.

achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt 
und zu 'papier' gebracht (siehe anhang).


//niffko

von Rudi (Gast)


Lesenswert?

Niff Ko schrieb:
> was hast du denn genau für ein gerät? logamax ist nur so eine art
> familienname für wandhängende heizgeräte.

Das ist die GB152.

Niff Ko schrieb:
> achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt
> und zu 'papier' gebracht (siehe anhang).

Das ist doch mal etwas. Hast du zufällig Angaben für den maximalen Strom 
für die einzelnen Komponenten am Bus ? Werden die 5V aus der VREF 
erzeugt ?

Niff Ko schrieb:
> am ende soll eine außentemperaturgeführte
> rücklaufregelung dabei herauskommen.

Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe) 
den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird 
das nicht funktionieren, es sei denn du zapfst noch einen 
Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-)


Danke & Grüße.

von Niffko (Gast)


Lesenswert?

hi rudi,


> Das ist die GB152.

das gebläse gehört bei 6L/229 erst mal nicht zu den üblichen 
verdächtigen. abnormale geräusche kommen in der regel vom lager, hatte 
ich hin und wieder schon. fehler 6L bedeutet, dass das flammensignal 
(ionisation) vorhanden war aber dann zusammengebrochen ist. hier hätte 
man sich bei auftreten des fehlers mal den wert des flammenstromes im 
monitor anschauen können. evtl. schwächelt deine ionisationselektrode, 
die zeigen manchmal erst bei längerer auskühlung ihr wahres gesicht.



>Hast du zufällig Angaben für den maximalen Strom
>für die einzelnen Komponenten am Bus ?

negativ.



>Werden die 5V aus der VREF erzeugt ?

nein. U_REF  ->  ~0,6V, die geht lediglich auf die komparatoren. 5V 
kommen vom netzteil des moduls.



> Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe)
> den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird
> das nicht funktionieren, es sei denn du zapfst noch einen
> Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-)

du meinst, die abgegebene wärmemenge berechnen und dann eine 
entsprechende brennerleistung vorgeben? nein. anstatt wie üblich 
abhängig von der aussentemperatur die vorlauftemperatur auszuregeln, 
wird bei der rücklaufregelung - du ahnst es bereits - die 
rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile, 
googel das mal.


//niffko

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

Niffko schrieb:
> du meinst, die abgegebene wärmemenge berechnen und dann eine
> entsprechende brennerleistung vorgeben? nein. anstatt wie üblich
> abhängig von der aussentemperatur die vorlauftemperatur auszuregeln,
> wird bei der rücklaufregelung - du ahnst es bereits - die
> rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile,

Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang 
an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben, 
es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine 
Kurven, durch Mikrozirkulation etc..

Wenn du nun die Rücklauftemperatur als Führungsgröße nimmst, würde der 
Vorlauf ansteigen ohne nennenswerte Änderung der Führungsgröße 
(Rücklauftemperatur).

Wie willst du das Problem ohne weitere Regelgrößen erschlagen ?


Grüße.

von Fred (Gast)


Lesenswert?

Gibts eigentlich noch mehr Informationen über die Telegramme des 
Servicekeys? Habe schon einiges raus (anhand der Listen und PDFs hier). 
Mir fehlt allerdings z.B. noch die RÜcklauftemperatur.

von IngoF (Gast)


Lesenswert?

Na dann hast Du nicht richtig gesucht:
Beitrag "Re: Logamatic 2107 Schnittstelle"

Gruß
Ingo

von Fred (Gast)


Lesenswert?

IngoF schrieb:
> Na dann hast Du nicht richtig gesucht:
> Beitrag "Re: Logamatic 2107 Schnittstelle"
>
> Gruß
> Ingo

Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen 
ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255 
die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus. 
Bissl komisch

von Rudi (Gast)


Lesenswert?

Fred schrieb:
> Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen
> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255
> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.

Werden die digitalen Werte an der Anlage richtig angezeigt ?

von Fred (Gast)


Lesenswert?

Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile, 
Flammenstrom, Kessel-Soll,Kessel-Ist, WW  etc.pp. das geht soweit alles.


Rudi schrieb:
> Fred schrieb:
>> Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen
>> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255
>> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.
>
> Werden die digitalen Werte an der Anlage richtig angezeigt ?

von Ingo F. (ingof)


Lesenswert?

Fred schrieb:
> Allerdings bekommen
> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255
> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.
> Bissl komisch

Hallo Fred,

kann dann ja eigentlich nur mit dem Softwarestand Deiner Busteilnehmer 
zusammenhängen oder mit Deiner Anlage. Wie sieht dass denn bei Dir aus?

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

Fred schrieb:
> Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile,
> Flammenstrom, Kessel-Soll,Kessel-Ist, WW  etc.pp. das geht soweit alles.

Ich meinte die beiden Werte die du per ServiceKey nicht richtig siehst.

von Fred (Gast)


Lesenswert?

@Ingo F.
Wie sieht was bei mir aus? :-) Ist eine Logamax Plus GB172 mit BC10 und 
RC35.


@rudi
Was meinst du genau?



Die Softwareversionen kann ich erst heute Abend abfragen.

von Rudi (Gast)


Lesenswert?

Fred schrieb:
> @rudi
> Was meinst du genau?

Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden 
Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle 
siehst.

von Fred (Gast)


Lesenswert?

Rudi schrieb:
> Fred schrieb:
>> @rudi
>> Was meinst du genau?
>
> Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden
> Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle
> siehst.

Ah, das meinst du. Zu finden ist das im Servicemenü der BC10? Muss ich 
nachher gleich mal schauen.

von Niffko (Gast)


Lesenswert?

Fred schrieb:
> Allerdings bekommen
> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255
> die sich nicht ändern).

... das ist schon o.k. so - der gb172 hat weder rücklauf- noch 
drucksensor.

Fred schrieb:
> Ist eine Logamax Plus GB172 mit BC10 und RC35.

der bc10 heißt beim 172er bc25   ;-)




//niffko

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang
> an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben,
> es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine
> Kurven, durch Mikrozirkulation etc..
hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im 
gerät über einen bypass (überströmventil), wenn der heizkreis dicht 
gemacht hat? deine rücklauftemperatur dürfte sich normalerweise nicht 
wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb 
des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen 
thermostatventilen mit nur geringem delta der vorlauftemperatur folgen.



Rudi schrieb:
> Wie willst du das Problem ohne weitere Regelgrößen erschlagen ?
das problem stellt sich bei mir nicht. ich habe die heizkreise meiner 
fußbodenheizung abgeglichen und die heizkennlinie entsprechend 
angepasst. so benötige ich keine zonenventile, die heizkreise sind also 
immer offen.


//niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im
> gerät über einen bypass (überströmventil), wenn der heizkreis dicht
> gemacht hat?

Das warme Wasser steigt nach oben und Zirkuliert oder ein Ventil ist 
nicht 100%ig zu etc.. Das meinte ich damit. Meine Temperatursensoren an 
den Rohren sehen ab und zu etwas zuviel bzw. sind nicht träge genug.

> deine rücklauftemperatur dürfte sich normalerweise nicht
> wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb
> des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen
> thermostatventilen mit nur geringem delta der vorlauftemperatur folgen.

Das ist eine Rücklauftemperatur von 3 Heizkreisen, ob es einen Bypass 
gibt, kann ich nicht sagen. Wie es sich mit dem Hauptrücklauf verhält, 
wenn alle 3 Heizkreise dicht gemacht haben, weiss ich noch nicht. Ich 
werde das demnächst mal ausprobieren.


Grüße.

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> Das ist eine Rücklauftemperatur von 3 Heizkreisen ...
ich war davon ausgegangen, dass es sich um einen ems-wert handelt. dann 
hätte es nur der kesselrücklauf sein können, da keine heizkreisrückläufe 
erfasst werden. ob an deinen heizkreisen überströmventile vorhanden 
sind, weiß ich natürlich nicht. deine gb152 jedenfalls ist mit einem 
internen überströmventil ausgestattet.

ich habe nur einen ungemischten heizkreis, daher ist kesseltemperatur 
gleich heizkreistemperatur und ich kann den ems-wert des 
kesselrücklaufes als führungsgröße benutzen.



//niffko

von buddi (Gast)


Lesenswert?

Hallo,

ich hab seit ein paar Monaten eine GB 162 und würde gern zur Optimierung 
der Anlage die Daten  zumindest wochenweise mit einem alten Notebook 
aufzeichnen und mit der Buderus Software auswerten.

Laut Buderus kostet der dazu erforderliche Service Key 214.-€.

Wenn ich mir den Thread so durchlese scheinen es einige unter euch 
geschafft zu haben einen "ServiceKey" selbst zu basteln.

Funktionieren diese Lösung tatsächlich so, dass die gleichen 
Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?

Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet 
sich der Aufwand im Vergleich zu Originalteil ?

Viele Grüße

buddi

von Rudi (Gast)


Lesenswert?

Hallo,

buddi schrieb:
> Funktionieren diese Lösung tatsächlich so, dass die gleichen
> Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?

Nein, dort siehst du direkt den EMS-Bus.

> Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet
> sich der Aufwand im Vergleich zu Originalteil ?

Ich denke nicht mehr als 10€ für die Bauteile.

von buddi (Gast)


Lesenswert?

Hallo,

> Funktionieren diese Lösung tatsächlich so, dass die gleichen
> Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?

Nein, dort siehst du direkt den EMS-Bus.

...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da 
geliefert und werden die mit der Buderus-Software angezeigt ?


> Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet
> sich der Aufwand im Vergleich zu Originalteil ?

Ich denke nicht mehr als 10€ für die Bauteile.

...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ?


Gruß
buddi

von Rudi (Gast)


Lesenswert?

Hallo,

buddi schrieb:
> ...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da

Die Daten/Telegramme vom EMS-Bus (siehe weiter oben).

Mit Service Key sieht es etwa so aus:

EMS-Bus (EMS-Telegramme) -> ServiceKey (Service Key Protokoll) -> 
Buderus Software oder Terminal

Mit dem Nachbau so:

EMS-Bus (EMS-Telegramme) -> Nachbau (EMS-Telegramme) -> Terminal


> geliefert und werden die mit der Buderus-Software angezeigt ?

Nein, die versteht das Format nicht direkt, nur wenn die Daten 
aufbereitet werden, wie durch den ServiceKey.

> ...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ?

Ich denke das sind alles Teile die du bei R. bestellen kannst. Es gibt 
hier im Thread mindestens 3 Schaltungen.

Das EMS-Protokoll ist hier auch etliche male beschrieben worden, 
zumindestens alle wichtigen Teile zur Überwachung der aktuellen Werte 
und Einstellungen.


Grüße.

von Fred G. (sysrun)


Lesenswert?

Nabend,

ich habe jetzt das Senden an die Anlage hinbekommen :=) ServiceKey ist 
in der Geräteliste aufgeführt, also alles bingo :-D


Jetzt versuche ich die ganze Sache mit der ECO-SOFT zu verbinden. Dazu 
schnüffel ich grad ein wenig am COM-Port des Rechners rum.

Nun meine Fragen:

1. Ist es richtig das die Software als erstes ein 0x02 sendet?

2. Wenn ich auf dieses 0x02 mit 0x10 antworte bekomme ich
 0x00 0x00 0x10 0x03 0x13; Was bedeuten diese Werte überhaupt?

3. Auf den obigen String antworte ich mit 0x10 0x02. Daraufhin bekomme 
ich 0x10 von der Software zurück. Da ich dann nichts mehr antworte, gibt 
mir die Software die Fehlermeldung "Keine ComKarte gefunden !!!"

Woher weiss ich eigentlich das ein "Telegramm" von der Software komplett 
gesendet wurde? Kommt z.B. nach "0x00 0x00 0x10 0x03 0x13" ein 
UART-Break? Trennzeichen habe ich da nirgends :-/

von IngoF (Gast)


Lesenswert?

Das sollte die Prozedur 3964R sein.
Habe mal meine Erkenntnisse aus den Logs von Chris_be hier gepostet:

Beitrag "Re: Logamatic 2107 Schnittstelle"
Beitrag "Re: Logamatic 2107 Schnittstelle"

generell kommt ein 04 davor. Bei einzelnen geänderten Werten zusätzlich 
noch eine 20.

Die Originalsoftware fragt erst alle Seriennummern der Busteilnehmer und 
anschließend alle Telegramme ab.

Dannach könnte man mit den Monitorwerten, die ja änderungen der 
einzelnen Bytes im Telegramm sind, alle Änderungen verfolgen,

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

Hm, das hatte ich schon gesehen.

Derzeit sende ich allerdings nichts an den Bus sondern habe als 
Gegenstelle zur ECO-SOFT einen Atmega zur Analyse.

Das erste was ich von der ECO-SOFT bekomme ist einfach nur 0x02. Mehr 
nicht, auch leider keine Trennzeichen.

Wenn ich darauf nicht antworte kommen noch 2x "0x02" nacheinander und 
dann 0x15 (ist wohl der Abbruch).

Das mit den nicht vorhandenen Telegrammstrennern stört mich ein wenig. 
Wenn ich das dann später auf den Bus schicke muss ich doch wissen wann 
ich ein BREAK setzen muss oder?!

von IngoF (Gast)


Lesenswert?

Das ist das Handshake vom 3964R-Protokoll. Es gibt dort kein Break. Das 
wird alles über das 3964R-Protokoll gemacht.

Einfach mal googeln. Die eigentlichen Daten kommen dann erst. Erst mal 
fragt die Ecosoft alle Busteilnehmer nach den Serienummern und den 
Telegrammen ab.
Und wenn auf die Abfrage keiner antwortet wird die Eco-Soft auch wohl 
keine Lust mehr haben weiter zu reden.

Oder habe ich irgendwas falsch verstanden.?

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

Ah! Okay, jetzt hats "klick" gemacht!
0x02 ist STX, 0x10 ist DLE, also die Antwort.

Dann kann ich ja nun weitermachen :-D

von Fred G. (sysrun)


Lesenswert?

So, das war schonmal recht erfolgreich.

- EMS-Verbindung Heizung <-> uC läuft
- Verbindung PC(Ecosoft) <-(3964R)-> uC läuft


Nun aber wieder ein paar Fragen g. Ich möchte ja nun beides 
zusammenbringen :)


Wenn ich die Kommunikation in der Ecosoft starte sendet diese als erstes 
"0x00 0x00".

Darauf Antworte ich dann mit "0x00 0x00 0x00 0x00 0x53 0x02 0x31".
Nun hat die Ecosoft schomal meinen "ServiceKey" identifiziert.

Laut dem Log hier aus dem Forum (serial_logamatic_0911_.txt) müsste ich 
dann noch folgendes an die Ecosoft schicken?!
<RX>00 00 01 00 00 00 03 00 01 03
<RX>00 00 02 00 08 0A 0C 0E 10 12 14 16 18 1A 1C 1E

Das Abfragen der werte beginnt offenbar ja erst danach:
<TX>04 08 07 .. .. ......

von Ingo F. (ingof)


Lesenswert?

TX: 00 00
RX: 00 00 00 00 53 02 31
RX: 00 00 01 00 00 00 03 00 01 03
RX: 00 00 02 00 08 0A 0C 0E 12 14 16 18 1A 1C 1E
TX: 04 08 07
RX: 04 08 07 00 0B 01 01 02 00 00 00 00 00 00 00 00 00 00 00
TX: 04 08 02
TX: 04 09 02
RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00
RX: 04 09 02 00 44 02 00

Also ich vestehe dass so dass mit der "00 00" alle Telegrammtypen vom 
Gateway selber abgerufen werden. Fragt sich nur was passiert wenn man 
diese Telegramme weglässt. Vielleicht steht ja auch drin welche 
Busteilnehmer am Bus hängen. Oder muss man bei der EcoSoft vorher 
angeben welche Busteilnehmer in der Anlage sind?
Irgend eine Bedeutung müssen die Werte ja haben. Notfalls einfach mal 
ausprobieren ob sich die Ecosoft dann anders verhält wenn man andere 
Werte oder keine Werte schickt.

Wenn die "00 00 00" gekommen wäre würde sich die Ecosoft ja nur für die 
Seriennummer interessieren. Also müsstest Du demnach auch alle 
Telegramme schicken...

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

Man KANN wohl vorher angeben welche Geräte verbaut sind. Man muss aber 
nicht.

Was ich schonmal gefunden habe:

00 00 00 00 53 02 31

0x53 = ServiceKey, 0x52 = "EcoTool"
0x02 = DEC 2 = Version 2
0x31 = DEC 49 = Version.49

Ich sende da 0x53 0x00 0x63, da meint die EcoSoft dann ich habe einen 
Servicekey in der Version 0.99 :-)


Ich probier da morgen mal weiter!

von Ingo F. (ingof)


Lesenswert?

Hallo an alle,

ich habe es endlich geschafft meine Software für die Hardware so langsam 
in den Griff zu bekommen ;-)

Ich möchte eine Platine für meine Hardware fertigen lassen.
Darauf befindet sich ein PIC18F2585. Die Hardware soll dann über 
DIP-Schalter konfiguriert werden können.

Je nach Hardwarebestückung und DIP-Schalterstellung gibt es verschieden 
Modes:

1) nur mitlesen und ausgeben der Telegramme über die serielle 
Schnittstelle. Ausgabe im Textmodus oder als RAW-Daten mit "0xaa 0x55 
0xaa 0x55" anstelle des <Break> was auf dem EMS-Bus. Beim Textmodus wird 
ein CR&LF gesendet damit nur ein Telegramm in einer Zeile steht.

2) mitlesen und senden. Dazu würden dann zwei Platinen benötigt und die 
Kommunikation läuft über den CAN-Bus. Hat den Vorteil dass man dann 
später mehrere Module anschließen könnte. Z.B. ein eigenes Display für 
Fehleranzeige oder alles andere.

Ich würde die Platine fertigen lassen. Es gibt auch eine möglichkeit die 
Platinen schon fertig bestücken zu lassen. Die Platinen gäb es dann zum 
Selbstkostenpreis+Versand

Wer hätte interesse daran. Den Preis müsste ich noch erst in Erfahrung 
bringen.

Dazu wäre ganz interessant welche Möglichkeiten Ihr habt und was Ihr für 
eine bestückte SMD-Platine ausgeben möchtet oder könntet. Will nichts 
verdienen...

*) Firmwäre brennen
*) Platine bestücken/löten (DIP)
*) Platine bestücken/löten (SMD)

Allerdings ist die Software für den CAN-Bus noch in der Entwicklung und 
würde die Platinen natürlich erst fertigen lassen wenn die Software 
fehlerfrei funktioniert.

Die Preise für die Bestückung lohnt sich allerdings erst ab einer 
größeren Menge weil eine einzelne Platine sonst 200€ kosten würde und 
sinnlos wäre.

Wer will kann ja mal dazu hier posten. Wenn es an die Bestellung geht 
gibt dann hier noch mal eine e-Mail oder URL. Kann allerdings nichts 
über den Zeitplan sagen. Ist eben nur ein Hobby von mir und habe nicht 
immer Zeit um daran zu arbieten.

Gruß
Ingo

Die Emulation eines ServicKey wird erst mal nicht funktionieren aber 
vielleicht auch irgendwann mal damit funktionieren.

von Karl M. (Gast)


Lesenswert?

Servus Ingo,

ja, das klingt gut :-)

An einer solchen, möglichst unbestückten Platine hätte ich Interesse.
Da ich schon was älter bin und gerne zittere ;-), wäre mir persönlich 
eine dip Version lieber. Aber ich würde auch bei einem smd Board nicht 
nein sagen, abhängig vom Preis natürlich.

Danke für Deine Mühe und Arbeit und
einen guten Rutsch
an alle EMS-Bus-Freaks ;-).

von Fred G. (sysrun)


Lesenswert?

Guten Morgen und frohes neues Jahr :)

@ingo: Das hört sich interessant an!

An der emulation eines Servicekeys arbeite ich ja grad. Das ganze läuft 
derzeit auf einem Arduino-Klon. Auf EMS-Seite nutze ich einen i2c-UART. 
Der kann per Registersetting astreine Breaks auf den Bus zaubern :-)

Die Kommunikation über 3964R läuft super.

Ich habe offenbar noch ein paar Probleme beim Senden auf den EMS-Bus. 
:-(

Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann 
Antwort mit 0x08) funktioniert.

Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht 
ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04 
<geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück.

Worauf muss ich beim Senden achten?

>Nach jedem gesendeten Zeichen musst du den Bus auslesen,
>um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf
>Low liegt, kann man wohl nicht senden.

Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne 
ich das am besten in der Software? Warten bis ein Break auf dem Bus 
auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann 
einfach lossenden?


Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal 
vom UART invertiert und dann über einen Transitor der eine Z-Diode 
"durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es 
besseres?

von Ingo F. (ingof)


Lesenswert?

Fred Granna schrieb:
> Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann
> Antwort mit 0x08) funktioniert.

Na das ist vermutlich ein Tippfehler. Antworten müsstest Du auf das 
Polling vom Servicekey 0x8b mit Der ServiceKey Adresse 0x0B und nicht 
0x08 ;o)

Fred Granna schrieb:
> Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht
> ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04
> <geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück.

Wichtig wäre zu wissen was Du bekommst und was Du sendest.

Vermute mal dass Du auf das Polling 0x8b mit 0x0b beantwortest und dann 
das Telegramm schickst. Das ist meiner Meinung nach falsch.

Der Busmaster 0x08 sendet das Polling und übergibt somit die Kontrolle 
jeweils einem einzigen Slave mit der Adresse. Und wartet eine bestimmte 
Zeit. Wenn nichts kommt existiert der Busteilnehmer nicht und wird erst 
mal für eine Zeit nicht mehr abgefragt. Wenn der Busteilnehmer beim 
nächsten mal abgefragt bekommt er die Adresse des Slave zurück. Der 
Busmaster weiss jetzt dass der Busteilnehmer vorhanden ist und und fragt 
den Busteilnehmer jetzt viel öfter ab.

Wenn der Slave Daten zum senden hat antwortet er wieder mit der eigenen 
Adresse. Dann sendet er die Zieladresse. Es gibt dann folgende drei 
Möglichkeiten für eine Zieladresse:

1) 0x00
... Telegramm ist an alle gerichtet er will keine Antwort.

2) <Busadresse> (z.B. 0x08)
... Telegramm ist an einen einzigen Empfänger gerichtet und keine 
Antwort erwartet.

3) <Busadresse + 0x80)
... Telegramm ist an einen einzigen Empfänger gerichtet und eine Antwort 
wird erwartet.

Danach wird dann die Telegrammadresse gesendet. Wenn der Slave jetzt 
Daten mitsendet folgen diese. Das erste Byte ist dann das Offset des 
Telegramms. und danach folgen die Daten mit der Prüfsumme.

Wenn der Slave seine Kontrolle über den Bus abgibt weil alle Telegramme 
gesendet wurden sendet er anschließend noch ein <Break>

Dann geht das Polling weiter bis zum anderen Busteilnehmer. Dieser kann 
dann antworten. Es kann auch sein dass der Busteilnehmer auch erst 
später antwortet und nicht sofort auf das nächste Polling mit der 
Antwort reagiert.

Also in Deinem Fall würde ich erst mal folgendes Versuchen:

RX: 0x8b <Break>
TX: 0x0b <Break>
.
.
.
RX: 0x8b <Break>
TX: 0x0b 0x88 0x02 0x00 <"CRC"> <Break>
TX: 0x0b <Break>
.
.
.

Vermutlich kann man auch im ersten Durchgang sofort mit dem Telgramm 
antworten und muss nicht erst mal nur seine Anweseheit zeigen. Weiss 
leider nicht mehr ob der Busmaster sofort mit dem verstärkten Polling 
anfängt oder erst drei mal auf eine Antwort vom Busteilnehmer erwartet. 
Ist schon zu lange her...

Wenn das nicht so will wie von mir erwartet würde ich auch mal mit 
Zieladresse ohne das gesetzte "Antwortbit" versuchen (0x08)

Kann auch sein dass man das Offset (0x00) bei einer Abfrage nicht 
mitsenden muss oder darf.

ALso
TX: 0x0b 0x08 0x02 0x00 <"CRC"> <Break>
TX: 0x0b 0x08 0x02 <"CRC"> <Break>

Es kann auch sein dass man nicht wirklich noch zusätzlich mit einer 
leeren Antwort am Schluss die Übertragung beenden muss und nach einer 
bestimmten Zeit einfach der nächste Busteilnehmer angepollt wird.

Aber wenn mann Pech hat muss man zusätzlich noch irgendwelche Daten 
übergeben. Habe gerade mal aus meinem Log ohne Polling die folgen Zeilen 
gefunden:

10 89 29 00 01 90
09 10 29 00 6B DF
10 08 35 00 01 01 00
10 88 14 00 03 6E
08 10 14 00 39 AA 1C EC

Meine Vermutung ist aber eher dass z.B. beim ersten Telegramm die RC30 
(0x10) die 0x09 auffordert im Telegramm 0x29 mit dem Offset 0x00 das 
Byte auf 0x01 zu setzen. Wird dann wohl ein Steuerparameter sein.

Poste doch einfach mal Deine Versuche und die Antwort. Habe selber noch 
keine "echten" Sendeversuchen unternommen. Habe nur mal alle Adressen 
beantwortet um die Service-Key Adresse herauszufinden. Habe Dummerweise 
erst nach der RC30 angefangen zu suchen und die 0x0b also übersehen.

Fred Granna schrieb:
> Worauf muss ich beim Senden achten?
>
>>Nach jedem gesendeten Zeichen musst du den Bus auslesen,
>>um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf
>>Low liegt, kann man wohl nicht senden.
>
> Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne
> ich das am besten in der Software? Warten bis ein Break auf dem Bus
> auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann
> einfach lossenden?

Ups ich glaube das habe ich schon mit meiner viel zu ausführlichen 
Antwort erschlagen ;o)

Fred Granna schrieb:
> Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal
> vom UART invertiert und dann über einen Transitor der eine Z-Diode
> "durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es
> besseres?

Das war auch die Methode die ich das letzte mal beim scannen der 
Busadressen verwendet habe.

Habe aber danach herausgefunden dass die RC30 und andere "Externe" 
Busteilnehmer nicht so "brutale" Sendeversuche unternehmen, sondern nur 
der Busmaster 0x08 und evtl die 0x09 die am "internen" Bus hängen.

Beitrag "Re: Logamatic 2107 Schnittstelle"
Beitrag "Re: Logamatic 2107 Schnittstelle"

Es reicht also eine schaltbare Stromquelle mit ~40mA (wenn ich mich 
recht erinnere) dafür zu nehmen.

Der nächste Versuch ist also bei mir eine Sendestufe bei der der TX-Pin 
auf die Basis vom NPN-TRansistor geht und einen Emistterwiderstand gegen 
Masse von 80-100 Ohm. Der Kollektor geht dann direkt mit an den EMS-Bus.

Denke das dürfte schon ganz gut gehen.

Rudi hat wohl schon sowas ähnliches mit einem FET aufgebaut.... steht 
irgendwo in diesem Thread ;o)

Poste doch mal Deine Versuche und das Ergebnisse... Bin halt neugierig 
:o)

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

Ui, danke für diese "Ausarbeitung" ;-)


Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch 
das Polling eine Art "Sendefreigabe" weiterreicht. Also muss ich mit dem 
Senden so lange warten bis der Busmaster mir diese Freigabe per "0x8B 
<break>" erteilt.

Das mit dem TX ohne Z-Diode werd ich auch mal ausprobieren.


Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten 
;-)

von Ingo F. (ingof)


Lesenswert?

Fred Granna schrieb:
> Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch
> das Polling eine Art "Sendefreigabe" weiterreicht.

So könnt man das auch formulieren.

Mann kann auch in den Telegrammdaten eine längere Pause gesehen. Die 
RC30 bei mir legt auch mal nach einem Datenhäppchen eine 100ms Pause 
ein.

Fred Granna schrieb:
> Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten
> ;-)

Ich bin gespannt....

Werde meine Senderversuche erst unternehmen wenn der Empfang und 
übertragung über CAN-Bus erst mal problemlos läuft. So weit scheint der 
Weg nicht mehr zu sein :o)


Was ich ncoh vergessen habe.

Das Telegramm was man sendet muss man zwischen den Bytes eine Pause von 
einem Byte machen damit der Busmaster dieses Byte wiederholen kann (auf 
10 V heruntergezogen). Er spielt also so eine Art Repeater damit auch 
der in der letzte Reihe auch noch alles mitbekommt. Also genauso wie 
beim Polling auch. Vielleicht macht es ja Sinn später nach jedem 
gesendeten Byte die eigenen Daten zu vergleichen.

Wenn man irgendwann mal die Schaltung über den EMS-Bus speisen möchte 
sollte man die Strombelastung gut Buffern damit nicht ausvershen Daten 
gesendet oder der Bus gestört wird.

Gruß
Ingo

von Niffko _. (niffko)


Lesenswert?

Hallo Leute,


kurze Zwischenfrage zum Thema Sendestufe: Warum groß herum 
experimentieren, wenn eine original Buderus-Lösung bekannt ist?

Beitrag "Re: Logamatic 2107 Schnittstelle"

Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das 
schon interessieren.


Gesundes neues Jahr,

//niffko

von Ingo F. (ingof)


Lesenswert?

Niffko _ schrieb:
> Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das
> schon interessieren.

Ups, Die Lösung habe ich komplett vergessen :-)

Also ich hatte versucht die RC-30 Sendestufe zu entflechten. Ist mir 
allerdings nicht gelungen (Multilayer Platine)
Bin dann zu der gerade geposteten Lösung gekommen.

Allerdings ist diese Lösung auch so etwa der selbe Weg....

Bei der Buderus-Lösung sind vier 910 Ohm Wiederstände parallel und haben 
also einen Gesamtwiderstand von 227 Ohm. Der Bus wird also mit ~60mA 
belastet. Das wäre auf meine Schaltung übertragen also rechnerisch ein 
Emitterwiderstand von ~71 Ohm (68 Ohm).

Den LM393 habe ich zufällig auch in meiner Schaltung und reinzufällig 
auch noch eine Hälfte frei. :o)

Spricht also nichts dagegen diese zu übernehmen. Der OP soll wohl noch 
dafür sorgen dass man einen saubereren Pegel zur Ansteuerung hat.

DANKE für den Hinweis :o)

Die Buderus-Empfangsschaltung muss ich mir irgendwann noch mal genauer 
ansehen. Vermutlich wird die besser sein...

Noch mal zu dem Senden auf dem EMS-Bus.

Habe gerade noch mal im Log mit Polling einen kleinen Ausschnitt gesehen 
dass die RC30 bei mir erst das Telegramm sendet und dannach dann eine 
leere Antwort. (0x10 <Break>)

Also beendet die RC30 Ihre Buskontrolle mit einem eigenen leeren 
Telegramm am Ende.

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne
> ich das am besten in der Software? Warten bis ein Break auf dem Bus
> auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann
> einfach lossenden?

Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt, 
danach kannst du das nächste Zeichen senden oder eben ein Break für die 
Busfreigabe von deiner Seite.

Das sollte in etwa so aussehen:

RX: 8B BRK
TX: 08
RX: 08
TX: Zeichen
RX: Zeichen
....
TX: BRK
RX: BRK


Grüße.

von IngoF (Gast)


Lesenswert?

Rudi schrieb:
> Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt...
Stimmt.. ist wohl in der Textflut untergegangen :)

Ingo F. schrieb:
> Das Telegramm was man sendet muss man zwischen den Bytes eine Pause...

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt,
> danach kannst du das nächste Zeichen senden oder eben ein Break für die
> Busfreigabe von deiner Seite.

... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem 
nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt?


//Niffko

von Ingo F. (ingof)


Angehängte Dateien:

Lesenswert?

Niffko _ schrieb:
> ... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem
> nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt?

Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind 
kein Problem:
Beitrag "Re: Logamatic 2107 Schnittstelle" (Bild1)

Also Pausen von 190ms gibt es mehrere, 200ms habe ich noch keine 
gesehen. Bei mir jeweils bei der RC30 die solche Pausen einlegt.

von Niffko _. (niffko)


Lesenswert?

Ingo F. schrieb:
> Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind
> kein Problem:

ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x 
Delay senden, anstatt extra den Bus zu überwachen.


//Niffko

von Rudi (Gast)


Lesenswert?

Gesundes neues Jahr erstmal ;-)


Niffko _ schrieb:
> ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x
> Delay senden, anstatt extra den Bus zu überwachen.

Besser wäre senden und auf RX warten mit einem Timeout. Wenn das 
empfangene Byte nicht identisch zum gesendeten Byte ist, musst du auf 
das nächste 0x8b BRK warten, ansonsten kann die Anlage in eine Störung 
gehen -> keine Heizung ;-). Ein Delay wäre dann nicht mehr notwendig und 
mit einem RX-Timeout wärst du auch gleich schneller beim Senden, da der 
Master in der Regel relativ schnell antwortet.

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> Besser wäre senden und auf RX warten mit einem Timeout.
Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein 
Byte, der Master repeatet und bevor ich das nächste Byte sende, warte 
ich auf ... was? Könntest Du mich da noch mal erhellen?

Rudi schrieb:
> ... ansonsten kann die Anlage in eine Störung
> gehen -> keine Heizung ;-).
... glaube ich nicht, das würde die CRC dann schon richten.


//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x

So groß muss das Timeout ja nicht sein. Meistens kommt die Antwort ohne 
Pause oder unter einer Bitlänge. Zwei Bit reicht immer.

Mann müsste einfach sofort das Byte einlesen und vergleichen. Das ist 
vermutlich einfacher als ein Delay. Bei einem Fehler sofort mit Break 
abbrechen und nochmal neu senden. Denke das dürfte kein Problem sein. Ab 
und zu senden die Busteilnehmer ja auch zwei Telegramme hintereinander.

Meine RC30 habe ich schon mal im Log dabei erwischt wie sie ein 
Telegramm widerholt hat :o)

Bei einem erneuten Fehler würde ich dann aufs zweite Polling warten.

Rudi schrieb:
> Besser wäre senden und auf RX warten mit einem Timeout.

Na das ist eine gute Idee. Hätte erst mal keins eingebaut.

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein
> Byte, der Master repeatet und bevor ich das nächste Byte sende, warte
> ich auf ... was? Könntest Du mich da noch mal erhellen?

Ups die Antwort hatte ich noch nicht gesehen..

Sicherlich würde es reichen auf 12Bitlängen zu warten. Würde ich aber 
nur als Notlösung ansehen.
Am besten auf die Widerholung warten. Wenn nach zwei Bitlängen keine 
Antwort kam unterwegs ist dann abbrechen und noch mal neu senden. 
vermutlich bekommt man aber nicht mit wenn der UART schon ein Bit 
empfangen hat.

Als Timeout wurde ich dann 14 (vielleicht 15) Bitlängen nehmen falls die 
MC10 mal nichts wiederholen sollte.

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> und bevor ich das nächste Byte sende, warte
> ich auf ... was?

Vielleicht noch genauer auf Deine Frage. Wenn der Master wiederholt dann 
einfach das nächste Byte senden. Rudi meinte das Timeout für den Fall 
das der Master nicht antwortet.

Gruß
Ingo

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Rudi meinte das Timeout für den Fall
> das der Master nicht antwortet.

Ah jetzt ja ... das war der entscheidende Hinweis, danke. Wobei es bei 
mir nicht so tragisch wäre, wenn ein Telegramm mal nicht ankommt, da ich 
sie für die Leistungssteuerung eh' periodisch versende.


//Niffko

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

Hallo Leute,

nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene 
Lösungen.
Die Grundidee ist, zur Signalgewinnung den internen Analog Comparator 
eines AVR's zu nutzen und diesen dann mit einer Soft-UART mit FIFO zu 
verheiraten. Letzteres stellt in sofern kein Problem dar, da es 
Soft-UART Lösungen gibt, die über Input Capture eines Timers getriggert 
werden und der Ausgang des Analog Comparators so konfiguriert werden 
kann, dass er besagten Input Capture auslöst.
Die Vorteile liegen auf der Hand: der externe Comparator entfällt und 
man hat den Hard-UART für die Kommunikation mit dem PC frei. Da man zur 
Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART 
diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe 
Anhang.
Empfehlenswerter Soft-UART mit FIFO:
Beitrag "Software UART mit FIFO"


//Niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
>> ... ansonsten kann die Anlage in eine Störung
>> gehen -> keine Heizung ;-).
> ... glaube ich nicht, das würde die CRC dann schon richten.

Jein, wenn du die anderen Teilnehmer zu oft störst, werden diese einfach 
abgemeldet und die Anlage geht auf Störung, wenn z.B. der Brenner 
verschwunden ist. Aus diesem Grund muss auch jedes z.B. 0x8B BRK 
beantwortet werden. Die genaue Anzahl der tolerierten Fehler kenne ich 
nicht, müsste man mal austesten.


Niffko _ schrieb:
> Da man zur
> Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART
> diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe
> Anhang.

Damit verbaust du dir eine Entkopplung von E-Heizungskreis und 
E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf 
digitale Signale so einfach wie möglich halten, sprich über eine passive 
Schaltung.

Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede 
Flanke/jedes Bit vergoldet wird.



Grüße.

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene
> Lösungen.

Eigentlich auch eine gute Lösung.
Allerdings ist mir ein externer Komperator doch irgendwie lieber. Und 
sooo viel kostet der auch nicht.

Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend 
wieder reinnehmen. Wenn der Bus verpolt angeschlossen wird gibt es zwei 
Probleme:

1) Der Komperator funktioniert nicht wie gewünscht.
2) Die BAT46 schließt den EMS-Bus kurz.

Habe keine Ahnung was die BAT46 soll. Vermute mal dass sie die Schaltung 
vor Überspannungen vom EMS-Bus schützen soll.

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe mir jetzt nochmal einige unbekannte Werte vom EMS-Bus 
angesehen. Erkennt jemand den Zusammenhang von Nachricht:

08 00 19 Index 13

und der Brennerleistung

08 00 18 Index 8 ?

Anbei ein Plot der beiden Werte.

von Niffko _. (niffko)


Lesenswert?

Hi Rudi,

das sieht mir nach der Modulation der internen Gerätepumpe aus. Wird in 
Prozent angegeben, bezieht sich auf die Drehzahl und wird abhängig von 
der Brennerleistung variiert. Wenn ich mich richtig erinnere ist die 
minimale Pumpenmodulation bei deinem Gerät 55% - sollte also passen.

//Niffko

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> Jein, wenn du die anderen Teilnehmer zu oft störst,
ok ... stattgegeben.


> ... werden diese einfach abgemeldet und die Anlage geht auf Störung,
Was wiederum nicht so tragisch wäre. Kommunikationsfehler generieren im 
EMS-System nur blockierende Störungen, keine verriegelnden. D.h. die 
Anlage geht nach Wiederherstellung der Kommunikation wieder in Betrieb. 
Hilft natürlich nicht wenn die Störungen im Minutentakt auftreten ... 
schon klar.


> Aus diesem Grund muss auch jedes z.B. 0x8B BRK beantwortet werden.
hmm ... 0x8B wird bei mir definitiv nicht beantwortet.



> Damit verbaust du dir eine Entkopplung von E-Heizungskreis und
> E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf
> digitale Signale so einfach wie möglich halten, sprich über eine passive
> Schaltung.
Wobei letzteres aufgrund der geringen Strombelastbarkeit ja 
offensichtlich nicht so einfach ist. Mal abgesehen davon, dass in meinem 
Fall eine Trennung nicht notwendig ist (Heizungsregelung), was spricht 
dagegen, den Sklaven in das Heizungsnetz zu integrieren und von ihm aus 
entkoppelt zu kommunizieren?


> Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede
> Flanke/jedes Bit vergoldet wird.
Hast' ja prinzipiell recht, wird aber durch einen interrupt-beschickten 
FIFO schon deutlich entschärft. Außerdem läuft man dann nicht Gefahr, 
dass der AVR beim Empfangen und Weiterleiten der 9600baud Daten, an 
Langeweile stirbt.

IngoF schrieb:
> Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend
> wieder reinnehmen.
Komm schon ... Du machst hier mit Mikrocontrollern rum und willst mir 
erzählen, dass du die Polarität von zwei Leitungen nicht vor dem 
Anschließen feststellen kannst. Wenn Buderus Brückengleichrichter 
einbaut, dann deshalb, weil die Verdrahtung von Heizungsbauern 
vorgenommen wird ... wenn Du weißt was ich meine.



//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> hmm ... 0x8B wird bei mir definitiv nicht beantwortet.

OK... dann aber eben dass Polling für das Modul dass Du emulieren 
möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel 
seltener gepollt und musst länger auf das versenden der Nachrticht 
warten.

Vielleicht ignoriert auch die MC10 Telegramme die von einem 
"unbekannten" Busteilnehmer kommen.

Niffko _ schrieb:
> ... dass du die Polarität von zwei Leitungen nicht vor dem
> Anschließen feststellen kannst.

Sicher bin ich dazu fahig. Macht aber die Sache einfacher mit 
Gleichrichter. Anstöpseln und fertig.

Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt 
wenn man verpolt.

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> OK... dann aber eben dass Polling für das Modul dass Du emulieren
> möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel
> seltener gepollt und musst länger auf das versenden der Nachrticht
> warten.
ja, weiß ich doch. Hatte bloß in Rudis Text das 0x8B im Kontext mit 
Brenner gelesen und dann hätte es bei mir auch als Antwort auftauchen 
müssen.


> Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt
> wenn man verpolt.
Nö, die bleibt drin ;-). Scheint als schnelle Clamp-Diode gegen negative 
Spikes gedacht zu sein. Ich denke hier muss der jeweilige Anwendungsfall 
betrachtet werden. Wenn das Interface ständig an- und abgestöpselt wird, 
kann man sicherlich über einen Brückengleichrichter reden. In meinem 
Fall wird einmal angeschlossen und gut is'. Deshalb hatte ich in meinem 
Post auch extra geschrieben: "als Anregung für eigene Lösungen".



//Niffko

von Niffko _. (niffko)


Lesenswert?

Niffko _ schrieb:
> das sieht mir nach der Modulation der internen Gerätepumpe aus.

@Rudi
Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es 
ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei 
Dir (GB152) nicht im Monitor angezeigt wird.


//Niffko

von Fred G. (sysrun)


Lesenswert?

Dieses "BusEcho" lässt mir ja irgendwie keine Ruhe. Warum existiert 
dieses Echo nur wenn man über die Servicekey-Schnittstelle etwas sendet? 
Ich habe dieses Echo noch nicht einmal bei anderen Stationen gesehen. 
Oder täuscht mich das?

Ich habe folgende Komponenten:

MC10 Master-Controller (0x08) (UBA3) (Also die "Backplane" des Systems 
und Busmaster)
BC25 Basis-Controller (0x09)
RC35 Raum-Controller (0x10)

Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das 
genau ein einziges mal. Keine Wiederholungen vom MC10.

In den Buderus Planungsunterlagen für EMS ist ein Busdiagram. Im Zentrum 
steht der MC10 als Master. Von dort sieht man einen EMS-Baum wo die 
ganzen Zusatzmodule wie RC35, RC25, EM10, MM10 etc angeschlossen sind.

Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25 
angeschlossen ist.

Und an diesen Modulen hängt ja der ServiceKey.

Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum 
Internen EMS-Bus auftritt und diese "Echos" nur auf die 
ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise 
nicht vom BusMaster generiert sondern vom BasisController BC10/25.

Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen 
Modulen?

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das
> genau ein einziges mal. Keine Wiederholungen vom MC10.
Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte 
für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du 
nicht sehen können, da diese mit deutlich geringerer Amplitude senden.

Fred Granna schrieb:
> Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum
> Internen EMS-Bus auftritt ...
Ein klares Jain. Ich habe bereits die Interna von BC10, UBA und MC10 in 
Augenschein nehmen können - die dicken Transistoren hängen nur bei UBA 
und MC10 am Bus. Beim BC25 sieht die Sache aber anders aus, in ihm sind 
sozusagen BC10 und UBA vereint.


//Niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es
> ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei
> Dir (GB152) nicht im Monitor angezeigt wird.

Danke! Im Monitor wird der Wert nicht angezeigt.


Fred Granna schrieb:
> Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25
> angeschlossen ist.

Richtig, der ServiceKey bekommt noch 12V VCC, also ein 3-Draht-Bus und 
kein 2-Draht-Bus.


> Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum
> Internen EMS-Bus auftritt und diese "Echos" nur auf die
> ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise
> nicht vom BusMaster generiert sondern vom BasisController BC10/25.

Nein, wie ich weiter oben schon geschrieben hatte: Der Klinkenstecker 
hängt mit den 2 Leitungen (GND,DATA) direkt am internen EMS-Bus.


Fred Granna schrieb:
> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das
> genau ein einziges mal. Keine Wiederholungen vom MC10.

Du siehst die Wiederholung. Als TX-Slave arbeitet das ganze als 
Stromschnittstelle und als RX-Slave Level-Sensitiv. Dreh mal dein Oszi. 
auf dann siehst du es.

von Fred G. (sysrun)


Lesenswert?

Niffko _ schrieb:
>> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das
>> genau ein einziges mal. Keine Wiederholungen vom MC10.
> Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte
> für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du
> nicht sehen können, da diese mit deutlich geringerer Amplitude senden.

Das würde ja bedeuten, das wenn ich zu heftig in den Bus schreie, die 
anderen Module alle Zeichen doppelt empfangen und daher nur Müll 
zurückkommt?

Das würde evtl. erklären warum meine Antworten auf das Polling "0x8B" 
funktionieren, die Kommunikation mit anderen Modulen aber nicht.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> ... dass wenn ich zu heftig in den Bus schreie ...

ich denke, dein 'Umgangston' würde sich, durch den Austausch der Z-Diode 
in Deiner Senderstufe gegen einen 220R Widerstand, erheblich verbessern 
;-)


//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> .....durch den Austausch der Z-Diode
> in Deiner Senderstufe gegen einen 220R Widerstand.....

Ja, das wird es garantiert ändern.

Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link 
bringe:
Beitrag "Re: Logamatic 2107 Schnittstelle"

Auf dem ersten Bild kann man gut das Polling von der MC10 an die RC30 
sehen.
Die MC10 brüllt rum und dann ein kleines flüstern von der RC30 das dann 
die RC30 noch mal in den letzten Winkel brüllt. Der Rest der Antwort 
kommt dannn von der RC30 nach etwa 100ms wenn sich die RC30 wieder 
gesammelt hat. Was dann genauso wie auch das Break widerholt wird.

Wenn man eine zu kleine Z-Diode nimmt und die Spannung noch tiefer als 
die MC10 herunter zieht gibt es teilweise richtige Ausfälle am Bus Bei 
der nach dem Break noch ein 0xFE gesendet wird. Ob das jetzt eine 
Absichtliche Fehlermeldung oder eine Fehlfunktion kann ich nicht 
beurteilen.

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

IngoF schrieb:
> Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link
> bringe:

Dann darf ich aber auch mal ;-)

Beitrag "Re: Logamatic 2107 Schnittstelle"

von Fred G. (sysrun)


Lesenswert?

Okay, also vereinfacht gesagt:

Keiner Spricht direkt sondern immer über den Chef.
Jeder flüstert dem Chef was zu wenn er dran ist (Aufforderung kommt vom 
Chef) und der wiederholt das Laut so das es dann alle hören.

von IngoF (Gast)


Lesenswert?

Rudi schrieb:
> Dann darf ich aber auch mal ;-)

Tja, der Thread ist ja schon etwas länger... Da kann man noch viel 
ausgraben was inzwischen schon fast untergegangen ist.

Fred Granna schrieb:
> Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen
> Modulen?

Wenn man nicht mit einem Oszilloskop auf dem Bus hängt ist es auch nicht 
soo leicht dies mit zu bekommen. Das Problem ist dass der größte Teil 
von der Adresse 0x08 kommt und die MC10 sich selber natürlich nciht 
widerholt. Wenn das jemand selber nachvollziehen möchte kann am besten 
am Oszilloskop die Triggerschwelle knapp über die Maximale Spannung 
stellen und triggert dann auf das Überschwingen.

So jetzt werde ich mal lieber wieder an meiner Software spielen und 
versuchen mich hier zurück zu halten.

von Fred G. (sysrun)


Lesenswert?

Ich peil es nich. Kann mir kurz einer schildern was für z.B. senden muss 
um z.B. eine Versionsabfrage an ein Modul zu richten?

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Ich peil es nich. Kann mir kurz einer schildern was für z.B. senden muss
> um z.B. eine Versionsabfrage an ein Modul zu richten?

0x0B 0x10 0x02 <CRC>

Ansonsten schalte deine Anlage aus/ein und schau dir die ersten 
Nachrichten an.

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:
> Ansonsten schalte deine Anlage aus/ein und schau dir die ersten
> Nachrichten an.

Hm, darauf hät ich auch kommen können facepalm

bzgl. Sendepfad:

Ich hab mir nun das hier zum Vorbild genommen: 
Beitrag "Re: Logamatic 2107 Schnittstelle"

Ich invertiere mein UART-TX über nen OpAMP und denn auf einen Transistor 
der zieht den Bus über 220 Ohm auf Masse.

Zwei Fragen dazu:
- Wozu ist der 4K7 PUllup dort?
- Ist der 1,5n Kondensator wichtig?

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Zwei Fragen dazu:
> - Wozu ist der 4K7 PUllup dort?

Damit der Transistor einen ordentlichen Pegel sieht, falls mal nichts 
passiert oder der OP nicht beschaltet ist (dauersenden).

> - Ist der 1,5n Kondensator wichtig?

Rechnen das mal durch (Tiefpass), siehe:

http://de.wikipedia.org/wiki/RC-Glied

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

Die Kurve für den Tiefpass sieht in etwa so aus. Ich denke die hohen 
Frequenzen der Anlage (CPU etc.) sollen sich nicht durch das ganze Haus 
verteilen ;-)

von Fred G. (sysrun)


Lesenswert?

Hm, ich glaub meine CRC-Berechnung haut nicht hin.

Habe diese Funktione hier genommen: 
Beitrag "Re: Logamatic 2107 Schnittstelle"

Und dann mal probiert:

uint8_t tempbuffer[]={0x10,0x21,0xac,0x0,0x0,0x0,0x0};
uint8_t crc=buderus_ems_crc(tempbuffer,7);

da bekomme ich als CRC: 0x0D

Laut dem hier müsste es aber 0x1A sein oder?
Beitrag "Re: Logamatic 2107 Schnittstelle"

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Hm, ich glaub meine CRC-Berechnung haut nicht hin.

Und ich weiss das sie funktioniert ;-)

Versuch mal Länge 8 und nicht 7. Die Berechnung geht von der Datenlänge 
mit CRC aus.

von Fred G. (sysrun)


Lesenswert?

Jo, hab ich auch zur sekunde festgestellt.

Bekomme aber trotzdem keine Antworten...

Befürchte das da mit dem Timing was nicht hinhaut. Denke mal mit meinem 
i2c-UART am EMS-Bus kann ich das ganze vergessen. Hat hier einer von 
euch spezis nen bissl C-Code zum durchforsten für mich? Ihr seit doch da 
bestimmt schon weiter als ich...

von Fred G. (sysrun)


Lesenswert?

Moin,

hat eigentlich schon jemand eine richtige Abfrage auf den EMS-Bus 
gemacht? Ich meine jetzt nicht einfach ein Byte auf eine Pollinganfrage 
senden :)

von Fred G. (sysrun)


Lesenswert?

Mal ein paar Tests:

Ich warte jeweils auf "0x8B <brk>". Nach meinen Telegrammen sende ich 
jeweils "0x08 <brk>" zum Abschluss


Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 0x2 0x00 0x3E <brk>" und bekomme "80 0B <brk>"
Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 0x0 <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 <brk>" und bekomme "80 0B <brk>".

von Rudi (Gast)


Lesenswert?

Versuch doch mal:

0B 88 02 00 06 <crc>

von Fred G. (sysrun)


Lesenswert?

Ich sende "0B 88 02 00 06 9A"
Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00"

uff O.O

Warum geht das? Was bedeutet die 0x06 vorm CRC?

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Warum geht das?

Wie schon einmal gesagt, schalte deine Anlage aus/ein und schau dir die 
initialen Nachrichten an .........

> Was bedeutet die 0x06 vorm CRC?

K.A., evtl ein Index.


Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:
> Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?

Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Ich sende "0B 88 02 00 06 9A"
> Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00"

Gratuliere!
Darf ich fragen, mit welchem Prozedere du sendest - ich meine im 
Speziellen die Pausen zwischen den Bytes?


//Niffko

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
>> Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?
>
> Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram.

Das sehe ich. Mich wundert nur die Länge der Antwort. Bei mir sieht es 
so aus wenn die 0x10 anfragt:

10 88 02 00 06 33
08 10 02 00 40 03 02 3d

von Fred G. (sysrun)


Lesenswert?

Niffko _ schrieb:
> Darf ich fragen, mit welchem Prozedere du sendest - ich meine im
> Speziellen die Pausen zwischen den Bytes?

Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter 
bis ich das "echo" vom Master habe.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter
> bis ich das "echo" vom Master habe.

Joa ... danke!



Rudi schrieb:
> Mich wundert nur die Länge der Antwort. Bei mir sieht es
> so aus wenn die 0x10 anfragt:
>
> 10 88 02 00 06 33
> 08 10 02 00 40 03 02 3d

Bei mir sieht's so aus (UBA3 V2.07):

10 88 02 00 09 3C
08 10 02 00 40 02 07 3A

UBA3 und UBA4 haben technisch gesehen nicht mehr viel gemein, daher 
evtl. die unterschiedlichen Antworten.


//Niffko

von Fred G. (sysrun)


Lesenswert?

Mich würde ja interessieren was der ServiceKey intern so alles anstellt.

- Der Servicekey empfängt die Anfrage
"04 08 02"

-- Der Key sendet auf dem Bus
"0B 88 02 00 06 <crc> <brk>"

-- Der Key empfängt vom Bus
"08 0B 02 00 7B 04 05 00 00 00 <crc> <brk>"

- Der Key sendet zur Software
"04 08 02 00 7B 04 05 00 00 00".

Man bräuchte mal einen parallelen Log vom ServiceKey und vom EMS-Bus um 
mal zu sehen was da wie angestellt wird...

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Mich würde ja interessieren was der ServiceKey intern so alles anstellt.

Also zumindest packt er auch mehrere Teiltelegramme zusammen oder 
splittet die. Das Telegramm 0x3f besteht beim Service-Key aus etwa 100 
Byte.

Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das 
Offset.

Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab. 
Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04.

Mich würde auch mal ein paralleles Log interessieren. Nur bräuchte 
irgendjemand einen Service-Key und gleichzeitig eine Möglichkeit die 
Daten aufzuzeichenen. Für das Log würde es ja auch reichen wenn man dies 
mit einem Programm wie hTerm z.B. Hexadezimal evtl mit dem Zeitstempel 
mitloggt.

Eigentlich muss mann nicht unbedingt eine großartige Empfangsschaltung 
haben. Es reicht aus Die Masse (Pin 5) von der Seriellen Schnittstell 
auf die 12 Volt von der Service-Key Buchse zu gehen und die Daten auf 
die Empfangsleitung der Schnittstelle (Pin 3). Oder umgekehrt.

Am besten mit einem Laptop das keine Verbindung zum Stromnetz hat.

Habe das damals auch gemacht und keine Probleme damit gehabt.
Dadurch hat man dann einen Signalpegel von +-2,5Volt. Eigentlich 
benötigt man mindestens  +-3 bis +-12Volt als Pegel. Hat bei mir aber 
einwandfrei funktioniert.

Was dies 0x00 0x06 soll interesssiert mich auch. Eigentlich wäre das 
Offset 0 mit den Daten 0x06. Es gibt auch viele Telegramme von der RC30 
(0x10, 0x11) die auch irgendwelche Daten an die MC10 senden. Vermute mal 
das sind irgendwelche Parameter/Stellwerte für die Heizungsregelung.

Hatte bei mir gestern schon mal das simple beantworten der 0x8b mit 0xb 
programmiert und werde dann in der nächsten Zeit endlich auch mal 
"echte" Sendeversuche unternehmen können wenn ich dazu Zeit finde.

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

IngoF schrieb:
> Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das
> Offset.
>
> Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab.
> Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04.

Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder 
hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät> 
0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und 
dann daraus geholt werden?

Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe 
vorhin mit dem Offset vor der CRC ein wenig gespielt; die Heizung hat 
dann plötzlich nen Fehler ausgegeben...

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe

Das stimmt. Ohne Log geht garnichts. Würde aber vermuten dass der 
ServiceKey alles im Speicher vom anfang an mitpuffert und dann nur noch 
Änderungen überwacht und diese dann über die serielle Schnittstelle 
mitsendet. Vielleicht werden ja auch mal am Anfag alle Telegramme 
abgefragt ohne dass sich die Logasoft dies anfragt. Und wenn eine 
Anfrage auf ein spezielles Telegramm kommt aus dem Speicher sendet. 
Vielleicht hängt das auch vom Telegrammtyp ab wie er sich verhält....

Wollte ja eigentlich auch nur sagen dass ein Log auch jeder ziehen kann 
der eine zweite serielle Schnittstelle frei hat und sich nur ein Kabel 
RS232 auf Klinke basteln muss. (1x Service-Key und 1x Diagnose-Buchse)

Vermute mal dass jemand der einen ServiceKey hat sich nicht noch extra 
irgend eine Schaltung zusammenlötet oder sogar irgendwas programmiert..

von Rudi (Gast)


Lesenswert?

Also wir haben jetzt bei einem Telegramm schon mehrere Möglichkeiten:

UBA3 V3.2
---------
10 88 02 00 06 33
08 10 02 00 40 03 02 3d

UBA3 V2.7
---------
10 88 02 00 09 3C
08 10 02 00 40 02 07 3A

UBA4 V4.5 / keine Erweiterung
-----------------------------
0B 88 02 00 06 9A
08 0B 02 00 7B 04 05 00 00 00 FC

UBAX V 2.4 / SAFE 2.20 / keine Erweiterung
------------------------------------------
TX: 04 08 02
RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00

Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?

von IngoF (Gast)


Lesenswert?

Also mit dem Offset einfach so herumexperimentieren werde ich mich erst 
mal nicht trauen :-) Wer weiss denn schon was man da so alles verstellen 
kann...

Für mich reicht erst mal wenn ich die Telegramme mitlogge und nur die 
Schaltzeiten verändern kann. Also dass mein Server dynamisch die Zeiten 
ändern kann. Z.B. wenn ich schon weiss dass der Arbeitstag länger dauern 
wird eine eMail an meinen Server schicken und der ändert die Heizzeiten. 
Vielleicht auch schnell mal für ein Jahr im vorraus meinen Urlaub 
eintrage und alles automatisch umgestellt wird :o)
Und natürlich dass ich sehen kann was meine Heizung denn da so 
veranstaltet und sich irgendwie Energie einsparen lässt.

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder
> hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät>
> 0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und
> dann daraus geholt werden?

Alle Module haben ein EEProm mit festen Daten und volatile Daten 
(Temperaturen etc.). Wie diese beiden Datentypen unterschieden werden 
ist nun die große Frage.
Der ServiceKey wird sich wohl alle EEProm Daten von den Modulen holen 
und speichern. Die volatilen Daten bzw. die nicht volatilen Daten die 
geändert werden (z.B. durch die RC3X) bekommt er direkt vom Bus.

von IngoF (Gast)


Lesenswert?

Rudi schrieb:
> Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?

Das könnte ein Platz für eine weitere Versionsnummer (Erweiterung?) 
sein. Die MC10 übermittelt ja seine eigene Version und die SAFe-Version. 
Die Seriennummer scheinen ja immer aus drei Byte sein
1
RX: 04 08 02 00  H  MC10        2.04  48 02  04 4B 02 14 00 00 00      
2
                 K  SAFe        2.20            4B 02 14

von Fred G. (sysrun)


Lesenswert?

Weiter Probiert mit "Offset"; sehr interessant:

"0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"
"0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"
"0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F"
"0B 88 02 00 05 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 7E"
"0B 88 02 00 06 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 FC"
"0B 88 02 00 08 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 DB"
"0B 88 02 00 10 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 00 
03 44"

Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)

von IngoF (Gast)


Lesenswert?

Rudi schrieb:
> Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?

Kann es vielleicht sein dass sich die MC10 je nach Absender anders 
verhält?

Beides mal wenn die 0x00 0x00 0x00 auftaucht war die Adresse 0x0b im 
Spiel. bei der 0x10 sind die nciht aufgetaucht. Die untere UBA wird 
vermutlich auch eine UBA3 sein. Die Version liegt ja genau in dem 
Bereich von den anderen beiden UBA.

Keine Ahnung ob da was dran ist..

von Fred G. (sysrun)


Lesenswert?

YEAH!

"0B 88 18 0 255 <crc>" => "08 0B 18 00 3C 02 77 64 17 09 01 25 40 80 00 
02 32 80 00 00 7A FF 2D 48 00 C8 00 02 00 B1 00 0D"

:-D

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)

Die maximale Antwortslänge ;-)

09 88 04 05 01 af
08 09 04 05 19 cb

10 88 04 00 0c 21
08 10 04 00 04 1b 03 40 18 19 30 00 00 69 6b 0c 5d

von Andreas F. (Gast)


Lesenswert?

Mensch so langsam wird das ja konkret.
Ich lese so nebenbei mit. Habe schon ein schlechtes Gewissen, weil ich 
nen Servicekey besitze aber momentan keine Möglichkeit zum mitloggen 
habe. Mist.

von Fred G. (sysrun)


Lesenswert?

Und jetzt pass auf:

"0B 88 18 03 01" => "08 0B 18 03 64 DA"

Das ist auslesen eines Registers:

18 = Register
03 = Offset (Start)
01 = Anzahl der Zeichen die gelesen werden

Also lese ich aus Register 18 das dritte Zeichen

von Rudi (Gast)


Lesenswert?

@Fred Granna

Kannst du mal versuchen ob es sich bei dem dritten und vierten Byte um 
einen Offset in einen statischen Speicher handelt ?


10 88 15 00 05 <crc>
10 88 1c 00 0b <crc>

Und dann mal bei der 0x15 schauen ob du die Antwort der 0x1c durch 
ändern der Längenangabe mit empfängst.

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:
> 10 88 15 00 05 <crc>
= 08 0B 15 00 00 3C 01 01 09 <FE>

- 10 88 15 00 10 <crc>
= 08 0B 15 00 00 3C 01 01 09 48 00 00 <86>

> 10 88 1c 00 0b <crc>
= 08 0B 1C 00 00 00 00 00 00 00 00 00 00 00 00 <97>

Oder hab ich die Frage nicht richtig verstanden?

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)

IngoF schrieb:
> Also mit dem Offset einfach so herumexperimentieren werde ich mich erst
> mal nicht trauen :-)

Also bei der Seriennummer kann vermutlich nicht viel passieren...

Fred Granna schrieb:
> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)

Hey, bitte sagen falls ich hier herumtrolle....

Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das 
ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe. 
Wenn mann z.B. beim ersten Telegramm nur die Datenbytes zählt kommt mann 
auf 26 = 0x1A. Das nächste Telegramm fängt mit 0x1B im "Offset" an.

in der Zeile darunter mit dem RX: das Telegramm von Chris_be was ich aus 
seinen Logs zusammengestellt habe...

Ich finde diese beiden Telegramme sehen doch sehr gleich aus.. Ist das 
nur Zufall??

Allerdings scheint es auch wohl teilweise andere Bedeutungen zu haben. 
Vielleicht ist das nach Sollwerten, Veränderlichen Daten oder 
Seriennummern anders.

Bei dem Telegramm 0x10 und 0x11 sind das Telegramme von der RC30 an die 
MC10. vielleicht ist dass dann dort kein Offset und ist vielleicht ein 
Befehl. Was mich daran stört ist dass die Antwort unterschiedlich lang 
ausfällt.

Dann noch das "Versionsnummernproblem" warum wird da bei einigen die 
0x06 und bei anderen 0x09 an das "Offset" 0x00 gesendet??? Ist das ein 
Befehl, EIne Prüfsumme?? Was soll das? Dort scheint es kein Offset zu 
sein.

Hoffe ich kann mit meinen "Spekulationen" helfen...

Gruß
Ingo

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Oder hab ich die Frage nicht richtig verstanden?

Doch, alles okay. Das scheint so nicht zu funktionieren. Es wird wohl 
wie bei ECO-CAN über Typen gehen, also was du als Register bezeichnest 
und einen Offset, den es bei ECO-CAN auch gibt.

von IngoF (Gast)


Angehängte Dateien:

Lesenswert?

IngoF schrieb:
> Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das
> ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe......

Sorry, glatt das wichtigste vergessen.. Hier die dazugehörigen Daten als 
TXT-Datei:

von Rudi (Gast)


Lesenswert?

IngoF schrieb:
> Hoffe ich kann mit meinen "Spekulationen" helfen...

Es ist ja nicht so das wir die Daten nicht ändern können, es soll nur 
etwas komfortabler werden ;-). Am besten hält man sich erst einmal an 
die RC3X, so wie die die Daten ändert. Bisher hat sich leider noch 
niemand die Mühe gemacht das Protokoll für die Änderungen zu erfassen.

von Fred G. (sysrun)


Lesenswert?

@ingo

Ich habe eben mal eine Zeile aus deinem Log genommen:
{52} 19:49:38 06.01.11: 10 88 11 18 1B 52
{CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00 
CF

Habe dann gesendet "11 88 11 18 1B <crc>"
Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"

Dann "11 88 11 18 1C <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"

Und "11 88 11 18 05 <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"

Und "11 88 11 00 1B <crc>"
Resultat "08 0B 11 00 00 00 00 00 00 00 00 00 00 00 00 00 48 00"

von Rudi (Gast)


Lesenswert?

@Fred Granna

Hast du deine Anlage nicht programmiert (Heizzeiten) ?

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> "0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"
> "0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"
> "0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F"

> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)

ALso das Offset meinte ich mit dem dritten Byte was bei Dir immer 0x00 
ist.

Aber das Byte dannach ist wohl die Antwortlänge. Allerdings scheint die 
MC10 das nach Belieben anzupassen. Die 0x02 ist der MC10 zu wenig 
gewesen und hat dann einfach 3 Datenbyte gesendet.

Bei den Seriennummer

Rudi schrieb:
> UBA3 V3.2
> ---------
> 10 88 02 00 06 33
> 08 10 02 00 40 03 02 3d
>
> UBA3 V2.7
> ---------
> 10 88 02 00 09 3C
> 08 10 02 00 40 02 07 3A

Bei den Seriennummern wurden nur 3 Datenbyte gesendet obwohl einmal 6 
und einmal 9 Datenbyte abgefragt wurden.

Fred Granna schrieb:
> 18 = Register
> 03 = Offset (Start)
> 01 = Anzahl der Zeichen die gelesen werden
>
> Also lese ich aus Register 18 das dritte Zeichen


ALso da bin ich nicht mit zufrieden.. ich stimme für Telegramm 0x18 also 
die schnell veränderbaren Messwerte.

Könnt Ihr denn mal vergelichen ob das mit dem Offset auch wirklich 
stimmt?
Wenn ich richtig verstanden habe sind die Daten die dann gesendet 
identisch mit den Daten aus dem letzten Telegramm 0x00 ab dem Offset 
0x03??

Gruß
Ingo

Fred Granna schrieb:
> Ich habe eben mal eine Zeile aus deinem Log genommen:
> {52} 19:49:38 06.01.11: 10 88 11 18 1B 52
> {CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00
> CF
>
> Habe dann gesendet "11 88 11 18 1B <crc>"
> Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"

OK. Leider ist ja nicht bekannt was das "Telegramm" 0x10 und 0x11 
überhaupt für eine Bedeutung hat. Dass die Prüfsumme ja anders ist liegt 
an der unterschiedlichen Adresse. Oder habe ich Dich falsch verstanden?

Habe hier mal die beiden Telegramm von Chris_be:
RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 
12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 
01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00
RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A 
14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 
07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B


Wenn das ja mit dem Offset stimmt wunder mich nur warum dort bei mir 
alles 0x00 angezeigt wird und bei Crhis_be ganz andere Werte stehen...

Muss dann eine andere Hardware sein oder vielleicht sind das 
irgendwelchen geloggten Werte von der MC10 die erst nach einer 
bestimmten Laufzeit in diesen "Speicherplätzen" abgelegt werden...

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:
> Hast du deine Anlage nicht programmiert (Heizzeiten) ?

Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese 
Einstellung.

von IngoF (Gast)


Lesenswert?

Rudi schrieb:
> Hast du deine Anlage nicht programmiert (Heizzeiten) ?

Also die Heizzeiten sind doch die Telegramme 0x3f soweit ich das mal 
gesehen habe.. Oder sind das vielleicht die Temperaturen für die 
Schaltpunkte? Kann ja eigentlich auch nicht sein. es gibt doch nur 
zwei...

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese
> Einstellung.
Also bei mir ist HK1 und die Zirkulation mit einem eigenen Programm 
versehen.

Zirkulation nur morgens zwischen 5:00 und 6:00 soweit ich mich erinnere.

von Fred G. (sysrun)


Lesenswert?

IngoF schrieb:
> Habe hier mal die beiden Telegramm von Chris_be:
> RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14
> 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00
> 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00

So sieht das zerteilt aus:
04 08 10 00

34 55 02 09 89 0A 12 17 2A 00 BF 4B
34 55 02 09 89 0A 14 12 22 00 1E 4B
33 43 02 1A 86 05 10 1E 18 00 02 4B
36 4C 02 24 80 01 00 01 27 00 01 4B
36 59 01 FE 00 00 00 0F 00 00 01 4B
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

und

> RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A
> 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15
> 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B

04 08 11 00
37 41 02 26 8A 02 08 1A 25 00 01 4B
36 4C 02 05 87 0C 0A 14 22 00 01 4B
36 4C 02 05 87 0B 15 11 06 00 01 4B
36 4C 02 05 87 0B 15 07 1C 00 01 4B
36 4C 02 05 87 02 0D 0C 21 00 01 4B

Ich hab grad  weiter oben was zu den Schaltzeiten geschrieben:

Ich habe nur Zeiten für HK1 programmiert, die anderen Module übernehmen 
diese Zeit. Denke mal das wird bei dir genauso sein und daher sind die 
dann 0x00 ...

von IngoF (Gast)


Lesenswert?

Sorry, habe nicht verstanden was Du damit sagen wolltest...

Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine 
Idee mit der Zuordnung der Daten zu den Schaltzeiten hat..

Hatte Rudi so verstanden dass die 0x00 dort stehen weil Du nur einen HK 
und sonst keine Zeiten programmiert hast.

Wollte nur sagen dass ich für die Zirkulation ein eigenes Zeitprogramm 
erstellte habe und nicht von dem Heizkreis1 die Zeiten übernommen 
wurden.  Also demnach müssten dann ja bei mir andere Daten 
auftauchen....

von IngoF (Gast)


Lesenswert?

IngoF schrieb:
> Also demnach müssten dann ja bei mir andere Daten
> auftauchen....

oder besser gesagt mehr Daten... weil ich ja noch zusätzlich ein 
Schaltprogramm für die Zirkulation eingestellt habe...

von Fred G. (sysrun)


Lesenswert?

Das Ding ist: Die Logs der Kommunikation zwischen ServiceKey und PC 
helfen nur bedingt.

Beispiel:

> <TX>04 08 07 (Sendet der PC zum Servicekey)
Würde ich nun übersetzen nach "0x0B 0x88 0x07 0x00 0xFF"
Das Ergebniss: "08 0B 07 00 0B 01 00 00 00 00 00 00 00 00 00 00 00 FB"
> <RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00  (Sendet der SK zum 
PC)

Solche EInzelabfragen sind also wohl kein Problem.

Aber es gibt auch solche Anfragen an den ServiceKey:

> <TX>04 08
> <TX>04 09

Und da kommen dann 20 Verschiedene Telegramme von 0x08 und 0x09:

<RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00
<RX>04 08 18 00 26 01 BF 64 64 19 01 17 01 01 E4 83 00 80 00 02 0F FF 2D 
48 00 00 FF 00 00 00 E4 02 82 02 83 73 00 00 2C 00 00
<RX>04 08 19 00 00 59 01 98 02 61 FF FF FF 00 00 BA 78 04 7B 9E 02 EC F8 
03 BD D8 00 AB F4 00 00
<RX>04 08 02 00 48 02 04 4B 02 14 00 00 00
usw usw usw....



_Masterfrage_: Wie veranlasse ich die Module ihre kompletten Daten auf 
einmal auszugeben?

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Wie veranlasse ich die Module ihre kompletten Daten auf
> einmal auszugeben?

Also ich hatte gehofft dass das Telegramm auch auf dem EMS-Bus anwendbar 
wären...

Also:

für alle Telegramme die vorhanden sind:
0b 08 <Break>

für alle Daten zu dem Telegramm/Datentyp 0x18
0b 08 18 <Break>

für die Daten von Telegramm 0x18
0b 08 18 1B <CRC> <Break>

für die 10 Bytes ab Adresse 0x1b vom Telegramm 0x18
0b 08 18 1B 0A <CRC> <Break>

Aber leider scheint das nicht so auf dem EMS-Bus funktionieren. Die 
Hoffnung war wohl zu blauäugig..

Eventuelle muss man alle Datentypen/Telegramm aufeinmal abfragen..

Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird.

@Andreas F. (Gast)

könntest Du denn evtl. mal einen Log-Versuche starten wenn Du Zeit und 
die Möglichkeit hast?

Also die beschriebene Version mit dem Kabel habe ich am Anfang auch 
gehabt und Du benötigst keine selbstgeschriebene Software oder 
irgendwelche andere Hardware außer das Kabel.

Eventuell könnte ich Dir das Kabel zuschicken oder evtl. Eine kleine 
Testplatine mit Programm dafür erstellen und dir zuschicken. Mit der 
Hardware könnte etwas dauern. das Kabel könnte ich sofort losschicken. 
liegt hier bei mir auf dem Tisch.

Es würde für den Anfang auch erst mal ein serieller Port auch schon 
reichen.. man könnte dann zumindest sehen ob der Service-Key beim Start 
ohne EcoSoft-Programm alle Telegramme abfragt und wie er das macht..

Oder wohnt zufällig jemand mit Hardware zum loggen in Deiner Nähe?

Ich bin in der Nähe von Münster.

hatte damals auch nur ein Kabel ohne Software genommen:
Beitrag "Re: Logamatic 2107 Schnittstelle"

Gruß
Ingo

von Andreas F. (Gast)


Lesenswert?

IngoF schrieb:
> Ich bin in der Nähe von Münster.

Leider weit entfernt. Mein Nachbar fährt morgen nach Münster übers WE 
aber das hilft Dir auch nichts.

Momentan habe ich keinen verfügbaren Laptop mit geeigneter Schnittstelle 
zur Verfügung und die anderen Rechner sind wenig portabel. Ich überlege 
mal am WE, wie ich vielleicht doch was tun kann. Könnte ich die Heizung 
transportieren, stünde mir ein ganzer Meßpark zur Verfügung. Aber im 
Winter wäre meine Frau nicht wirklich begeistert.
Mhmmm

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird.

Komme gerade vom Training, sonst hätte ich schon früher Laut gegeben. 
Ich habe Service-Key, Logasoft und einen RX-Slave ... werde sobald ich 
Zeit habe die Key-Telegramme mal mitloggen.


//Niffko

von Andreas F. (Gast)


Lesenswert?

Na dann bin ich ja raus und lese entspannt weiter mit. Danke.

von Fred G. (sysrun)


Lesenswert?

So, noch nebenbei eine allgemeinere Frage zum Senden:

Mein derzeitiger Ablauf:

1. Ich warte auf "0x8B <brk>"
2.1 Nun sende ich meine Abfrage mit einem abschliessenden <brk>
2.2 Danach ein "leeres" Telegram "0x0B <brk>" als Abschluss.

Mein Problem:
Teilweise bekomme ich die erwartete Antwort. Teilweise aber auch nur 
"0x80 0x0B <brk>"

Ist das überhaupt das richtige Vorgehen zum Senden?

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Ist das überhaupt das richtige Vorgehen zum Senden?

Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen 
Ablauf mit Punkt 2.2 ?

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:
> Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen
> Ablauf mit Punkt 2.2 ?

Den hab ich mir so zusammengereimt. Ich habs nun ohne das leere 
"Abschlusstelegram" gemacht. Geht auch, ist also nicht nötig.

Ich glaube ich habe noch ein paar Timingprobleme...

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken 
lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis 
findet Ihr im Anhang.
Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft - 
hierfür bräuchte ich einen zweiten Laptop ... mal sehen.
Viel Spaß bei der Lektüre ...



//Niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> Viel Spaß bei der Lektüre ...

Der Key ist ja mehr als gesprächig ...

von Fred G. (sysrun)


Lesenswert?

Niffko _ schrieb:
> So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken
> lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis
> findet Ihr im Anhang.

Das ist ja schonmal nicht schlecht :) Kannst du da evtl. noch 
Zeitstempel mit einfügen?

> Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft -
> hierfür bräuchte ich einen zweiten Laptop ... mal sehen.

Das ist so schonmal ganz gut. So sieht man das im SK wohl eine eigene 
Logik inkl. Zwischenspeicher drinhängt.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Kannst du da evtl. noch Zeitstempel mit einfügen?

Hatte ich versucht. Das Problem ist, Hterm setzt die Zeitstempel nicht 
immer am Anfang eines Telegrammes sondern immer spätestens nach 16 Bytes 
- so zerhackt es dann immer die längeren Telegramme. Man kann die 
überflüssigen Zeitstempel zwar über 'Suchen & Ersetzen' herausoperieren, 
es fehlen dann aber immer noch die Zeitstempel die nicht gesetzt wurden.
Sollten Dich irgendwelche Zeiten im Speziellen interessieren, sag' 
Bescheid - ich schaue dann mal nach.


//Niffko

von chris_be (Gast)


Lesenswert?

Gute morgen,

ich habe eine andern PC nur Serial Comm, und habst von Conrad eine USB 
RS232 converter gekauft.
Ich habe mit die Ecosoft und Service Key geprobierd, aber kann keine 
kommunikation starten.

Ich habe die Spannungen gemessen und die sind OK, auch eine Scope 
gebraucht und kann sehen dass das Signal is nicht gleich wenn sendet bei 
RS232 port. (und dan keine antwort von ServiceKey...)

Wo habst eine gleiche setup ?

Ins driver kann ich latency, timeouts, ... parameters andern ...

vielen danke

von Andreas F. (Gast)


Angehängte Dateien:

Lesenswert?

Guten Morgen,

vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein 
wenig aufklären.

Viel Spaß weiterhin.

von Rudi (Gast)


Lesenswert?

Hallo,


Andreas F. schrieb:
> vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein
> wenig aufklären.

Danke für die Bilder. Eine Frage hätte ich da noch. Sind die beiden 
Optokoppler auf der Seite Heizung<->Schaltung oder PC<->Schaltung ?


Grüße.

von Andreas F. (Gast)


Lesenswert?

Hallo,

natürlich habe ich nun alles schön wieder zugeschraubt und alle 
Aufkleber wieder drauf. ;-(

Wahrscheinlich hilft Dir das schon weiter.

Auf Bild 1 ist der komplette Key dargestellt. Links oben ist der 
Mini-USB Stecker als Schnittstelle zum PC. Die kleine Platine links 
unten steckt über dem Controller M306...
Unter der kleinen Platine erkennt man die dicken Leiterbahnen. Dort 
werden die verschiedenen Adapter(Klinkenstecker) aufgesteckt.

Viel Spaß

von Rudi (Gast)


Lesenswert?

@Andreas F.

Okay danke. Dort wird also nur der USB-Teil galvanisch getrennt und der 
Rest der Schaltung läuft über die ServiceKey Versorgung (12V). So etwas 
habe ich mir schon gedacht.

@all

Falls es jemanden interessiert, Junkers benutzt wohl einen 
vergleichbaren Bus in ihren Geräten mit dem Namen "HT-Bus". Hier der 
Link zu den Leidgenossen:

Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle"


Grüße.

von IngoF (Gast)


Angehängte Dateien:

Lesenswert?

Hier mal meine aktuelle Sende/Empfangsschaltung.......

von IngoF (Gast)


Lesenswert?

IngoF schrieb:
> Hier mal meine aktuelle Sende/Empfangsschaltung.......

Der R6 hat da nichts zu suchen. Der hat sich irgendwann 
eingeschlichen...

von Christian S. (christianse)


Lesenswert?

Hallo zusammen!

Hab mir jetzt mal den Thread so durchgelesen.
Ich habe eine Junkers ZSB 14 Therme im Keller mit der Heatronic 3 und 
würde auch gerne Daten mitloggen und eventuell die Therme steuern.

Funktioniert die Schaltung damit oder ist es nur eine Vermutung?

Was würde ich alles dazu brauchen oder "bietet" jemand eine fertige an?

Bin zwar Elektriker aber mit Platinen/Elektronik hab ich so keine 
Erfahrung.



Liebe Grüße,
Christian.

von IngoF (Gast)


Lesenswert?

Also ich habe zumindest geplant so eine Platine als "Sammelbestellung" 
zu machen. Allerdings ist meine Hardware noch in der Entwicklung.

Evtl. würde die auch mit der Heatronic laufen. Das einzige was die 
Platine macht ist die Telegramme in ein PC-Verständliches Format zu 
bringen (0xAA 0x55 am Anfang und Ende oder eben nach 3964R)

Meine PC-Software würde nur funktionieren wenn auch das selbe 
"Protokoll" darauf läuft und die einzelnen Datenbytes die selbe 
Bedeutung haben.

Eventuelle müsste man dann noch die PC-Software selber entwickeln.

Aber erst mal abwarten wie die Telegramm/Daten denn dort eigentlich 
ausshen...

Allerdings habe ich im Moment nicht gaanz so viel zeit an der 
Hard/Software zu arbeiten.

Gruß
Ingo

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

Bin ab sofort auch unter den 'Sendenden'. Schaltung siehe Anhang. 
Basiert, wie weiter oben schon geschrieben, auf einem Soft-UART. Daher 
auch kein externer Inverter für die Ansteuerung des TX-Transistors, wird 
per SW erledigt.

Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der 
Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach 
hintereinander abfeuern. Könnte das bitte nochmal jemand testen und 
bestätigen?

@IngoF oder Rudi
Wenn ihr etwas Zeit übrig habt, könntet ihr euch das ja auch mal mit dem 
Oszi anschauen.



//Niffko

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der
> Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach
> hintereinander abfeuern. Könnte das bitte nochmal jemand testen und
> bestätigen?

Wenn es funktioniert ist es doch okay. Bei der Byteweisen TX/RX-Methode 
werden Buskollisionen schneller erkannt und der Transfer kann direkt 
abgebrochen werden. Das Vorgehen halte ich für die bessere Wahl, da wir 
keine weiteren Informationen zu diesem Bus haben (Verhalten bei 
Buskollision, Timing etc.) und die Busbelegung bei Fehlern minimiert 
wird.


Grüße.

von Fred G. (sysrun)


Lesenswert?

@Niffko

Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück?

von Rudi (Gast)


Lesenswert?

Hallo,

hier noch bei paar Oszi.-Bilder vom Bus:

Beitrag "Re: Logamatic 2107 Schnittstelle"
Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle"
Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle"

Bis auf den Master senden die Slaves immer nur ein Byte und warten auf 
das Echo.



Grüße.

von IngoF (Gast)


Lesenswert?

@Niffko

Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den 
invertierenden Komperator/OP einsparen. Beim internen UART würde Die 
Schaltung ja nicht so funktionieren...

Was würdest Du denn gerne am Oszillopgramm überprüft wissen? Also das 
Echo kommt eigentlich immer sofort am Anschluss an jedes gesendete Byte. 
Wenn man das nicht überprüfen will ist das ja auch OK. Allerdings hat 
man dann keine Ahnung ob das Telegramm verstanden wurde und muss dann 
eben auf die entsprechende Reaktion warten. Eine Garantie dass es 
verstanden wurde gibt es ja sowieso nicht.

@all

Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein 
Telgramm mit der falschen CRC auf den Bus schiebt?

Hatte ja gemerkt dass nach dem Break ein 0xFE gesendet wird wenn man 
selber mit einem Low-Pegel unter 10 Volt sendet. Vermute aber schon dass 
das nicht eine gewollte Reaktion ist und keine Fehlermeldung vom 
Busmaster.

Meine Sendehardware ist soweit auch schon betriebsbereit und 
funktioniert soweit ganz gut. Die Software sollte auch schon zu fertig 
sein, aber habe im Moment nicht Zeit daran weiter zu basteln...

Gruß
Ingo

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der
> Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach
> hintereinander abfeuern. Könnte das bitte nochmal jemand testen und
> bestätigen?

Achso.. hatte das wohl falsch verstanden...

Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst oder 
einfach das Echo ignorierst. Also wird das warten nicht nötig sein...

Oder wolltest Du wissen WANN das Echo kommt? Das Echo kommt immer sofort 
ohne große Wartezeiten oder Pausen.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück?

Kann ich (noch) nicht sagen, ich habe keine Anfragen gesendet, sondern 
eher Mitteilungen.



Rudi schrieb:
> hier noch bei paar Oszi.-Bilder vom Bus:
>
>             ...
>
> Bis auf den Master senden die Slaves immer nur ein Byte und warten auf
> das Echo.

Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt 
sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein 
Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir 
das noch nicht als 'Beweis' ;-)


//Niffko

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den
> invertierenden Komperator/OP einsparen. Beim internen UART würde Die
> Schaltung ja nicht so funktionieren...
jep ... Recht hast Du. Ist zwar etwas mehr Programmieraufwand, aber wenn 
ich dadurch Hardware einspare, ist das o.k.


IngoF schrieb:
> Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst ...
Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln, 
wenn er stur nach jedem empfangenen Zeichen ein Reply sendet.


IngoF schrieb:
> Oder wolltest Du wissen WANN das Echo kommt?
Ich würde gerne wissen, wie das Oszillogramm aussieht, wenn man ein 
Daten-Telegramm 'am Stück' auf den Bus gibt. Theoretisch müsste dann 
darauf ja auch ein Echo 'am Stück' folgen.


 Das Echo kommt immer sofort
> ohne große Wartezeiten oder Pausen.
Eine kleine Pause gibt es lt. den Oszi-Bildern aber schon. Die würde 
auch ausreichen um zu erkennen ob noch ein Zeichen folgt, da auf das 
Stop-Bit(H) des gesendeten Bytes sofort das Start-Bit(L) das nächsten 
Bytes kommen würde.



//Niffko

von MartinQ (Gast)


Lesenswert?

Hallo zusammen
ich bin erstmalig hier im Forum.

Zuerst zu meiner Person: ich besitze eine Anlage mit folgenden 
Eigenschaften:
GB 142 (Bj 2004)
UBA3/MC10: Version 2.05
BC10: Version 2.00
RC30: Version 2.05

Nach Kauf im Jahr 2004 und grober Analyse des EMS-Bus-Protokolls hatte 
ich
damals eine ansatzweise Betriebsdatenaufzeichnung mit 16bit uC 
aufgebaut. Allerdings konnte ich die Prüfsumme nicht herausfinden. Auch 
der Polling-Mechanismus war mir im Detail unklar geblieben (besitze kein 
Oszi).

Deshalb hier an alle vielen Dank für die Arbeit, insbes. an Rudi 
(24.10.2010) und auch IngoF für die CRC-Berechnung. Mit dem Wissen ist 
es jetzt viel einfacher, Logging-Informationen zuverlässig auszuwerten. 
Allerdings sind meine Kenntnisse von damals (2004) schon fast wieder 
vergessen.

Zur Frage der Schaltprogramme von IngoF (06.01.2011):
IngoF schrieb:
> Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine
> Idee mit der Zuordnung der Daten zu den Schaltzeiten hat..

Nach Veränderung eines Schaltprogramms am RC30 sendet der RC30 offenbar 
einmalig vier Telegramme mit dem kompletten Inhalt des jeweils 
geänderten Schaltprogramms.
Die entsprechenden Telegramme sind (bei meiner RC30):
   10 00 3f  für Heizkreis 1
   10 00 38  für Warmwasser
   10 00 39  für Zirkulation.
Beispiel für ein geändertes Schaltprogramm am Heizkreis 1 (Log incl. 
CRC)
   Msg: 10 00 3f 00 01 1e 00 82 21 1f 20 82 41 1f 40 82 61 1f 60 82 81 
1f 80 82 a1 20 a0 82 c1 20 c0 11
   Msg: 10 00 3f 1b 82 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 
e7 90 e7 90 e7 90 e7 90 e7 90 b0
   Msg: 10 00 3f 36 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 
90 e7 90 e7 90 e7 90 e7 90 e7 23
   Msg: 10 00 3f 51 90 e7 90 00 00 00 11 08 0a 0a 09 0a 01 01 00 01 01 
00 97
Die vier Telegramme enthalten den Speicherbereich des Schaltprogramms 
(99 Bytes Nutzdaten):
   Byte 4: Startadresse des Speicherbereich-Blockes
   Byte 5-Ende (vor CRC): Nutzdaten (3 x 27 Bytes und 1 x 18 Bytes).
Die Nutzdaten enthalten nach meiner Einschätzung:
   42 * 2 Bytes mit Schaltzeiten und weitere 15 Bytes (Inhalt unklar).
Ein Schaltpunkt enthält die beiden Bytes:
   0xXY 0xZZ  mit X = Tag (0=Mo, 2=Di, C=So, E=Schaltpunkt undefiniert),
                  Y = Schalten (0=Aus, 1=Ein, 7=Schaltpunkt 
undefiniert),
                  ZZ = Zeitpunkt (00=00:00, ... 8f=23:50, 
90=undefiniert).
Beispiel:
   01 1e : Montag, Ein, 5:00

Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus 
?

von Ingo F. (ingof)


Lesenswert?

Niffko _ schrieb:
> daher reicht mir
> das noch nicht als 'Beweis' ;-)

Na wenn Du Beweise brauchst.... ;o)
Beitrag "Re: Logamatic 2107 Schnittstelle"

Gut, man kann es nicht wirklich 100% erkennen. Aber als ich noch näher 
herangezoomt habe konnte man gut sehen dass nach jedem gesendeten Byte 
ein EchoByte vom Master kommt. Beide Bilder sind aus der selben Messung.


Niffko _ schrieb:
> Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln,
> wenn er stur nach jedem empfangenen Zeichen ein Reply sendet.

habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es 
gemeint hatte. Die RC30 wartet immer auf ein Echo bevor das nächste Byte 
kommt. Kann sein dass der Master erkennt wenn jemand ein ganzes Paket 
ohne Pause sendet und dann keine Echo sendet.

Allerdings würde ich empfehlen es genau so zu machen wie die RC30. Also 
nach jedem Byte ein Byte Pause machen oder das Echo einlesen und zu 
vergleichen.

Der einzige der ohne die 1-Byte-Pause zwischen den Sendebytes sendet ist 
der Busmaster.

Habe allerdings auch mal ein Telegramm am OSzillioskop gesehen das in 
mehreren Bröckchen gesendet wurde. Kann das allerdings nicht mehr 
nachfollziehen.

Wäre möglich dass auf dem EMS-Bus nur gesendet werden darf wenn ein Echo 
gesendet wurde. Kann ja sein dass der Busmaster kurz beschäftigt ist und 
dadurch dem Sender eine Pause aufzwingen kann.

Vielleicht funktioniert ja auch das Dein "drauflospusten" und macht erst 
Probleme wenn irgendwelche Komponenten z.B. mit neuerer Firmware in der 
Heizung ausgetauscht werden.

MartinQ schrieb:
>  ... insbes. an Rudi ... und auch IngoF für die CRC-Berechnung. ...
Danke, sieht man nicht wirklich wieviel Zeit ich mit der 
Tabellenkalkulation verbracht habe um das erste Ergebnis zu bekommen. 
Aber der Entscheidende Hinweis kamm dann von Rudi, dass bei gesetzten 
Bit7 der CRC nochmal mit einem Wert (0x12?) geXORed wurde. Hätte ich 
vermutlich nie herausgefunden! Hab schon echt verzweifelt ;o) Wusste nur 
dass es mit den getesteten Telegrammen ohne >0x80 funktioniert hatte.

Aber gut dass es das Internet und Mikrocontroller.net gibt....

MartinQ schrieb:
> Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus ?

Das ist nur eine Frage der Zeit. Das ist ja einer der Hauptgründe warum 
ich an den EMS-Bus wollte....

Denke aber dass da noch jemand schneller sein wird als ich.

Gruß
Ingo

von IngoF (Gast)


Lesenswert?

00 11 08 0a 0a 09 0a 01 01 00 01 01

0 Stunden Party Funktion

17.08.2010
Urlaubstart Tag
Urlaubstart Monat
Urlaubstart Jahr

10.09.2010
Urlaubende Tag
Urlaubende Monat
Urlaubende Jahr

01.01.2010
Feiertagstart Tag
Feiertagstart Monat
Feiertagstart Jahr

01.01.2000
Feiertagende Tag
Feiertagende Monat
Feiertagende Jahr

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt
> sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein
> Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir
> das noch nicht als 'Beweis' ;-)

Könntest du einfach mal senden und dir die empfangenen Daten anzeigen 
lassen ? Wenn du deine gesendeten Daten nicht siehst, dann funktioniert 
es nicht, bzw. erkennt der Busmaster deine Daten nicht.


Grüße.

von IngoF (Gast)


Lesenswert?

IngoF schrieb:
> 01.01.2010
> Feiertagstart Tag
> Feiertagstart Monat
> Feiertagstart Jahr
>
> 01.01.2000
> Feiertagende Tag
> Feiertagende Monat
> Feiertagende Jahr
 musste eigentlich heissen:

10.01.2001

00.01.2001

Keine Ahnung warum dort 00 als Tag steht...

von Rudi (Gast)


Lesenswert?

IngoF schrieb:
> Keine Ahnung warum dort 00 als Tag steht...

Da gibt es  mehrere Variationen ;-). Je nachdem wann der erste des 
Monats und der erste Monat anfängt, mit der Zeit das gleiche, steht da 0 
oder 1. Bei den Wochentagen gibt es glaube ich auch nette Variationen, 
einmal fängt er Sonntags an, einmal Montags ....

von Niffko _. (niffko)


Lesenswert?

Ingo F. schrieb:
> habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es
> gemeint hatte. ...  Kann sein dass der Master erkennt wenn jemand ein
> ganzes Paket ohne Pause sendet und dann keine Echo sendet.
... habe dich schon verstanden und der letzte Satz ist genau der Punkt. 
Es ist ja offensichtlich so, dass der Master nicht dogmatisch darauf 
besteht, nach jedem Zeichen ein Echo zu senden. Sonst hätte ich ja mein 
gesendetes Telegramm nicht auf dem Bus sehen können.

Ingo F. schrieb:
> Allerdings würde ich empfehlen es genau so zu machen wie die RC30.
Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)

Ingo F. schrieb:
> Vielleicht funktioniert ja auch das Dein "drauflospusten" ...
uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll**


Rudi schrieb:
>Könntest du einfach mal senden und dir die empfangenen Daten anzeigen
>lassen ?
Hatte ich natürlich gemacht. Wie hätte ich auch sonst feststellen 
sollen, dass keine Pausen notwendig sind. Ursprünglich wollte ich 
austesten wie weit man es mit den Sendepausen treiben kann und habe die 
Zeit zwischen Polling-Antwort und Break immer weiter ausgedehnt. Als 
dann bei 255 Bitlängen immer noch niemand gemeckert hat und ich ohne 
Weiteres nicht mehr erhöhen konnte, war der nächste logische Schritt, es 
auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer 
ordnungsgemäß vom Master auf den Bus geschoben.



//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> war der nächste logische Schritt, es
> auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer
> ordnungsgemäß vom Master auf den Bus geschoben.

Na dann war dass wohl ein Missverständnis.
Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und 
dem nächten Byte...

Man muss garkeine Pausen machen. Also Byte senden. Master sendet ohne 
Pause das Echo. Sofort wenn das Echo empfangen wurde kann das nächste 
Byte gesendet werden.

Niffko _ schrieb:
> Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)

Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade 
so über die Hürden zu kommen.
Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat 
Dein Pfer aber ein Problem und bleibt hängen.
Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem 
falschen Fuß aufgestanden.... Wer weiss ;o)

Niffko _ schrieb:
> uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll**

Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das 
Echo zu warten das nächste hinterher schickst. Denke der Busmaster 
dürfte aber mehr Puste haben, und Dein nächstes Byte mit seinem Echo 
wegpusten....

Gruß
Ingo

von IngoF (Gast)


Lesenswert?

Ganz vergessen..

Mit dem Alter schrumpft man ja auch ein wenig. Spätestens dann hat Dein 
"gerademalsodrüberhüpdpferdchen" Probleme :D

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:

> Na dann war dass wohl ein Missverständnis.
> Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und
> dem nächten Byte...
Oh mann, hier hat das geschriebene Wort wohl mal wieder so richtig seine 
Tücken. Ich versuch's jetzt nochmal:

mit Pause
Master sendet : 8X <brk>
Ich sende     : 0X P XX P XX P XX P XX P XX P <BRK>
Ich empfange  : 0X XX XX XX XX XX <BRK>


ohne Pause
Master sendet : 8X <brk>
Ich sende     : 0X XX XX XX XX XX <BRK>  kontinuierlicher Stream, auf 
Stop-Bit folgt Start-Bit, keine Pausen
Ich empfange  : 0X XX XX XX XX XX <BRK>



> Niffko _ schrieb:
>> Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)
>
> Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade
> so über die Hürden zu kommen.
Ich schrieb: so hoch wie es muss, nicht wie es kann.

> Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat
> Dein Pfer aber ein Problem und bleibt hängen.
Ein gutes Pferd sieht das und springt dann ebend höher.

> Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem
> falschen Fuß aufgestanden...
Wenn es schlechte Tage hat, ist es kein gutes Pferd.
So ... jetzt ist aber gut ;o)

IngoF schrieb:
> Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das
> Echo zu warten das nächste hinterher schickst.
ja ... richtig ... geht doch.


IngoF schrieb:
> Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes
> Byte mit seinem Echo wegpusten....
Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte.



//Niffko

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> IngoF schrieb:
>> Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes
>> Byte mit seinem Echo wegpusten....
> Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte.

Du kannst aber nicht wissen wann der Master senden will und das ist das 
Problem. Wenn der Bus auf Low gehalten wird darf nicht gleichzeitig 
gesendet werden. In den Scope Bildern von mir siehst du auch wie der 
Master gleichzeitig sendet, okay mein Sendepegel war etwas zu groß, aber 
das sollte erst einmal egal sein.


Grüße.

von rkoch (Gast)


Lesenswert?

Nur mal eine Vermutung von mir:

An anderer Stelle hat mal einer erwähnt, das der Empfänger des Masters 
auf die durch den Transistor und den 220 Ohm Widerstand erzeugten 
Stromschwankungen reagiert, anstatt auf die eher geringen 
Spannungsschwankungen.

Der Strom ist bei 15V damit beim Senden um 68mA höher, bei 10V (Low) um 
45mA höher als der Ruhestrom.

Warum soll der Master also nicht auch unabhängig von seiner eigenen 
Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht 
doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen 
würde!

Damit könnte ich mir vorstellen das der Master brav nach jedem 
empfangenen Byte sofort das Spannungsecho sendet und parallel dazu auf 
seiner Stromschnittstelle das nächste Byte empfängt. Der Sendeschaltung 
ist es auch schitegal ob sie mit statisch 15V oder mit modulierten 
10/15V beaufschlagt wird.

BTW: Nachdem ich jetzt auch mal mitrede zu meiner Person:
Buderus GB162
Windhager Logwin
UVR1611

Den GB162 steuere ich über Leistungsmodulation (10V mit Original EM10, 
hallo Niffko :-) )
Bislang hab ich nur mitgelesen (und werd es wohl auch im wesentlichen 
auch in Zukunft tun) da ich momentan mich eher darauf konzentiere zu 
versuchen das LON-Protokoll zu entschlüsseln weil ich das was ihr hier 
macht mit dem Logwin machen möchte.... Am Ende sollen sowohl der Logwin 
als auch der GB162 mit entsprechenden Interfaces direkt via OpenCAN von 
der UVR1611 gesteuert/ausgelesen werden.

von IngoF (Gast)


Lesenswert?

rkoch schrieb:
> Warum soll der Master also nicht auch unabhängig von seiner eigenen
> Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht
> doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen
> würde!

Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert.

von Rudi (Gast)


Lesenswert?

IngoF schrieb:
>> Warum soll der Master also nicht auch unabhängig von seiner eigenen
>> Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht
>> doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen
>> würde!
>
> Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert.

Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der 
beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe 
auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo 
funktioniert das so nicht.


Grüße.

von Rudi (Gast)


Lesenswert?

Rudi schrieb:
> ergo funktioniert das so nicht

zuverlässig ;-)

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein
> Telgramm mit der falschen CRC auf den Bus schiebt?

Was Telegramme angeht, die für den Busmaster(08) bestimmt sind, kann ich 
hierzu Folgendes sagen. Grundsätzlich werden auch Telegramme mit 
falscher CRC auf den Bus 'ge-echot'. Beim Senden mit Unterbrechung ist 
das natürlich logisch und nicht zu verhindern. Aber auch wenn mann das 
Telegramm im Paket absetzt und der Busmaster vor dem Wiederholen die 
Möglichkeit zur Prüfung hätte, wird das fehlerhafte Telegramm auf den 
Bus gegeben. Ein fehlerhaftes Telegramm wird dann allerdings vom Master 
mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk> 
bekommt. Somit wäre das auch eine gute Möglichkeit eine abgesetzte 
Sendung zu verifizieren.



//Niffko

von rkoch (Gast)


Lesenswert?

> Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der
> beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe
> auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo
> funktioniert das so nicht.

Wenn ich mich nicht irre wissen wir über die Sendeschaltung des Masters 
recht wenig. Da es möglich ist auf einer Busleitung eine 
spannungsgesteuerte und eine stromgesteuerte Übertragung mit annähernd 
100%iger Kanaltrennung zu fahren könnte ich mir sehr wohl vorstellen das 
das funktioniert. So lange unser System nicht Multi-Master-Fähig ist 
(ist es das ?) bräuchte der Master genausowenig wie die Clients 2 
Kanäle. Bei ihm wäre nur die Sende/Empfangsschaltung genau konplementär 
zu der der Clients...

Da man der Sendeschaltung des Masters offenbar einiges an Strom zumuten 
kann würde ein zweiter Master mit Spannungssignalisierung IMHO nicht 
funktionieren. Insofern wäre Multi-Master IMHO nur möglich, wenn man den 
Master in zwei Funktionalitäten trennt: Bus-Master und Device Master, 
d.h. der Bus Master ist der einzige am Bus mit Spannungssender, Device 
Master senden und empfangen (solange sie nicht zugleich Bus-Master sind) 
wie Clients, aber machen das Polling für ihre Clients.

Ob es so was wie Multi-Master gibt kann ich aus den bisherigen Beiträgen 
auf die Schnelle nicht herauslesen. I.d.R. kommen hier wohl nur entweder 
Logamatic oder BC10 als Master vor....

Falls es doch mehrere Master am Bus gibt müssen diese aber eigentlich 
nur im Moment des Einschaltens sich einig werden wer den Bus-Master 
macht - im simpelsten Fall einfach indem derjenige der beim Einschalten 
0V auf dem Bus sieht seine Treiber aktiviert. Der Verlierer in dieser 
Selektion schaltet dann einfach sein RX/TX auf das Client-Interface.

Ich weiß zwar absolut nicht ob das so läuft, aber vorstellbar wäre es - 
gibt es schließlich in anderen Systemen nicht viel anders.

Die Master-Sendeschaltung stelle ich mir relativ primitiv vor: 2 
Spannungsquellen (15V/10V), die 10V einfach über eine Diode (oder einen 
Transistor) auf den Bus geschaltet, die 15V immer über Transistor. 
Eventuell auch noch einfacher: 15V und Spannungsdrop von ~5V durch eine 
5V-Leistungs-Z-Diode die mit einem Transistor überbrückt wird. Als 
Stromempfänger dann einfach ein Widerstand (ca. 6 Ohm), deshalb der 
Spannungsabfall von ca. 0,5 V bei ~70mA, der Ruhestromwert über Tiefpass 
auf Comparator, der Impulsstromwert direkt.

Vieleicht fabiluiere ich hier nur ins Blaue hinein, aber technisch 
vorstellbar wäre so was.

von Fred G. (sysrun)


Lesenswert?

Kurze Zwischenfrage: Kann mir einer von euch ein wenig C-Code zur 
Verfügung stellen? Bekomme das mit dem Software-UART leider nicht 
richtig hin :-(

von IngoF (Gast)


Lesenswert?

Fred Granna schrieb:
> Bekomme das mit dem Software-UART leider nicht
> richtig hin :-(

Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link 
mit dem Soft-UART-Link von Niffko:
Beitrag "Re: Logamatic 2107 Schnittstelle"

Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware 
UART.

Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist 
Geschichte??

Niffko _ schrieb:
> Grundsätzlich werden auch Telegramme mit
> falscher CRC auf den Bus 'ge-echot'.

Das hatte ich mir auch schon fast gedacht. Der Master kann die Prüfsumme 
ja erst vergleichen wenn das Telegramm zu ende ist und das letzte Break 
gesendet wurde.

Niffko _ schrieb:
> Ein fehlerhaftes Telegramm wird dann allerdings vom Master
> mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk>
> bekommt.

Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im 
Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder 
erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird?

Gruß
Ingo

von Fred G. (sysrun)


Lesenswert?

IngoF schrieb:
> Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link
> ...
Hatte Niffko ne PM geschickt aber keine Antwort bekommen...

> Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware
> UART.
Nehme ich ungern, der Atmega328 von meinen Boards ja nur eine.


> Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist
> Geschichte??

Mit dem i2c-Uart hab ich leider Timingprobleme. Die Break-Erkennung ist 
zu langsam da ich den Chip nur über Polling ansprechen kann.

von rkoch (Gast)


Lesenswert?

@Fred Granna

Hast Du Dir die App-Note AVR304 
(http://atmel.com/dyn/resources/prod_documents/doc0941.pdf bzw. 
http://atmel.com/dyn/resources/prod_documents/avr304.zip) schon mal 
angeschaut? Ist doch eigentlich ganz gut dokumentiert und auch nicht 
wirklich kompliziert. Die einzige Änderung wäre doch anstatt des 
externen Interrupts den Comparator-IRQ zum Starten des Empfangs zu 
verwenden und dann natürlich anstatt des IO-Ports den Ausgang des 
Comparators zum Empfang zu verwenden.... und natürlich ggf. den IAR-Code 
an z.B. gcc (WinAVR) anzupassen.

von Niffko _. (niffko)


Lesenswert?

Fred Granna schrieb:
> Hatte Niffko ne PM geschickt aber keine Antwort bekommen...

öhmm, sorry ... war keine böse Absicht. Das Motherboard von meinem Dell 
ist mal wieder im Eimer und auf dem Laptop habe ich keinen Email-Krams 
drauf.

Meinen AVR-Code möchte ich aber momentan keinem zumuten, der ist noch zu 
'Baustelle'.

Formuliere doch mal die Probleme die Du hast, dann kriegen wir das schon 
hin. Vielleicht hilft's ja auch dem Ein oder Anderen mit ähnlichen 
Problemen.

Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich 
die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren 
muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer 
falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief.

Wenn Du den Soft-UART von P.D. in alles Einzelheiten verstanden hast, 
solltest Du das eigentlich hinbekommen.

Also ... lass mal hören, wo die Säge klemmt.



//Niffko

von rkoch (Gast)


Lesenswert?

Niffko _ schrieb:

> Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich
> die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren
> muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer
> falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief.

417 wäre aber definitiv richtig... Kann es sein, das Du den Timer immer 
wieder neu aufsetzt anstatt ihn einfach im PWM Mode mit IRQ bei Overrun 
laufen zu lassen? Dann musst Du natürlich die Zeit die der AVR zum 
Setzen des Zählers braucht abziehen... Trotzdem gibt das u.U. immer noch 
genug Jitter um aus dem Ruder zu laufen, je nachdem ob Du noch andere 
IRQs aktiv hast.

von Niffko _. (niffko)


Lesenswert?

rkoch schrieb:
> 417 wäre aber definitiv richtig...
tja ... wem sagst Du das. Vielleicht geht mein Quarz ja 'etwas' nach. :D

rkoch schrieb:
> Kann es sein, das Du den Timer immer wieder neu aufsetzt anstatt
> ihn einfach im PWM Mode mit IRQ bei Overrun laufen zu lassen?
Negativ. Timer1 wird bei Programmstart einmal auf volle Bitzeit 
initialisiert und läuft danach permanent im CTC-Mode. Der TX-Algo läuft 
in der OutputCompareA ISR. RX wird über InputCapture gestartet 
(Startbit) und OutputCompareB einmalig so gesetzt, dass die Abtastung in 
der OutputCompareB ISR eine halbe Bitzeit später beginnt. Von daher 
dürften eigentlich keine Abweichungen entstehen.


//Niffko

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im
> Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder
> erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird?

Hallo Ingo,

nachfolgend ein Paar Snippets zum Thema Quittierung.

Quittierung 'standard':
1
91 00
2
11 08 1E 00 00 F9 9B 00
3
01 00
4
11 00


Quittierung 'mittendrin':
1
90 00
2
10 88 11 24 18 29 00
3
08 10 11 24 36 41 00 E3 8B 01 11 11 2C 00 00 00 04 00
4
10 88 11 30 0C 15 00
5
08 10 11 30 36 41 00 E3 8B 01 11 11 2C 00 00 00 4A 00
6
10 08 35 00 01 01 00 00
7
01 00
8
10 88 1C 00 17 5A 00
9
08 10 1C 00 00 00 00 00 00 00 00 00 00 00 00 62 00
10
10 00


Folgendes ist mir erst kürzlich aufgefallen. Es widerlegt meine These, 
dass nur Telegramme an den Master(08) quittiert werden und wirft die 
Frage auf, wer überhaupt quittiert - der Master oder der jeweilige 
Empfänger!? Ich wäre ja fast für Letzteres.
1
90 00
2
10 11 9D 00 64 B3 00
3
01 00
4
10 91 02 00 03 FE 00
5
11 10 02 00 47 01 01 30 00
6
10 00 02 00 56 01 06 01 00
7
10 00



//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> der Master oder der jeweilige
> Empfänger!? Ich wäre ja fast für Letzteres.

Na das wird sich ganz einfach feststellen lassen...

Allerdings habe ich noch einen Bug in meiner Senderoutine. Irgendwie 
gibt es noch Probleme mit dem Vergleich der gesendeten Bytes.

Wenn die Quittierung von der MC30 kommt wenn ich ein Telegramm an sie 
sende sollte man erst den Sendepegel der RC30 sehen und anschließend das 
Echo vom Busmaster.

Wenn der Busmaster die Telegramme quittiert fehlt der.

Wenn irgendjemand die Telegramme quittiert die man von anderen 
Busteilnehmern bekommt, dann kann es nur der Master sein.

Bin auch für die Vermutung dass der Empfänger quittiert. Aber bisher 
natürlich nur eine Vermutung.

Mir ist gerade aufgefallen dass nur Telegramme bestätigt werden in denen 
das Bit7 nicht gesetzt ist. Also nur Telegramme auf die sonst keine 
Antwort vom Empfänger kommt.

Vermutlich auch ein Zeichen dafür dass der Empfänger bestätigt....

Gruß
Ingo

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Na das wird sich ganz einfach feststellen lassen...

... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^


//Niffko

von IngoF (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

habe noch mal meine alten LOG-Files durchsucht.

Es sieht so aus als ob Das Telegramm 10 00 06 ..... immer bestätigt 
wird.

Telegramme an die 21 wurden nicht bestätigt. An die 08 allerdings 
schon.. Also hat das nicht nur was mit dem Polling zu tun...
Allerdings war das beim herausfinden der Adressen am EMS-Bus und die 
0x21 bin ich gewesen (Hatte nutr Polling beantwortet)

Einmal kam die 01 ohne dass das Polling an die 10 rausgegangen ist und 
dannach Antwortet die 10 (MC30)
Oder ist das ein Check ob die die RC30 noch da ist? Macht ja auch wenig 
Sinn.. es gibt ja das Polling.

Die "Quittierung" kommt sogar mal ganz spontan ohne irgendwelche 
Telegramme. Vielleicht wird es zusätzlich jede Minute die keine 
Telegramme versendet wurden auch auf den Bus gegeben. Allerdings hatte 
ich damals noch einen großen Buffer und die Zeiten ändern sich selten. 
Kann also im Moment nicht sagen wie lange die Pause sein kann....

Die Qutittierung 04 habe ich allerdings garnicht gefunden.

Hier mal ein paar Ausschnitte die ich Beispielhaft aus meinen Log-File 
geschnibbelt habe:

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> ... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^

Genau das hatte ich auch damit gemeint.. Allerdings ärgert mich noch 
meine Senderoutine. Der Vergleich will nicht immer klappen...

Also wenn ich soweit bin werde ich mal danach gezielt suchen...

Bis dahin kann ich nur dannach in meinen Log-Files suchen und wild 
herumspekulieren ;o)

Gruß
Ingo

von Niffko _. (niffko)


Lesenswert?

IngoF schrieb:
> Telegramme an die 21 wurden nicht bestätigt ... und die
> 0x21 bin ich gewesen (Hatte nutr Polling beantwortet)
ok ... das spricht dafür, dass der Empfänger quittiert. Denn als solcher 
wärst Du offensichtlich dafür verantwortlich gewesen, hast es aber nicht 
getan.

IngoF schrieb:
> Die Qutittierung 04 habe ich allerdings garnicht gefunden.
... hierfür wirst Du ein Telegramm mit einer falschen CRC schicken 
müssen. Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich 
robust.


//Niffko

von IngoF (Gast)


Lesenswert?

Niffko _ schrieb:
> ok ... das spricht dafür, dass der Empfänger quittiert.

Mich stört nur noch das ab und zu die 01 Grundlos mitten im Polling 
auftaucht.. Aber vermute mal das war irgend ein Fehler in meiner 
Software. Es trat immer vereinzelt auf und danach kam eine Antwort von 
der 10 (MC30) ohne Polling.. Hätte also eigentlich eine 90 sein 
müssen...

Niffko _ schrieb:
> Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich
> robust.

Also in 137 MByte (60Stunden) kein einziges fehlerhaftes Telegramm ist 
doch auch schon mal was

von Rudi (Gast)


Lesenswert?

Hallo,

ich sehe die 0x01 auch ;-).

Die Bestätigung wird offensichtlich nur gesendet, wenn "Werte" gesetzt 
werden:

=> 10 08 1a 00 38 64 64 00 09
=> 01

=> 10 08 35 00 11 11 30
=> 01

Wenn in der Bedienung ein paar Werte geändert werden, sollte die 0x01 
auch zu sehen sein !?



Grüße.

von Ingo F. (ingof)


Angehängte Dateien:

Lesenswert?

Hallo an alle...

im Moment tut sich ja nicht mehr viel in diesem Thread. Aber eigentlich 
ist ja inzwischen schon fast alles bekannt.

Habe schon mal das 3964R-Protokoll "eingebaut". Falls jemand sowas 
ähnliches vorhat und das noch testen will kann ja mal mein kleines 
3964R-Terminal Programm ausprobieren.

Zu finden http://modelledit.rc-sim.de unter Downloads.

Den Trace kann man nur sehen wenn das Programm über die Batchdatei oder 
über Console mit java -jar Terminal-3964R aufgerufen wird. der 
"löschen"-Knopf hat noch keine Funktion.

Als Paramter kann man noch den seriellen Port übergeben.

Sollte auch unter Linux oder auf dem MAC laufen. Habe es allerdings noch 
nciht getestet. Einfach "COM1" auf den entsprechenden Namen ändern.
Java 1.6 ist Mindestvorraussetztung.

Wer das Programm hilfreich findet kann ja eine Kleinigkeit an Unicef 
spenden.

Installation: Entpacken und starten :-)

Gruß
IngoF

von F. F. (pic18f)


Lesenswert?

Hallo, erstmal an alle Lob und Anerkennung, ich lese schon längere Zeit 
mit. Da es aber sehr viel ist, finde ich es gut wenn man eine 
Zusammenfassung vom heutigen Stand hätte. Ich selbst habe eine Buderus 
Heizungsanlage aus dem Jahr 2003:
GB142-24
RC30
MM10
WM10

da ich den PIC 18F2550 / 18F4550 programmiere bin ich an ein Programm 
für diesen interessiert. Also die Schnittstelle zum EMS Bus. Ich möchte 
zuerst nur einmal die Störmeldungen abfragen falls das Gerät ausfällt. 
Später möchte ich evtl. der RC30 Temperatur-Sollwerte vorgeben. Ich 
denke das ist nach dem heutigen Stand möglich.

IngoF schrieb:
> Also ich habe zumindest geplant so eine Platine als "Sammelbestellung"
>
> zu machen. Allerdings ist meine Hardware noch in der Entwicklung.


@IngoF an eine Sammelbestellung bin ich interessiert, soll es ein PIC 
sein?
mich würde auch deine Firmware interessieren (für PIC). Welche 
Programmiersprache benutze Du? Macht es einen Sinn die 
Komperatoreingänge zu benutzen?

Gruß pic18f

von Ingo F. (ingof)


Lesenswert?

F. F. schrieb:
> da ich den PIC 18F2550

Ich habe den 18F258 bisher verwendet und nehme jetzt den 18F2580. Der 
18F2550 hat keine eingebaute CAN-Schnittstelle.

Mit den Komperatoreingängen habe ich mich nicht beschäftigt. Wenn man 
diese beutzen möchte kann man den eingebauten EUSART nicht nutzen und 
müsste auf einen Soft-UART zurückgreifen.
Aber irgendwie sind mir persönlich externe Komperatoren lieber. Notfalls 
kann man die auch austauschen.

Vermutlich werde ich aber auch noch einen SoftwareUART zusätzlich 
verwenden damit ein PIC zwischen EMS-Bus und PC läuft. Vielleicht wird 
es ja auch ein externer UART oder auch ein anderer PIC. Im Moment habe 
ich einen PIC der den EMS-Bus mit CAN verbindet. Der zweite verbindet 
dann den CAN mit dem PC.

Ich bin Assembler Anhänger weil ich kein C kann und mir einbilde dass 
ich dann mehr Kontrolle über die Hardware habe.

Werde später dann den Eagle-Schaltplan und die Firmware als Download 
anbieten und natürlich eine Art Sammelbestellung machen. Wird vermutlich 
SMD sein die selber bestückt werden muss. Wenn natürlich genug 
zusammenkommen würde eine fertig bestückte Platine sich auch rechnen.

Das Sollwert vorgeben sollte wirklich kein Problem mehr sein... Die 
Prüfsumme, das Telegrammformat sind ja soweit eigentlich bekannt...

Bin allerdings noch nicht mit meiner Empfangsschaltung zufrieden und 
werde demnächst mal die gepostete Buderus-Lösung ausprobieren. 
Vermutlich wird die besser als meine "Standartbeschaltung".

Im Moment kämpfe ich noch mit den letzten Feinarbeiten an dem 
3964R-Protokoll herum.

Werde mich hier auf jedenfall noch mal zu Wort melden wenn eine 
Sammelbestellung in Sicht ist.

Gruß
IngoF

von F. F. (pic18f)


Lesenswert?

Hallo,
endlich jemand der einen PIC programmiert.

Der 18F2580 hat gegenüber den 18F2550 zwei Nachteile. Es fehlt der 
USB-Bus sowie die Komperatoreneingänge, diese hat laut Datenblatt nur 
der große Bruder 18F4580. Falls man diesen nimmt, dann dürfte es mit der 
EUSART keine Probleme geben.
Der Vorteil des 18F2580 ist, daß wenn 32Mhz Taktfrequenz genügen man 
keine Quarzbeschaltung benötigt, da man den internen Takt über der der 
PLL hochtreiben kann. Sowie der CAN-Bus.

Habe ich es richtig verstanden, daß der CAN-Bus nur für die Verbindung 
der zwei PIC's genommen wird? Könnte da man nicht den I2C-Bus nehmen 
oder ist da die Reichweite zu klein. Welche Schnittstelle wird denn zum 
PC genommen? Eine RS232? Diese Schnittstelle haben die meisten neuen 
Rechner nicht mehr, hier wäre eine USB-Schnittstelle von Vorteil. Zum 
EMS-Bus wird wohl die Eusart-Schnittstelle mit dem 3964R Protokoll 
genommen, welches ich nicht kenne.

Von SMD bin ich kein Freund, ich weiß nicht ob ich dies mit einem 
normalen Lötkolben löten kann. Außerdem, falls man mal was ändert, dann 
ist die Beschaltung doch sehr klein.
Die PIC's habe ich immer mit einen Bootloader, welcher ich mit einen 
einfachen Brenner programmiert hatte, versehen. Die Firmware hatte ich 
dann mit den USB-Bus geladen hatte. Pitkit oder ähnliches besitze ich 
nicht.

Assembler ist Ok, ich programmiere zwar mehr in C18 wegen der 
Übersichtlichkeit, aber schnelle Interruptprogramme habe ich meistens in 
Assembler geschrieben.


Ich bin auf jeden Fall auf den Schaltplan sowie der Firmware 
interessiert und freue mich wenn eine Sammelbestellung in Sicht ist.

Viele Grüße
F. F.

von Ingo F. (ingof)


Lesenswert?

Hallo F.F.

habe mal einen neuen Thread für dieses Thema gemacht:
Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"

Alles zu der Sammelbestellung, Schaltungs- und Softwareentwicklung gibt 
es dann dort.

Hat ja schon lange nichts mehr mit der Buderus 2107 zu tun.

Gruß
IngoF

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt
> und zu 'papier' gebracht (siehe anhang).

Hallo Niffko,


deine Schaltung ist so nicht richtig. An den Eingangskomparator muss an 
- die Uref. Die 1nF/100k/10k sollten da nicht sein, wofür sind die? Ich 
habe die Schaltung mal aufgebaut und mit einem Funktionsgenerator 
getestet und gemessen. Funktioniert ganz ordentlich mit der Änderung.


Grüße.

von Niffko _. (niffko)


Lesenswert?

Rudi schrieb:
> deine Schaltung ist so nicht richtig.

Gut gebrüllt, Löwe.


> An den Eingangskomparator muss an - die Uref.

Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt, 
hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden 
Eingängen, hältst Du das bei einem Komparator für sinnvoll?!

So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K) 
auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig 
unterhalb dem von (+) und der Komparator damit definiert auf High.

Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze 
(Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da 
die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein 
Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des 
1nf Kondensators, schaltet der Komparator.

Soweit meine Theorie ... sollten hier Profis mitlesen, bitte ich ggf. um 
Berichtigung.

Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte 
Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im 
TX-Betrieb einwandfrei.


// Niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> Rudi schrieb:
>> deine Schaltung ist so nicht richtig.
>
> Gut gebrüllt, Löwe.

Ja ;-).


Die Signale sehen an +/- in etwa gleich aus, bei dem 1nF Kondensator 
etwas verzerrter. Ich kann mal Bilder mit dem Oszi machen, wie gesagt 
ich habe das mit einem Signalgenerator getestet (Offset 9.5V und dann 
ein 5V Signal) ohne ordentliches Signal am Ausgang. Es gab nur Spikes an 
den Flanken.


Grüße.

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

Anbei das Bild. Oben das Signal am 10uF und unten das Signal am 1nF. Wie 
man sieht kann der Komparator bei diesen Signalen nicht schalten.

Niffko _ schrieb:
> Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt,
> hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden
> Eingängen, hältst Du das bei einem Komparator für sinnvoll?!

Der Widerstand arbeitet als Pullup für das Signal am Kondensator, siehe 
Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten.

> So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K)
> auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig
> unterhalb dem von (+) und der Komparator damit definiert auf High.

Auch hier wird das Signal hinter dem Kondensator über die beiden 
Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem 
Kondensator relativ gering und das Signal fällt relativ schnell ab.

> Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze
> (Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da
> die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein
> Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des
> 1nf Kondensators, schaltet der Komparator.

Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur 
sich ändernde Signale.

> Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte
> Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im
> TX-Betrieb einwandfrei.

Das ist seltsam. Kannst du die Signale mit einem Oszi. messen?


Grüße.

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

Hallo Rudi,

vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor 
gelassen - warum schaltet der Komparator nicht spätestens bei Markierung 
II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf 
Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators 
bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste 
sich also unterhalb der an (-) befinden, was ein Schalten des 
Komparators zur Folge hätte.


> Niffko _ schrieb:
>> ... über den 47K Widerstand ebenfalls Uref. anliegt...
>
> Der Widerstand arbeitet als Pullup ...

Sozusagen. Und auf welche Spannung pullt er up ... auf Uref.


> ... als Pullup für das Signal am Kondensator, siehe
> Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten.

Das ist nicht unrichtig, aus meiner Sicht ist der Hintergrund aber ein 
anderer. Wie Du richtig angemerkt hast, wird über die Kondensatoren nur 
der AC-Anteil des Signals eingekoppelt. Durch die Widerstände werden die 
Eingänge des Komparators auf ein gewisses DC-Niveau vorgespannt - über 
den Daumen, (+) auf 0,6V und (-) auf 0,55V. Der eingekoppelte AC-Anteil 
bewirkt dann das Auslösen des Komparators. Beim Anliegen eines Null-Bits 
gibt es bis zum Schalten des Komparators eine Totzeit (Bereich zwischen 
I und II), da das Signal zunächst auf beide Eingänge wirkt, die Spannung 
an (-) durch die schnellere Umladung des 1nF Kondensators aber relativ 
fix wieder auf 0,55V steigt (siehe Bild).


>> So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K)
>> auf den (-) Eingang gelegt.
>
> Auch hier wird das Signal hinter dem Kondensator über die beiden
> Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem
> Kondensator relativ gering und das Signal fällt relativ schnell ab.

Wie gesagt, m.E. keine Signalkonditionierung, sondern ein Vorspannen der 
Komparatoreingänge.


>> Den 1nF Kondensator sehe ich als eine Art Störunterdrückung...
>
> Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur
> sich ändernde Signale.

Du hast mich nicht richtig verstanden. Das es hier um AC-Kopplung geht, 
sollte klar sein. Das Ding ist, dass der 10µ das Signal 1:1 durch 
reicht, der 1nF aber nur kurze Spikes auf den (-) Eingang koppelt. 
Daraus ergibt sich eine Art Schaltverzögerung, wodurch kurze Störimpulse 
dann keinen Schaltvorgang auslösen.


>> Besagte Schaltung arbeitet übrigens ... einwandfrei.
>
> Das ist seltsam. Kannst du die Signale mit einem Oszi. messen?

Aus Mangel an einem Funktionsgenerator, könnte ich das nur am Bus 
machen. Weiß nicht ob das viel Sinn macht. Ist auch alles ziemlich 
fummelig, da SMD. Mal sehen ...



// Niffko


Edit sagt: Zumindest ein Kollege aus dem Junkers-Thread scheint die 
Schaltung auch erfolgreich anzuwenden.

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor
> gelassen - warum schaltet der Komparator nicht spätestens bei Markierung
> II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf
> Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators
> bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste
> sich also unterhalb der an (-) befinden, was ein Schalten des
> Komparators zur Folge hätte.

Ja, wenn der Komparator schnell genug ist sollte man am Ausgang Spikes 
sehen. Der schaltet den Ausgang auf High wenn das Signal (+) über oder 
auf Low wenn das Signal unter der Schwelle (-) liegt. Und hier schaltet 
der nicht weil das Signal nie unter der Schwelle liegt.

>> Niffko _ schrieb:
>>> ... über den 47K Widerstand ebenfalls Uref. anliegt...
>>
>> Der Widerstand arbeitet als Pullup ...
>
> Sozusagen. Und auf welche Spannung pullt er up ... auf Uref.

Genau, wenn am Kondensator mal kein Signal anliegt bzw. nur ein High auf 
dem Bus anliegt, liegt das Signal über der Schwelle und am Ausgang vom 
Komparator liegt das Signal stabil auf High. Ansonsten würde sich der 
Kondensator mit der Zeit entladen und gegen 0V laufen, unter die 
Schwelle und am Ausgang wäre ein Low zu sehen.

Das spricht eigentlich dafür, das der Kondensator nicht an das 
Eingangssignal geht sondern dort an Masse (Blockkondensator) und die 
beiden Widerstände als Widerstandsteiler arbeiten um die Uref etwas zu 
senken.


Grüße.

von Niffko _. (niffko)


Lesenswert?

Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind 
die Offsets real oder hast Du vertikal verschoben?


// Niffko

von Rudi (Gast)


Lesenswert?

Niffko _ schrieb:
> Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind
> die Offsets real oder hast Du vertikal verschoben?

Der Auflösung lag bei 200mV, wenn ich mich recht erinnere. Die Offsets 
sind vertikal verschoben.

Ich werde für den RX-Pfad wie bisher den ADCMP370 benutzen, der hat bis 
jetzt funktioniert und die Bauteile halten sich in Grenzen. Den TX-Pfad 
werde ich wie bei dir in der Schaltung aufbauen, aber ohne Komparator. 
Die Versorgung werde ich auf 3V3 legen, aus einem LDO und die Anbindung 
wird dann Isoliert (ISO7421D).


Grüße.

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte
> Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im
> TX-Betrieb einwandfrei.

könntest Du dein Projekt etwas näher beschreiben? Ich werde demnächst 
etwas ähnliches regeln. Leider ist die Heizung z.Z. nicht mehr 
operational, da in diesem Raum eine Bodensanierung anliegt.

Ich will den Rücklauf über einen Speicher anheben, der von der 
Holzheizung geladen wird und evtl. später auch von Solar.


Grüße.

von Niffko _. (niffko)


Lesenswert?

Hi Rudi,

Rudi schrieb:
> könntest Du dein Projekt etwas näher beschreiben?

Ich habe die Heizkreisregelung komplett aus dem RC35 herausgenommen. Die 
Brenneransteuerung erfolgt im Grunde über zwei Kennlinien - 
Außentemperatur vs. Rücklaufsolltemperatur und Außentemperatur vs. 
Brennerleistung. Die Führungsgrößen Rücklauftemperatur und 
Außentemperatur werden vom Bus genommen, Brenneransteuerung erfolgt über 
außentemperaturabhängige Vorgabe der Brennerleistung. Für Logging- und 
Monitorzwecke wird über UART ein Telegramm mit relevanten EMS-Daten 
bereitgestellt, EMS-Kommunikation läuft über Soft-UART. Momentan bin ich 
dabei, mit C# eine GUI zu stricken, über die dann Monitoring, 
Logging(.csv) und Parametrierung des Reglers möglich ist.


> Ich will den Rücklauf über einen Speicher anheben, der von der
> Holzheizung geladen wird und evtl. später auch von Solar.

Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht 
man üblicherweise mit einem Differenztemperatur-Regler welcher 
Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf 
kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und 
das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die 
Puffertemperatur noch nicht deckend sein, heizt der Heizkessel 
entsprechend seiner Kennlinie nach.


//Niffko

von Rudi (Gast)


Lesenswert?

Hallo,

Niffko _ schrieb:
> Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht
> man üblicherweise mit einem Differenztemperatur-Regler welcher
> Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf
> kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und
> das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die
> Puffertemperatur noch nicht deckend sein, heizt der Heizkessel
> entsprechend seiner Kennlinie nach.

Ja, klassische Zweipunktregelung die den Brenner zum oszillieren bringt 
und ich vermeiden wollte. Ich werde ein "richtiges" Mischerventil 
benutzen und versuchen den Brenner auf Sparflamme zu fahren und nicht 
volle Pulle umschalten. Wenn die Speichertemperatur größer als die 
Sollvorlauftemperatur ist, verbrät mir die Zweipunktregelung zu viel 
Energie.


Grüße.

von Fred G. (sysrun)


Lesenswert?

Hallo :)


Hat hier einer eigentlich mal einen längeren Mitschnitt was sich 
zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil 
eingesteckt hat?

von Fred G. (sysrun)


Lesenswert?

Hoch eine Frage bzgl. KM271-Schnittstelle:


Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu 
benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch 
für die Kommunikation oder?

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Hat hier einer eigentlich mal einen längeren Mitschnitt was sich
> zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil
> eingesteckt hat?

Weiter oben sind doch welche. Das Problem ist eher die Kommunikation 
bzw. Umsetzung von PC<=>SERVICEKEY.


Grüße.

von Rudi (Gast)


Lesenswert?

Fred Granna schrieb:
> Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu
> benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch
> für die Kommunikation oder?

In der Schaltung wird angeblich(tm) der GND verschoben, also alle 
Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen 
Anschluss für einen Abgassensor.


Grüße.

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:

> Weiter oben sind doch welche. Das Problem ist eher die Kommunikation
> bzw. Umsetzung von PC<=>SERVICEKEY.
>
>
> Grüße.

Hm, bin ich blind? Da habe ich einen Log gefunden. Der ist aber nicht 
vollständig. PC<->SK ist doch "nur" 3964R. Frage ist eher: Wie setzt der 
SK da was um.

von Fred G. (sysrun)


Lesenswert?

Rudi schrieb:

> In der Schaltung wird angeblich(tm) der GND verschoben, also alle
> Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen
> Anschluss für einen Abgassensor.
>
>
> Grüße.

ALso könnte der Analogteil eigentlich wegfallen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.