END CUE Fail

[Vishal Sammy]

Hello, I have an NEC NC2000C with a GDC SX3000 IMB, at the end of every show the END CUE fails and the cool down counter starts.
Can anyone assist with this issue?

Thanks.

[Frank Cox]

I always put the ten seconds of black (Black MOS) clip at the end of every show and put the "end show" cue at the start of that clip.

I figure that gives the server a chance to send the entire signal. If you just send the "power off" signal, it might switch itself off before sending the signal to the rest of the equipment.

Or not.

I've always done it this way and it works, though I don't know if it's actually necessary or not. Doesn't hurt anything anyway.

[Vishal Sammy]

Hi, thanks I am doing this but still having the issue.

[Darryl Spicer]

With cue failures I try and reboot the automation. In my cases we use the Jnior automation. When they get finicky and a cue stops working I reboot them and after about 5 minutes things are back to normal.

[Mark Gulbrandsen]

It takes 30 seconds to light the lamp in that projector before the dowser opens, but it should go off immediately at the end. Projection wise, my first cue was light lamp, then 30 seconds of black and then everything else happened. Also, if the NC-2000 is busy moving the lens or doing other stuff then you have to wait for that to finish before extinguishing the lamp at the end. It can only process one command at a time.

[Marcel Birgelen]

There seems to be a difference between projectors in how commands are being handled while handling a previous command. Both Barco and Christie seem to queue commands to some extend, while NEC simply ignores them. Maybe there's also a difference between models?

In any way, it's always safe to be sure that a command has sufficient time to execute before firing another, in order to avoid unforeseen consequences.

[Mark Gulbrandsen]

There seems to be a difference between projectors in how commands are being handled while handling a previous command. Both Barco and Christie seem to queue commands to some extend, while NEC simply ignores them. Maybe there's also a difference between models?

In any way, it's always safe to be sure that a command has sufficient time to execute before firing another, in order to avoid unforeseen consequences.

If you read my post above yours, then you'll know that NEC can only safely process one cue at a time and that it takes almost 30 seconds to light the lamp before the douser can be opened. So don't tell one top do anything else while the lamp is lighting or while the lens is changing or it will be ignored....

[Marcel Birgelen]

Yeah, that was clear, but not really my point.

My point is that there seems to be a discrepancy between projector brands regarding how they handle commands. I was asking if there might also be some difference between individual models or series.

[Bruce Cloutier]

With cue failures I try and reboot the automation. In my cases we use the Jnior automation. When they get finicky and a cue stops working I reboot them and after about 5 minutes things are back to normal.

Darryl... Series 3 I would bet. If the problem were the automation (and it is not always the case) a reboot may resolve the current situation but it is simply just a form of procrastination.

[Dave Macaulay]

Different models handle automation differently but to a limited extent. Series 1 projectors and series 2 have very different electronics and software, so they handle automation and internal processes differently. For example, a Barco S1 projector does lens setting changes one motor at a time so they can take a long time to complete, S2 does them concurrently and the time taken is much shorter.
Series 1 in general, for all makes, is more finicky on automation commands and they should be spaced a few seconds apart and tested to see if there are any race conditions causing lost commands. Series 2 Barco and Christie systems are more forgiving and apparently do queue commands or obey them concurrently. NEC is different, so more care is needed with consecutive commands as Mark has described.
The brand specific (not the TI subsystem) processor boards and software for S2 projectors (with exceptions - for example on laser models and those with the Barco ICMP) are the same and should all work the same regarding automation responses.
The "series 3" systems should also work consistently across a brand's various models but I haven't experimented much with them.

[Mark Gulbrandsen]

Yeah, that was clear, but not really my point.

My point is that there seems to be a discrepancy between projector brands regarding how they handle commands. I was asking if there might also be some difference between individual models or series.

Oh, of course. Just like some brands change the lens faster than others do. IDK why NEC did that because certainly processors are available that can perform multiple tasks. It is what it is though, but at least it's an amazingly reliable projector.

[Marcel Birgelen]

I think it's more a design philosophy and a software thing than a real CPU thing. Almost any micro-controller nowadays is able to do some kind of multi-tasking. It's still handling basic IP traffic while performing other tasks, for example. Compare this to e.g. a Dolby CP650, who can even just handle one TCP session at a time.

AFAIK, no Barco projector performs the automation cues really in parallel, but they seem to have a message queue for incoming commands. So, instead of discarding the command, it will be executed once the previous command has finished.

[Mark Gulbrandsen]

I think it's more a design philosophy and a software thing than a real CPU thing. Almost any micro-controller nowadays is able to do some kind of multi-tasking. It's still handling basic IP traffic while performing other tasks, for example. Compare this to e.g. a Dolby CP650, who can even just handle one TCP session at a time.

AFAIK, no Barco projector performs the automation cues really in parallel, but they seem to have a message queue for incoming commands. So, instead of discarding the command, it will be executed once the previous command has finished.

You hit the nail on the head! The message queue is actually whats missing on NEC. If you send another queue after it starts one it gets ignored rather than stored.

[Darryl Spicer]

Darryl... Series 3 I would bet. If the problem were the automation (and it is not always the case) a reboot may resolve the current situation but it is simply just a form of procrastination.

Series 2, it is actually not a very common thing anymore.