marcoboy

Verfasste Forenbeiträge

Ansicht von 14 Antwort-Themen
  • Autor
    Beiträge
    • als Antwort auf: LAS stürzt ab #225906
      marcoboy
      Teilnehmer

      Grundsätzlich stürzt schon mal nichts ab wenn es zu viel Speicher braucht, Windoof schon gar nicht da das System so etwas abfängt. Das Programm einfach keinen Speicher mehr bekommt wenn es ihn anfordert. Das sollte man dann in dem Programm auffangen.

      Das Problem wird er sein das die CPU nicht mehr in der Lage ist die Werte für die Channels zu berechnen, dann läuft irrend etwas gegen den Baum. Speicher und CPU lassen sich gut in dem System beobachten, das mit Hauseigenen Mitteln.

      Das ließe sich finden 😉 Allerdings gebe ich dir recht, das die Leistung dafür extrem dünn ist. Mittlerweile gibt es auch besseres in dem Format.

    • als Antwort auf: RDM Status messages wann obsolet ? #222883
      marcoboy
      Teilnehmer

      Was die Statusmessages betrifft ist zumindest in SYMPL alles behoben worden.

      – Zuordnung zu den Subdevices
      – E120_STATUS_XXX_CLEARED -> Status wird gelöscht bleibt aber weiterhin in der Liste als LOG erhalten
      – queued Messages auch für Subdevices

      Ungültige RDM Pakete gibt es nun auch nicht mehr 🙄 das Problem wurde behoben.

    • als Antwort auf: RDM Status messages wann obsolet ? #222882
      marcoboy
      Teilnehmer

      So langsam bekomme ich einen Fön 🙁 da es immer stärker darauf hinausläuft er e:cue und SYMPL als meinen eigen Code zu Debuggen.

      – ecue fragt DEVICE Info für die Subdevices nicht ab -> SYMPL schon
      – SLOT_DESCRIPTION funktioniert bei beiden nicht -> wird überhaupt nicht angefragt für Subdevices
      – SLOT_INFO schon
      – STATUS_MESSAGES fehlt die Zuordnung zu den Subdevices. SYMPL ignoriert diese komplett wie auch alles über 0x8000 .

      gibt es es eine Liste was unterstützt wird und was nicht ? Um so man in die tiefe vor stößt um so mehr Unzulänglichkeiten fallen einen auf 😥

    • als Antwort auf: Uhr im Butler XT2 geht heftig nach ! #225893
      marcoboy
      Teilnehmer

      NTP wird also nicht unterstützt … Schade denn der IP Stack hat mit Sicherheit diesen Dienst. So hätte man einen Server dort eintragen können. Es gibt hierzu auch externe Lösungen mit DCF oder GPS die dann einen NTP Server zur Verfügung stellen.

      Der Butler könnte dann z.Bsp jede Stunde die Zeit prüfen und korrigieren wenn die Abweichung zu groß ist. Bzw. beim reboot sich die Zeit auch holen.

      Alternativ veröffentlicht man den Mechanismus zum setzen der Zeit per Ethernet, vom Programmer aus ist dies ja möglich. Bei Interesse bastel ich dann eine DCF oder NTP Lösung wenn das Ergebnis der passiven Korrektur unbefriedigend ausfällt.

      Über RDM wäre es auch möglich die Zeit zu holen. Allerdings funktioniert RDM offline nicht der RDM Stack läuft in der Software. Der Butler reicht das GET/SET nur durch.

    • als Antwort auf: RDM Status messages wann obsolet ? #222881
      marcoboy
      Teilnehmer

      Ich muss nochmal nerven 🙄

      Kann es sein das e:cue die STATUS_MESSAGES mit ACK_OVERLOW ignoriert ?

      Fassen wir zusammen wie es sein sollte :bang:

      Sind im Paket mehr wie 25 Messages wird ACK_OVERFLOW gesetzt
      kommt die gleiche PID mit TN +1 wird der Rest über tragen -> ewt, erneutes OVERLOW wenn > 25 Messages.

      Kommt dazwischen eine andere Anfrage wird diese beantwortet und beim weiteren GET_STATUS_MESSAGES die Liste wieder von vorne übertragen , es folgt ein erneutes ACK_OVERFLOW …

      Der Sinn dessen ist das der Controller die Übertragung mit einer andern PID abbrechen kann.
      Die Messages gilt erst als Gesendet wenn alle Daten übertragen wurden. Bei nächsten GET_STATUS_MESSAGES wird die liste gelöscht.

      Was mit SYMPHOLIGHT wieder funktioniert scheitert bei e:cue dort schweigt der Programmer bei einen Messages Count größer 25 .

      Mein Logic ANALYSER zeigt alles ok. Der Programmer holt sich auch die Daten zeigt sie aber nicht mehr an.

    • als Antwort auf: RDM Status messages wann obsolet ? #222879
      marcoboy
      Teilnehmer

      Erstmal Danke ..

      In so weit habe ich auch alles korrekt umgesetzt. Das Gerät hat schon die Möglichkeit dem Controller mitzuteilen das Fehler etc. aufgehoben wurden. Hierzu wurden folgende Statustypen zusätzlich vereinbart.

      STATUS_ERROR_CLEARED, STATUS_WARNING_CLEARED,STATUS_ADVISORY_CLEARED

      Wenn der Programmer mit ADVISORY fragt bekommt er alles messages zurück auch _CLEARED. Womit der Status aufgehoben wird. Diese Erweiterung ist wohl nicht implementiert 😉 Ich ging davon aus das dass icon damit wieder verschwindet. Nun gut muss man es so machen, per e:script geht das auch ?

      :edit in der beta von SYMPHOLIGHT funktioniert das ganze wie vorgesehen. Die Symbole und die Messages werden gelöscht.

    • als Antwort auf: RDM Timeout Logs #222873
      marcoboy
      Teilnehmer

      Ich muss das noch mal hoch holen.


      01/12/17 18:34:28 : [RDM 1] Butler S2 port 0: device 534C:390400CD: Hiding gateway timeout
      01/12/17 18:38:26 : [RDM 1] Butler S2 port 0: device FFFF:FFFFFFFF: Hiding gateway timeout
      01/12/17 18:48:22: [RDM 1] Butler S2 port 0: device 534C:390400CD: Forwarding gateway timeout

      Ich habe meinen eigenen RDM Stack programmiert. Ab und zu tauchen dort diese Warnungen auf aber nicht von meinen sondern von Soundlight Geräten. Äußerst selten auch mal mit meinen UIDs .

      Die Warnung ist leider bezogen auf ihr Problem nicht sehr aussagekräftig.

      Kurz gesagt beim schreiben gefunden in dem ich die Netzwerkverbindung im Programmer deaktivierte wird diese Meldung generiert. Offenbar sendet der Butler die RDM Antwort nicht zum Programmer “Gateway = Butler ” . In den Log aus diesen Thread sind die gleichen Wahrungen enthalten. Macht dieser das weil die RDM Antwort vom Gerät verworfen wurde ? oder weil auf der Ethernet Seite das Paket nicht ankam ?

      edit: das Problem ist unabhängig vom Gerät welche UID in der Warnung enthalten ist hängt nur davon ab welche UID der Programmer gerade bearbeitet. Trennt man dabei die Verbindung kommt die Warnung im Dauerlauf . Offenbar hängt der Code dann in der schleife fest 😉 …

    • als Antwort auf: WS2812 LED #225888
      marcoboy
      Teilnehmer

      Wenn es also einfach Tubelites ersetzen soll kann man das verhalten auch fest einprogrammieren und per DMX beeinflussen.

      Also man programmiert dann ein Fixture für sein neu kreierten gerät und jede DMX Steuerung kann das ganze dann mit moderaten Kanälen ansteuern.

      Wenn nur per DMX und ein Ws2812 Channel ist kann man das mit einen 8bit AVR Arduino etc etwas Code kosten günstig Realisieren.

    • als Antwort auf: WS2812 LED #225887
      marcoboy
      Teilnehmer

      Hallo

      dazu gibt es Lösungen z.Bsp von Radig oder auch von madrix. Die Hardware von Madrix wird wohl funktionieren die von Radig so lala. Unter e:cue mit der damaligen Software nicht. Verliert immer wieder den Link.

      Die Umsetzung vom Artnet wie auch die Stabilität, Verdrahtung sind beim Radig nicht sehr toll.

      Ich habe etwas mit einen Arduino Due am Start. Artnet 4 konform und die Ausgabe erfolgt mit dem PWM Controller. Dieser wird per DMA so gesteuert des es das Datensignal des Ws2812b ergibt. Das weißt Signal kein Jittern etc. alle Universen werden Synchron ausgegeben. Beim Radig wackelt es ganz schön manchmal da er die Ausgabe per DMA über den GPIO realisiert. Außerdem ist es nicht so einfach das ganze zu synchronisieren..

      Einfache Sachen könnte man auch fest so ausgeben, die Länge des Streifens ist ja nicht begrenzt. Allerdings sinkt dann die Framerate. Über Jinx! kann man die Ausgabe in eine Datei umleiten und dann über SD ausgeben.

      Meine Lösung arbeitet Momentan mit 4 Universen. 8 Stränge mit je 170 LEDs wären möglich. Artnet bietet aber nur 4 Universen pro Node. Man kann auch mehr daraus machen allerdings mit der selben MAC. das ist nicht Artnet konform und mit einen externen IP Stack solche Datenmengen zu verarbeiten ist schwierig. Das geht mit dem W5500 mehr als mit dem alten ENC28J60.

      Ich hätte noch eine Lösung mit einen Xmos MCU die könnte in der Lage sein alle 6µS ein Paket zu verarbeiten. Es dauert aber noch das Projekt zu portieren. Damit wären auch 50 und mehr Universen möglich.

    • als Antwort auf: e:cue Programmer Artnet Poll Reply packet zu kurz ?! #222864
      marcoboy
      Teilnehmer

      Ich arbeite momentan das Paper von Artnet 3 ab aber an der Länge des Reply Packets wurde nichts geändert die Versionen sollten zueinander kompatible sein. Deswegen wurden auch filler eingebaut. Mir viel das nur auf weil e:cue zufällig auf dem Netz lief und auf ein Poll Antwortete.

      Aktuelle Version wenn man das bei 2013 noch sagen kann 🙄 Wie gesagt als Controller macht der Programmer das was er soll, in soweit ist alles korrekt.

      RDM über Artnet unterstützt er aber nicht ? Timecode schon ?

    • als Antwort auf: e:cue Programmer Artnet Poll Reply packet zu kurz ?! #222862
      marcoboy
      Teilnehmer

      Bitte schön .

      Die 192.168.1.160 ist der Programmer …

      Der Style Code ist auch falsch 🙄 nicht 0x00 sondern 0x01 ist ist eine Console .

    • als Antwort auf: fader unit #225881
      marcoboy
      Teilnehmer

      Hallo,

      ich bin letztens etwas verrutscht im Plan 😉 der Mux der Fader ist darunter, was bedeutet es doch Encoder sind. Diese laufen über den 541 als Latch und geben den Status auf den Datenbus.

      PullUp Prüfen und die Umschaltung von A0 über das 7400 auf die beiden 74541 funktioniert.

      Wenn du keine Ahnung lass dies irrend wo machen, es wird durch unprofessionelle Lötversuche nicht schöner.

    • als Antwort auf: fader unit #225879
      marcoboy
      Teilnehmer

      Das ist ein Analog Switch, die Analogen Signale werden bei Mux auf die beiden ADCs des Pics geschaltet. Wenn das auswählen der Adresse nicht richtig funktioniert werden Werte von anderen Kanälen eingelesen.

      Ich sagte ja irrend wo fehlen Bits vom Datenbus.

    • als Antwort auf: fader unit #225877
      marcoboy
      Teilnehmer

      Die LEDs hängen an einen HC574 und dessen Clock läuft über einen Adressdecoder. Durch einen Hardreset gehen die LEDs aus, da die Flip Flops zurückgesetzt werden.

      Mit dem Clock werden die Daten für 8 LEDs vom Bus übernommen. Vermutlich sind Leiterbahnen durch gefault und der CLK liegt nicht korrekt an den Gattern. Auch Abblockkondensatoren sind nicht Cola oder Bierfest. Somit kommt es zu einen Fehlverhalten.

      Die Jogs sind in der Tat wirklich Potis ohne Anschlag. In der Zeit wo das Konstruiert wurde gab es kaum µP die mit 5 Encodern fertig geworden wären und wenn wären sie nur damit beschäftigt gewesen.

    • als Antwort auf: Fader in Fader unit #224354
      marcoboy
      Teilnehmer

      10k

      ich könnte nachschauen, die Fader sind von Alps. Die Baureihe findet man, mit der passende Aufnahme schon weniger.

      Bei bekannten Elektronikhändler nicht leicht bis gar nicht zu bekommen. Ich habe diese damals in gewissen Mengen bei Alps bezogen.

      Allerdings würde ich das wechseln ohne Professionelle Endlöttechnik nicht empfehlen oder gar davon abraten.

Ansicht von 14 Antwort-Themen