ElabNET Technik Forum

Ich arbeite gerade an einem universellen Raumtemperaturregler in einer Custom Logik (werde ich gleich gesondert auch posten). In der Logik möchte ich Überwachen ob Temperatur-Telegramme ausfallen und dann einen boolschen Alarmausgang beschalten (Anwendungsfall Sensorausfall).

Im Moment überwache ich das mit So lange ich nur den einen, ersten Temperatur-Sensorwert verwende, den erstellt, funktioniert es.
Parametriere ich in dem Logikzelle jedoch einen zweiten Temp-Eingang, kann ich die Logik aufgrund eines Fehlers nicht mehr starten.

Hat jemand eine Idee, warum? Und wie ich es umgehen kann.

Hallo Sven,

wunderbar.

Da am Ende des Tages alles ausfallen kann, ist es sehr wichtig, dass Regelungen nicht gegen einen Anschlag (alles auf oder alles zu) fahren, nur weil ein Sensor ausgefallen ist.


Vorschläge:

- Bei Heizungen kann man sich bei Ausfall eines Sensors auch der Werte aus anderen Räumen bedienen, es ist - wenn nicht gerade das Fenster auf ist - meist kein großer Unterschied - oder dem Mittelwert aller Werte. (d.h. man hat eine Logik, welche die Mittelwerte berechnet und diese als "Not-Ist-Temperatur" dem eigentlichen RTR zur Verfügung stellt, für den Fall, das vom eigentlich Ist-Wert kein Datum mehr kommt.

- Bei bei Ausfall aller Sensoren könnte man bei Heizungen - als eine Art Notprogramm - den Mittelwert der Ventilstellungen der letzten Tage senden


lg

Stefan

StefanW hat geschrieben: ↑So Sep 15, 2019 8:09 am auch der Werte aus anderen Räumen bedienen, es ist - wenn nicht gerade das Fenster auf ist...

... oder die Tür zu!

Hi Sven,

Robosoc hat geschrieben: ↑So Sep 15, 2019 7:33 am Hat jemand eine Idee, warum? Und wie ich es umgehen kann.

Die VAR<...!?> Darstellung ist ein Platzhalter für eine Reihe mehrerer Levels.
Und das klappt nur richtig an Stellen, an denen eine variable Anzahl von Levels angeben werden kann.
Wie z.B. beim Statistic Modul: ein Array mit beliebig vielen Eingängen:
["Statistic",["$VAR<TempIn!>"],0,0,"$Controlled",0]

Das Modul Monoflop erwartet keine variable Anzahl von Levels. Darum geht das hier nicht.
["Monoflop","$Trigger","$Reset","$State","$Time",1]

Aber es kommt noch schlimmer:
Als Trigger wird ein Boolscher Wert erwartet, also nur True/False.
Wenn du hier einen Float-Wert verwendet, kommt es zu einer impliziten Typumwandlung, d.h. der Wert 0.0 wird zu False und alles ungleich 0.0 wird zu True.
Mit anderen Worten, deine Sensorausfall-Überwachung funktioniert so nicht.

Eine einfache Überwachung, die nur auswertet, ob irgendein Wert die Logik regelmäßig triggert wäre folgende:
["Monoflop","$KonstTrue",0,"$internStatus","$watchdogTime",1] // mit $KonstTrue fest auf true

Dann würde der Watchdog zuschlagen wenn eine "$watchdogTime" lange kein Trigger die Logik angestoßen hat.

Alles klar, danke für die ausführliche Antwort.
Vollständig verstanden.

@Robert_Mini : Ich glaube die Antwort kann Teil des KB-Kapitel 4.6.6 werden, also im Abschnitt zu Monoflop...was meinst Du?

@S. Kolbinger
Hallo Stefan,

kann man
A) mit irgendeinem Baustein auswerten, wieviele Levels ein Anwender einer flexiblen Variable angelegt hat
z.B. und

B) kann man gezielt eine Variable aus einem solchen Array auslesen?
z.B.

Hallo Sven,

leider nein!
Das "$VAR<...!?>"-Konstrukt ist nur für gleichartige, austauschbare Levels gedacht, bei denen die Reihenfolge egal ist.
Aber bei der Auswahl eines bestimmten Levels könntest du evtl. über einen Mutliplexer gehen. Dafür sollte aber die Anzahl der Eingänge bekannt sein.

Ja, das war auch schon meine Idee. Ich überlege mir mal was.

Ich hätte glaube ich eine Idee, wie man Sensorausfälle über fehlende Telegramme auch bei variablen Levels umsetzen könnte. Aber das wird eine ziemliche Bausteinschlacht aus

Polynom, Statsistic, Ratio, Monoflop oder Stopuhr, Counter und AND's (also recht viele integer und float operationen). Dazu kommen ja ohnehin noch die PID Regler, Limiter, Polynom Bausteine aus dem Skalierten PID-Baustein von S. Kolbinger.
Wenn man sowas dann x mal (in meinem Fall vermutlich >22x) ausführt, würdet Ihr dann erwarten, dass ich damit schon nennenswert Leistung meines TWS verbrauche?

Andere Frage:
Ist durch Euch eine in der LE auswertbare Fehlererkennung von 1-wire Sensoren konkret geplant? Dann würde ich mir eine Umsetzung im LE jetzt sparen, weil ich damit zu 95% 1-wire Sensoren überwachen wollen würde.

Willst du auch den Fall erkennen, dass der „teildefekte“ Sensor falsche Werte weiterschickt?

Ansonsten Sensoren alle 10min zyklisch Senden und mit pegelgetriggerten Timer kombinieren. Dabei am Eingang ein “in Bereich” => macht die float => bool Umwandlung und zusätzliche Plausibilisierung!

Hab ich was übersehen?

Lg
Robert