Baustein mit IN & OUT Paramtern, oder INOUT`erstellen?

Bensen83

Level-1
Beiträge
777
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
`Hallo Leute, ich habe mal eine geschmacksfrage für euch.

Ich habe nen Baustein, welcher folgende Parameter liest:

Parameter A, Parameter B, Parameter C

Er schreibt zusätzlich Parameter D und Parameter E

Wie würdet Ihr es progrommieren:

1. 3 Eingänge und 2 Ausgänge

2. Einen Eingang mit Struktur (enthält Parameter A,B und C) und einen Ausgang mit Struktur (Enthält Parameter D und E)

3. Einen INOUT Mit einer Sruktur (Enthält Parameter A, B, C, D und E)

Danke für Eure Meinungen
 
Wenn das aufrufende Programm die selben Daten mit mehreren aufgerufenen FB's austauscht, z. B. Maschinen-PRG <-> Arbeitsstations-FB's, bevorzuge ich Variante 3.
Ansonsten eher 1.
2 ist vor allem bei Eingängen ungünstig, weil man beim FB-Aufruf dann keine einzelnen Elemente des Structs übergeben kann. Bei Ausgängen mache ich das dagegen schon mal, wenn die Ausgangsstruktur vor allem dazu dient, als Ganzes an weitere FB's übergeben zu werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
2 ist vor allem bei Eingängen ungünstig, weil man beim FB-Aufruf dann keine einzelnen Elemente des Structs übergeben kann.

Das sollte ja der Sinn meiner Überlegung sein, dass ich eben nicht so viele Eingänge habe.
Denn wenn ich eine Struktur mit 10 Variablen habe, ist es doch schöner diese Struktur zu übergeben, als 10 mal die einzelen Variablen, oder habe ich dich da falsch verstanden?
 
Wenn bei JEDEM Aufruf ALLE Eingangsvariablen übergeben werden sollen, kann man sie dafür in ein Struct packen. Wenn nicht, sind einzelne Variablen besser.
 
Wenn bei JEDEM Aufruf ALLE Eingangsvariablen übergeben werden sollen, kann man sie dafür in ein Struct packen. Wenn nicht, sind einzelne Variablen besser.

INOUT als struct ist immer beste Wahl, und in der CoDeSys ST Umgebung die einzige Parameter Übergabe "Per Reference" sonst immer "Per Value"

genaueres: http://de.wikipedia.org/wiki/Referenzparameter

http://blog.gungfu.de/archives/2005...zwischen-call-by-value-und-call-by-reference/

oder kurz gesagt, wer es einsetzt und versteht, wo der Unterschied liegt, bekommt schnellere Zykluszeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Überhaupt eingaben???

Was würdest du denn sagen, wenn ich eine Struckt habe, welche ich an einen FB übergebe und diese in diesem verarbeitet wird.
Bspw. Für Eine Ventilansteuerung. Ist es dann sinnvoll eine Variable von diesem Strukttyp zu erstellen und an die FB instanz zu übergeben.

So dass ich im programm mit der strukt arbeite.

ODER:

Wäre es vielleicht sinnvoll auf die übergabe und deklaration der variable zu verzichten und imKompletten programm einfach auf die einzelnen Parameter der instanz zuzugreifen?

Ich mache mal ein Beispiel:

Ich habe eine Instanz Ventil_1 und eine Variable Status.

Nun möchte ich mittels Aktion das Ventil ansteuern. und auf den Status reagieren.


1. Variante (Mit Variable)

Ventil_1.vor();

IF Status = Position_erreicht THEN
.
.
.


2. Variante (direkt auf Instanzen zugreifen)

Ventil_1.vor();

IF Ventil_1.Status = Position_erreicht THEN
.
.
.




Also Bei Variante 2 greife ich direkt auf den Status der Instazn zu und habe somit schon eine optische Zuordnung. (Finde ich zumindest).


Was findet ihr besser, bzw. Sinnvoller?
Nachteil ist eben, wenn ich keine Ausgänge anlege, sieht man auch nicht, was an dem FB alles für Werte abrufbar sind.
Eine weitere Möglichkeit wäre den FB mit ein und Ausgängen zu versehen, jedoch diese nicht zu beschalten und trotzdem direkt auf die Instanzen zuzugreifen. So würde man wenigstens die Ausgänge sehen (Ist aber auch etwas unschön, da man auf die Idee kommen könnte, wenn der Ausgang nicht belegt ist wird er auch nicht verwendet. Was meint ihr?
 
Hallo,
also meine Präferenz bei der Datenhaltung ist die Zusammenfassung aller Daten in logischen Einheiten (also Strukturen).

Wenn die Parameter A,...E logisch zusammen gehören (also z.B. Laufzeitvariablen eines Ventils) dann in einem Datentyp zusammengefasst. Dieser als Pointer an alle FUBs übergeben die damit irgendwie arbeiten können / müssen.

Damit kann man Online auch direkt nur die Variablen-Instanz beobachten und muss nicht einmal die Eingänge von einem Fub und dann wieder Ausgänge von einem anderen FUB beobachten.

Für Diagnosezwecke (bei Projekterstellung usw. ) kann man auch mal ganz schnell interne Variablen in die Struktur einbinden und man kann auch diese dann ganz eindeutig mit den Parametern diagnostizieren...

Die Übergabeliste an den Fub bleibt somit auch schlank und auf wenige Pointer beschränkt.

bg
bb
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Damit kann man Online auch direkt nur die Variablen-Instanz beobachten und muss nicht einmal die Eingänge von einem Fub und dann wieder Ausgänge von einem anderen FUB beobachten.
Kannst Du mir mal bitte einen Screenshot vom Online-Beobachten der Variablen machen?

Harald
 
Ventilbaustein

angenommen ich würde gerne einen FB schreiben, welcher ein ventil ansteuert (vor und zurueck).

Würdet ihr es so machen, dass ich bools als ansteuerbefehle habe und diese dann mit if ... then abfrage und den ausgang dem entsprechende setze,

oder würdet ihr da irgendwie ne aktion oder so erstellen? Bspw. aktion Ventil.vor();

Das blöde wäre dann natürlich wieder, dass ich einmal die Variable hätte (IN_OUT) und einmal die instanz mit der aktion. --> eine sache mit 2 unterschiedlichn namen ansprechne gefällt mir dann nicht so.

Was meint ihr?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
eine sache mit 2 unterschiedlichn namen ansprechne gefällt mir dann nicht so.
Wieso unterschiedliche Namen?
Mit einer Aktion sieht es so aus: Ventil.Vor();
Wenn "Vor" eine Input-Variable des FB's ist, dann so: Ventil.Vor:=True; oder Ventil(Vor:=True);
Die Zuordnung zur Instanz geht doch in beiden Fällen aus dem Programmtext hervor.
 
Ja schon klar, aber wenn ich als eingabe eine Struktur habe die bspw. "Ventil_schiebetuer" heist und der FB eine instanz hat "INST_Schiebetuer" dann würde ich alle parameter mit Ventil_Schiebetuer.xy ansprechen und die aktion mit INST_Schiebetuer.xy(); das meinte ich.

oder würdest du die Eingänge garnicht belegen und direkt auf die Instanz zugreifen?
 
Warum willst Du unbedingt eine Struktur "Ventil_schiebetuer" ausserhalb des FB's haben? Deklariere die darin enthaltenen Daten doch als VAR_INPUT/VAR_OUTPUT des FB's. Ein FB ist doch nichts anderes als eine Struktur, an der zusätzlich noch der zu ihrer Bearbeitung dienende Code dranhängt. Dann brauchst Du im PRG nur auf die FB-Instanz zugreifen, z. B. FB.Aktion(), FB.Input:=True, IF FB.Output THEN...
 
Zurück
Oben