A new Pi5 sells for 90€ these days. You can easily find a very potent used shuttle PC on ebay for 90€.
This is what I would suggest: Search a litte on ebay for used shuttle PCs. If necessary upgrade from HDD to SSD and you will have plenty of computation power. Also you don't need a lot of disk space. Like 128 GB is plenty.
Also das kommt ganz drauf an wer der "Kunde" ist. In letzter Zeit waren das bei mir immer Freunde/Verwandte und dann stehen da halt 0,- € auf der Rechnung. Da bin ich auch recht großzügig was den Kreis der Leute angeht der 100% Rabatt kriegt. Weil bei mir ist das ganz klar ein Hobby ohne jegliche Ambitionen jemals schwarze Zahlen zu machen und weil es mir schwer fallen würde gewissen Leuten "Rechnungen zu stellen". 
Ansonsten ist natürlich die Frage was dir deine Arbeitszeit wert ist bzw. wert sein muss falls du davon leben willst. Mal zum Vergleich ein paar meiner Meinung nach mindestens übliche Stundensätze:
Hilfskraft ca. 40€, Fachkraft ca. 55€, Meister/Techniker ca. 75€. Tagessätze häufig 10x, zzgl. Überstünden und Nachtzuschläge
Wenn ich mir jetzt mal z.B. eine kleine Hochzeit vorstelle mit wenig Vorbereitungsaufwand weil mal z.B. auf bestehende Projekte und so zurückgreifen kann und wir mit 55 €/h rechnen:
6h Vorbereitung, 4h Aufbau, 10h Veranstaltung, 2h Abbau macht 22h also 1210,- €
Fahrtzeiten und -kosten, Zeit die Sachen zu Hause zu sortieren etc. noch nicht berücksichtigt. 
Wenn ich jetzt zu "normalen Leuten" hingehe und sage ich will nur für meine Dienstleistung "Licht machen", weil über Gerätemiete haben wir ja noch gar nich gesprochen, 1200€ haben ist das Gespräch meiner Erfahrung nach sofort beendet.
Für einen DJ mit Tontechnik so wie viel Geld locker zu machen fällt vielen Leuten gefühlt einfacher. Ich glaube einfach die "Wertschätzung" für das Licht ist geringer als für den Ton. Ich denke besonders hier im Forum sind wir ja schon etwas die "Lichtnerds" und ich glaube auch hin und wieder etwas blind dafür wie wenig wichtig oder sichtbar oder ausschlaggebend unsere Arbeit mit dem Licht ist. Meine subjektive Erfahrung aus vielen Situationen in denen ich mir schon auch arg Mühe gemacht hab, dass Details gut sind einfach weil es mir halt wichtig ist aber andere Menschen u.a. auch Veranstaltungstechniker das nicht so nachempfinden konnten.
In früheren Jahren habe ich privat genau solche Veranstaltungen bereut und unter Nutzung meines eigenen Equipments (ausreichend Ton, Partylicht) zwischen 500 und 800€ pauschal genommen zzgl. evtl. Anmietung von Geräten aber inkl. allem also auch Ton und DJ. Rundumsorglospaket. In der Größenordnung bewegt sich meiner Meinung nach immernoch der Betrag der "normale" Hochzeitspaare bereit sind zu zahlen. Normal in dem Sinne, dass es halt keine 75 k€ Hochzeit auf nem Schloss ist.
Wichtiger Hinweis: Enduhrzeit verbindlich regeln! 
Ich hoffe meine Erfahrungen sind hilfreich. Das ganze Thema sieht natürlich ganz anders aus, wenn man da ein langfristiges Geschäft mit machen will. Oder Geschäftskunden oder die öffentliche Hand als Kunden hat.
Ich hatte auch schon zwei mal die Gemeinde als Kunde. Denen war das jetzt nicht komplett egal was das kostet aber das Geld saß gefühlt schon locker. Viel wichtiger war dort das Vertrauen der Entscheidungsträger, dass das was Gutes wird und sie ein Rundumsorglospaket bekommen. Und das mein ich echt so nach dem Motto "Hier, nimm mein Geld und kümmer dich um alles Technische" 
. Und das erleb ich auch aktuell bei meiner Arbeit an einer Hochschule auch, dass öffentliche Entscheidungsträger häufig zu einer Lösung tendieren mit der das Thema schnellstmöglich weg vom Schreibtisch ist, aus ihrer Perspektive fertig und Verlass darauf ist, dass die Lösung passt.
Lg
Martin
Boar, danke.
Das hätt ich nie gefunden.
Hallo Zusammen,
ich habe ein paar Lauflichter erstellt und dazu mehrere Cuelists angelegt, die als Taktquelle alle den gleichen Speedmaster haben.
Alle Cues in den Cuelists haben als Auslöser Beat, keine Einblendzeiten oder sonst was. Das geht einfach hart an und aus und sie wiederholen sich nach der letzten Cue.
Diese Cuelists sind alle in einer Cuelist-Group, wobei eingestellt ist, dass immer nur eine Cuelist aktiv ist.
Folgendes Szenario:
Die erste Cuelist läuft. Auf jeden Beat schaltet es eine Cue weiter.
Jetzt starte ich eine andere Cuelist aus der Gruppe. Die erste Cuelist wird sofort beendet. Es wird daher dunkel.
Erst wenn der nächste Beat kommt "startet" die zweite Cuelist und es wird wieder hell.
Irgendwelche Ideen wie ich dieses "Dunkelwerden" beim Wechsel der Cuelists vermeiden kann?
Idealerweise würde der alte Wert einfach stehen bleiben bis zum nächsten Beat wenn dann die neue Cuelist übernimmt.
Kann man irgendwie einstellen, dass die erste Cuelist erst beendet wird, wenn die neue Cuelist tatsächlich neue Werte setzt?
Bei der 2er Version hatte ich das Problem nicht, weil da war der Beat ja quasi das Signal zur Cue beenden.
In der 3er ist der Beat aber das Signal zum Cue beginnen...
Eine Alternative zu OS2L wäre auch MIDI.
Das hier hab ich gemacht, weil ich viel freier in dem bin was Virtual DJ und DMX Control austauschen.
Ich habe hier auch mein aktuelles Device und Mapping angehägt.
Das ist mittlerweile etwas umfangreicher als in dem Post.
Ich mache grade eine wie ich finde interessante Beobachtung:
Wenn ich die Ansteuerung der Dimmer auch "virtualisiere" und über ein Dummy Gerät einen ParameterMaster und der ParameterMaster dann das tatsächliche Geräte ansteuere sehe ich kein Flackern mehr. Zumindest hab ichs jetzt mal sehr konzentriert ne halbe Stunde angeschaut.
Der Unterschied zu "mit ParameterMaster" oder "ohne" ist aber sofort ersichtlich.
Hier mal noch ein Bild zum ganzen Aufbau.
Die 1...4 sind DMX Mixer Nodes. Diese beziehen sich auf "Dummy"-RGB Geräte. Diese DummyRGBs werden über eine Cuelist angesteuert, die auf SpeedMaster1 triggert.
Diese vier DummyRGBs sind an vier ColorMaster angeschlossen. In den realen Geräten mappe ich jetzt nur noch die Farbe auf ColorMaster1...4. Diese Mapping ist zunächst mal statisch. Aber könnte sich natürlich auch über Cuelists ändern.
Auf dem Stand von einem ersten Post wurden nun noch die Dimmerkanäle der realen Geräte über eine Cuelist angesteuert, die auch auf SpeedMaster1 triggert.
Anders als in meinem ersten Post habe ich nun auch Dimmerkanäle über Master angesteuert.
Die 5 und 6 sind DMX Mixer Nodes, die sich auf einen "DummyDimmer" beziehen. Auch diese DummyDimmer werden über Cuelist angesteuert, die auf SpeedMaster1 triggert.
Die Dummy Dimmer sind an zwei ParameterMaster angeschlossen. Und in den realen Geräte mappe ich auch hier nur noch den Dimmerwert auf ParameterMaster1 oder 2. Auch dieses Mapping ändert sich erstmal nicht.
Wenn ich beide Signalwege, also den für Farbe und den für Dimmer auf diese gleiche weise abstrahiere, flackert es nicht mehr.
Ich hab iwie den DMX Mixer oder die ParameterMaster im Verdacht.
Ist da was dran?
Sry für die unpräzise Ausdrucksweise.
Ja, alles Cuelists. Die einzelnen Cues triggern auf Beat. Alles Cuelists auf den gleichen Speedmaster gelegt.
Hallo,
ich glaube der Titel klingt etwas philosophisch aber lasst mich erklären:
Ich habe für Tanzveranstaltungen immer gerne einen Haufen Cuelists, die Farbchaser machen und einen zweiten Haufen Cuelists, die die Dimmerkanäle ansteuern. Von diesen beiden Haufen läuft immer je eine Cuelist und dann kann bissl kombinieren und recht viel Abwechslung aus wenig Programmieraufwand schaffen.
Mit der 3.3er bin ich dazu übergangen die Farbchaser zunächst mal ColorMaster ansteuern zu lassen und dann diese ColorMaster mittels "Mapping Cues" auf die Geräte zuzuweisen. Also noch mehr Kombinationsmöglichkeiten...
Sowohl die Farbchaser als auch die Dimmerchaser sind beatgetriggert, bzw. die Cuelists hören auf den gleichen SpeedMaster.
Jetzt habe ich aber das Problem, dass wenn ein Beat kommt häufig der Farbchaser und Dimmerchaser nicht exakt im gleichen Moment "weiterschalten". In diesem Beispiel ist der Dimmerchaser immer ein bisschen schneller als der Farbchaser. Vermutlich weil ich so kompliziert über ColorMaster gehe und die Berechnung eben dauert. Das führt aber im Umschaltmoment zu einem recht unschönen Flackern. Ich vermute die einzelnen Cuelists werden asynchron abgearbeitet und am Ende kommen die Signale eben dann wenn sie kommen am Mixer an und es geht raus aufs Interface.
Die "einfache" Lösung wäre vermutlich alles was wirklich gleichzeitig sein soll in eine Cuelist zu packen. Aber dann kann ich eben nicht mehr kombinieren.
Ich hätte mir gewünscht, dass alle Berechnungen die von einem Ereignis abhängen, abgeschlossen werden müssen, bevor das nächste DMX-Frame ausgegeben wird.
Im Moment berechnet DMXC die Werte einfach zyklisch und nicht ereignisbasiert oder?
Das dürfte reichlich kompliziert sein gemischte zyklische und ereignisbasierte Werteberechnung zu haben. Ein möglicher Ansatz wäre vllt alle Signalpfade zu flaggen, die von einem Ereignis abhängen. Tritt ein Ereignis auf, könnte solange noch der alte DMX Wert weiter zyklisch ausgegeben werden, bis alle relevanten Signalpfade "fertig berechnet" melden und erst dann wird für alle betreffenden Signalpfade die neuen Werte geschrieben.
Hat jemand sonst noch eine Idee, wie ich unterschiedliche Cuelists zu einer gleichzeitigen Ausgabe bringen kann?
Lg
MWSysTech
Meine Güte, jetzt komm ich mir dämlich vor.
Ich war einfach nicht auf die Idee gekommen einer Lampe was anderes als Helligkeitswerte zu verbinden.
Danke für die Erleuchtung.
Der Vollständigkeit halber hier ein Bilder für alle die sich in Zukunft fragen wie das geht:
Hallo Leute,
gibt es irgendeine Möglichkeit per Input Assignment eine Farbe auf dem Softdesk darzustellen?
Z.B. würde ich einen Colorpicker auf den aktuellen Farbwerts eines Gerätes springen lassen. Colorpicker sind aber reine Eingabeelemente.
Hab ich was übersehen wie das gehen könnte?
LG
MWSysTech
Hallo an das Entwicklerteam,
erstmal vorweg: Ich habe euer gRPC Special sehr interessiert verfolgt, weil ich selbst damit beruflich zu tun habe.
Ich will mir gar nicht ausdenken was für ein Aufwand das sein muss quasi den kompletten "Unterbau" von DMX Control auszutauschen.
Dieser Beitrag hat zumindest bei sehr dazu beigetragen, dass ich besser nachvollziehen kann "warum das mit der 3.3er denn so lange dauert".
Und das gRPC war ja nur eine der großen Baustellen, die ihr angesprochen habt.
Trotzdem bin ich sicherlich nicht der einzige hier im Kreis der Nutzer, der schon sehnlich auf die 3.3er wartet.
Bei mir persönlich liegt das vor allem am Timecode Player.
Vielleicht an der Stelle: Gibts eine aktuelle Prognose zum Release? 
Ich möchte folgenden Vorschlag in den Raum stellen:
Könntet ihr euch vorstellen die Beta Versionen nicht nur dem Kreis der Beta-Tester, sondern öffentlich zugänglich zu machen.
Vielleicht könnte man die aktuellste Beta Version einfach auch auf der Download Seite anbieten.
Aber mit dem deutlichen Hinweis eben, dass das eine Beta-Version ist und die Leute froh sein sollen, dass sie überhaupt die Beta-Version kriegen und sich nicht wundern brauchen wenns mal kracht.
Also einfach der deutlich Hinweise, dass hier keinerlei Gewähr oder Support geboten wird. Damit würde bei euch im Team hoffentlich kein weiterer Aufwand entstehen. Außer eben die Version zum Download zu stellen.
Wir als Nutzer, die auf einige Funktionen warten hätten dann aber wenigsten die Wahl ob wir uns mit 90% fertig zufrieden geben wollen oder eben die 100% abwarten.
Und zumindest von außen betrachtet wirken die Beta-Versionen mit denen u.a. die Videos und Livestreams gedreht werden schon zum Teil besser als 90% fertig. 
Ich habe hier im Forum schonmal bisschen zu dem Thema geschaut und festgestellt, dass ihr als Team euch eure Beta-Tester sehr gut aussucht.
Das kann ich auch gut nachvollziehen, weil gut Beta-Testen ist eben eine richtige Arbeit.
Aber ich kenne das von viel anderer freier Software und sogar der ein oder anderen bezahlten Software, dass eben der stabile Build klar empfohlen wird und auch nur der offiziell supported wird.
Aber wer die aktuelleste Beta haben will... Da sagen eben einige: Ok, auf eigenes Risiko halt.
Vielleicht könntet ihr euch das ja überlegen und eure Einschätzung dazu teilen.
Lg
MWSysTech
Ich habe auch zwei alte Nebelmaschinen aber ich glaube auch in "moderneren" Maschinen ist eigentlich genau das gleich drin, wie früher auch schon.
Und zwar: Ein Heizelement, ein Bimetallschalter, der auslöst sobald das Heizelement auf Betriebstemperatur ist und die Nebelfunktion (also die Fluidpumpe) freigibt. Manchmal wird das auch nicht direkt über Bimetallschalter geschalten, sondern es ist noch ein Relais dazwischen.
Das Klacken das du hörst dürfte jener Bimetallschalter sein. Dieser Temperaturfühler arbeitet natürlich nur dann richtig, wenn er auch an der Fühl-Seite guten Kontakt zum Heizelement hat. Wenn du schreibst du hast ihn jetzt neu reingedreht ist das auf alle Fälle schonmal.
Leider verstehe ich aber nicht ganz wie du das mit der Verkabelung meinst. Vielleicht hast du ein Foto um das besser einschätzen zu können.
Ich würde schätzen das der Bimetallschalter aus irgendeinem Grund nicht mehr zuverlässig. Z.B. auch Wasserschaden, falls irgendwann mal etwas nicht ganz so dicht war und irgendwo Fluid reinkam. Wer weis leckt die Maschine immer etwas. Das würde auch erklären warum es nach einer Zeit wieder geht. Das geleckte Fluid verdampft nach ein paar Sekunden/Minuten...
Bei mir muss immer alles beatgesteuert sein. Für DMXC2 hatte ich ein funktionierendes Setup. Nun steige auch ich endlich auf die 3er um und es stellte sich ein wenig problematisch dar den Beat aus Virtual DJ 8 (freie Version hier ausreichend) in DMXC3 zu bekommen.
Ich wurde im Forum nicht wirklich hilfreich fündig was dieses Thema angeht. Nach einigem Rumprobieren konnte ich das Problem aber lösen und möchte meine Lösung hier teilen. Ich freue mich auf bessere Lösungen
Vorbedingungen:
Teil 1: Beat aus Virtual DJ 8 raussenden
Teil 2: Beat in DMXC3 empfangen und verarbeiten
Das ist jetzt aus meiner Sicht eine eher weniger elegante Lösung aber sie funktioniert bei mir wenigstens zuverlässig.
Ich hoffe das kann auch anderen Leuten helfen, bzw. ich hoffe andere Leute können mir sagen wie man das "richtig" macht
Hallo an alle Entwickler und Plugin-Entwickler,
ich habe mal versucht mich über das Thema Plugins in DMXC3 zu informieren.
Leider musste ich feststellen, dass es wenig Infos oder gar ein kleines Tutorium gibt, wie man ein Plugin erstellt.
Alles was ich dazu im Forum gefunden habe, war immer stark auf einzelne Probleme fokussiert.
Ich würde gerne um eine Wiki-Eintrag bitten, in dem beschrieben wird, welche DLLs man braucht, wo die herkommen und einen exemplarischen Weg was man dann damit anfängt, bzw welche Möglichkeiten es gibt.
Ich weiß natürlich, dass das ein recht großer Wunsch ist. Dennoch habe ich die Hoffnung, dass dadurch die Einstiegshürde für Leute die eigentlich Programmieren können aber halt schlichtweg bei dem Thema nicht wissen wo vorne und hinten ist deutlich reduziert wird (z.B. ich :D). Vllt ein unkonventionelles Beispiel: Viele im Forum kennen bestimmt das Spiel Cities: Skylines. Das ist ja an sich von Hause aus schon ein gutes Spiel gewesen aber erst durch seine weitreichenden und gut dokumentierten Möglichkeit zum Modden wurde die Community in die Lage versetzt, das Spiel nach eigenen Vorstellungen (in gewissen Grenzen) und für alle zugänglich zu erweitern. Und jetzt nehmen wir einfach mal an, dass in diesem Fall die Kunden tatsächlich am besten wissen, was sie haben wollen.
Das heißt natürlich nicht, dass DMXC3 es in der selben Manier machen sollte, aber ich denke das Thema ist eine grundsätzlich dankbare Angelegenheit. Gut für die Software, für die Cummunity und evtl. sogar so gut, dass eine Plugins in den "offiziellen" Programmumfang übernommen werden können, die die "Hauptentwickler" entlasten.
Lg
MWSysTech
Hallo Theodor,
jaja diese Anwendungsfälle dachte ich mir schon. Klassisches Mischpult eben
PWM: Dein Gedanke war ja auch erstmal richtig. Im Grunde ist es ja möglich das mit Portbits so zu machen. Nur ist eben nicht so trivial... Was die PWM Frequenz angeht hätte ich bei der Größe des Motors auch so 8kHz geschätzt. Ist aber für die Regelung an sich eher nebensächlich. Auch mit Assembler hat deine Quelle natürlich was Wahres gesagt. Macht die ganze Sache nunmal nicht gerade einfacher
Also einen genauen Code kann ich dir leider nicht anbieten. Dazu müsste ich mich ja erstmal mit genau deinem Controller vertraut machen und ich habe im Moment ehrlich gesagt nicht die nerven Datenblätter mit Registern zu wälzen^^ Aber kann gerne das Prinzip zusammenfassen.
In der Regel haben µC ja sog. Timer, meistens auch mehrere davon. Ein Timer läuft mehr oder weniger unabhängig vom eigentlichen Programm im Hintergrund und zählt kontinuierlich mit einer gewissen Geschwindigkeit hoch. Wenn er beim Maximalwert angelangt ist, springt er zurück auf 0 fängt von vorne an. Also so eine Art Dreiecksfunktion. Einen Timer kann man entsprechende Register konfigurieren. Z.B. An- Ausschalten, Geschwindigkeit. Die Geschwindigkeit des Timers wird später die PWM Frequenz definieren. Über sog. Compare-Register kann man den Timer zu einer PWM Quelle machen. Angenommen der Timer zählt bis 255. Steht im Compare-Register nun 64 so läuft der PWM Ausgang auf 25%. Während der Timer von 0 bis 64 hochzählt ist der Ausgang HIGH, danach LOW. Du kannst also im Hintergrund auf diese Weise deine PWM-Erzeugung laufen lassen und im Programm nur ab und zu dieses Compare-Register beschreiben.
Welche Register du genau wie beschreiben musst, musst du aus dem Datenblatt des Prozessors raussuchen, das ist bei jedem etwas anders aufgeteilt und benannt.
Wie du links sehen kannst, studiere ich noch Mechatronik. Arbeite aber seit dem 1. Semester in einem Unternehmen der Antriebstechnik. Da geht es zwar eher um Motoren im kW Bereich und dementsprechende Frequenzumrichter aber das ist ja im Prinzip immer gleich, egal wie groß die Maschine. Beim Thema Lageregelung bin ich aber besonders hellhörig geworden, weil mir das aktuell im Studium schlaflose Nächte bereitet
Lg
Martin
Hallo Theodor,
ich habe noch ein wenig Hoffnung, dass mein realer Name durch dieses Pseudonym nicht zu ermitteln ist. Und da unsere Kommunikation öffentlich und nicht privat stattfindet, würde ich es gerne dabei belassen.
Aber ja, ich denke ich habe etwas besser begriffen worum es bei beider spezifischen Aufgabenstellung geht.
Das mit dem TLC... und dem und dem Motortreiber klingt soweit mal ganz solide. Ich denke was die Hardware angeht sind wir d'accord.
Der Tiny bekommt über PortB einen 8 Bit Wert vom übergeordnete Rechner, bei mir ist des der RASPI. Der wird verglichen mit dem 8 Bit Wert des Faders. Das ist der IST-Wert. Ist der etwa tiefer als der SOLL-Wert, bekommt der Motor einen Schups auf einem der beiden Portausgänge. Nach einer Zeit wird der Fader ausgelesen. Dazu halte ich den Motor ersteinmal an. Je nachdem, welcher Wert gelesen wird, wird durch Vergleich mit dem SOLL-Wert entweder derselbe Port wieder geschaltet oder der andere, der den Fader in die Gegenrichtung fährt.
Sollten beide Werte gleich groß sein, wäre die Regelung beendet und der Fader kann ganz normal von Hand bedient werden.
Klingt irgendwie sehr einfach, geht aber im Prinzip gar nicht. Ich bin zwar schon durch diverse Experimente auf eine recht gute Regelung gekommen, der Motor bleibt halt nicht stehen, wenn man ihn abschaltet, sondern läuft etwas weiter.
Ich habe daraufhin die Spannungspulse verkürzt, damit der Fader langsamer sein Ziel erreicht. Erhält er aber einen zu kurzen Spannungspuls, bewegt er sich halt nicht.
Eine Nebenbemerkung bevor ich zum Wesentlichen komme: Was die Problemmatik mit dem "Faderposition auf Wert von der Steuerung fahren und dann aber Manuell bedienbar" angeht, gibt es das Konzept der Reglerfreigabe. Das ist im einfachsten Fall ein bit, das eben gesetzt ist oder auch nicht. Immer wenn es gesetzt ist arbeitet der Regler, sonst nicht. Damit kann man recht leicht z.B. wenn die "Seite" auf dem Mischpult umgestellt wird kurz alle Fader auf einem Pin triggern, dass sie den Regler freigeben und wenn eine gewisse Abbruchbedingung, z.B. Differenz(Soll-Ist) < 5% erreicht ist wird die Reglerfreigabe gelöscht und der Fader kann von Hand bedient werden.
Soweit ich das verstanden habe, gibt es bei deinem Antrieb nur Stop, Vollgas-Vorwärts, Vollgas-Rückwärts. Sollte das der Fall sein, dann liegt hier die Quelle der unbefriedigenden Verhaltens. Das was du tust, nennt sich Vier-Quadranten-Betrieb und unterscheidet sich von einer PWM in einem Punkt: Man muss suuuuper genau timen, wenn man auch nur eine Chance haben will, dass das funktioniert. Deswegen macht, das keiner und die ganze Welt nutzt PWM.
Gedankenexperiment: Dein Fader ist nur ein ganz wenig vonn der Sollposition entfernt. Gerade so viel, dass die Regelung anspringt. Der kürzest mögliche Schaltimpuls von der Regelung also die Zeit vom Einschalten des Motors, bis zum Logikverarbeiten und wieder Ausschalten des Motors sei 10µs. in diesem 10µs halt sich Fader aber, weil er ja auf vollgas lief viel zu weit bewegt. Es hätte perfekt gepasst wenn er 10µs auf 20% gelaufen wäre. Das ist total blöd zu erklären. Also wenn du nur an/aus kannst, musst du brutal genau timen, i.d.R. genauer als technisch möglich. Durch PWM kanns du aber sozusagen genau so viel Gas geben wie eben gerade nötig. Und der Motor könnte mit einer PWM auch aktiv gebremst werden, dass man dieses Auslaufverhalten rausbekommt.
Ich würde also dringend empfehlen, das wenigstens testweise mal mit einer PWM-Ansteuerung des Motors zu versuchen.
Motor während der Messung abschalten wird dann auch nicht mehr nötig sein, im Gegenteil es muss beides laufen. Ist ja ein Regelkreis, wie du bereits richtig erwähntest.
Was den Reglercode angeht würde ich das noch erstmal zurückstellen, sonst machen wir hier 5 Themen auf einmal auf und keiner blickt mehr durch. Nur so viel. D wirst du nicht brauchen. Würde ich auch erstmal noch raus lassen. Es wird auch nur mit P-Regler funktionieren. Der I-Anteil holt am Ende nur die letzten 10% Präzision raus.
Ja, C-Control ist ein Krapf
Lg
MWSysTech
Hallo Theodor,
super! Genau mein Thema Ich mache Antriebstechnik Da kann ich ersma schööön den Fachidioten raushängen lassen:
Was du da vor hast ist eine sogenannte Lageregelung. Weil du willst ja das der Fader die Position (Lage) hält die dem anliegenden DMX-Wert entspricht.
Lageregelung ist dummerweise nicht so ganz ohne weiteres zu machen. Der Wikipedia-Artikel ganz unten ist schonmal hilfreich aber wirklich erklärt wird es eher im Buch (auch unten). Trotzdem will ich mal versuchen das wesentliche in meinen Worten wiederzugeben:
Hardware:
Hardwareseitig hast du sicherlich irgendetwas, um die abgegriffene Spannung zu messen nicht wahr? Und das geht dann an einen ADC aufm µC und irgendwie rechnest du das dann in einen Wert zwischen 0 und 255 um. Das ist ja dein Messsignal der Regelschleife
Und am Fader ist sicher ein kleiner DC-Motor der von einer H-Brücke angesteuert wird, damit man den Motor in beide Richtungen mit beliebiger Spannung speisen kann.
Lageregelkreis:
Man könnte jetzt versuchen mit diesem Spannungssignal direkt auf Lage zu regeln, indem man schlicht einen PID-Regler nimmt, die Differenz aus Soll- und Ist-Wert einfüttert und dann eben z.B. -12 bis +12V Spannung auf den Motor ausgibt. Kann funktionieren. Wird sehr leicht schwingen, wenig präzise und vor allem nicht so schnell ausregeln wie man das evtl. von professionellen Pulten kennt, wo man aufs Knöpfchen drückt und zack sind die Regler an Ort und Stelle, so schnell, dass man es fast net sieht. Das Problem bei dieser Art Regelung ist, dass man versucht mit Hilfe eines Lagesignals (Abgegriffene Spannung am Potis) den Strom am Motor zu Regeln (Spannung und Strom am Motor stehen ja logischerweise in Verbindung). Der Motorstrom bestimmt jedoch das Drehmoment des Motors also quasi die Beschleunigung. Die Beschleunigung ist die zweite Ableitung des Ortes (Lage) => spätestens hier sollten die Alarmglocken losgehen: Umgangssprachlich: "Stellgröße (Motorspannung) und Regelgröße (Potisspannung) sollten nicht durch eine oder gar mehrere Ableitungen/Integrale getrennt sein." Wie gesagt kann funktionieren, hat aber halt so seine Tücken, ist aber manchmal aufgrund begrenzter Ressourcen das einzig Mögliche. Man kann auch versuchen nicht einfach nur einen PID-Regler zu nehmen, sondern z.B. auch die Parameter adaptiv einstellen oder einen Fuzzy-Regler sind aber alles Tricks die zwar ihre Berechtigung haben aber naja... Einfacher wirds dadurch auch net.
Elektrische Maschinen sollten Momentengeregelt betrieben werden. Da man das Moment aber nur kostenintensiv messen kann, realisiert man eine Stromregelung. Strommessung ist ja recht einfach über einen Shunt-Widerstand möglich, der im einfachsten Fall unter die H-Brücke kommt, Messverstärker dran und Signal am ADC einlesen. Über die sog. Motorkonstante lässt sich aus dem Strom direkt das Drehmoment bestimmen. Misst man also den Strom hat man das Drehmoment -> Regelbar. PI-Regler reicht in der Regel, sonst schwingt es eh nur.
Der Momentenregler wird von einem Drehzahlregler überlagert, der wie der Name sagt, die Drehzahl des Motors regelt. Dazu ist natürlich wiederum eine Messung der Drehzahl nötig, die i.d.R. durch einen Drehgeber erfolgt in deinem Fall kann das aber auch die Ableitung der Potisspannung sein. Auch hier PI.
Und schließlich der überlagerte Lageregler, der die Lage oder Position des Motors regelt. Messsignal wäre hier deine Potisspannung. Auch hier reicht ein PI völlig aus.
Die Kunst an dieser Sache ist jetzt natürlich erstmal die drei Signale sauber zu messen und dann die drei Regler einzustellen.
Sinn des Ganzen ist erstens dieses Spiel mit "Ableitungen der Stellgröße" rauszukriegen und dein System aufzuteilen. Ab jetzt ist es nämlich "nur" noch eine Sache von Wie stelle ich meinen Regler ein. Wenn du das aber schaffst, ist das fast das schnellstmöglich was du machen kannst um auf Lage zu regeln.
Wenn nämlich der Lageregler eine Abweichung feststellt gibt er eine Solldrehzahl aus. Die natürlich nicht beliebig ist, sondern bei kleinen Abweichungen eben klein aber bei großen halt auch schon mal saftig sein kann. Der Momentenregler schaut, dass er das entsprechende Drehmoment erzeugt bekommt um auf diese Geschwindigkeit zu kommen. Also die Aufgaben sind verteilt und jeder macht das was er kann. Es wird dadurch z.B. auch möglich einen Fader festzuhalten. Weil egal wie stark du drückst. Der Drehzahlregler gibt Drehzahl 0 aus und der Momentenregler drückt halt entsprechend dagegen, um das zu halten. Natürlich alles im Rahmen seiner physikalischen Möglichkeiten.
Also zum Testen würde ich erstmal einen PI Regler bauen und direkt mit der Potisspannung die Motorspannung regeln. Vielleicht reicht es ja. Wenn es nicht reicht wirst du um die typische Lagereglerstruktur nicht drumrumkommen.
Software:
A und O jeder Regelung ist ja eine saubere, möglichst verzögerungsfreie Messung. Potis haben allerdings eine recht hohe Toleranz. Ich denke also, dass es nötig sein wird für jedes Potis den unteren und oberen Messwert einzulernen und irgendwo im µC abzulegen. Nur dann kannst du korrekt aus der Potisspannung auf ein DMX Signal zwischen 0 und 255 umrechnen. Verzögerungsfrei dürfte kein Problem sein allerdings würde ich in betracht ziehen das sogar absichtlich etwas mit einem Kondensator zu glätten, damit man weniger Rauschen reinkriegt und Regler nicht die ganze Zeit nervös zappelt.
Was jetzt konkret den Code angeht würde ich dazu raten einen möglichst einfachen PI Regler in C zu suchen und dann eben von Hand dein spezifischen ATtiny Assembler Code zu übersetzen.
Mein Rat:
Was ich in so einem Fall als Erstes tun würde wäre erstmal den guten alten Arduino rausholen, da alles anstöpseln, die bewährten Standardbibliotheken für z.B. PID Regler nehmen und einfach mal irgendwie zum laufen bringen. Und dann halt schrittweise zum Zielsystem vorarbeiten. Also z.B. wenn du merkst, dass dir ein einfacher Regler nicht gut genug regelt erstmal den Lageregelkreis aufm Arduino aufbauen, bevor man das im vergleichsweise komplizierten Assembler macht... Und dann mal den Regler selbst schreiben... usw.
Das war jetzt erstmal recht umfangreich und vielleicht noch zu wenig konkret... Aber frag ruhig nach
Lg
MWSysTech
https://de.wikipedia.org/wiki/Lageregelung
Elektrische Antriebe - Regelung von Antriebssystemen, Dierk Schröder, Springer Vieweg
Super Sache mit der neuen Bibliothek.
Ich wollte die Gelegenheit gleich nutzen ein paar DDFs von mir hochzuladen, die noch nicht da waren und dabei stellt sich mir folgende Frage:
Bei der Installation von DMXC werden ja eine ganze Reihe von DDFs installiert.
Sind das einfach alle die in der Bibliothek liegen?
Oder sucht da jemand aus welches standardmäßig installiert wird und welches nicht?
Lg
MWSysTech
Hallo Dominik2205,
Muss diese Fernbedienung wirklich mobil sein? Wie viele Stationen oder Szenen? Wie idiotensicher?
Gut das mit den Audioeinspielungen ist denke ich kein Problem. Zumindest DMXC2 kann das ja schon lange und wenn du Szenen triggern kannst ist das auch kein Thema mehr.
Aber das Triggern ist halt doof, weil du von mehreren Punkten zum PC musst...
Also wenn es ein bisschen technisch sein darf, würde ich sagen wäre das einfachste jeder installiert sich z.B. TeamViewer auf Handy, dort sieht man die Kommandobox oder Softdesk des steuernden PCs und kann dann halt wie am PC klicken.
Wenn es wirklich hart idiotensicher sein muss, würde ich von mobil eh abraten und so wie im ein oder anderen Museum einen Knopf oder Schalter (oder ganz edel mit RFID) irgendwo z.B. an der Wand verstecken, der eine bestimmte Szene triggert. Je nach Anzahl der Szenen wird das natürlich umfangreich. Bei wenigen könnte man über MIDI-Übertragung nachdenken, wenns es mehr wird vielleicht eher ArtNet.
Wenn es mobil und idiotensicher sein muss, könnte man vielleicht sogar einen dieser PowerPoint Presenter missbrauchen. Aber keine Ahnung wie da die Reichweiten sind und und dann muss man diesen Klick ja noch irgendwie zu einem Triggersignal für DMX Steuerung machen...
Je nachdem wären vllt auch Bastellösungen möglich mit Arduino oder eigener App auf dem Handy aber das ist halt aufwändig.
Guten Rutsch
MWSysTech
Hallo Kevin1435,
Ich kann ehrlich gesagt nicht genau Abschätzen woran das liegt. Ich vermute aber aufgrund der Beschreibung, dass du DMX Control 2 benutzt.
Ich habe dann eine Bewegungsszene erstellt. Eine einfache Kreisfahrt. Hat funktioniert. Dann wollte ich den Farbwechsel programmieren und habe dann versucht über die zugeordnete Szene (unten rechts) einen entsprechenden Befehl zu erstelle. Moving Head ausgewählt, Colour und einen neuen Wert eingegeben.
Ich möchte eine Möglichkeit beschreiben, wie das meiner Meinung nach sicherlich funktioniert:
Was ist jetz der Sinn der Sache: Du hast deine Problem, das aus zwei Komponenten besteht in eben diese zwei Teile zerlegt und kannst dich erstmal völlig getrennt voneinander um eines nach dem anderen kümmern und das dann zusammenfügen. Das sollte meiner Erfahrung nach auch alles in einer Bewegungsszenen geht aber auch wenn das hier vielleicht mehr Klicks bedeutet ist es wenigstens übersichtlicher.
Aber wie kommt nun Bewegung in die Geschichte. Also noch einen Schritt programmiert, aber das konnte natürlich nicht funzen. Nun dreht sich der MH im Kreis, bleibt stehen, Lampen an und aus und nächste Kreisfahrt. Logisch, da die Schritte ja nacheinander abgearbeitet werden.
Genau richtig erkannt. Auch hierfür ist meine Konzept eine Lösung, weil du durch die zwei Effekte die Möglichkeit hast diese beiden schon erwähnten Teilaufgaben quasi-parallel, also mehr oder weniger gleichzeitig auszuführen.
Nach meinem augenblicklichen Stand programmiere ich ne Kreisfahrt und die Lampen. Dann lege ich beides in die Kommandobox und muss 2 Schalter betätigen ??? Das glaube ich nicht.
Stimmt, deswegen ja der Starter-Effekt.
Guten Rutsch
MWSysTech
