Sida 1 av 1

Knepigt DMX-problem

Postat: mån 07 jan 2013, 14:22
av Mattias Hartelius
Jag har ett (för mig) märkligt fenomen när jag ska köra en viss scannermodell från vissa ljusbord.
Scannern är en chinamodell (försök till robekopia)
Kör jag dessa med billigare typ av ljusbord, har kört div Elation, Stairville etc är det inga problem och scannern fungerar som den ska.
Men så fort jag ansluter den till ett "bättre" fabrikat av bord så ställer den sig i ett läge där alla 6 dmx-kanaler parkerar på ca 60 någonstans (0-255). Även om jag på bordet satt alla reglar till 0.
Har provat både att skapa en fixture och att köra den i "dimmerläge" för att testa.
Oavsett hur jag gör verkar 0-läget på regeln motsvara ca 60 och 255-läget ca 126.
Kan mao inte få ut hela 0-255 på respektive kanal...

Någon annan som varit med om liknande?

Får problemet på bl.a SGM & Zero88 bord.

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 17:16
av Nicke Löfgren
Kanske det beror på DMX signalens överförings hastighet?

Jag kan inte exakt men det finns två olika "protokoll"
Dom "bättre" borden går snabbare så får scannern spunk!!
Kanske :)

Kablar? Rätt vänt?
Har du ett slutmotstånd?

Funkar borden ok till en annan armatur?

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 17:46
av Mattias Hartelius
Ja jag är oxå inne på att DMX signalen ser annorlunda ut på något sätt som du säger Nicke.

Kablarna är bra, rätt polaritet är det på signalvägen & slutmotstånd finns i änden :)
Bordet funkar klockrent med andra armaturer - och scannern klockrent med "billigare" bord...

Ska egentligen inte lägga så mkt kraft på detta då jag normalt använder andra armaturer.
Men jag har 8 scanners av denna modellen, och dom är rätt trevliga, så det hade vart smutt att kunna använda dom nån gång ibland vid behov.

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 18:59
av Niklas Elste
http://www.totalljud.se/dms26-merger-p-1898-c-206.aspx

Som jag förstår det så är det start biten som kan vara olika lång

DMX ger en stat pulls för att synka tx med rx
när rx känner pullsen ställer dn sig och väntar på adress
och sen heller den koll på hur långt i från rätt byte den är och räknar tills rett byte dyker upp

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 21:33
av Anton Gildebrand
Niklas, det kan också vara olika hastighet på DMX-signalen. Man brukar kunna ställa in på en del bord vilken hastighet som man ska köra.

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 22:13
av Niklas Elste
Protocol



DMX-512 signal on an oscilloscope, annotated to show measured timing
At the datalink layer, a DMX512 controller transmits asynchronous serial data at 250 kbaud. The data format is fixed at one start bit, eight data bits, two stop bits and no parity.
Break condition
Mark-After-Break
Slot 0, containing the one-byte Start Code
Up to 512 slots channel data, each containing one byte
The start of a packet is signified by a break followed by a "mark" (a logical one), known as the "Mark After Break" (MAB). The break, which signals the end of one packet and the start of another, causes receivers to start reception and also serves as a frame (position reference) for data bytes within the packet. Framed data bytes are known as slots. Following the break, up to 513 slots are sent.
The first slot is reserved for a "Start Code" that specifies the type of data in the packet. A start code of 0x00 (hexadecimal zero) is the standard value used for all DMX512 compatible devices, which includes most lighting fixtures and dimmers. Other start codes are used for Text packets (0x17), System Information Packets (0xCF), for the RDM extension to DMX (0xCC), and various proprietary systems. ESTA maintains a database of alternate start codes.[7]
All slots following the start code contain control settings for slave devices. A slot's position within the packet determines the device and function to be controlled, while its data value specifies the control set point.
[edit]Timing
DMX512 timing parameters may vary over a wide range. The original authors specified the standard this way to provide the greatest design flexibility. Because of this, however, it was difficult to design receivers that operated over the entire timing range. As a result of this difficulty,[citation needed] the timing specification of the original 1986 standard was changed in 1990. Specifically, the MAB, which was originally fixed at 4 μs, was changed to 8 μs, minimum. The E1.11 (2004) standard relaxed the transmitter and receiver timing specifications. This relaxed the timing requirements for systems using controllers built to DMX512-A (E1.11); however, a significant number of legacy devices still employ transmit timing near the minimum end of the range.
-- Min Break (μs) Min MAB (μs)
Transmitted 92 12
Receiver recognize 88 8
Maximum times are not specified because as long as a packet is sent at least once per second, the BREAK, MAB, inter-slot time, and the mark between the last slot of the packet and the break (MBB) can be as long as desired.
A maximum-sized packet, which has 512 channels (slots following the start code), takes approximately 23 ms to send, corresponding to a maximum refresh rate of about 44 Hz. For higher refresh rates, packets having fewer than 512 channels can be sent.
The standard does not specify the minimum number of slots that can be sent in a packet. However, it does require that packets be transmitted so that the leading edges of any two sequential BREAKs must be separated by at least 1204 μs, and receivers must be able to handle packets with break-to-break times a short as 1196 μs.[8] The minimum break-to-break transmit time can be achieved by sending packets that contain at least 24 slots (by adding extra padding bytes, if necessary) or by stretching parameters such as the BREAK, MAB, Interslot, or Interpacket times.[9]

Re: Knepigt DMX-problem

Postat: mån 07 jan 2013, 23:20
av Nicke Löfgren
Va händer?? En massa urklipp *batman*

Re: Knepigt DMX-problem

Postat: tis 08 jan 2013, 10:25
av Mattias Hartelius
Jag tackar för tipsen tills vidare.
Är på resande fot men ska testa lite mer i slutet på veckan med timing etc.

Re: Knepigt DMX-problem

Postat: tis 08 jan 2013, 22:07
av Niklas Elste
Nicke Löfgren skrev:Va händer?? En massa urklipp *batman*
jag ville bara poentera min ståndpungt i form av lite källhänvisning

och där står det en spesad hatighet men varierande puls tider

Re: Knepigt DMX-problem

Postat: ons 09 jan 2013, 19:44
av Mattias Hartelius
Problemet är löst!
Testade dmx-mergern som Niklas länkade till och den löste mitt problem.
Ändrade time-out tiden på utsignalen i denna till 45ms och då funkade allt klockrent.

Så jag tackar o bockar för tipsen :D

Re: Knepigt DMX-problem

Postat: tor 10 jan 2013, 00:13
av Niklas Elste
varsågod jag hjälper gärna till i mån av tid och kunnskap