Step 7 Funktionsbausteine Ausgangsparameter

[Junge]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich wollte mir einen Funktionsbaustein erstellen und verwendet werden IN, OUT, STAT Variablen, allerdings habe ich damit noch nicht viel gearbeitet.
Jetzt die Fragen:

Wenn ich in diesem FB eine OUT Variable über eine PF Setze, ist diese dann Dauerhaft gesetzt oder verhält sich diese wie eine TEMP Variable und hat einen undefinierten Zustand sobald ich den FB verlasse? Oder muss ich eine STAT Variable über die PF setzen und damit die OUT Variable setzen?

Angenommen Sie bleibt dauerhaft gesetzt, wie kann ich diese OUT Variable zurücksetzen?
über eine extra IN Variable mit einem extra NW im FB, wo diese OUT Variable zurückgesetzt wird oder direkt auf den Instanz DB die OUT Variable zurücksetzen?

 

[RobiHerb]

Nicht alles ist vom Verhalten definiert.

Den FB rufts Du regelmässig auf, nach dem Verlassen des FB stehen in den Out Variablen die Werte, die Du reingeschrieben hast. Diese Werte bleiben GARANTIERT erhalten, bis Du das nächste mal in den FB einsteigst. Wenn der Compiler es überhaupt zulässt, dass Du aussrhalb des FB auf diese Variablen schreibst, ist er schwach, zumindest sollte er warnen.

Innerhalb des FB schreibst Du die Out Variablen. Wenn Du nicht schreibst, könntest Du ein Problem bekommen, das Verhalten ist dann wohl NICHT GARANTIERT. Wenn Du liest, bevor Du schreibst, sollte der Compiler ebenfalls warnen.

Lesen nach schreiben und wiederum schreiben sollte innerhalb des FB zulässig sein, ist aber "schlechter Stil", d.h. in unserer Firma spätestens beim Review durchgefallen.

 

[Junge]

Zuviel Werbung?
-> Hier kostenlos registrieren

d.h. einmal den FB aufgerufen und eine OUT Variable hat den Status TRUE , bleibt diese Variable solange auf True bis ich den FB erneut aufrufe und die Variable durch die Verknüpfung den Status False bekommt. Daraus schließt sich aber auch, dass ich diese OUT Variable dann auch nur innerhalb des FB´s zurück setzen kann.

Also die OUT Variable verhält sich ähnlich wie die STAT Variable bzgl. des Status.

Ok, Danke. Denke das hat mir weitergeholfen.

 

[PN/DP]

Bei Step7 muß man einem FB-OUT nicht bei jedem Aufruf etwas zuweisen. Ohne Zuweisung behalten die OUT ihren Wert - sie verhalten sich wie STAT.

Allerdings können die OUT-Parameter von außerhalb des FB direkt beschrieben werden - deshalb ist es NICHT garantiert, daß sie beim nächsten FB-Aufruf noch den Wert vom vorherigen Aufruf haben. Und deshalb warnt der TIA-Compiler, wenn ein FB-OUT innerhalb des FB gelesen wird.

Harald

 

[Paul]

.... und deshalb warnt der TIA-Compiler, wenn ein FB-OUT innerhalb des FB gelesen wird.

Das ist also der Hintergrund für diese BLÖDEN NERVIGEN Warnungen, die an dieser Stelle immer aufpoppen.
Da muss man erst mal drauf kommen.

Typisch TIA. Für jeden der halbwegs weiß was er macht sind diese "Verbesserungen" einfach nur lästig.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, ich hab gestern auch versucht, die Warnungen wegzubekommen, indem ich Temp-oder Star-Variablen nutze und am Ende erst auf OUT schreiben. Aber das sind rel. viele und irgednwie sah das auch nicht so toll aus, am Anfang ein par Variablen lesen, am Ende schreiben, muß eigentlich nicht sein.
Noch nerviger sind die Warnungen "Diese Variable ist evtl. nicht initialisiert". Die kann man teilweise gar nicht umgehen. Wenn ich am Ende eines FB einen SFC/SFB (z.B. für TCP/IP) aufrufe und der hat eine Fehlermeldung als OUT, dann lege ich die auf eine Stat-Var, werte die nach dem SFC/SFB aus und gebe einen Fehler aus. Aber natürlich wird die Stat-Var erstmals erst am Ende des FB geschrieben. Frage ich diese Stat-Vat aber am Anfang ab, wo z.. in einer Case-Anweisung in Schrift xy der Start für den SFC/SFB drinsteht, gibt es o.g. Meldung. Initialisieren direkt am Anfang des FB geht nicht, dann überschreibe ich die Fehlermeldung, in einer IF ... Then -Anweisung mit einer extra INIT-Flanke geht zwar, aber auch hier gibts eine Warnung. Wie löst ihr das? Ignorieren? Denn der FB funktioniert, es geht ja nur darum, in Fehlerfall keinen Start zu geben.

 

[Paul]

... Wie löst ihr das? Ignorieren?

Ignorieren, Augen zu und durch.

Mistgelumpp, verrecktes.

 

[borromeus]

Also eine OUT-Variable ausserhalb eines FB's zu beschreiben stellt- ich sage mal einen zumindest- problematischen Umgang dar.
Mag sein, dass es Fälle gibt wo man das machen muss, mir fällt gerade keiner ein.

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und außerdem gibt es ja auch noch INOUT.

 

[Junge]

... hätte da nochmal eine Frage.

Zu meinen erstellten FB100 habe ich mir einen Instanz DB100 erstellt.

Wenn ich jetzt nun meinen FB100 z.B. 5 mal in einem Funktionsbaustein Aufrufe, muss ich dann jeweils einen eigenen Instanz DB dafür erstellen oder Kann ich jedesmal den gleichen DB100 verwenden?

 

[borromeus]

Da brauchst Du natürlich jedes mal einen neuen IDB.
Noch besser ist es wenn Du den FB multiinstanzierst.
Das heisst Du legst eine STAT-Variable an.
Im Stat Bereich schreibst Du bei "Name" Fb-Aufruf und bei Datentyp "FB100" hin.
Dann legt dir die Software innerhalb der FB-Instanz einen Aufrufinstanz-Db an.
Probiers mal aus...

Edit: selbstredend, dass in Deinem FB100 keine Merker, Zeiten, Zähler, etc. mit fixen Nummern verwendet werden dürfen.

 

[Junge]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für den Tipp.

https://support.industry.siemens.co...stellt-und-aktualisiert-werden?dti=0&lc=de-DE

 

[RobiHerb]

Deklaration und Initialisierung gehören zusammen.

Ignorieren, Augen zu und durch.

Mistgelumpp, verrecktes.

Ignorieren ist ggf. bei der Spielzeugeisenbahn Steuerung erlaubt.

In der Softwaretechnik gilt die alte Erfahrungs Regel "Deklaration ist Initialisierung". D.h., wo Du eine Variable neu einführst, wird sie auch sofort auf einen Wert gesetzt. In modernen Sprachen wie C# wird das sogar erzwungen.


Genauer kann man hier sich informieren:

Ich hab das mal hier illustriert, wie ich das in ST/Codesys programmiere.





und so stellt es sich im Debugger dar, man sieht einmal initialisiert und dann in jedem FB Aufruf einmal geschrieben.

 

[PN/DP]

Ignorieren, Augen zu und durch.

Mistgelumpp, verrecktes.

Ignorieren ist ggf. bei der Spielzeugeisenbahn Steuerung erlaubt.

Paul meint, daß er die Compiler-Warnungen ignorieren will statt alle betroffenen Programmstellen umzuschreiben (vermutlich weil das Programm vor der Konvertierung zu TIA ja auch funktioniert hat?).

Wir sind hier bei Siemens-SCL (oder -AWL?)
Und bei Siemens-TIA bekommst Du für Dein "iStart := iRet;" eine Compilerwarnung, weil ein OUTPUT nicht dafür gedacht ist, wieder eingelesen zu werden. Wenn der Wert des OUTPUT gemerkt werden soll, dann soll man das über eine STAT-Variable und anschließendes Kopieren auf den OUTPUT lösen (oder einen INOUT benutzen).

Rücklesen eines OUTPUT ist auch aus folgendem Grund problematisch:
ein FB hat 2 OUTPUT, wo außen jedesmal die selbe Variable angeschlossen ist. Wenn im FB der erste OUTPUT zurückgelesen wird, welchen Wert sollte das Lesen ergeben? Den Wert, den die außen angeschlossene Variable gerade hat oder den Wert, der zuletzt an den ersten OUTPUT zugewiesen wurde?

Für ein Beschreiben des Instanz-Ausgangs von außerhalb (z.B. "Instanz.iRet := 0;") gibt es meines Wissens keine Warnung. Der Schreibzugriff könnte ja auch von einem HMI kommen und das kann der Compiler schließlich auch nicht verhindern.

In der Softwaretechnik gilt die alte Erfahrungs Regel "Deklaration ist Initialisierung". D.h., wo Du eine Variable neu einführst, wird sie auch sofort auf einen Wert gesetzt.

Mir erschließt sich nicht, was eine Initialisierung mit dem hier diskutierten Merken und Lesen eines OUTPUT zu tun hat.

Harald

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warnungen ...

@PN/DP

Compiler Warnungen sind Warnungen, dass da etwas falsch sein könnte.

Wer sie ignoriert und "Augen zu und duch sagt", bekommt im Falle eines Unfalls mit seiner Software sehr leicht Fahrlässigkeit vorgeworfen.
Das kann bis hin zu Gefängnis führen.
Compiler Warnungen sind kein Schicksal sondern vermeidbar, da musst Du durch.
"Geht schon, haben wir immer so schon bei STEP7 gemacht", ist gefährlich auch für Dich selber.

Dass ich in dem Beispiel in der ersten Programmzeile iStart := iRet; schreibe, ist natürlich nicht das Gelbe vom Ei. Diese Zeile macht nur mit dem 3.Screenshot einen Sinn. Ich wollte zeigen, dass bei Erreichen des Breakpoint in der letzten Zeile der FB bei Eintritt diesen Startwert in iRet hatte. Sonst hätte ich jeweils single Step Screenshots machen müssen. In Production Code sollte die angemerkte erste Zeile natürlich nicht vorkommen.

Initialisierung bei der Deklarierung: siehst Du doch in der Deklaration, jede Variable ist initialisiert.



Ansonsten, wo man über VAR_OUT redet, sollte man auch mal über Properties sich Gedanken machen, PRIVATE SET im FB und PUBLIC GET sind die sicherste Antwort, wie man Daten aus einem FB nach draussen bekommt.

Übrigens, ich mache für solche Spielzeuge Software, da hat der TÜV oder vergleichbar ein Auge auf alle Programmzeilen.

Anhang anzeigen 32062 Rettungsfahrzeug mit 6 redundanten Intercontrol SPS + 2 unabhängige Visus im Chassis und on Top, 3 parallele redundante Bussysteme.

http://www.rptc.de/


250 MeV Cyclotron gesteuert durch Siemens Safety SPS (genaueres darf ich nicht sagen). Das Monster ist die Protronen Strahlenquelle für eine spezielle Krebs Therapie. Hier hatte ich während der Entwicklung für die Software des Sicherheits Bedien Systems die Verantwortung.

Dann gab es einen Unfall, am besten mal dieses Forum ansehen.

http://forum.prostatakrebs-bps.de/s...ll-am-Rinecker-Protonentherapiezentrum/page2&

Da wird jede Programmzeile durchgekämmt und wehe Dir, wenn da Warnungen im Compiler auftreten.

 

[Paul]

Ignorieren ist ggf. bei der Spielzeugeisenbahn Steuerung erlaubt.

Ich glaube nicht, dass ich planlos oder leichtsinnig programmiere
Aber ich programmiere auch keine Atomkraftwerke oder Raketensilos.

Wenn ich mir anschaue wie inflationär die gelben Ausrufezeichen beim generieren auftauchen....
da hätte ich viel zu tun, wenn ich die alle ausmerzen wollte.

Bis jetzt hat mein Zeug (früher oder später) eigentlich immer funktioniert.
Und gerade bei TIA sind eben viele Warnungen eigentlich überflüssig,
Als Beispiel eben genau diese Geschichte mit dem Lesezugriff auf OUT Variablen.
Wenn man nicht total "von hinten durchs Knie" programmiert, passiert da gar nichts.
Trotzdem kommt jedes mal ein lästige Warnung.
Sprungmarken in AWL.
Andauernd wird irgendwas Rot, reicht manchmal schon wenn Du den Cursor hinter die Marke stellst
Aus diesem Grund: Augen zu und durch.....

 

[Paul]

250 MeV Cyclotron gesteuert durch Siemens Safety SPS (genaueres darf ich nicht sagen). Das Monster ist die Protronen Strahlenquelle .........

Und wenn ich solche kreuzgefährlchen Sachen programmieren müsste, würde ich
mir dreimal überlegen ob ich da TIA einsetze.
Meine Anlagen (mittelständischer Maschinenbau) sind um Glück eine Nummer simpler.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Initialisierung bei der Deklarierung: siehst Du doch in der Deklaration, jede Variable ist initialisiert.

Anhang anzeigen 32061

Mit was für einem Nicht-IEC-konformen System programmierst du denn da? Denn die IEC61131 gibt die Initialwerte bei elementaren Datentypen vor, und die sind bei INT := 0. Das heißt was du da in deinem Screenshot zeigst ist überflüssig, da in der Norm festgelegt.

Aber Codesys nimmt es mit der IEC-Konformität ja eh nicht so genau, da sind mindestens so viele Abweichungen vom Standard wie bei Siemens SCL. Wobei Siemens die Abweichungen davon wenigstens vollständig dokumentiert hat. Außerdem gibt es von Siemens eine formale Sprachbeschreibung, nach so etwas sucht man bei den Codesys-Leuten vergeblich.

 

[Thomas_v2.1]

Und solche Typ-Prefixe benötigt man auch nur, wenn es der Compiler erlaubt wie im Saustall jeden Datentyp ohne Warnung mit impliziter Konvertierung auf einen anderen zu ferkeln (Codesys). Bei Siemens lassen sich solche Schweinereien wenigstens per Einstellung verbieten. Bei Codesys? Fehlanzeige.

 

[oliver.tonn]

Hallo Thomas,
könntest Du da mal bitte konkreter werden, bei welchen Datentypen das passiert? Wenn ein INT in einen DINT geschrieben wird kann man warnen aber man muss es nicht. Ich sehe das jetzt nicht als so problematisch an.