WAIT - Should I name it?

Spire_Jeff

Here is a tip that might be useful:

DHawthorne wrote:

Named waits will not call a new iteration if the previous has not been canceled or expired.

Here is the thread where this appeared in case you want an example of when this might be useful: http://amxforums.com/showthread.php?postid=5178 *NEW LINK*

Jeff

jjames

Good idea!

I used to have problems with devices sending a gazillion and a half IR pulses if I pressed a button multiple times without using a WAIT name & and not cancelling my wait. Sometimes, the sequence of IRs would continue for a couple of minutes. Good idea to share the whole naming of WAITs!!

(EDIT) - Links works fine. Was saying I wasn't logged in - but I was. After it prompted me to log in again and I did, it worked. Strange . . . must be a bug.

[Deleted User]

Named waits

The only reason to name a wait is if you have a need to cancel it.

dchristo

I have to agree with Brian. All WAIT's (named or not) should not be placed in the "wait list" multiple times. I believe that WAIT's are tracked by line number, not name. Perhaps someone from Engineering could chime in?

I use

WAIT 5 {nFlash = !nFlash}

in Mainline of just about every program I write. If unnamed WAIT's allowed multiple instances, the variable nFlash would toggle at the rate that Mainline was being scanned (which doesn't happen).

--D

DHawthorne

B_Clements wrote:

The only reason to name a wait is if you have a need to cancel it.

Not really.

If your code has something like this:

WAIT 50
(do something)
WAIT 50
(do something else)
WAIT 50
(do another thing)

...all three things will happen, at the same time.

If your code says:

WAIT 'TEST' 50
(do something)
WAIT 'TEST' 50
(do something else)
WAIT 'TEST' 50
(do another thing)

...only the first thing will happen. The other WAITs, having the same name, will not take effect because a WAIT with the same name is already active.

If your code says:

WAIT 'TEST1' 50
(do something)
WAIT 'TEST2' 50
(do something else)
WAIT 'TEST3' 50
(do another thing)

...all three will happen at the same time. It's the same as leaving them unnamed.

Edit: corrected as per Brian's observation below

Spire_Jeff

I can think of one way in which this could be utilized. Say I want to send out email notification when a certain security sensor is tripped, but I only want to send out a maximum of 1 email every 5 minutes. In the email I am sending the last 50 timestamps when that sensor tripped so it doesn't matter if the sensor trips 5 times in a minute. I could do something like:

DEFINE_CALL 'SEND EMAIL'
{
 sSTATUS_MSG = GET_TIMESTAMP_INFO()//Routine to put timestamp info into a single variable
 SmtpQueMessage('status@abc.com',
										'president@abc.com',
										"'Security Event - ',TIME,'  ***AUTOMATED NOTIFICATION***'",
										sSTATUS_MSG,
										'')

}

DEFINE_EVENT
DATA_EVENT[vdvSECURITY]
{
  STRING:
	{
		IF(FIND_STRING(DATA.TEXT, 'ZONE1:FAULT',1))
		  WAIT 3000 'SEND STATUS EMAIL' 
				CALL 'SEND EMAIL'
	}
}

I think this will do what I want without me having to write a timelines or track when the last message was sent. Does this seem logical, or am I misinterpreting the implementation?

Jeff

[Deleted User]

DHawthorne wrote:

Not really.

If your code has something like this:

WAIT 50
(do something)
WAIT 50
(do something else)
WAIT 50
(do another thing)

...all three things will happen, 5 seconds apart. An unnamed WAIT is sort of a global wait, and there is only one handler for it. Any other unnamed waits will be queued up for after the previous ones expire.

QUOTE]

Wrong!

The example above will have all three wait expire after 5 seconds and the code beneath the waits (first line only) will execute. If you want 5 seconds apart you need to use braces. (nested wait)

WAIT 50
{
  (do something)
  WAIT 50
  {
    (do something else)
    WAIT 50
    {
       (do another thing)
    }
  }
}

You can have many unnamed waits and they will all run independently.

Brian

DHawthorne

It should, Jeff. Heh, except I would definitely put some sort of flag in there I could shut it down with if I couldn't get right out there to fix it. I did that once with a thermostat control, and compounded the error by not putting any kind of wait or timeline in it. Next time the thermostat system acted up, my mailbox had thousands of error messages in it withing a few minutes. Good thing I was on site and could shut the NetLinx down. I wouldn't have even known if someone at the office hadn't noticed the mailserver going berzerk.

That little tale aside, I only use waits for the simplest things in NetLinx. What you are describing, I would go ahead and make a timeline for it. For something like that, killing and restarting a timeline is trivial.

dchristo

DHawthorne wrote:

If your code has something like this:

WAIT 50
(do something)
WAIT 50
(do something else)
WAIT 50
(do another thing)

...all three things will happen, 5 seconds apart. An unnamed WAIT is sort of a global wait, and there is only one handler for it. Any other unnamed waits will be queued up for after the previous ones expire.

This isn't quite correct. All three WAIT's will execute at the same time 5 seconds later. They are not nested, and each is handled separately.

--D

DHawthorne

You're right Brian, I got myself mixed up on the queuing issue. However, you still have three events happening, even if they are the same. If the waits are named, only one will happen because a named wait will not fire if another of the same name is already active.