Sunday night challenge : Reflex Conditionals?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • jpdw
    Automated Home Guru
    • Oct 2007
    • 169

    Sunday night challenge : Reflex Conditionals?

    Does anyone know if you can do a conditional execution in a reflex 'program' ?

    Scenario is that I have a DRB configured so that a press on button #2 sends the appropriate packets to re-set a DTS' trigger levels to a specific set of values (a much lower "I'm away" set point).

    I want to press the same button again to send a slightly different set of packets to return the DTS to the normal level.

    But this means I need to be able to record and then query the "state" to know which set of packets to send (set point 18C or set point 12C).

    I seem to remember reading something on reflex conditional execution & states somewhere but (as with anything you later look specifically for) I now can't find it....

    Edit: Before anyone asks, DRB Button #1 is otherwise already used. I guess I could rig up a switch to the digital inputs but a "toggled" button behaviour would be nicer.
    Jon
  • Karam
    Automated Home Legend
    • Mar 2005
    • 863

    #2
    The answer is yes. I'll just outline the principle for the moment:

    A set of (at least) 8 flags (UDRCFs) is provided for use by Reflex programs on a given module. A Reflex response can be written to modify these flags. Similarly a Conditional Reflex response can be written which only executes if the flag/s are in a particular state.

    So you can do something like this in response to a button press event:

    If flagN = 0 then Set temperature limit to X
    If flagN = 0 then turn off LED 1 (if you want indication)
    If flagN = 1 then Set temperature limit to Y
    If flagN = 1 the turn on LED 1 (if you want indication)
    Toggle flagN

    Cortex does not provide a 'pre-canned' way of dealing with conditional Reflex packets or directives so the main packet body will have to be manually constructed (but still using the Cortex Reflex programming utility). Since there are details specific to your application I will help you work it out directly first and then hopefully disseminate the results to the forum in perhaps a more explanatory manner.

    Karam

    Comment

    • Gumby
      Moderator
      • May 2004
      • 437

      #3
      Yes you can. There are conditional directives E0-E5 that can go at the head of each UDR segment in the command code byte. They are covered in the IdraGen document if you have it. You can use them to compare a direct parameter with a memory location. So you could store your state in a memory location. There are also the flags, which I can't pinpoint at the moment, but provide a limited store for simple state.

      I did something like this when sorting out Reflex fallback for LD11s: http://www.gumbrell.com/archives/200...ing-x10-u.html

      What I haven't found is whether/how you can trigger a UDR from a network packet. This means you could store the state on the DTS and have a simple packet on the DRB - in other words implement a toggle program on the DTS and just invoke it. This makes better sense to me, for example if you had multiple buttons to change your settings, since it localises the state correctly and avoids a synchronisation problem. So I have to believe that it is do-able, just not covered in the documents I have
      ----------------------
      www.gumbrell.com

      Comment

      • Gumby
        Moderator
        • May 2004
        • 437

        #4
        I should have waited ...
        ----------------------
        www.gumbrell.com

        Comment

        • Karam
          Automated Home Legend
          • Mar 2005
          • 863

          #5
          Originally posted by Gumby View Post
          I should have waited ...
          Actually no, my suggested solution uses the DRB module to maintain the state. So I agree that what you are suggesting might be better when you have the possibility of control from multiple locations. Modules other than the MFP and DFP series do not have a (nice) way of triggering UDRs via a network packet. This might change in future incarnations. If we exclude the hacking method (modifying specific RAM locations) then the present solution can be extended to synchronise the flag states in other control modules, but as you say not so nice since if you add a new control module then you have to update the Reflex code on all. Alternatively I suppose the ZID or TID addressing can be utilised to minimise this. Ok I'm rambling now ..... :-)

          Karam

          Comment

          • Gumby
            Moderator
            • May 2004
            • 437

            #6
            Am I correct in understanding that the conditionals can operate on memory locations as well as UDRCFs ? What is the format for the memory address as a parameter (ie number of bytes) and how do you determine the number of bytes in the UDCRF for a particular type of module.
            ----------------------
            www.gumbrell.com

            Comment

            • jpdw
              Automated Home Guru
              • Oct 2007
              • 169

              #7
              Thanks Gumby & Karam for suggestions.

              I've tried a few more things... Possible 50% successful as the toggle works just perfectly 50% of the time .

              I'm either failing to successfully test the bit or to toggle it at the end of the execution - I am successfully skipping the "false" execution, just at the moment *always* skipping the same line!!! Doh.
              Jon

              Comment

              • jpdw
                Automated Home Guru
                • Oct 2007
                • 169

                #8
                Originally posted by Gumby View Post
                this when sorting out Reflex fallback for LD11s: http://www.gumbrell.com/archives/200...ing-x10-u.html
                I think this is probably where I got the idea from ... remembering having read it back when I read & re-read your Blog-Bible !

                Trying what you've described gives me some success (see above) but not completely... either your different modules mean the 'code' is different or I'm misunderstanding something here.

                If I can't get this working I'll feel a real numpty .. 12/14 years ago I was involved with safety critical auto stuff so I really ought to be able to figure this one out....
                Jon

                Comment

                • Gumby
                  Moderator
                  • May 2004
                  • 437

                  #9
                  Difficult to decide what you might be doing wrong - perhaps if you post your Reflex program ?
                  ----------------------
                  www.gumbrell.com

                  Comment

                  • jpdw
                    Automated Home Guru
                    • Oct 2007
                    • 169

                    #10
                    Okay, sorry to keep you all in suspence but after making the original post I had to go away for a few days last week. In the meantime I got some suggestions off-list from Karam which I've just tried.

                    So... Long story long:

                    Background
                    I have a DTS triggering a "call for heat" on a DRB Relay#1.
                    Generally the high/low triggers are 18.5/18C. On passing the trigger points (ie going below the Low, or above the High), the DTS sends a packet to open or close the DRB Relay and reset/set the DRB LED1 .
                    In turn, the relay contacts are inline between my CH timer and CH flow zone valve. The microswitch on the zone valve provides 'call for heat' to the boiler. ie this is bog-standard low-tech heating except the DRB relay has replaced a nasty analogue thermostat.
                    Note that at the moment, I'm not using Cortex to actively manage things, so I'm relying on simple reflex packets for this very simple set-up.

                    What I'm trying to achieve
                    I'm away quite often for work, so is my wife. I've been using cortex's reflex editing function to reset the High/Low triggers from the normal 18.5/18C to something lower - example 14.5/14C. I want move this functionality to button 2 on the DRB - ie press button 2 and the trigger points get set to "gone away mode" 14/14.5C. Come home, press button 2 and the trigger points are re-set to 18/18.5C. I want LED2 on the DRB to indicate "gone away mode".

                    The solution
                    Using the Command Insight functionality I've created the following packets, all against the "DRB Relays" object:
                    1) Packet name "E2 Set Low Temp to 14C (0E00)"
                    E20001FF90FFFF100844001207020E00

                    2) Packet name "E2 Set High Temp to 14.5C (0E80)"
                    E20001FF90FFFF100844001207030E80

                    3) Packet name "E2 Set LED 2"
                    E200013C0102

                    4) Packet name "E3 Set Low Temp to 18C (1200)"
                    E30001FF90FFFF100844001207021200

                    5) Packet name "E3 Set High Temp to 18.5C (1280)"
                    E30001FF90FFFF100844001207031280

                    6) Packet name "E3 Reset LED 2"
                    E300013C0202

                    7) Packet name "Toggle UDRCF"
                    0C3001

                    Defining them against the DRB Relays is important... Although some will eventually affect the DTS (setting the triggers) they will be executed on the DRB. The packets that do affect the DTS are effectively instructions to send another packet to the DTS (to set the low/high triggers)... instruction to send an instruction. Took me a few moments to get that which is why I've just repeated it here!

                    To attach this lot of actions to button 2, I then opened up the DRB Switches Reflex box then selected selected "button 2 trigger" to get the Reflex Triggers box. Here I selected each of the packets listed above, in the same order as I've shown. Then close the dialogs and "Program this Node" (remembering that programming the DRB has to be done from the top-level DRB object).

                    The packets in more detail
                    The key to this is to create a state-variable / state-flag. This is the UDRCF mentioned in previous posts (and inspiration from reading Gumby's blog, as ever).
                    The packet "0C3001" toggles bit 1 of this flag byte
                    [0C = modify, 3 = Toggle (set/reset available alternatively), 0, 1 = bit 1]

                    The packet 'prefix' E2 00 01 is used as a conditional that executes the remainder of the packet is UDRCF bit 1 is SET.
                    [E2 = the conditional, 00 = UDRF address, 01 = the comparison]
                    ** I had a different value for the UDRCF, Karam gave me the correct value - I'm not sure if I'd messed up or if Cortex gave me this value **

                    The remainder of the packet is the instruction to send a packet to the DTS:

                    FF90FFFF100844001207020E00
                    where
                    - the DTS address is 1008
                    - 0702 references the Low temp threshold (0703 for High temp)
                    - 0E00 is the temp to set (14C)

                    So the full packet is:

                    E20001FF90FFFF100844001207020E00

                    Follwing this pattern, there are 2 x "E2" packets (to set high trigger and low trigger)

                    E20001FF90FFFF100844001207020E00
                    E20001FF90FFFF100844001207030E80

                    then 2 x "E3" packets (which will execute if UDRCF bit 0 is NOT set)

                    E30001FF90FFFF100844001207021200
                    E30001FF90FFFF100844001207031280

                    I added a couple of E2/E3 packets to set/reset the LED and then finally the UDRCF toggle packet

                    I hope this makes sense... If I get time I'll do a version with screen shots as I know people prefer like pictures....!
                    Last edited by jpdw; 13 February 2008, 12:03 AM.
                    Jon

                    Comment

                    • Karam
                      Automated Home Legend
                      • Mar 2005
                      • 863

                      #11
                      Originally posted by Gumby View Post
                      Am I correct in understanding that the conditionals can operate on memory locations as well as UDRCFs ? What is the format for the memory address as a parameter (ie number of bytes) and how do you determine the number of bytes in the UDCRF for a particular type of module.
                      Sorry, somehow didn't see this question until now. The answer is yes you can use conditionals on other memory (RAM) locations. The address is just a single byte (meaning locations 00 to FFh) but the first 8 bytes are reserved to mean UDRCF bytes 0 - 7, because the actual location of the UDRCF byte/s are different on different modules. Also most modules only implement 1 UDRCF byte at present (providing 8 flags). Using UDRCF addresses 01-07 will just point you to UDRCF address 00. There is no easy way to tell how many UDRCF bytes are implemented other than asking IDRATEK but minimum is 1.

                      Although you can use the conditionals on other memory locations it is only useful if you have a memory map for a particular module. Like the memory modifying instructions these features are not really intended for general usage but exist mainly for diagnostic operations.

                      Karam

                      Comment

                      • Karam
                        Automated Home Legend
                        • Mar 2005
                        • 863

                        #12
                        Reflex temperature set point change

                        This rather complex looking Reflex procedure probably illustrates some of the reasons why we provide and try to improve the Reflex programming facility within Cortex and also why it in some aspects might initially seem counter intuitive (see below).

                        If it wasn't for the conditional requirement the commands to change the DTS high/low threshold parameters would actually be programmed within the DTS object in the Cortex utility, rather than the DRB as is necessary in this example. Why? Because when you program the instruction against the DTS object you don't have to specify the header and address of the DTS module (FF90FFFF44001008 in this case). This not only makes it easier for a user to program (since they don't have to understand the header nor look up the module address) but it also means that the code is to some extent module address independent. In other words if you should change that modules's address for some reason then you don't then have to go and change all Reflex code targetted at that module from other modules. Instead you just click on Reflex program the network and Cortex will automatically write in any necessary address changes.

                        This mechanism may also be possible to implement with conditionals but its something we have not yet got round to looking at, so for the moment conditional statements have to include the recipent packet in explicit form and you have to be careful if you change the recipient address for some reason.

                        Karam

                        Comment

                        • jpdw
                          Automated Home Guru
                          • Oct 2007
                          • 169

                          #13
                          Originally posted by Karam View Post
                          This rather complex looking Reflex procedure probably illustrates some of the reasons why we provide and try to improve the Reflex programming facility within Cortex and also why it in some aspects might initially seem counter intuitive (see below).

                          If it wasn't for the conditional requirement the commands to change the DTS high/low threshold parameters would actually be programmed within the DTS object in the Cortex utility, rather than the DRB as is necessary in this example. Why? Because when you program the instruction against the DTS object you don't have to specify the header and address of the DTS module (FF90FFFF44001008 in this case). This not only makes it easier for a user to program (since they don't have to understand the header nor look up the module address) but it also means that the code is to some extent module address independent. In other words if you should change that modules's address for some reason then you don't then have to go and change all Reflex code targetted at that module from other modules. Instead you just click on Reflex program the network and Cortex will automatically write in any necessary address changes.

                          This mechanism may also be possible to implement with conditionals but its something we have not yet got round to looking at, so for the moment conditional statements have to include the recipent packet in explicit form and you have to be careful if you change the recipient address for some reason.

                          Karam
                          Defining instructions against one module (here the DRB) to send to another (here the DTS) really does though emphasise the distributed object nature of the system.

                          It's really "cool" (in a techy-HA kind of way) now to press the button on the DRB, see it's re-setting the DTS' triggers then hear the DRB relay open as the DTS tells it heating isn't needed any more....


                          The editor is usually very good at suggesting possible next bytes for a packet but it seems to get a bit lost when you go "off piste" and start defining things like the above - I guess because I was using a network address to select the module to send to, it didn't realise it was a DTS so couldn't continue to offer be the applicable choices.

                          --Jon
                          Jon

                          Comment

                          • Gumby
                            Moderator
                            • May 2004
                            • 437

                            #14
                            $64m?

                            Thanks JPDW - Great post - does it work now?
                            ----------------------
                            www.gumbrell.com

                            Comment

                            • Karam
                              Automated Home Legend
                              • Mar 2005
                              • 863

                              #15
                              The command insight (editor help) is admittedly not entirely up to date :-(. Also didn't help that it gave you the wrong (legacy) suggestion for the UDRCF address of 2E when it should actually have been 00. These are issues which will be gradually fixed/improved...

                              Karam

                              Comment

                              Working...
                              X