Moin,
wo ihr schon meine RDM-Lib entdeckt habt:
Könnte mal jmd. versuchen, mit demPC-Interface ein offizielles RDM-Gerät anzusprechen? Bislang haben sich ja nur Komponeneten von mir miteinander unterhalten, wodurch Denkfehler von mir im Protokoll unentdeckt geblieben sein könnten...
Ach ja: OpenDMX ist nicht kompatibel zu meiner SW, da Enttec die Schaltung verbockt hat. (Das automatische Port-Turnaround bleibt dort ungenutzt...)
Viele Grüße,
Hendrik
Blade:
man kann auch theoretisch mit einer roten Low-Current LED ein 80m weit entferntes Haus rot anleuchten (komplett 
). Ob das erkennbar ist, ist eine ander Sache :wink:
Ich finde das Projekt nett und würde nicht jedes Wort auf die Goldwage legen und nach Messdaten schreien.
Wenn ich allerdings sehe, wie oft jetzt Wackelköppe mit meiner FW betrieben werden, sollte ich mal Pan und Tilt auf 16bit und Rampen setzen... Hoffentlich wird dann auch die Versorgung weniger zickig.
Viele Grüße,
Hendrik
hier kurz die Zusammenfassung meiner PN:
Hammerschlagreflektor homogenisiert und verteilt den Output eher.
Die polierten bündeln eher.
Ich seh da keine gewaltigen Vor- oder Nachteile bei Strobes.
Eurolite und GENI sind inkompatibel.
Die Sourcen sind aber öffentlich zugänglich und GPL - wer Lust hat, kann ja auf diese Strobes portieren. Auch habe ich gehört, dass jemand mit der neusten SP1500-Revision Probleme hatte. (Ob es an Code oder Hardware liegt, weiß ich nicht - ich kann's ja schlecht nachprüfen...)
Wenn jmd. von Euch mal drübergucken möchte, kann ich hier ja spezifische Fragen zum Ablauf und Aufbau der FW erläutern (aber auf keinen Fall mehr bei Null [Was ist eine ISR, Was sind Fuses, Wie flashe ich richtig,...] anfangen!)
Viel Spaß,
Hendrik
Moin,
bei Thumbnails kann man die Ladezeit drastisch verringern, indem man die großen Fotos mit z.B. IrfanView auf die gewünschte Thmb-Nail-Größe herunterskaliert und diese dann in die Seite einbindet. Ein Klick auf das Tumb öffnet dann das verlinkte große Bild.
So baut sich alles sofort auf und man muss keine 2-3s warten (trotz 16er flat...)
Viele Grüße,
Hendrik
Du meinst, die Offsets einfach nicht statisch lassen sondern permanent zwischen der "Referenz-" und "Slavephasen" nachmessen?
Müsste gehen...
Zu dem 80C537:
Das Teil hat zwar 4 16bit-Timer mit insg. 21 comapare channels - aber bei Sätzen wie "Microcontroller with factory mask-programmable ROM" oder "Microcontroller for external ROM" wird mir etwas mulmig. Ich habe jedenfalls on chip flash memory und in system programming zu schätzen gelernt... Von der Perepherie her ist das Teil aber schon eine schöne Sache.
Viele Grüße,
Hendrik
PWM ist bei Dimmern nicht ganz trivial... Es läuft dabei letztlich auf eine Art Umrichter mit variabler Zwischenkreisspannung hinaus.
Phasenan- und abschnitt kann man beliebig fein abstufen. Das ist höchstens eine Frage der Auflösung des Timers.
Mir geht es in dieser Frage nicht um den Weg des geringsten Widerstandes (3MCUs), sondern um mögliche Ansatzpunkte für eine Lösung mit einer MCU und zu wenig Timern. (Ansonsten würde ich hier ja auch keinen Thread starten, sondern die Geschichte kurz runterschreiben...)
Also aktueller Stand:
Ansatz mit Referenzphase und festen Phasenverschiebungen taugt nichts, da die Verschiebungen nicht fest ist.
Bleibt eine eigenständige Lösung für jede Phase, wobei mein geschilderter Ansatz mit dem Overflow-Problem zu kämpfen hat.
Viele Grüße,
Hendrik
Was ich mit dem Pack schon bereits gemacht habe:
Nulldurchgang mit erster ZC-Detection aufgenommen und Zündpunkt mit zweiter. Delay mit AVR aufgenommen, Mittelwerte gebildet und dabei langsam die Kanäle von 0 bis 255 hochgefadet.
Das Ergebnis war ernüchternd: <100Schritte betrug die Auflösung. (Unter diesen Umständen bringt eine Firing Curve auch richtig was )
Zum guard-Interval:
Dieser Begriff ist mir bislang unbekannt. Ich schätze, Du meinst die Triacs schon deutlich vor ZC zu löschen um ein Flackern zu verhindern. Das wäre bei mir kein Problem da ich in den ersten Schritten derzeit Phasenprüfer dimmen könnte...
Durch diese Keule könnte man ein Flackern bei verschobenen Slave-Phasen verhindern (ein so großes Sicherheitsintervall, dass weit und breit nichts zündet) - Helligkeitsschwankungen bei driftender Referenzphase kriegt man dennoch nicht in den Griff...
Und wie schon gesagt: Ein Ausfall der Referenzphase ist peinlich.
Besser wäre es also deshalb wohl, die Phasen unabhängig voneinander zu betrachten... Wie könnte so etwas aussehen?
Viele Grüße,
Hendrik
Theoretisch hast Du Recht - praktisch kommt man dann aber nicht mit dem Aufbau aktueller Packs mehr klar, da diese halt aus Kostengründen mit einer MCU (und eigentlich zu wenig Timern) arbeiten.
Findet man für diesen technisch gesehenen Unsinn einen vernünftigen Algorithmus, hätte man Zugriff auf günstige HW, deren Firmware man nach seinen Wünschen anpassen könnte...
An sich müsste es eine offensichtliche Lösung geben - ich habe sie nur nicht vor Augen...
Viele Grüße,
Hendrik
Dass Arena und MA so arbeiten, ist mir bewust (und entspricht ja auch meiner ersten Lösung). Die Sache ist schön stabil, redundant und einfach zu realisieren. Aber ca. 1,20EUR/Pack teurer - und deshalb verzichten die meisten aktuellen Mittelklassepacks darauf.
Viele Timer entspricht meiner zweiten Lösung - das Problem ist hier die Verfügbarkeit passender MCUs. In meinem Liteputer steckt ein einziger ATmega8515 und jeder Kanal hat seine eigene Detection. (Und es ärgert mich ziemlich, keinen Schimmer zu haben, wie sie das (trotz äußerst mieser Auflösung) gebacken bekommen.)
Zu LC2412:
Die Frequenz ist im Mittel fest - schwankt aber durchaus etwas kurzzeitig. Bei digitalen Dimmern kann man seine Curve dann an die aktuelle Frequenz anpassen. Die Phasenlage ist spätestens bei Generatorbetrieb mit anderen (komplexen) Lasten nicht mehr fix bei 120° zu sehen sondern schwankt. Du scheinst denselben Denkfehler wie ich damals zu machen...
Viele Grüße,
Hendrik
Moin zusammen,
da mir gerade auffiel, dass es in der Mehrzahl der Threads hier eher um die Reparatur von Fertiggeräten oder Kleinkram geht, möchte ich mal testen, ob auch so ein Thread noch hier funktioniert 
Mir ist aufgefallen, dass die meisten Dimmerpacks auch bei mehreren Phasen mit einer MCU auskommen. Beim Schreiben der 3p-Firmware für meine Packs ist mir aufgefallen, dass die Umsetzung gar nicht so trivial ist.
Mir fallen grundsätzlich folgende Ansätze ein:
1MCU/Phase
+ einfach machbar
- teurer
- gilt nicht :wink:
für jede Phase einen 16bit-Timer
- Es gibt nur wenige (teure) MCUs mit mehr als 2 16bit-Timern
Man lässt einen 16bit Timer als Zeitreferenz kontinuierlich laufen und berechnet die Zündpunkte als aktuelle Zeit +Zündwinkel.
Der Vergleich der Zündzeiten mit der aktuellen Zeit erfolgt möglichst oft in einer Schleife.
- Man trifft in der Vergleichschleife nie den exakten Zeitpunkt sondern eher etwas später, so dass ein Zeitfenster sinnvoll ist. Dieses Konzept scheitert in meiner Theorie beim Überlauf der 16bit-Zeitreferenz.
Man berechnet anfangs die Phasendifferenz und speichert sie als Offsets zur Referenzphase. Nun berechnet man die einzelnen Zündwinkel, addiert ggf. die Phasenoffsets und positioniert alle Zündwinkel auf der Halbwelle der Referenzphase.
+ so arbeite ich bislang mit vernünftigen Ergebnissen und akzeptabler MCU-Auslastung
- ändern sich die Phasendifferenzen (Lastwechsel,...) stimmen die Zündwinkel der Slave-Phasen nicht mehr.
- eine unsaubere Nulldurchgangserkennung wirkt sich auf Grund der höheren aktuellen Spannung auf den Slavephasen ungleich stärker aus.
-> Die Phasen müssen also unabhängig voneinander ausgewertet werden.
Fällt Euch noch eine Variante oder eine Lösung ein?
Viele Grüße,
Hendrik
...war da ...
Moin,
gibt's schon was Neues - oder hakelt es irgendwo?
Ansonsten habe ich grad eine kleine Analyzer Firmware fertiggestellt, die vielleicht auch etwas Klarheit bei manchen Problemen mit DMX bringt...
Viele Grüße,
Hendrik
Die Variante von Manu ist etwas eleganter als ein zweiter Thermoschalter...
Allerdings sind die meisten NTC nicht bis >300°C zugelassen - Was nun?
was Andi (denke ich) meinte:
Wenn die Pumpe nicht im Volumen regelbar ist (AN/AUS), verbraucht das gepumpte Fluid mehr Energie als das Heizelement in der gleichen Zeit zuführen kann.
(Thermodynamisch gesehen ist der Satz Blödsinn - ich weiß...)
Die Lösung:
Für dauernebel die Vibrationspumpe mittels Phasenanschnitt auf 30% regeln. Da wir wahrscheinlich DMXfähig sein möchten, kann das gleich die mcu übernehmen. Die Temperaturüberwachung lieber in HW, nicht dass bei einem unwahrscheinlichen Absturz der Heizblock schmilzt...
Viele Grüße,
Hendrik
Moin, stOne!
Die Idee finde ich sehr genial!!
Was bislang Viele gefragt haben:
Pattern für mehrere Strobes (Lauflichter, wechselnd, Gewitter)
Ein Xfaden der Intensität ist wohl überflüssig.
Möglichkeiten zur realisierung:
a) Einzelblitze an Strobes, gemeinsame Brightness (Du brauchst Dich nicht an normale refresh-Raten halten - 200Hz, kein IDLE und keine Interbyte-Gaps sollten problemlos funktionieren)
b) Du gibst einmal eine Sequenz mit SYNC-Pulsen raus, versorgst alle mit gleicher Geschwindigkeit und Helligkeit. (Durch die Sequenz gibst Du 1Mal die Phasenverschiebung vor und solltest dann Ruhe haben - wahrscheinlich bist Du so aber unflexibler bei den Möglichkeiten für Pattern...)
Was evtl. auch interessant sein könnte wäre eine Tap-Funktion, mit der man die Strobes gezielt auf den Beat legen kann. (Evtl. sollte das aber direkt in den Strobo-Mod selbst rein und von jedem Pult aus ansprechbar. Das wäre dann wohl eher mein Job...)
Falls es irgendwo hakeln sollte: Ich habe die Sourcen mittlerweile unter GPL offengelegt. (ich weiß, dass C lesbarer ist - habe aber einfach nicht die Zeit für einen Port...)
Ich wäre sehr dankbar, wenn ich die Controller-FW / Dein Projekt am Ende verlinken oder sonst zu Deinen Konditionen auf meinen Seiten einbinden könnte.
Ich selbst habe jetzt die LED-Movinglight FW fertig (und die Seiten auch) und werde sie hochladen, sobald ich wieder auf den Beinen bin. (Habe mir gerade was eingefangen...)
Anschließend werde ich dann nach und nach die Sourcen von FW, die seit einem halben Jahr stabil laufen, unter GPL veröffentlichen und dann mal langsam wieder Richtung Laser gehen...
Alles Gute (und sorry für off-topic)
Hendrik
Was willst Du denn mit der PWM-Source?
Für ein Strobe benötigst Du die DMX-Empfangsroutine. Die gibst Du in das Vergleichsregister OCR1A von Timer1 und stellst ihn auf CTC-Mode.
Evtl. noch eine kleine Tabelle im Flash mit den Geschwindigkeiten und ab geht's.
Für mehr Strobes mit Pattern wird es evtl. leicht komplizierter.
Ich denke, Michael oder ich würden das (freie Zeit vorausgesetzt...) in 1-2h runterschreiben.
ich hätte es wohl auch schon gemacht, wenn es dafür ernsthaft Bedarf gäbe - aber in Zeiten von DMX-Strobes...
VG,
Hendrik
Moin,
falls es noch aktuell ist:
Zu Weihnachten lade ich eine neue Version des servo-codes hoch, der entweder 4Servos wie gewohnt steuert oder 2Servos +RGB.
Es gab jetzt paar Mal die Nachfrage und ich dachte das wäre mal eine nette Überraschung...
VG,
Hendrik
definitiv 5Pol.
VG,
Hendrik
...dann hat sich das ja erledigt 
ich werde Dir was für meinen Demux aufmalen und Du kannst es dann auf Deine Geräte übertragen.
Ich meine deshalb eigentlich auch nicht 0-10V sondern 0..-10V - also ein Demux mit negativem Output.
Das müsste eigentlich auch mit einem normalen Demux funktionieren, wenn man auf den Pin mit Bezugspotential (also eigentlich GND) +10V gibt: Die einzelnen Kanäle haben dann in Bezug zu diesem Pin -10V bis 0V.
Voraussetzung ist, dass die OPVs nicht durch Dioden (für HTP-Mix) entkoppelt sind - aber selbst in diesem Fall könnte man noch etwas über Pull-Down Widerstände retten...
Viele Grüße,
Hendrik
