Projector warm-up time?

fogled@mizzou

I'm trying to account for the warm-up and cool-down time for a projector, since that cycle has to complete before it will accept any other commands.

I can easily poll the projector and get the current lamp state. I just can't figure out how to keep polling the projector every so often (5-10 seconds or so). A simple WHILE loop will swamp the projector with queries and I never get a response back. How can I slow down the processes inside the WHILE loop to only happen every XX ticks? When I put a WAIT in there, the stuff inside the WAIT waits, but the WHILE loop itself doesn't.

Can someone offer some advice on this issue?

Thanks,

glr-fti

Try a timeline.

NMarkRoberts

A timeline is the "correct" way to do it but the "trad" way is as follows

define_program

wait 20 (* Two seconds *)
  {
  if (bProjectorWarmingCooling)
    {
    PollProjector()
    }
  }

Darkside

Some projectors are quite happy to be asked their status all the time, and will respond all the time in which case another option you have is to issue the poll command without logic in mainline like so...

define_program

wait 20 send_command vdvVproj,'current_status'

It may represent more traffic as we are talking to the dev all the time, however, it will allow the system to remain 'in sync' even if a user controls the vp by remote. Another reason we poll like this is that if the projector doesn't respond, it may well have died or been stolen!....either way security steps are taken in this instance.

:-)

Polling a device every 2 seconds is a lifetime for a serial port and shouldn't pose any problems for your dev or master on an average sized system.

Final thought, IMHO you should always use a code block to stack and handle all commands to the port and issue them at the 'correct' intervals for that dev no matter how simple you think the coms will be.

Using a code block like this will ensure the 'poll' does not bump into other commands you might be issuing somewhere else in your code, and vice versa.

vining

You could also try just counting seconds. It takes more code but is a little simpler than setting up a timeline and doesn't require using waits. I like Timelines and don't mind waits but often do something like this:

DEFINE_CONSTANT
PROJ_LAMP_DELAY  = 20 ;
PROJ_POLLING     = 7;

DEFINE_PROGRAM

     {
     LOCAL_VAR SINTEGER nTT_CurSecond ;
     LOCAL_VAR INTEGER nCounter ;
     
     if(nTT_CurSecond != TIME_TO_SECOND(TIME))
	  {
	  nTT_CurSecond = TIME_TO_SECOND(TIME) ;
	  nCounter ++ ;
	  if(nCounter == PROJ_POLLING)
	       {
	       send_command vdvVproj,"'current_status'" ; 
	       nCounter = 0 ;
	       }
     	  }
     }

jweather

Vining -- I don't see any particular advantage to doing that versus

DEFINE_PROGRAM

WAIT 70 {
  send_command vdvVproj,"'current_status'" ;
}

Can you explain why you would want to count off the seconds yourself rather than letting the processor do the work for you? The WAIT 70 above just gets stuck in the wait queue, rather than testing a condition on every loop through the DEFINE_PROGRAM section.

Jeremy

fogled@mizzou

Well, I thought there was a single, simple answer to this, since I'm just still learning AMX programming. I should have known there are several ways to solve the problem.

My initial mistake, why I couldn't get it to work, was that I was trying to do the WAIT up in DEFINE_EVENT instead of DEFINE_PROGRAM. Otherwise, my code looks a lot like what NMarkRoberts posted.

That said, I've never implemented a timeline before, and I need to learn. So I'm going to give that a try. If I run into trouble with the timeline, I'll post a new thread with more specific questions.

Thanks everyone for the guidance!

vining

jweather wrote:

Can you explain why you would want to count off the seconds yourself rather than letting the processor do the work for you? The WAIT 70 above just gets stuck in the wait queue, rather than testing a condition on every loop through the DEFINE_PROGRAM section

It's just another way to skin the same dead animal. Basically it does what the processor does when it puts it in the wait queue, When something is in the WAIT Queue the processor has to check it on every pass as well to see if the time is up. I would typically have this in a timeline and not define_program anyway. Having the system test the "IF" every pass of the program is the same as any feedback channel comparison.

[dvTP,nButtons[i + 60]] = nMARoomSource[i] > 0 ;

Uses the same amount of system resources. I can also see the variable in debug to watch it execute while testing code and it provides a little more flexibiltiy if I want to expand upon the simple timer functionality. Sometimes I do things just because I can, whether it makes sense or not.