Announcement: there is an English version of this forum on 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.
Angehängte Dateien:
-
EMS_Interface.png
180 KB
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
Angehängte Dateien:
-
vlrl.png
84 KB
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
Ah! Okay, jetzt hats "klick" gemacht! 0x02 ist STX, 0x10 ist DLE, also die Antwort. Dann kann ich ja nun weitermachen :-D
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
Angehängte Dateien:
-
Timeout.png
2,5 KB
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
Angehängte Dateien:
-
RX_EMS.png
84 KB
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.
Angehängte Dateien:
-
delete.png
33 KB
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
IngoF schrieb: > Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link > bringe: Dann darf ich aber auch mal ;-) Beitrag "Re: Logamatic 2107 Schnittstelle"
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.
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?
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
Angehängte Dateien:
-
tiefpass_tx.png
2,3 KB
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>".
Ich sende "0B 88 02 00 06 9A" Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00" uff O.O Warum geht das? Was bedeutet die 0x06 vorm CRC?
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 ?
Rudi schrieb: > Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ? Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram.
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 wir haben jetzt bei einem Telegramm schon mehrere Möglichkeiten: UBA3 V3.2 --------- 10 88 02 00 06 33 08 10 02 00 40 03 02 3d UBA3 V2.7 --------- 10 88 02 00 09 3C 08 10 02 00 40 02 07 3A UBA4 V4.5 / keine Erweiterung ----------------------------- 0B 88 02 00 06 9A 08 0B 02 00 7B 04 05 00 00 00 FC UBAX V 2.4 / SAFE 2.20 / keine Erweiterung ------------------------------------------ TX: 04 08 02 RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00 Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?
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
1 | RX: 04 08 02 00 H MC10 2.04 48 02 04 4B 02 14 00 00 00 |
2 | K SAFe 2.20 4B 02 14 |
Weiter Probiert mit "Offset"; sehr interessant: "0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" "0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93" "0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F" "0B 88 02 00 05 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 7E" "0B 88 02 00 06 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 FC" "0B 88 02 00 08 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 DB" "0B 88 02 00 10 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 00 00 00 00 00 03 44" Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)
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..
YEAH! "0B 88 18 0 255 <crc>" => "08 0B 18 00 3C 02 77 64 17 09 01 25 40 80 00 02 32 80 00 00 7A FF 2D 48 00 C8 00 02 00 B1 00 0D" :-D
Fred Granna schrieb: > Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-) Die maximale Antwortslänge ;-) 09 88 04 05 01 af 08 09 04 05 19 cb 10 88 04 00 0c 21 08 10 04 00 04 1b 03 40 18 19 30 00 00 69 6b 0c 5d
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.
Rudi schrieb: > 10 88 15 00 05 <crc> = 08 0B 15 00 00 3C 01 01 09 <FE> - 10 88 15 00 10 <crc> = 08 0B 15 00 00 3C 01 01 09 48 00 00 <86> > 10 88 1c 00 0b <crc> = 08 0B 1C 00 00 00 00 00 00 00 00 00 00 00 00 <97> Oder hab ich die Frage nicht richtig verstanden?
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.
@ingo
Ich habe eben mal eine Zeile aus deinem Log genommen:
{52} 19:49:38 06.01.11: 10 88 11 18 1B 52
{CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00
CF
Habe dann gesendet "11 88 11 18 1B <crc>"
Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Dann "11 88 11 18 1C <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Und "11 88 11 18 05 <crc>"
Resultat "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
Und "11 88 11 00 1B <crc>"
Resultat "08 0B 11 00 00 00 00 00 00 00 00 00 00 00 00 00 48 00"
@Fred Granna Hast du deine Anlage nicht programmiert (Heizzeiten) ?
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.
IngoF schrieb: > Habe hier mal die beiden Telegramm von Chris_be: > RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 > 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 > 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 So sieht das zerteilt aus: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14 12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00 01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 und > RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A > 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 > 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A 14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15 07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B Ich hab grad weiter oben was zu den Schaltzeiten geschrieben: Ich habe nur Zeiten für HK1 programmiert, die anderen Module übernehmen diese Zeit. Denke mal das wird bei dir genauso sein und daher sind die dann 0x00 ...
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...
Das Ding ist: Die Logs der Kommunikation zwischen ServiceKey und PC helfen nur bedingt. Beispiel: > <TX>04 08 07 (Sendet der PC zum Servicekey) Würde ich nun übersetzen nach "0x0B 0x88 0x07 0x00 0xFF" Das Ergebniss: "08 0B 07 00 0B 01 00 00 00 00 00 00 00 00 00 00 00 FB" > <RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00 (Sendet der SK zum PC) Solche EInzelabfragen sind also wohl kein Problem. Aber es gibt auch solche Anfragen an den ServiceKey: > <TX>04 08 > <TX>04 09 Und da kommen dann 20 Verschiedene Telegramme von 0x08 und 0x09: <RX>04 08 07 00 0B 01 02 00 00 00 00 00 00 00 00 00 00 00 <RX>04 08 18 00 26 01 BF 64 64 19 01 17 01 01 E4 83 00 80 00 02 0F FF 2D 48 00 00 FF 00 00 00 E4 02 82 02 83 73 00 00 2C 00 00 <RX>04 08 19 00 00 59 01 98 02 61 FF FF FF 00 00 BA 78 04 7B 9E 02 EC F8 03 BD D8 00 AB F4 00 00 <RX>04 08 02 00 48 02 04 4B 02 14 00 00 00 usw usw usw.... _Masterfrage_: Wie veranlasse ich die Module ihre kompletten Daten auf einmal auszugeben?
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
Angehängte Dateien:
Guten Morgen, vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein wenig aufklären. Viel Spaß weiterhin.
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.
IngoF schrieb: > Hier mal meine aktuelle Sende/Empfangsschaltung....... Der R6 hat da nichts zu suchen. Der hat sich irgendwann eingeschlichen...
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
Angehängte Dateien:
-
RX_TX_EMS.png
4,8 KB
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 Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück?
Hallo, hier noch bei paar Oszi.-Bilder vom Bus: Beitrag "Re: Logamatic 2107 Schnittstelle" Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle" Beitrag "Re: Junkers HT-Bus Heatronic 3 Schnittstelle" Bis auf den Master senden die Slaves immer nur ein Byte und warten auf das Echo. Grüße.
@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
Ganz vergessen.. Mit dem Alter schrumpft man ja auch ein wenig. Spätestens dann hat Dein "gerademalsodrüberhüpdpferdchen" Probleme :D
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.
Kurze Zwischenfrage: Kann mir einer von euch ein wenig C-Code zur Verfügung stellen? Bekomme das mit dem Software-UART leider nicht richtig hin :-(
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':
1 | 91 00 |
2 | 11 08 1E 00 00 F9 9B 00 |
3 | 01 00 |
4 | 11 00 |
Quittierung 'mittendrin':
1 | 90 00 |
2 | 10 88 11 24 18 29 00 |
3 | 08 10 11 24 36 41 00 E3 8B 01 11 11 2C 00 00 00 04 00 |
4 | 10 88 11 30 0C 15 00 |
5 | 08 10 11 30 36 41 00 E3 8B 01 11 11 2C 00 00 00 4A 00 |
6 | 10 08 35 00 01 01 00 00 |
7 | 01 00 |
8 | 10 88 1C 00 17 5A 00 |
9 | 08 10 1C 00 00 00 00 00 00 00 00 00 00 00 00 62 00 |
10 | 10 00 |
Folgendes ist mir erst kürzlich aufgefallen. Es widerlegt meine These, dass nur Telegramme an den Master(08) quittiert werden und wirft die Frage auf, wer überhaupt quittiert - der Master oder der jeweilige Empfänger!? Ich wäre ja fast für Letzteres.
1 | 90 00 |
2 | 10 11 9D 00 64 B3 00 |
3 | 01 00 |
4 | 10 91 02 00 03 FE 00 |
5 | 11 10 02 00 47 01 01 30 00 |
6 | 10 00 02 00 56 01 06 01 00 |
7 | 10 00 |
//Niffko
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
IngoF schrieb: > Na das wird sich ganz einfach feststellen lassen... ... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^ //Niffko
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.
Angehängte Dateien:
-
3964R-Terminal.jpg
54 KB
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.
Angehängte Dateien:
-
ems_measure.jpg
210 KB
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.
Angehängte Dateien:
-
ems_measure_1_.jpg
200 KB
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.
Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind die Offsets real oder hast Du vertikal verschoben? // Niffko
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?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.