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
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.
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.
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
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.
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
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.
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.
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
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 ?
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 ?
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
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.
@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.
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.
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.
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
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
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.
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
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
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.
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
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.
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 :-/
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
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?!
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
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 .. .. ......
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
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!
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.
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 ;-).
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?
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
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
;-)
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
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
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
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.
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...
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
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.
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
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.
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
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.
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.
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
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
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
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.
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.
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.
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
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
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.
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
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
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?
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
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.
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.
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
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
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.
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.
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.
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?
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
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 ;-)
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"
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.
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...
Moin,
hat eigentlich schon jemand eine richtige Abfrage auf den EMS-Bus
gemacht? Ich meine jetzt nicht einfach ein Byte auf eine Pollinganfrage
senden :)
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>".
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 ?
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
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
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.
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
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...
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
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...
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..
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
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.
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
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..
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.
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
@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.
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
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.
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:
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.
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
Rudi schrieb:> Hast du deine Anlage nicht programmiert (Heizzeiten) ?
Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese
Einstellung.
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...
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.
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....
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...
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
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
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
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?
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 ?
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...
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
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.
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
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
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.
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ß
@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.
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.
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
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
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.
@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
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.
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
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
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
?
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
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
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.
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...
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 ....
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
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
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
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.
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.
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.
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.
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
> 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.
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
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.
@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.
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
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.
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
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':
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.
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
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:
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
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
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
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.
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
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
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
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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
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.
Hallo :)
Hat hier einer eigentlich mal einen längeren Mitschnitt was sich
zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil
eingesteckt hat?
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?
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.
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.
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.
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?
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