WAIT and TIMED_WAIT_UNTIL

jprovan
jprovan Junior Member
in NetLinx Studio
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 ?
· Share on FacebookShare on Twitter

Comments

  • jjames
    jjames AMX Sustaining Engineer
    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...
		}
	}
}
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    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)
	}
}
    · Share on FacebookShare on Twitter
  • vining
    vining X Member
    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
    · Share on FacebookShare on Twitter
  • jprovan
    jprovan Junior Member
    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 ?
    · Share on FacebookShare on Twitter
  • ericmedley
    ericmedley Senior Member - 3709 Posts
    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.
    · Share on FacebookShare on Twitter

Categories