Erhöhter Speicherbedarf beim Zugriff von Strukturparametern in FBs und FCs

hubert

hubert

Level-2
Beiträge
405
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

vielleicht kann mir einer von Euch das erklären. Wenn ich eine Anwenderdefinierte Struktur in Step 7 erstelle (UDT) in diese als Parameter (IN, OUT oder IN/OUT) bei einem FC oder FB angebe und dann innerhalb des Bausteines drauf zu greife habe ich einen sehr großen Speicherbedarf für einen Baustein, obwohl nur Quellcode drinnen steht.
Geh ich allerdings her und übergibt die Struktur als ANY und leg die Struktur im STAT (FB) oder im TEMP (FC) an und ich kopiere mit dem BLKMOV denn ANY in den jeweiligen Bereich und greife dann drauf zu, so ist der Speicherbedarf nicht mehr so groß. Ich habe keine Erklärung für dieses Phänomen. Ich hoffe einer von euch kann mir das Erklären. Anbei liegt eine Programm mit der folgenden Situation bei. Was mich noch interessiert, gibt es irgendwie auch eine Dokumentation zum SFC20 (BLKMOV), wo drinnen steht, wie lege er für eine bestimmte Datenmenge braucht?
Danke schon mal vorab für Euere Hilfe.
 

Anhänge

  • Speicherbedarf_UDT.zip
    48 KB · Aufrufe: 19
Zuviel Werbung?
-> Hier kostenlos registrieren
Paule schrieb:
Für diese Frage hat der Kollege vierlagig das hier schön dokumentiert.
http://sps-forum.de/showpost.php?p=237189&postcount=4
Zum Vergrößern anklicken....

war nicht ganz die richtige antwort ^^ ... die dokumentation heißt operationsliste. zu finden, wie immer, bei http://support.automation.siemens.com

...is nämlich auch bißchen cpu abhängig, für die verlinkten berechnungen habe ich eien pi*daumen-schnitt hergenommen
 
Hallo,

habe mir das mit der Zykluszeitbelastung im Handbuch durchgelesen.
Das mit den 10µs + 0,01µ/Byte stimmt schon von vierlagig.
Aber das andere Problem bleibt ja noch bestehen. Vielleicht findet ja hier auch jemand eine Erklärung warum der Speicherbedarf so hoch ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wir kommen hinter alles, wir finden alles raus *sing* :eek:)

weil es nur nach außen so aussieht wie es aussieht, also annähernd gleich

AWL:
Code: 
*
Netzwerk 2 (UDT)
      UN    #E_Bereit
      O     #St_Schieber_ext
      O     #St_End_auf
      O     #St_End_zu
      =     #Daten.SIGNALE.HMI_Stoerung

Netzwerk 2 (ohne UDT)
      UN    #E_Bereit
      O     #St_Schieber_ext
      O     #St_End_auf
      O     #St_End_zu
      =     #Temp_Daten.SIGNALE.HMI_Stoerung
MC7:

Code: 
*
Netzwerk 2 (UDT)
      UN    DIX [AR2,P#0.3]
      O     DIX [AR2,P#8.5]
      O     DIX [AR2,P#8.6]
      O     DIX [AR2,P#8.7]
      BLD   18
      T     LD     4
      TAK   
      T     LD     8
      L     DIW [AR2,P#12.0]
      T     LW    12
      AUF   DB [LW 12]
      L     DID [AR2,P#14.0]
      LAR1  
      L     LD     8
      L     LD     4
      =      [AR1,P#0.0]

Netzwerk 2 (ohne UDT)
      UN    DIX [AR2,P#0.3]
      O     DIX [AR2,P#18.5]
      O     DIX [AR2,P#18.6]
      O     DIX [AR2,P#18.7]
      =     DIX [AR2,P#32.0]
 
Ich muss zugeben, ich habe nicht ganz verstanden was du machst, bzw. machen willst. Aber wenn du die Struktur im FB in der Deklaration hast, brauchst sie speicher, da sie ja im InstanzDB erstellt wird. Wenn du Sie im FC in den Lokaldaten hast nicht, da Sie dort ja nur temporär existiert, solange sie bearbeitet wird.

Gruß Philip
 
Philip schrieb:
Ich muss zugeben, ich habe nicht ganz verstanden was du machst, bzw. machen willst. Aber wenn du die Struktur im FB in der Deklaration hast, brauchst sie speicher, da sie ja im InstanzDB erstellt wird. Wenn du Sie im FC in den Lokaldaten hast nicht, da Sie dort ja nur temporär existiert, solange sie bearbeitet wird.

Gruß Philip
Zum Vergrößern anklicken....

ja, du hast das problem tatsächlich nicht verstanden. :rolleyes:
er hat zwei funktional gleiche FBs
im FB A hat er die STATs mit hilfe einer UDT eingefügt
im FB B die selben daten im STAT bereich als Struct angelegt

FB A ist mehr als doppelt so groß im vergleich zu FB B

grund: siehe meinen post oben
 
hubert schrieb:
Ich sehe, dass hier im MC7-Code schon ein deutlicher unterschied besteht.
Zum Vergrößern anklicken....

das ist der wesentliche unterschied, denn so wird der baustein gespeichert und erst beim öffnen im editor übersetzt.
siehe dazu auch: Patent EP 1 004 960 A2 "Verfahren zur Ablage der Anwenderprogramme eines Automatisierungssystems"
 
vierlagig schrieb:
ja, du hast das problem tatsächlich nicht verstanden. :rolleyes:
er hat zwei funktional gleiche FBs
im FB A hat er die STATs mit hilfe einer UDT eingefügt
im FB B die selben daten im STAT bereich als Struct angelegt

FB A ist mehr als doppelt so groß im vergleich zu FB B

grund: siehe meinen post oben
Zum Vergrößern anklicken....

wow ja, sieht so aus :). aber macht auch nichts. Ich hätte auch nicht erklären können *ROFL*

Gruß Philip
 
erhöhter Codebedarf für Hidden-Adressberechnung

hubert schrieb:
Wenn ich eine Anwenderdefinierte Struktur in Step 7 erstelle (UDT) in diese als Parameter (IN, OUT oder IN/OUT) bei einem FC oder FB angebe und dann innerhalb des Bausteines drauf zu greife habe ich einen sehr großen Speicherbedarf für einen Baustein, obwohl nur Quellcode drinnen steht.
Zum Vergrößern anklicken....
Das liegt daran, daß alle Datentypen größer 4 Byte nicht als call_by_value sondern als call_by_reference übergeben werden,
d.h. es wird nicht der Wert der Variablen (als Kopie) übergeben, sondern die Adresse der Original-Variablen.
Das ist in Step7 leider nicht so deutlich sichtbar wie z.B. in C, das muß man halt wissen.

Weil dadurch die Adresse der übergebenen Variablen zur Compilierzeit nicht bekannt ist, muß der Baustein die Adresse der Variablen
zur Laufzeit auflösen und in ein AR-Register laden, um danach den Wert der Variablen indirekt zu lesen.
Soweit ich mich erinnere, sind das bei jedem Zugriff etwa 42 Byte mehr Code als ein Zugriff auf Variablen im TEMP- oder STAT-Bereich.

Vorsicht!
Egal, ob die Struktur als IN, IN_OUT oder OUT übergeben wird, kann auf Variablen der Struktur geschrieben werden.
Dabei wird die Original-Variable verändert! Der Step7-Editor/Compiler verhindert das nicht!

Gruß Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Das liegt daran, daß alle Datentypen größer 4 Byte nicht als call_by_value sondern als call_by_reference übergeben werden,
d.h. es wird nicht der Wert der Variablen (als Kopie) übergeben, sondern die Adresse der Original-Variablen.
Das ist in Step7 leider nicht so deutlich sichtbar wie z.B. in C, das muß man halt wissen.

Weil dadurch die Adresse der übergebenen Variablen zur Compilierzeit nicht bekannt ist, muß der Baustein die Adresse der Variablen
zur Laufzeit auflösen und in ein AR-Register laden, um danach den Wert der Variablen indirekt zu lesen.
Soweit ich mich erinnere, sind das bei jedem Zugriff etwa 42 Byte mehr Code als ein Zugriff auf Variablen im TEMP- oder STAT-Bereich.

Vorsicht!
Egal, ob die Struktur als IN, IN_OUT oder OUT übergeben wird, kann auf Variablen der Struktur geschrieben werden.
Dabei wird die Original-Variable verändert! Der Step7-Editor/Compiler verhindert das nicht!

Gruß Harald
Zum Vergrößern anklicken....
Hi Harald,
welcome back, lange nichts mehr von Dir gelesen.
Das nenne ich mal eine Erklärung.
Ich habe das auch schon mal gehört oder gelesen, hätte das aber so nicht wiedergeben können.
 
Hallo Harald

PN/DP schrieb:
Das liegt daran, daß alle Datentypen größer 4 Byte nicht als call_by_value sondern als call_by_reference übergeben werden,
d.h. es wird nicht der Wert der Variablen (als Kopie) übergeben, sondern die Adresse der Original-Variablen.
Das ist in Step7 leider nicht so deutlich sichtbar wie z.B. in C, das muß man halt wissen.

Weil dadurch die Adresse der übergebenen Variablen zur Compilierzeit nicht bekannt ist, muß der Baustein die Adresse der Variablen
zur Laufzeit auflösen und in ein AR-Register laden, um danach den Wert der Variablen indirekt zu lesen.
Soweit ich mich erinnere, sind das bei jedem Zugriff etwa 42 Byte mehr Code als ein Zugriff auf Variablen im TEMP- oder STAT-Bereich.

Vorsicht!
Egal, ob die Struktur als IN, IN_OUT oder OUT übergeben wird, kann auf Variablen der Struktur geschrieben werden.
Dabei wird die Original-Variable verändert! Der Step7-Editor/Compiler verhindert das nicht!

Gruß Harald
Zum Vergrößern anklicken....

Hab das mal ausporbiert. Habe eine UDT erstellt, der folgenden Aufbau hat. 2*REAL + 2*Byte = 10 Byte länge. Habe diese dann als IN-Paramer an einem FB angegeben. Innerhalb des FB's hab ich nur eine kleines Programm geschrieben, wo ich lesend und schreiben auf die Struktur zugreife. Was ich nun festegestellt habe ich folgendes. Die Wert habe sich in dem übergebene DB mit der Struktur nicht verändert. Also ist das mit call_by_referenc bei Strukturen doch nicht ganz richtig oder hab ich was falsch gemacht?
 
hubert schrieb:
Hallo Harald



Hab das mal ausporbiert. Habe eine UDT erstellt, der folgenden Aufbau hat. 2*REAL + 2*Byte = 10 Byte länge. Habe diese dann als IN-Paramer an einem FB angegeben. Innerhalb des FB's hab ich nur eine kleines Programm geschrieben, wo ich lesend und schreiben auf die Struktur zugreife. Was ich nun festegestellt habe ich folgendes. Die Wert habe sich in dem übergebene DB mit der Struktur nicht verändert. Also ist das mit call_by_referenc bei Strukturen doch nicht ganz richtig oder hab ich was falsch gemacht?
Zum Vergrößern anklicken....

Imho hast du, und damit widerspreche ich nun PN/DP teilweise, nichts falsch gemacht.
Es ist hier nämlich ein essentieller Unterschied zwischen FB/FC.

Bei einem FC ist "Intern" zwischen IN/OUT/IN_OUT tatsächlich kein Unterschied,
es wird ein Pointer berechnet, und über selbigen dann zugegriffen.
Hier stimmt das Call by Ref zu 100%.


Bei einem FB hingegen, wirken sich "normale" L/T U O = Operationen intern ausschließlich auf dem IDB aus.
Bei IN_OUT findet hingegen wieder analog zum FC die Pointerberechnung statt.

FB Anwendersicht:
FB_Norm.jpg

FB MC7:
FB_MC7.jpg

FC Anwendersicht:
FC_Norm.jpg

FC MC7:
FC_MC7_1.jpg
FC_MC7_2.jpg

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MSB schrieb:
Bei einem FB hingegen, wirken sich "normale" L/T U O = Operationen intern ausschließlich auf dem IDB aus.
Bei IN_OUT findet hingegen wieder analog zum FC die Pointerberechnung statt.
Zum Vergrößern anklicken....

...und bei einem FB gibt es nochmal die zwei Anwendungsfälle: Multiinstanz oder nicht Multiinstanz.
Das unterscheidet sich auch nochmal nicht unerheblich.
 
Thomas_v2.1 schrieb:
...und bei einem FB gibt es nochmal die zwei Anwendungsfälle: Multiinstanz oder nicht Multiinstanz.
Das unterscheidet sich auch nochmal nicht unerheblich.
Zum Vergrößern anklicken....


Das hier wäre die Nicht-Multinstanzvariante:
FB_MC7_Nicht_Multiinstanz.jpg

Wobei das ganze aber vom groben Prinzip ähnlich ist.
Lediglich das ganze AR2 Offset Zeugs entfällt.


Mfg
Manuel
 
Zuletzt bearbeitet:
Hallo Manuel,

man muss aber dann auch Sagen, dass das von Siemens sehr schlecht gelöst ist. Für was brauch in dann überhaupt Strukturen, wenn ich Sie mit umwegen auf andere Bereich kopieren muss, damit ich Speicher- und Geschwindigkeitsbewusst Programmiere. Habe momentan mit einem Telemechanic Controller zu tun, welcher über CodeSys von Programmiert wird. Hier arbeite ich viel mit Strukturen, und das braucht nicht so viel Speicher, wie ich es bis jetzt gesehen habe. Dieser Controller ist auch verdammt schnell. Momentan so 280µs Zykluszeit. Hier arbeite ich auch mit vielen Antriebsbausteinen, welche viele Strukturen beinhalten und auch übergeben werden müssen.
 

Similar threads

S
TIA AWL Probleme mit LD Zugriff in FC bei TIA V17
Antworten
14
Aufrufe
633
StallionP51
S
S
TIA DB_Any als In/Out deklariert aber DB geht nicht für das eigen Verständnis
Antworten
3
Aufrufe
279
DCDCDC
D
M
TIA Teil eines UDT kopieren
Antworten
9
Aufrufe
2K
mmm_ams
M
C
TIA ET200 OC und FTP- Server
Antworten
4
Aufrufe
373
CNC840D
C
F
TIA S7300 S71200 PUT GET Negative Quittung von Partner-CPU
2
Antworten
22
Aufrufe
2K
Fetzy
F
Zurück
Oben