Seite 4 von 5

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: Fr Apr 09, 2021 6:34 pm
von Robert_Mini
Korrekt ist “a”, sonst wird nichts gesendet.
Ich ändere es oben auch gleich.

Lg
Robert

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 9:41 am
von Franky

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 4:40 pm
von Franky
Robert_Mini hat geschrieben: So Dez 27, 2020 4:50 pm Durch das Clocksignal wird die Logik automatisch nach Reboot oder Restart des Logik-Prozesses ausgeführt.
Ich hab mal wieder das ganze Konstrukt nicht verstanden, merke ich gerade. Ist das Modul Clocksignal denn wie alle anderen Module ein Modul, das ausgeführt wird, weil die Logikzelle auch ausgeführt wird und somit alle Module unter dem Block "Module": [...] ausgeführt werden?

Oder ist das ein "Magic-irgendwas", dessen Vorhandensein unter Module dazu führt, dass die Logikengine die Logigzelle triggert und überhaupt abgearbeitet wird? Also so, als hätte man in der GUI einen Trigger hinzugefügt?

Wenn dem so ist, ist das aber nicht intuitiv verstehbar, da Clocksignal ja vom Codeaufbau als Funktion unter "Module" steht und diese werden doch eigentlich nur abgearbeitet, wenn die Logikzelle getriggert wurde :think: :think: :think:

Die Doku sagt "Erstellt einen zyklischen Trigger innerhalb einer Custom-Logik, der die Ausführung der Logikzelle auslöst ( → Triggerfunktion) ."

Aber wann wird dieser Tigger von wem erstellt? Es kann ja nicht die Ausführung der Logikzelle sein, weil wer sollte die getriggert haben?

Verstehst Du/ihr, was ich meine? Das Henne/Ei-Problem.

Edit1: @Robert_Mini Gerade einen Kommentar von Dir gefunden, auf den aber nie jemand eingegangen ist:
Ich vermute mal, dass eine Logik sobald ein clocksignal oder wakeup vorkommt, beim speichern automatisch getriggert wird (das müsste S. Kolbinger bestätigen können). Das wurde mal als Bugfix ergänzt
Und das gilt dann nicht nur für Speichern, sondern auch Neustart der Logicengine. Wenn das so stimmt, sollten wir das nicht besser in der Doku aufnehmen? Also dieses "automagische Verhalten"?

im Thread Diskussion zu ZSU-Baustein

Edit2
OK, nachdem ich jetzt alle Threads gelesen habe, die eine Suche nach Clocksignal hervorbringt, bin ich mir sicher, dass es wirklich dieses "automagische Verhalten" auslöst, was für ein rabbit hole :lol:

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 7:18 pm
von Robert_Mini
Hallo Franky!

Die Doku hat hier sicher Luft nach oben, aber grundsätzlich ist es ganz einfach :-)

Eine Logik wird getriggert:
1) Durch die Eingänge je nach Triggeroption
2) Trigger Eingang (mit Objekt oder Cron)
3) Durch Ablauf eines Timers triggert sich die Logik selbst (oder von innen wie du es nennst)

Zu 3) gehört auch das Taktsignal, das die Besonderheit hat, dass dieses keinen Start-Trigger braucht sondern einfach losläuft, sofern True am Eingang anliegt. Dies kommt vom Standardmodul Taktsignal, das man ja mit einem Parameter True auf Run fix "enablen" kann. Auch in dem Fall soll es nach einem Reboot ja weiterlaufen...

lg
Robert

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 7:38 pm
von eib-eg
Wenn ich es richtig verstanden habe, dann ist die Logik die mir Dragonos @Dragonos2000 gegeben hat, zum überprüfen des Lebensbits vom Wolf auf dem Bus, die im Fehlerfall mir einen Fehler seitens Bus auf Telegram sendet sowas?

Oder bin ich jetzt auch auf dem falschen Dampfer :think: ?

Code: Alles auswählen

/**
 * New custom logic
 *
 * 
 */
{
  "_Meta": { // Optional
    "Description": "Watchdog to send configurable data, after timeout of trigger input",
    "Version": "1.1",
    "Icon": "" // format: "data:image/svg+xml;base64,ENCODED_FILE"
  },
  "Input": [
  ["Timeout","Watchdog time in seconds, after which the output is sending an alarm","$P_Delay","u"],
  ["Active alarm value","Numeric output value to be sent, when timeout exceeded and alarm raises (used for trigger and state output)","$P_OutValAlarm","u"],
  ["No Alarm state value","Numeric output value to be sent, when no alarm condition detected (only used for state output)","$P_OutValNoAlarm","u"]
  ],
  "Output": [
  ["Alarm trigger","Output, which sends the configured active alarm value, when timeout exceeded","$O_AlarmTrigger","x"],
  ["Alarm state","Output, which sends the configured alarm values (both: alarm or no alarm), when timeout exceeded","$O_AlarmState","c"]
  ],
  "Level": [
  ["$ConstTrue","bool",true],
  ["$ConstFalse","bool",false],
  ["$Send","bool",false],
  ["$P_Delay","int",60],
  ["$P_OutValAlarm","int",1],
  ["$P_OutValNoAlarm","int",0],
  ["$O_AlarmTrigger","int",0],
  ["$O_AlarmState","int",0]
  ],
  "Module": [
  ["Latch","$P_OutValAlarm","$O_AlarmTrigger","$ConstTrue",0],
  ["Monoflop","$ConstTrue","$ConstFalse","$Send","$P_Delay",1],
  ["SendExplicit","$Send","$O_AlarmTrigger",2],
  ["Multiplexer",["$P_OutValAlarm","$P_OutValNoAlarm"],"$O_AlarmState","$Send"]
  ]
}

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 8:01 pm
von Robert_Mini
Das ist wieder was anderes: eine "Selbsthalteschaltung" solange vom Bus das Lebensbit kommt. Fällt der Timer ab (weil kein zykl. Telegram empfangen wird), dann wird ein Wert gesendet.

Robert

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: So Mär 16, 2025 9:05 pm
von Franky
Robert,

danke für die Infos. Es fühlt sich noch ein wenig "komisch" an, dass da ein Teil der module von alleine startet (Cron, Clocksignal, Monoflop, Weakeup,...), um timer / trigger abzubilden. Aber es ist pragmatisch und wenn man es weiss, dann ist alles gut... Ich hab mal einen Kommentar für mehr Klarheit auf der Seite https://elabnet.atlassian.net/wiki/spac ... Logikzelle eingetragen.
Das bedeutet, dass wenn sich eine der Module Cron, Clocksignal, Monoflop, Wakeup (welche noch??) in einer Customlogik befinden, so werden diese als Trigger für die Logikzelle (die custom logik) aktiviert, ohne dass die customlogik bereits getriggert / "ausgeführt" wurde. Hierdurch können Trigger durch das reine Speichern einer custom logik eingerichtet und aktiviert werden, ohne dass eine GUI-Interaktion notwendig ist. Ein sehr komfortables Feature, z.B. bei der Weitergabe / Kopieren von custom logiken.
Franky

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: Mo Mär 17, 2025 7:35 am
von Robert_Mini
Danke. Ich pflege das ein.
Nachtrag: auch die Sendeverzögerung oder Cron bei einer Standardlogik funktioniert so.

Lg
Robert

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: Mo Mär 17, 2025 7:31 pm
von Franky
Robert_Mini hat geschrieben: Mo Mär 17, 2025 7:35 am Nachtrag: auch die Sendeverzögerung oder Cron bei einer Standardlogik funktioniert so.
hmm, was meinst Du mit "so"?

LG

Franky

Re: Erweiterung für Persistenz: Senden nach Reboot

Verfasst: Mo Mär 17, 2025 8:56 pm
von Robert_Mini
Dass sich die Logik selbst triggert. Beim Timer erst nachdem die Logik mal ausgelöst wurde und der Timer dann abläuft.
Eine Logik mit Cron als Triggert löst auch zum definierten Zeitpunkt aus, ohne dass jemals von außen ein Trigger erfolgt ist.

lg
Robert