Options
Waits at the end of functions?
vegastech
Posts: 369
Why can't I have a wait at the end of a function? I Was trying to build functions for source selection buttons, and I'm trying to implement a wait for the tvs turn on delay. What would be a better approach?
0
Comments
You can have WAITs in functions, you'll just need one for every combination.
Consider this . . .
Paramter A = 1
Function is called with parameter A.
Function is executed upon parameter A.
WAIT is encountered, and retains parameter A.
Function is called again, this time parameter A = 2.
WAIT is executed - which do you think it's going to use? 1 or 2?
Answer = 2.
The best way to use WAITs in a function is to spell them out. Do a SWITCH/CASE or SELECT/ACTIVE on the parameter value, then do the WAIT. Do any CANCEL_WAITs if necessary.
For your example, this approach would probably work best (and this is what I do as well.)
Note - this is an example, not verbatim code with what I do.
DEFINE_FUNCTION fnTV_POWER(nTV_NUM) { SWITCH(nTV_NUM) { // TV number 1 in dv_TV array CASE 1: { SEND_COMMAND dv_TV[1],"'SP',nTV_INPUT[1] + 80" // Send input SEND_COMMAND dv_TV[1],"'SP',27" // Power TV On WAIT 120 SEND_COMMAND dv_TV[1],"'SP',nTV_INPUT[1] + 80" // Send input } // TV number 2 in dv_TV array CASE 2: { SEND_COMMAND dv_TV[2],"'SP',nTV_INPUT[2] + 80" // Send input SEND_COMMAND dv_TV[2],"'SP',27" // Power TV On WAIT 120 SEND_COMMAND dv_TV[2],"'SP',nTV_INPUT[2] + 80" // Send input } // TV number 3 in dv_TV array CASE 3: { SEND_COMMAND dv_TV[3],"'SP',nTV_INPUT[3] + 80" // Send input SEND_COMMAND dv_TV[3],"'SP',27" // Power TV On WAIT 120 SEND_COMMAND dv_TV[3],"'SP',nTV_INPUT[3] + 80" // Send input } } }Like I said, this is a loose example as to what I do. I would typically remove the first two statements (the initial input & power statements), and make them work with the array - and because they need to be executed immediately, I can use the parameter value (nTV_NUM) as opposed to "spelling" it out ([1], [2], or [3]) The second input command I must specify them or else I'll be bitten if handling more than one TV at once.
Hope this makes sense; there's actually a thread on here talking about the specifics - but can't find it off hand.
I?ve never heard that term before but the answer is no, it will not work as desired.
nTV_Num is evaluated after the WAIT expires not when the WAIT is thrown into the queue.
DEFINE_FUNCTION fnTV_POWER(nTV_NUM) { SEND_COMMAND dv_TV[nTV_NUM],"'SP',nTV_INPUT[nTV_NUM] + 80" // Send input SEND_COMMAND dv_TV[nTV_NUM],"'SP',27" // Power TV On SWITCH(nTV_NUM) { // TV number 1 in dv_TV array CASE 1: { WAIT 120 SEND_COMMAND dv_TV[1],"'SP',nTV_INPUT[1] + 80" // Send input } // TV number 2 in dv_TV array CASE 2: { WAIT 120 SEND_COMMAND dv_TV[2],"'SP',nTV_INPUT[2] + 80" // Send input } // TV number 3 in dv_TV array CASE 3: { WAIT 120 SEND_COMMAND dv_TV[3],"'SP',nTV_INPUT[3] + 80" // Send input } } }I've just been looking at this a little and it appears to me that if a function with a wait is called again before the expiration of the wait from the first call that the second wait doesn't happen.
For example:
define_function fnTestWait(integer dummy) { send_string 0, "'Dummy = ',itoa(dummy)" wait 300 send_string 0, "'Dummy = ',itoa(dummy)" } channel_event[dvio,2] { on: { nArgument = 999 fnTestWait(nArgument) wait 150 { nArgument = 1 fnTestWait(nArgument) } } }seems to cause three strings to be sent to the console:
1 @ time = 0
1 @ time = 15 seconds
1 @ time = 30 seconds
I would expect the second call to the function to generate two strings to the console, the second at time = 45 seconds, but that doesn't seem to be the case.
Seems to me that waits in functions don't necessarily work as one might expect.
Even though the WAIT is encountered thousands of times a second, the string is only printed out once every half second.
There is a problem (or at least used to be) with WAITs inside a function but it?s in reference to a different subject. I can?t recall offhand exactly what it was, something about integer arrays I think. If I can find the thread I?ll post a link to it.
http://amxforums.com/showpost.php?p=6913&postcount=7
My expectation would have been that waits generated by two different function calls would not be the same wait. That is, apparently, not the way it works and I'm surprised by that. Oh, well.
Added:
Let me explain a bit why I'm surprised by the way things are. In the code samples above that jjames provided, he expects that 12 seconds after the function is called that a send_command will execute. But, if a subsequent function call is made within 12 seconds, the subsequent send_command expected will not occur. Button events appear to work the same way. So, if you try to turn on multiple tvs within a 12 second period, the function may not perform as the programmer intended.
We deal with the environment as it exists and not as we would like it, so I'll get over this, even though I'm not quite sure how to get around the problem.
The code that jjames provided should perform as intended because there is a separate CASE for each TV and each CASE has its own WAIT. The contents of the WAITs are hardcoded; there are no variables to evaluate. That function can be called three times back-to-back-to-back once for each TV and all three TVs will turn on without issue.
If you replace the word jjames with a_riot42 then what you cited above is true. If that code is called three times (What happened to that post? Call the cops, there?s been a robbery.) back-to-back-to-back once for each TV then the WAIT is only executed one time. The second and third encounters with the WAIT will be ignored, however, since nTV_NUM is evaluated after the WAIT expires only the third TV will work as intended.
One way is to do something like what jjames demonstrated and add a separate CASE/WAIT for each TV.
In this kind of situation, I prefer to use modules. I use one DEFINE_MODULE for each TV and then in my main code I use the same two lines of code for any TV.
For off I do a:
And to turn a TV on a do a:
The module takes care of the rest and the WAIT issues discussed here don?t come into play.
The other thing too about the code I posted, is that the nTV_INPUT (obviously a variable that needs to be set somewhere - I do it in the function - I should have explained that before), is used for which input needs to be shot out. Say nTV_INPUT[1] = 3, and then the function is called again and its value is changed to 1 before the WAIT expires, then 1 will be used and not 3. This way, it's all kept up to date and there's very little manage.
Of course, there are much more elegant ways to manage TV power (I've gone as far as timing the power up and power down sequence and waiting for when the TV is ready to do what the user last told it to do - a headache), but the posted code should give you a good start. Good luck and let us know how it goes!
You're right and you caught me just in time.
channel_event[vdvRecreationTv,nTvChans]{ on:{ local_var integer nRecreationTvPower; local_var integer nRecreationChan; switch(channel.channel){ case 27:{ if(!nRecreationTvPower){ send_command dvRecreationTv,"'SP',channel.channel"; wait 5 send_command dvRecreationTv,"'SP',channel.channel"; wait 120 nRecreationTvPower = 1 } } case 28:{ send_command dvRecreationTv,"'SP',channel.channel"; wait 5 send_command dvRecreationTv,"'SP',channel.channel"; nRecreationTvPower = 0 } default:{ nRecreationChan = channel.channel wait_until(nRecreationTvPower) send_command dvRecreationTv,"'SP',nRecreationChan"; } } } }Now, this code block is written with the understanding that all I am doing with the TV is turning it on/off and switching inputs. Because of this, I am storing anything other than the power commands in the nRecreationChan variable. I decided that I don't need to buffer this as you really only want the TV to switch to the most recent input selected. You will have to adjust the power on delay to match the TV you are controlling.
You could also add some code to the input channels that will execute the power on command if the power is not currently on, and then you simply need to send the input command when you switch inputs. You could also track the current input in a separate local_var and only send it if the TV is not on that input, but since I am dealing with IR devices, I just let it send the input every time just in case the input command is missed by the TV.
Jeff
My method might seem a bit convoluted, but I love how it works in the end.
I have a standard database that I enter in all my values to manage a TV. Command type (IR,RS-232, IP, AMX command, etc.. Actuall command values, delay times for all occasions, how video is handled, how audio is handled, how those things interact with other systems in the install. Power lifts or screens up and down, etc, etc,..) This works for up to 100 TVs.
I have a rather simple TV command function that is fed from a queue. The queue handles timing and sets up the pass through the function and monitors the state of the function. Nothing happens in the function until it's cleared out or cancelled for some reason.
So, to 'code' an install, you just lable all the TVs and fill in the data matrix. Afterward, you're done. no coding involved. Which TP controls which and how many TVs is entereed into another database on the TP Navigation section. I'm really getting lazy in my old age.
--John