FUP: Signal zurückführen / manuelles verbinden?

[OChatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,
gaaaanz dumme Noob-Frage, aber ich habe es bislang weder im Programm noch tutorials so wirklich herausfinden können.
Wie lässt sich denn eine als Linie dargestellte Verbindung von Bausteinen herstellen, die nicht mit dem Anhängen am jeweils vor/nachgelagerten Baustein zu machen ist?

Einfachstes Beispiel: ein RS-Baustein soll nach Zeitablauf sich zurücksetzen. Okay, also Anzugverzögerung an den RS-Ausgang. Aber wie nun das verzögerte Signal zurück zum R-Eingang?
Funktional scheint es ja zu klappen, gleiche Variablenamen am Aus- und Eingang zuzuweisen. Aber lässt sich das auch als rückgeführte Linie darstellen? Wenn ja, wie verlegt man diese?

Gleiches Problem bei mehrfacher Nutzung eines Eingangssignals, wenn die Zweige später vereinigt werden sollen. Klar, kann man von hinten her aufdröseln, bis man vom Ausgang verzeigend alle relevanten Zweige hat, aber dann ist nicht auf anhieb ersichtlich, dass der gleiche Eingang mehrere Zweige durchläuft. Und irgendwie scheint es mir nicht ganz Sinn der Sache zu sein, die meiste Überlegung in die geschickteste Abfolge von Block-Einfügungen zur schönsten Darstellung zu verwenden.

Muss doch irgendwie eine elegantere Lösung geben - nur ist sie mir nicht ersichtich.

 

[Heinileini]

Und irgendwie scheint es mir nicht ganz Sinn der Sache zu sein, die meiste Überlegung in die geschickteste Abfolge von Block-Einfügungen zur schönsten Darstellung zu verwenden.

Natürlich geht es nicht darum, um jeden Preis die "schönste" Darstellung hineinzupflegen. Und selbstverständlich sollte man bemüht sein, eine übersichtliche, leicht zu durchschauende Darstellung zu finden.
Die "rückgeführte Linie" deutet darauf hin, dass Du etwas darzustellen versuchst, was nicht den Tatsachen entspricht: der Ausgang des Timers wirkt nicht im selben Zyklus auf das RS-FF zurück, sondern erst im nächsten PLC-Zyklus. Deshalb ist die direkte Verbindung mit einer Linie nicht zulässig. Bei der LOGO-Steuerung wäre im FunktionsPlan die Verbindung per Linie zulässig, aber nur, wenn ein Merker oder Ausgang dazwischen geschaltet ist. Aber Eingang und Ausgang eines Merkers bzw. Ausgangs stellen nicht den Zustand im selben Zyklus dar, was man nicht unbedingt einleuchtend finden muss. Geschmackssache. Käme aber vermutlich Deinen Vorstellungen entgegen.
Welches Problem Du mit mehrfach genutzten Eingängen hast, verstehe ich nicht so ganz. Vermutlich hast Du hier auch die LOGO-Denkweise drauf, die es nicht zulässt, dass im FunktionsPlan dieselben Eingänge mehrfach auftreten dürfen.
Die üblichen Systeme sind aber anders als die LOGO-FunktionsPlanDarstellung. Und, dass die LOGO-FunktionsPlanDarstellung nicht zaubern kann, siehst Du schon, wenn Du einen LOGO-FunktionsPlan in die KontaktPlanDarstellung wandeln lässt.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die elegante Lösung ist, daß SPS-Programme zyklisch arbeiten. Wenn die Programmabarbeitung (von oben nach unten) unten angekommen ist, dann wird die Abarbeitungen von oben wiederholt. Und in diesem nächsten Zyklus wird der Zustand verarbeitet, den der Timer oder die Variable dann hat, z.B. der Zustand der im vorherigen Zyklus zuletzt an die verknüpfte Variable zugewiesen wurde - so schließt sich der Kreis bzw. Linie.

Ein Eingang "durchläuft" nicht mehrere Zweige, sondern dessen Zustand wird in mehreren Zweigen verknüpft - und das kann man tun so oft wie man will.

Harald

 

[Heinileini]

Wenn die Programmabarbeitung (von oben nach unten) unten angekommen ist, ...

Genau das ist es, was in einem FunktionsPlan à la LOGO total verloren geht bzw. gehen kann.
Da gibt es nicht nur 'von oben nach unten', sondern u.a. von links nach rechts, von unten rechts noch oben links u.s.w., kurzum, von überall nach überall.
Das ist noch beherrschbar, solange das komplette Programm "auf einem Blatt" darstellbar ist - also bei MiniProgrammen.
Wer auf dem Wege über die LOGO-FunktionsPlanDarstellung in die SPS-Programmierung einsteigt, der wird in FunktionsPlänen anderer Systeme den vermeintlichen "Komfort" der LOGO vermissen.
Und er wird merken, dass er über die ArbeitsWeise einer SPS noch nicht so wirklich viel gelernt bzw. sich falsche Vorstellungen angewöhnt hat.
Für Systeme, die auch für komplexere Programme geeignet sein sollen, ist die LOGO-Philosophie ungeeignet. Man würde vor lauter VerbindungsLinien die verhältnismässig wenigen "Blöcke" nicht mehr sehen.

Positiv möchte ich vermerken, dass der TE immerhin um eine übersichtliche Darstellung bemüht ist.
Dass FunktionsPläne nicht automatisch übersichtlich werden, nur weil sie mit den Mitteln einer LOGO dargestellt wurden, dafür gibt es in diesem Forum genügend Beispiele.
Da bleibt oft viel Raum, die VerbindungsLinien nachzupflegen.

 

[Blockmove]

Genau das ist es, was in einem FunktionsPlan à la LOGO total verloren geht bzw. gehen kann.
Da gibt es nicht nur 'von oben nach unten', sondern u.a. von links nach rechts, von unten rechts noch oben links u.s.w., kurzum, von überall nach überall.
Das ist noch beherrschbar, solange das komplette Programm "auf einem Blatt" darstellbar ist - also bei MiniProgrammen.
Wer auf dem Wege über die LOGO-FunktionsPlanDarstellung in die SPS-Programmierung einsteigt, der wird in FunktionsPlänen anderer Systeme den vermeintlichen "Komfort" der LOGO vermissen.
Und er wird merken, dass er über die ArbeitsWeise einer SPS noch nicht so wirklich viel gelernt bzw. sich falsche Vorstellungen angewöhnt hat.
Für Systeme, die auch für komplexere Programme geeignet sein sollen, ist die LOGO-Philosophie ungeeignet. Man würde vor lauter VerbindungsLinien die verhältnismässig wenigen "Blöcke" nicht mehr sehen.

Positiv möchte ich vermerken, dass der TE immerhin um eine übersichtliche Darstellung bemüht ist.
Dass FunktionsPläne nicht automatisch übersichtlich werden, nur weil sie mit den Mitteln einer LOGO dargestellt wurden, dafür gibt es in diesem Forum genügend Beispiele.
Da bleibt oft viel Raum, die VerbindungsLinien nachzupflegen.

Heini du hast im Prinzip Recht, aber das was du als Logo-Philosophie nennst, findest du auch als CFC in großen Systemen.
In der Gebäudetechnik oder bei Regelungen hat das System doch viele Vorteile im Vergleich zu reinem FUP.
Es gilt halt auch hier: Das Werkzeug muss zur Aufgabe passen.

 

[OChatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Heini du hast im Prinzip Recht, aber das was du als Logo-Philosophie nennst, findest du auch als CFC in großen Systemen.
In der Gebäudetechnik oder bei Regelungen hat das System doch viele Vorteile im Vergleich zu reinem FUP.
Es gilt halt auch hier: Das Werkzeug muss zur Aufgabe passen.

Moin,

ja CFC ist das richtige Stichwort, was dem entspricht, was ich eigentlich gesucht habe. Hätte nur damit gerechnet, dass das auch irgendwie unter Funktionsplan läuft bzw. es dort noch eine mir nicht ersichtliche Möglichkeit zu dies Linien gibt.

Was die Übersichtlichkeit anbelangt:
Hmm, bei Blattübergreifenden Plänen kann ich das in Teilen nachvollziehen. Aber wären dann nicht Beschriftungsfahnen an den Blattgrenzen die sinnigste Variante? Oder Variablenname zusätzlich zur Linie am Eingang? Erscheint mir doch schon hilfreich zu sehen, mit welchen anderen Zweigen da eine Interaktion stattfindet.

Ja, die zyklische Arbeitsweise ist grundsäzlich bekann und führte auch schon zu etwas Grübelei, da ein vorrangig rücksetzendes FlipFlop in meiner Überlegung zu einem kurzzeitigen Rückfall und damit Timerneustart führte.. Zwar hab ich da ne Umgehung gefunden, allerdings wenn ich so länger drüber Nachdenke - komme ich zu einer weiteren Frage:
Werden die internen Variablen ebenfalls im Eingangsabbild erfasst und gefreezt? Und heißt das dann, dass eine Kette von sagen wir mal 10 Blöcken auch 10 oder gar noch mehr (externe) SPS-Takte benötigt? Oder wird ein Abbild erzeugt, dann alle Blöcke abgearbeitet, bis auch der letzte seinen neuen Endzustand hat und dann Ausgegeben? Wie verhält es sich dann aber mit Signalen mit unterschiedlich langem Laufweg? Meinetwegen einmal über doppelte Negierung und einmal unverändert auf ein XOR? Ergibt das am a) SPS-Ausgang b) auf interner Verbindung (z.B. zu einem FlipFlop-Eingang oder Flankenbaustein) einen kurzen Wischer?
Wenn nein, weil solch interne Konkurrenzen abgewartet werden? Oder weil der Compiler die doppelte Negation wegoptimiert?
Falls letzteres, wird das ganze XOR auch wegoptimiert? Und ändert sich was, wenn hinter der ersten Neation eine Verzweigung folgt, das invertierte Signal also anderweitig zwingend gebraucht wird?


besten Dank für Erklärungen,
OChatter

 

[PN/DP]

Du darfst Dir den Funktionsplan nicht wie eine elektronische Schaltung vorstellen, wo die Signale unterschiedlich schnell vorwärts kommen können. In einem Funktionsplan gibt es keine Signallaufzeit oder "interne Konkurenzen". Es gibt aber eine Abarbeitungsreihenfolge und deshalb auch ein "vorher" und "danach".

Die grafische Programmdarstellung wird in ein sequentielles Programm compiliert, was nur eine komplett-Durchlaufzeit/Abarbeitungszeit hat. Ob da Anweisungen oder Anweisungsketten mit unterschiedlich langen Ausführungszeiten enthalten sind ist unerheblich. An Stellen wo Signalzweige verknüpft werden, werden erst beide Zweige abgearbeitet und danach deren Endzustände verknüpft. Bei einem Block mit mehreren Eingängen werden erst alle Eingangszweige abgearbeitet und das Ergebnis jeweils in die Eingangsparameter gespeichert, und erst danach wird der Block aufgerufen, der dann die Eingangsparameter verarbeitet.


Bei FlipFlops gibt es je nach SPS verschiedene Implementierungen.
Wenn das FlipFlop als Funktionsblock implementiert ist, dann funktioniert es wie gerade beschrieben (Eingangssignale in Eingangsparameter speichern und danach den Funktionsblock-Code aufrufen).

Bei einigen SPS bewirkt der obere Zweig ggf. sofort ein Setzen oder Rücksetzen des FlipFlops, und der untere Zweig danach noch ein eventuelles Rücksetzen oder Setzen des FlipFlop, so daß das FlipFlop während dem Programmdurchlauf kurzzeitig bis zu zweimal seinen Zustand ändern kann, was aber nur bei Multitasking ein Problem ist (z.B. bei höherpriorer HMI-Kommunikation), oder wenn man im unteren Zweig den Zustand des FlipFlops verwendet (was man nicht tun sollte).

Es gibt auch SPS, wo das FlipFlop als Befehlssequenz mit Selbsthaltung implementiert ist, die in nur einer Zuweisung an das FlipFlop endet. Da schaltet das FlipFlop in einem Durchlauf höchstens einmal.

Der Signalweg hinter dem FlipFlop wird in allen Implementierungen erst nach beiden Eingangszweigen bearbeitet - verknüpft also den letzten/endgültigen Zustand des FlipFlop.

Diese grafische FUP-Darstellung

                    +-----+    FlipFlop
    Setzbedingung_1-|  &  |    +------+
    Setzbedingung_2-|     |----|S     |
                    +-----+    |      |
                               |      |
                    +-----+    |      |   Ausgang
Rücksetzbedingung_1-| >=1 |    |      |   +-----+
Rücksetzbedingung_2-|     |----|R    Q|---|  =  |
                    +-----+    +------+   +-----+

wird in eine Anweisungssequenz compiliert.

Implementierung als Funktionsblock

U Setzbedingung_1
U Setzbedingung_2
= FlipFlop.S
O Rücksetzbedingung_1
O Rücksetzbedingung_2
= FlipFlop.R
CALL FlipFlop
U FlipFlop.Q
= Ausgang

Implementierung mit S/R-Anweisungen, FlipFlop schaltet evtl. kurzzeitig in "falschen" Zustand

U Setzbedingung_1
U Setzbedingung_2
S FlipFlop
O Rücksetzbedingung_1
O Rücksetzbedingung_2
R FlipFlop
U FlipFlop
= Ausgang

Selbsthalte-Implementierung, FlipFlop schaltet nur in den endgültigen Zustand

U Setzbedingung_1
U Setzbedingung_2
O FlipFlop
UN(
O Rücksetzbedingung_1
O Rücksetzbedingung_2
)
= FlipFlop
U FlipFlop
= Ausgang

Harald

 

[OChatter]

Hi,

Die grafische Programmdarstellung wird in ein sequentielles Programm compiliert, was nur eine komplett-Durchlaufzeit/Abarbeitungszeit hat. Ob da Anweisungen oder Anweisungsketten mit unterschiedlich langen Ausführungszeiten enthalten sind ist unerheblich. An Stellen wo Signalzweige verknüpft werden, werden erst beide Zweige abgearbeitet und danach deren Endzustände verknüpft. Bei einem Block mit mehreren Eingängen werden erst alle Eingangszweige abgearbeitet und das Ergebnis jeweils in die Eingangsparameter gespeichert, und erst danach wird der Block aufgerufen, der dann die Eingangsparameter verarbeitet.

hmm, dann bin ich mal gespannt was da bei solch gegenseitiger Verschachtelung bei rauskommt. Hier mal der Anlass meiner Überlegungen. Gehtmir darum, im Nachgang zur Benutzung eines Badezimmers (gemessen über das Einschalten der Beleuchtung) einen Fensterschließer anzusteuern, sofern denn die Nutzungsdauer auf eine Belüftungerfordernis wie Duschen schließen lässt. Die Automatik soll zudem manuell übersteuerbar sein, und zwar derart, dass per Tippen eine Öffnung/Schließung angestoßen werden kann, die dann im Weiteren wieder dem automatischen Vorgang unterliegt, sofern nicht durch Rasten der manuellen Eingabe eine dauerhafte Festlegung eines Zustands erzwungen wird. Da komme ich auf folgende Schaltungsvariante:

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch für gegenseitige Verriegelung von Ausgängen braucht man keine Rückführungen. Es reicht, direkt vor der Ausgangszuweisung mit dem aktuellen Zustand des jeweils anderen Ausgangs zu verriegeln (Und Not ..). Dann können die Ausgänge schon nicht gleichzeitig Ein sein. Doch bei so einer Relais-Geschichte ist sowieso eher angebracht, eine Mindest-Umschaltpause für Richtungswechsel einzubauen, während der beide Ausgänge Aus sind.

Wenn ich Deine Aufgabe richtig verstanden habe, dann könnte man die Aufgabe etwa so lösen:

                              +---+  M_Lueften   T_Lueften
                       S_Zu --|>=1|   +-----+     +-----+
                T_Lueften.Q --|   |---|R   Q|--+--|TON Q|
                              +---+   |     |  [COLOR="#0000FF"]|[/COLOR]  +-----+
                                      |     |  [COLOR="#0000FF"]|[/COLOR]
              +---+                   |     |  [COLOR="#0000FF"]| T_MotAuf[/COLOR]
   BadLicht -o| & |   +---+           |     |  [COLOR="#0000FF"]|  +-----+[/COLOR]
T_Vorlauf.Q --|   |---|>=1|           |     |  [COLOR="#0000FF"]+--|TON Q|[/COLOR]
              +---+   |   |           |     |  [COLOR="#0000FF"]|  +-----+[/COLOR]
                      |   |   +---+   |     |  [COLOR="#0000FF"]|              +---+[/COLOR]
              S_Auf --|   |---| & |   |     |  [COLOR="#0000FF"]| T_MotAuf.Q -o| & |[/COLOR]
                      +---+   |   |   |     |  [COLOR="#0000FF"]+--------------|   |-> Relais_Auf[/COLOR]
                              |   |   |     |  [COLOR="#0000FF"]|              +---+[/COLOR]
                       S_Zu -o|   |---|S    |  [COLOR="#0000FF"]|  T_MotZu[/COLOR]
                              +---+   +-----+  [COLOR="#0000FF"]|  +-----+[/COLOR]
                                               [COLOR="#0000FF"]+--|TOF Q|[/COLOR]
                                               [COLOR="#0000FF"]|  +-----+[/COLOR]
                                               [COLOR="#0000FF"]|              +---+[/COLOR]
                                               [COLOR="#0000FF"]|  T_MotZu.Q --| & |[/COLOR]
                                               [COLOR="#0000FF"]+-------------o|   |-> Relais_Zu[/COLOR]
                                                              [COLOR="#0000FF"]+---+[/COLOR]
          T_Vorlauf
           +-----+
BadLicht --|TON Q|
           +-----+

(Ich habe kein Codesys und weiß nicht, ob die beiden T_Mot..-Q direkt auf die &-Blocks an den Ausgängen verbunden werden können oder als Variable angebunden werden müssen. Du fragst doch hier für eine Codesys-Steuerung?)

Den blauen Ausgabe-Teil würde ich besser in einen eigenen FB programmieren, evtl. mit gegenseitiger Verriegelung, besser noch mit einer Umschaltpause von einer Richtung in die andere. Vielleicht kann man auch einen fertigen einfachen Jalousie-Baustein verwenden.

Harald

 

[OChatter]

Moin,

Danke für deine Skizze.

T_Vorlauf.Q UND negiertes BadLicht sorgt dann durch die zyklische Arbeitsweise für einen Impuls beim Ausschalten des Lichts?

Ist das FlipFlop mit Priorität auf R oder S? Wenn ersteres, wie verhält sich das Programm bei dauerhaft anliegendem S_Auf wenn die Verzögerung von T_Lueften abläuft? Wird dann der R-Eingang für einen Zyklus aktiv und resettet das FF, während dieses wiederum im nachfolgenden Zyklus von S_Auf sofort wieder aktiviert wird?


Codesys: Zumindest war meine Absicht, sich mal damit näher zu befassen und hab es dort bislang zu programmieren und simulieren versucht. Inzwischen ziehe ich für genau diese Aufgabe u.U auch eine Mitsubishi Alpha in Erwägung, mal gucken was preiswerter daherkommt.

 

[PN/DP]

T_Vorlauf.Q UND negiertes BadLicht sorgt dann durch die zyklische Arbeitsweise für einen Impuls beim Ausschalten des Lichts?

Ja, das spart mir die Erkennung der fallenden Flanke von BadLicht. Der TON T_Vorlauf darf dabei erst danach aufgerufen werden.

Ist das FlipFlop mit Priorität auf R oder S?

Priorität hat der untere Eingang (also S), weil der nach dem oberen Eingang bearbeitet wird - dadurch "gewinnt" er im "Streitfall" R und S beide 1.

wie verhält sich das Programm bei dauerhaft anliegendem S_Auf wenn die Verzögerung von T_Lueften abläuft?

Dauer-S_Auf setzt das FlipFlop in jedem Zyklus, unabhängig von T_Lueften.
Wenn T_Lueften abgelaufen ist, dann wird zwar in jedem Zyklus das Flipflop evtl. zunächst rückgesetzt (implementationsabhängig), durch das Dauer-S_Auf aber sofort wieder gesetzt - das merkt der nachfolgende Code aber nicht, der sieht nur FlipFlop.Q = 1
Mit dem &-Block vor dem S des FlipFlop habe ich S_Zu Vorrang vor S_Auf gegeben.

Falls während geöffnetem Fenster die SPS neu startet und M_Lueften ist nicht remanent, dann kann das Fenster nicht direkt geschlossen werden (Relais_Zu bzw. TOF T_MotZu benötigt daß vorher M_Lueften auf 1 war), es muß dann einmal S_Auf getippt werden (oder das BadLicht > T_Vorlauf Ein sein), dann schließt das Fenster nach Ablauf von T_Lueften oder wenn S_Zu getippt wird.
(Wenn man anstatt dem TOF einen TON mit negiertem Eingang nimmt und den Q negiert an den &-Block gibt, dann wird bei jedem SPS-Neustart möglicherweise Relais_Zu für die Dauer von T_MotZu aktiviert. Das könnte man mit einem langen Anlaufmerker unterdrücken.)

Harald