[patriche]

kenne das problem sehr gut, liegt meiner einschätzung nach aber nicht an Chamsys, die A7 (softwareupdate mitte jänner) verhalten sich mit einer Roadhog genauso.

[GunnarLoose]

Ja, mach das mal. Die sollen mal im Detail sagen was da geändert werden müsste.

LG
Gunnar

[C. Conrad]

Hi,

eventuell unter SETUP -> VIEW SETTINGS -> HARDWARE -> REDUCED RATE OUTPUT mal auf CONTINUOUS stellen?

Aber ich denke auch, dass es nicht an der Chamsys liegt. Hatte vor langer Zeit auch mal A7 an der Konsole
und konnte da keine Probleme feststellen.

Gruß
Christian

[redlightmt]

ok das mit dem output werde ich heute noch ausprobieren.
Lampen mit alter, also 1.0er Softwareversion hatten das Problem auch nicht.
Kam erst ab der 1.1er.

[redlightmt]

Ok, also jetzt hab ich mich noch mal eine Stunde an die A4 ran gesetzt.
Also ich glaube jetzt nicht mehr dass es an der Lampe liegt.
Ich hab einfach richtig bescheidenen DMX Output.
Vielleicht liegt es an der Mac OSX Version von MagicQ (neueste Version) oder auch an meinem Mini Wing.

Auf jeden Fall hab ich folgendes beobachtet:
JB A4 normal gepatcht -> auf Weiß -> Dimmer auf 50% -> Sinus EFX auf Dimmer mit 100% Fade und 100% Size
Bei Geschwindigkeiten unter 0.4 Sekunden kommt irgendwann nur noch Mist bei den Lampen an. (Reduced Rate Output im Setup auch schon auf alles Mögliche gestellt), immer das gleiche Problem, es wird völlig unrund und fängt zu stottern an und irgendwann stürzt das Programm komplett ab!!!!

So, das gleiche mit nem modifizierten A4 gemacht. Dimmerkanal vom Head zum Dimmermodus gemacht und auf Default 255 gestellt. (Damit der interne Dimmer der Lampe immer auf 100% steht und man virtuellen Dimmer patchen kann)
Dann zu jeder Lampe einen virtuellen Dimmer gepatcht.
Funktioniert alles bis dahin wunderbar.

Gleiches Spiel, auf Weiß -> Dimmer auf 50% -> Sinus EFX auf Dimmer mit 100% Fade und 100% Size
Naja jetzt gehts zumindest bis auf 0.25 Sekunden runter bis es anfängt auszuflippen und abzustürzen.

Irgendwie nicht sehr befriedigend grad. Gott sei Dank is mir das nicht während der Show passiert.

[patriche]

werd das am mittwoch mal mit winXP, PCWing und a7 mit 2.0 Software ausprobieren

[Pat]

Moin,

ich selber habe schon Stunden mit den Jungs von JB diskutiert....
aber ohne Erfolg !! Sie bringen immer die gleiche Erklärung die ja
nicht sein kann !! Ev hält sich JB und MA nicht an die DMX Spezifikation
und sendet einfach schneller... ?!?

kann jemand das DMX Signal " sniffen" ( aufzeichnen / analisieren ? )

Das geile ist ja das es mit ner JB Konsole und nem W-DMX oder einem Inteligenten DMX Splitter auch nicht mehr richtig spielt !!!

Wir betreiben unsere A7 mit der Firmware 1.0 da spielt es einwandfrei !!
Nun haben wir A-12 gekauft.... auch da ist das selbe Dimmerproblem !!!

Ich hoffe wir können das Problem lösen !!!

Gruss Ita

[Pat]

Zitat :

JB hat mit allen kommuniziert. Daraufhin haben wohl angeblich alle reagiert und ihre Software im Pult so überarbeitet, dass wirklich von 0 bis 255 über alle Werte gefadet wird.


Ha ha darum geht auch mit Avolite und Roadhog auch nicht !!

[GunnarLoose]

Moin,
also haben andere Pult auch Probleme damit???
Interessant. Wie soll es sich denn Verhalten im DMX???
Ist das nur bei schnellen Veränderungen so??? Oder... wie schnell muss der Fade sein damit
es nicht mehr geht.

Weil die DMX Werte kann man ja mit nem normalen DMX Tester auslesen und sich paralel betrachten.

LG
Gunnar

[Pat]

Laut JB muss jeder Wert von 255 - 0 ausgegeben werden...

also 255, 254 , 253 , 252 etc...

alles andere ( werte auslassen ) wird als flashen interpretiert und deaktiviert den fade Modus,
was ein ruckartiges Dimmverhalten zu folge hat !!

Aber wir wissen ja das bei schnellen Fades nicht mer alle " Werte" ausgegeben werden können...

demzufolge kann JB`s Aussage so nicht stimmen !!

Gruss Ita

[Pat]

Ev. kann das ja mal jemand im JB Forum "platzieren"....

nimmt mich wunder was sie zu dem Problem schreiben...

[Machtl]

Beim neuen 4port Ethernet-Interface von ChamSys kann man ja direkt auf die DMX-Framingdaten zugreifen, also Speed, Breakzeit etc...
Damit könnte man das doch mal gut austesten obs eventuell an der Refresh-Rate liegt oder dergleichen.

Zur Aussage "Alle Pulthersteller haben reagiert" kann man auch sagen "99,99% aller DMX-Lampen funktionieren mit dem Pult, nur die JB Lampen gehen nicht".

Also meiner Meinung nach liegt der Bug eindeutig auf JB Seite.

[Machtl]

Ev hält sich JB und MA nicht an die DMX Spezifikation
und sendet einfach schneller... ?!?

Wenn du 512 Kanäle mit 250kBit/s senden willst, und dazu das BREAK und MARK, dann ist bei 44Hz schluß.

Das geile ist ja das es mit ner JB Konsole und nem W-DMX oder einem Inteligenten DMX Splitter auch nicht mehr richtig spielt !!!

Kannst du das mal näher ausführen?

[redlightmt]

also ich hab mich bis jetzt nicht so wirklich mit dem Übertragungsraten von DMX beschäftigt weils immer das gemacht hat was ich wollte aber das mit den 44Hz versteh ich nicht. Wenn ich das richtig interpretiere (hier:http://www.soundlight.de/techtips/dmx512/dmx512.htm und hier: http://www.theater-technisch-lab.nl/dmxdu.htm) brauchts pro Frame 44us. Wenn man noch Break und Start Bits dazurechnet kommt man irgendwie auf 128 Mikrosekunden oder so. Mal die 256 Werte, komm ich doch auf 0,032 Sekunden oder so um von 0 bis 256 alle Werte auszuspielen.
Wie gesagt. Alles etwas wage und nicht wissenschaftlich, aber hab ich ungefähr Recht?

[Machtl]

Also 88µs RESET + 8µs MARK + 44µs Startbyte + 512*44µs Datenbytes = 22668 µs für einmal komplett alle 512 Kanäle senden.

1 / 22668µs = 44,1Hz

Und das sind jetzt mal die absoluten Minimalwerte für RESET, MARK und keine Pause zwischen den Datenbytes.