TIA Programmierstil

kuti

Level-1
Beiträge
354
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe einen FB12, in der ein Regelschieber je nach Regeldifferenz auf und ab bewegt wird. Jetzt soll ich eine "Mindestöffnung" des Regelschiebers programmieren. Diese Funktion soll an- und abwählbar sein.
Programmieren tue ich mit lokalen Variablen, was für mich noch Neuland ist, deswegen jetzt meine Frage: Die Ausgänge für den Regelschieber stehen in dem FB12. Darf ich jetzt einen anderen FB oder FC programmieren, wo ich diese Mindestöffnung programmiere,d.h wo ich die auch dort Ausgänge noch mal beschreibe? Oder dürfen die Ausgänge nur in dm FB12 beschrieben werden?

Gruß
 
Grundsätzlich darfst du die Ausgänge so oft beschreiben wie du willst. Der letzte Schreibende Zugriff im Zyklus gilt dann aber.

z.B. könntest du ein weiteres zuschieben des Schiebers verhindern wenn du nach dem FB12 nochmal abfragst ob die Mindestöffnung schon erreicht wurde und den zuschiebausgang auf "false" zurücksetzen.

Es gibt aber sicher bessere und sauberere Lösungen. Ich ziehe ein es vor wenn ein Objekt nur von einem Baustein bedient wird und dieser halt die entsprechenden Freigaben und Konditionen verarbeitet.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das heißt, ich kann die Ausgänge in mehreren FB oder Fcs beschreiben? Habe da irgendwie immer was anderes gelernt, nämlich ein Ausgang sollte immer nur in seinem Netzwerk beschreiben werden.
 
Das heißt, ich kann die Ausgänge in mehreren FB oder Fcs beschreiben? Habe da irgendwie immer was anderes gelernt, nämlich ein Ausgang sollte immer nur in seinem Netzwerk beschreiben werden.
Du kannst die Ausgänge schon in mehreren Netzwerken beschreiben. Das ist prinzipiell erst mal nicht verboten.
Aber es ist auch kein besonders guter Programmierstil und Du solltest Dir es gar nicht erst angewöhnen. Wenn Du lokale Variablen verwendest, ist das auch überhaupt nicht nötig.

An Deiner Stelle würde ich den FB 12 in der Schnittstelle erweitern und dann ein weiters Netzwerk einfügen.
So in etwa wie in diesem Beispiel:





Am Schnittstellen-Ausgang des FBs wird dann (nur an dieser einen Stelle) der reale Ausgang angegeben. Im FB wird nur mit lokalen Variablen gearbeitet.
 
Danke dir für deine Mühe. Also ich nehme mit: Ausgänge ( hier: lokale Variable) immer in EINEM NETZWERK schreiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nicht ganz:
Die lokalen Variablen (auch Baustein-Ausgänge) kann man schon in mehreren Netzwerken verwenden. Das läßt sich auch gar nicht immer vermeiden. (Siehe Netzwerk 2 und 3 in meinem Beispiel)
Die lokalen Variablen sind ja immer auf die Verwendung in einem Baustein begrenzt. Zu anderen Bausteinen müssen sie ggf. über die Schnittstelle übergeben werden.

Die realen Ausgänge der SPS sollten aber möglichst nur an einer Stelle verwendet und auch möglichst zugewiesen und nicht gesetzt/rückgesetzt werden.
 
Zuletzt bearbeitet:
"Die lokalen Variablen (auch Baustein-Ausgänge) kann man schon in mehreren Netzwerken verwenden."

Wenn man z.B. eine temp-Variable hat und diese sowohl in Netzwerk 1 und Netzwerk 2 beschreibt, ist das keine so gute Idee.
 
Wenn man z.B. eine temp-Variable hat und diese sowohl in Netzwerk 1 und Netzwerk 2 beschreibt, ist das keine so gute Idee.
Warum sollte das keine gute Idee sein? Da spricht nichts dagegen.

Es ist keine gute Idee, eine Temp-Variable im Netzwerk 1 zu lesen, bevor sie dann im Netzwerk 2 erst nachfolgend beschrieben wird.
Und zwar deshalb, weil alle Temp-Variablen vor der ersten Zuweisung (Schreiben) keinen definierten Zustand haben. Und das in jedem Zyklus wieder von Neuem.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Genau, man muss nur die zyklische bearbeitungsreihenfolge beachten!
Und man muss auch wissen das in lokalen Variablen völliger Quatsch stehen kann wenn man sie bedingt beschreibt.. :)
 
Ich meine es so: Wenn man eine temp-Var hat, die in unterschiedlichen Netzwerken mit unterschiedlichen Vorbedingungen verknüft ist, dann ist DAS keine gute Idee. Denn wenn man weiter unten diese nimmt für eine Verknüpfung, dann führt das zu Problemen, oder ?
 
Nö.

:D


Bei Temp ist nur eins wichtig - in jedem Zyklus zuerst beschreiben und danach kann man sie erst auslesen. Vorher Auslesen, z.B. weil man sie im letzten Zyklus beschrieben hat, ist undefiniert! Daher temporär.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich meine es so: Wenn man eine temp-Var hat, die in unterschiedlichen Netzwerken mit unterschiedlichen Vorbedingungen verknüft ist, dann ist DAS keine gute Idee. Denn wenn man weiter unten diese nimmt für eine Verknüpfung, dann führt das zu Problemen, oder ?

Grundsätzlich führt die zu keinen Problemen

Z.B.
Code:
U #Eingang1
U #Eingang2
= #TEMP1

U #TEMP1
= #OUT1

U(
L#iIN1
L#iN2
>=I
)
=#TEMP1

U #TEMP1
= #OUT2

Wäre absolut korrekt und funktioniert wie angedacht. Out1 reagiert nur auf die Bitverknüpfung und Out2 reagiert nur auf den Teil ab und mit U( weil diese Vergleichsopperation ebenfalls immer die Temporäre Variable beschreibt. Die Temporäre Variable wird immer beschrieben, entweder mit 0 oder mit 1.
Es ist aber nicht schön. Man kann nahezu so viele temporäre Variablen nutzen wie man will, darum soll man sie auch nutzen und vernünftig beschriften und kommentieren.

mfG René
 
Danke euch. Normalerweise sind lokale Variablen nur innerhalb einer FB,FC bekannt, inder sie deklariert wurden. Was ist wenn ich in einem FB einen FC aufrufe? Sind dort die lokalen Variablen vom FB bekannt?
 
Nein die sind dort nicht bekannt. Daten sollten immer über die Schnittstelle übergeben werden. Sei dass nun direkt per Call FC

Code:
      CALL  "BrandAbsaugKlappe"
       BAK_Brand_Auf           :=M100.0
       BAK_Brand_Zu            :=M100.1
       Stoerung_NichtbereitFern:=M100.2

oder bei FBs an den Instanzdb ist dann wieder ne Streitfrage.

Code:
      CALL  "lamp_age" , "IDB_lamp_age"
       SetMode      :=
       SetScenery   :="SheratonEntry".SetScenery
       AssScenery   :="SheratonEntry".AssScenery

[COLOR="#FF0000"]L "SheratonEntry".SetMode
T "IDB_lamp_age".SetMode[/COLOR]
 
Nein, wenn Du da was brauchst, muss das über die Schnittstelle übergeben werden.

Jeder Baustein hat nur seine eigenen lokalen (oder halt globale) Variablen. Soll ein Baustein mehrfach im Zyklus aufrufbar sein, dürfen nur lokale Variablen verwendet werden. Man spricht dann von Bausteinkapselung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich programmiere gerade in FUP.Im FB12 habe ich zwei IN-OUT-Vriablen als Schnittstelle für die realen Ausgänge deklariert. Ich möchte jetzt irgendwo in der Mitte des FB eine FC11 aufrufen, in der der Schieber auf eine Mindestöffnung gefahren wird. Jetzt weiß ich nicht wie ich das mit den Ausgängen machen soll. In meinem FB habe ich beide Ausgänge als IN-OUT-Variabelen deklariert. Wenn ich jetzt diese FC11 aufrufe, greife ich ja auch auf die Ausgänge zu, was mache ich dann mit diesen IN-OUT-Variablen im FB? :confused:
 
Du schreibst die notwendigen lokalen Variablen aus dem FB an die Schnittstelle des FC bei dessen Aufruf. Dadurch werden diese Werte vom lokalen Speicher des FBs an den lokalen Speicher des FCs übergeben und dieser kann dann intern damit arbeiten.
 
Du hast doch auch TIA. Normalerweise steht doch der CALL-Befehl rechts bei der Programmsteurung. Ich finde das nicht.
 
Zurück
Oben