Ankündigung

Einklappen
Keine Ankündigung bisher.

Starthilfe für Logik: Fahren/Stop von Markisen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    HS/FS Starthilfe für Logik: Fahren/Stop von Markisen

    Hallo zusammen,

    ich bastel gerade meine erste "komplexere" Logik für den HS. Vermutlich habe ich ein falsches Verständnis der Funktionsweise. Vielleicht kann mir jemand Starthilfe geben und sagen woran es hängen könnte.

    Folgendes will ich machen:
    Auf einer 14-Byte GA kommt ein String an. Das ist der Tastencode einer Fernbedienung. Jeweils zwei nebeneinander liegende Tasten sollen eine Markisengruppe fahren. Eine Taste für Auf, eine für Ab. Ein zweiter Druck auf die gleiche Taste, bzw. ein Druck auf die Gegenrichtung soll die Markisen stoppen. (Eigentlich so, wie bei der "normalen" Bedienung über Taster.) So weit so einfach.

    Meine Idee war es, den Fahrbefehl in einem RS-FlipFlop zu speichern. Kommt eine Taste und der Merker ist 0, dann fährt die Markise und setzt den Merker auf 1. Kommt dann eine Taste bei Merker == 1, stoppt die Markise.
    Wenn ich die Logik so laufen lasse, dann sendet der HS allerdings zyklisch Auf - Stop - Ab, sobald ich einmal eine Taste gedrückt habe.

    AUF/AB (Zentralbefehl Endlage) und Stop (Zentralbefehl Schritt/Stop) liegen auf unterschiedlichen GAs.

    Irgendwie stehe ich auf dem Schlauch. Wird die Logik zyklisch oder telegrammbasiert abgearbeitet?
    You do not have permission to view this gallery.
    This gallery has 1 photos.
    Zuletzt geändert von DerSeppel; 22.04.2016, 15:22.

    #2
    Logik wird abgearbeitet basiert auf Telegramm Änderung.

    I think the behavior of the RS-Flip-Flop may be the issue. Give the internal KO an internal GA (i.e. 100/1/1), and verify with EIBMON if it does what you think it does when the buttons are pushed.

    Alternative:
    If I had to write it, I would build something differently. Make your internal KO a 2-bit object. Set the default to 1 (so, not zero).
    From the text comparator, go directly to an output selector (Input E1). (Note: an output selector expects a '1' or a '2' as input.) The first output would command 'UP' and set the internal KO to '2'. This IKO is tied to input E2 of the output selector. When the value is '2', the second output is selected. Use that output to command the 'Stop' action, and to set the IKO back to '1'.
    Same for the 'Down' logic.
    Hope it makes sense...

    Bram

    Kommentar


      #3
      Hello Bram,

      thanks for the hint, thats a nice approach! I'll try it. Thanks a lot!
      Zuletzt geändert von DerSeppel; 24.04.2016, 18:09.

      Kommentar


        #4
        Okay, I tried it. The outcome is the same.
        But now it seems a lot more logical to me.
        I guess the UP-STOP-DOWN Loop is caused by the fact that the moving commands also set the IKO. The change of the IKO then (re-)triggers the logic?
        Can I prevent that?

        You do not have permission to view this gallery.
        This gallery has 1 photos.

        Kommentar


          #5
          I did not realize that the '1' on the input of the selector will send a '1' on the output when the selection input changes. One way to resolve that could be to set a telegram delay on that module (if it has that option), so that the exit is blocked for a short time. That may have unintended side-effects for which you will have to test. If it works, it would be the simplest logic. Alternatively, create one additional IKO and tie that to the same inputs as your text comparator outputs. The commands then would be:
          Drive (up or down)
          Set the new IKO to zero (to force the input to OFF)
          Set the 2-bit IKO.

          By the way, you will also have to include logic to set the 2-bit IKO back to 1 when the movement has stopped at the end of a normal, full cycle.

          Bram

          Kommentar


            #6
            It is working now. Thanks for your hints Bram!

            What I learned is:
            - The output selection input of the output selector does indeed trigger the evaluation as well. This makes perfect sense for cases where the Input is static, but you want to dynamically select an output target. So, everythings fine. My expectation was just wrong.
            - Also, it does really matter in what order you put your commands in the outputs. I set the IKO after sending the KNX GA. So first the command was sent, then the IKO was changed, which re-triggered the whole logic. After reordering the commands everythings fine now.

            About your last hint. The actuator is configured to send a telegram after stoping, regardless of the reason. So I just use that to re-set my IKOs. I could probably remove the reset from the STOP action now too. But this does not hurt at the moment.

            If anyone's interested, the logic now looks like this:

            logik.PNG

            Kommentar

            Lädt...
            X