Reihenfolge der Variablen im DB festlegen

[Franky08]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

in meinem SCL Programm (FB) deklariere ich einen UDT folgendermaßen:

VAR
Parameter := UDT10;
END_VAR

Weiterhin deklariere ich mehrere Ein- und Ausgangsvariablen.

Ich möchte gerne, dass der UDT als erstes in den Instanz-Datenbaustein eingefügt wird und dann erst die anderen Variablen folgen.

Leider werden Ein- und Ausgangsvariablen jedoch vor den statischen Variablen im Instanz-DB angelegt.

Gibt es eine Möglichkeit diese Reihenfolge zu ändern. Also das die statischen Variablen als erstes im Instanz-DB angelegt werden?

Oder besteht die Möglichkeit dem UDT eine feste Anfangsaddresse im DB zuzuweisen?

Hintergrund ist, dass ich einem anderen FB die Anfangsaddresse des UDT in meinem DB übergeben muss.

Wenn ich jetzt irgendwann mal neue Ein- und Ausgangsvariablen hinzufüge, wird sich die absoulte Anfangsaddresse ja ändern. Das ist nicht so schön.
Und um Fehler zu vermeiden, hätte ich da gerne eine feste Addresse.

MFG.

Frank

 

[sps-concept]

Stat

Hallo,

nein die Reihenfolge im IDB ist fix. Bei Änderungen in der Schnittstelle rutscht alles nach. Querzugriffe von anderen Bausteinen auf einen fremden IDB sind unschön!! Leg lieber die bereitgestellten Daten in einer UDT eines globalen DBs ab die du an den FB als IN, OUT oder INOUT (je nach Zugriff) übergibst.

André

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deklarieren als IN-Variable

Hallo Franky08,

deklariere Deinen UDT im FB als erste IN-Variable und lasse den Parameter beim Bausteinaufruf unbeschaltet.
Dann liegt der UDT immer am Anfang im IDB und es hat den Vorteil, daß der UDT wenigstens in der offiziellen
Bausteinschnittstelle als Übergabeparameter veröffentlicht ist.

Alle IN/OUT/IN_OUT-Parameter können außerhalb des Bausteinaufrufs gelesen und beschrieben werden!
z.B.:

[B]VAR_INPUT[/B]
Parameter := UDT10;
...
END_VAR
...

L "FB_Instanz".Parameter.member1
T "FB_Instanz".Parameter.member2
L "FB_Instanz".invar
T "FB_Instanz".outvar

Der leider mögliche Zugriff auf STAT-Variablen eines IDB von außerhalb sollte für disziplinierte Programmierer absolut
tabu sein (Stichworte: Kapselung, private lokale Variablen, Wiederverwendbarkeit, dokumentierte Schnittstelle).

MfG
PN/DP

 

[Onkel Dagobert]

Hallo N/DP,

..deklariere Deinen UDT im FB als erste IN-Variable und lasse den Parameter beim Bausteinaufruf unbeschaltet..

Wie macht man das?


Gruß, Onkel

 

[PN/DP]

wie macht man das?

Hallo Onkel,

wie macht man was?
? als IN-Variable deklarieren? -> siehe Beispielcode VAR_IN...END_VAR
? beim Aufruf unbeschaltet lassen?

CALL "FB_Instanz","IDB"
  Parameter :=                //<- hier nichts ranschreiben (geht nur bei FB)
  invar     :=MW20
  ...
  outvar    :=MW40

MfG
PN/DP

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo PN/DP,

? beim Aufruf unbeschaltet lassen?[/quote]
Ist zumindest bei FBs ungewöhnlich. Werd's bei Gelegenheit mal testen.
 
Gruß, Onkel

(Sorry, acht Staeks und zwei Bier :sm24:)

 

[PN/DP]

Bausteinparameter unbeschaltet lassen

Hallo Onkel,

Bausteinparameter bei FB unbeschaltet lassen kommt häufig vor, z.B. beim Regler-Baustein FB41 werden eigentlich nie alle Parameter beschaltet, weil es da für die Reglerparameter das extra-Tool "PID Assistent" (oder so ähnlich) gibt, das die Parameter direkt in den IDB schreibt. Und die sollen ja nicht überschrieben werden.

In anderen Programmiersprachen wie IEC 1131 geht es manchmal garnicht anders (oder nur über Zwischenvariablen). Da wird oft ein Eingangs-Parameter vor Aufruf des FB beschrieben. Oder ein FB-Ausgangsparameter im nachfolgenden Programm mehrmals direkt abgefragt: L "FB_Instanz".outvar

Gruß
PN/DP

 

[vierlagig]

Wie macht man das?

wie macht man was?

ich glaub er meint das so:

*
TYPE UDT 1
VERSION : 0.1


  STRUCT     
   test : BOOL ;    
   test1 : BOOL ;    
  END_STRUCT ;    
END_TYPE

FUNCTION_BLOCK FB 2
TITLE =
VERSION : 0.1


VAR_INPUT
  test : UDT 1;    
  xIN1 : BOOL ;    
  xIN2 : BOOL ;    
END_VAR
VAR_OUTPUT
  xOUT1 : BOOL ;    
  xOUT2 : BOOL ;    
END_VAR
BEGIN
NETWORK
TITLE =

      U     #xIN1; 
      U     #xIN2; 
      =     #test.test1; 

      U     #xIN1; 
      O     #xIN2; 
      =     #test.test; 

      U     #test.test1; 
      =     #xOUT1; 
      NOT   ; 
      UN    #test.test; 
      =     #xOUT2; 

END_FUNCTION_BLOCK

DATA_BLOCK DB 2
TITLE =
VERSION : 0.0

 FB 2
BEGIN
   test.test := FALSE; 
   test.test1 := FALSE; 
   xIN1 := FALSE; 
   xIN2 := FALSE; 
   xOUT1 := FALSE; 
   xOUT2 := FALSE; 
END_DATA_BLOCK

FUNCTION FC 1 : VOID
TITLE =
VERSION : 0.1

BEGIN
NETWORK
TITLE =

      CALL FB     2 , DB     2 (
           xIN1                     := E      0.0,
           xIN2                     := E      0.1,
           xOUT1                    := A      0.0,
           xOUT2                    := A      0.1);


END_FUNCTION

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke 4L für den ausführlichen Quelltext. Ja, genau so war mein Vorschlag gemeint.

In FUP/KOP/AWL-Editor sieht der Aufruf bei AWL so aus

CALL FB 2 , DB 2
  [B][COLOR="Blue"]test  :=[/COLOR][/B]
  xIN1  := E0.0
  xIN2  := E0.1
  xOUT1 := A0.0
  xOUT2 := A0.1

Bei FUP und KOP sind an dem Eingang "test" dann 3 Punkte.

(ich arbeite selten mit Quellen, wußte noch garnicht, daß man die unbeschalteten Parameter
einfach komplett weglassen kann, obwohl: in 1131 ist es ja auch so)

Gruß
PN/DP

 

[vierlagig]

(ich arbeite selten mit Quellen, wußte noch garnicht, daß man die unbeschalteten Parameter
einfach komplett weglassen kann, obwohl: in 1131 ist es ja auch so)

hat mich auch kurz stutzen lassen und ich hab die quelle ein zweites mal generiert ... keine änderung.

fügt man

*
             test                        :=,

ein, zickt der compiler rum -> Anweisung erwartet Operanden

 

[PN/DP]

Danke 4L, wieder was dazugelernt!

Gruß
PN/DP

 

[Franky08]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die vielen Antworten

Habe es ausprobiert, den UDT als IN-Variable zu deklarieren.
Funktioniert wunderbar.

MFG.

Frank