TIA Setzen in SCL geht nicht

[pongneng]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich arbeite mich gerade in SCL (TIA V15.1) ein und will mal einige einfache Sachen probieren.
Hier mein aktuelles Problem:
Ich möchte einen Ausgang setzen (nicht zuweisen) mit

IF #trigger1 = true  THEN
    #"Ausgang_" := true;
END_IF;

Wenn trigger1 high ist, wird Ausgang_ auch high -> gut so
Geht trigger auf low zurück, geht auch Ausgang_ auf low -> soll aber bis zu einem späteren Rücksetzen auf high bleiben.
Das heißt, in jedem Zyklus wird Ausgang_ selbständig wieder zurückgesetzt.
Warum ist mein Konstrukt kein Setzen sondern offensichtlich ein Zuweisen?

 

[rostiger Nagel]

Ist den deine Ausgang auch Statisch oder was für eine Variable ist es überhaupt?
Wird der Ausgang an anderer Stelle noch einmal zugewiesen?
Bei richtiger Deklaration und Verwendung des Ausgang, funktioniert das mit der
IF Anweisung ist wie ein Setzen bei einen SR Glied zu vergleichen.

Bei einer Boolschen IF Abfrage reicht es wenn du den Trigger einfach abfragst:

IF #trigger1 THEN
    #"Ausgang_" := true;
END_IF;

 

[pongneng]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
also trigger1 ist Input und Ausgang_ ist Output.

 

[rostiger Nagel]

mach mal bitte dein Output zu einen IN/OUT

 

[pongneng]

OK, so geht's.
Sieht aber nicht schön aus, weil der Ausgang auf der linken Seite des FC steht :???:

Es geht auch, wenn ich keinen FC verwende, sondern einen FB mit Instanz-DB.
Dann kann mein Ausgang_ auch ein Output sein.

 

[Senator42]

Zuviel Werbung?
-> Hier kostenlos registrieren

> FB mit Instanz-DB
> Dann kann mein Ausgang_ auch ein Output sein.
logisch, dann wird der "ausgang" im RAM des DB gespeichert.
Und am FB-ende das RAM auf den #"Ausgang_" geschrieben.

 

[pongneng]

das heißt, ein FC in SCL wird anders abgearbeitet, als ein FC in nicht SCL.
Denn da bleibt ja der Operator, der gesetzt wurde, auch gesetzt. :icon_rolleyes:

 

[Ralle]

das heißt, ein FC in SCL wird anders abgearbeitet, als ein FC in nicht SCL.
Denn da bleibt ja der Operator, der gesetzt wurde, auch gesetzt. :icon_rolleyes:

Ein FC hat keinen Speicher, in dem er sich irgendwelche Zustände merken kann. Wie also soll er nach X Zyklen der SPS wissen, das der Ausgang einmal gesetzt war?
Das ist einer der Gründe, warum es FC und FB gibt.

 

[pongneng]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja das weiß ich doch, das Verhalten ist ja auch logisch.
Aber warum bleibt dann ein Ausgang, der in einem FC gesetzt wurde, auch über den CPU Zyklus hinaus gesetzt, obwohl die Setz-Bedingung nicht mehr ansteht?

 

[Larry Laffer]

@TE:
Du vergleichst hier Äpfel mit Birnen ...
In dem einem Fall, in dem du schreibst, das es funktioniert, setzt du den Ausgang selbst. In deinem FC steht dann also etwas wie :

U E3.3
S A7.4

Wenn du das Gleiche genauso in SCL programmierst dann wird es auch funktionieren - also in deinem geposteten Code die Absolut-Operanden einfügen ... 8)

Nun möchtest du aber mit Variablen des FC arbeiten ...
Du hast also eine IN-Variable (dieser wird immer der Zustand des daran programmierten Operanden zugewiesen - bei jedem Aufruf des Bausteins) ...
und du hast eine OUT-Variable (diese hat in einem FC immer erstmal keinen Zustand - also False). Möchtest du nun erreichen, dass diese OUT-Variable immer den von dir gewünschten Zustand hat dann mußt du sie in JEDEM FC-Aufruf zuweisen ... ODER ... du machst es wie oben schon genannt (FB an Stelle von FC oder IN_OUT an Stelle von OUT).

Ich hoffe, ich konnte es dir verständlich machen ...

Gruß
Larry

 

[Onkel Dagobert]

.. du hast eine OUT-Variable (diese hat in einem FC immer erstmal keinen Zustand - also False). ..

Larry, das "also False" ist in deiner Aussage zu viel, glaube ich, "kein Zustand" ist aber richtig. Ich denke, du hast das auch so gemeint.

Wenn ich mich recht entsinne, beschreibt die FC konsequent ihre Ausgänge beim beenden der FC. Wenn ein Ausgang vorher nicht zugewiesen wurde, so steht dort ein zufälliger Wert aus dem L-Stack. Falls es, wie im betrachteten Beispiel, scheinbar mal funktionieren sollte, dann liegt es daran dass der L-Stack des Bausteins über den Zyklus hinweg nicht an anderer Stelle überschrieben wurde.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sieht aber nicht schön aus, weil der Ausgang auf der linken Seite des FC steht

Sieht vielleicht nicht schön aus, sollte aber helfen bzw. nach der HolzHammerMethode ganz dezent darauf hinweisen, wo das Problem/Missverständnis liegt.
Wenn man statt

IF #trigger1 = true  THEN
    #"Ausgang_" := true;
END_IF;

etwas vervollständigt schreibt

IF #trigger1 = true  THEN
    #"Ausgang_" := true;
ELSE
    #"Ausgang_" := [B]#"Ausgang_"[/B];
END_IF;

sieht das zwar auch blöd aus, aber man wird hoffentlich(!) daran erinnert, dass der FC ins Leere greift, wenn er den vorherigen Zustand des Ausgangs nicht verändern soll.

 

[blimaa]

IF #trigger1 = true  THEN
    #"Ausgang_" := true;
ELSE
    #"Ausgang_" := [B]#"Ausgang_"[/B];
END_IF;

sieht das zwar auch blöd aus, aber man wird hoffentlich(!) daran erinnert, dass der FC ins Leere greift, wenn er den vorherigen Zustand des Ausgangs nicht verändern soll.

Aber das wäre ja nicht mehr Setzen/Rücksetzen sondern:

U #trigger1
 = #"Ausgang_"

Aber einfach gesagt: Wenn es mit einem FC mit IN-Out Variable gemacht wird, dann wird das "Gehirn" nach aussen gelagert.

PS: Mir wurde mal gesagt, dass ein FC nur für Umwandlungen und Berechnungen zu gebrauchen ist. Also für Aufgaben wo nur nichts länger als ein Zyklus gespeichert werden muss...

Gruss blimaa

 

[Heinileini]

Aber das wäre ja nicht mehr Setzen/Rücksetzen

Doch, Setzen schon, aber nicht Rücksetzen. Rücksetzen (aber nicht Setzen) wäre es, wenn in '#"Ausgang_" := true;' true durch false ersetzt würde.

 

[blimaa]

Zuviel Werbung?
-> Hier kostenlos registrieren

ah klar, habs zuschnell überflogen

blöde Frage, aber der FC speichert doch auch die Ausgänge nicht? Oder?

 

[Heinileini]

der FC speichert doch auch die Ausgänge nicht?

Seine eigenen Outputs speichert er nicht, so wie er auch alles andere nicht von sich aus speichert.
Die Ausgänge der PLC werden bzw. bleiben unabhängig von irgendwelchen FCs im ProzessAbbild gespeichert, es sei denn irgendein FC überschreibt (hier unbeabsichtigt) das ProzessAbbild.

 

[holgermaik]

so steht dort ein zufälliger Wert aus dem L-Stack. Falls es, wie im betrachteten Beispiel, scheinbar mal funktionieren sollte, dann liegt es daran dass der L-Stack des Bausteins über den Zyklus hinweg nicht an anderer Stelle überschrieben wurde.

Ich habe beim TIA Lehrgang gelernt, dass im gegesatz zu Classic der L-Stack im TIA immer abgelöscht wird.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe beim TIA Lehrgang gelernt, dass im gegesatz zu Classic der L-Stack im TIA immer abgelöscht wird.

Bezogen auf den FC dieses Thread ist das aber ein unerheblicher Unterschied. Im FC wird nicht dafür gesorgt, dass auf den alten Zustand zugegriffen wird.
Ob stattdessen ein sauber vorbesetztes False oder ein dem Zufall überlassenes "Vielleicht" am Ausgang (des FC) übergeben wird, ist gleichermassen nicht das, was beabsichtigt ist.

 

[rostiger Nagel]

etwas vervollständigt schreibt

IF #trigger1 = true  THEN
    #"Ausgang_" := true;
ELSE
    #"Ausgang_" := [B]#"Ausgang_"[/B];
END_IF;

sieht das zwar auch blöd aus, aber man wird hoffentlich(!) daran erinnert, dass der FC ins Leere greift, wenn er den vorherigen Zustand des Ausgangs nicht verändern soll.

So ein Konstrukt macht die Sache nur unübersichtlicher, hilft nicht beim von
TE beschriebene Problem, eher im Gegenteil weil Außerhalb des FC Kann der
Ausgang True sein und im FC zu False werden, weil er ja nicht eingelesen wird.
Begründung hat Onkel Dagobert schon geliefert.
Am besten gleich richtig deklarieren und nicht einen Code unnötig aufblähen.

 

[rostiger Nagel]

Ich habe beim TIA Lehrgang gelernt, dass im gegesatz zu Classic der L-Stack im TIA immer abgelöscht wird.

Ich glaube das kann doch nur Steuerungssbhängig sein, gehst du mit TIA auf eine 300er
wird sie sich doch weiter wie eine 300er verhalten.