Step 7 Out-Parameter von FB setzen

Beiträge
62
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, die Damen und die Herren:

folgendes Problem bzw. folgende Fragestellung beschäftigt jetzt schon den ein oder anderen Programmierer von uns:

Ist es möglich (ohne undefinierte Zustände oder Fehler zu erhalten), einen OUT-Parameter eines FBs zu setzen / rückzusetzen?
(Auch als Multiinstanz bzw. bei mehreren Instanzen des FBs).
Konkretes (vereinfachtes) Beispiel:

O #STAT_1
O #STAT_2
S #OUT_1

U #IN_1
R #OUT_1

--> Kann das so gemacht werden, auch wenn #STAT_1 und #STAT_2 mal beide 0 werden? Also #OUT_1 wird irgendwann gesetzt, weil das ODER wahr wird
--> bleibt #OUT_1 dann gesetzt, auch wenn das ODER wieder falsch wird? Oder kann man das so nicht machen?

Wäre natürlich ideal, wenn jemand die entsprechende Stelle aus einer Siemens-Doku zur Hand hätte und beweisen könnte, dass das so geht bzw. eben nicht geht.

Vielen Dank im Voraus für viele hilfreiche Antworten!
 
Ja, das funktioniert. :p

Die OUT Parameter sind ja Speicherbereiche im InstanzDB und in genau diesen wird der Status von OUT_1 gespeichert. (Auch wenn #STAT_1 usw. auf null gehen -> weil eben gespeichert ;) )

Tja beweisen kann ich es dir nicht aber du bist gerne eingeladen dein Beispiel in vermutlich 3 Minuten selbst zu testen und zu bemerken dass es funktioniert.
Die Erklärung hast du ja nun.
 
Wäre natürlich ideal, wenn jemand die entsprechende Stelle aus einer Siemens-Doku zur Hand hätte und beweisen könnte, dass das so geht bzw. eben nicht geht.

Was setzt Du denn ein? Step7 5.x oder Tia Portal? Im TIA Portal stimmt an der Stelle nämlich die Doku nicht :cool:

irgendwo gabs hier mal nen Thread dazu...

PS: Wobei man natürlich überlegen könnte, ob man das unbedingt so machen muss... ich versuche, in meinen Bausteinen die Ausgänge in jedem Aufruf auch zu beschreiben...
 
Zuletzt bearbeitet:
Projektierungssoftware ist Step 7 5.5.

Ja, es ist zumindest "unschön", einen OUT zu setzen, statt per = zuzuweisen. Sollte dem SR vorgezogen werden... Habs aber schon öfters so gemacht, werde mir das wohl abgewöhnen.
Klar, dass es beim FC nicht geht. Aber wie gesagt, wir diskutieren hier mit 4 Kollegen über das Thema, 2 (die erfahrenen) tendieren eher dazu bzw. sind sich sogar sicher, dass es NICHT geht, die beiden andern (mich eingeschlossen)
wundern sich, dass das nicht gehen soll und denken eher, dass es funktioniert.

Angeblich hängt es damit zusammen, dass die OUT-Variablen zwar im Instanz-DB stehen, aber vom FB irgendwie anders behandelt werden, eher so wie TEMP-Variablen. So 100% hab ichs auch nicht verstanden, warum das so sein sollte, aber es ist nun mal ihre Meinung. Ich will ja auch nicht ihre Kompetenz in Frage stellen, nur ist es eben ein Thema, was mich schwer verwundert...

Ich habs wie gesagt auch auf anderen Anlagen schon öfters so eingesetzt und Probleme damit sind mir bisher noch nicht aufgefallen, auch im PLCSIM habs ich natürlich direkt nachgestellt --> Kein Problem. Deshalb eben, ich weiß, ich wiederhole mich, meine Unsicherheit und Verwunderung bzgl. dieses Themas...

Und solange ich das jetzt nicht irgendwie bewiesen bekomme, wie es im Endeffekt richtig ist, bleibe ich skeptisch (auch wenn ichs gern nicht wäre :-D ), ich meine, über 20 Jahre Programmiererfahrung der Kollegen gegen meine 3 mickrigen haben natürlich schon irgendwie eine gewisse Aussagekraft...

Danke für die Antworten und wie gesagt, gerne mehr davon!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bausteinparameter eines FBs liegen im IDB. Beim Aufruf eines FBs müssen deswegen nicht alle Bausteinparameter versorgt werden. Sind gewisse Bausteinparamter nicht versorgt, arbeitet der FB mit seinen alten Werten vom letzten Aufruf oder mit den Werten der Vorbelegung. Einzige Ausnahme sind die Durchgangsparameter mit zusammengesetztem Datentyp.

Nachzulesen in jedem guten Buch (will jetzt keine Schleichwerbung betreiben ;) )

Ich hoffe, das konnte helfen...

Ansonsten kannst du deinen Quellcode auch so schreiben:
O #STAT_1
O #STAT_2
= #OUT_1

oder


O #STAT_1
O #STAT_2
S #OUT_1

UN #STAT_1
UN #STAT_2
R #OUT_1


Ein Auszug aus der Hilfe (hier: TIA Portal)
Versorgung der Parameter von Funktionsbausteinen (FB)
Bei Funktionsbausteinen werden die Parameterwerte in den Instanzdaten gespeichert.
Wenn Ein-, Aus- oder Durchgangsparameter eines Funktionsbausteins nicht mit Werten versorgt wurden, werden die gespeicherten Werte verwendet.
In einigen Fällen wird zwingend die Angabe eines Aktualparameters verlangt.
 
Zuletzt bearbeitet:
Wäre natürlich ideal, wenn jemand die entsprechende Stelle aus einer Siemens-Doku zur Hand hätte und beweisen könnte, dass das so geht bzw. eben nicht geht.
Ihr seid ja Spezialisten ... kommt denn bei Euch niemand auf die Idee (oder ist das so schwer?) sich mal ganz naheliegend die Simatic-AWL-Hilfe zur Parameterübergabe anzusehen statt wegen verschwommen-uralter Erfahrungen ergebnislos zu diskutieren?

Hilfe zu AWL > Parameterübergabe schrieb:
Die Parameter eines Bausteins werden als Wert übergeben. Bei Funktionsbausteinen wird innerhalb des aufgerufenen Bausteins eine Kopie des Aktualparameterwertes im Instanz-DB verwendet. [...] Vor dem Aufruf werden die INPUT-Werte in den Instanz-DB [...] kopiert. Nach dem Aufruf werden die OUTPUT-Werte zurück in die Variablen kopiert. Innerhalb des aufgerufenen Baustein arbeitet man nur auf einer Kopie.
[...]

Warnung

Sorgen Sie bei der Programmierung des aufgerufenen Bausteins dafür, daß die als OUTPUT deklarierten Parameter auch beschrieben werden. Sonst sind die ausgegebenen Werte zufällig! Bei Funktionsbausteinen bekommt man den vom letzen Aufruf gemerkten Wert aus dem Instanz-DB
(rote Hervorhebungen sind von mir)

Also eindeutig: S/R von OUT-Variablen in FB funktioniert, weil bei FB die OUT-Variablen im IDB liegen und dadurch ein "Gedächtnis" haben.
Trotzdem die Warnung, es auch in FB möglichst nicht zu tun - wie schnell kopiert mal jemand den "prima Code" in einen FC und da funktioniert's dann nur zufällig.

Harald
 
Macht es einen Unterschied, wenn die Variable in einem UDT liegt, also eigentlich #OUT_UDT.OUT_VALUE heißt?

Also laut der Antwort von PN/DP sehe ich das aber jetzt doch anders:

Warnung

Sorgen Sie bei der Programmierung des aufgerufenen Bausteins dafür, daß die als OUTPUT deklarierten Parameter auch beschrieben werden. Sonst sind die ausgegebenen Werte zufällig! Bei Funktionsbausteinen bekommt man den vom letzen Aufruf gemerkten Wert aus dem Instanz-DB

D.h., die OUT-Variable MUSS beschrieben werden, und das wird sie ja im Fall von

O #STAT_1
O #STAT_2
S #OUT_1

nicht, wenn #STAT_1 und #STAT_2 beide 0 sind! Sie wird nur beschrieben, wenn das ODER erfüllt (VKE = 1) ist! --> Folglich kann #OUT_1 Zufallswerte erhalten!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Trotzdem die Warnung, es auch in FB möglichst nicht zu tun - wie schnell kopiert mal jemand den "prima Code" in einen FC und da funktioniert's dann nur zufällig.

Harald

dann ist der auch einer von den Spezialisten.
das man nicht sofort die Hilfe liest kann ich gut verstehen aber warum man das nicht mal schnell probiert an einer Steuerung oder PLCSIM sonder lieber unter Spezialisten diskutier .... Da denk ich mir mal meinen Teil dazu
 
dann ist der auch einer von den Spezialisten.
das man nicht sofort die Hilfe liest kann ich gut verstehen aber warum man das nicht mal schnell probiert an einer Steuerung oder PLCSIM sonder lieber unter Spezialisten diskutier .... Da denk ich mir mal meinen Teil dazu

Warum so kritisch?
Durch die Diskussion geht das viel besser ins Gedächtnis, man versteht es vielleicht auch besser.
Und nicht zu vergessen, genau dazu ist das Forum ja da!
 
Im Plcsim lassen sich solche Sachen ja leider nur mit dem nötigen Grundwissen testen. Denn ein fc mit Temp oder Out als Speicher verwendet, kann ja sogar gut funktionieren solange kein echtes Programm drumrum tanzt.

Mit freundlichen Grüßen René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Im Plcsim lassen sich solche Sachen ja leider nur mit dem nötigen Grundwissen testen. Denn ein fc mit Temp oder Out als Speicher verwendet, kann ja sogar gut funktionieren solange kein echtes Programm drumrum tanzt.

Mit freundlichen Grüßen René

Stimmt aber wenn man so was schreibt mache ich mir über das Grundwissen weniger Gedanken.

Hallo, die Damen und die Herren:

folgendes Problem bzw. folgende Fragestellung beschäftigt jetzt schon den ein oder anderen Programmierer von uns:



Warum so kritisch?
Durch die Diskussion geht das viel besser ins Gedächtnis, man versteht es vielleicht auch besser.
Und nicht zu vergessen, genau dazu ist das Forum ja da!

@Ralle da hast du 100% recht das dafür ein Forum da ist

Aber wenn man nicht in der Lage ist mit dem ein oder anderen Programmierer
selber dafür eine Lösung zu erarbeiten...... Da denk ich mir mal meinen Teil dazu

Traurig wenn die Leute bei so einer Kleinigkeit nicht selber was probieren sondern per Google, Forum oder sonstige Suchmaschine
sich berieseln lassen. Meiner Meinung nach auf bequeme Art und Weise an die Lösung kommen wollen....... Deshalb haben wir ja so viele Spezialisten.

Sorry Leute und jetzt wieder zum schwierigen Thema zurück.
 
@UniMog: Du hättest dir jeden deiner Kommentare sparen können. Denn statt produktiv was beizutragen, hast du einfach nur den Thread zugemüllt. Hörst dich an wie ein verbitterter alter Mann, Hauptsache irgendwas rumgemeckert.

Natürlich können wir das selbst erarbeiten und testen und nachlesen, aber dafür ist ja eben ein Forum da. Zwei erfahrene Kollegen hatten zu dem Thema unterschiedliche Meinungen und jeder hatte auch eine Begründung dazu. Und natürlich weicht von denen dann auch keiner so schnell von seiner Meinung ab. Aber logischerweise muss einer falsch liegen. Und es ist ja durchaus möglich bei solchen Geschichten, dass in irgendwelchen Spezialfällen was anderes gilt als "normal".

Und bevor wir stundenlang rumtesten wegen so einer "Kleinigkeit", die so ein toller Hecht wie du natürlich, wie alles andere, perfekt beherrscht, ist es doch sinnvoller, mal in die Runde zu fragen. Wie weit wäre die Menschheit, wenn jede Generation alles neu erfinden müsste und Erfahrungen nicht weitergegeben würden? Darum geht es hier nämlich! Leider sind in jedem Forum immer ein Haufen Mitglieder unterwegs, deren einziger Beitrag es ist, andere lächerlich zu machen, anzumeckern oder sowas.

Auf meine letzte Frage konnte aber immer noch keiner antworten, wenn ich das richtig sehe.
 
Macht es einen Unterschied, wenn die Variable in einem UDT liegt, also eigentlich #OUT_UDT.OUT_VALUE heißt?

Nein, kein Unterschied da der UDT ja kein "eigner" Speicher ist sondern der Speicherbereich genauso im InstanzDB liegt!

D.h., die OUT-Variable MUSS beschrieben werden, und das wird sie ja im Fall von

O #STAT_1
O #STAT_2
S #OUT_1

nicht, wenn #STAT_1 und #STAT_2 beide 0 sind! Sie wird nur beschrieben, wenn das ODER erfüllt (VKE = 1) ist! --> Folglich kann #OUT_1 Zufallswerte erhalten!

Zufallswerte möchte ich nicht sagen - er hat den Wert der "letzten ordentlichen" Zuweisung aus dem Programm eben.
Was nicht bedeutet dass das immer prickelnd sein muss... Dies muss einem eben bewusst sein wenn man das anwendet.
Aber grundsätzlich ist der DB ja remanent und daher sollte es im normalen Betrieb nicht zwangsläufig sofort zu Problemen kommen.

Gefährlich wirds z.B. wenn sich am DB was verändert das den Aktualwert des OUT Parameters ändert...

Aber auch bei der Programmierung mit Merkern ist Obacht zu geben ob es ein remanenter oder eben ein nicht remanenter ist.
(setzen von NICHT remanenten Merkern) -> das halte ich für noch viel gefährlicher!

lg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
die von pn/dp zitierte doku bezieht sich allgemein auf fc und fb. bei fc waere der Wert zufaellig, bei fb kommt er aus dem idb. da es aber warum auch immer auch bei fb Probleme geben kann (faellt mir aber Grad nix ein) sollte man auch im fb die outparameter immer beschreiben...
 
ein problemfall waere vielleicht, wenn man im laufenden Betrieb den db neu in die sps laed. da wuerde dann der out auf den projektierten Werte gesetzt. ein vorher vom fb nur einmalig gesetzter out Wert waere verloren und wuerde auch nicht neu gesetzt. aber kommt natuerlich drauf an, was man ueberhaupt machen will...
 
@UniMog: Du hättest dir jeden deiner Kommentare sparen können. Denn statt produktiv was beizutragen, hast du einfach nur den Thread zugemüllt.

Tja das stimmt...... wollte ich nicht deshalb mein Sorry .....aber deine Formulierung mit 2 Programmierer und 2 erfahrene Programmierer
macht also 4 die wenig Ahnung haben.... Da konnte ich nicht über meinen Schatten springen

Und bevor wir stundenlang rumtesten wegen so einer "Kleinigkeit", die so ein toller Hecht wie du natürlich, wie alles andere, perfekt beherrscht,

Kleinigkeit.... Aha...
Genau deshalb trennt sich hier die Spreu vom Weizen ..... andere nehmen sich die Zeit.


ist es doch sinnvoller, mal in die Runde zu fragen.

Sinnvoller für das erfahrene Team wäre es mal mehr die Nase in Bücher und Doku zu stecken...... mit anschließender gemeinsamer
praktischer Übung an einer echten Steuerung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Urteile nicht über Menschen, die du nicht kennst und von denen du nicht weißt, was sie tatsächlich tun oder können. Und immer noch kam von dir kein produktiver Beitrag, sondern auch weiterhin nur bescheuerte Tipps, was wir gefälligst tun und lassen sollen, wir Menschen, die keine Ahnung haben.
Wir HABEN getestet und recherchiert, dennoch hindert einen das ja nicht daran, andere Meinungen einzuholen!
Das hier ist ein Frage-Antwort-Spiel. Eine Person wünscht den Rat anderer auf eine Fragestellung, diese geben diesen Rat bzw. versuchen, die Fragestellung zu beantworten. Eigene Meinungen, die nichts mit dem eigentlichen Thema zu tun haben, sind selbstverständlich vorhanden, haben aber hier nichts verloren, da sie nichts zur eigentlichen Sache beitragen.

Ich verbitte mir also zukünftig solche Unterstellungen. Der einzige, der hier keine Ahnung hat, bist du, denn du hast eben keine Ahnung von dem, was wir tun bzw. getan haben, um der Sache auf den Grund zu gehen.
--> Wie geht der Spruch? Wenn man keine Ahnung hat, einfach mal die ... Futterluke halten.

mit anschließender gemeinsamer
praktischer Übung an einer echten Steuerung


Ich weiß, ich sollte ruhig sein und dir das letzte Wort lassen, aber wenn ich solche blöden, hämischen Kommentare lese... Ich weiß nicht, weshalb du in diesem Forum bist oder mit Steuerungen zu tun hast (was du, wie gesagt, IMMER NOCH NICHT unter Beweis gestellt hast), aber ob dus glaubst oder nicht, wir tun es täglich. Erfolgreicher als so manch anderer.

Ich möchte jetzt diese Unterhaltung beenden und habe die Hoffnung noch nicht aufgegeben, dass du Koriphäye der SPS-Programmierung endlich dein ganzes besserwisserisches Gehabe rechtfertigst und mir auf den Punkt sagst, ob eine OUT-Variable eines FB, von dem im Programm mehrere Instanzen aufgerufen werden und die nicht in jedem Zyklus beschrieben wird, im laufenden Betrieb ohne Einfluss von außen oder Änderung am Programm den Wert der letzten Beschreibung beibehält oder auch Zufallswerte annehmen kann bzw. zurückgesetzt wird o.ä., natürlich mit ausführlicher und einleuchtender Begründung, die du auch entsprechend beweisen kannst.

Bei allen anderen, die auf meine ursprüngliche Frage geantwortet haben, möchte ich mich für diesen Hickhack mit UniMog in aller Form entschuldigen, das gehört hier nicht hin, aber ich hoffe, ihr könnt meinen Unmut verstehen. Des Weiteren möchte ich mich natürlich bei ihnen für ihre Antworten bedanken, weiter so!
 
Zurück
Oben