Jinx! - LED Matrix Control ... und die nächste Matrix Software ...

    Als erstes die Matrixsize setzen , dann den Ausgang anlegen ( schau da, das die Kanalzahl stimmt), dann patchen. Wenn du den Ausgang anlegst bevor du die Matrixsize anpasst, dann hast du ( falls nicht manuell korrigiert) die alte Matrixsize als Kanalzahl. Wenn du zu viele Kanäle rausschickst hast du genau das beschriebene Problem. Bei 8x8 sind es 64 Pixel, bei 3 Farben dann 192 Kanäle. Das sollte auch beim Ausgang als Channel eingestellt sein.

    NoNameStriker schrieb:

    dort x=16 statt x=8 steht


    Ja gut das ja nur ist die Vorbelegung für den Fastpatch. Der Patch spielt hierbei auch erstmal keine Rolle, wenn der Patch falsch ist bleibt die Software nicht stehen. Was bedeutet schmiert ab, laufen die Effekte noch auf dem Bildschirm oder friert dort die Anwednung ein ?
    Wie gesagt einfrieren kann das eigentlich zu dem Zeitpunkt nur, wenn die Daten an der seriellen nicht abgenommen werden und ein Stau entsteht (da muss ich endlich mal eine Sicherheitssperre einbauen). Wenn also die Kanalzahl stimmt (du hast auch nur dieses einen Outputdevice angelegt ?) und die Baudrate dann darf da eigentlich nix schief gehen. Wenn du ein Bild bekommst auf der Matrix müsste ja auch die Schnittstelle mal grundsätzlich stimmen, oder kommt überhaupt was auf der Matrix an ?
    Hattest du mal mit Glediator getestet ? Hat es da ohne Probleme funktioniert ?

    NoNameStriker schrieb:

    Mit Glediator kann ich gar nicht erst den COM-Port anwählen, da keiner zum Auswählen erscheint.


    rx/tx lib ? Die bekommst du z.B. hier: mfizz.com/oss/rxtx-for-java Musst halt die richtige auswählen 32 oder 64 Bit, wobei das nichts mit deinem Betriebssystem zu tun hat sondern mit deiner Java Runtime. Auch wenn du ein 64 Bit Windows hast, hast du im Regelfall ein 32Bit Java, somit brauchst du auch die 32Bit lib, diese einfach in das Glediator Verzeichnis werfen. Hatte ich schon mal verlinkt: Glediator - Freeware LED Matrix Steuerung - Software

    Hmm irgendwas läuft da mit der seriellen noch schief, im Gerätemanager ist sie sauber drin ? Der Arduino Uno läuft ja auf gleiche weise wie der USb2serial Light mit nem Atmega. Den nutze ich um meine Solderlab Boards anzusteuern, insofern seh ich hier nichts ungewöhnliches. Evtl. läuft auch die Firmware auf dem Arduino nicht rund, vielleicht hab ich auch noch einen Bug. Insofern wäre es interessant das du noch mal versuchst Glediator ans laufen zu bekommen, wenn es da geht muss es auch mit Jinx gehen (oder ich hab nen Bug :D ). Ich hab keinen Arduino zum testen hier und hab mir auch die Firmware noch nie angeschaut, daher tue ich mich gerade ein bisschen schwer mit Fehler suchen, aber wie schon erwähnt wenn Jinx einfriert kann es nur an der seriellen Kommunikation liegen und das hier die Daten sich stauen (warum auch immer).
    Das war noch gerade, nachdem ich Java und rxtx (auch in den Java ordner!) neu installiert habe:
    Also jetzt wo ich den COM-Port wählen kann, "funktioniert JAVA Platform SE binary nicht mehr". Wie bei Jinx! wird das nur erste Bild aber auf der Matrix angezeigt.
    Das Problem bei Jinx! hat sich jetzt etwas gewandelt. Wenn ich jetzt mit Falling Rain anfange, läuft es einwandfrei. Stelle ich was aufwändigeres ein, schmiert es anders ab.
    Die Software läuft, jedoch schmiert das USB-Gerät ab.
    Dann kamm ich auf die Idee, mal GND nicht an das Arduino anzuschließen, sondern an das Netzteil. (Überall steht man solle es ans Arduino anschließen X().
    Und siehe das: es läuft perfekt. Sowohl in Jinx! als auch in Glediator. :D

    Danke für die Hilfe
    Matthias

    PS: Jinx! ist super und total übersichtlich!

    Seddi schrieb:

    Die 160 ms beim ruckeln, kann ich nachvollziehen. In der Software bekomm ich da beim abfragen 3 mal hintereinander keine Daten von der Schnittstelle ( meldet einfach 0 Bytes in der Queue) , bei der 4. abfrage bekomm ich dann die ganzen Frames auf einen Schlag.
    Ja, das klingt logisch - also wohl ein seltsames Treiber/Windows-Problem...

    ich lass' ds wohl erst mal so mit den 3 übetragenen Bytes bei mir, obwohl's generell natürlich schon cooler ist, wenn man alle 512 hat, und dann direkt in Jinx die Adresse einstellen kann - wo stellst Du denn die Latency auf 1 ms runter, mit diesem FTDI-Config-Tool...?

    Seddi schrieb:

    Da hast du dir die Antwort doch schonmal selbst gegeben im SEDU Board Software Thread ;) ... "2. der Treiber wurde so modifizeirt, dass der FT232 mit 250 kBaud sendet/empfängt, wenn man am PC 115,2 k einstellt" ... Die Gui des Bootloaders öffnet die Schnittstelle mit 115,2k und somit mit 250k, deshalb funktioniert das mit dem String bei 250k Baud. Ist das SEDU Board auf 500k kann es mit den 250k nix anfangen, da müsste dann das Baud-Aliasing im Treiber so eingestellt sein, das beim öffnen der Schnittstelle 500k gefahren wird.
    Hm, ich dachte, das könnte man einstellen, oben rechts ist doch so ein Auswahlfeld mit Baudraten...? - ich bin schon davon ausgegangen, dass die dann so bleibt, also wenn ich jetzt den Bootstring mit 500 k schicke und er dann in den Bootloader springt, dass dieser dann bei den 500 k bleibt...?

    aber natürlich schon logisch, der Bootloader muss ja (kann ja auch direkt nach dem Reset aufgerufen werden) den USART konfigurieren, und das wird er dann stur auf 115,2 k machen, da kann er ja schlecht Rücksicht drauf nehmen, wie der vorher eingestellt war - *könnte* er natürlich schon, also z.B. gucken, ist schon irgendne Baudrate eingestellt, dann lass' ich die... aber k.A., ob die das so gecodet haben.

    da frage ich mich dann schon, wozu man da die Baudrate überhaupt einstellen kann...? ?( :D - OK, man könnte die natürlich im Bootloader selbst auch ändern, ich muss mal den Nino fragen, der hat den Source gekauft...

    Seddi schrieb:

    2mm Loch an der richtigen Stelle im Gehäuse und du hast nen klassischen Reset Knopf den man mit der Büroklammer drücken kann, hat heutzutage jeder Router :P
    Ja, das stimmt - ich hab' halt generell gerne so wenig Löcher wie möglich in Gehäusen, insb. wenn die irgendwo auf Partys etc. rumliegen, aber OK, das macht das Kraut auch nicht fett...

    Counterfeiter schrieb:

    Wenn du nicht gerade Software UART machst, dann hast du 1 Byte "transmit buffer" und 1 Byte "shift buffer" und das meine ich ;)
    Achso - ja, klar, da ist en Buffer - aber der kann auc hnicht überlaufen, ich frage ja wie gesagt das Flag ab, ob das Byte schon raus, also der Buffer wieder leer ist...

    Seddi schrieb:

    Ich denke mit einem Terminalprogramm kann man das nicht wirklich verfolgen, da allein die Textausgabe auf dem Schirm schon der Datengeschwindigkeit hinterher hinkt. Da ja alle Werte kommen und nichts verschluckt wird sieht das auf dem Bildschirm dann schon sauber aus, lässt sich aber zeitlich m.E. nicht wirklich bewerten.
    Da hast Du natürlich recht! - da müsste ich dann in den empfangenen Daten gucken, da sind dann die Stufen bestimmt auch drin.
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!
    @NoNameStriker
    Hauptsache es funktioniert, hab mir schon den ganzen Tag den Kopf zerbrochen wo das am Ausgang noch stocken könnte. Ich bau die Tage erstmal ne Sicherheitsroutine ein, dass das Programm nicht hängen bleibt wenn der Abfluss verstopft ist oder jemand die serielle Verbindung trennt während die Ausgabe läuft.

    Und Danke für die Blumen, wobei ich das Lob ja weitergeben muss. Was die übersichtliche Oberfläche angeht hab ich mir ja auch einige Ideen bei Glediator ausgeborgt ;)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Seddi“ ()

    Pesi schrieb:

    wo stellst Du denn die Latency auf 1 ms runter, mit diesem FTDI-Config-Tool...?

    Ganz einfach Gerätemanager, Doppelklick auf den Com-Port und dann unter Port Settings -> Erweitert. Insofern halte ich es für praktikabel das einfach runterzustellen und die 512er Version läuft ohne Probs.

    Pesi schrieb:

    oben rechts ist doch so ein Auswahlfeld mit Baudraten...?

    Ooops .. hab gar nicht gesehen das ich hier die anderen Baudraten (250k und 500k) einblenden kann, hab nur immer die 115200 gesehen und kleiner.

    Pesi schrieb:

    Da hast Du natürlich recht! - da müsste ich dann in den empfangenen Daten gucken, da sind dann die Stufen bestimmt auch drin.

    Die Stufen sind ja nur zeitlich, alle Werte kommen ja an, nur blockweise, also müsste man trotzdem ne schöne Reihe 1-> 255 sehen im Terminal, die Daten gehen ja nicht verloren.
    Also beim Glediator hatte bei nativen USB am uC festgestellt. Wenn ich mit der Infrarotfernbedienung on drücke und dann quasi die Ausgabe mit den Funktionen der Fernbedienung überlagere, bleibt die Animation stehen aber das Programm lässt sich noch bedienen. Anschließen drück ich auf der IR wieder off und der Controller nimmt wieder Daten entgegen -> Animation läuft an der selben Stelle weiter... fand ich total geil :) (auch wenns total egal is) ;)

    Getestet hab ich das mit dem neuen SEDU V3

    Grüße Basti
    Glediator hat hier den Vorteil das es nur mit einem Timer arbeitet, wenn dieser ausgebremst wird (weil keine Daten ander seriellen abgenommen werden), dann wird einfach die Framerate langsamer aber das Programm bleibt bedienbar. Bei Jinx arbeite ich mit mehreren Timern, das hat viele Vorteile aber auch den Nachteil das bei einem blockierenden Ausgang die Timer sich überlagern und somit Gegenseitig ins Nirvana schiessen, sprich die einzelnen Generatoren wollen weiterarbeiten aber der Ausgang blockt, somit gibts dann nen ganz bösen Stau im Programm. Wenn du den Ausgang in so einem Fall wieder anklemmst und ein weilchen wartest bist der Stau aufgelöst ist, lässt sich Jinx auch wieder bedienen. Es stürzt also nicht wirklich ab, ist aber so etwas unpraktisch geb ich zu :D
    Deshalb muss ich diesen "Fehlerfall" noch abfangen, steht auch schon seit Ewigkeiten auf meiner ToDo Liste, mach ich die Tage versprochen. Ging mir diese Woche schon selbst auf die Nerven als ich beim testen öfters umgesteckt habe. Wenn man im laufenden Betrieb die Matrix absteckt (bei serieller Übertragung), hat man ja den gleichen Fall.
    So, nochmal eine neue Version (0.92a), ich häng sie (vorerst) ausnahmsweise mal hier mitten im Thread an, da ich sehr viel an der seriellen Ausgabe gearbeitet habe und hier nicht alles selber testen kann. In der Simulation über eine virtuelle Com-loop funktioniet es zwar sauber, aber trotzdem hätte ich da gerne eine Bestätigung mit echter Hardware ;)

    Wenn also jemand Zeit, Lust und die Möglichkeiten dazu hat wäre es super wenn ihr die seriellen Ausgaben (Glediator, tpm2 und MiniDMX) testen könntet. Glediator Protokoll kann ich morgen auch selbst kurz testen, hab nur die Matrix im Büro und nicht hier zu Hause.

    Folgendes hat sich geändert:
    -kleiner Bugfix beim Screencapturing, hier gab es einen Stride-Fehler, sprich verzerrte Bilder bei Matrixauflösungen die nicht ein vielfaches von 4 waren
    -kleiner Fix beim tpm2 Eingang (Remote), hier konnten (wenn auch sehr selten) Frames verschluckt werden
    -Fix für generelle Ausgabe/Patch, wurden gleichzeitig verschiedene Interface-Arten angelegt (kommt in der Praxis wohl selten bis gar nicht vor, daher ist das auch noch nie aufgefallen), wurden ab dem zweiten Interface die gepatchten Pixel verschoben
    -Umbau der seriellen Ausgabe (tpm2, Glediator, MiniDMX) auf OVERLAPPED mode, dadurch kann ich die Out-Queue von Windows abfragen und kontrollieren
    -Automatischer Frameskip bei der seriellen Ausgabe wenn nötig

    Dies bedeutet nun im Klartext: Wenn man ausversehen zu viel Kanäle auf eine zu kleine Baudrate einstellt (also mehr senden will als die Baudrate bei 25fps hergibt), friert das Programm nun nicht mehr aufgrund des Staus an der seriellen Schnittstelle ein sondern lässt solange Frames bei der Ausgabe aus bis die serielle wieder frei ist und die alten Daten vom Empfänger abgearbeitet wurden (die Software selbst läuft mit vollen 25fps weiter). Sollte aus irgendeinem Grund der Empfänger gar keine Daten mehr annehmen (z.B. Kabel ausgesteckt), werden auch keine Daten mehr gesendet, so dass auch hier die Software nicht mehr einfrieren kann.

    Ach ja, und damit ein Update auch Spass macht:
    -Neuer Effekt für "Simple Lines": Dancing Snakes (siehe angehängte Szenen im Demofile)

    anderes Thema ... @Pesi und @Turi
    Fast ein bisschen Offtopic, aber ich wollte keinen neuen Thread aufmachen. Mir ging gerade so der SEDU durch den Kopf, es wird ja immer wieder danach gefragt wie es mit der Ausgabe von DMX aussieht, da wohl viele ihre RGB Tubes als Matrix steuern möchten (auch bei Glediator wird da immer mal wieder rumgebohrt). Bevor ich jetzt anfange die ganzen unzähligen USB2DMX Dinger zu programmieren, die z.T. wirklich fürchterliche Treiber und APIs haben (vor allem die günstigen ebay Dinger die meist auf dem Elektor Bausatz basieren und man Windows in den Testmodus schalten muss das man den Treiber ans laufen bekommt), hab ich gedacht können wir da nicht ein tpm2->DMX mit einem SEDU machen ?
    Die ersten brauchbaren USB2DMX (Enttec Open, Digital Enlightment) fangen so bei 100,- EUR an, da wär ein SEDU deutlich günstiger und tpm2 kann schon jede hier vertretene Matrix-Soft (Pixelcontroller, Glediator, Jinx), das Teil ist also somit sofort einsetzbar. Wenn dann wieder die Frage kommt kann man den User sagen, OK, kauf dir für knapp 200,- EUR das billigste Artnet/DMX Node von Botex, bastel was selber oder nimmer hier den SEDU mit tpm2->DMX z.B. fertig bei Turi für 39,- EUR (oder was auch immer die SEDUs gerade kosten, ich hab nicht nachgeschaut). Da hat dann vielleicht auch Turi was davon ;) Ich könnte dann noch eine kleine handliche Artnet->tpm2 Node Software (als Open Source) mit in die Runde schmeissen und somit wäre das Ding als richtiges DMX Interface für DMXControl, Freestyler und Konsorten auch noch nutzbar. Und dazu noch deutlich günstiger und stabiler/zuverlässiger als die billigsten USB2DMX Interfaces die man einmal in der Stunde vom USB abziehen und neu anstecken muss damit sie weiterlaufen. Was meinst ihr dazu ?
    Dateien
    • jinx-0.92a.zip

      (85,92 kB, 151 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „Seddi“ ()

    Bitte nach so langer Zeit keinen Edit machen, sondern nen neuen Post - ich hatte Deinen Beitrag gestern abend gelesen, ohne die PN hätte ich gar nicht mitbekommen, dass Du in der Nacht noch was dazu editiert hast...

    ja, gute Idee, das kann ich mal schnell machen, ist ja mehr oder weniger nur C&P.... ;)

    das geht aber eigentlich jetzt auch schon, mit dieser SW kann man "Mini-DMX" in DMX konvertieren, das können die meisten dieser SWs ja auch ausgeben - also neben Jinx, Glediator und Pixelcontroller auch DMXcontrol und Freestyler etc.

    trotzdem schadet ne zusätzliche SW tpm2->DMX gar nicht, idealer Weise soll sich dieses Protokoll ja auch ein bisschen verbreiten... ;)
    It's only light - but we like it!

    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    turi schrieb:

    Da steht zumindest im Titel, dass zusätzlich DMX ausgegeben wird. Pesi wird das schon wissen...

    Ah jetzt blick ichs. Ich hab immer den Post darüber angesehen und die Soft war für WS2801, die Dimmersoft hatte gar nicht gesehen. Wer lesen kann ist klar im Vorteil :D

    @All
    Die serielle Ausgabe ist inzwischen erfolgreich getestet bei der 0.92a (siehe 4 Posts drüber), ich häng sie also mal zusätzlich im ersten Post mit an.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Seddi“ ()