Nec Np2000
setholle
Posts: 66
I have just finished a job working with the NEC NP2000 projector. I had a huge amount of problems with control. I tried the duet module provided, it caused all sorts of reference error problems and it was huge.
So I used the standard hex code. However the feedback from this projector is highly unreliable, it also goes into these silence modes.
I eventually managed to make it work, through a huge amount of code to figure it when it is talking, when it is warming, cooling etc.
Has anyone one else had similar problems with NEC. Their technical support was useless.
Or maybe I just missed something using the module. Let me know.
So I used the standard hex code. However the feedback from this projector is highly unreliable, it also goes into these silence modes.
I eventually managed to make it work, through a huge amount of code to figure it when it is talking, when it is warming, cooling etc.
Has anyone one else had similar problems with NEC. Their technical support was useless.
Or maybe I just missed something using the module. Let me know.
0
Comments
I don't remember the projector model, but found some notes from the installation.
One thing that made the projector more responsive was setting a projector menu item to "Idle Mode". Also, the projector that we had wouldn't work properly with a three wire RS232 cable, but shorting 7 and 8 on the projector end fixed this.
After a number of bad experiences with projectors that act very oddly during their warming and cooling periods, I now use a standard module for all projectors which waits for the stipulated period and does not attempt to communicate with the projector until afterwards.
Also - and this is a biggie - set coms on both the control system & projector for 9600 baud - that will do WONDERS for reliability. Never had to use hardware handshaking on an NEC or fake it out, but have had problems at the default speed of 38400.
- Chip
I agree with the one post about a standard module, the problem with this nec, was that the warming and cooling times were completely unreliable. For instance the module provided by nec could never really figure it out.
If you turn the projector on and off quickly, it could take up to 4 minutes to warm up or cool down the second time.
I have never seen a projector do that, also oddly it would send a hex bit 22 ahead of all information, I could see it in my buffer off the projector, but not in the notications screen. Again something i have never seen.
Is this a pattern for nec?
Seth
I've recently worked with a Runco and a Panasonic that both seemed to have variable warming/cooling times. I worked around it by hard-coding what seemed to be the maximum delay possible. It would be nice if it was standard in the protocol for projectors with a delay to broadcast their ready state or lack thereof.
I poll for status every 30 seconds and after a user-initiated power command.
To the contrary, I was frustrated upon using Hitachi's for a job and finding out that there was no way to poll for warm-up/cool-down.
The extremely long warmup cycle is due to the temperature of the lamp at the time the power on command is called. You'll notice that the fan ramps up during these extended warmup periods without the lamp coming on. Once the fan dies down, you're in a normal warmup cycle and the projector comes right up.
Another thing I've noticed is that, indeed, the projector loses communication for a few seconds (up to 10) when it is powering down.
Through exhaustive polling using the "Control Device" dialog, I found out that the projector goes through 4 phases of cooldown.
1 - Actual cooldown - projector reports that it is cooling down, no problem
2 - Off - projector reports that it is off - this status only lasts 1-2 seconds, however
3 - Silent - projector loses communication for roughly 10 seconds after phase 2
4 - Off - finally, the projector has communication and reports that it is off
I've noticed that each batch of projectors NEC puts out has its own set of quirks. When you get a new model, it is almost mandatory that you set it up and bench test to make sure there's no craziness in the protocol.
As for the baud rate, just condition yourself to think that 9600 is the max for an NEC.
I dropped the same module into a job with an NP2000 in it and it is 'sort of half ok, sort of'!
:-)
Timing is critical, the blackout periods vary, and the status is often behind the times - for instance, the lamps strikes yet it can be up to 20 seconds before the WARMING response is rx'd. Similarly, the lamp can have been on for minutes before the RUNNING response is received.
I've now 'got it covered' and all is well again, but it did take some nutting out to get the exact behavioral pattern sorted out.
The base ASCII protocol for the unit is identical to the MT 10xx series, and NEC have suggested we try the HEX commands to see if the results are any different to what was found above (and by others).
I've seen no difference using the HEX over the ASCII.
Never had an issue with the lamp run time vals coming back..
Not only does it make the system incredibly slow whilst coding/downloading etc, there is still so much work to be done around it to make it do what I want that I have shelved it.
The response issue discussed here adds significant complication to the whole process!
....IMHO
:-)
I too have just finished (...no make that 'still trying to walk away from...' ) a job with three of the new NEC 4001 DLP projectors. What a nightmare!!.. These creatures have serious communication faults. From not switching/reporting to just plainly ignoring commands I have spent extraordinary hours getting these things somewhere near stable, and please don't ask about NEC tech support. It took months to get a intelligible response from them and came down to near begging to get a firmware upgrade. I nearly don't recognise the original RS232 control module i wrote that is rat-salad strong in the old 1075's and 770's and even when I converted it for IP the older models had no problems.... but these NP 4001 and 2150 models are nothing but a pain in the....
That sounds suspiciously as though the virtual device being passed to the module had a device number that was not in the Duet range (ie 41000:1:0 - 42000:1:0).
I haven't had too many hassles controlling NP1000's and NP2000's. Interestingly they have an undocumented ASCII protocol in addition to the more usual NEC protocol. From memory, if you open up a terminal and type "Help" or "?" or something along those lines it'll give you details of the commands that can be used.
At least NP2000's have decent status feedback ("running sense" as NEC seems to call it). Many of the smaller NEC's with serial control have little or no feedback available. Add to this variable warm up and cool down times and you've got a truly uncontrollable pig of a thing.
NEC control can be a pain. Every batch seems to have its own Quirks. I have found recently that the NP series is a bit more consistent when a delay is used.
Send_Command NEC_NP,"'CHARDM-20'".
- Chip