Hallo zusammen, ich stehe mittlerweile in mehreren Anwendungen vor dem Problem, zu verschiedenen Zeitpunkten verschiedene Aufgaben zu erledigen. Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen werden. Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs betragen. Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den anderen gleichzeitig ändern. (Ein Beispiel wäre zum Beispiel ein dreiphasiger Dimmer mit mehreren Kanälen.) Es wäre nett, wenn Ihr mir etwas weiterhelfen könntet... Was ich bislang betrachtet habe: "soft FM" In einer Timer-ISR hoher Frequenz werden mehrere Zählvariablen dekrementiert. Bei Null wird die Aktion ausgeführt und der nächste Zeitpunkt geladen. Nachteil: hohe CPU-Belastung, schlechte Genauigkeit der Zeitpunkte (der genaue Wert muss auf die ISR-Frequenz "quantisiert" werden...). "Zeitpunkte sortieren und jeweils nächsten in das Compare-Register laden" Im Hintergrund wird jeder neue Zeitpunkt einsortiert oder jedes Mal das komplette Array durchsortiert (worst case Betrachtung entscheidet). Nach dem Update wird der Pointer für die ISR auf das neu sortierte Array gesetzt. Nachteil: Wenn ich zu dem aktuellen Timerwert die Verzögerungszeit addiere und es zum Überlauf kommt, arbeitet die Sortierung falsch. (Der Timer steht aktuell auf 0xFF00 und ich möchte in 0x10F Ticks etwas tun, so wird 0x10 vor z.B. 0xFF10 einsortiert, was aber zuerst erreicht wird...) "verlinkte Liste" Ich halte dies derzeit für eine elegantere Variante der eben genannten Sortierung. Ich befürchte allerdings dasselbe Problem mit Überläufen... Es ist allerdings gut möglich, dass ich bei dem Bilden der Offsets zu vorigen Zeitpunkten einen Denkfehler mache. Viele Grüße, Hendrik
Klingt interessant, aber was passiert beim nächsten Softwareupdate? Verschiebt sich alles, reichen die Zeiten noch? Meine innerste Stimme sagt: Ein Atomkraftwerk würde ich damit nicht steuern wollen, höchstens eine Puppenstube. Jedenfalls würde ich noch irgendeine Plausibilitätsprüfung am Ende einbauen, um zu erkennen wenn das System hängt.
@oszi: häh? Der Zeitdauer eines Delays wird bei >100µs liegen. Von daher bleibt etwas Zeit zum Rechnen. Ansonsten würde 30kW nicht in eine Puppenstube einbauen. Als Scheduler misbraucht, möchte ich einen Einsatz in "interessanteren" Steuerungen auch nicht ausschließen. ===== Nach dem ich den Post tippte, fiel mir auf, dass das Arbeiten mit Offsets evtl. doch funktionieren könnte, da ich niemals den absoluten Timerstand beim Auslösen vor der Sortierung bilden muss -> keine Überläufe, keine Fehlsortierung...
>Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen >werden. >Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs >betragen. Wenns im us Bereich sein muss würde ich das ganze gleich sein lassen. Beispiele (Befehle mit mehreren Takten mal vernachlässigt): ATMega mit 4MHz 250ns pro Befehl 4 Befehle pro us ATMega mit 16MHz 62.5ns pro Befehl 16 Befehle pro us So, nun rechnest du mal aus wieviele Befehle du zwischen deinen Zeitpunkten zur Verfügung hast und schätzt dann mal ab ob das überhaupt geht. >(Ein Beispiel wäre zum Beispiel ein dreiphasiger Dimmer mit mehreren >Kanälen.) Da reichen sicherlich auch ms.
@ Henne (Gast) >Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen >werden. >Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs >betragen. >Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den >anderen gleichzeitig ändern. Tja, das kann mn wohl auf gängigen Mikrocontrollern vergessen, wie dummy richtig bemerkte. Das braucht echte Hardware, entweder als FPGA/CPLD oder Timermodul. Der 683xx hat sowas glaub ich, nennt sich TPU, Time Processing Unit. MFG Falk
@Falk, dummy: Bei 50Hz beträgt die Dauer einer Halbwelle 10ms. Bei 255 Werten/Halbwelle und entsprechenden Korrekturtabellen ist man bei <40µs. Arbeitet man mit mehreren Phasen wird es noch einmal enger... Derzeit habe ich noch Hoffnung, da ich die Zündzeitpunkte kurz nach dem Nulldurchgang kenne und bis zum ersten Anschnitt gut 200µs Zeit habe. Derzeit werkelt auch schon ein 3p-Dimmer von mir nach dem zweiten Prinzip (Sortierung). Der Nachteil war nur, dass ich mit festen Phasenverschiebungen rechnete und alle Zündzeiten auf eine Halbwelle runterrechnete. (So umging ich das Überlaufproblem ;-) Einige Leute haben aber nun das Problem, dass bei extremen Belastungen die Phasenveschiebungen variieren und somit Scheinwerfer an den "Slavephasen" flackern, da die Nulldurchgänge nicht mehr exakt getroffen werden. http://www.hoelscher-hi.de/hendrik/light/dmxdimmii.htm Ich hatte nun die Hoffnung, dass ein Forum voller Experten intelligenter ist, als ein einzelner Maschi... Viele Grüße, Hendrik
@ Henne (Gast) >Werten/Halbwelle und entsprechenden Korrekturtabellen ist man bei <40µs. >Arbeitet man mit mehreren Phasen wird es noch einmal enger... Kann man lösen, siehe Soft-PWM. Das ist aber MEILENWEIT von dem Problem entfernt, welches du nebulös skizziert hast. >Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen >werden. >Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs >betragen. >Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den >anderen gleichzeitig ändern. >Einige Leute haben aber nun das Problem, dass bei extremen Belastungen >die Phasenveschiebungen variieren und somit Scheinwerfer an den >"Slavephasen" flackern, da die Nulldurchgänge nicht mehr exakt getroffen >werden. Naja, dann braucht man halt für jede Phase eine Nulldurchgangserkennung. Entweder clever über den einen ICP, denn die Phasen sind ja auf jeden Fall ~120 Grad zueinander versetzt, oder über drei kleine 8-Pin AVRs, die einzeln die Phasen steuern, die können ja an einem DMX- Receiver hängen. >Ich hatte nun die Hoffnung, dass ein Forum voller Experten intelligenter >ist, als ein einzelner Maschi... Woraum du einen lassen kannst, selbst wenn es der beste Maschi der Welt wäre . . . MFG Falk
@Falk: Stimmt - die dritte Variante mit der Sortierung könnte funktionieren, da auch mit Offsets gearbeitet wird. Da hatte ich mich damals verguckt und absolute Werte in Erinnerung. Danke! Die Annahme einer konstanten Phasenverschiebung von 120° scheint nicht immer zuzutreffen*, da einige Leute bei starken Lastwechseln oder an Dieselaggregaten Probleme hatten. (Ich konnte es leider nicht verifizieren und es scheint auch nur bei Wenigen aufzutreten.) Die nebulöse Umschreibung kam daher, dass die Geschichte wohl auch bei anderen Aufgaben (einen Haufen Stepper, LEDs,...) nützlich sein könnte und der Dimmer nur das Nächstliegende war ;-) Der Ansatz einen Stapel Slave-AVRs einzusetzen ist zwar gängig - aber irgendwie auch unsportlich... Viele Grüße, Hendrik *alternativ kann auch kurzfistig die Frequenz schwanken. Das hätte denselben Effekt, da ich mit zeitlichen Offsets von 120° bei 50Hz Netzfrequenz rechne.
@ Sebastian B. (mircobolle) >Ich habe den Thread nur überflogen, konnte aber dein exakten >Randbedingungen nun nicht direkt erfassen. Dieser Fehler wird gern und häufig gemacht. Nicht gut, wie man mal wieder sieht. >Und du benötigst nun einen Scheduler mit Echtzeitanforderungen im us >(Mikrosekunden) Bereich. Jaja, sonst noch was? Lies mal den Thread in RUHE. MFg Falk
@ Henne (Gast) >Die Annahme einer konstanten Phasenverschiebung von 120° scheint nicht >immer zuzutreffen*, da einige Leute bei starken Lastwechseln oder an >Dieselaggregaten Probleme hatten. (Ich konnte es leider nicht >verifizieren und es scheint auch nur bei Wenigen aufzutreten.) Nun, das sollte man schon mal abklopfen oder halt ignorieren. Es könnten auch Probleme bei der Erkennung des Nulldurchgangs sein. Denn so dolle ist die 0815 Optokopplerschaltung nicht. >Der Ansatz einen Stapel Slave-AVRs einzusetzen ist zwar gängig - aber >irgendwie auch unsportlich... Warum einfach, wenns auch umständlich geht ;-) >*alternativ kann auch kurzfistig die Frequenz schwanken. Das glaub ich kaum. Ausserdem muss der Dimmer sowieso JEDE Vollwelle neu synchronisieren. In dieser Zeit läuft die Phase keinesfall um mehr als ein paar us weg. MFg Falk
@Sebastian: Es sind drei Phasen. Aber nach Deinem Post entspräche ein Kanal einem Prozess. Rechne mit 3..12 Kanälen. Jeder Prozess würde 100Mal/s einen Triac zünden. Allerdings ist die Phasenverschiebung der einzelnen Prozesse zueinander variabel und abhängig von Nulldurchgang und gewünschter Helligkeit. Das ist aber eine sehr verdrehte Beschreibung des Ablaufes... Ich denke, dass ich mit der 3.Soft-PWM meinen Ansatz gefunden habe. Viele Grüße, Hendrik
@Falk: Es wird jede Vollwelle synchronisiert. Ich spiele blos mit dem Gedanken, die Periodendauer zu messen und darüber Phasenverschiebungen und Zündwinkel permanent nachzujustieren.
@Sebastian: Prinzipiell hat Falk Recht, wie Du beim Überfliegen feststellen wirst. Die Lösung wird wohl auch ein Hybrid aus einem Scheduler und der Soft-PWM sein. Es lohnt sich nicht, sich wegen sowas in die Haare zu kriegen...
@ Henne (Gast) >Ich spiele blos mit dem Gedanken, die Periodendauer zu messen und >darüber Phasenverschiebungen und Zündwinkel permanent nachzujustieren. Wozu? Die Netzfrequenz schankt nur im Promillebereich, das kann man in den Skat drücken. Und wenn jemand an nen 1kW Generator 2KW Lampen hängt und damit die Frequenz jenseits von Gut und Böse liegt ist das einfach Pech. MFG Falk
@Falk: Na ja - gegen Ende meiner Schulzeit hatten wir mal eine größere Feier in einem Gewächshaus, das über zwei Gasturbinen versorgt wurde. Man konnte hören, wie die Drehzahlen passend zu den Bässen der PA schwankten und die Spannungen um >20V einbrachen. Ich befürchte, dass Generatoren grundsätzlich mit der Nennleistung klarkommen aber mit Lastwechseln Probleme haben. Die Frequenzabweichungen im normalen Netz werde ich mir mal morgen auf ein LCD ausgeben lassen. Ich habe sie kurzzeitig als deutlich größer in Erinnerung.
Die Frequenzabweichungen im "normalen Netz" sehe ich nicht so groß, eher fallen auf dem Oszi die versauten Sinuswellen durch Schaltnetzteile, Tyristoren usw. auf. Wenn diese verkrüppelten Sinuswellen dann ausgewertet werden, könnten schon merkliche Differenzen auftreten zum Idealfall!
Och, da gibt es noch viel schönere Sachen. Ich habe derzeit Standard-Dimmer am Laufen (Bausatz von Conrad), die immer zu gewissen Zeiten flackern, aber nicht wenig. Man hat manchmal den Eindruck, dass nicht nur eine Halbwelle fehlt, so extrem ist das. Richtig extrem wird es gegen 22:00 Uhr, danach ist wieder Ruhe. Meine Vermutung sind Rundsteuersendungen, allerdings blieb meine Anfrage beim örtlichen Energieversorger ohne Erfolg... Deshalb hatte ich irgendwann (wenn ich mal Zeit habe, also nie fg) mal vor, einen Dimmer mit einem AVR zu basteln, der derartige Störungen rausrechnet (plausibilitätskontrolle des Nulldurchgangs, Fehlerkorrektur durch Berechnung des Zündpunkts aus den vorhergehenden)
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.