TIA WIE Aufruf organisieren?

spirit

Level-1
Beiträge
961
Reaktionspunkte
23
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Profis,

brauche mal wieder einen Denkansatz ...


Es gibt in einer Anlage (bis jetzt) sieben FB's (= 7 Varianten), in denen jeweils Schrittketten programmiert sind. Leider sind die Schrittketten in jeder Variante unterschiedlich, so dass hier ein Multiinstanzaufruf entfällt.

Jede Variante kann über das Display angewählt werden; d.h. es ist IMMER nur einer der sieben FB's aktiv!


Meine Frage dazu:

Kann ich an jeden FB die gleichen Aktualparameter (z.B. Merker für Ventile) anschreiben, da ja immer nur ein FB zur gleichen Zeit aktiv ist - oder wird das dann ein Kuddelmuddel? ;)
 
Das wäre m.M.n. durchaus sinnvoll, nur müssen dann die Aufrufe der inaktiven FB übersprungen werden, damit sie nicht dazwischenpfuschen.
Aber sind die Unterschiede so groß, daß man sie nicht innerhalb der SK abfangen kann (Verzweigung, Bedingte Aktion und/oder Rezept, das die Abweichungen enthält)? Das würde ich bevorzugen, auch schon wegen der einfacheren Wartung. erfahrungsgemäß ändert sich nämlich genau das was in allen Varianten gleich ist ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann ich an jeden FB die gleichen Aktualparameter (z.B. Merker für Ventile) anschreiben, da ja immer nur ein FB zur gleichen Zeit aktiv ist - oder wird das dann ein Kuddelmuddel? ;)
Dir muss halt klar sein, dass die Merker "kleben bleiben" wenn der FB nicht mehr bearbeitet wird.
Aber ich denke das weißt Du schon.

Wenn Du bei jedem "FB Wechsel" am Anfang der Schrittkette einen Initialschritt machst, wo alle betroffenen
Merker erst mal plattgemacht werden geht das schon.
Kommt halt auch drauf an wie viele Ventile (Merker) das eigentlich sind.
Kann unter Umständen schon unübersichtlich werden und wenn noch ein Ventil dazukommt musst Du
unter Umständen alle 7 Schrittketten-FBs anpacken.

Ich mach das eigentlich immer so, dass für jedes Ventil einen kleinen FC habe.
(Also natürlich immer den selben FC, nur unterschiedlich beschalten)
An diesen FC wird die Betriebsart (Hand/Auto) geschrieben und die entsprechende Anforderung (Auto ANF GST,
Auto ANF AST, Hand ANF GST, Hand ANF AST, Spule GST, Spule AST)

In deinem Fall würde sich wahrscheinlich eigener FB/FC anbieten wo die Zuweisung für alle Ventile erfolgt.
 
Zuletzt bearbeitet:
Dir muss halt klar sein, dass die Merker "kleben bleiben" wenn der FB nicht mehr bearbeitet wird.
Aber ich denke das weißt Du schon.

Ja, daher könnte man/frau :p an dieser Stelle evtl. auf den Vorschlag von 'Ingmar64' zurückkommen:

Das wäre m.M.n. durchaus sinnvoll, nur müssen dann die Aufrufe der inaktiven FB übersprungen werden, damit sie nicht dazwischenpfuschen.

Wäre doch dann insgesamt ein ganz passabler Weg, oder?
 
Das wäre m.M.n. durchaus sinnvoll, nur müssen dann die Aufrufe der inaktiven FB übersprungen werden, damit sie nicht dazwischenpfuschen.

Alternativ müsste man die Ausgänge der inaktiven abläufe Abschalten. Dann könnten alle Ausgänge auf Temp-Variablen geschrieben und verodert weiter gegeben werden. Siehe dazu Hilfe -> Suche -> "Zero_Op"

Ist ne nette Alternative zu Jumps. Wird der Aufruf in SCL gemacht, ist das überspringen weniger ein Problem, da einfach eine Case-Anweisung genutzt werden kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde Ventile oder Aktoren überhaupt nicht in der Schrittkette verschalten,
wie schon gesagt wegen des Klebenbleibens, wenn du dich nicht darauf geachtet
hast, das abzufangen.

Meiner Ansicht nach ist es besser, wenn du jeder Schrittkette bzw. FB einen eigenen
DB spendierst.

Die beschaltung der Aktoren, also von dir angesprochenen Venitle, machst du dann
nur an einer Stelle in deinen Programm, legst dann Freigaben wie Not-Aus, Endlagen
und was weiß ich davor und dann die Variablen die von den Schrittketten erzeugt
wurden.

So hast du Sicherheit das dein Aktor auch wirklich abschaltet bei Aus oder Endlage
und du kannst besser erkenn, in welcher Schrittkette du murks gemacht hast.
 
Ich würde Ventile oder Aktoren überhaupt nicht in der Schrittkette verschalten,
wie schon gesagt wegen des Klebenbleibens, wenn du dich nicht darauf geachtet
hast, das abzufangen.

Meiner Ansicht nach ist es besser, wenn du jeder Schrittkette bzw. FB einen eigenen
DB spendierst.

Die beschaltung der Aktoren, also von dir angesprochenen Venitle, machst du dann
nur an einer Stelle in deinen Programm, legst dann Freigaben wie Not-Aus, Endlagen
und was weiß ich davor und dann die Variablen die von den Schrittketten erzeugt
wurden.

So hast du Sicherheit das dein Aktor auch wirklich abschaltet bei Aus oder Endlage
und du kannst besser erkenn, in welcher Schrittkette du murks gemacht hast.



Aber das Problem des "Klebenbleibens" würde sich ja auch nicht ändern, wenn ich stattdessen (immer die gleichen) Variablen für die jeweiligen Ventile an den FB schreibe. Wenn schon, dann müsste ich ja für jeden FB-Aufruf unterschiedliche Variablen benutzen - und genau das wollte ich eigentlich vermeiden.


Eine weitere Möglichkeit:

Wie wäre es denn, wenn ich ALLE Schrittketten (in SCL programmiert) in einem einzigen FB programmiere und dann die jeweilige SK über die entspr. Bedingung und den Befehl "WHILE DO" aktiviere? Dann könnte ich an diesen FB einmalig Variablen für die Ventile anschreiben und in einem separaten FC mit den Ausgängen verschalten.


Also um es klar zu machen, ich möchte mir einfach ersparen, dass ich für jede SK eines FB's unterschiedliche Namen für die Variablen der Ventile vergeben muss ...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich weiß ja nicht, wie dein Baustein so aufgebaut ist. Du kannst aber m.E. selbstverständlich 7 Bausteine mit der gleichen E/A-Beschaltung haben, von denen dann nur jeweils einer läuft. Das könntest du durchaus über eine Freigabe an den Baustein regeln - der Baustein braucht dann ja innen nicht mehr weiter bearbeitet zu werden. Aber vielleicht postest du mal etwas dazu ...

Gruß
Larry
 
Code:
CASE _variable_name_ OF
    1:  // Statement section case 1
        call dein_aufruf;
    2:  // Statement section case 2
        call dein_aufruf;
    ELSE  // Statement section ELSE
        ;
END_CASE;

Dann kannst du auch einfach alle gleich beschalten. Nicht schön, aber machbar. Die Schrittketten brauchst du nicht in SCL zu schreiben, da geht auch jede andere Sprache. Machst du den Aufruf in FUP oder AWL, musst du das über Jumps lösen, geht aber auch. Allerdings bekommst du zum dank einen Teller Spaghetti von demjenigen, der da mal Fehler suchen muss.
 
Ich weiß ja nicht, wie dein Baustein so aufgebaut ist. Du kannst aber m.E. selbstverständlich 7 Bausteine mit der gleichen E/A-Beschaltung haben, von denen dann nur jeweils einer läuft. Das könntest du durchaus über eine Freigabe an den Baustein regeln - der Baustein braucht dann ja innen nicht mehr weiter bearbeitet zu werden. Aber vielleicht postest du mal etwas dazu ...

Gruß
Larry

Danke Larry,

in jedem einzelnen FB sind Schrittketten (in SCL) programmiert, die sich zwar durch den Ablauf der Ketten, nicht jedoch durch die anzusteuernden Aktoren (Ventile, Schütze, usw.) unterscheiden. Das bedeutet also, dass ich an jeden FB (derzeit 7 an der Zahl) die gleichen Aktualparameter (Variablen) anschreiben möchte.

In einem spearaten FC werden dann diese Aktualparameter (E/A-Beschaltung) den eigentlichen Ausgängen zugeordnet.
Meine Frage(n) hierzu:

1) Wenn ich das so aufbaue, wie müsste ich dann die Freigabe an den einzelnen FB's regeln - über den ENO-Eingang oder über den Befehl "WHILE DO" in der Kette, oder wie sonst?
2) Muss ich dann gar nicht die nicht aktiven FB's überspringen?

Danke ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
CASE _variable_name_ OF
    1:  // Statement section case 1
        call dein_aufruf;
    2:  // Statement section case 2
        call dein_aufruf;
    ELSE  // Statement section ELSE
        ;
END_CASE;

Dann kannst du auch einfach alle gleich beschalten. Nicht schön, aber machbar. Die Schrittketten brauchst du nicht in SCL zu schreiben, da geht auch jede andere Sprache. Machst du den Aufruf in FUP oder AWL, musst du das über Jumps lösen, geht aber auch. Allerdings bekommst du zum dank einen Teller Spaghetti von demjenigen, der da mal Fehler suchen muss.

Danke Christmaspoo,

also ich mag Spaghetti schon sehr gerne! :p


An Stelle von "call dein_aufruf" würde also jedes Mal der SK-FB aufgerufen werden, richtig? Aber an welcher Stelle würde dann die Bedingung für den Aufruf stehen - müsste ich das über dem CASE OF regeln?

Und ich könnte dann auch ALLE Variablen an den aufgerufenen FB's GLEICH benennen, ohne dass es zu Komplikationen kommt?
 
Zuletzt bearbeitet:
Hilfe -> PLC programieren -> Anweisungen -> SCL -> Programmsteuerung -> CASE: Mehrfach verzweigen

bischen eigenleistung muss schon da sein ;-)

Mit den Spaghetti war übrigends folgendes gemeint: https://de.wikipedia.org/wiki/Spaghetticode


Ok, aber das Beispiel hatte ich mir schon angesehen. Im Grunde verstehe ich den Befehl CASE auch; ich bin mir nur nicht ganz klar darüber, wie die Vorauswahl für den Aufruf der einzelnen FB's organisiert werden muss?


Code:
IF #Bedingung_1 THEN
  #Aufrufe := 1;
ELSIF #Bedingung_2 THEN
  #Aufrufe := 2;
ELSIF #Bedingung_3 THEN
  #Aufrufe := 3;
  
  ...
  
END_IF;


CASE #Aufrufe OF
  1:  // Statement section case 1
  Call FB1, DB1;
  2:  // Statement section case 2 
  Call FB2, DB2;  
  3:  // Statement section case 3 
  Call FB3, DB3;
    
    ...
    
END_CASE;

Denke, so müsste es klappen? :confused:
 
Nun habe ich noch ein Problem beim Aufruf der FB's in einem FC im TIA-Portal ...

Ich verwende in den FB's eine IN/OUT-Variable. Diese soll mit einer IN-Variable aus einem anderen DB "verkuppelt" werden. Dabei kommt es zu einer Fehlermeldung.


Nun möchte ich diesen Weg gehen:

1) Anlegen einer Temp-Var im Aufruf-FC
2) Dieser Temp-Var übergebe ich die IN-Variable aus dem Datenbaustein
3) Die Temp-Var übergebe ich schließlich der IN/OUT-Var aus den Schrittketten-FB's

Kann ich das so lösen? Zumindest kommt keine Fehlermeldung! ;)

Lieben Dank ...
 
Zuletzt bearbeitet:
Und was soll das bringen?

TIA meckert, weil das OUT-Ergebnis des FB nicht in die IN-Variable des FCs geschrieben werden kann, auch wenn diese aus einem DB stammt.
Das würde bedeuten, dass der OUT nach dem Zyklus verloren geht. Wenn der nicht benötigt wird (Temp-Variante), wieso wird dann INOUT und nicht IN im FB verwendet?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und was soll das bringen?

TIA meckert, weil das OUT-Ergebnis des FB nicht in die IN-Variable des FCs geschrieben werden kann, auch wenn diese aus einem DB stammt.
Das würde bedeuten, dass der OUT nach dem Zyklus verloren geht. Wenn der nicht benötigt wird (Temp-Variante), wieso wird dann INOUT und nicht IN im FB verwendet?


Die IN/OUT-Variable dient zweierlei Zwecken:

1) Es wird eine neue Position (out) in einen Antrieb geschrieben.

2) Es wird überprüft (in), ob der Antrieb die neuen Positionsdaten verarbeitet hat.

Daher also eine IN/OUT-Variable.


Funktioniert das niemals, dass ein OUT eines FB's in ein IN eines FC's geschrieben wird? :confused:

Welche Möglichkeit hätte ich jetzt hier speziell, dieses Problem zu lösen?
 
Zuletzt bearbeitet:
1) Wenn ich das so aufbaue, wie müsste ich dann die Freigabe an den einzelnen FB's regeln - über den ENO-Eingang oder über den Befehl "WHILE DO" in der Kette, oder wie sonst?
2) Muss ich dann gar nicht die nicht aktiven FB's überspringen?

So in etwa würde ich es machen. Du kannst die unterschiedlichen Bausteine an ihrem Aufruf überpringen oder ihnen eine Freigabe geben und dann innen den ganzen Code überspringen (entweder mit einem GOTO :Ende oder mit einem IF dass die komplette innere Bearbeitung ausklammert). WHILE DO verbietet sich hier doch wohl von selbst ...

So, wie du es beschreibst, würde ich hier wahrscheinlich nicht 7 unterschiedliche Schrittketten in den einen Baustein hinein packen und diese mit einem SELECT (oder IF) entsprechend laufen lassen. Ich kann mir vorstellen, dass das zu unübersichtlich wird - so etwas würde man so in der Hochsprachen-Programmierung auch nicht machen. Auch dort würde man einzelne Methoden haben, die man entsprechend anwählt ...

Gruß
Larry
 
Funktioniert das niemals, dass ein OUT eines FB's in ein IN eines FC's geschrieben wird?
Nicht wenn dieser FB vom FC aufgerufen wird.
Wo soll denn der FC den Rückgabewert vom INOUT des FBs speichern?

Wenn Du z.B. aus dem IN des FCs auch einen INOUT machst, dann kann das Ergebnis des FBs weiter (in diesem Fall an den DB) durchgereicht werden.
 
Zurück
Oben