dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: October 25 2001 at 00:34 | IP Logged
|
|
|
It has come to my attention that there is some confusion over the Action Style of Triggers. The action style can be either Immediate or Queued. Generally, you want your action styles to be queued. The only time you would want your action styles to be immediate would be if the action (macro or send keys) are going to access the multi-X system variables (the previous incoming X-10 stack). Another time you would use the Immediate action style would be to update a global variable immediately which other actions in the execution queue may be dependent upon. If your action does have an immediate action style, the action absolutely must not send commands to the connected controllers. You can execute commands to the controller, but these actions must be queued. A good example of this can be seen in the sample database with the triggers that start with PP K and the macro that they call PP K ALL. The triggers must be immediate because the PP K ALL macro uses the multi-X system variables. However, within the macro, any IR or X-10 send commands are posted instead of immediate.
What happens is that the CM11A can transmit multiple received commands to PowerHome. PowerHome will act upon each command in order, firing triggers as necessary. If one of these triggers is immediate and attempts to send X-10 commands to the controller, the remaining commands in the receive queue will be destroyed and you will get a critical error on line 7 of function f_controllerrecv.
However, you must use the immediate action style if the action accesses the multi-X variables. In the example above, if the trigger is queued and multiple received commands are processed, when the queued action is executed, the multi-X variables will already have been updated by the subsequent received commands.
The other instance where immediate is handy can be seen the sample database with the DSS POWER trigger. This trigger is using a global variable to track the current power state of a DSS receiver. Anytime an infrared POWER command is sent to the DSS receiver, the global variable is toggled between 1 and 0. Since no commands are being sent to a controller, this is safe to do. If this trigger was queued instead of immediate, you could run into a problem with queued macros. If queued macro 1 sent a DSS POWER command, and queued macro 2 had a conditional statement to send a DSS POWER command based upon the status of the global variable, the second queued macro would not respond correctly because the trigger fired by the first macro would not execute until after the second queued macro.
I know this sounds complicated, but when you understand the principle, it actually makes sense.
I welcome any questions or suggestions on this issue either posted or via Email.
Thanks,
Dave.
|