Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

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

  1. #11
    Registriert seit
    11.04.2008
    Ort
    Bayern
    Beiträge
    523
    Danke
    26
    Erhielt 67 Danke für 67 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Kann ich mit den MC7 Code von meinen Programm irgendwie anschauen/auslesen?

  2. #12
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von netmaster Beitrag anzeigen
    Kann ich mit den MC7 Code von meinen Programm irgendwie anschauen/auslesen?
    ja, anschauen, nicht aber bearbeiten.
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  3. Folgender Benutzer sagt Danke zu vierlagig für den nützlichen Beitrag:

    hubert (21.01.2010)

  4. #13
    Registriert seit
    05.11.2009
    Beiträge
    42
    Danke
    1
    Erhielt 6 Danke für 5 Beiträge

    Standard

    Zitat Zitat von vierlagig Beitrag anzeigen
    ja, du hast das problem tatsächlich nicht verstanden.
    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
    wow ja, sieht so aus . aber macht auch nichts. Ich hätte auch nicht erklären können

    Gruß Philip

  5. #14
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Zitat Zitat von hubert Beitrag anzeigen
    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.
    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
    Geändert von PN/DP (20.01.2010 um 01:34 Uhr)
    Zitieren Zitieren erhöhter Codebedarf für Hidden-Adressberechnung  

  6. Folgende 6 Benutzer sagen Danke zu PN/DP für den nützlichen Beitrag:

    Bernard (20.01.2010),hubert (21.01.2010),netmaster (20.01.2010),Paule (20.01.2010),RGerlach (20.01.2010),rostiger Nagel (20.01.2010)

  7. #15
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    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
    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.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

  8. #16
    Avatar von hubert
    hubert ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    17.09.2003
    Ort
    Zell bei Dietfurt a.d. Altmühl
    Beiträge
    357
    Danke
    8
    Erhielt 27 Danke für 25 Beiträge

    Standard

    Hallo Harald

    Zitat Zitat von PN/DP Beitrag anzeigen
    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
    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?
    MfG

    Hubert

    \"Never change a running system. \"

  9. #17
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.725
    Danke
    314
    Erhielt 1.519 Danke für 1.282 Beiträge

    Standard

    Zitat Zitat von hubert Beitrag anzeigen
    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?
    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
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  10. Folgender Benutzer sagt Danke zu MSB für den nützlichen Beitrag:

    PN/DP (21.01.2010)

  11. #18
    Registriert seit
    29.03.2004
    Beiträge
    5.731
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    Zitat Zitat von MSB Beitrag anzeigen
    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.
    ...und bei einem FB gibt es nochmal die zwei Anwendungsfälle: Multiinstanz oder nicht Multiinstanz.
    Das unterscheidet sich auch nochmal nicht unerheblich.

  12. Folgender Benutzer sagt Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    MSB (20.01.2010)

  13. #19
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.725
    Danke
    314
    Erhielt 1.519 Danke für 1.282 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    ...und bei einem FB gibt es nochmal die zwei Anwendungsfälle: Multiinstanz oder nicht Multiinstanz.
    Das unterscheidet sich auch nochmal nicht unerheblich.

    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
    Geändert von MSB (20.01.2010 um 23:57 Uhr)
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  14. Folgender Benutzer sagt Danke zu MSB für den nützlichen Beitrag:

    hubert (21.01.2010)

  15. #20
    Avatar von hubert
    hubert ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    17.09.2003
    Ort
    Zell bei Dietfurt a.d. Altmühl
    Beiträge
    357
    Danke
    8
    Erhielt 27 Danke für 25 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.
    MfG

    Hubert

    \"Never change a running system. \"

Ähnliche Themen

  1. Antworten: 1
    Letzter Beitrag: 14.01.2011, 11:56
  2. Erhöhter Leerlaufstrom am Umrichter?
    Von TommyG im Forum Antriebstechnik
    Antworten: 2
    Letzter Beitrag: 15.10.2009, 08:36
  3. Probleme beim Zugriff auf DP-Konfiguration
    Von mathias007 im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 27.11.2007, 14:00
  4. Fehler beim Peripherie Zugriff
    Von INST im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 18.01.2007, 11:37
  5. Probleme beim Indzierten DB-Zugriff
    Von kiestumpe im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 17.05.2006, 14:30

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •