Hi, ich habe die Vermutung, daß in einem 50Hz Sinussignal Sprünge auftreten. Leider scheint das nur alle 5-30s zu sein, von daher will ich das erstmal auf dem Oszi nachweisen, daß das wirklich passiert. Erstmal ist das eine PWM mit 4kHz (5V) die den Sinus darstellt, da finde ich das mit dem Oszi natürlich nie. Also erstmal ein RC-Glied mit 10k und 100nF gegen Masse, das ist dann schonmal halbwegs ein Sinus. Jetzt hab ich gedacht einen einfachen Hochpass, 100n in Reihe und dann je 10k nach Gnd und 5V. Das müsste doch mit dem Oszi auf AC gestellt Triggern wenn da mal ein Sprung im Sinus ist aber auch wenn ich das provoziere tut sich da nix. Ich versuche es jetzt mal mit der Pass/Fail Funktion vom Oszi. Sonst irgendwelche Vorschläge wie ich das "fangen" kann? Gruß, Norbert
Andi D. schrieb: > was meinst du mit "sprünge" ? Vermutlich, daß die Software von Zeit zu Zeit mal einen Stützpunkt aus der Sinustabelle überspringt oder ausläßt? Das gäbe dann ein Jittern.
Hi, ich dachte, der Sinus springt z.B. von 120° plötzlich auf 240° oder sowas, Phasensprung könnte man das vielleicht nennen? Jetzt habe ich es 2-3 Mal durch Zufall gesehen. Sieht wohl so aus, daß der Sinus gelegentlich mal plötzöich viel zu langsam ist, vielleicht 20-30Hz für ein paar Perioden oder sowas und dann geht es normal weiter. Passt auch zu dem Problem das die ganze Kiste insgesamt macht. Nur würde ich das gerne halbwegs reproduzierbar auf den Schirm kriegen um das genauer zu analysieren und somit der Fehlerquelle auf die Spur zu kommen. Gruß, Norbert
Ich würde mit einem Logikanalysator die Pulsbreite vermessen. Die einzelnen Breiten kann man dann nach exportieren/importieren komfortabel in einem Tabellenkalkulationsprogramm näher untersuchen. mf
Solche Sprünge können auftauchen, wenn du den Compare Wert der PWM kleiner als den Zählerstand machst, dann haste quasi einmal einen Durchlauf ohne Capture was dann mal min 100% sind. Dafür hat der XMega spezielle Bufferregister, ein normaler Mega hat die nicht Ingo
Norbert S. schrieb: > ich dachte, der Sinus springt z.B. von 120° plötzlich auf 240° oder > sowas, Phasensprung könnte man das vielleicht nennen? alles klar ;) > Nur würde ich das gerne halbwegs reproduzierbar auf den Schirm kriegen > um das genauer zu analysieren und somit der Fehlerquelle auf die Spur zu > kommen. ein oszilloskop ist für sowas relativ ungeeignet..du brauchst irgendeine messkarte o.ä. die dein signal über einen längeren zeitraum aufzeichnet... zB eine NI karte mit Matlab oder LabView... alternativ ein AVR den du als "Logger" umbaust..
Um sowas zu messen ist ein externer Trigger sinnvoll. Wo kommt denn die PWM eigentlich her?
Wilhelm Ferkes schrieb: > Vermutlich, daß die Software von Zeit zu Zeit mal einen Stützpunkt aus > der Sinustabelle überspringt oder ausläßt? Das gäbe dann ein Jittern. Hi, sowas in der Art aber das müssten schon eine Menge Stützpunkte sein. Das müssten aber auch gleich alle 3 Phasen gleichzeitig machen denn danach bleibt es synchron. Sieht aber so aus, ... siehe oben... Da bin ich mit dem Hochpass natürlich völlig falsch. Ich hab das jetzt schon ein paar Mal mit Pass-Fail erwischt aber das Scheissding zeigt den falschen Frame nur ganz kurz und dann kommt noch ein guter Frame und es stoppt. Die "Macke" sehe ich nur ne halbe Sekunde und dann isses weg. Ich fürchte, RTFM könnte eine Lösung sein ;-) Gruß, Norbert
Joachim минифлоть schrieb: > Die > einzelnen Breiten kann man dann nach exportieren/importieren komfortabel > in einem Tabellenkalkulationsprogramm näher untersuchen. Jede Änderung des PWM-Timers zusammen mit dem System-Timer (Zeitstempel) in das serielle FIFO schreiben, welches natürlich reichlich groß sein sollte, und per RS232 an ein Terminal senden, das in eine Textdatei mit schreibt. Dann unter Umständen diese Datei in Excel laden. So würde ich es mit meinen billigen Hausmitteln probieren.
Wilhelm Ferkes schrieb: > Jede Änderung des PWM-Timers zusammen mit dem System-Timer (Zeitstempel) > in das serielle FIFO schreiben, welches natürlich reichlich groß sein > sollte, und per RS232 an ein Terminal senden, das in eine Textdatei mit > schreibt. Dann unter Umständen diese Datei in Excel laden. So würde ich > es mit meinen billigen Hausmitteln probieren. Tja, LA hab ich nicht, nur das Oszi. Ich hab da noch einen M8 auf dem Steckbrett, vielleicht lass ich den das mitplotten und über Uart-USB auf den Rechner schubsen. Das müsste sogar noch für die PWM mit 4kHz gehen. Ich probiere jetzt mal mit dem Oszi auf zu flache Flanke zu triggern. ERWISCHT! Mit dem Trigger auf flache Flanke von dem billigen Rigol DS1052E hat es geklappt. Etwas ausgeholt: Der Takt für den Sinus wird in einem anderen µC erzeugt. Der µC für die PWM ist ein M88 und da er auch die Totzeit macht, hatte ich für den Sinus keinen Timer mehr. Hatte ich hier letztens nach gefragt und das Ergebnis war vorerst, daß extern einzuspeisen. Der M88 kriegt also alle 5° von dem Sinus einen Ping und holt sich den nächsten Wert aus der Tabelle. Ich dachte da wäre der Fehler aber es ist wohl der Ping. Der Sinus ist für etwa 1/4 Periode viel zu langsam und das passt aber sowas von zu der Struktur der Software mit der das Timing gemacht wird... Jetzt ist klar, wo ich den klitzekleinen dusseligen Fehler suchen muß. Ich weiß, daß das mit dem M88 und dem Ping Dreck ist, ein Tiny861 könnte das wunderbar mit der Totzeit machen aber das ging jetzt auf die Schnelle nicht zu ändern. Das ist aber alles nicht so wichtig. Hauptsache ich kann sicher sein, daß der Mist in der Software passiert, das ist immer lösbar. Das hätte auch EMV in der 21kW-Endstufe sein können und da zu messen ist immer sowas von ekelhaft und aufwändig... Danke an alle! Das Problem kann als gelöst betrachtet werden. Gruß, Norbert
Thread beobachten
Seitenaufteilung abschaltenBitte 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.