I Plugged into a Avolites dimmer today using vvvv and an Enttec Pro which worked well outputting 24 channels of DMX to the 24 dimmer channels. The problem happened when i reduced my output to a spread of 6 using an IO box with 6 rows. Instead of spread 0 controlling the first channel of each dimmer rack, e.g 1,7,13,19. the last dimmer rack crashed and put all channels at full. I had to turn off the dimmer and turn it back on again to regain control.
Is there an easy way to fill up the rest of the unused slices with a value of 0 when outputting dmx. Say for example i had an io box with 6 rows representing a small 6 channel dimmer. How would i stop channel 1 repeating down the DMX spread.
Im sorry if this is a really stupid question but I couldnt find out through the vorum search.
i never heard of dimmers crashing when receiving invalid data. but perhaps they have some more hidden channels which do some things which one should understand before sending arbitrary data into them.
I think I should add a “fill all channels not used with 0” option to my driver patch. (a < and a select node would do)
I never heared either off any DMX device crashing when it recieves wrong data, the hidden channels thing could be it. I know a lot off semi-inteligent devices (moving heads, Scanners, Laser) have a hidden ‘reset’ value, mostly meaning you can’t use the device for a minut or so.
Or the dimmers have a setting that say: when we don’t recieve any DMX, we go full open (so you never sit in the dark when a lightdesk crashes). I prefer the “hold last DMX when DMX is gone” way.
Hi Guys, Yea the hidden channels theory sounds right. Any way the resample node looks like it will work a treat! I should have acces tot he same dimmer rack next week where ill have more time to “play” ;-).
Has anyone used vvvv to controll pixeline 1044, should have a few of them to play with next week too :-).
here and there i experienced that some equipment ignores DMXdata
if doesn’t contain “enough” channels.
Device “A”
with Startaddress “1”, which had 8 DMXchannels,
claimed to be the DMX not valid if you sent only 4 DMXchannels.
Device “B”
which was kind of dimmer with 9 DMXchannels,
didn’t allow Startaddress “505”.
the manufacturer of this device had to reprogram it for me (within one day with shipping…), because i definitely needed this startaddress… was used here.
here and there i experienced that some equipment ignores DMXdata
if doesn’t contain “enough” channels.
usually it happens on low cost dmx board, that have low cost chipset ( why sending 512 ch when this is a 12 channel board ?)…
i think this trouble is because the rs232 approach is not sending a buffer of 512 channels. to avoid this, better is to send a 512 spread, all the time, that is for the dimmers, not to crash. and use a customer spread ( 12 / 240 channels…) with setslices function for patching.
The remaining bytes make up the actual level data. Up to 512 bytes can be sent, and it is the job of the receiver to count the bytes to keep track of the channels. As there is no error detection or correction in DMX, it is vitally important for receivers not to miss bytes, and to discard packets if framing or buffer overflow errors are detected.
A full packet takes approximately 23 mS to send, corresponding to a refresh rate of about 44 Hz. For higher refresh rates, fewer channels can be sent. This is accomplished by simply starting a new packet before all 512 channels have been sent. The minimum packet length is equivalent to 24 channels. Most transmitters send all 512 channels though, as many receivers have trouble with shorter packets.
recently i did an installation using 192 channels, patch is running with around 80 FPS.
this makes the whole thing going really “fluid”. animations are that soft that it is not possible to capture this quality on video with 25-30 FPS.
cheaper interfaces aren’t capable to reach those refresh rates though.
@kalle: be assured that it looked incredibly smooth already on your video. i was thinking that you had some smoothness capacitors in there, but also the strobing effects looked incredibly precise and fast. is there a chance to see it?
ah thx,
with that 80fps i’m referring to an installation in hamburg.
interestingly @u7angel can see it from his bureau and asked me today if i did this…
will be documented soon.
this 78ccfl thingi from that video in fact runs only with around 25 fps because of an extensive GUI with 5 (!) Simulations (4 of them for previewing and morphing…).
indeed you can see it here in wiesbaden atm.
eventually it will be shipped overseas but thats not clear now.
are you visting 3deluxe soon?
in case of this call me.
smoothness/quickness: you refer to led or non-hallogen sources ?
it s not the first time i read things about quickness and dmx in the vvvvorum…
things i do not understand as dmx bufer should be sended minimum at 50fps refresment not to be seen …
it remembers me the old time i was using an lpt interface, sending channel after channel…
i will test (ah holyday !) tomorrow west patch with dimmers to understand…
DMX is a very basic and therefore reliable, stable, foolproof protocol which is designed to work also under bad circumstances.
therefore i like it very much…
i even had some running gear accidentally without pin2 connected (so-called “one-legged” signal…).
regarding RS232:
There is a module for cheap, lame Interface which uses RS232. but i cannot imagine that this helps you.
