ElabNET Technik Forum

S. Kolbinger hat geschrieben: ↑Fr Dez 27, 2019 6:40 pm versuch es mal damit:

Danke Stefan, deine Logik funktioniert einwandfrei.



Ich habe die verschiedenen Zustände mit dieser Logik mal durchgetestet:
Der Ausgang verhält sich genauso, wie er es soll (außer dass die Interlock-Zeit erst nach dem Impuls gestartet wird, aber das ist hierbei egal).


Frage:

Das was ich aber nicht verstehe und wahrscheinlich auch mit der Erklärung von @Matze76 zusammenhängt ist, warum sich bei dem rechten rot markierten Bereich der Start_Pulse auf 1 bleibt, obwohl der Interlock den AND eigentlich sperrt.

Ich schätze mal dass die Erklärung hierzu diese ist:

Matze76 hat geschrieben: ↑Sa Dez 28, 2019 9:21 am Durch das Ausschalten von Timer 2 ist zwar die AND-Bedingung wieder erfüllt, die Änderung des Werts der internen Variable triggert aber die Logik nicht neu an. Von daher passiert nichts weiter.

Es erklärt sich damit, warum meine Logik mit 3 einzelnen Bausteinen funktioniert, eben weil die internen Signale von einer Custom-Logik (welche die Logik selber nicht erneut triggern) dann keine internen Signale mehr sind, sondern externe Trigger-Signale für die anderen Logiken.

Mein Gedankenfehler war wieder aus der SPS-Welt, wo eine Logik immer zyklisch durchgegangen wird und nicht erst bei einem externen Trigger-Signal.

Was man hier auch verstehen muss ist, dass nach einem Trigger-Eingang die Logik in sich geschlossen zwar weiterläuft bzw. eher linear durchläuft (Timer usw.), aber das letzte Signal nicht mehr rückgeführt zur ersten Logik wird (bei mir zum AND).
Stimmt diese Erklärung für meine Frage? Habe ich es so richtig verstanden?

Edit: Die gesamte Antwort kann diese obige blaue verschwommene Erklärung von mit aber nicht sein, denn wenn es keine Rückführung gibt, dann müsste das Start_Pulse Signal bei der rechten roten Markierung ja immer auf 1 bleiben???

Bitte helft mir hierbei noch auf die Sprünge...

Eraser hat geschrieben: ↑Sa Dez 28, 2019 11:26 am Edit: Die gesamte Antwort kann diese obige blaue verschwommene Erklärung von mit aber nicht sein, denn wenn es keine Rückführung gibt, dann müsste das Start_Pulse Signal bei der rechten roten Markierung ja immer auf 1 bleiben???

Ich versuche es mal zu erklären. Ich hatte da auch sehr viele "Aha"-Effekte in den letzten Monaten

- Ein Trigger startet die Ausführung der Logik
- Die Module (Zeilen) werden durchlaufen. Die Reihenfolge der Module spielt durchaus eine Rolle für das Ergebnis - es ist aber nicht mit der Abarbeitung eines Programms in einer prozeduralen Sprache vergleichbar! Es ist eher eine Priorisierung.

Das heißt: Wenn ein Modul als Output den Wert (Zustand) einer Variable ändert, wirkt sich das auf alle anderen Module aus, in der die Variable als Input verwendet wird - egal an welcher Stelle sie im Code stehen.

Es ist also kein Programmcode, der von Zeile 1 bis Zeile 10 abgearbeitet wird.
Ich würde es mir eher als miteinander in alle Richtungen "verdrahtete" Module vorstellen, die sich über die gemeinsamen Variablen wechselseitig bedingen (Stichwort Elektronikbaukasten).

Dass das AND-Modul nach dem Ablauf von Timer2 dafür sorgt, dass $Start_Pulse wieder true ist, ist deshalb auch nicht als Rücksprung im Sinne einer Sprunganweisung ("goto") zu verstehen.

Das Wechseln von $Start_Pulse auf true müsste nun auch den Timer 1 wieder anstoßen. Da Monoflops in einem "Durchgang" aber nur 1 x ausgeführt werden, passiert das nicht. Die Logik bleibt nun so lange in diesem Zustand, bis wieder ein erneuter Trigger kommt.

(Es gibt aber auch Module, die intern den Trigger für die nächste Ausführung setzen können, z. B. das "Clocksignal").

Matze76 hat geschrieben: ↑So Dez 29, 2019 11:43 am Da Monoflops in einem "Durchgang" aber nur 1 x ausgeführt werden, passiert das nicht. Die Logik bleibt nun so lange in diesem Zustand, bis wieder ein erneuter Trigger kommt.

(Es gibt aber auch Module, die intern den Trigger für die nächste Ausführung setzen können, z. B. das "Clocksignal").

Also kann dann ein Monoflop pro externem Trigger nur einmal intern durchlaufen, korrekt?

Danke für diese wichtige Erkenntnis!


Eine letzte Frage hierzu, die leider für mich noch nicht geklärt ist:

Interessant ist für mich der gekennzeichnete Zeitpunkt.
Zu diesem Zeitpunkt ist Timer 1 (Pulse) gerade abgelaufen und Timer 2 (Interlock) startet (Signal Interlock geht auf 1).
Dieses Interlock müsste aber am AND des Start_Pulse eine 0 erzeugen, da es an einem invertierten Eingang angeschlossen ist, egal was dabei am Input daher kommt. Interessanterweise bleibt Start_Pulse aber auf 1.

Matze76 hat geschrieben: ↑So Dez 29, 2019 11:43 am Wenn ein Modul als Output den Wert (Zustand) einer Variable ändert, wirkt sich das auf alle anderen Module aus, in der die Variable als Input verwendet wird - egal an welcher Stelle sie im Code stehen.

Dadurch müsste sich der Interlock auf das AND eigentlich auswirken, oder was verstehe ich noch immer nicht?

Eraser hat geschrieben: ↑So Dez 29, 2019 6:33 pm Dadurch müsste sich der Interlock auf das AND eigentlich auswirken, oder was verstehe ich noch immer nicht?

Ja, das hätte ich auch erwartet... Und nach meinen bisherigen Erkenntnissen war das (vermeintlich) auch immer so.
Aber du hast Recht, ich habe es selber auch noch einmal bei mir nachvollzogen:

- Bei Anlauf von Timer2 wird $interlock true. Die AND-Bedingung wird dadurch eigentlich false, $Start_Pulse bleibt aber true.

Bei Ende von Timer2 geht $interlock auf false. Und dann ändert sich auch $Start_Pulse. Es geht aber auf false, obwohl jetzt die AND-Bedingung true ist.

Das hat mich etwas verwirrt

1.) Ich konnte mit einer anderen Logik (mit einer OR-Bedingung) nachstellen, dass es tatsächlich eine Rolle spielt, ob die Anweisung im Code vor oder nach dem Monoflop steht. Steht sie davor, beeinflusst das Ein-/Ausschalten durch den Monoflop sie wie hier scheinbar nicht. Nur wenn sie danach steht, beeinflusst der Monoflop-Output die AND/OR-Bedingung. Sorry, wenn ich da für Verwirrung gesorgt habe, aber offensichtlich habe ich doch noch nicht alles durchdrungen...

2.) Was ich hier aber nicht verstehe ist, warum am Ende von Timer2 ($Interlock wird false) die Variable $Start_Pulse dann doch noch false wird. Wodurch wird das ausgelöst? Die AND-Bedingung passt nicht, und sonst gibt es doch kein Modul, das $Start_Pulse im Output hat?

Irgendwie bin ich erleichtert, dass es nicht nur mir so geht...

Ich glaube da kann nur S.Kolbinger Licht ins Dunkel bringen... (oder aber vielleicht jemand anderer?)

Matze76 hat geschrieben: ↑So Dez 29, 2019 9:02 pm 1.) Ich konnte mit einer anderen Logik (mit einer OR-Bedingung) nachstellen, dass es tatsächlich eine Rolle spielt, ob die Anweisung im Code vor oder nach dem Monoflop steht. Steht sie davor, beeinflusst das Ein-/Ausschalten durch den Monoflop sie wie hier scheinbar nicht. Nur wenn sie danach steht, beeinflusst der Monoflop-Output die AND/OR-Bedingung. Sorry, wenn ich da für Verwirrung gesorgt habe, aber offensichtlich habe ich doch noch nicht alles durchdrungen...

Schaut doch mal hier:
app.php/kb/viewarticle?a=84

Die Reihenfolge ist wichtig.
Man kann sich das wie eine Signalschaltung vorstellen. Ausgang Baustein 1 => Eingang Baustein 2.
Natürlich mit Verzweigungen und Bypass von Bausteinen etc.

lg
Robert

In der KB ist dies die wichtige Info:

"Alle Module (mit Ausnahme des Moduls "Break") werden in der Reihenfolge, wie sie in der Liste stehen, ausgeführt."

Das würde dann heißen...
-) keine Rückkopplungen von einem späteren Modul in ein früheres Modul, auch nicht bei z.B. AND
-) in meinem Beispiel wird deshalb der Start_Pulse nicht korrekt aktualisiert
-) nach Durchlaufen der ganzen Logik wird das AND automatisch rückgesetzt
-) man muss eine Custom-Logic als einen reinen Durchlauf verstehen, bei dem ein Ausgangsergebnis von einem Modul nur in nachfolgenden Modulen verwendet werden kann

Bitte um Klarstellung

Danke Robert. Ja, da stehts, die Module werden in der vorgegebenen Reihenfolge abgearbeitet, und auch der Schaltplan - soweit ich ihn lesen kann - zeigt das. So baue ich ja auch meine Logiken auf. Irgendwie hatte sich trotzdem in meinem Kopf festgesetzt, dass die Ausgangs-Signale innerhalb eines "Durchlaufs" auch wieder in die andere Richtung wirken können. Ich habe versucht, die Logik zu finden, die mich zu dieser Annahme geführt hat - es gibt sie aber nicht. Da wo ich lange gebastelt hatte, weil sich ändernde Werte von Variablen unerwartete Auswirkungen hatten, ging es immer nur in eine Richtung, oder es lag ein erneuter Trigger der ganzen Logik zugrunde.

OK, das AND-Modul setzt $Start_Pulse also nach Ablauf von Timer1 nicht auf false.

Aber was nun $Start_Pulse dann am Ende des gesamten "Durchlaufs" auf false wechseln lässt, ist mir immer noch nicht klar. Es werden doch nicht einfach so am Ende die Variablen wieder auf ihren Ausgangswert gesetzt ?

Hallo Wolfgang, hallo Matthias,

erst mal ein gutes neues Jahr,
zweitens sorry, dass ich mich nicht schon früher in die Diskussion einschalten konnte.
Euren vielen guten Ratschläge, doch auch mal ein paar Tage so richtig abzuschalten, habe ich befolgt.
Ganz nebenbei, das war auch dringend notwendig . Aber nun frisch ans Werk.

Im allgemeinen habt ihr die Antworten schon fast alle selbst gegeben.

1. Wird eine Logik-Zelle getriggert, werden alle Module der Reihenfolge nach abgearbeitet
2. Jedes Modul wird pro Durchlauf (Trigger-Ereignis) nur einmal ausgeführt.
3. Ein Durchlauf kann nur durch ein Break-Modul oder durch einen Fehler (z.B. Division durch Null, bei Ratio-Modul) vorzeitig abgebrochen werden.
4. Ändert das k. Modul den Wert eines Levels, so steht für den aktuellen Durchlauf der neue Wert den Modulen k+1 .. n zur Verfügung.
   Die Module 1 .. k-1 sehen den neuen Wert erst beim nächsten Durchlauf (nach neuem Trigger-Ereignis).
5. Mögliche Trigger-Ereignisse sind:
   1. Werte an den Eingängen (Abhängig von ein Trigger-Filtern: A,C)
   2. Ablauf von Timern, die von den eigenen Modulen (Clock, Monoflop, Cron, Wakeup) gestartet wurden.

Auch der Timer-Trigger 5.b. bewirkt einen normalen Durchlauf der Module von 1..n und verändert nicht die Reihenfolge.
Erst wenn das Modul, das den Timer angestoßen hat, an der Reihe ist, wird der Ausgangs-Level (Timer-Running-Flag) angepasst.
Es gilt auch hier die Aussage von Punkt 4.

Nun lässt sich auch diese Frage beantworten:

Matze76 hat geschrieben: ↑So Dez 29, 2019 11:36 pm Aber was nun $Start_Pulse dann am Ende des gesamten "Durchlaufs" auf false wechseln lässt, ist mir immer noch nicht klar. Es werden doch nicht einfach so am Ende die Variablen wieder auf ihren Ausgangswert gesetzt ?

Der Ablauf des Interlock-Timers startet einen neuen Durchlauf. $Interlock ist noch nicht verändert. Das And-Modul nimmt noch den alten Wert vom letzten Durchlauf (true) und berechnet damit $Start_Pulse zu false.
Erst danach, wenn das Modul "Monoflop" des Interlock-Timers an der Reihe ist, wird $Interlock auf false gesetzt, und die Logik-Zelle ist wieder "scharf" geschaltet für die nächste positive Flanke am Eingang.

Hallo Stefan,

danke für die hilfreiche Erklärung. Schön dass ihr die freie Zeit zum Erholen nutzen konntet.

Beste Grüße
Jens