Home AMX User Forum AMX Technical Discussion

Nec Np2000

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.

Comments

  • HedbergHedberg Posts: 671
    We had one of the NEC projectors a couple years ago and had problems with it.

    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.
  • Unreliability during cooling and warming

    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.
  • Likewise experiences with NEC projector feedback on warming & cooling. Even though NEC's protocol says they all work the same, they don't - the firmware in some is just plain different.

    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
  • NEC warming and cooling

    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
  • DHawthorneDHawthorne Posts: 4,584
    setholle wrote:
    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.
  • Thomas HayesThomas Hayes Posts: 1,164
    I had 40 of the first NP2000's in North America. Like you I had several odd issues from these units, so much that I had to re-write most of my code which has worked for years with no problems. Feedback is an issue, lamp run time is all over the place. The lack of communication well after the warm-up/shut-down time is also poses some headaches and that 30 sec ultra cooldown. Some of these problems I don't understand because these units now have a buffer for the commands. Maybe dropping the baud rate like Chip said might help out.
  • gregrgregr Posts: 54
    Don't know if this applies, but all of the Sanyo projectors I have worked with have discrete status responses for off, warm-up, on, and cool-down. This makes it very convenient to display status to the user, and to know when to issue commands, although most of our jobs do nothing more than that because they incorporate switcher/scalers to eliminate the need of projector switching.

    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.
  • JMeeksJMeeks Posts: 8
    I've worked extensively with the NP line and here's what I've figured out:

    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.
  • DarksideDarkside Posts: 345
    I wrote a module around the MT 10xx series VPs some time ago and the reporting was excellent.

    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..
  • DarksideDarkside Posts: 345
    ...oh, and have not bothered pursuing the duet module.

    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

    :-)
  • Thomas HayesThomas Hayes Posts: 1,164
    I've had a few of these projectors give bad 'lamp runtimes' same program as I use everywhere else. I just mark it up to being fickle or border line cable distance for the RS-232.
  • Rod NRod N Posts: 28
    NEC NP proj headaches

    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....
  • AuserAuser Posts: 506
    setholle wrote: »
    I tried the duet module provided, it caused all sorts of reference error problems and it was huge.

    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 Quirky RS232 characteristics

    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'".
  • We just had an issue with the RMS and the NEC NP-2150's series where the sample rate was too fast and the response time from when you pushed a button to the projector executed the command was near 6 sec's.
  • Is that at 9600, or are you leaving the default? (38400, I believe)

    - Chip

    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'".
Sign In or Register to comment.