Haben momentan mit Problemen zu tun, die den externen Quarz betreffen. An einem ATmega328 ist asynchron ein Uhrenquarz mit zwei 22p Kondensatoren angeschlossen, der zur Zeitmessung benutzt wird. Die Platinen werden bei uns bestückt und durch eine Reflowstraße geschoben. Jetzt kommt es immer wieder vor, dass der Quarz mal nicht schwingt, bei manchen Geräten. Wenn ich dann neben den Pads des µC mit einem Messer entlangritze, geht es teilweise wieder --> evtl. mechanische Spannungen. Ich habe bereits ein Reflow Profil aufgenommen, was der Norm entspricht und auch in der Note von Atmel beschrieben ist. Mein Erster Gedanke war, Popcorneffekt, allerdings werden die Chips luftdicht mit einem Entfeuchtersäckchen gelagert. Hat jemand Erfahrungen damit?
Versuchs mal mit 12pF und Quartz nachher einbauen
Manuel schrieb: > An einem ATmega328 ist asynchron ein Uhrenquarz mit zwei 22p > Kondensatoren angeschlossen, Ohne ins Datenblatt gesehen zu haben: externe Kondensatoren sind ggf. nicht notwendig.
Mit 27pF und bei niedriger Spannung kann es vorkommen dass der 32 KHz quartz nicht sofort anschwingt, oder nicht bei jedem Start. u.U. kann es mehrere Minuten dauern.
hi, 22p ist sehr üppig für nen uhrenquarz und hat der mega nicht schon 6p oder sowas drin? auf die schnelle hab ich jetzt im db nichts gefunden. wenn die uhr denn geht, ist sie genau genug nach dem db des quarz? gruß, norbert
Manuel schrieb: > Jetzt kommt es immer wieder vor, dass der Quarz mal nicht > schwingt, bei manchen Geräten. Ist da eine Ultraschallreinigung im Spiel? Das ist Gift für Uhrenquarze, die müssen nachher eingebaut werden. Georg
Manuel schrieb: > An einem ATmega328 ist asynchron ein Uhrenquarz mit zwei 22p > Kondensatoren angeschlossen Was bedeutet hier "asynchron"? Wie ist der angeschlossen?
Manuel schrieb: > An einem ATmega328 ist asynchron ein Uhrenquarz mit zwei 22p > Kondensatoren angeschlossen Für einen Uhrenquarz (gemeint ist wohl ein 32kHz Quarz) soll man gar keine extra Kondensatoren verwenden. Vielleicht mal das Datenblatt lesen? Vorher? XL
Axel Schwenke schrieb: > Für einen Uhrenquarz (gemeint ist wohl ein 32kHz Quarz) soll man gar > keine extra Kondensatoren verwenden. > > Vielleicht mal das Datenblatt lesen? Vorher? hi, ich hatte das oben ja auch angedeutet aber kann immer noch nichts im db finden. wo zum teufel steht das? app-note? gruß, norbert
Hallo, es ist entscheidend was der 32kHz Quarz als Bürde verlangt, ich hatte schon welche die 30pF benötigten und somit mit den interen Kapazität + Leiterplatte zu schnell schwingt.
Norbert S. schrieb: > Axel Schwenke schrieb: >> Für einen Uhrenquarz (gemeint ist wohl ein 32kHz Quarz) soll man gar >> keine extra Kondensatoren verwenden. >> > ich hatte das oben ja auch angedeutet aber kann immer noch nichts im db > finden. > wo zum teufel steht das? Im Datenblatt des ATmega48..328A, Kapitel 9 "System Clock and Clock Options", Unterkapitel 9.3 "Low Power Crystal Oscillator" ist eine Tabelle, die für Quarzfrequenzen unter 900kHz empfiehlt, die externen Kondensatoren nicht zu beschalten. Unterkapitel 9.5 "Low Frequency Crystal Oscillator" gibt die integrierten Lastkapazitäten mit 18pF (Xtal1/Tosc1) bzw. 8pF (Xtal2/Tosc2) an. XL
danke, da war ich ja richtig blind. gruß, norbert
Wenn ich nicht recht entsinne wird über die Fuses eine interne Kapazität eingeschaltet. Es gab lediglich mal eine Serie Atmega8 bei denen ein Fehler diesbezüglich vorlag.
Uwe S. schrieb: > es ist entscheidend was der 32kHz Quarz als Bürde verlangt Axel Schwenke schrieb: > Im Datenblatt des ATmega48..328A Für das Anschwingverhalten ist erstmal einzig und alleine die Angabe aus dem Datenblatt des Quarzes relevant. Wie man das nötige Umfeld durch Schaltungsauslegung und Konfiguration des Prozessors erzeugt, ist erst das zweite Thema.
>Im Datenblatt des ATmega48..328A, Kapitel 9 "System Clock and Clock >Options", Unterkapitel 9.3 "Low Power Crystal Oscillator" ist eine >Tabelle, die für Quarzfrequenzen unter 900kHz empfiehlt, die externen >Kondensatoren nicht zu beschalten. Also bei mir steht 0.4-0.9 MHz. Wenn man von der gängigen Übereinkunft von 32768 Hz für einen Uhrenquarz ausgeht (warum das eigentlich?), dann ist obige Aussage unter 9.3 (CKSEL3=1) hier nicht relevant. Wichtig ist der Satz unter 9.5 (CKSEL3=0) "Crystals specifying load capacitance (CL) higher than 6 pF, require external capacitors applied".
der alte Hanns schrieb: > 32768 Hz für einen Uhrenquarz ausgeht (warum das eigentlich?) teile mal durch 2**5...
an Olaf: Wie wäre es mit 4194304 Hz, wie früher einmal?
Und was Sie mit 1024 Hz anfangen wollen, ist mir völlig unklar.
der alte Hanns schrieb: > Und was Sie mit 1024 Hz anfangen wollen, ist mir völlig unklar. Ich würde es mit 2**10 teilen, um mir einen Sekundentakt zu erzeugen ;-)
der alte Hanns schrieb: > Wie wäre es mit 4194304 Hz, wie früher einmal? Da braucht man ja viieel mehr Teilerflipflops als bei 32768 Hz :-) Mit int16 kommt man da nicht mehr hin.
Verwendet wird dieser hier: https://cdn-reichelt.de/documents/datenblatt/B400/597580-F04.pdf Gerade gesehen: Lastkapazität von Typ. 12,5pF Ich fasse zusammen: Nach der Angabe aus dem Datenblatt des AVR würde ab 6pF ein externer Kondensator Sinn ergeben. Also statt 22p zwei 6p Kondensatoren an jedem Pin des Quarzes richtig? Betrieben wird der µC mit 5V. Vielen Dank
Um nochmal aus das eigentliche Problem zurückzukommen: Komisch ist, dass wenn ich den µC von Hand per Heißluft löte, es noch nie Probleme gab. Wenn ich ihn nach Norm durch die Reflow-Straße schiebe, machen manche Serien diese Probleme. Woran kann das liegen? Verändern sich intern die Kapazitäten?
Ihr solltet einen nehmen, der auch für Reflow_Lötung spezifiziert ist und nicht irgendeinen ...
Keine Ahnung, ob das von praktischer Bedeutung ist, aber meine Berechnung ergibt unterschiedliche Kapazitäten für TOSC1/2; auch passt der maximale ESR nicht ganz. >Wenn ich dann neben den Pads des µC mit einem Messer entlangritze, geht es >teilweise wieder Hängen da Lötreste oder sonst etwas? CKSEL3..1 steht auf 010?
Ist es vielleicht ein Röhrenquarz (Metallröhrchen)? Die vertragen kein Reflow. Nimm einen ordentlichen SMD-Uhrenquarz und pappe 2 5p6-Kondensatoren dran, dann läuft´s auch.
Der Quarz wird nach dem Reflowprozess von Hand eingelötet. Weiter oben steht der Link zum Datenblatt des Quarzes. Werde geringere Kapazitäten mal testen.
Also ist es ein Röhrenquarz. Die können schon vor dem Prozess schadhaft sein, wenn es sich um Schüttgut aus der Tüte handelt. Mechanischer Stress beim Anlöten tut ein Übriges. Löte mal einen anständigen SMD-Quarz ein und Du wirst keine Probleme mehr haben. Hier ein paar Beispiele: http://www.mouser.de/Passive-Components/Frequency-Control-Timing-Devices/_/N-6zu9e?P=1yzmo0zZ1z0z7ymZ1z0zlseZ1yzu7kvZ1yzvlbm
>Also ist es ein Röhrenquarz. Die können schon vor dem Prozess schadhaft >sein, wenn es sich um Schüttgut aus der Tüte handelt. Kann ich nicht bestätigen. Ich habe über die letzten Jahre hinweg ca. 700 Stück vom Typ DT-26 (Reichelt-Best.nr. 0,032768-L6) an ATmega16 verbaut und nie ein Problem damit gehabt (Handlötung).
der alte Hanns schrieb: > Kann ich nicht bestätigen. Ich schon. In dem Bestückungsbetrieb, in dem ich arbeite, gabe es bis zu 25% Ausfall. Wobei ich den Lieferanten nicht kenne. Ich weiß nur, dass das Zeug billig war und in PE-Tüten zu 10.000 Stück geliefert wurde. Wie oft die Tüten auf ihrer Reise aus dem Reich der Mitte bis hier unsanft behandelt wurden, kann ich nicht sagen. Es gab aber auch durch (unqualifiziertes) Einlöten Ausfälle, wo die Quarze zuvor noch in Ordnung waren (durch Eingangsprüfung in Steckfassung bestätigt).
Hallo, ja, Qurze sind halt auch 'mechanische' Bauteile, die durch Schlag oder Sturz kaputtgehen können, das berifft nicht nur Uhrenquarze, die aber besonders, da der eigentliche Quarz bei ihnen recht groß ist. Ich kann mich noch an mein Praxissemester erinnern (Ist aber soch über 20 Jahre her), in der Elektronik-Produktion wurden Quarze unbesehen entsorgt, wenn jemand die Kiste, oder auch die kleine Schütte am Arbeitsplatz, fallen gelassen hatte. Man wollte sich da nicht auf, vielleicht auch später auftretende, Fehlfunktionen einlassen. Mit freundlichem Gruß - Martin
>(unqualifiziertes) Einlöten
Nun ja - ich löte bei 250 °C immer etwa 10 Stück auf einmal, erst
jeweils die einen, dann die anderen Anschlüsse. Es vergeht also eine
gewisse Zeit zum Abkühlen, bis der zweite Anschluss eines Quarzes
drankommt.
Wenn ich nach dem reflow vorgang den fehler feststelle und den mikrokontroller per hand austausche funktioniert alles. Es muss also am mikrokontroller liegen, der durch den reflowvorgang schaden nimmt. Nur kann sich das keiner so richtig erklären.
Manu schrieb: > Wenn ich nach dem reflow vorgang den fehler feststelle und den > mikrokontroller per hand austausche funktioniert alles. Es muss also am > mikrokontroller liegen Das hättest du auch gleich sagen können - 30 Posts für die Katz. Georg
Sind die Kondensatoren jetzt richtig dimensioniert??? Wenn es dann immer noch auftritt kannste wieder kommen.
>An einem ATmega328 ist asynchron ein Uhrenquarz ...
Könnte es auch fehlerhafte Software sein? Z.B. rund um die ...UB-Flags
im ASSR?
Manu schrieb: > Wenn ich nach dem reflow vorgang den fehler feststelle und den > mikrokontroller per hand austausche funktioniert alles. Es muss also am > mikrokontroller liegen, der durch den reflowvorgang schaden nimmt. Nur > kann sich das keiner so richtig erklären. Wenden Sie sich an Ihren Quarzlieferanten/-hersteller. Der kann Ihnen einen für Ihr System passenden Quarz heraussuchen und einmessen. Es bringt nichts, in einem Verbund von Mikrocontroller, Quarz, Stützkondensatoren, Layout, Löt-/Umgebungstemperatur (plus all deren Toleranzen) und parasitären Effekten hier und da ein Bauteil zu tauschen, bis das System wieder (vermeintlich) funktioniert. Die hier oft verbreitete allgemeine Aussage á la "nimm 2x 22p und gut ist" mag für die eine Baugruppe auf dem Basteltisch noch irgendwie funktionieren, ist aber für den gewerblichen Einsatz absolut kein gangbarer Weg.
Ich habe in mehreren defekten systemen die 22p kondensatoren gewechselt auf 6 pf, sie gehen nicht, weder bei hitze noch bei kälte. Erst wenn ich den mikro tausche und ihn programmiere geht alles wieder. Manche serien gehen ohne probleme, auch mit 22ps. An der software kanns nicht liegen, weil sie auf 90 prozent läuft. Reflow profil ist direkt auf dem mikrokontroller (thermoelementt) aufgenommen worden, alle normrichtlinien eingehalten. Der quarz wird von hand eingelötet. Wenn manchmal zwischen den pins geritzt wird, an den der quarz angeschlossen ist, läuft das system manchmal wieder --> spannungen im mikrokontroller? Denke eher an popcorn effekt. Aber die mikros werden mit einem entfeuchterkissen gelagert, mit indikator. Luftdicht abgeschlossen, bin ratlos.
Manuel77 schrieb: > An der software kanns nicht liegen, > weil sie auf 90 prozent läuft. Hut ab, so entwickeln Profis!
Wenn Sie genauso systematisch arbeiten wie Sie hier Ihren Namen und die
Rechtschreibung verwenden, Manuel, Manu, Manuel77 oder wie auch immer...
>An der software kanns nicht liegen
Diese Aussage ist generell gewagt, im Zusammenhang mit dem asynchronen
Timer aber schlicht falsch.
Ich habe gestern wegen Ihnen etwas herumprobiert und einiges seltsames
Verhalten gesehen, welches sich erst nach dem dritten Blick ins
Datenblatt erklärte, Stichwort wie bereits erwähnt ...UB-Flags im ASSR,
aber auch
"... the interrupt will immediately occur and the device wake up again.
The result is multiple interrupts and wake-ups within one TOSC1 cycle
from the first interrupt.",
überhaupt das ganze Kapitel 18.9.
Wird denn immer dieselbe Software aufgespielt, mit denselben Fusebytes?
Was die Quarzthematik betrifft: ATmega328P-PU mit DT-26 auf Steckbrett
läuft mit der reinen Steckbrettkapazität, auch noch mit zusätzlichen 2*
33 pF, benötigt dann aber über 5 s zum Anlaufen (eine große Spielwiese
für den asynchronen Modus).
Manuel77 schrieb: > An der software kanns nicht liegen, weil sie auf 90 prozent läuft. Schon mal dran gedacht, dass in der Software irgendetwas mistig konfiguriert wird und nicht alle Bauteile ausreichend Reserve haben, um den Bockmist so locker weg zu stecken?
Eine gute Gelegenheit, wieder einmal Paul Watzlawick zu zitieren, das letzte Mal ist schon länger her, vielleicht kennt der Eine oder Andere die Geschichte noch nicht, ausserdem ist Wochenende, also: Ein Betrunkener kriecht um Mitternacht auf allen Vieren um eine Straßenlaterne herum. Kommt ein Polizist vorbei: "Sie, was machen Sie denn da?" "Ich suche meinen Hausschlüssel." Jetzt suchen beide. Nach einer Viertelstunde fragt der Polizist "Sagen Sie mal, sind Sie sicher, dass Sie den Schlüssel hier verloren haben?" Antwort: "Nein, nicht hier, sondern dort drüben. Aber dort ist es viel zu dunkel zum Suchen."
Immer wieder schön zu lesen, wie hier Personen von dem eigentlichen Grund, hier zu sein ablenken und einen auf seine Rechtschreibung ansprechen. Ich habe von einem Handy geschrieben, erklärt auch die unterschiedlichen Namen ;) ... Initialisierung des Timers:
1 | //Timer2 |
2 | ASSR |= (1 << AS2); |
3 | TCCR2A |= 0x00; |
4 | TCCR2B |= (1 << CS21) | (1 << CS20); |
5 | TIMSK2 |= (1 << TOIE2); |
6 | sei(); |
Routine:
1 | //--------Timer-------- |
2 | SIGNAL (SIG_OVERFLOW2) |
3 | { |
4 | ... |
5 | } |
Variablen etc. mit volatile definiert. Es sind 8Bitter, also kein atomarer Zugriff nötig. Bevor ihr euch wieder über die Interruptroutine zerreißt, das Programm ist 7 Jahre alt.
Also zum dritten Mal: Wo in Ihrem Code wird auf das Update der Timer2-Register gewartet?
>Immer wieder schön zu lesen, wie hier Personen
Hilfe erwarten, aber unfähig sind oder keine Lust haben, konkreten
Hinweisen nachzugehen und mal ins Datenblatt zu schauen.
Und wenn es seit 7 Jahren läuft, ist ja alles in Ordnung. Ich
verabschiede mich ins Wochenende.
@Hanns: Werde die UB-Flags nächste Woche mal einpflegen. Du meinst nach dem setzen des AS2 Bits auf die UBs warten, richtig?
1 | //Timer2 |
2 | ASSR |= (1 << AS2); |
3 | // Auf UBs warten: |
4 | while(ASSR & 0x1F) |
5 | { |
6 | _delay_ms(1); |
7 | } |
8 | |
9 | TCCR2A = 0x00; |
10 | TCCR2B |= (1 << CS21) | (1 << CS20); |
11 | TIMSK2 |= (1 << TOIE2); |
12 | sei(); |
@Matthias: Auch gerade gesehen, hast du Recht.
Manuel77 schrieb: > An der software kanns nicht liegen, ... Manuel Hupe schrieb: > @Matthias: Auch gerade gesehen, hast du Recht. SCNR
Das kann nicht Ihr Ernst sein! Beispiel, in Assembler, ohne weiteren Kommentar: ldi tmp0,(1<<AS2) ; start asynchron 32768 Hz sts ASSR,tmp0 ldi tmp0,(0<<CS22)+(1<<CS21)+(1<<CS20) sts TCCR2B,tmp0 warten_TCCR2B_update: lds tmp0,ASSR sbrc tmp0,TCR2BUB rjmp warten_TCCR2B_update ldi tmp0,(1<<TOIE2) sts TIMSK2,tmp0 sei Zum zweiten Mal: Lesen Sie das Kapitel 18.9 in Gänze (sowie zumindest 18.11.8), es gibt noch weitere asynchrone Stolperfallen.
Also wie Ihr Programm sieben Jahre lang (offenbar in vielen Systemen) funktionieren konnte, ist mir völlig unklar - das wäre eine eigene Untersuchung wert. Wenn ich hier in meiner Minimalkonfiguration die Warteschleife weglasse, kommt in 3 von 4 Fällen der Interrupt nicht mehr, wohl abhängig von den Startverhältnissen, egal, ob ich einen neuen ATmega328P von 1426 verwende oder einen alten 168 von 0452. Und in dem (oben erwähnten) mittelgroßen System mit ATmega16 ginge generell gar nichts. Das heißt natürlich leider noch lange nicht, dass dies ihr Fehler ist, es ist aber auf jeden Fall eine mögliche Fehlerquelle.
Klar, der oben ergibt wenig Sinn. Habe den Code nur auf die Schnelle zusammengeschrieben. Teste ihn nächste Woche.
1 | //Timer2 |
2 | ASSR |= (1 << AS2); |
3 | TCCR2A = 0x00; |
4 | TCCR2B |= (1 << CS21) | (1 << CS20); |
5 | TIMSK2 |= (1 << TOIE2); |
6 | |
7 | // Auf UBs warten: |
8 | while(ASSR & 0x10) |
9 | { |
10 | _delay_ms(1); |
11 | } |
12 | |
13 | // Interruptflag löschen: |
14 | TIFR2 &= ~(1<<TOV2); |
15 | sei(); |
Vielleicht lag es an der niedrigen Systemfrequenz von 1 MHz, dass der alte Code nahezu immer funktioniert hat.
:
Bearbeitet durch User
Manuel schrieb: > Ich habe von einem Handy geschrieben, erklärt auch die > unterschiedlichen Namen ;) Nein, tut es ganz&gar nicht. Ich schreibe abwechselnd vom drei PCs, einem Tablet oder dem Handy. Und jedesmal mit dem selben Namen. Du solltest nicht immer so schnell naheliegende Ausreden suchen. Ich sehe da ausgeprägte Parallelitäten zu der hier vorliegenden Fehlersuche... Manuel77 schrieb: > An der software kanns nicht liegen, weil sie auf 90 prozent läuft. Aus meiner Erfahrung gilt eher: obwohl manche Software (und/oder Hardware) zu 100% läuft enthält sie noch einige Fehler. Und viele Fehler werden erst durch einen Zufall etliche Jahre später entdeckt... Wenn das Anlaufen eines Systems nicht klappt, dann muss man jeden einzelnen der nötigen Punkte mit dem Datenblatt abgleichen. Und sich nicht beim erstbesten Verdachtsfall ("defekte Quarze") festbeißen...
:
Bearbeitet durch Moderator
Nein, nicht richtig. Das TCNT2 wird ja gar nicht angefasst, das Problem liegt beim TCCR2B, folglich ist das Flag ASSR.TCR2BUB abzufragen: while(ASSR & 0x01) (statt 0x10) oder eben, wie Sie es ursprünglich hatten, 0x1F (auch wenn's hässlich aussieht). Das delay halte ich für unnötig.
>Obwohl manche Software (und/oder Hardware) zu 100% läuft enthält sie noch >einige Fehler. Es ist wie im Richtigen Leben: das System mit der Bezeichnung 'alter Hanns' wird obsolet werden, lange bevor die letzten Fehler darin entdeckt wurden.
Nach langer Zeit habe ich ein defektes Gerät entdeckt und teile euch nun das Ergebnis mit: Das defekte Gerät mit zwei 22p Kondensatoren am Uhrenquarz lief nach alter Programmierung nicht an. Bei der neuen Programmierung lief es allerdings auch nicht an. Nach einem Wechsel auf 6,8p Kondensatoren dann schon. Die Geräte, die auch mit alter Programmierung liefen, liefen auch mit neuer Programmierung, obwohl zwei 22p Kondensatoren verbaut waren. Vielen Dank für die Hilfe, MfG, Manuel
Und wie passt das jetzt zu dem Beitrag vom 29.08.: >Ich habe in mehreren defekten systemen die 22p kondensatoren gewechselt >auf 6 pf, sie gehen nicht, weder bei hitze noch bei kälte. Erst wenn ich >den mikro tausche und ihn programmiere geht alles wieder.
1 | // Auf UBs warten:
|
2 | while(ASSR & 0x01) |
3 | {
|
4 | _delay_ms(1); |
5 | }
|
6 | |
7 | // Interruptflag löschen:
|
8 | TIFR2 &= ~(1<<TOV2); |
Gemeint war das alte Programm ohne den Code.
:
Bearbeitet durch User
Heute ist mir eine Platine untergekommen, wo der Uhrenquarz mit zwei 6,8pF Kondensatoren und neuem Code nicht anläuft. Wenn ich die Platine leicht verwinde, läuft er an. Nach tauschen des µC läuft er sofort an, auch stabil. Wie kann das sein? Der Kontroller kann doch nur im Reflowprozess kaputt gegangen sein.
Löte mal den Controller mit Heißluft nach.. auf die Art und weise habe ich schon einen Großen Teil defekter Elektronik ein neues Leben eingehaucht. Keine Ahnung was Dein Reflowofen so macht.. Gruß, Holm
Zum Thema Reflowofen. Hier einmal das aktuelle Profil, aufgenommen mit einem Thermo-K-Typ, befestigt direkt auf der Platine an der Position wo der µC platziert wird.
Der muss ja auch ganz schön was aushalten bei dir... 5 Minuten über 150°C, 2 Minuten über liquidus... Guck mal die Kurve von Atmel an: http://www.atmel.com/images/atmel-8826-seeprom-pcb-mounting-guidelines-surface-mount-packages-applicationnote.pdf "The time above the liquidus temperature should be around 60 seconds"
Du schriebst auch, durch Kratzen zwischen den Pins mit dem Messer bekommst du die Dinger manchmal wieder zum Laufen. Versuche mal statt Kratzen mit Platinenreiniger intensiv die Flussmittelreste rauszuputzen. Evtl. ist das ja die Ursache.
Easylife schrieb: > Du schriebst auch, durch Kratzen zwischen den Pins mit dem Messer > bekommst du die Dinger manchmal wieder zum Laufen. > Versuche mal statt Kratzen mit Platinenreiniger intensiv die > Flussmittelreste rauszuputzen. Evtl. ist das ja die Ursache. Das werde ich aufjedenfall versuchen, wenn mir das nächste defekte Gerät auffällt. Easylife schrieb: > Der muss ja auch ganz schön was aushalten bei dir... > 5 Minuten über 150°C, 2 Minuten über liquidus... Okay, das wusste ich nicht. Habe mich an diesem Dokument orientiert: http://www.microsemi.com/document-portal/doc_view/131105-solder-reflow-leadfree
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.