[Gelöst] Modul "Triggered"

[Robosoc]

Habe ich leider noch nicht testen können, da ich noch immer 1.6 IP1 verwende.
@S. Kolbinger Hat dieser Bug eine Vorgangsnummer bekommen?

[Robosoc]

Mal eine Frage ob jemand eine bessere Idee hat?

Ich muss in einer Logik erkennen ob die Logik durch einen Timer getriggert wurde und mach das im Moment so, dass ich stattdessen alle Inputs mit Parameter a oder c mit „Triggered“ auswerte. Wenn keiner davon Triggered ist, schließe ich daraus, dass ein Timer der Triggergrund gewesen sein muss. Das scheint zu funktionieren.

Dies bedarf aber einer Reihe von Code Zeilen und Variabeln (also auch eine Menge Zeilen).Daher die Frage, ob ich eine eleganteren Weg übersehen habe?

[S. Kolbinger]

Hallo Sven,

falls du die Timer nachträglich über die GU "dazu geklickt" hast, sehe ich auch keine andere Möglichkeit.

Wenn du die Timer aber bereits im Custom-Code eingebaut hast, sollte es kein Problem sein.

Monoflop: hat einen eigenen Aushang, der anzeigt, ob der Timer aktuell abgelaufen ist.

Clocksignal: zeigt durch Wechsel am Taktausgang an, wenn dieser (zyklische) Timer getriggert hat.

Damit lässt sich auch noch genau feststellen, welcher Timer (falls mehrere) der Auslöser war.

[Robosoc]

Monoflop: hat einen eigenen Aushang, der anzeigt, ob der Timer aktuell abgelaufen ist.

Mir geht es tatsächlich um zwei Monoflop's...

Welchen Parameter meinst Du? Übersehe ich was oder gibt es noch einen weiteren optionalen Parameter?

Die sind die Parameter gemäß KB 4.6.6
["Monoflop","$Trigger","$Reset","$Ausgang","$Verzögerungszeit",0]

Think think... Minuten später...

Ach klar, wenn ich den Ausgang mit einem Latchmodul auf eine fallende Flanke überwache, ist es quasi das was ich suche... Meintest Du es so?

[S. Kolbinger]

Genau so.

[Robert_Mini]

@Robosoc: Bist du noch immer auf IP1 ?
Ich verstehe den Bug leider nicht und kann daher nicht testen, ob es nun passt, deshalb ist das noch FINR.

lg
Robert

[Robosoc]

[Bin inzwischen auf 1.6 RC3, habe mich irgendwann getraut um Rückmeldungen zu geben, bevor die offizielle 1.6 kommt

Das Problem mit Triggered und Break scheint mir wie angekündigt behoben zu sein. Ich habe es mit folgenden Code getestet (falls man es irgendwann später mal braucht), der meinen Erwartungen entsprechend funktioniert hat:

Code: Alles auswählen

/**
* Triggered mit Break Test
*/

{
  "Input":[
    ["In1","","$In1","c"],
    ["In2","","$In2","c"]
  ],
  "Output":[
    ["Out","","$Out","a"]
  ],
  "Level":[
    ["$In1","bool",false],
    ["$In2","bool",false],
    ["$Out","bool",false],
    ["$triggered","bool",false]
  ],
  "Module":[
    ["Triggered", "$In1", "$triggered"],
    ["Break", ["$triggered"]],
    ["Latch","$In1","$Out","$In1",3],
    ["Latch","$In2","$Out","$In2",3]
  ]
}

Habe das Topic als gelöst markiert

[Dragonos2000]

Kann es sein, dass das Modul "triggered" keine dynamisch erzeugten Eingänge verarbeiten kann? Also dass sowas nicht möglich ist:
["Triggered", "$VAR<Input?>", "$Touched" ]

Und das hier fällt beim erzeugen des 2. Eingang auf die Nase:
["Triggered", "$VAR<Input!>", "$Touched" ]

Ist kein Beinbruch, aber ich frage bevor ich mir weiter nen Wolf suche (nettes Wortspiel )

[adimaster]

Kann es sein, dass das Modul "triggered" keine dynamisch erzeugten Eingänge verarbeiten kann? Also dass sowas nicht möglich ist:
["Triggered", "$VAR<Input?>", "$Touched" ]

Gibt es hierzu schon Updates?