16 bit pan/tilt fade op lichttafel

**axs** · 04-03-05, 20:05

Ff ter verduidelijking:

Pan fine wordt gebruikt voor het exact positioneren van een fixture.
Hiermee kan je dus NIET een volledige beweging uitvoeren maar enkel 'fine-tunen'
Wat je tafel dus doet, klopt perfect.
Hij gaat in 10sec van pan1 naar pan2 en dan 'finetunen' van je pan2.

citaat:
Is het niet zo dat de pan fine alle 256 waarden (van 255 naar 0 of omgekeerd) moet doorlopen voor elk stapje van de pan?

Dit werkt dus idd niet zo... uitleg zie boven

**Jasper-Lichtbron** · 05-03-05, 13:48

Dat is niet waar... als je het netjes wilt doen behoort de fine-waarde ook mee te lopen in je fade!

Het zit zo:
8 bits aansturing betekend 1 DMX kanaal omdat DMX nu eenmaal 8 bits (1 byte) op een kanaal kan plaatsen. Je stuurt dus 1 parameter (zeg PAN) aan met 1 kanaal -> 8 bits -> 2^8 = 256 stappen.
Omdat movingheads meestal aardig wat graden kunnen draaien, en redelijk gevoelig zijn is 256 stappen te weinig om een mooie, langzame soepele beweging te krijgen. Dit kun je oplossen met algoritmen, maar makkelijker is een oplossing die gebruik maakt van 2 kanalen; Coarse & Fine. Je hebt dan 2 kanalen waarmee je 2^16 = 65536 stappen kunt bepalen.

Voorbeeldje: je stelt je PAN in op 0-0 en gaat deze vervolgens ophogen. Dit gebeurd in het fine-kanaal; dit wordt 256 stappen opgehoogd; dan zit ie vol. Vervolgens gaat je coarse kanaal 1 omhoog en begint fine weer bij 0. Zie het alsof je 1.0 begint op te hogen met stappen van 0.1:
1.1 - 1.2 - 1.3 - 1.4 - 1.5 - 1.6 - 1.7 - 1.8 - 1.9 - 2.0

Als het zou zijn zoals jij zegt AXS, dan heb je dus nog steeds maar 256 stappen in je bewegingen, en bevat het fine-kanaal alleen fine-tuning achteraf, een verschil van (256/65536)*100 = 0,39% wat je echt niet zult zien in je positie.

Heb het nog even gechecked maar onze tafel werkt echt op bovenstaande manier!

**Pieter Huijgen** · 05-03-05, 14:04

Vergeet niet dan de 8 bit waarde MSB is en de 16 bit waarde (het fine channel) LSB.
Ik weet niet of dat te definiëren valt met freestyler

**Jasper-Lichtbron** · 05-03-05, 14:10

Idd par-av.nl... als je software die mogelijkheden niet kent kun je het ook onmogelijk netjes programmeren. De software moet zo geschreven zijn dat je kanalen met elkaar kunt combineren, anders heeft het geen nut.
Zie ook: Most Significant Bit / Least Significant bit... www.google.com vind je daar zat over

**DeAl** · 06-03-05, 00:10

@iCe & par-av.nl,

Bedankt voor de bevestiging, ik had inderdaad verwacht dat pan fine en tilt fine als LSB moeten meelopen tijdens een pan/tilt fade. Het geheel wordt dan een 16-bits counter die op- of afloopt.

Of in de praktijk al die 16-bits DMX waarden effectief kunnen uitgestuurd worden, is nog maar de vraag. Stel dat alle 512 DMX kanalen moeten worden aangestuurd, dan heb je op de DMX-lijn een verversingsfrequentie van ongeveer 44 Hz per kanaal (250.000 baud/512/11 bit). En dan een full 16 bit pan uitvoeren van 0 naar 65535 in bvb. 3 sec... De pan DMX waarden hikken dan in stappen van 496 (!) naar omhoog.
Zelfs in een full 8 bit pan (in 3 sec.) kun je dan nog niet alle waarden doorsturen.
Dus zijn de vloeiende bewegingen toch uiteindelijk te danken aan intellegente programmering van de fixture firmware...

**Jasper-Lichtbron** · 06-03-05, 16:51

Tenzij je dus langzame bewegingen gebruikt die ook niet al te groot zijn; dan maakt het wel degelijk verschil. Die 44Hz is trouwens streefwaarde heb ik gemerkt, meestal geven onze macs een waarde van ongeveer 30/35 aan. Tja DMX is nu eenmaal een hopeloos verouderde toestand

**CoenCo** · 09-03-05, 20:00

citaat:Geplaatst door DeAl

@iCe & par-av.nl,

Bedankt voor de bevestiging, ik had inderdaad verwacht dat pan fine en tilt fine als LSB moeten meelopen tijdens een pan/tilt fade. Het geheel wordt dan een 16-bits counter die op- of afloopt.

Of in de praktijk al die 16-bits DMX waarden effectief kunnen uitgestuurd worden, is nog maar de vraag. Stel dat alle 512 DMX kanalen moeten worden aangestuurd, dan heb je op de DMX-lijn een verversingsfrequentie van ongeveer 44 Hz per kanaal (250.000 baud/512/11 bit). En dan een full 16 bit pan uitvoeren van 0 naar 65535 in bvb. 3 sec... De pan DMX waarden hikken dan in stappen van 496 (!) naar omhoog.
Zelfs in een full 8 bit pan (in 3 sec.) kun je dan nog niet alle waarden doorsturen.
Dus zijn de vloeiende bewegingen toch uiteindelijk te danken aan intellegente programmering van de fixture firmware...

De meeste lichttafels en MovingHeads gebruiken ook niet de volledige 16 bit, maar maar 12 ofzo. Een pearl2000 berekent geloof ik standaard 12of13 bit. Met de volledige 16 bit zou je (bij een mac250 / 500 ) met een totale pan van 540 graden tot op: 540 / 65000 == 0,008 graad nauwkeurig kun positioneren. En dat is wel een beetje overkill

Of beter gezegd, veel nauwkeuriger dan een stappenmotor kan positioneren.

**Pieter Huijgen** · 09-03-05, 20:59

Ieder kanaal op een lichttafel is te regelen in waarde van 0 - 255 (256 stappen, 2^8, 8 bit)
Als je dus in 16 bits modus werkt gebruik je 2 kanalen van 8 bit (voor iedere MSB stap op het eerste kanaal zijn 256 stappen beschikbaar op het tweede kanaal (LSB), 256 X 256, 2^16, 16 bit = 65536).

Een stappenmotor kan een een lagere resolutie hebben.
Overkill is het zeker niet, als je met geautomatiseerde profielschijnwerpers (VL1000, X-Spot, MAC2000, Warp, Revolution) werkt zul je het vaak nodig hebben....

**CoenCo** · 09-03-05, 22:38

citaat:Geplaatst door par-av.nl

Ieder kanaal op een lichttafel is te regelen in waarde van 0 - 255 (256 stappen, 2^8, 8 bit)
Als je dus in 16 bits modus werkt gebruik je 2 kanalen van 8 bit (voor iedere MSB stap op het eerste kanaal zijn 256 stappen beschikbaar op het tweede kanaal (LSB), 256 X 256, 2^16, 16 bit = 65536).

Een stappenmotor kan een een lagere resolutie hebben.
Overkill is het zeker niet, als je met geautomatiseerde profielschijnwerpers (VL1000, X-Spot, MAC2000, Warp, Revolution) werkt zul je het vaak nodig hebben....

klopt.. maar het verschil tussen 8 en bijv 12 bit is enorm nuttig en zichtbaar, terwijl het verschil tussen 12 en 16 bit technisch precies even groot is, maar veel minder zichtbaar. Het verschil tussen een hoeknauwkeurigheid van 540/255=ca 2 graden. t.o.v. van 540/8096(12bit)=0,13 graad is VEEL zichtbaarder dan het verschil tussen die 0,13 graad en 0,008graad (16bit). reken het verschil in positie maar eens uit op een een hoogte van 10 meter, rekening houdend met de hoek van inval.

Daarom worden in veel spots en lichttafels niet alle 16bit gebruikt, terwijl ze theorethisch wel beschikbaar zijn.
Van een 16bits waarde bijv. 01010101-01010101 worden dan alleen de eerste 12 bekeken/berekend ==> 01010101-0101xxxx

**Pieter Huijgen** · 10-03-05, 01:01

Coen,

Ik zie de 16 bit uitsturing in een tafel nog steeds als 2 aparte kanalen met ieder 8 bit. Berekening van de 16 bit waarde gebeurt pas in het dmx ontvangend apparaat, waar de 16 bit data wordt uitgelezen en vervolgens de (stappen)motoren (op hun max. resolutie) aanstuurt.

**Jasper-Lichtbron** · 10-03-05, 08:56

Coen heeft deels gelijk, want de meeste tafels berekenen niet alle 16 bits om processor kracht uit te sparen. Dit geld echter alleen voor de effect generator etc, de waarden kun je handmatig wel 16 bits aansturen. Hoe het precies werkt weet ik ook niet; maar het algoritme van de generator zal hier en daar wel wat op- en aftel werk doen zodat de berekeningen wat sneller uit te voeren zijn. Wanneer je een cirkeltje laat draaien zie je dat verschil inderdaad toch niet. Hoe die algoritmen hun werk precies doen is uiteraard afhankelijk van de console.

Overigens neem ik aan dat de huidige generatie tafels gewoon 16 bit rekent, omdat daar veelal 16/32 bits processoren inzitten. Dan hebben die algoritmen weinig zin meer. Ook dat computerprogramma waar het hier over gaat moet gewoon 16 bits rekenen, daar heeft een pc geen enkel probleem mee.

16 bit pan/tilt fade op lichttafel

16 bit pan/tilt fade op lichttafel

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment