ElabNET Technik Forum

Verfasst: **Sa Nov 02, 2019 12:27 pm**

@Robert_Mini vielleicht sollten wir den verschiedenen Möglichkeiten der Alternativen zu Wenn-Dann eine eigene Seite in der knowledge base widmen... Diese Frage werden viele sehr früh haben (ging mir auch anfangs so) :

Für rein boolsche Bedingungen ist hier eine AND logik gut geeinet und ausreichend, wenn der Ausgang numerisch sein soll hilft das mapping.

Für numerische Bedingungen hilft die Eingangsfunktion "wert innrrhalb"

Für customlogiken bietet es sich meiner Meinung nach an immer multiplexer zu verwenden, egal ob bool oder numerische ein- und Ausgänge und egal ob zwei oder mehr Zustände und egal ob 1 oder mehr Ausgänge.

Else gibt es nicht, hier bietet sich an die negative Bedingung noch einmal anzulegen

Verfasst: **Sa Nov 02, 2019 12:28 pm**

Hallo Martin,

die Lösung von @Robosoc finde ich auch sehr gelungen.

Der Vollständigkeit halber wollte ich noch eine weitere Möglichkeit zeigen, wie du solche IF_THEN_ELSE- ,bzw. SWITCH_CASE_DEFAULT-Konstrukte nachbilden kannst:

Code: Alles auswählen

{
    "Level": [
        ["$In_val","integer",0],
        ["$Val_offen","integer",0],
        ["$Val_gekippt","integer",1],
        ["$Val_geschlossen","integer",2],
        ["$Stat_offen","bool",false],
        ["$Stat_gekippt","bool",false],
        ["$Stat_geschlossen","bool",false],
        ["$Stat_Stoerung","bool",false]
    ],
    "Module": [
        ["Limiter","$In_val",0,"$Stat_offen",["$Val_offen","$Val_offen"]],
        ["Limiter","$In_val",0,"$Stat_gekippt",["$Val_gekippt","$Val_gekippt"]],
        ["Limiter","$In_val",0,"$Stat_geschlossen",["$Val_geschlossen","$Val_geschlossen"]],
        ["Or",["$Stat_offen","$Stat_gekippt","$Stat_geschlossen"],"-$Stat_Stoerung"]
    ],
    "Input": [
        ["In","Statuswert des Fensterkontaktes","$In_val","c"]
    ],
    "Output": [
        ["offen","wahr wenn offen","$Stat_offen","c"],
        ["gekippt","wahr wenn gekippt","$Stat_gekippt","c"],
        ["geschlossen","wahr wenn geschlossen","$Stat_geschlossen","c"],
        ["Störung","wahr bei keinem der drei anderen Zuständen","$Stat_Stoerung","c"]
    ]
}

Hierzu verwendet man den boolschen Ausgang von "Limiter", der anzeigt, wenn der Eingangswert innerhalb der Grenzen liegt.
Damit lassen sich auch beliebige Eingangswerte (die nicht sequenziell von Null hochzählen) leichter bearbeiten.
Zusätzlich habe ich den "Störung"-Status dahin gehend modifiziert, dass er auch nicht plausible Werte (kleiner 0 oder größer 3) abdeckt.

Advenoni hat geschrieben: ↑Sa Nov 02, 2019 10:24 am Evtl. ist es auch beruflich bedingt, dass ich solche Sachen ganz gerne in eigenen Bausteinen mache, gerade wenn das ganze mehrfach verwendet wird.

... und mit dem "duplicate logic"-Button wird das auch unterstützt.

Verfasst: **Mo Nov 04, 2019 6:30 am**

Hier noch ein Verweis auf einen anderen Threat, der das Thema IF-Then oder Wenn-Dann behandelt hat. Dort verweise habe ich geschrieben, dass das Mapping von Standardbausteinen (welches ja auch quasi ein If-Then ist) ebenfalls mit Multiplexern gelöst ist.

viewtopic.php?f=24&t=1420

Verfasst: **Di Nov 05, 2019 8:14 pm**

Else gibt es nicht

mit einer "And" + "Latch" -Kombination gibt es eine Alternative zum Multiplexer, mit der man auch ein ELSE ähnlich zur vielleicht gewohnten Struktur abbilden kann.

Beispiel:
3 bool`sche Eingänge ($Eingang1, $Eingang2, $Eingang3)
1 Ausgang ($Ausgang).
3 mögliche Werte, die je nach Bedingung auf den Ausgang gehen sollen : $Wert1, $Wert2, $Wert3.

Diesen Pseudo-Code in IF/ELSE IF/ELSE...:

Code: Alles auswählen

IF $Eingang1=true AND $Eingang2=true THEN $Ausgang = $Wert1
ELSE IF $Eingang1=false AND $Eingang2=true AND $Eingang3=true THEN $Ausgang= $Wert2
ELSE $Ausgang = $Wert3
END IF

... kann man so in Custom Logik abbilden:

Code: Alles auswählen

// Zuerst kommt das ELSE:

[  "Latch", "$Wert3", "$Ausgang", "$KonstanteTrue", 0  ]   =>  Schiebt grundsätzlich $Wert3 auf den Ausgang

// Dann folgen die IF / ELSE IF Bedingungen. => "And" prüft die Bedingung und setzt bei Erfüllung die jeweilige Hilfs-Variable ($Bedingung..) auf true. Der zugehörige "Latch" schiebt dann den gewünschten  Wert auf den Ausgang und übersteuert damit den grundsätzlichen Wert.

[  "And",  [ "$Eingang1", "$Eingang2" ], "$Bedingung1" ],
[  "Latch", "$Wert1", "$Ausgang", "$Bedingung1", 0 ],

[  "And",  [ "-$Eingang1", "$Eingang2","$Eingang3" ], "$Bedingung2" ],
[  "Latch", "$Wert2", "$Ausgang", "$Bedingung2", 0 ],

Verfasst: **Di Nov 05, 2019 8:59 pm**

würde ich nicht so sehen, das ist ja kein echtes Else, sondern entspricht dem Fall, dass man die Zuweisung ($Ausgang = $Wert3) vor dem If-Block schreibt. Es wird ja in jedem Fall ausgeführt. Und wenn Du damit tatsächlich direkt auf einen Ausgang einer Logik legst, wird das auch erstmal gesendet, auch wenn Millisekunden später noch etwas anderes im If-Block definiert werden könnte.

Auch das AND + Latch ist meiner Ansicht nach kein elseif, sondern nur ein neues If. Es wird ja auch in jedem Fall berechnet und nicht nur dann, wenn das allererste Latch nicht getriggert hat.

Verfasst: **Di Nov 05, 2019 9:16 pm**

wird das auch erstmal gesendet,

Nein, ich denke, dass nach dem Triggern erst der gesamte Code durchlaufen wird und am Ende einmal der Ausgang beschrieben wird.

Jedenfalls sehe ich das im Doktormodus in Grafana so. Aber ich lasse mich da auch gerne eines Besseren belehren.

Auch das AND + Latch ist meiner Ansicht nach kein elseif, sondern nur ein neues If

Das mag sein, es ist ja auch nicht 1:1 übersetzbar. Aber im Endeffekt ist es hier doch das selbe ob ich sage:

IF a=1 THEN tue dies
ELSE IF a=2 THEN tue das
END IF

oder

IF a=1 THEN tue dies.
IF a= 2 THEN tue das.

Verfasst: **Di Nov 05, 2019 9:57 pm**

Matze76 hat geschrieben: ↑Di Nov 05, 2019 9:16 pm
Nein, ich denke, dass nach dem Triggern erst der gesamte Code durchlaufen wird und am Ende einmal der Ausgang beschrieben wird.

Jedenfalls sehe ich das im Doktormodus in Grafana so. Aber ich lasse mich da auch gerne eines Besseren belehren.

Doch, das kann ich mit absoluter Sicherheit sagen. Da gab es auch schon einen anderen Threat zu, wo S. Kolbinger dies bestätigt hat. Der Timberwolf arbeitet im LE rein Zeilenbasiert, jede Zeile wird direkt ausgeführt (und wenn eine Zeile einen Ausgang beschreibt, wird dies auch sofort gemacht, deshalb werden Zeilen vor einem Break auch ausgeführt (steht ja inzwischen auch so in der KB). Es gibt kein Prozess-Eingangsabbild und -Ausgangsabbild wie bei zyklisch arbeitenden SPS‘en wie eine Simatic.

Wird eine Logik getriggert werden die Module Zeile für Zeile sofort abgearbeitet.

Im Dok-Modus wirst Du es vermutlich nicht sehen, weil die Anzeige im Browser ja nur mit einer gewissen Rate geupdated wird. Sowas kennt man auch von anderen Web-Visualisierungen. Du müsstest aber in TimeSeries oder Bustelegrammen nachvollziehen können , dass es ein Zwischensenden gibt.

Verfasst: **Di Nov 05, 2019 10:02 pm**

Matze76 hat geschrieben: ↑Di Nov 05, 2019 9:16 pm Das mag sein, es ist ja auch nicht 1:1 übersetzbar. Aber im Endeffekt ist es hier doch das selbe ob ich sage:

IF a=1 THEN tue dies
ELSE IF a=2 THEN tue das
END IF

oder

IF a=1 THEN tue dies.
IF a= 2 THEN tue das.

Ja, sehe ich genauso. Das wollte ich eigentlich auch mit dem Satz „Else gibt es nicht, hier bietet sich an die negative Bedingung noch einmal anzulegen“ ausdrücken, aber Du hast es deutlich besser beschrieben. Und das wäre vielleicht schon gut für die Knowledge

Wichtig ist nur, dass es eben kein else ist. D.h. das Zweite if wird auf jeden Fall ausgeführt und nicht nur dann, wenn das erste If = false war. In Deinem Beispiel macht es keinen Unterschied, aber in vielen anderen Fällen schon. Mit einem Else beabsichtigt man ja häufig, dass der nachfolgende Teil nur ausgeführt werden soll, wenn der erste Teil nicht ausgeführt wurde.....und da ja jede Zeile ausgeführt wird und nicht nur das Endergebnis ist das Funktionsrelevant....bla bla bla ich denke es ist eh schon klar. Sorry.

Verfasst: **Di Nov 05, 2019 10:11 pm**

Hallo zusammen,

Robosoc hat geschrieben: ↑Di Nov 05, 2019 9:57 pm Doch, das kann ich mit absoluter Sicherheit sagen. Da gab es auch schon einen anderen Threat zu, wo S. Kolbinger dies bestätigt hat. Der Timberwolf arbeitet im LE rein Zeilenbasiert, jede Zeile wird direkt ausgeführt (und wenn eine Zeile einen Ausgang beschreibt, wird dies auch sofort gemacht, deshalb werden Zeilen vor einem Break auch ausgeführt (steht ja inzwischen auch so in der KB). Es gibt kein Prozess-Eingangsabbild und -Ausgangsabbild wie bei zyklisch arbeitenden SPS‘en wie eine Simatic.

Wird eine Logik getriggert werden die Module Zeile für Zeile sofort abgearbeitet.

hier scheint es noch Klärungsbedarf zu geben.

Grundsätzlicher Ablauf der Berechnung einer Logik-Zelle:

Ein Trigger (entsprechend der Trigger-Optionen an den Eingängen) löst die Ausführung/Abarbeitung der Logik-Zelle aus.
Alle Module werden der Reihenfolge nach ausgeführt.
Alle Ausgänge werden entsprechend der Sende-Option an den Dispatcher(DOS) gesendet

hier auch nochmal klargestellt: viewtopic.php?f=24&t=1601&p=16821#p16821

Sorry, falls es hier zu Missverständlichkeiten gekommen ist.

Verfasst: **Di Nov 05, 2019 10:21 pm**

Danke, dass Du mich hier gleich korrigierst. Da habe ich ganz offensichtlich ein ziemliches Missverständnis im Kopf gehabt, was aus folgendem Threat kam: viewtopic.php?f=24&t=1232&p=12455&hilit=SPS#p12455

Matthias (Matze67), bitte entschuldige dass ich Dich mit einem Fehler korrigiert habe.

Ich werde für heute Schluss machen und mir in Ruhe morgen anschauen, was ich damals falsch verstanden habe bzw. was an dem Beispiel damals anders war so dass meine Behauptung da gestimmt hat.

ElabNET Technik Forum

Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert

Re: Binärausgänge abhängig vom Zahlenwert