Posts by Rajiva

    Hallo zusammen,

    nachdem die erste Version doch noch sehr Fehlerbehaftet war, hat aber keiner gemerkt :D, will ich euch die vorerst letzte Version nicht vorenthalten. Der Downloadlink im 2. Beitrag ist noch korrekt und die Anleitung habe ich im Softwarepaket aktualisiert.

    Meinem RasPi Zero habe ich inzwischen eine IR Diode spendiert und so lässt sich das ganze jetzt auch mit jeder IR Fernbedienung steuern. Die LIRC Geschichte ist natürlich optional. Wie das ganze konfiguriert wird ist wieder in der Beispiel XML Datei beschrieben.

    Das schöne an einer Fernbedienung ist dass man die DMX Sequenzen über diese Fernbedienung starten oder wechseln kann. Das macht schon richtig Spaß!

    Wie man auf dem Raspberry PI die Hardware und das benötigte LIRC Paket installiert ist hier ganz schön beschrieben.

    VG

    Rajiva

    Würde mich trotzdem interessieren in wieweit der TPM2 Player eine Lösung wäre. Damit ließen sich die letzten beiden Wegoptimieren

    Als eigenständiges Gerät vielleicht schon, aber schon der fehlende "DMX In -> Out Mode" wäre für mich ein NoGo. Ich hab auch noch ein IMG DMX-1440 Lichtsteuerpult und will nicht immer einen PC anwerfen wenn ich mal schnell was ausprobieren möchte. Erst die Nodle Firmware V1.04 hat mich überhaupt dazu bewogen mich auf das Nodle einzulassen. ;)

    Man hätte den Sternenhimmel auch autark bauen können, aber wenn man mal angefangen hat mit DMX zu spielen muss halt alles DMX sprechen. :whistling:

    Mal ne andere Frage. Der TPM2 Player von Ulrich geht nicht? Hat der nicht so was wie ne Endlosschleife?

    Wie geschrieben, alles gut, ich habe eine Lösung gefunden. Sie heißt Nodle U1 + Raspberry Pi Zero + AutoControlDMX Service. ;)

    Dass man letztere beiden nicht wegoptimieren kann ist schade aber nicht weiter schlimm! Der Sternenhimmel ist nur eine Spezialsache für die Familie, ich hab auch noch anderes DMX Spielzeug für das der RasPI nicht gebraucht wird und hier wird das Nodle Interface sicher gute Dienste leisten. Wenn mir mal ein anderes DMX Interface mit "pass through" und Änderungsmöglichkeit über den Weg läuft kann ich ja nochmal über einen Umstieg nachdenken, so teuer war das Nodle ja nicht. Jetzt sind aber erst mal alle Requirements erfüllt und die Familie freut sich schon auf das neue Lichtermeer an der Decke. ;)

    Viele Grüße

    Rajiva

    "letzten Bit optimiert." Kann ich sagen weil es so ist und nicht weil ich ein Programierer bin!

    Dirk, ich schreibe seit über 30 Jahren beruflich Software und habe über 10 Jahre Erfahrung mit den AVR Controllern, sorry aber solche Aussagen habe ich schon viel zu oft gehört. ;)

    - 513 Byte empfangen


    - USB 16* In & Out von den Daten.

    - einige Timer und der ganze Kopier und vergleich Kram

    Ist bei einem Automode doch gar nicht notwendig!

    Im Automatikmodus müssen Daten auf den DMX Bus gelegt werden, mehr nicht. Es ist genug Flash Speicher frei und RAM ist offensichtlich auch noch üppig vorhanden.

    Aber lass gut sein, mein Problem ist gelöst und ich bin zufrieden mit der kleinen Box. ;)

    Viele Grüße

    Rajiva

    Du musst zwischen Modi und Config unterscheiden

    ja, hab ich beim schreiben vielleicht durcheinander gebracht. Verstanden habe ich es aber schon richtig, die API ist da ja auch klar. ;)

    Config: Timings wie Breaktime, etc (die AdvConfig), permanent im EEPROM und wird beim start daraus gelesen

    Sehr schön, lässt sich aber nicht auslesen, richtig?


    Modus: 0 bis 7 - DMXin->DMXOut, standby, etc... -> nur im Ram, weil durch Host gesetzt

    Ok, lässt sich aber auch nicht auslesen, richtig?

    EDIT: Bestückungsplan muss ich mal schauen... sollte machbar sein, wenn der im Projektarchiv fehlt...

    Das wäre wirklich hilfreich!:thumbup:

    Gerade wenn es um die Messungen oder die Fehlersuche geht sind die Bauteilbezeichnung wichtig.


    Also wie schon gesagt das Ding ist Voll und da ist alles schon bis zum letzten Bit optimiert.

    Sagen das nicht alle Programmierer? :D


    Der Prozessor ist schon recht am Würgen wenn der unter Volllast läuft.

    Moment mal, der Atmel ist kein PC sondern ein 8-bit RISC Microcontroller. Der läuft immer unter Volllast, oder habt ihr dem Mutithreading beigebracht? 8o

    Also 44Hz DMX In und Out und am Besten .dann noch IN + PC ==> OUT

    Ich kenne euren super optimierten Code zwar nicht, aber der AVR braucht bei den meisten Operationen nicht mehr wie einen Taktzyklus. Bei 16MHz Taktfrequenz kann der rund 16 Millionen Operationen pro Sekunde abarbeiten, da sind 44 Hz ja jetzt keine Hochfrequenz. ;)


    Ein Editor / Ablauf-Generator wird es nicht geben, außer DU schreibst den.

    Was kein Problem gewesen wäre und was ich wahrscheinlich sowieso tun muss. Frauchen hat schon kund getan dass Sie die Farben auch gerne selbst ändern möchte und mit XML hat sie es leider auch nicht so. ^^

    Diese Funktion übernimmt DMXControl normalerweise

    Ist mir klar dass DMXControl das sicher auch alles kann, aber ganz ehrlich, selbst ich war beim ersten Start von DMXControl völlig überfordert und hab das erst mal auf die lange Bank geschoben. Für jemanden der einfach nur einen Schalter umlegen möchte, oder wie im Fall von AutoControlDMX eine USB Verbindung herstellen, für den ist DMXControl einfach Overkill. Frauchen will was in die Steckdose stecken und dann muss alles leuchten. Der Spieltrieb, wie bei uns, ist da schlicht nicht implementiert. ;)

    ich mache das bestimmt nicht!

    Hat ja keiner verlangt. Wie oben schon geschrieben, wenn man niemanden mitmachen lässt ...

    ..., gleichzeitig verwehrt man sich aber auch den Ideen und Lösungen anderer. Ist halt immer auch aufwendig alles selbst zu programmieren und gute Ideen bleiben oft wegen Zeitmangel auf der Strecke liegen

    Einen Statischen Speicher von 1-X Universe könnte man nachdenken, aber wie schon gesagt da gibt es andere Projekte

    Alles kein Problem Dirk! Ich will hier niemanden angreifen oder gar etwas fordern! Ich hab meine Idee vorgestellt und es letztendlich über den Umweg des Raspberry PIs auch anders lösen können. Das ganze funktioniert sehr gut und ich kann damit leben dass der RPI die Arbeit macht. Wenn ich es gleich im Nodle hätte implementieren können wäre es noch schöner gewesen, denn dann hätte man den PC noch nicht mal abstöpseln müssen und das ganze über einen Mode 8 gelöst. ;)
    Sicher gibt es unendlich viele Projekte aber ich hab mich nun mal für das Nodle Interface entschieden. Nicht zuletzt wegen der aktuellen V1.04 Firmware und der Möglichkeit eines Stand alone Modes. Wenn es beim Nodle einen einfachen Automodus gäbe wäre das nur das Sahnehäubchen, das ist sicher kein "Must have" bei einem USB to DMX Interface.

    Alles wird gut! Liebe Grüße

    Rajiva

    Mit Firmware 1.04 ist, was den Mode angeht, nur eine Neuerung hinzugekommen, und zwar, wenn das Nodle KEINEN USB-Host erkennt,

    sondern nur mit Spannung versorgt wird (z.B. USB-Netzteil), schaltet das Interface automatisch in Mode 1 (repeater, DMX-In => DMX-Out), sofern der Jumper gesteckt ist

    Genau dieses Setup habe ich am laufen. PC aus = Mode 1, PC an = Mode wie gesetzt, RasPi gesteckt = wie PC an. Wenn nichts im EEPROM des Nodle gespeichert wird braucht es auch keinen Reset, aber dann haltet ihr die Daten ja unnötigerweise im RAM und dann wünscht man sich die permanente Speicherung der Einstellungen ja um so mehr! Ich hab noch nicht viel mit DMXControl gemacht, aber werden da bei jedem Start erst mal alle Einstellungen im Nodle neu gesetzt?

    Der RAM des Nodle ist mit 2560 byte sehr knapp. Selbst mit schon gut optimierter Software brauchen wir aktuell 2209 byte RAM

    Na, da sind ja ohne Optimierung noch über 300 Byte RAM frei! Über 10% freier RAM, was für ein Traum. ;)

    sind diese Daten statisch (dein Sternenhimmel macht die Farbwechsel selber, weil Funktion eingebaut) oder ändern sich die DMX-Daten stetig ?

    Der DMX LED Treiber macht von selbst nichts. Die Daten werden anhand der XML Konfigurationsdatei vom RasPi über den Nodle an den LED Treiber gesendet. Je nach Konfiguration, also z.B. beim Farbwechsel, ändern sich die Daten stetig. Das ändern der Daten könnte das Nodle auch selber machen, es bräuchte nur einen Editor um die Daten ins EEPROM zu packen. Den Automode könnte man ebenfalls über einen Jumper oder Microschalter auswählen. Da wär noch nicht mal eine Hardwareänderung nötig.;)

    BTW, Hardware, gibt es inzwischen einen Bestückungsplan mit den Bauteilbezeichnungen? Layer 25 im Eagle Editor.

    Hallo zusammen,

    Was wäre denn der Anwendungsfall für "Modus zurücklesen"?

    Der Sinn besteht darin die veränderten Werte wieder zurücksetzen zu können. Vielleicht hätte ich noch weiter ausholen müssen. :/

    Also das Projekt ist für folgendes DMX fähige LWL Gerät gedacht. An den beiden Öffnungen hängen später ca. 500 LWL Leitungen die einen Sternenhimmel an der Decke simulieren. Neben diesem Gerät haben wir auch noch ein paar Lichter von Eurolite und ein IMG DMX-1440 Lichtsteuerpult im DMX Strang hängen. An der USB Buchse des Nodle soll wahlweise ein kleiner RasPI oder ein PC mit DMXControl angeschlossen sein. Durch die neue Nodle Firmware 1.04 wäre sogar ein Solobetrieb denkbar.

    Da die Familie sich nicht in Lichtsteuertechnik einarbeiten möchte, der PC und das Lichtsteuerpult also ausfällt ;), und selbstständig nur an dem Sternenhimmel Interesse hat suchte ich eine Lösung um dieses DMX fähige Gerät völlig automatisch in Betrieb zu nehmen. Als die Idee das kleine Programm im Flash des AT-Mega zu speichern aufgrund fehlender Sourcen verworfen werden musste habe ich mich für einen kleinen Raspberry PI Zero entschieden. Dieser lässt sich einfach an den USB Anschluss des Nodle anschließen und steuert dann völlig automatisch den Sternenhimmel DMX LED Controller.

    Jetzt ist es natürlich so, dass der Sternenhimmel völlig andere Betriebseigenschaften hat wie der Rest vom Lichtequipment und so wäre es doch schön wenn in diesem speziellen Fall alle geänderten Einstellungen, z.B. kein benötigtes DMX-In vom Lichtsteuerpult, wieder zurück gesetzt werden könnten. Andernfalls müsste das immer wieder über Software geschehen, auch wenn nur das Lichtsteuerpult zum Einsatz kommt. Ich bin da aber Lichtsteuertechnisch noch ein Anfänger und denke vielleicht an Dinge die es in der Praxis gar nicht braucht. :/

    Den Mode zurueck setzen geht aber. Einfach den neuen Mode setzen. Standby ist mode 0.

    Diese Lösung ist leider unpraktikabel da so immer ein PC zum einstellen eines anderen Modus benötigt wird. Wenn man sich nur mit dem Lichtsteuerpult spielt (Mode 1) will man das ja gerade nicht.

    Außerdem ohne diese Daten war das ändern der Werte auch immer so eine Sache.

    Das sehe ich genauso, immer alle Werte einstellen zu müssen, weil der Ist stand unbekannt ist, ist suboptimal.

    Da ist der zulangsam BZW: RAM ist Voll, EEProm und Flash genug frei aber das bringt nicht wirklich was

    Was den RAM angeht weiß ich natürlich nicht Bescheid, lässt sich aber sicher optimieren;), aber dem Rest müsste ich widersprechen. Ein 16 MHz getakteter AT-Mega ist zu einigem fähig. Da habe ich schon ganz andere Sachen entwickelt.

    Klar kann man so etwas wie "aktuelles Universe speichern" einbauen und das irgendwann abrufen.

    Würden dann aber auch nur 1-X Universe werden, kenne jetzt nicht die genaue Eeprom größe.


    Ich glaube da denkst Du zu kompliziert! Mein kleines RasPI Programm sendet einfach nur DMX Werte und die Farben im LED Controller ändern sich wunschgemäß. Alles was es braucht sind also Kanal und Werte Informationen die in einem Loop auf dem DMX Bus landen. Das ist auch für einen kleinen AT-Mega quasi Null Problem.

    So wie man ein Nodle-Firmware Update machen kann, kann man genau so gut eine eigene

    Na ja, wieso sollte man das Rad immer und immer wieder erfinden? Der DMX Teil scheint gut zu funktionieren, bedarf also keine Re-Erfindung. Die fehlende Funktionalität, also ein Standalone Mode, steht in keinem Verhältnis zu einer komplett neuen Firmware. Da tut es auch ein kleiner RasPI den man an den USB Anschluss hängt. ;)

    und wird auch nicht OpenSource werden.

    Ich kann die vorgebrachten Gründe warum ihr das nicht wollt verstehen, gleichzeitig verwehrt man sich aber auch den Ideen und Lösungen anderer. Ist halt immer auch aufwendig alles selbst zu programmieren und gute Ideen bleiben oft wegen Zeitmangel auf der Strecke liegen. Ich habe selbst schon sehr sehr große Communityprojekte gestemmt, weiß also euer Dilemma gut einzuschätzen. ;)

    Edit: Vielleicht noch eine kleine Anmerkung zum AutoControlDMX Service und der Konfigurationsdatei. In einer XML Datei können beliebig viele <Device></Device> Tags vorkommen, es sind als beliebig viele Geräte gleichzeitig steuerbar. Natürlich beschränkt durch die verfügbaren DMX Kanäle. ^^

    Liebe Grüße und danke für die vielen erhellenden Antworten!


    Rajiva

    Ich hab mir mal erlaubt deinen Code hier direkt mit dem Tool vom Forum zu formatieren. Sieht besser aus und ist dann auch am Handy besser lesbar :)

    (Zu deiner Frage kann ich leider nichts sagen, da kenne ich mich nicht so gut aus)

    Danke! Schade dass es an technischer Unterstützung fehlt, hab mir das Nodle U1 in der Hoffnung gebaut dass ein gemeinnütziges Projekt zumindest Protokolltechnisch supported wird. Viel lieber hätte ich das ganze natürlich in den AT-Mega gepackt, aber closed source ... ;)

    Hallo zusammen,

    ich hab zwar noch keine Antwort bekommen ?(, aber ich möchte euch dennoch schon mal meine erste Version des AutoControlDMX Service vorstellen.

    Das kleine Programm kann auf der Kommandozeile und als Systemd Service verwendet werden. Auf der Kommandozeile wird das Programm mit "Ctrl+C" beendet.

    Sinn und Zweck des Tools ist wie oben beschrieben ein Automatismus der das Nodle U1 per Konfiguration steuert. Als Service sogar automatisch beim anschalten.

    Hier noch eine kurze Beschreibung der benötigten Konfigurationsdatei anhand der vorhandenen Beispiel XML Datei.

    Geplant ist eigentlich noch das zurücksetzen auf den letzten Interface Mode und eventuell einstellen anderer Parameter, dazu braucht es aber etwas mehr Protokollinfo, siehe meine Frage oben.

    Grüße

    Rajiva

    Hallo zusammen,

    ich möchte das Nodle Interface benutzen um u.a. einen Sternenhimmel, angesteuert über eine DMX LED Light Engine aus China und ca. 3500m LWL Leitung, zu steuern. Da der Sternenhimmel keine manuellen Trigger braucht und einfach nur feste Farbwechsel vornehmen soll möchte ich eine Art Automatik Verhalten programmieren. Da die Firmware des Nodle leider nicht verfügbar ist, Platz wäre in dem Atmel Mega ja noch genug, möchte ich das jetzt über einen kleinen RaspberryPI Zero lösen.

    Ich habe mir dazu das USBDMX Projekt für den RasPI gebaut und habe nun ein paar Fragen zur API. ;)

    1. Wie bekomme ich den aktuellen InterfaceMode heraus? Also das Gegenstück zu SetInterfaceMode?

    2. Wie kann ich die InterfaceAdvTxConfig auslesen, also das Gegenstüch zu SetInterfaceAdvTxConfig?

    Vielleicht kann da einer der Entwickler helfen.

    Grüße

    Rajiva