# Bausteine aufrufen für dummies



## Max-Schulz (27 August 2006)

*Moin Moin,

habe leider ein Problem, und zwar bin ich mit meinem 
begrenzten Wissen am Ende.
Zur Zeit programiere ich eine Sortieranlage in Step7.

Da ich noch ziehmlicher Neuling bin brauche ich mal eure hilfe.
Das erstellen der AWL ist kein Thema aber nun kommt das Problem
der Bausteine.

Die Anlage soll je nach erfassung der Werkstücke diese durch verschieden Prozeduren Sortieren.

Da diese ja immer gleich sind wollte ich diese Prozeduren in verschiedene  Bausteine schreiben und diese dann je nach bedarf
aufrufen und ablaufen lassen und danach zur Abfrage zurück.

Leider finde ich nirgens eine aufstellung der Befehle zum aufrufen und starten der Bausteine.

Mir ist da nur der Call befehl bekannt aber wie der nun richtig eingesetzt wird is mir noch nicht klar.

1. CPU TYP  315-2DP
**
2. Step7 V5.3

Ich würde mich freuen wenn ihr mir da eine gute Quelle empfehlen könntet oder so weiterhelfen würdet.

Am besten anhand eines Quelltextes...


Vielen Dank

Gruß Max
*


----------



## Garog (27 August 2006)

Hallo

Wenn du dir einen Baustein baust und diesen dann in einem anderen lädst, dann hast du an diesem Baustein, den du dir gemacht hast, mindestens einen EN und einen ENO Anschluss dran, generiert Step 7 automatisch. Brauchst du also nichts in deiner Quelle schreiben.

Der Baustein wird standartmässig immer aufgerufen. Es sei den du hast am Eingang EN eine Variable stehen. Dann aktiviert sich der Baustein nur so lange wie dort das Signal "true" anliegt. Sobald das Signal "false" wird deaktiviert sich der Baustein.

Hoffe das war das was du brauchtest


----------



## Max-Schulz (27 August 2006)

Ist für mich jetz fachtürkisch 

Ich meine das so:

Ich habe jetz erstmal 3 Bausteine, OB1, FC1 und FC2.


```
//--------------Schwenkarm-links---------------------

      U     M      1.1
      U     M      2.2
      U     E      4.1
      S     M      1.2
      O     M      1.3
      O     M      0.0
      R     M      1.2

      U     M      1.2
      S     A      8.3



//--------------Induktiver-Sensor--------------------

      U     M      1.2
      U     E      8.3
      U     E      4.2
      U     E      8.3
      U     E      8.4
      UN    M      1.5
      S     M      1.3
      O     M      1.4
      O     M      0.0
      R     M      1.3

      U     M      1.3
      S     A     12.2
      L     S5T#1S
      SE    T      1
```

Das ist jetz mal ein auszug aus meinem Programm.

Bitte dazu keine Kommentare 

Nachdem der Teil mit dem Schwenkarm fertig ist soll je nachdem welche 
Sensoren aktiv sind, der FC2 oder ein anderer Baustein geladen werden.

Wie sage ich ihm, wenn Sensor 1 aktiv, lade FC2.
Wenn sensor 2 dann FC3, etc...


----------



## Ma_su (27 August 2006)

Bausteine lassen sich mit 
call fc 1 
aufrufen der call befehl ist aber nicht abhängig vom verkünpfungsergebnis des halb müsste in deinem Fall so aus sehen das noch ein bedingter sprung gemacht werden muss. Das sieht dann so aus:

ob 1

```
u Sensor 1     //sprungbedingung
un Sensor 2   //       "
spbn m001    //springe wenn VKE 0
call fc 1       //Bausteinaufruf
m001: nop 0 //Sprungmake und Nulloperation

u Sensor 2
un Sensor 1
spbn m002
call fc2
m002: nop 0
```

Hoffe das hilft dir weiter.


----------



## Martin007 (27 August 2006)

Hallo

wenn du die Bausteinaufrufe unter FUP oder KOP programierst, haben die Bausteine einen "EN" Eingang.
Wird dieser "EN" Eingang nicht angeschlossen, wird der Baustein immer aufgerufen.
Steuerst du den "EN" Eingang mit einem Signal an, so wird der Baustein in Abhängigkeit der Ansteuerung aufgerufen.

Martin


----------



## Garog (27 August 2006)

@Ma_su

so geht es natürlich auch
aber da er noch am anfang steht ist der weg über den EN einfacher finde ich als gleich mit sprungmarken zu arbeiten


@Max-Schulz

wenn du im ob1 bist und die ansicht auf FUP stellst (STRG+3)
und aus deiner linken leiste (sollte sie zumindest sein oder auch rechts) wenn sie nicht da ist dann CTRL+k
dort unter "FC Bausteine" findest du die Bausteine die du bereits geschrieben hast.
wenn du dir jetzt einen nimmst und den in ein NW in den OB ziehst dann lädt dieser den FC
wenn du jetzt am Eingang EN deinen Sensor eins legst dann wird dieser nur geladen wenn dieser auch belegt ist.
du kannst zur sicherheit auch ein und glied davor setzten und den zweiten eingang nigieren ( F9 am eingang drücken) und dort deinen sensor zwei anlegen.

ist das selbe was Ma_su beschrieben hat nur so kannst du es vll auch ein bissel besser verstehen wenn du gerade am anfang der sps welt stehst^^


----------



## Martin007 (27 August 2006)

Garog schrieb:


> @Ma_su
> 
> so geht es natürlich auch
> aber da er noch am anfang steht ist der weg über den EN einfacher finde ich als gleich mit sprungmarken zu arbeiten



Hallo Garog

wenn du die Aufrufe in FUPoder KOP scheibst,und dann in AWL umschaltest hast du den AWL-Code mit Sprungmarken, so wie ihn Ma_su geschrieben hat.

Martin


----------



## Garog (27 August 2006)

Martin007 schrieb:


> Hallo Garog
> 
> wenn du die Aufrufe in FUPoder KOP scheibst,und dann in AWL umschaltest hast du den AWL-Code mit Sprungmarken, so wie ihn Ma_su geschrieben hat.
> 
> Martin






weiß ich doch 

deswegen sagt ich doch das er das machen soll damit es einfacher ist für ihn...
ich habe ja auch erst das selbe geschrieben wie du und das war für ihn doch schon "fachtürkisch" wie er selber sagte
daher habe ich es ihm etwas einfacher gemacht
so das er weiß was er da macht
und nicht einfach das kopiert was hier steht


----------



## maxi (28 August 2006)

Ich würde einen Anfänger immer zu Sprüngen raten.
SPäter geht es einfach nicht mehr ohne.

Ich habe dann schon Programmkauderwelsch von Leuten gesehen die einfach Sprünge vermeiden wollten weil sie Probleme damit hatten, das glaubt ihr nicht.
Habe auch schon einmal ein extern von einen Ingeneuer erstelltes Programm nicht bezahlen lassen. Da hat ein Knaller alles in einen FB mit 1 DB geschrieben in 2 Netzwerke.
Habe das Programm noch  ist ein gutes Beispiel wie man es absolut nicht machen soll *fg*

Er hatte sich dazu nicht mehr geäussert, vom Programmaufbau sah es mir aus als hätte er es zuerst in Assembler erstellt und dann 1 zu 1 in S7-AWL umgewandelt.


----------



## Ralle (28 August 2006)

Neben dem Umspringen eines CALL-Aufrufes kann man auch den Befehl CC (bedingter Bausteinaufruf einsetzen). 

Siemens-Hilfe:



> CC <Kennung des Codebausteins> (bedingter Bausteinaufruf) ruft bei VKE = 1 einen Codebaustein vom Typ FC oder FB ohne Parameter auf. Die Operation CC gleicht der Operation CALL, mit dem Unterschied, daß keine Parameter übergeben werden können. Die Operation speichert die Rücksprungadresse (Selektor und relative Adresse), die Selektoren der beiden aktuellen Datenbausteine sowie das MA-Bit im B-Stack, deaktiviert die MCR-Abhängigkeit, erstellt den Lokaldatenbereich des Bausteins, der aufgerufen werden soll, und beginnt, den aufgerufenen Code auszuführen. Die Kennung des Codebausteins kann absolut oder symbolisch angegeben werden.


 
Aufruf: 

U E 2.0
CC FC2

Es können dann allerdings keine Parameter bzw. Instanz-DB angegeben werden.


----------



## Gerri (10 Dezember 2008)

Ralle schrieb:


> Es können dann allerdings keine Parameter bzw. Instanz-DB angegeben werden.


 
Es hört sich zwar blöd an aber was bedeutet "keine Parameter"; was versteht ma unter Parameter bzw was hilt ein FB ohne Instanz-DB?
Für mich hört sich das an als würde das ins Nirvana gehn!


----------



## Perfektionist (10 Dezember 2008)

das bedeutet so viel, dass der Befehl CC praktisch kaum zur Anwendung kommt - eben weil nur ein FC ohne Parameter damit *sinnvoll* bedingt aufgerufen werden kann.


----------



## Gerri (10 Dezember 2008)

wobei CC ja noch sinnvoller ist als UC. 
Damit kann man Funktionen wenigstens bewusst nicht abarbeiten (hab das schon einmal gebraucht und bin dann mit SPB drüber gesprungen). 
UC macht beim Aufruf zum FC keinen Unterschied, verwendet aber FB´s wie FC´s.
Hab ichs urchschaut oder gibts noch mehr zu wissen?


----------



## vierlagig (10 Dezember 2008)

Perfektionist schrieb:


> das bedeutet so viel, dass der Befehl CC praktisch kaum zur Anwendung kommt - eben weil nur ein FC ohne Parameter damit bedingt aufgerufen werden kann.



??? ich hab hier grad ein programm offen ...

codeauszug:


```
*
      UC    FB    12
      UC    FB    13
      UC    FB    14
      UC    FB    15
      UC    FB    16
      UC    FB    17
      UC    FB    18
      UC    FB    19
      UC    FB    20
      UC    FB    21
      UC    FB    22
      UC    FB    23
      UC    FB    24
      UC    FB    25
      UC    FB    26
      UC    FB    27
```
in den einzelnen FBs wird dann mit globaldaten gearbeitet ...

nicht nach dem sinn fragen, einfach nur merken: jopp, geht.

Gebs hat vor kurzem auf UC und CC hingewiesen...



Gebs schrieb:


> Hallo heinerbollo,
> 
> es gibt eine Möglichkeit den Instanz-DB variabel zu übergeben, aber es ist ziemlich tricky!
> 
> ...


----------



## Gebs (10 Dezember 2008)

Perfektionist schrieb:


> das bedeutet so viel, dass der Befehl CC praktisch kaum zur Anwendung kommt - eben weil nur ein FC ohne Parameter damit bedingt aufgerufen werden kann.


 
Das stimmt so nicht ganz. Man kann auch FB's mit CC bzw UC aufrufen.
Hier steht wie und warum:
http://www.sps-forum.de/showthread.php?t=23936

Grüße
Gebs

[EDIT]
Warum ist der VL immer schneller?
[/EDIT]


----------



## vierlagig (10 Dezember 2008)

Gebs schrieb:


> [EDIT]
> Warum ist der VL immer schneller?
> [/EDIT]



muß er, wenn er gegen einen der Dalton Brüder zu Werke gehen muß ... da gewöhnt man sich sowas an


----------



## Perfektionist (10 Dezember 2008)

vierlagig schrieb:


> ...
> nicht nach dem sinn fragen...


ich habs geändert:


Perfektionist schrieb:


> das bedeutet so viel, dass der Befehl CC praktisch kaum zur Anwendung kommt - eben weil nur ein FC ohne Parameter damit *sinnvoll* bedingt aufgerufen werden kann.


wobei ich dann auch noch dazu sagen muss, dass ich so wenig wie möglich Globaldaten und daher fast nie FC benutze. Na gut, CC und UC mögen ihre Existenzberechtigung haben - bei dem, was Gebs da beschreibt, unterstreiche ich aber das tricky mal doppelt 

und ... OK, dann gibt der UC einen SINN ...


----------



## hovonlo (10 Dezember 2008)

Und mit UC und CC lässt sich gegenüber dem CALL noch eine wunderbare indirekte Adressierung realisieren:


```
UC  FC [MW 2]
```
Klappt prima, kann aber so richtig unwartbarer Code draus entstehen


----------



## vierlagig (14 Januar 2009)

jetzt muß ich das UC dingens hier nochmal hochschieben.

man nehme einen FB und lege eine datenstruktur darin fest. diese struktur merkt man sich und baut sie genauso in einen anderen FB (namen sind schall und rauch, die steuerung interessiert hier nur die richtige datenstruktur, obwohl ... also der nutzer sollte wert darauf legen, sonst kommt grütze raus) in den zweiten FB programmiert man jetzt etwas, dass mit den daten, die in der struktur angelegt sind, etwas machen. diesen FB ruft man im ersten per UC auf und den ersten mit einem CALL (übergabe instanz) ... was man jetzt gemacht hat: man kann im zweiten FB auf die instanz des ersten zugreifen, da dieser IDB ja immer noch offen ist

wichtig: auf die datenkonsistenz achten!


----------



## Ralle (14 Januar 2009)

vierlagig schrieb:


> jetzt muß ich das UC dingens hier nochmal hochschieben.
> 
> man nehme einen FB und lege eine datenstruktur darin fest. diese struktur merkt man sich und baut sie genauso in einen anderen FB (namen sind schall und rauch, die steuerung interessiert hier nur die richtige datenstruktur, obwohl ... also der nutzer sollte wert darauf legen, sonst kommt grütze raus) in den zweiten FB programmiert man jetzt etwas, dass mit den daten, die in der struktur angelegt sind, etwas machen. diesen FB ruft man im ersten per UC auf und den ersten mit einem CALL (übergabe instanz) ... was man jetzt gemacht hat: man kann im zweiten FB auf die instanz des ersten zugreifen, da dieser IDB ja immer noch offen ist
> 
> wichtig: auf die datenkonsistenz achten!



He 4L, geiler Satzbau, aber kannst du das bitte nochmal eindeutschen!


----------



## Gerri (14 Januar 2009)

Ralle schrieb:


> Es können dann allerdings keine Parameter bzw. Instanz-DB angegeben werden.


 

Also kaum für eine Anwendung geeignet, nümm?

Sprünge sind ok. Man muß halt bedenken dass die bearbeiteten Daten "eingefroren werden" bis der FC wieder aufgerufen wird.


----------



## vierlagig (14 Januar 2009)

Ralle schrieb:


> He 4L, geiler Satzbau, aber kannst du das bitte nochmal eindeutschen!


 
hier wird vielleicht deutlicher, was ich meine:


```
*
FUNCTION_BLOCK FB 2
TITLE =
VERSION : 0.1

VAR_INPUT
  in1 : BOOL ; 
  in2 : BOOL ; 
END_VAR
VAR
  _1 : BOOL ; 
  _2 : BOOL ; 
  _3 : BOOL ; 
  _4 : BOOL ; 
  _5 : BOOL ; 
  _6 : BOOL ; 
  _7 : BOOL ; 
  _8 : BOOL ; 
END_VAR
BEGIN
NETWORK
TITLE =
      U     #_6; 
      U     #_7; 
      =     #_5; 
END_FUNCTION_BLOCK
FUNCTION_BLOCK FB 1
TITLE =
VERSION : 0.1

VAR_INPUT
  in1 : BOOL ; 
  in2 : BOOL ; 
END_VAR
VAR
  _1 : BOOL ; 
  _2 : BOOL ; 
  _3 : BOOL ; 
  _4 : BOOL ; 
  _5 : BOOL ; 
  _6 : BOOL ; 
  _7 : BOOL ; 
  _8 : BOOL ; 
END_VAR
BEGIN
NETWORK
TITLE =
      U     #in1; 
      =     #_1; 
      U     #in2; 
      =     #_2; 
NETWORK
TITLE =
      U     #_1; 
      U     #_2; 
      =     #_4; 
NETWORK
TITLE =
      SET   ; 
      =     #_6; 
      CLR   ; 
      =     #_7; 
      UC    FB     2; //unbedingter aufruf, IDB bleibt erhalten

NETWORK
TITLE =
      U     #_5; 
      U     #_4; 
      =     #_8; //geht nicht, weil 7 auf null
END_FUNCTION_BLOCK
DATA_BLOCK DB 1
TITLE =
VERSION : 0.0
 FB 1
BEGIN
   in1 := FALSE; 
   in2 := FALSE; 
   _1 := FALSE; 
   _2 := FALSE; 
   _3 := FALSE; 
   _4 := FALSE; 
   _5 := FALSE; 
   _6 := FALSE; 
   _7 := FALSE; 
   _8 := FALSE; 
END_DATA_BLOCK
ORGANIZATION_BLOCK "Cycle Execution"
TITLE = "Main Program Sweep (Cycle)"
VERSION : 0.1

VAR_TEMP
  OB1_EV_CLASS : BYTE ; //Bits 0-3 = 1 (Coming event), Bits 4-7 = 1 (Event class 1)
  OB1_SCAN_1 : BYTE ; //1 (Cold restart scan 1 of OB 1), 3 (Scan 2-n of OB 1)
  OB1_PRIORITY : BYTE ; //Priority of OB Execution
  OB1_OB_NUMBR : BYTE ; //1 (Organization block 1, OB1)
  OB1_RESERVED_1 : BYTE ; //Reserved for system
  OB1_RESERVED_2 : BYTE ; //Reserved for system
  OB1_PREV_CYCLE : INT ; //Cycle time of previous OB1 scan (milliseconds)
  OB1_MIN_CYCLE : INT ; //Minimum cycle time of OB1 (milliseconds)
  OB1_MAX_CYCLE : INT ; //Maximum cycle time of OB1 (milliseconds)
  OB1_DATE_TIME : DATE_AND_TIME ; //Date and time OB1 started
END_VAR
BEGIN
NETWORK
TITLE =
      CALL FB     1 , DB     1 (
           in1                      := E      0.0,
           in2                      := E      0.1);
END_ORGANIZATION_BLOCK
```


----------



## Ralle (14 Januar 2009)

@4L

Damit können sich ein paar spezielle Jungs dann wieder ordentlich austoben. 
Hinterher dürfen wir ran und am Besten mit einem neuen Programm für Klarheit sorgen.


----------



## vierlagig (14 Januar 2009)

Ralle schrieb:


> @4L
> 
> Damit können sich ein paar spezielle Jungs dann wieder ordentlich austoben.
> Hinterher dürfen wir ran und am Besten mit einem neuen Programm für Klarheit sorgen.


 
ich find das, ehrlich gesagt, ziemlich geil. du hast einen übergeordneten baustein, mit einer festgelegten struktur. diese struktur trägst du in alle aufgerufenen FBs ein und kannst so innerhalb von überall auf alles zugreifen ohne global adressieren zu müssen ... also auch die portierbarkeit bleibt erhalten

feine sache das - das beispiel nicht, das war ein bißchen dürftig und nur schnell zusammengeschustert


----------



## Ralle (14 Januar 2009)

vierlagig schrieb:


> ich find das, ehrlich gesagt, ziemlich geil. du hast einen übergeordneten baustein, mit einer festgelegten struktur. diese struktur trägst du in alle aufgerufenen FBs ein und kannst so innerhalb von überall auf alles zugreifen ohne global adressieren zu müssen ... also auch die portierbarkeit bleibt erhalten
> 
> feine sache das - das beispiel nicht, das war ein bißchen dürftig und nur schnell zusammengeschustert



Das war mir klar, daß du das gut findest.
Ich finde das 100%-ige Sch...
Wenn da einer drin ändert, ohne immer alle FB nachzuführen ist Sense.
Da wäre es doch wirklich, gerade in diesem Falle, intelligenter, einen globalen DB herzunehmen. Aber das ist ja eh der alte Streit.


----------



## vierlagig (14 Januar 2009)

der vorteil ist, dass du in einer anlage mit vielen ähnlichen maschinen, gleiche funktionen auslagern kannst und dich nur noch auf eine gesamte datenstruktur einigen brauchst.


----------



## Ralle (14 Januar 2009)

vierlagig schrieb:


> der vorteil ist, dass du in einer anlage mit vielen ähnlichen maschinen, gleiche funktionen auslagern kannst und dich nur noch auf eine gesamte datenstruktur einigen brauchst.



4L glaub mir, ich hab gerade so ein Ding hier auf dem Tisch liegen und hau den ganzen Mist raus. (Graph7 + PDiag, eigentlich ne tolle Sache) Die haben allerdings immer am Anfang ihrer FB die Daten per indirekter Adressierung in ihren IDB rein kopiert und noch ein paar andere Gimmicks angewandt. Fakt ist, daß es für "Nicht Eingeweihte" extrem schwierig ist alle Zugriffe auf die Daten auch zu finden. Und selbst wenn, dauert das jedes mal ewig lange, weil man mehrere Möglichkeiten beim Suchen durchspielen muß. Das ist definitiv nicht so toll für Wartung und Instandhaltung.


----------



## vierlagig (14 Januar 2009)

ich sitz hier grad in einer anlage wo es genau so gemacht ist ... und es ist gut so - sorry - ich war auch mal instandhalter und hab mich auch während dieser zeit nicht vor einer, auf die anwendung zugeschnittene datenstruktur gescheut.
sicher könnte man das ganze auch mit globalen DBs machen, aber bitte wie willst du da portierbare bausteine schreiben ... jetz hör mir aber auf mit AUF DB ... und vielleicht noch als INT übegeben oder so ... das ist IMHO wesentlich schlimmer als eine anlage mit 15 CPUs die nach obigen schema alle die struktur beinhalten.


----------



## Perfektionist (14 Januar 2009)

was ja kein Geheimnis ist und wohl auch schon lange bekannt sein dürfte: da stehe ich klar auf Ralles Seite.

@4L: was ich sehr empfehlen würde, um den Gleichklang der Deklarationen in den verschiedenen FB sicherzustellen: einen UDT definieren und den in die Deklaration der verschiedenen FB reinschreiben. Dann ist die Datenstruktur für die beteiligten FB an zentraler Stelle änderbar und auch klar ersichtlich, welche FB gemeinsam auf diese Struktur zugreifen.


----------



## vierlagig (14 Januar 2009)

Perfektionist schrieb:


> @4L: was ich sehr empfehlen würde, um den Gleichklang der Deklarationen in den verschiedenen FB sicherzustellen: einen UDT definieren und den in die Deklaration der verschiedenen FB reinschreiben. Dann ist die Datenstruktur für die beteiligten FB an zentraler Stelle änderbar und auch klar ersichtlich, welche FB gemeinsam auf diese Struktur zugreifen.


 
ich hoffe, du beziehst dich jetzt nicht aufs beispiel  ...

ansonsten, ja, durchaus eine richtige und wichtige anmerkung und so ist es auch realisiert.


----------



## Perfektionist (14 Januar 2009)

@4L: entschuldige, ich hatte da etwas flüchtig drübergelesen:


vierlagig schrieb:


> ... übergeordneten baustein, mit einer festgelegten struktur. diese struktur trägst du in alle aufgerufenen FBs ein ...


und nach dieser Anmerkung:


Ralle schrieb:


> ... Wenn da einer drin ändert, ohne immer alle FB nachzuführen ist Sense. ...


dann wirklich an eine Strukturierung, wie Du sie im Beispiel angeführt hast, gedacht.


----------



## Ralle (14 Januar 2009)

@4L
Es sind nun mal nicht alle SPS-Programmierer und nicht alle Instandhalter die großen Superprogrammierer (Ich zähle mich auch nicht dazu, das zeigt offensichtlich meine schwache Begeisterung für das, was du so Klasse findest). Besonders, wenn in den Firmen die Instandhalter nur selten nach Fehlern suchen müssen und viele Systeme zu betreuen haben, ist das unmöglich. Daher bin ich nach wie vor der Meinung, daß man es den Leuten ja nicht gar zu schwer machen muß, nur, um seinen Genius zu beweisen. Wir reden hier wohlgemerkt nicht über Serienmaschinen  zu 1000 Stück, sondern über Sondermaschinenbau.


----------



## Perfektionist (14 Januar 2009)

am Rande angemerkt: mir ist das Problem des Kollegen rs-plc-aa wieder eingefallen: "Großen FB in 2 Teile splitten - knifflig."
http://www.sps-forum.de/showthread.php?t=16404

da kam dann auch der CC/UC als Lösungsansatz drin vor:


godi schrieb:


> Hallo!
> 
> Ja die zwei FB's müssen in der Deklaration gleich sein und den zweiten FB rufst du dann mit CC / UC auf dann brauchst du keine Parameter mehr übergeben.
> siehe dazu http://www.sps-forum.de/showthread.php?t=14604&highlight=fb+aufruf
> ...


----------



## MFreiberger (16 Juli 2014)

Moin vierlagig,

das finde ich sehr interessant. Ich habe mich schon immer gefragt, wofür man "UC" braucht.
Man könnte allerdings auch die IDB-Nummer des ersten FB abfragen, den Wert dem aufgerufenen FB als Eingangsvariable übergeben und dann den IDB der ersten öffnen (AUF DI [IDB-Nummer]). Dann greift man direkt auf den IDB des ersten FB zu...


----------



## vierlagig (16 Juli 2014)

MFreiberger schrieb:


> Man könnte allerdings auch die IDB-Nummer des ersten FB abfragen, den Wert dem aufgerufenen FB als Eingangsvariable übergeben und dann den IDB der ersten öffnen (AUF DI [IDB-Nummer]). Dann greift man direkt auf den IDB des ersten FB zu...



genau eben nicht!


----------



## MFreiberger (17 Juli 2014)

Moin vierlagig,

ich hatte mal einen Code, wie folgt vorliegen:


```
L     #Scannp_db                  // Kopieren der Daten in den Telegrammsendebereich
      T     #P_Db


      L     #Scann_dw
      SLW   3
      LAR1  


      L     0
      SLW   3
      LAR2  


      AUF   DI   179


      AUF   DB [#P_Db]


      L     5
loop: T     #Za


      L     #Scannp_db
      T     DBW [AR1,P#0.0]


      +AR1  P#1.0
      +AR2  P#1.0


      L     #Za
      LOOP  loop
      L     0
      T     #Fehl
      CALL  "Daten_löschen"
       Db_quelle:=179
       Von      :=0
       Nach     :=30
       wert     :=B#16#20


      BEA   


old:  NOP   0
```

Dabei werden Daten aus dem DB179 an den  DB5103 (IN #Scannp_db als int) übergeben.
Mal abgesehen davon, dass die DBW-Adresse immer nur um ein Byte hochgezählt wird und ich auf diese Weise bei fünf Durchläufen 6 Byte übergeben werden,
wird innerhalb der Schleife symbolisch auf #Scannp_db zugegriffen. Dabei ist hier der erste int-Wert aus DB179 abgefragt worden, weil als DI geöffnet.
Das hier nicht der übergebene IN-Wert stand, war der Knackpunkt und es hat echt gedauert, bis ich das verstanden habe 

Könnte man auf diese Weise nicht auf (gleiche) Deklarationen zugreifen, wobei man als IDB einen anderen, als den bei Bausteinaufruf angegebenen öffnet?


Gruß

MFreiberger


----------



## vierlagig (17 Juli 2014)

MFreiberger schrieb:


> Könnte man auf diese Weise nicht auf (gleiche) Deklarationen zugreifen, wobei man als IDB einen anderen, als den bei Bausteinaufruf angegebenen öffnet?



und genau damit ist der Witz gemordet. man muss für jeden CALL-Aufruf eine Instanz, sei es nun ein Instanz-DB pro Aufruf oder eine Multiinstanzdefinition angeben.
Ferner muss die Nummer übergeben werden.
Schmutziger ist nur, auf die Lokaldaten des Vorgängers zu zugreifen :roll:



MFreiberger schrieb:


> Dabei werden Daten aus dem DB179 an den  DB5103 (IN #Scannp_db als int) übergeben.
> Mal abgesehen davon, dass die DBW-Adresse immer nur um ein Byte hochgezählt wird und ich auf diese Weise bei fünf Durchläufen 6 Byte übergeben werden,
> wird innerhalb der Schleife symbolisch auf #Scannp_db zugegriffen. Dabei ist hier der erste int-Wert aus DB179 abgefragt worden, weil als DI geöffnet.
> Das hier nicht der übergebene IN-Wert stand, war der Knackpunkt und es hat echt gedauert, bis ich das verstanden habe



An welcher stelle wird Symbolisch auf den zweiten geöffneten Datenbaustein zugegriffen?
Das sieht zumindest nach einer ziemlichen Sauerei aus!


----------



## MFreiberger (17 Juli 2014)

Moin vierlagig,



> und genau damit ist der Witz gemordet. man muss für jeden CALL-Aufruf eine Instanz, sei es nun ein Instanz-DB pro Aufruf oder eine Multiinstanzdefinition angeben.
> Ferner muss die Nummer übergeben werden.
> Schmutziger ist nur, auf die Lokaldaten des Vorgängers zu zugreifen :roll:



alles klar. habe ich verstanden.


```
L     #Scannp_db                  // Kopieren der Daten in den Telegrammsendebereich     >>> hier war der Zugriff noch i.O. (Wert 5103, IN-Parameter)
      T     #P_Db


      L     #Scann_dw
      SLW   3
      LAR1  


      L     0
      SLW   3
      LAR2  


      AUF   DI   179             >>> bis hier war es der, für den FB angegebene IDB80. Danach 179


      AUF   DB [#P_Db]


      L     5
loop: T     #Za


      L     #Scannp_db            >>> hier erfolgte der (unrechtmäßige) Zugriff! (Wert aus [FONT=Verdana, Arial, Tahoma, Calibri, Geneva, sans-serif][B][I]IDB[/I][/B]179 mit Adresse der in diesem FB deklarierten Variablen #Scannp_db)[/FONT]

      T     DBW [AR1,P#0.0]


      +AR1  P#1.0
      +AR2  P#1.0


      L     #Za
      LOOP  loop
      L     0
      T     #Fehl
      CALL  "Daten_löschen"
       Db_quelle:=179
       Von      :=0
       Nach     :=30
       wert     :=B#16#20


      BEA   
 [COLOR=#333333] [/COLOR][COLOR=#333333]old: NOP 0[/COLOR]
```



Habs ja gefunden 

Gruß

MFreiberger


----------

