Funktionsbausteine

Zuviel Werbung?
-> Hier kostenlos registrieren
Möglicherweise meint er, daß man an IN_OUT keine PEW oder PAW "anschließen" darf. Doch alles andere - auch E und A - kann man problemlos anschließen. Ob das was möglich ist auch Sinn macht steht auf einem ganz anderen Blatt. Sinnvolle Lösungen zu finden lernt man nicht unbedingt in einem Programmier-Lehrgang.

Harald
GENAU ...und Konstanten und Arrays auch nicht ... mit dem "Programmier-Lehrgang" hast 100% recht ...insbesonderes wenn eher autodidaktish ist ... Arbeitsamt Kurs eh :)
 
Das man keine Konstanten an IN_OUT parametrieren kann ist klar, aber ARRAY und STRUCT kann ich doch als IN_OUT verwenden. Sie werden halt nicht initialisiert weil im IDB nur der Zeiger auf die Adresse steht, oder lieg ich da falsch?
 
Das man keine Konstanten an IN_OUT parametrieren kann ist klar, aber ARRAY und STRUCT kann ich doch als IN_OUT verwenden. Sie werden halt nicht initialisiert weil im IDB nur der Zeiger auf die Adresse steht, oder lieg ich da falsch?
Beim Strommausfall wirst Probleme bekommen ohne Initialisierung !
 
Zuletzt bearbeitet:
Ich kann ja im FB initialisieren, genauso wie ich das mit jeder OUT oder STAT variable mache.
 
Mit ST kannst alles triksen aber es dauert SICHER länger als FUP oder LADDER ! ...meiner Meinung nach .Stell dir vor du hast andere INITIALWERTE als nur 0 oder nur 1 im array ... ist nicht besser gleich 2 arrays zu haben ?
Wann wird das gelesen :
FOR i = 1 TO (nArrayLaenge)
array := "false" oder "0" oder "1"
END_FOR

In jeder Bearbeitungszyklus ?
:confused:

Rede schon wieder Unsinn ? :(
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich will ja nichts tricksen, ich will nur mit den mir gegebenen Werkzeugen schnellstmöglich ans Ziel kommen. Und wenn ich eine Struktur oder ein Array als IN_OUT Parameter am Baustein brauche und es da Sinn macht, dann werde ich dass da auch einsetzen. Wie ich dann mein Zeug im FB initialisiere oder ob ich das da überhaupt brauche steht auf einem anderen Blatt.

edit: und bei mir gibts keine anderen Initialwerte als 0 in einem ARRAY... entweder ich initialisiere was oder nicht!
 
Zuletzt bearbeitet:
Ach und mit Deiner a+b=c funktion


Code:
VAR_IN_OUT
     a := DINT;
     b := DINT;
     c := DINT;
END_VAR;

c := a + b;
a := c + 1;


Jetzt aber bitte nicht fragen ob das Sinn macht oder nicht...;) Die cpu geht aber nicht in Stop wenn ich das laufen lasse.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
edit: und bei mir gibts keine anderen Initialwerte als 0 in einem ARRAY... entweder ich initialisiere was oder nicht!

Heisst initialisieren (nur) nullen oder auch (irgendwelche erwünschte) STARTWERTE geben ???

http://de.wikipedia.org/wiki/Variable_(Programmierung)

" Variablen sollten vor ihrer Benutzung initialisiert werden, das heißt, einen definierten Wert zugewiesen bekommen. "

Hat es in der SPS andere Bedeutung ? ... habe manchmal auch andere STARTWERTE als Null benutzt ( wäre das nicht mehr "initialisieren" ?
:confused:
 
Zuletzt bearbeitet:
Die Wortklauberei macht doch keinen Sinn.

Das Zitat stammt vermutlich aus der Hilfe zum Thema TEMP-Variablen.

Bei TEMP-Variablen ist es nun mal so, dass diese mit "irgendwas" zugewiesen sein müssen, um einen definierten Wert für die weitere Verwendung im Baustein zu haben. Das kann man jetzt meinetwegen nennen wie mal lustig ist, das ändert aber nichts an der Sache.
 
Wie schon einer gesagt hat, haben FB ein Gedächtnis. Ihre Instanz. Bei Siemens ist das ein DB.
Dieser bekommt schon in der Entwicklungsumgebung (TIA oder Step7V5 oder noch älteres Zeug -- und auch bei CodeSys) Werte, welche auf die AS geladen werden. Damit sind die immer initialisiert.
Wenn der Strom wieder kommt, dann ist es bei S. möglich die Werte wieder aus dem Ladespeicher zu holen. Also sind sie auch da wieder initialisiert.
FB Parameter müssen nicht verschaltet werden, da diese Werte ja in der Instanz liegen. Außer bei komplizierten Datentypen im IN-OUT. Dort werden im DB nur Pointer hinterlegt, der eigentliche Wert liegt wo anders.

Und jetzt kommt mal wieder Siemens-Spezialverwirrung:

Wenn also kein einziger FB Aufruf den komplizierten IN-OUT versorgt, dann steht da ein Null-Pointer drim. Beim Zugriff auf diesem IN-OUT innerhalb des FB geht die CPU in STOP (oder OB121).
Vollprofis (oder sollte ich hier Vollpfosten sagen) haben noch die Möglichkeit im DB-Editor in den Pointer was rein zu schreiben. Also mit dieser grottigen Syntax P#DBa.DBXb.c den Zeiger auf einen hoffentlich vorhandenen DB zu lenken. Schlechter Stil, gaaaanz schlechter Stil sowas. Wenn das nicht klappt, dann suchst du stundenlang nach etwas was nicht da ist (da sucht man ja bekanntlich am längsten nach)

Eine Struktur im IN-OUT (per Referenz übergeben) wird mit Peripherie versorgt. Bloß unterscheidet der Pointer nicht zwischen PE und PA. Der kennt nur P. Der Befehl im FB entscheidet dann ob von PE gelesen oder nach PA geschrieben wird. Du denkst, dass du da ein PEW angelegt hat, aber drinnen schreibt er dir auf das PAW mit der Nummer. HEUL
Das mit den Peripheriezugriffen sollte man bei Siemens bleiben lassen.

Noch schlimmer ist das bei FC. In Step7V5 ist es erlaubt an einen Input eines FC vom Typ sagen wir mal DWORD z.B. ein PAD20 dran zu schreiben. Im FC darfst du sowohl auf den Input schreiben als auch von ihm Lesen. D.h. wenn du liest bekommst du PED20, wenn du schreibst PAD20. Bei Siemens werden bei den CPU 300 und 400 auch FC Parameter immer per Referenz übergeben. noch mehr heul.

Bei einfachen Datentypen verhält sich der Siemens FB eher so, wie es die Begriffe IN OUT und INOUT suggerieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Deswegen habe ich gemeint IN-OUT Variablen sind mit Vorsicht zu genissen !
Vielen , vielen DANK HelleBarde ...sehr gut erklärt (für mich mindestens ) .

Einen Hinweis :
- beim Stromausfall ist die Anlage in irgendeinem SCHRITT ... die Daten in der DB sind remanent (wenn so eingestellt) gehen also nicht verloren , sind aber mit der Daten des unterbrochenen Schrittes belegt .
Beim Neustart muss diese Schritt neu gestartet werden also es wäre möglich dass die DB mit Daten von der vorherigen Schritt belegt werden muss... (Stichwort INITIALISIEREN )

DAS GEHT ABER aber bei STRUCT , ARRAY typen NICHT!
Initialisiert müssen die Daten in DB auch beim Neustart nach Stromausfall ... oder Manuell Sprung zu irgend einem manuell gewählten Kettenschritt !

Hoffe jetzt ist es klar was ich weiter zurück meinte !?!
 
Zuletzt bearbeitet:
Ich glaube ihr redet von zwei verschiedenen Dingen.

Und In_Out sind nicht vorsichtiger zu geniessen wie alles andere. Wenn man "einigermassen" vernünftig programmiert geht davon nicht der Hauch einer Gefahr aus. In diesem Tread wäre die Pointerproblematik nichteinmal erwähnenswert gewesen sondern verkompliziert die Sache für den Leser völlig unnötig.

mfG René
 
Ich würde INOUT Variablen sowieso nur für rekurrente Funktionen ( Funktionen auf sich selbst ) benutzen .
Einfacher Beispiel wäre ein 1-Addierzähler
"a" INOUT Variable
a : a+1

Bei jedem FC Durchlauf wird "a" Flankenabhängig um 1 erhöht ....
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Deswegen habe ich gemeint IN-OUT Variablen sind mit Vorsicht zu genissen !

Nein. Deswegen lässt man eben keine dressierten Affen an das PG.

Ich kann doch als Benutzer einer Software nicht erwarten, dass der Compiler jeden erdenklichen Fehler des Anwenders erkennt.
 
Einen Hinweis :
- beim Stromausfall ist die Anlage in irgendeinem SCHRITT ... die Daten in der DB sind remanent (wenn so eingestellt) gehen also nicht verloren , sind aber mit der Daten des unterbrochenen Schrittes belegt .
Beim Neustart muss diese Schritt neu gestartet werden also es wäre möglich dass die DB mit Daten von der vorherigen Schritt belegt werden muss... (Stichwort INITIALISIEREN )

DAS GEHT ABER aber bei STRUCT , ARRAY typen NICHT!
Initialisiert müssen die Daten in DB auch beim Neustart nach Stromausfall ... oder Manuell Sprung zu irgend einem manuell gewählten Kettenschritt !

Ein linearer oder auch ein verzweigter Ablauf ist schnell programmiert, ohne sich viele Gedanken zu machen.

Ein sauberer Wiedereinstieg nach einem Abbruch o.ä. erfordert halt etwas Hirnschmalz. Ich muss doch nur wissen, ob meine Schrittkette immer im letzten Schritt steht und was ich bei Wiederanlauf machen möchte. Das kann man dann sauber ausprogrammieren. Und für mich spielt es da erstmal keine Rolle, welche Art der Schrittkettenprogrammierung man gewählt hat.
 
Ich würde INOUT Variablen sowieso nur für rekurrente Funktionen ( Funktionen auf sich selbst ) benutzen .
Einfacher Beispiel wäre ein 1-Addierzähler
"a" INOUT Variable
a : a+1

Bei jedem FC Durchlauf wird "a" Flankenabhängig um 1 erhöht ....

Ich bin stolz auf dich. Dafür ist die InOut Definition da. Für Zugriffe von denen gelesen und gleichzeitig geschrieben werden soll.
Ob man da jetzt nur liest, ne eins dazu addiert und dann schreibt...
oder ob man liest, zweihundert Funktionen/Berechnungen etc. ausführt und dann irgendwann draufschreibt ist eigentlich absolut dasselbe.

Darauf wurde ja am Anfang ja schon ausgiebig hingewiesen.
 
Zurück
Oben