Home AMX User Forum AMX General Discussion
Options

Sharp Projector RS-232

We have recently come across an issue with the Sharp XG-MB70X DLP projectors. It appears that these projectors have a wait period for some commands before another command will be recognized by the projector. Most notable are the commands to change sources. These have an 8 second wait period. I have run into many instances where our instructors desire to bounce back and forth between sources and are unable to because of this issue. Sharp technical support has been anything but steller in their response and the only reason I found out about this was by contacting a regional rep.

I was wondering if anyone else has had this issue with a projector and what thoughts you might have on working around it.

I have attached the supplement if anyone is interested.

Comments

  • Options
    Gee, Sharp is winning fans left and right it seems... :)

    Honestly, I thought MOST projectors these days had several seconds on latency between input switching. 8 seconds seems pretty extreme, but it honestly doesn't suprise me.

    For what it sounds like your customer wants, get an Extron scaler (even better, seamless switcher) with the inputs you need and leave the projector running in RGB.

    - Chip
  • Options
    This is a known issue with the MB60/70 series, only workaround is to program some sort of wait between input switching commands. Sharp leaves the issue as is.
  • Options
    wgreenwgreen Posts: 15
    The customer is actually me. We have been dealing mostly with Panasonic LCD projectors for many years. We have been having lots of discoloring on the panels and decided to try another manufacturer. The panasonics do not have any of delay in switching from one source to another. Guess it is back to Panasonic
  • Options
    Thomas HayesThomas Hayes Posts: 1,164
    Is it a real delay in switching or is the projector 'auto-adjusting' the image before it displays it? We use NEC projectors and I routinely see a delay of 5-8 sec's between switch command and the image displayed.
  • Options
    wgreenwgreen Posts: 15
    It isn't really a delay in the switching. The switch just never happens. If you try to send another command to the projector within this wait period the projector sends an error response to the command and nothing happens.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    I've seen this same behavior on Runco projectors. In their protocol documents, they actually specify a delay of 15 seconds between commands. WHat is happening is that the projector is detecting the input signal, making internal adjustments, and writing it to memory. While the process is going on, it cannot accept new commands. It wouldn't make sense to queue them, because an impatient operator might be mashing buttons and stacking up an endless stream of commands, so it tosses them instead.

    This falls firmly and squarely in the area of trying to make a product too "smart" to make it more accessible (and thereby more sellable). I wish some of these engineers would stick their noses in the real world long enough to recognize that they really need to make some of these types of settings permanently set by an expert to override the automatic behavior, and leave the automatic stuff as an alternative option for the times when it is of benefit.
  • Options
    Thomas HayesThomas Hayes Posts: 1,164
    DHawthorne wrote:
    It wouldn't make sense to queue them, because an impatient operator might be mashing buttons and stacking up an endless stream of commands, so it tosses them instead.

    I was pondering about making it so during this switching time any key pushes
    would be ignored until the projector is ready, a simple wait with a flag to re-activate the command flow should work. I had a client who kept on pushing the source button which kept the projector blanked while it tried to auto-adjust the image 4 million times.
  • Options
    wgreenwgreen Posts: 15
    I received a call from Sharp support asking me what I wanted from the projector, so they got an ear full. Mostly that I wanted no delay in the switching of video sources. She stated she would look into it. we'll see.

    My one thought as a work around was to set up a wait within the program and based on my variable as to which video source was active, delay the command up to a maximum of eight seconds and make a pop up window appear letting the instructor know that the input had been accepted but could not yet be executed. I would use simpler language though.

    My biggest concern with this whole thing is that our some of our instructors already refuse to use "technology". This delay can and will disrupt the "flow" of their teaching and may cause me even more issues in terms of customer support.
  • Options
    Thomas HayesThomas Hayes Posts: 1,164
    I wouldn't hold my breath waiting. In 20 yrs I have rarely seen a change to a product without a few billion complaints before hand. Part of the problem is that the end user expects that the equipment operates at twice the speed of light and it should be instant when they push that button. I have the same issue here on campus with end users.
  • Options
    a video switcher is your only bet, or wear the discolouring. Sharp wont do anything, till maybe the next model and firmware. even then, delays must be expected for any video display.

    and yes, a pop-up (opaque for greyed-out effect of lower page) to tell people to wait works well. i cover the entire panel so buttons can not be pressed until the controller is ready (ensure your main program turns off all popups on boot, else a panel could get locked out if there was a system failure while the popup was on)
  • Options
    DHawthorne wrote:
    I've seen this same behavior on Runco projectors. In their protocol documents, they actually specify a delay of 15 seconds between commands.QUOTE]

    Which models do you know do this?

    Personally, i'm searching the forum again today because it seems like 2 Runco-CL-710's in our field seem to lock up intermittently. It strange, it just seems like they don't respond to Off commands every blue moon. The 232 we had attached to them didn't always seem stable (like it ignored commands) so we moved to using IR, but we have this "Not turning off" issue every now and then with IR control and Runco tech support says there is no known issue with the CL-710

    Anyway, i'm just wondering if i'm missing something. And your comment above makes me wonder if maybe i'm not waiting long enough before sending an off command. (Currently i have 3 off commands being sent, one at 1 tenth sec one at 5 tenth sec and one at 2 seconds.)
  • Options
    DHawthorneDHawthorne Posts: 4,584
    AlexArtist wrote:
    DHawthorne wrote:
    I've seen this same behavior on Runco projectors. In their protocol documents, they actually specify a delay of 15 seconds between commands.QUOTE]

    Which models do you know do this?

    Personally, i'm searching the forum again today because it seems like 2 Runco-CL-710's in our field seem to lock up intermittently. It strange, it just seems like they don't respond to Off commands every blue moon. The 232 we had attached to them didn't always seem stable (like it ignored commands) so we moved to using IR, but we have this "Not turning off" issue every now and then with IR control and Runco tech support says there is no known issue with the CL-710

    Anyway, i'm just wondering if i'm missing something. And your comment above makes me wonder if maybe i'm not waiting long enough before sending an off command. (Currently i have 3 off commands being sent, one at 1 tenth sec one at 5 tenth sec and one at 2 seconds.)
    The VX-5000, for certain; the old Transvision controller is variable - 1 second between input commands and 10 seconds after a power command; those are the ones I can lay my hands on the protocol manuals and confirm quickly, but I'm certain I've seen it on others. My guess is any that are paired with a controller, and especially DLP's. I know I saw this first several years ago, long before the VX-5000 came out, and since then I have basically experimented with each one. You can easily fire off commands from a Telnet session in NetLinx, or from Open Axcess for an Axcent system, and get a rough idea of how much spacing you need to delay them with if it isn't explicitly documented.
  • Options
    i am dealing with a very similar problem right now.

    the runco will not respond to commands.

    i've been given a new firmware file for it, but the uploading program is hard coded to comm1 i believe, which my notebook doesn't have, so i haven't been able to do the patch to the projector yet.

    and, it's not that the runco wont turn off. for us it's that it's own processor is stopping. even trying to use the remote supplied with it will not control it.

    basically, the projector can hang at any stage, from initial boot (low glow from globe but no image or control) till later when you try to shut it down.

    the firmware i am trying to get installed is Runco_CL710_RM1A_Ver204_20031231.hex


    the runco tech support, like all hardware suppliers, must be taken with a grain of salt. everyone continues to deny problems with their systems, prefering to push the blame to others (ie, programmers). but 99% of the time, the hardware is at fault. i no longer accept hardware makers saying they don't know of a problem. it's just denial or laziness.
  • Options
    Runco's techsupport seemed pretty open about telling me about a controller we dealt with that needs a firmware update to prevent lockups. I think it was a Vivix-II we had connected to a VX-1000d, and i usually find their support helpfull. Anyway, the CL-710 i'm having issues with has a really long IR and RS232 run, so i'm thinking something just might be wrong with the install of that job. But despite that, i found out today, if i spam the OFF pulse every seconds for about 40 seconds, the CL-710 will evetually catch the signal. (Kinda ghetto i know, but it works! and the pulses gets canceled if the client tries to power on or change sources, so it's pretty full proof.) So! all is well for now.
Sign In or Register to comment.