DMX ouderwets?

[DJ Antoon]

Helaas heb ik daar geen antwoord op. Ik moet zeggen dat ik het probleem zelf niet ken. Iemand anders hier een idee over?

Kan ook dat er hikken in de aansturing zit.
Ik gebruik zelf 10 ledtubes van ieder 48 kanalen, die staan op cm's van elkaar.
Totaal dus 480 kanalen, ik draai dit op ledtrix een plug in van martin lightjockey en ik zie nooit schokken.
En ja natuurlijk op 1 dmx lijn.

De andere DMX lijn zit trouwens een heel eind vol met bewegend licht en ander spul.

Maar misschien is dat ook mede aan de gebruikte electronica, alle data word op de break (zo noem je dat geloof ik) in ieder geval synchroon op de led uitgang gezet.

LJ draait trouwens op een oude PIII.

[Paul10]

Totaal dus 480 kanalen,

onder de 500 kanalen gaat het bij mij ook nog goed, kom ik daar boven gaat het fout(bij hoge snelheid van lichtwissels) werk zelf met MA light ultralight of micro, toch best een okee tafeltje, die volgens de logic-analyzer netjes uitstuurt, Ik denk zelf hat het probleem in de timing zit van de changes en het dmx protocol.
Voorbeeld.

als ik een refresh-rate/dmx heb van 44 keer seconden = 0,0137 sec tussen break - break
en ik flash met 10 HZ in chase . 0,03 seconden aan en 0,03 seconden uit,

dan ik de kans heel groot dat hij een paar flitsje overslaat of nie?

[laserguy]

0.03 seconden is 33 Hz...

[Paul10]

@ laserguy, thanks stom van mij maar komt op het zelfde neer.


als ik een refresh-rate/dmx heb van 44 keer seconden = 0,0228 sec tussen break - break
en ik flash met 10 HZ in chase = 0.1 . . 0,05 seconden aan en 0,05 seconden uit,

dan ik de kans heel groot dat hij een paar flitsje overslaat of nie?

[laserguy]

DMX slaat geen stapje over maar misschien de sturing wel in het toestel wel. Ik heb hier bijvoorbeeld switchpacks liggen die een aantal keren een correct DMX-pakket moeten ontvangen hebben vóór ze reageren.

[Paul10]

DMX slaat geen stapje over

nee dat snap ik. maar ik heb het even uitgerekend"laatste poging". als de DMX een refresh-rate heeft van 44hz(meest gunstige geval bij 512 patch) en ik heb een chase die pulst op 15 HZ = 0.0334 aan en 0.0334 uit. de ficture krijgt dan te zien (vanwege de timing tussen de refrash-rate en de chase timing) aan 0.0456/ uit 0.0228/ aan 0.0456 / uit 0.0213 enz. als je dan een lichttafel hebt die iets langere refrash-rate heeft(misschien heeft de GMA dat wel = zeer waarschijnlijk) ga je dit zeker zien.

en dan ga ik er inderdaad voor het gemak nog even van uit dat de fictures er geen probleem me heeft. als je bitmappen snel laat bewegen is dit geen ondenkbare situatie.

[laserguy]

Normaal gezien dient de software van je lichttafel daar rekening mee te houden. Het is niet dat de tafel eerst een signaal gaat maken dat dan door de DMX gesampled wordt. In theorie kan er dus tot 22 Hz gepulst worden (22 frames aan, 22 frames uit). Grote bitmaps tegelijk laten bewegen besteed je beter uit aan een mediaserver met meerdere universums.

[Paul10]

Normaal gezien dient de software van je lichttafel daar rekening mee te houden.

dat kan dus volgens mij niet want de snelheid van de DMX is de factor, er is volgens mij NO WAY dat je dit met software kan oplossen, tenzij je de refreshrate van je DMX gaat aanpassen op de timing van je chase. en dat word een onmogelijkheid als je meerdere chases hebt.

Het is niet dat de tafel eerst een signaal gaat maken dat dan door de DMX gesampled wordt

Signaal ? snap ik niet leg uit. tafels hebben zover ik weet een vaste timing voor de DMX. meestal gaat dit via een UART in de controller die de dmx verzorgt. Deze word ingesteld op een vaste baudrate en van de bytes voorzien. het moet mijn inziens haast wel dat dit wel in 1 keer gesampled word.

In theorie kan er dus tot 22 Hz gepulst worden (22 frames aan, 22 frames uit).

snap frames niet maar. maar neem aan dat je bedoeld 0.0455 sec aan/uit. Het klopt dat je daarna inderdaad sneller informatie wil versturen dan je refrashrate, gezien de timing gaat het volgens mij dus al eerder fout.

Grote bitmaps tegelijk laten bewegen besteed je beter uit aan een mediaserver met meerdere universums.

.

zijn we weer 1 pagina terug met mijn vraag:

nu is het natuurlijk zo dat je hier beter een media-of-zo-iets-server voor kan gebruiken, dus:
DMX verkeerd toegepast of gewoon meer DMX lijnen gebruiken of is DMX veroudert (te traag)?

[laserguy]

Je software van de tafel gaat niet eerst intern analoge signalen maken die dan door een DMX gesampled worden. Als je op 15 Hz iets wilt laten knipperen, weet zij ook dat ze dat moet berekenen naar 44 DMX-pakketten en daar proberen het beste van te maken. Er is dus helemaal geen signaal dat gesampled wordt maar een directe datastroom die gegenereerd wordt (opgebouwd/geconstrueerd uit berekeningen).

Die laatste vraag is filosofisch: als je op den duur van plan bent om hoge resoluties als 800 x 600 aan te sturen, ga dan gewoon via VGA... DMX is bedoeld om lampen aan te sturen, voor gigantisch veel pixels te sturen gebruiken we vga/hdmi/... Moet gans de industrie dan ook maar de RS232/RS485 of CAN-bus buitengooien omdat die ook te traag zijn om gigantische hoeveelheden data door te sturen? Dacht het niet toch? Je moet gewoon de dingen gebruiken waar ze voor gemaakt zijn. Je rijdt ook geen Formule 1 met een Fiat 500...

[Paul10]

Je software van de tafel gaat niet eerst intern analoge signalen maken die dan door een DMX gesampled worden.

heb ik dit beweerd dan?

(Betrap mezelf op het feit dat dat nog gebeurt ook ;-) hoe leest je tafel een fader uit dan?)

Als je op 15 Hz iets wilt laten knipperen, weet zij ook dat ze dat moet berekenen naar 44 DMX-pakketten en daar proberen het beste van te maken. Er is dus helemaal geen signaal dat gesampled wordt maar een directe datastroom die gegenereerd wordt (opgebouwd/geconstrueerd uit berekeningen).

wat bedoel je met 44 DMX-pakketten?? Ik moet zeggen dat ik al aardig wat ontworpen heb op basis van DMX( ook wel zij genoemd), maar hoe je dat wil doen is voor mij een grote vraag, theoretisch kan dit niet, misschien kan je mij onderbouwd uitleggen hoe. want ik geloof niet dat ik jou een timing probleem uit kan leggen.

Die laatste vraag is filosofisch: als je op den duur van plan bent om hoge resoluties als 800 x 600 aan te sturen, ga dan gewoon via VGA... DMX is bedoeld om lampen aan te sturen, voor gigantisch veel pixels te sturen gebruiken we vga/hdmi/... Moet gans de industrie dan ook maar de RS232/RS485 of CAN-bus buitengooien omdat die ook te traag zijn om gigantische hoeveelheden data door te sturen? Dacht het niet toch? Je moet gewoon de dingen gebruiken waar ze voor gemaakt zijn. Je rijdt ook geen Formule 1 met een Fiat 500...

interessant leg eens uit hoe je ledjes aanstuurt met VGA. Ik had het gewoon over een ledje laten knipperen op een vol gepachte dmx lijn.

Ik dank je op het antwoord op mijn filosofisch vraag:
nu is het natuurlijk zo dat je hier beter een media-of-zo-iets-server voor kan gebruiken, dus:
DMX verkeerd toegepast of gewoon meer DMX lijnen gebruiken of is DMX veroudert (te traag)?

@ lazerguy Ik Probeer onderbouwd uit te leggen wat de beperkingen van DMX zijn (als advocaat van de duivel). met de vraag daarbij of dat als "Probleem" word ervaren.
Als je mij technisch niet geloofd prima dan niet. de discussie over can/ RS232/RS485, wil ik graag (op een ander forum) met je voorzetten. Van auto's weet ik niets, dat neem ik blind van je aan.

Mag ik zo onbeleefd zijn de conclusie te trekken dat jij (net als ik overigens) het huidige protocol afdoende vindt . ondanks de beperkingen?

[kokkie]

Even voor de duidelijkheid, het ontwerp van de strobe en de software van de strobe bepalen hoe het op DMX reageert. Het is niet de desk die een aan/uit signaal naar de strobe stuurt!

Bij de ene strobe kan ch1 @ 40% 10 hz zijn en bij de andere strobe ch3 @ 80%.
De personality/library file in de desk zorgt ervoor dat de desk het goede kanaal en de goede waarde uitstuurt. Dus wil jij met beide strobes een minuur lang stroben, zal hij voor de ene een minuut lang 40% en van de andere een minuut lang 80% uitsturen en niet op de door jou gewenste freq. aan en uit gaan.
Voor dit soort problemen zit de oplossing dus al in het armatuur.

Voor de rest van de problemen zit de oplossing in de beperkingen.
Voor bitmaps het menselijk oog, de refreshrate van DMX is goed genoeg voor mensen om geen last van flikkeringen te hebben.
Voor armaturen in de mechanica, waardoor spotjes tegenwoordig best snel zijn, maar nog lang niet snel genoeg dat ze DMX eruit lopen.

[laserguy]

Mooie aanvulling van Kokkie.

Als DMX een refresh rate heeft van 44 Hz, dan betekent dit dat er 44 volledige DMX-pakketten verzonden worden. Ledjes aansturen over VGA gebeurt (ok, dvi dan) o.a. in video walls. Daar is DVI dan ook voor ontworpen, DMX niet. Zoals ik al zeg: gebruik de dingen waar ze voor dienen en dan kom je geen problemen tegen.

[Paul10]

Dat snap ik allemaal, en zo te merken zijn jullie heel blij met de huidige manier zoals DMX gebruikt word, maar als we nou eens denken in hoe het beter zou kunnen. (dat is toch leuk!)

in principe gebruik je de Macro's in de armaturen (bijvoorbeeld voor een strobe functie) omdat DMX dit niet (makkelijk)aan kan sturen, dit geld dus (bijna) ook voor het aansturen van een led sreen. DVI/vga whatever, word omgezet naar meerdere seriele "lijnen" waar leddriver naar luisteren die vervolgens 1 RGB led aanstuurt.

Als we nou eens een DMX??? ontwikkelen die bijvoorbeeld, 10x zo snel is, kan je de 512 strobe's exact synchroon ,om en om, of 1 voor 1 laten knipperen, door ze via een chase aan te sturen. of direct de leddrivers in een Ledscreen aansturen, zonder tussenkomst van media servers, DVI en weet ik veel wat voor video standards er nog meer zijn.


@kokkie mijn ervaringen omtrent leds met bitmappen aansturen op een VOL gepachte lijn is toch echt anders, maar misschien ligt het aan de GRANDMA(langzame refresh?). Niet elke Ficture heeft macro's voor een stobe functie en daarbij vind ik prettiger als ik het zelf kan programmeren zoals ik het wil , over wat snel genoeg is voor het menselijk oog zijn heel wat onderzoeken geweest google maar eens, laat maar eens een ledje strobe op 20Hz en beweeg het, of beweeg zelf.


@laserguy, noem je dat pakketten, wij hebben er een andere benaming voor. thanks.