LED Streifen über C# oder Visual Basic oder xxx?

    LED Streifen über C# oder Visual Basic oder xxx?

    Grüß euch,ich bin leider auch ein Anfänger und bräuchte eure Hilfe für unser Projekt.
    Wir wollen einen Regal mit 10 Fächern mit LED Streifen beleuchten und diese LED Streifen sollen gemeinsam verschieden Lichtspiele von sich geben!
    Wird aber über ein Menu (C# oder Visual Basic) eine Auswahl getroffen wie z.B.: Was wollen Sie heute anziehen? Antwort T-shirt und Jean--> dann sollen nur die Regale leuchten wo Jeans und T-Shirts enthalten sind..

    Also nur gewisse Teile/Felder von einem LED Strip.
    Meine Hardware:
    2 WS2812 LED Streifen mit je 5m
    ein ArtNet, sACN 4096 Kanal LED Pixel Controller von Ulrich Radigein
    Diamex LED-Controller-L mit IR-Fernbedienung für WS2812-LEDs als alternativevielleicht

    hat schon jemand von euch mit Visual Basic, C# oder einer anderen Software direkt gewisse Felder von einem LED Streifen angesteuert?
    Wäre für jede Hilfe dankbar,

    grüße,
    joe
    Wenn du den Radig Controller verwendest, dann musst du deine Pixel als Artnet oder sACN senden, sind eigentlich nicht so kompliziert die Protokolle:
    Artnet: artisticlicence.com/WebSiteMaster/User Guides/art-net.pdf
    sACN (auf der Seite nach E1.31 suchen): tsp.esta.org/tsp/documents/published_docs.php

    Wenn du den Diamex nimmst, kannst du die Pixel im TPM2 Format via USB schicken (virtual COM Port), serielle Daten senden ist quasi noch einfacher als Netzwerkdaten und der Protokoll-Rahmen ist deutlich übersichtlicher und einfacher, allerdings musst du PC/Controller dann via USB verbinden und hast da natürlich auch Grenzen in der Kabellänge.
    TPM2 Specs gibts hier im Forum: tpm2 - Protokoll zur Matrix-/Lichtsteuerung

    Ich würde mich vermutlich für das Netzwerkprotokoll entscheiden, ist zwar ein bisschen mehr aufwand zum programmieren, aber du bist flexibel was die Ansteuerung betriifft da es über Netzwerk geht. Somit kein problem mit den Kabellängen, etc. oder auch via WLAN Bridge machbar.
    Danke für die Antworten, ich habe mir inzwischen auch einen raspberry pi und einen arduino besorgt, über arduino war es gar kein Problem aber der reiz ist natürlich mit dem Lan Controler von Radig die ganze Sache zu lösen :)
    Habe auch mit Radig Kontakt aufgenommen aber der hat mir nicht wirklich weiter helfen können oder wollen, trotzdem finde ich seine Hardware super und ich denke das wird auch noch laufen, aufgeben werde ich sicher nicht, .

    Da wir gerade Nachwuchs bekommen haben komme ich leider nicht wirklich dazu, sobald ich aber das ding zum laufen gebracht habe, wird der Code natürlich veröffentlicht..

    Grüße,
    Joe
    Hallo zusammen,

    nach tagelangem Versuchen und rumexperemtieren möchte ich kurz mein Problem erläutern. Ich denke es passt zu diesem Thread:

    Ich möchte Jinx! über eine Visual Basic Applikation steuern um einfache Szenen auszuwählen (Nutze also die Jinx! Remote Control Funktion). Ich ich habe mich für das tpm2 Protokoll entschieden, da es für mich den schnellsten Einstieg in kombination mit Visual Basic bietet (Einfache versendung von Bytes über die Write-Methode). Um meine Applikation mit Jinx Remote Control zu verbinden nutze ich die Software "Virtual Serial Port Emulator (VSPE)" von Volodymyr Ter.
    Laut Monitoring-Bericht versendet meine Visual Basic Applikation die entsprechenden Bytes die das tpm2 Protokoll benötigt. Jinx! ließt diese auch entsprechend aus dem COM-Port aus.

    Laut Jinx-User Manual 2.4 interpretiert Jinx einen 8 Bit Wert (also ein Byte) um z.B. eine Szene auf Kanal 0 auszuwählen.

    Die Frage ist nur: wie muss der genaue Aufbau in tpm2 aussehen, damit Remote Control (Jinx) einen Szenenwechsel vollführt (Z. B. Szene 5 wählen)???

    In meinem Fall sende ich über die Visual Basic Applikation folgende Bytes als Array.

    0xC9 / Blockstart-Byte nach tpm2-Spezifikation (seriell)
    0xDA / Ich will ein Datenbyte senden. Richtig für einfache Jinx! Szenenauswahl???
    0x01 / Framegröße des Highbyte
    0x01 / Framegröße des Lowbyte
    0x05 / Mein Datenbyte (hier soll Szene 5 gewählt werden) entpricht im Dezimalsytem ebenfalls dem DataByte = 5
    0x36 / Blockende-Byte nach tpm2-Spezifikation

    Kann mir jemand helfen? Ich sitze schon recht lange an diesem Problem und habe schon X Varianten in Visual Basic durchgespielt.

    Oder muss ich Jinx Remote Control über das Kommando-Byte ansprechen (also Byte 0xC0 anstatt 0xDA)? Falls dies der Fall ist: Was muss ich dann bei Kommando-Kontrol-Byte beachten?

    Viele Grüße,

    TP
    Framesize ist falsch, das High Byte muss 0 sein, so wie bei Dir wäre das ja Framegröße 257 ;)

    ich weiß nicht, ob Jinx! Remote auch nur ein Byte auswertet, normal sind es (m.W.) drei, Szene, Helligkeit und Strobo.

    steht bestimmt irgendwo in der Anleitung...
    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!
    Danke für den Tipp, Pesi! Mir ist es gestern Abend wie Schuppen von den Augen gefalllen: Jetzt habe ichs geschnallt: Die Frame-Größe wird über den 16 Bit Wert angebenen (so wie es auch in deinem tpm2-Thread bechrieben wird!) Also vollkommen Falsch von mir. Habe es gestern Abend noch direkt implementiert

    Stimmt laut User Manuel 2.4 steht dort wörtlich: Jinx! will receive every tpm2 frame with a minimum of 4 and maximum of 512 channels
    and will use the given start channel for the first control.

    Darauf hin habe ich direkt versucht alle Jinx Control Känäle (Insgesamt 7) jeweils über ein Byte anzusteuern (Zahlenwerte gemäß Jinx User Manuel 2.4) und hatte jetzt nach Tagen des Versuchens sogar einen kleinen Teilerfolg: Jinx empfängt Bytes und stürzt sofort ab.

    Ich habe diverse Varianten bezüglich des versendens über die Visual Basic Write-Methode ausprobiert: Das einzige was anscheinend wirklich gut funktioniert ist, dass senden über meine Visual Basic Applikation und das Empfangen der Bytes von Jinx. Ich kann dies über eine unabhängige Monitoring Software sehen.

    Ich möchte nochmals die Bytes hier aufführen die ich versendet habe. Evtl. liegt es ja ein einem kleinen Syntax- oder Denkfehler den ich beim ansprechen von Jinx! Remote Control übersehen habe. Ich versende die Bytes gleichzeitig in einem Byte-Array:

    0xC9 / Blockstart-Byte nach tpm2-Spezifikation (seriell)
    0xDA / Ich will ein Datenbyte senden. Richtig für einfache Jinx! Szenenauswahl? Oder muss ich über das Kommando-Byte gehen (also 0xC0)
    0x00 / Highbyte zur Definition der Gesamtframegröße
    0x07 / Lowbyte zur Definition der Gesamtframegröße. Ich will 7 Bytes versenden um die sieben Remote Control Kanäle von Jinx zu steuern.

    0x05 / die fünfte Szene soll auf der linken Seite dargestellt werden
    0c00 /Szene rechts. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
    0x00 /Chase. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
    0x01 /Crossfade Mode. Laut User Manuel: Werte zwichen 0 und 20 entsprechen dem Progressive Mode
    0x00 /Crossfade einstellen. Wert 0 steht für "ganz links"
    0x00 /Master Stobo: Wert 0 steht für "off"
    0x78 /Master Brigthness, Entspricht ca. dem Dezimalwert 120. wollte ich auf ca. der hälfte haben.

    0x36 / BlockEnde-Byte nach tpm2-Spezifikaiton

    Evtl. kann mir beim Problem jemand helfen.Ich sitze beteits schon mehrere Abende an diesem Probelm dran und kann mir nicht vorstellen, dass es so schwer ist ein paar Bytes an Jinx zu senden.

    Wenn ich mit meiner kleinen VS.NET-Applikation fertig bin, werde ich den Code in allgemeiner Form hier zu verfügung stellen, damit jeder was davon hat. Gerne auch im 1:1 Original Visual Basic Code mit Bildern meines LED-Projekts.

    Gruß,

    TP

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „LED_TP_“ ()

    Hm, ich habe das zuletzt benutzt, als Jinx! Noch weniger Bytes wollte, in einer früheren Version. Ob das mit dem abstürzen nun einfach an Jinx! liegt, kann ich daher nicht sagen. K.A., ob das ein bekanntes Problem ist, so viele Leute benutzen diese Fernsteuerung m.W. nicht...

    kann mir aber nicht vorstellen, dass der Seddie das nicht getestet hat... evtl. liegt's an diesem virtuellen Com-Port, dass das damit nicht zurecht kommt...? - der tpm2-Frame wie von Dir gepostet ist jedenfalls korrekt...
    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!
    Danke für die Antwort, Pesi! Ich kann nun den tpm2-Frame als korrekt vorausezten.

    Nach einem weiteren Sonntag vormittag habe ich das serielle tpm2-Protokoll verworfen. Anscheinend liegt es tatsächlich an der Software die den virtuellen COM-Port emuliert. Hatte keine Lust mehr mich mit dem seriellen Port auseinander zu sezten. Ich bin jetzt auf das tpm2.net Protokoll umgestiegen, was sich mit VB.NET auch recht leicht realisieren lässt.

    Ich nutze also jetzt UDP zum versenden meines tpm.net Blocks und Jinx! kommuniziert jetzt wunderbar mit meiner Applikation!!!
    Bin als jezt heilfroh und es kann weitergehen.

    Im folgenden will ich das vorhegen für die Allgemeinheit erklären:
    Ich sende Daten für alle 7 Remote Kanäle von Jinx! (Jinx 2.4). Die im folgendem präsentierten Bytes im Hex-Darstellung werden dabei in einem Byte-Array über UDP versendet. Zum allgemeinen vorgehen beim versenden von Daten über UDP gibt es reichlich Tutorials im Netz. Daher will ich es hier neutral und unabhängig von einer Programmiersprache darstellen:

    Quellcode

    1. / Protokoll-Header
    2. BlockStartByte = 0x9C /Blockstart-Byte nach tpm2-Spezifikation (seriell)
    3. TypeByte = 0xDA /Es sollen Daten gesendet werden
    4. FrameSizeHighByte = 0 /Highbyte zur Definition der Gesamtframegröße
    5. FrameSizeLowByte = 7 /Lowbyte zur Definition der Gesamtframegröße. 7 Bytes werden versendet um die 7 Remote Control Kanäle von Jinx zu steuern.
    6. Packetnummer = 1 /Angabe der Packetnummer nach tpm2.net-Spezifikation.
    7. Packetanzahl = 1 /Angabe der Packetanzahl nach tpm2.net-Spezifikation. =1 Für einfache Kontrolle von Jinx.
    8. /Jetzt kommen 7 Datenbytes zur eigentlichen Stueerung von Jinx! 2.4. Die gültigen Werte können Jinx! User Manuel entnommen werden
    9. SceneLeft = 1 /die erste Szene soll auf der linken Seite dargestellt werden
    10. SceneRight = 0 /Szene rechts. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
    11. Chase = 0 /Chase. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
    12. CrossfadeMode = 1 /Crossfade Mode. Laut User Manuel: Werte zwichen 0 und 20 entsprechen dem Progressive Mode
    13. CrossValue = 0 /Crossfade einstellen. Wert 0 steht für "ganz links"
    14. Strobo = 0 /Master Stobo: Wert 0 steht für "off"
    15. MasterBright = 0xFF /Master Brigthness, Entspricht dem maximalen Wert.
    16. BlockEndByte = 0x36 /Blockende-Byte


    So. das wars erstmal für heute. Das Gesprojekt wird folgt, wenn es einen soliden Stand erreicht hat.

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

    Cool, dass es funktioniert! - und klar, tpm2.net ist ja hier auch einfacher, weil keine spezielle Zusatz-sw nötig... ;)
    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!