Home AMX User Forum NetLinx Studio

WAIT and TIMED_WAIT_UNTIL

I have the need, in a recursive routine, to use a unique WAIT name:

WAIT nTimeOut "'Timed Wait - ', Zone[nZone].name"

Something along those lines. The WAIT requires a literal string which disallows this from being stated. Is there another way of doing this that I am just unaware of ?

Comments

  • jjamesjjames Posts: 2,908
    You're correct - wait names MUST be constant.

    Typically what I would do is just do a switch case:
    SWITCH(Zone[nZone].name)
    {
       CASE 'Bedroom 1':
    	{
    		WAIT nTimeOut 'Bedroom 1'
    		{
    			// Do something...
    		}
    	}
    	
    	CASE 'Bedroom 2':
    	{
    		WAIT nTimeOut 'Bedroom 2'
    		{
    			// Do something...
    		}
    	}
    }
    
  • ericmedleyericmedley Posts: 4,177
    jprovan wrote: »
    I have the need, in a recursive routine, to use a unique WAIT name:

    WAIT nTimeOut "'Timed Wait - ', Zone[nZone].name"

    Something along those lines. The WAIT requires a literal string which disallows this from being stated. Is there another way of doing this that I am just unaware of ?

    Perhaps you could do this with a Timeline instead.

    Something like this. I did an old fashioned button stack for the example. You could do it just about any way you like.
    button_event[vdv_time_out,1]
    button_event[vdv_time_out,2]
    button_event[vdv_time_out,3]
    button_event[vdv_time_out,4]
    {
    push:
    	{
    	timeline_create(BUTTON.INPUT.CHANNEL, Test_1,4, timeline_absolute,timeline_once)
    	}
    }
    
  • viningvining Posts: 4,368
    Since wait names are set in stone at compile time they need to be explicitly defined at that time. However I don't see why you can't use a constant array with a constant index pointer but even then the compiler doesn't approve.

    I would try a switch case like in the code below.
    DEFINE_CONSTANT
    
    CHAR ZONE_NAME_ARRY[5][6]=
         {
         'ZONE_1',
         'ZONE_2',
         'ZONE_3',
         'ZONE_4',
         'ZONE_5'
         }   
    
    DEFINE_FUNCTION fnTestWaits(INTEGER iZone)
    
         {
         if(iZone <= LENGTH_ARRAY(ZONE_NAME_ARRY))
    	  {
    	  SWITCH(iZone)
    	       {
    	       CASE 1:
    		    {
    		    SEND_STRING dvMaster,"'PRE-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    		    WAIT 20 'ZONE_1'
    			 {
    			 SEND_STRING dvMaster,"'POST-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    			 iZone ++ ;
    			 fnTestWaits(iZone) ;
    			 }
    		    }
    	       CASE 2:
    		    {
    		    SEND_STRING dvMaster,"'PRE-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    		    WAIT 20 'ZONE_2'
    			 {
    			 SEND_STRING dvMaster,"'POST-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    			 iZone ++ ;
    			 fnTestWaits(iZone) ;
    			 }
    		    }
    	       CASE 3:
    		    {
    		    SEND_STRING dvMaster,"'PRE-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    		    WAIT 20 'ZONE_3'
    			 {
    			 SEND_STRING dvMaster,"'POST-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    			 iZone ++ ;
    			 fnTestWaits(iZone) ;
    			 }
    		    }
    	       CASE 4:
    		    {
    		    SEND_STRING dvMaster,"'PRE-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    		    WAIT 20 'ZONE_4'
    			 {
    			 SEND_STRING dvMaster,"'POST-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    			 iZone ++ ;
    			 fnTestWaits(iZone) ;
    			 }
    		    }
    	       CASE 5:
    		    {
    		    SEND_STRING dvMaster,"'PRE-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    		    WAIT 20 'ZONE_5'
    			 {
    			 SEND_STRING dvMaster,"'POST-WAIT ZONE = ',ZONE_NAME_ARRY[iZone]" ;
    			 iZone ++ ;
    			 fnTestWaits(iZone) ;
    			 }
    		    }
    	       }
    	  }
         
         RETURN ;
         }
    
    DEFINE_START
     
    WAIT 600
         {
         fnTestWaits(1) ;
         }
    


    Diagnostics window:
    Line      1 (10:18:47):: PRE-WAIT ZONE = ZONE_1
    Line      2 (10:18:49):: POST-WAIT ZONE = ZONE_1
    Line      3 (10:18:49):: PRE-WAIT ZONE = ZONE_2
    Line      4 (10:18:51):: POST-WAIT ZONE = ZONE_2
    Line      5 (10:18:51):: PRE-WAIT ZONE = ZONE_3
    Line      6 (10:18:53):: POST-WAIT ZONE = ZONE_3
    Line      7 (10:18:53):: PRE-WAIT ZONE = ZONE_4
    Line      8 (10:18:55):: POST-WAIT ZONE = ZONE_4
    Line      9 (10:18:55):: PRE-WAIT ZONE = ZONE_5
    Line     10 (10:18:57):: POST-WAIT ZONE = ZONE_5
    
  • jprovanjprovan Posts: 16
    Thank you for the quick replies. I had thought that timelines might be the way to go, however, what I am attempting to do is write a bidirectional RS-232 routine for a Sharp TV. I was trying to issue a command, wait for one of several responses and then either retry the command or issue the next command based on the response from the TV. NetLinx's OS (and therefore it's event architecture) makes it very difficult for that kind of conversation to occur. What I have wound up with is a piece of extremely convoluted code just to accomplish this. Have any of you written such a routine ?
  • ericmedleyericmedley Posts: 4,177
    jprovan wrote: »
    Thank you for the quick replies. I had thought that timelines might be the way to go, however, what I am attempting to do is write a bidirectional RS-232 routine for a Sharp TV. I was trying to issue a command, wait for one of several responses and then either retry the command or issue the next command based on the response from the TV. NetLinx's OS (and therefore it's event architecture) makes it very difficult for that kind of conversation to occur. What I have wound up with is a piece of extremely convoluted code just to accomplish this. Have any of you written such a routine ?

    this is a classic example of an asyncronous two-way conversation. I used to write them almost exlusively with a Data_Event and a seriers of conditionals with waits in the DEF_PROGRAM section. While Timelines do add some complexity to the structure of the async loop w/conditionals, it does allow for a lot more flexibility in the end.

    And since the Timeline identification uses a numberic id, it is easy to track and tie to other things.
Sign In or Register to comment.