Your Universal Remote Control Center
RemoteCentral.com
RTI Control Systems Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Flag durations in a system macro?
This thread has 10 replies. Displaying all posts.
Post 1 made on Friday August 3, 2007 at 02:39
tgrugett
Select Member
Joined:
Posts:
August 2004
1,850
Here is something that I have always wondered....

Does a flag action have a duration?

A scenario... to track input selection and zone sync in a muli-zone system on the processor I will issue a "clear all input flags" system macro before issuing a new input flag. This can often include 8 or more flags. I will often use this system macro nested in other system macros or standalone macros. Will this have a measurable duration that I need to consider when inserting delays between individual system macros contained within another macro?

As a rule, I will insert delays between nested system macros based on the following formula... .3 sec for each IR/232 command or single command nested system macro contained within a called system macro plus the total of any delays contained within any nested macros. This works well as a default most of the time, however, I currently do not allow any duration for flag events and I wonder if this could be the potential source of the macro timing issues I occasionally have. It would be fantastic if TTD could show the duration of all the system macros so that the delay structure could be planned ahead of time!!!

Other considerations... is a processor flag set, clear or test ignored if placed after a multi-command system macro without having a delay between them? Does a flag have a default delay built in like with IR commands?

I also imagine that each single command has a specific duration unique to that command or protocol. The variations are likely slight but does anyone know what a good default is? If there is a default .3 sec delay after commands it would seem reasonable that the command and the delay together would be greater than .3 sec.
Post 2 made on Friday August 3, 2007 at 06:15
Oz AVI
Senior Member
Joined:
Posts:
November 2004
1,151
On August 3, 2007 at 02:39, tgrugett said...
Here is something that I have always wondered....

Does a flag action have a duration?

Troy, I believe you're right in thinking flags having a duration.
As to the duration, a number of factors come into play. Obviously any time delay, including the .3 second delay after the command is sent will have a great affect (I know you have already accounted for this one). We can see within Properties of the remote memory space, however, there is no information of processing speed of the remote itself, maybe someone out there knows? I feel that this must come into play at some stage.

On my own T2c, I can control a Split System Air Conditioner using a series of flags, each button push (Macro) requires roughly 16 to 18 flags to be checked and where required, set or cleared along with page flips and one discrete code to be sent.
If buttons are pressed too quickly the remote tends to lock up, so if I am demo'ing the remote (not in front of a AC unit), I tend to pause briefly between button pushes so as to not lock it up. Looks bad in front of a client!
Post 3 made on Friday August 3, 2007 at 06:16
vbcodep
Long Time Member
Joined:
Posts:
July 2007
36
This leads to another question. Are system macros thread safe meaning that they can not be pre-empted by another system macro. In another words does it just execute one macro at time or can it process multiple macros. The only exception I could see if when a system macro calls another but pre-emption is voluntary is this case. If macros are not thread safe then the operating system would have to manage the I/O ports and interrupt on completion. If this is the case then the flags would have to be managed using some type of synchronization mechanism such as a Mutex but I can't image the RP-6 is that complicated. I am guessing the RP-6 is queuing up trigger codes/system macros that come in then processing macros one at a time. Perhaps they are using some type of small shared memory buffer. I would love to see a schematic of the system. If you are using trigger codes these are basically just generating "hidden" system macros that are being indexed seperately. For some reason it distingushes RF from IR trigger codes and I am not sure why the real difference is here. It would seem that once the RF hits the antenna is would be converted to an IR trigger code but this is not the case. Perhaps something with the envelope is a bit different. I good question for RTI tech support. Do any of the RTI guys read this forum. I would love an hour with one the engineers. I have a list of questions for them.

If the RP-6 is thread safe then you should not need any delays to set or test flags as each flag should be safe. I can not image any other design especially in this scenario.

I would assume it is single threaded in which case you should not need any delay for setting flags because each macro is thread safe and can not be preempted by another macro.

When I have experience timing issues it is usually due to the fact that when a remote/touchscreen device calls a system macro it continues processing and has no method to wait for the macro to complete. You have to make a reasonable assumption about a side effect. Usually a delay by the caller of the system macro would provide enough time for the macro to complete.
OP | Post 4 made on Saturday August 4, 2007 at 03:36
tgrugett
Select Member
Joined:
Posts:
August 2004
1,850
On August 3, 2007 at 06:15, Oz AVI said...
On my own T2c, I can control a Split System Air Conditioner
using a series of flags, each button push (Macro) requires
roughly 16 to 18 flags to be checked and where required,
set or cleared along with page flips and one discrete
code to be sent.
If buttons are pressed too quickly the remote tends to
lock up, so if I am demo'ing the remote (not in front
of a AC unit), I tend to pause briefly between button
pushes so as to not lock it up. Looks bad in front of
a client!

Are these flags on the remote or the processor or both?
Post 5 made on Saturday August 4, 2007 at 04:05
Oz AVI
Senior Member
Joined:
Posts:
November 2004
1,151
On August 4, 2007 at 03:36, tgrugett said...
Are these flags on the remote or the processor or both?

The remote has to be in 'Stand Alone' mode for the page links to work. Also, unless there is a IR cable to the AC unit, once again it has to be stand alone.
If there is a cable to the AC unit, all the commands (as in the discrete temperature codes) would have to be system macros, once again so as to be able to do the page links.
I've yet to work with a ducted AC system that is (I.R) remote controlled, haven't seen any yet, but I'm sure they're out there!
OP | Post 6 made on Saturday August 4, 2007 at 17:35
tgrugett
Select Member
Joined:
Posts:
August 2004
1,850
I imagine that the remote and processor would have different parameters for things like flag duration and command processing.

I think the questions should probably be...

Does setting, clearing or testing a flag have a duration(s)?

Does calling a system macro have a specific duration unrelated to the contents of the macro? What I mean is this... thinking of the system macro as a shell to hold the contents of an action, does this "shell" have a specific duration? Does a system macro containing a particular command have a longer duration than the command by itself?

Can RTI employ a feature by which we can see the duration of a particular action or macro and even possibly run a macro diagnostic to detect any processing issues? That would be cool!

Do IR and RS232 commands have a general duration profile? I realize that each command is likely unique but does the system have some sort of inherent signature when dealing with these commands?

Should system macros have a default delay after the action feature that exists with IR commands? What about 232?

Can system macros eventually be made "thread safe" like vbcodep mentioned? Should they?

I see this as critical information especially as it applies to my programming. I will often use one or more T3 controllers to operate a whole house distributed system and I find it becomes more efficient to establish centralized flag placement. For example I will create system macros for zone on/off and zone source selection that will issue one command and set various flags (zone on flag, system on flag, source flag). Then I will create activity macros in which I will nest these macros. This way I only have to set or clear flags in one location and I can create my activity macros without having to worry about inserting flags in the sequence. I do, however, have to plan for my delays but I find this less tedious. A great example of the benefit of this method came on a job I finished recently. My client was very involved in the GUI and operation of the control system and he had me change the specific operation of the remote numerous times after he boiled down the various options. I had to come up with quite a few flag logic control variables to get the specific behavior he wanted. It would have been a nightmare had I placed flags in each sequenced macro and not the single command macros that I call because I would have had to scan through much more of system architecture.
Post 7 made on Saturday August 4, 2007 at 23:27
Ernie Bornn-Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
On August 3, 2007 at 06:16, vbcodep said...
This leads to another question. Are system macros thread
safe meaning that they can not be pre-empted by another
system macro. In another words does it just execute one
macro at time or can it process multiple macros.

This thread makes my head hurt, probably because I'm just looking and am not involved in solving a problem like this.

I have noticed that flag actions take time. I have a pretty simple flag macro on what I laughingly call a "system" in my living room: a TV with toggle only power, a DirecTV DVR, and a Sony DVD player.

When the "system" is on and I turn it off, my T2+ shows the button in action for about a second. This process involves checking the flag and turning off the TV...and there's a clue.

If the system is off and I hit the SYSTEM OFF button, the T2+ shows the button in action for only a couple tenths of a second. And here's where that clue comes in handy: if the flag has been unset, the macro does not execute TV POWER, nor does it unset the flag, and the macro takes less time. I'm sure it takes less time because of no TV POWER command, and maybe also because of no need to unset the flag.

Regardless, if you are using flags, you must be issuing commands dependent upon the state of the flag, so the macro will take a different amount of time depending on whether the state of the flag tells the remote to issue other commands, or not.

As to macros being thread safe, I know my T2+ will not do any next step once one macro has started, until it is finished. I believe that if a macro calls up another macro, that second macro would have to finish before the first one can do the next step. I think it has to be that way, because the remote can't issue multiple commands at the same time and so have to be strictly ordered to work at all.
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
OP | Post 8 made on Sunday August 5, 2007 at 15:33
tgrugett
Select Member
Joined:
Posts:
August 2004
1,850
On August 4, 2007 at 23:27, Ernie Bornn-Gilman said...
This thread makes my head hurt, probably because I'm just
looking and am not involved in solving a problem like
this.

Ernie,

This issue really comes into play, at least for me, when using RS232. Since there is no 232 search and replace feature, I have adopted a "Pronto" approach to the programming. As like many others, I would use hidden code pages when programming Prontos and then link GUI buttons to these hidden buttons that contained the commands. Change the codes on the hidden page and the system is quickly adaptable. I use the system macros storing 232 commands much in the same manner with the addition of mated flag actions. I know whenever I call one of these system macro commands that the processor flag status will always be correct. This obviously has nothing to do with flags on the remote for variable page flips, etc...

I do many Denon based systems using Pioneer of Fujitsu TVs also controlled via 232 so I can create one RP6 file that I can plug into just about any one of these configurations.

This issue of duration quickly becomes an issue using this method.
Post 9 made on Sunday August 5, 2007 at 16:25
fluid-druid
Senior Member
Joined:
Posts:
June 2005
1,312
If there is a delay when testing,setting,clearing flags it is VERY short. I know this because I have used flags in some pretty extensive ways.

Since you can't assign a string or number value to a variable (yet, I hope) if you want to have several flag possibilities, you have to CLEAR all the relative flags before setting a flag. I have macros that literally clear 40 or 50 flags, and then set one. And I haven't noticed anything other than a slight hiccup in the speed of the macro.
...couple a thumb tacks and a stick of double sided tape should hold this baby up...
Post 10 made on Tuesday August 7, 2007 at 00:07
estech
Active Member
Joined:
Posts:
August 2002
584
Thread safe macros?
If your referring to what I think you are, here's what I know:

1) The timing for a sequence of system macros, called from a keypad/controller macro, must be accounted for in the keypad/controller macro. If the first system macro has not completed before the second is called, the second one will be ignored (and possibly others that follow). Precise time delays are necessary.

2) The timing for a sequence of system macros, called from within another system macro, will automatically be accounted for by the processor. The processor won't start the second system macro until the first system macro is complete. No delays are necessary.

3) Multiple processors will run separate system macros simultaneously, when called from a single keypad/controller macro. No delays are necessary

Just my .02 cents.
Pay no attention to that man behind the curtain.
OP | Post 11 made on Tuesday August 7, 2007 at 00:31
tgrugett
Select Member
Joined:
Posts:
August 2004
1,850
Here is the response from Brett at RTI to my posted questions...

Hello Troy,

If you have two system macros embedded in another system macro, you do not need to add any additional time delays between them as they will run in succession. You only need time delays between system macros when they are being sent from a remote button macro in Standalone mode because the remote does not know if the processor is busy and the processor can only do one thing at a time. Therefore if the processor is running a system macro and the remote sends another trigger code, the processor will just ignore it.

A flag event will take a 5-10 milliseconds to run, so clearing 8 flags will probably take less than the minimum length of time delays which is .1 seconds. However, to be cautious, you might make your time delay .2 seconds to give the processor time to move to the next trigger code. A flag does not have a time delay built in by default like an IR code.

Also, most IR commands take less than .2 seconds to run depending on repeats. Those .3 second delays are there to give separation between codes so there isn't constant stream of IR coming out of the emitter/remote that might "confuse" the equipment. Therefore, if you wanted to be safe, you could assume .4 or .5 seconds per command delay should be sufficient when adding up time delays between system macros triggered from a remote button macro in Standalone mode.


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse