Robe LED 300 Wash Issues

[weazel91]

We have a couple of issues with out Robe Robin 300 LED Washes at present. We are hoping someone has an idea or has had similar experiences and could shed some light on a solution.

 

Issue 1 is happening with 2 out of 4 units. These units are displaying what appears to be a DMX fault by twitching, randomly moving and with the occasional flash. This only occurs when their DMX comes from a DMX splitter. When these are taken directly from the ETC Net 2 node (same node as DMX splitter is taken from) there are no issues what-so-ever. We have also controlled the units via ethernet (Art-Net) this also is fine. We have tried all outputs on the splitter with other units and cannot replicate the issue. We have fed a brand new piece of DMX from said splitter to one of these units (with a terminator plug) and the issue still arrises until once again the unit is plugged into the node or the Thru output of the splitter.

 

Issue 2 is with a different unit that when powered doesn't do anything (Motors don't engage). If this unit is un-plugged and powered up again the fault seems to resolve. When in the fault state the unit stops DMX backward and forwards throughout the whole DMX line. All other outputs from the splitter are unaffected.

 

Thanks,

Chris

[niclights]

Re. issue 1 I have seen similar issues with other fixtures and was solved by enabling an extra stop bit in the console DMX settings. Not sure if it's exactly the same issue or if you have such an option but might help.

[philis]

Re. issue 1 I have seen similar issues with other fixtures and was solved by enabling an extra stop bit in the console DMX settings. Not sure if it's exactly the same issue or if you have such an option but might help.

 

Sorry I don't really understand what "an extra stop bit" is can somebody explain?

 

(just for Clarity I work with Chris)

[niclights]

It's to do with the data sent as part of the DMX protocol. If your console has options to adjust DMX timing settings it might have this too.

[DrV]

Re. issue 1 I have seen similar issues with other fixtures and was solved by enabling an extra stop bit in the console DMX settings. Not sure if it's exactly the same issue or if you have such an option but might help.

 

Sorry I don't really understand what "an extra stop bit" is can somebody explain?

 

(just for Clarity I work with Chris)

After each byte of DMX data the line returns to its idle state (which is a "one" state) for one bit time (4uSec). This is referred to as a stop bit. An extra stop bit simply means a slightly longer gap between bytes. In a DMX receiver which is somewhat intellectually challenged it would allow a little extra processing time between the arrival of consecutive bytes. Having said all that I've never heard of a desk which had such a setting but there's nothing in the DMX protocol to prohibit it.

 

Dave

[niclights]

The Avolites Titan consoles have this setting.

[philis]

Thanks for the replies

 

I'l look at this

 

would seem odd, that they are fine with the DMX from the desk though as the fault only appears when it is through the DMX spliter

Clearly the inner workings of DMX is something I'm not realy up on, how does a splitter change the DMX signal?

 

Phil

[Don Allen]

My brief description is that most DMX splitters have an optocoupler on the input to isolate the signal lines, then the signal is fed to one or two DMX driver ic's, depending on whether the splitter has 3 and 5 pin outlets. The optocoupler is not usually set up as a linear coupler, so the output is not a direct copy of the input signal due to the transfer curve of the output transistor. This is not usually a problem with digital signals, but in some cases the output digital signal does not have the same timing as the input signal. You would need an oscilloscope to confirm this.

 

Hopefully timsabre will have a more accurate explanation.

[Jivemaster]

Seems that some splitters replicate the input exactly some rebuild it with differences.

[timsabre]

Yes, it could be that the splitter is regenerating the signal rather than just buffering it. More sophisticated RDM enabled splitters do this. In this case it may be affecting the timing. What model is the splitter?

DrV is partly correct about timing above, the gap between data bytes can be much larger than one bit time (4usec) and some older fixtures rely on this gap to do internal processing, it's normally called "interbyte idle time". The extra stop bit gives you more idle time.

 

If the splitter is regenerating the DMX then changing settings on the console won't make any difference.

[philis]

It is an old splitter it is badged Stage Electrics (I'm guessing that it is rebadged)

It has been in the venue at least 10 years to my knowledge

So not likely to be RDM I would think

[niclights]

FWIW the rig where I have this issue is not using a fancy splitter either. I'm not sure if we ever tried bypassing so I don't know if it's related or not in my case.

 

When the problem originally presented it was when changing to a new console. At the time the console was a new design and this was the first unit out in the wild so the hardware designer investigated on site but we could not find any evidence of the glitches originating from the console. It was at this point he suggested trying the extra stop bit option and it worked, so problem solved and we left it at that.

 

The affected fixtures in this case are both old - Clay Paky MiniScan HPE and a Celco Demux unit (groups of conventionals would flash). I can only assume they are particularly sensitive to something in the timing. I have seen the issue with Jands Vista consoles on the same rig.

 

Of course the OP's issue may be completely different, albeit with some similar symptoms. Is there an option to test with a different console?

[timsabre]

The affected fixtures in this case are both old - Clay Paky MiniScan HPE and a Celco Demux unit (groups of conventionals would flash). I can only assume they are particularly sensitive to something in the timing. I have seen the issue with Jands Vista consoles on the same rig.

 

Older fixtures really struggled to receive DMX due to the limited processing power of the microcontrollers then available. They relied on the DMX having some interbyte idle time in which they could run the fixture, if the DMX came too fast then they would occasionally miss bytes causing the whole data stream to move on by one channel and giving the characteristic flick or twitch effect. Fortunately older lighting consoles had the same problem so tended to send the data with gaps. DMX dongles were the first things I saw causing this trouble as they had nothing much to do except bang out the DMX as fast as possible.

 

However the Robe fixtures in question are fairly new and I would not expect to see this problem with them. I wonder if it is some sort of weird earthing or voltage issue.

[philis]

I wonder if it is some sort of weird earthing or voltage issue.

I have to say that this is my instinct

I have tried them in several different power supplies but on the same IWB

This show finishes tonight so I am going to have another look on Monday,I might try the DMX splitter from a different supply I'll also check the earth continuity on it

[Tomo]

As an aside - "extra stop bit" is a rather strange thing to say. Not quite understanding where it could come from given that DMX specifies two stop bits and commercial UARTs only offer 1, 1.5 and 2 stop bits.

A source only sending one stop bit would be (technically) noncompliant, though I suspect most modern receivers would probably handle it just fine.

 

As DrV said, many DMX sources have adjustable DMX byte timing, usually called "DMX Speed". It means adding additional 'idle time', both between bytes and in the MAB and MBB.

When using any form of Ethernet - DMX converter this setting needs to be made in the Ethernet>DMX box.

 

As far as I know, current Robe kit is absolutely fine on the very fastest compliant "speed", and of course they're working fine out of the node so this is not the issue.

 

My first guess would be termination - make sure the line has one terminator at each end (source terminator is normally fixed) and no other terminators!

 

I've seen this kind of thing with self-terminating fixtures where the self-terminator is failing - can't recall if these Robes have that or not.

 

Second guess is bad cabling or inappropriate earthing of the cable shield - the shield should be grounded at one place maximum, usually the source. Might be that the splitter has a bad/intermittent grounding of the shield.

(Or the entire unit, though PAT ought to detect that.)