determining if a value changed

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • J V
    LoxBus Spammer
    • 28.08.2015
    • 367

    determining if a value changed

    Hello,

    Perhaps some strange questions... but I want to be sure that I'm not making a logic error...

    1. If I want to determine whether a value changed, does it suffice to compare it with a memory flag that contains the same value with 1 cycle delay? Thus the condition below works?
    -
    if (value(t) <> value(t-1)) then value changed
    -- value(t) denotes the value at time t
    -

    2. If I have 2 values (a and b), and they should have the same value but should take the value of the one that changed last, would this work:
    -
    if ((a changed) and (b not changed)) then b=a
    if ((b changed) and (a not changed)) then a =b
    if ((a changed) and (b changed)) then ... ( this is very unlikely to occur within one cycle of the miniserver, but just to be safe I should catch it and either give priority to a or to b)
    -

    3. If the logic from 2. works, would the combination with 1. work,
    -
    if (a(t) <> a(t-1) and (b(t)==b(t-1) then b=a
    if (a(t) == a(t-1) and (b(t)<>b(t-1) then a=b
    ...
    -

    or will I risk to run into issues that the comparisons happen in different cycles, and that I would e.g. have to store whether one changed in an analog memory as below?
    -
    if (a(t) <> a(t-1)) then trigger analog memory "a_changed" to store true
    if (b(t) <> b(t-1)) then trigger analog memory "b_changed" to store true
    if (a_changed and not b_changed) then b=a, reset a_changed, reset b_changed
    if (b_changed and not a_changed) then a=b, reset a_changed, reset b_changed
    -
    Or can I forego the analog memory and just use the outputs of the conditions as in 2.


    Thanks!

    Jörg
    Zuletzt geändert von J V; 11.12.2019, 11:47.
  • Christian Fenzl
    Lebende Foren Legende
    • 31.08.2015
    • 11224

    #2
    Hi Jörg,

    From my previous experiences, if you connect two (or more) analogue values to a block with one analogue input, Loxone always uses the last changed value.
    This would directly solve (2.) and (3.)
    Try this with eg. a "Virtual Status" (digital: no), "Virtual Output" (digital: no) or any block, that allows analogue inputs and can show the result.

    If two values change in the same plc cycle, the result is undefined (maybe this or that value is the result), as the order of the plc processing is not known.
    Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine

    Kommentar

    • J V
      LoxBus Spammer
      • 28.08.2015
      • 367

      #3
      Thanks!
      I need to do more than just set a and b, so I need to identify which of the two changed, which is why I am thinking of the above constructions... My biggest worry was if the inequalities a(t)<>a(t-1) and b(t)<>b(t-1) are resolved in the same plc cycle... In that case
      -
      -
      if (a(t) <> a(t-1) and (b(t)==b(t-1) then b=a, a was the last one that changed
      if (a(t) == a(t-1) and (b(t)<>b(t-1) then a=b, b was the last one that changed
      ...
      -
      should work....

      I accidentally posted the question in the knx forum, but I'm again experimenting with synchronizing the intelligent room controller with my thermostats...

      Kommentar

      • Christian Fenzl
        Lebende Foren Legende
        • 31.08.2015
        • 11224

        #4
        You can use the internal logic from Loxone as described above to get the last value (as value), and additionally the marker logic to get a pulse at the changed values.

        The situation a(t)<>a(t-1) and b(t)<>b(t-1) in one plc cycle can neither be solved by Loxone's nor by the marker solution, as in both situations you don't know, how the plc processes the change events: The analogue value may be a or b, and the pulse from the marker compare solution may first detect and trigger a or maybe b.

        If you use both (to get the value and the impulse), the value is at least 1 cycle earlier as the pulse (because of the marker delay).
        Zuletzt geändert von Christian Fenzl; 11.12.2019, 12:55.
        Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine

        Kommentar

        • J V
          LoxBus Spammer
          • 28.08.2015
          • 367

          #5
          Ok, thanks! I wasn't sure how to interpret the cycle; this clarifies it.

          It means that the situation a(t)<>a(t-1) and b(t)<>b(t-1) is rather a(t1)<>a(t1-1) and b(t2)<>b(t2-1), with t1 and t2 an unknown number of cycles apart. Should still not be an issue for me as that case will most likely not occur and I will just have to choose an option. In the other cases, even if time "t" is not in the same cycle, it should not matter much... I think... The reason is that the value would be an infrequent changing value, both for a and b, and they are very unlikely to change together (the value has to do with thermostat settings - operation mode, setpoint shift, ... - and it is either set from the KNX bus (a) or from a Loxone block (b). As such, the fact that I am a few cycles of with the value I use is not an issue, as long as I know which one changed last and get its value; as I understand it should work with this:
          -
          if (a(t) <> a(t-1) and (b(t)==b(t-1) then b=a, a was the last one that changed
          if (a(t) == a(t-1) and (b(t)<>b(t-1) then a=b, b was the last one that changed
          -

          Important is rather that I would not miss a change in the normal case where either a or b changes.
          Zuletzt geändert von J V; 11.12.2019, 17:21.

          Kommentar

          Lädt...