MatrixMover - Noch eine LED Matrix Steuerung

hey McGyver

ich denke das sollte gehen, ist ja zu 95% mein code

noch eine kleine Anmerkung zum deinem Code, Klassen die du von dem PixelController Projekt übernommen hast, sollten das Copyright oben behalten wie es war, Beispiel Klasse: ArtnetDevice.java

Original :
/**
* Copyright (C) 2011 Michael Vogt <michu@neophob.com>
* Copyright (C) 2011 Rainer Ostendorf <mail@linlab.de>

Deine Version:
/*
* Copyright (C) 2012 Gyver

ist nicht so die feine art... Grundsätzlich finde ich es gut, dass PixelController jemand anders inspiriert, jedoch sollte dazu die nötigen credits gegeben werden und wie schon oben gesagt, copyright meldungen nicht einfach überschriebn werden.

cheers

@michuNeo
Könntest Du sowas bitte mit McGyver per PN klären, ich finde das gehört hier nicht her. Hier sollte es um die Software als solches gehen und der halbe Beitrag besteht bald nur darin über Copyrights zu diskutieren.

McGyver
Du hast mich überzeugt. Mit Deiner Software versuche ich auch mal ein bissel in die Matrix einzusteigen. Als erstes wollte ich dazu den Eiwomisa Controller dazu fähig machen MiniDMX zu empfangen und genau da liegt mein Problem. Leider finde ich keine wirkliche halbwegs "standardisierte" Versionsbeschreibung zum erweiterten MiniDMX ala "MiniDMX v3.0" oder so ähnlich. Ich würde mich bei der Empfangsroutine grundsätzlich erst mal an den Mini-DMX Standard halten. Nun gab es hier ja schon mehrere Diskussionen den Standard zu erweitern damit größere Pakete gesendet werden können, aber wirklich ein dokumentiertes Ergebnis gab es bisher nicht. In diesem Beitrag wurde zwar darüber gesprochen, aber als sich der "Vater" von MiniDMX dann gemeldet hat, hat sich das irgendwie verlaufen.

Ich würde hier gerne eine Senderoutine haben die dann mit dem erweiterten Standard funktioniert und mit dem bisherigen genauso. Vielleicht könnte auch Pesi da nochmals einen Beitrag erstellen wo es wirklich nur um diesen Standard geht und dieser nicht im TTT Bereich versauert. Es wäre dann natürlich auch gut wenn sich die Entwickler von der Software dort zu Wort melden würden.

Ansonsten finde ich es Top was hier gemacht wird.

Gruß, Benny.

Zitat von benkly

Könntest Du sowas bitte mit McGyver per PN klären, ich finde das gehört hier nicht her. Hier sollte es um die Software als solches gehen und der halbe Beitrag besteht bald nur darin über Copyrights zu diskutieren.

Naja, wenn da wirklich Copyright-Einträge überschrieben wurden, dann kann bzw. muss man schon öffentlich drauf hin weisen, das haben ja bestimmt auch schon ein paar in der "falschen" Version runtergeladen, die sollen das ja auch mitbekommen... was halt nicht geht, wenn der MichuNEO dem McGyver ne PN dazu schreibt...

Ein bisschen o.t. ist in so nem Forum auch ganz normal, siehe z.B. den Eagle-Thread, der auch zu 50% aus der alten (dort o.t.) Leier Eagle vs. Target besteht...

Zitat von benkly

Leider finde ich keine wirkliche halbwegs "standardisierte" Versionsbeschreibung zum erweiterten MiniDMX ala "MiniDMX v3.0" oder so ähnlich.

Weil's die noch nicht gibt! - das "Recht" auf den Namen "Mini-DMX" hat der Matthias Dzionsko, nur der kann ne Version 3.0 ausrufen... Daher war in dem Thread ja auch von einer "inoffiziellen Erweiterung" die Rede, also praktisch, man nimmt Mini-DMX als *Vorbild* (wie das da gemacht ist mit Blockstart/Ende und Framesize-Angabe) und macht ein Protokoll, das abwärtskompatibel ist, aber mit selbst festgelegten Framesize-Bytes... so als "Forums-Standard"

wie schon paar mal erwähnt, ist das dann meist auch kein "echtes" Mini-DMX mehr, weil eben dieses Frame doppelt puffern und bei Fehler verwerfen entfällt (*muss* auch oft entfallen, ausser man nimmt nen "wirklich großen" AVR mit meinetwegen 8 kB RAM, je nach Framegröße...), auch viele Sender (z.B. Glediator, DMXcontrol, ..) halten sich auch nicht genau dran, die schicken auch einfach raus, egal ob ne Rückmeldung kommt oder nicht...

ist eben (wie im anderen Thread schon angesprochen) auch gar nicht nötig, die Übertragung ist schon sicher genug... bei meiner Kugelketten-Matrix z.B. hängt ein "Mini-DMX"-Receiver direkt am Rechner, der empfängt nach Standard (also bis auf die Framegröße natürlich) Mini-DMX, puffert das auch und verwirft ggfs. Frames bei Fehlern, macht die Rückmeldung (damit PixelController den Port findet) - das Teil schickt dann aber über 20 m billiges Mikrofonkabel die Daten nach "Pseudo-Mini-DMX", also *ohne* Rückmeldung, *ohne* Frames verwerfen bei Fehlern, die Daten zu den Kugelketten-Controllern, mir wäre den ganzen Abend (5 Stunden Party) kein einziges Flackern oder sonstige Fehler aufgefallen...

Zitat von benkly

In diesem Beitrag wurde zwar darüber gesprochen, aber als sich der "Vater" von MiniDMX dann gemeldet hat, hat sich das irgendwie verlaufen.

naja, was heisst "verlaufen"...? - da gibt's halt einfach nix neues... der Matthias Dzionsko wollte sich dort wieder melden, wenn er den neuen Standard fertig hat, aber da ist er wohl noch dran...

ansonsten besteht der besagte Thread ja auch zu 70% aus o.t. über sichere Datenübertragung im Allgemeinen.. - ggfs. mache ich dann noch mal nen neuen hier bei "LED Schaltungen, Treiber und µC" auf... also wenn eben Interesse daran besteht, dass wir hier im Forum uns auf nen Standard einigen...

man kann nun also entweder drauf warten, bis der "Vater von Mini-DMX" nen neuen Standard veröffentlicht... oder wir machen hier im Forum einen eigenen *auf Basis von Mini-DMX*, den offiziellen Mini-DMX-Standard neu machen können *wir* ja nicht...

gehört ja auch in diesen Thread: McGyver, wenn Du dann "Mini-DMX" (oder wie auch immer) einbaust, was hältst Du von dieser Tabelle hier..? - Und MichuNeo und Pepe1981 (Ihr lest ja hier mit) ebenfalls gefragt, da sollten ja dann doch alle die selben Framegrößen und zugehörigen Startbytes benutzen, wenn man nicht wieder zu jedem Programm ne andere HW haben will....?

ansonsten kann ja auch jeder sein eigenes Süppchen kochen, notfalls halt dann alles über Artnet oder die jeweiligen proprietären Protokolle - aber *schöner* wär's natürlich schon, wenn man da ne gemeinsame, einfache Schnittstelle zu Eigenbau-HW hätte...

gute Idee! - darüber könnte man ja dann in diesem Thread weiter diskutieren, das wird hier sonst wirklich zu o.t. ...

Zitat von Pesi

naja, was heisst "verlaufen"...? - da gibt's halt einfach nix neues... der Matthias Dzionsko wollte sich dort wieder melden, wenn er den neuen Standard fertig hat, aber da ist er wohl noch dran...

Naja, nach Deinem Kommentar:

Zitat

Hm, naja, ausser dieser o.t.-Diskussion über die Sicherheit hat das leider niemanden so richtig interessiert - hier z.B. wurde das Mini-DMX-Protokoll mit den neuen Framegrößen eingebaut, das war's dann schon...

würde ich mich an Stelle von Mathias auch nicht mehr melden, zumindest hört sich der Kommentar von Dir danach an das es keinen Bedarf mehr gibt.

Ich benutze nun in dem Eiwomisa einen ATMEGA1284P, der hat 16K SRAM und somit stellt da das Puffern kein Problem dar. Und es ist auch nicht ganz so unwichtig das man sich bei dem Protokoll einig ist, das mag bei Dir bei so paar Lichtkugeln ok sein, aber nicht bei mir wenn ich das in meinen Controller reinsetze. Da kann ich nicht all Furz den Code ändern und von den Anwendern erwarten das die das alle selbst flashen, 99% dieser Anwender haben nicht mal einen Programmer.
Daher ist es für mich schon wichtig einen Standard zu haben und wir sollten da vielleicht nochmals auf Mathias zugehen. Ich könnte mir vorstellen das der Deine Aussage in den "falschen Hals" bekommen hat.

Gruß, Benny.

Ja, Du kannst Dir ja immer viel vorstellen... - darum geht's hier aber nicht... lt. Turi (der den Mathias auf diesen Thread aufmerksam gemacht hat) ist er an *seinem* neuen Standard dran, kommt wohl irgendwann, aber wieso sollte er posten, solange es nix zu berichten gibt..?

letztlich bezog sich sein Post hauptsächlich auch auf diese o.t.-These, dass sein Protokoll nicht sicher sei, er hat erklärt, warum es das seiner Meinung nach doch ist - dazu ein kleiner geschichtlicher Abriss über Mini-DMX - zum eigentlichen Thema lautet die Aussage ja:

Zitat von MDZ

Jedem ist es freigestellt das MiniDMX-Protokoll als Vorlage zu nehmen, mit eigenen Erweiterungen zu versehen und dann zu veröffentlichen. Er sollte dann aber deutlich darauf hinweisen.

Zitat von benkly

Ich benutze nun in dem Eiwomisa einen ATMEGA1284P, der hat 16K SRAM und somit stellt da das Puffern kein Problem dar.

Und wen interessiert's... - es gibt auch noch andere HW auf diesem Planeten als den Eiwomisa...

Zitat von benkly

Und es ist auch nicht ganz so unwichtig das man sich bei dem Protokoll einig ist, das mag bei Dir bei so paar Lichtkugeln ok sein, aber nicht bei mir wenn ich das in meinen Controller reinsetze.

Thread nicht gelesen...? - es geht doch eben *genau darum*, ein festgelegtes Protokoll zu schaffen! - meine paar Kugeln kann ich auch mit *irgendwas* steuern, dazu brauche ich weder nen Standard noch muss ich extra nen Thread im Forum aufmachen...

Und wer den schafft, ist doch wurscht - wenn alleine schon 3 Freeware-Matrixsteuerungen und div. HW hier aus dem Forum diesen Standard unterstützen, dann *ist* es einer, auch wenn er *genausowenig* wie Mini-DMX von USITT oder DIN oder sonstwas genormt ist! Damit geht das gewollte ja bereits, es geht letztlich nur noch um das angleichen von ein paar Parametern...

Wie gesagt, das kann doch jeder machen wie er will - auf die nächste offizielle Mini-DMX-Veröffentlichung warten, gemeinsam hier im Forum an einem Protokoll weiter arbeiten, das *jetzt bereits schon* zur Steuerung von Matritzen mit mehr als 512 Kanälen benutzt wird, oder ganz was anderes machen (Du kannst ja auch für Dich ein Eiwomisa-Protokoll schaffen, spricht ja nix dagegen).

Da das Ganze anscheinend ja für Verwirrung sorgt, würde ich dann vorschlagen, für das hier im Forum erarbeitete Protokoll (wenn es denn genug interessiert) einen eigenen Namen zu verwenden, und aber natürlich - wie sich das gehört - immer drauf hinweisen, dass die Vorlage dazu Mini-DMX war...

Zitat von benkly

Daher ist es für mich schon wichtig einen Standard zu haben und wir sollten da vielleicht nochmals auf Mathias zugehen.

ja, mach' doch, hindert Dich doch keiner daran...

also, bitte, keinen weiteren o.t. hier, über dieses neue Protokoll *auf Basis von Mini-DMX* kann man in dem zugehörigen Thread diskutieren, aber bitte auch dort *sachlich*, nicht wieder so Sachen wie *Du* irgendwleche Aussagen von mir auffasst...

Schaut gut aus - mit Artnet habe ich allerdings noch nichts zum Leuchten gebracht. MAC OSX Lion, 4x4 Matrix, folgende Config:

Zitat

#=========================
#frames per second
#=========================
output.fps=25

### ### ### ### ####
# DISPLAY SETTINGS #
### ### ### ### ####

# size of the pixel visuals
display.pixel.size.width=4
display.pixel.size.height=4
display.pixel.space=1

### ### ### ### ###
# OUTPUT SETTINGS #
### ### ### ### ###

# set ONE output device (null, artnet)
output.device=artnet

#=========================
# output dimension
#=========================
output.resolution.width=4
output.resolution.height=4

#=========================
# output mapping
#=========================
# Mapping is applied pixel wise. Do not point to outside matrix.
# Mapping overlays default mapping (horizontal from left top to
# right bottom). Begin with 0 to the number of pixels of your
# matrix minus 1. Devide numbers by ','
output.mapping=0, 1, 2, 3,4,5,6,7,8,9,10,11,12,13,14,15

# Define the pixel mode here. All Combinations of R, G and B useable.
output.pixel.mode=RGB

#=========================
#settings for ArtNet
#=========================
artnet.ip=192.168.1.90

#define how many rgb pixels are used on a universe, maximal 170 (=510 Channels)
artnet.pixels.per.universe=16

#define the first universe id
artnet.first.universe.id=1

#=========================
#settings for miniDmx (like the SEDU board)
#=========================
#minidmx.baudrate=115200

#EOF

Alles anzeigen

Artnet funzt bei mir leider auch noch nicht. Ist die Artnet datei eigentlich schon aktif?

Hi McGyver,

deine Anwendung sendet bei mir ein Universum ArtNet ohne Probleme.

Tests mit mehreren Universen mache ich die Tage.

Super!

Gruß

Armin

Echt genial!

Shapes ist wirklich super, da kann man ja auch die Kringel machen, die ich so mag - und noch viel mehr, super Sache!

Artnet funktioniert bei mir nun auch zuverlässig, bei der Alpha ging's mal und mal nicht, was aber natürlich auch wieder mal an meiner Uralt-Kiste liegen kann...

tatsächliche HW/Node habe ich leider noch nicht, nur mal mit Artnetominator nachgeguckt, ob/was da kommt, das zeigt nun *immer* Daten an

sehr schön wäre es nun noch, wenn es eine Möglichkeit gäbe, das direkt über USB seriell auszugeben...

die Diskussion über das modifizierte Mini-DMX ist leider wieder mal eingeschlafen, mir persönlich wäre es dann auch egal, ob das nun modifiziertes Mini-DMX ist, oder Pepe sein Protokoll, oder - wie schon mal im Gespräch war - ganz was neues eigenes...

ich würde dann dafür SW für nen µC machen, die dieses Protokoll empfängt, und damit direkt WS2801/TM1804/LPD6803-etc.-Strips ansteuert, bzw. DMX ausgibt (mal sehen, mit SW-UART sollten schon so 4-6 drin sein...) - damit nicht wieder irgendwer was falsch auffasst: Die stelle ich dann ebenfalls open source in's Forum rein, und die ist dann auch nicht auf irgendeine spezielle HW angewiesen...

Zitat von McGyver

Soll auf jeden fall kommen. Kann ich aber leider nicht testen. Macht das Implementieren also n bissel knifflig.

Da biete ich mich gerne an! - Turi wollte Dich eh' kontaktieren, ob Du Interesse daran hast, HW zum ausprobieren von ihm gestellt zu bekommen, da wäre ja ein Bootloader drauf, könnte ich Dir auch immer entsprechende Firmware zum testen schicken...

Ideal wäre halt, wenn man sich *erst* auf ein Protokoll einigt, dann bekommst Du die Test-HW, kannst Dein Ausgabemodul schreiben, was dann Pepe und Michu wiederum (wenn Interesse, zumindest Pepe hat schon solches signalisiert) bei sich einbauen können...

Zitat von McGyver

Mir isses im Prinzip egal. Ich würde sagen, ich implementiere dass, was die andern beiden schon drin haben.

Beide haben - neben Artnet - das "modifizierte Mini-DMX" drin, mit den Framegrößen wie hier angegeben - Pepe hat zusätzlich sein eigenes Protokoll... das wurde hier im Thread ja auch schon mal vorgeschlagen, das auch hier einzubauen...

dieses finde ich ja - wenn's rein um das verschicken von Pixeldaten geht - eigentlich auch nicht schlecht: bei dieser Anwendung ist's ja nun wirklich egal, ob man 254 oder 255 Helligkeitsstufen hat, aber dadurch, dass es ein dezidiertes Blockstart-Byte gibt, wird z.B. die Weiterleitung (Daisy Chain) deutlich einfacher als bei ner festgelegten Framegröße - also das kaskadieren von mehreren Empfängern ohne die explizit Adressieren zu müssen, wie Pepe es bei seinen Steuerplatinen ja auch macht...

das weitere vorgeschlagene neue Protokoll (Blockstart, 2 Bytes für die Framegröße, Nutzdaten, Blockende) hätte dagegen den Vorteil, dass man es auch zum übermitteln von Kommandos benutzen könnte, also z.B. Matrix-HW damit "aus der Ferne" konfigurieren" - wie gesagt Startbyte, dann High-Byte für die Framegröße, dieses aber max. 0x0F (mehr als 4.096 Byte/Frame machen über USB/Seriell wirklich nicht Sinn) - kommt statt 00-0F nach dem Startbyte FF, sind die folgenden Bytes Befehle, die man z.T. auch noch normen könnte...

z.B. so Sachen wie (*könnte* man dann machen, muss ja aber auch nicht), dass die Matrix zurück meldet, wie groß sie ist und wie verkabelt, und die SW sich dann automatisch darauf einstellt - oder eben, wurde ja schon oft nachgefragt, wenn man Szenen extern auf Standalone-Player speichern will, könnte man das auch über solche Befehle machen, z.B. "die folgenden 300 Frames unter Programm-Nummer 17 auf die SD-Karte speichern", o.ä.

wären halt viele Möglichkeiten, die man dadurch nutzen *kann*, aber auch nicht muss - einfach ein vielseitiges, auch noch erweiterbares Protokoll für viele solcher Anwendungen. Wirklich sinnvoll natürlich nur, wenn möglichst viele mitmachen...

bei Befehlen dann natürlich mit Rückmeldung (z.B. "Daten erfolgreich auf Karte gepeichert", "Konfiguration der Matrix: GBR 16x16 Snake vertical", etc., natürlich mit Kürzeln), beim reinen Daten senden aber ohne - um Zeit und Aufwand zu sparen, bei Artnet (UDP) gibt's ja auch keine Rückmeldung, ob die Pakete tatsächlich alle angekommen sind (?), und bei DMX auch nicht, das funktioniert ja auch alles seit Jahren problemlos...

auch so Sachen wie bei Pixelcontroller, dass ja den Port automatisch findet, wären damit wieder möglich: SW schickt halt an allen Com-Ports ne Abfrage raus, wo dann ne entsprechende Meldung zurück kommt, da hängt das Interface dran... oder auch mehrere

von weiterem rumgeschraube an Mini-DMX halte ich mittlerweile am wenigsten, da ist einfach z.B. das Problem mit den Blockgrößen, jeder hätte gern andere, Rückmeldung braucht Zeit und Aufwand, und falls doch mal das offizielle MiniDMX 3 kommt, wird's dann nicht mit der inoffiziellen Erweiterung kompatibel sein, dann gibt's nur noch mehr Verwirrung... solche ist jetzt ja schon vorhanden, weil der Artnet-Node von T64 nun schon andere Framesize-Bytes benutzt als Pixelcontroller und Glediator...

also lieber gleich was ganz neues eigenständiges.

Also wenn ich meinen Senf dazu geben darf (oder eher Wunsch), dann ist es das FF-Byte für "besondere Aufgaben". Ich denke, die Konfiguration oder auch der Aufruf von standalone-Programm und und und sollte schon vorbereitet sein.

Das Thema der Frame-Größe bis 4096 wird natürlich dann wieder interessant, wenn man über Netzwerk kommuniziert, also direkt. Dann sind sicher höhere Frame-Raten denkbar. Aber da hätte man ja auch noch genügend Raum nach 0x0F.

Was mir immer ein wenig am Herzen liegt, ist ein offline-Modus. Aber dazu fehlt momentan auch die passende Hardware. Ich denke, es gibt auch einige Anwendungsfälle, wo das sinnvoll ist. Dann könnte man ja das FF-Byte wieder nutzen und danach eine Programmnummer oder sowas vorsehen.

Aber alles nur als Idee/Wunsch verstehen ....