Reparatur Induktionskochfeld: Unterschied zwischen den Versionen
Festi (Diskussion | Beiträge) (Status auf stable geändert. Erfolgsmeldung hinzugefügt) |
|||
| Zeile 11: | Zeile 11: | ||
[[Category:Hardware]] | [[Category:Hardware]] | ||
| − | + | == Intro == | |
Wir haben vor ein paar Monaten ein Induktionskochfeld (AEG 55GAD84AE, PNC 949485702, 68000K-mn, Controller-PCB 629.914-04) gespendet bekommen, das sporadisch den Fehler F13 angezeigt hat. Die ersten Reparaturversuche waren leider erfolglos. Wir haben im Web keine Informationen zu dem Fehler bekommen, AEG hat uns zwar ein paar Datenblätter gegeben - die waren aufgrund des Informationsgehaltes zwar kostenlos, aber darum haben sie uns auch nicht geholfen. Es waren lediglich die Verkabelungen darin zu finden. Wir konnten weitere Fehler erzeugen, indem wir eines der beiden Leistungsstufen abgeklemmt haben. Auch haben wir versucht, die Leistungsstufe mit Netzteil durch eine externe Spannungsquelle zu ersetzen und haben die Controllerplatine nachgelötet... Leider alles ohne Erfolg - der Fehler war einfach mal da und dann wieder weg. | Wir haben vor ein paar Monaten ein Induktionskochfeld (AEG 55GAD84AE, PNC 949485702, 68000K-mn, Controller-PCB 629.914-04) gespendet bekommen, das sporadisch den Fehler F13 angezeigt hat. Die ersten Reparaturversuche waren leider erfolglos. Wir haben im Web keine Informationen zu dem Fehler bekommen, AEG hat uns zwar ein paar Datenblätter gegeben - die waren aufgrund des Informationsgehaltes zwar kostenlos, aber darum haben sie uns auch nicht geholfen. Es waren lediglich die Verkabelungen darin zu finden. Wir konnten weitere Fehler erzeugen, indem wir eines der beiden Leistungsstufen abgeklemmt haben. Auch haben wir versucht, die Leistungsstufe mit Netzteil durch eine externe Spannungsquelle zu ersetzen und haben die Controllerplatine nachgelötet... Leider alles ohne Erfolg - der Fehler war einfach mal da und dann wieder weg. | ||
Im Rahmen einer kleinen Erweiterung haben wir uns das Kochfeld nochmal angeschaut. Diesmal fanden wir einen interessanten [http://forum.electronicwerkstatt.de/phpBB/Reparatur%20Herd_und_Backofen/induktionsherd_aek_68000k_mn_fehlercode_f13_in_der_anzeige-t119497f57_bs0.html Forumsbeitrag]. Dort lag es an einem EEPROM der temperaturabhängig falsche Daten über Mircowire gesendet hat. Wir haben also den 4-KBit [http://ww1.microchip.com/downloads/en/devicedoc/21712B.pdf Microchip 93LC66] EEPROM auf unserer Platine gesucht und ihn mit Kältespray und Heißluft bearbeitet. Der Fehler war nun reproduzierbar! >200 Jahre Haltbarkeit? - jaja... | Im Rahmen einer kleinen Erweiterung haben wir uns das Kochfeld nochmal angeschaut. Diesmal fanden wir einen interessanten [http://forum.electronicwerkstatt.de/phpBB/Reparatur%20Herd_und_Backofen/induktionsherd_aek_68000k_mn_fehlercode_f13_in_der_anzeige-t119497f57_bs0.html Forumsbeitrag]. Dort lag es an einem EEPROM der temperaturabhängig falsche Daten über Mircowire gesendet hat. Wir haben also den 4-KBit [http://ww1.microchip.com/downloads/en/devicedoc/21712B.pdf Microchip 93LC66] EEPROM auf unserer Platine gesucht und ihn mit Kältespray und Heißluft bearbeitet. Der Fehler war nun reproduzierbar! >200 Jahre Haltbarkeit? - jaja... | ||
| − | + | == Reparatur == | |
Nachdem wir den Fehler mit Kältespray und Heißluft mehrere Male erfolgreich reproduziert hatten, haben wir den EEPROM mit Heißluft ausgelötet und über Challenger Clips an einen Arduino angeschlossen. | Nachdem wir den Fehler mit Kältespray und Heißluft mehrere Male erfolgreich reproduziert hatten, haben wir den EEPROM mit Heißluft ausgelötet und über Challenger Clips an einen Arduino angeschlossen. | ||
| − | + | === Auslesen über SPI? === | |
Da das verwendete Microwire-Protokoll sich nicht viel von SPI im Modus 0 unterscheidet, haben wir die ersten Versuche mit der Arduino SPI Library unternommen, um den Chip auszulesen. Wir haben etwas über die mangelnde Arduino Dokumentation geflucht. Mit Hilfe des Oszilloskops war es uns dann aber möglich die korrekte Nutzung der SPI Library zu ermitteln. Warum CS an Pin 10 hängen muss, ist uns aber nicht so klar geworden. Man muss wohl auch die verwendeten Pins selbst auf Output setzen... | Da das verwendete Microwire-Protokoll sich nicht viel von SPI im Modus 0 unterscheidet, haben wir die ersten Versuche mit der Arduino SPI Library unternommen, um den Chip auszulesen. Wir haben etwas über die mangelnde Arduino Dokumentation geflucht. Mit Hilfe des Oszilloskops war es uns dann aber möglich die korrekte Nutzung der SPI Library zu ermitteln. Warum CS an Pin 10 hängen muss, ist uns aber nicht so klar geworden. Man muss wohl auch die verwendeten Pins selbst auf Output setzen... | ||
Die ausgelesen Daten haben wir über USB CDC (Arduino Serialport) übertragen. Etwas seltsam war, dass die Daten nicht mit den erwarteten EGO-Bytes anfingen, obwohl die Struktur der Daten ziemlich gleich war. Außerdem war der ausgelesene Inhalt plötzlich nicht mehr temperaturabhängig. Vielleicht waren die Daten aufgrund einer neueren Version anders?! | Die ausgelesen Daten haben wir über USB CDC (Arduino Serialport) übertragen. Etwas seltsam war, dass die Daten nicht mit den erwarteten EGO-Bytes anfingen, obwohl die Struktur der Daten ziemlich gleich war. Außerdem war der ausgelesene Inhalt plötzlich nicht mehr temperaturabhängig. Vielleicht waren die Daten aufgrund einer neueren Version anders?! | ||
| − | + | === Auslesen und Schreiben mit Bitbang === | |
Im nächsten Schritt haben wir die Daten mehrmals ausgelesen und dann versucht diese zurück zu schreiben. Das hat aber leider nicht geklappt. Die Vermutung war, das irgendein Timing nicht ganz hinhaut. Als erstes wurde dann Bitbang für die Dinge mit außergewöhnlichem Timing versucht (eine extra CLK-Flanke etc.). Leider auch ohne Erfolg. Um noch mehr Kontrolle über das Timing zu erhalten, wurde die Microwire Ansteuerung dann komplett nachgebaut und auf SPI verzichtet. Plötzlich kamen auch die richtigen temperaturabhängigen Daten zum Vorschein (EGO-Bytes). Das Problem mit SPI ist wahrscheinlich das bei selektiertem Chip (CS high) der Clock ein paar Takte mehr läuft. Der Opcode zum Auslesen hat 27-Bit, SPI schickt aber 32 Bit. Aus dem Datenblatt des EEPROMs ist leider nicht ganz ersichtlich, dass das so nicht sein darf. | Im nächsten Schritt haben wir die Daten mehrmals ausgelesen und dann versucht diese zurück zu schreiben. Das hat aber leider nicht geklappt. Die Vermutung war, das irgendein Timing nicht ganz hinhaut. Als erstes wurde dann Bitbang für die Dinge mit außergewöhnlichem Timing versucht (eine extra CLK-Flanke etc.). Leider auch ohne Erfolg. Um noch mehr Kontrolle über das Timing zu erhalten, wurde die Microwire Ansteuerung dann komplett nachgebaut und auf SPI verzichtet. Plötzlich kamen auch die richtigen temperaturabhängigen Daten zum Vorschein (EGO-Bytes). Das Problem mit SPI ist wahrscheinlich das bei selektiertem Chip (CS high) der Clock ein paar Takte mehr läuft. Der Opcode zum Auslesen hat 27-Bit, SPI schickt aber 32 Bit. Aus dem Datenblatt des EEPROMs ist leider nicht ganz ersichtlich, dass das so nicht sein darf. | ||
Der Chip wurde also ein paar mal heiß und gefrostet ausgelesen. Die Daten im warmen Zustand dann zurückgespielt und auf Temperaturstabilität getestet. Anschließend Chip eingebaut und die Platte lief zumindest am Trenntrafo ohne Fehler. | Der Chip wurde also ein paar mal heiß und gefrostet ausgelesen. Die Daten im warmen Zustand dann zurückgespielt und auf Temperaturstabilität getestet. Anschließend Chip eingebaut und die Platte lief zumindest am Trenntrafo ohne Fehler. | ||
| − | + | === Space-Dunkel Problem === | |
Der Trenntrafo kann allerdings nur 1.5A, also wurde die Induktionsplatte am normalen Netz betrieben um etwas H<sub>2</sub>O zu erwärmen. Leider flog mehrmals die Sicherung direkt beim Einstecken. Ein Kurzschluss zwischen den Anschlüßen konnte nicht festgestellt werden. Einmal traf es zusätzlich auch die Hauptschraubsicherung und der Space war für 30 Minuten dunkel (Hauptsicherungskasten leider etwas undokumentiert) :) Bei weiteren Versuchen hat sich der Stecker etwas verändert - muss wohl ein bisschen Strom geflossen sein... | Der Trenntrafo kann allerdings nur 1.5A, also wurde die Induktionsplatte am normalen Netz betrieben um etwas H<sub>2</sub>O zu erwärmen. Leider flog mehrmals die Sicherung direkt beim Einstecken. Ein Kurzschluss zwischen den Anschlüßen konnte nicht festgestellt werden. Einmal traf es zusätzlich auch die Hauptschraubsicherung und der Space war für 30 Minuten dunkel (Hauptsicherungskasten leider etwas undokumentiert) :) Bei weiteren Versuchen hat sich der Stecker etwas verändert - muss wohl ein bisschen Strom geflossen sein... | ||
Der Auslöser wurde dann recht schnell bei einem erneuten Öffnen gefunden. Unter einem FET fehlte das Isolierpad zur Kühlung. Zum Glück ließ sich dieses Isolierplättchen noch im Gehäuse finden. Ist wohl bei einem vorherigen Reparaturversuch etwas verrutscht. Es gab also im eingeschalteten Zustand eine Brücke zwischen Phase und PE. Interessant ist dabei auch, dass der FI nur manchmal geflogen ist und meist die Überstromsicherungen ausgelöst haben. | Der Auslöser wurde dann recht schnell bei einem erneuten Öffnen gefunden. Unter einem FET fehlte das Isolierpad zur Kühlung. Zum Glück ließ sich dieses Isolierplättchen noch im Gehäuse finden. Ist wohl bei einem vorherigen Reparaturversuch etwas verrutscht. Es gab also im eingeschalteten Zustand eine Brücke zwischen Phase und PE. Interessant ist dabei auch, dass der FI nur manchmal geflogen ist und meist die Überstromsicherungen ausgelöst haben. | ||
| − | + | === Reparatur erfolgreich === | |
Schließlich wurde das Induktionsfeld in der neu renovierten Küche verbaut. Dort leistet es seit mehreren Monaten ohne Problem seinen Dienst. | Schließlich wurde das Induktionsfeld in der neu renovierten Küche verbaut. Dort leistet es seit mehreren Monaten ohne Problem seinen Dienst. | ||
| − | + | === Nachbau === | |
Wer das gleiche Problem hat, kann sich gerne an unserem [https://gist.github.com/krisha/fcaaf01534fa0ad9d3da Arduino code] bedienen. Im Code befindet sich auch der funktionierende Dump unserer Induktionsplatte. Es empfiehlt sich aber einen eigenen Dump mit dem Code anzufertigen, da es eventuell Versionsunterschiede gibt. | Wer das gleiche Problem hat, kann sich gerne an unserem [https://gist.github.com/krisha/fcaaf01534fa0ad9d3da Arduino code] bedienen. Im Code befindet sich auch der funktionierende Dump unserer Induktionsplatte. Es empfiehlt sich aber einen eigenen Dump mit dem Code anzufertigen, da es eventuell Versionsunterschiede gibt. | ||
| − | + | == Bilder == | |
<gallery> | <gallery> | ||
File:Induktion_challenger_zoomed.jpg | File:Induktion_challenger_zoomed.jpg | ||
Aktuelle Version vom 3. März 2016, 10:59 Uhr
 Status: stable | |
|---|---|
| |
| Beschreibung | Reparatur AEG 55GAD84AE Induktionskochfeld |
| Autor: | krisha, ffesti, schinken |
| PayPal | 
|
Intro
Wir haben vor ein paar Monaten ein Induktionskochfeld (AEG 55GAD84AE, PNC 949485702, 68000K-mn, Controller-PCB 629.914-04) gespendet bekommen, das sporadisch den Fehler F13 angezeigt hat. Die ersten Reparaturversuche waren leider erfolglos. Wir haben im Web keine Informationen zu dem Fehler bekommen, AEG hat uns zwar ein paar Datenblätter gegeben - die waren aufgrund des Informationsgehaltes zwar kostenlos, aber darum haben sie uns auch nicht geholfen. Es waren lediglich die Verkabelungen darin zu finden. Wir konnten weitere Fehler erzeugen, indem wir eines der beiden Leistungsstufen abgeklemmt haben. Auch haben wir versucht, die Leistungsstufe mit Netzteil durch eine externe Spannungsquelle zu ersetzen und haben die Controllerplatine nachgelötet... Leider alles ohne Erfolg - der Fehler war einfach mal da und dann wieder weg.
Im Rahmen einer kleinen Erweiterung haben wir uns das Kochfeld nochmal angeschaut. Diesmal fanden wir einen interessanten Forumsbeitrag. Dort lag es an einem EEPROM der temperaturabhängig falsche Daten über Mircowire gesendet hat. Wir haben also den 4-KBit Microchip 93LC66 EEPROM auf unserer Platine gesucht und ihn mit Kältespray und Heißluft bearbeitet. Der Fehler war nun reproduzierbar! >200 Jahre Haltbarkeit? - jaja...
Reparatur
Nachdem wir den Fehler mit Kältespray und Heißluft mehrere Male erfolgreich reproduziert hatten, haben wir den EEPROM mit Heißluft ausgelötet und über Challenger Clips an einen Arduino angeschlossen.
Auslesen über SPI?
Da das verwendete Microwire-Protokoll sich nicht viel von SPI im Modus 0 unterscheidet, haben wir die ersten Versuche mit der Arduino SPI Library unternommen, um den Chip auszulesen. Wir haben etwas über die mangelnde Arduino Dokumentation geflucht. Mit Hilfe des Oszilloskops war es uns dann aber möglich die korrekte Nutzung der SPI Library zu ermitteln. Warum CS an Pin 10 hängen muss, ist uns aber nicht so klar geworden. Man muss wohl auch die verwendeten Pins selbst auf Output setzen...
Die ausgelesen Daten haben wir über USB CDC (Arduino Serialport) übertragen. Etwas seltsam war, dass die Daten nicht mit den erwarteten EGO-Bytes anfingen, obwohl die Struktur der Daten ziemlich gleich war. Außerdem war der ausgelesene Inhalt plötzlich nicht mehr temperaturabhängig. Vielleicht waren die Daten aufgrund einer neueren Version anders?!
Auslesen und Schreiben mit Bitbang
Im nächsten Schritt haben wir die Daten mehrmals ausgelesen und dann versucht diese zurück zu schreiben. Das hat aber leider nicht geklappt. Die Vermutung war, das irgendein Timing nicht ganz hinhaut. Als erstes wurde dann Bitbang für die Dinge mit außergewöhnlichem Timing versucht (eine extra CLK-Flanke etc.). Leider auch ohne Erfolg. Um noch mehr Kontrolle über das Timing zu erhalten, wurde die Microwire Ansteuerung dann komplett nachgebaut und auf SPI verzichtet. Plötzlich kamen auch die richtigen temperaturabhängigen Daten zum Vorschein (EGO-Bytes). Das Problem mit SPI ist wahrscheinlich das bei selektiertem Chip (CS high) der Clock ein paar Takte mehr läuft. Der Opcode zum Auslesen hat 27-Bit, SPI schickt aber 32 Bit. Aus dem Datenblatt des EEPROMs ist leider nicht ganz ersichtlich, dass das so nicht sein darf.
Der Chip wurde also ein paar mal heiß und gefrostet ausgelesen. Die Daten im warmen Zustand dann zurückgespielt und auf Temperaturstabilität getestet. Anschließend Chip eingebaut und die Platte lief zumindest am Trenntrafo ohne Fehler.
Space-Dunkel Problem
Der Trenntrafo kann allerdings nur 1.5A, also wurde die Induktionsplatte am normalen Netz betrieben um etwas H2O zu erwärmen. Leider flog mehrmals die Sicherung direkt beim Einstecken. Ein Kurzschluss zwischen den Anschlüßen konnte nicht festgestellt werden. Einmal traf es zusätzlich auch die Hauptschraubsicherung und der Space war für 30 Minuten dunkel (Hauptsicherungskasten leider etwas undokumentiert) :) Bei weiteren Versuchen hat sich der Stecker etwas verändert - muss wohl ein bisschen Strom geflossen sein...
Der Auslöser wurde dann recht schnell bei einem erneuten Öffnen gefunden. Unter einem FET fehlte das Isolierpad zur Kühlung. Zum Glück ließ sich dieses Isolierplättchen noch im Gehäuse finden. Ist wohl bei einem vorherigen Reparaturversuch etwas verrutscht. Es gab also im eingeschalteten Zustand eine Brücke zwischen Phase und PE. Interessant ist dabei auch, dass der FI nur manchmal geflogen ist und meist die Überstromsicherungen ausgelöst haben.
Reparatur erfolgreich
Schließlich wurde das Induktionsfeld in der neu renovierten Küche verbaut. Dort leistet es seit mehreren Monaten ohne Problem seinen Dienst.
Nachbau
Wer das gleiche Problem hat, kann sich gerne an unserem Arduino code bedienen. Im Code befindet sich auch der funktionierende Dump unserer Induktionsplatte. Es empfiehlt sich aber einen eigenen Dump mit dem Code anzufertigen, da es eventuell Versionsunterschiede gibt.
