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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 14 von 14

Thema: SCL - ANY als Out-Parameter

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

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von RONIN Beitrag anzeigen
    Wenn der Blockmove seinen Any dereferenziert muss er schließlich auch die Informationen (DB1/10Byte/etc.) aus der Speicherstelle wo der Any liegt auslesen.
    Die Kopierfunktion selbst erfolgt danach separat.
    Wenn du dem Blockmove den Parameter "P#DB1.DBX 0.0 BYTE 100" übergibst, wird dieser für dich nicht sichtbar im Lokaldatenbereich zusammengebaut, und der Blockmove bekommt auch nur einen Zeiger auf den Anfang dieses Bereichs. D.h. er muss immer den Parameter dereferenzieren, ob du einen Variable vom Typ ANY oder eine Konstante übergibst.

    Ein Unterschied ist, dass SCL den Parameter nochmal umkopiert. Das hat aber etwas mit den erweiterten Möglichkeiten von SCL zu tun, z.B. der einen Any Parameter eines FBs an einen unterlagerten durchzureichen.

  2. #12
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.330
    Danke
    448
    Erhielt 687 Danke für 512 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Wenn du dem Blockmove den Parameter "P#DB1.DBX 0.0 BYTE 100" übergibst, wird dieser für dich nicht sichtbar im Lokaldatenbereich zusammengebaut, und der Blockmove bekommt auch nur einen Zeiger auf den Anfang dieses Bereichs. D.h. er muss immer den Parameter dereferenzieren, ob du einen Variable vom Typ ANY oder eine Konstante übergibst.
    Das ist schon klar, hab mich aber missverständlich ausgedrückt, sorry.
    Der Parameter am IN/OUT (Zeiger auf den Anfang des Any-Speicherbereichs) muss natürlich immer derefenziert werden damit man an den Inhalt des Any kommt.

    Aber ob ich jetzt den Inhalt/Zusammensetzung des Any über den Zeiger auslese oder ihn modifiziere ist eine andere Sache.

    Selbst wenn ich einen Konstante für den Any eintrage, dieser dann im Temp zusammen gebaut wird und der modifizierende FC/FB dann die Werte im Temp-Bereich modifiziert, ist das auch OK. Bringt in dem Fall halt nix.

    Wenn man einen Any über eine Schnittstelle übergibt ist klar das man dessen Zusammensetzung lesen will damit man den Zielbereich bearbeiten kann. Die Frage ist halt nur ob man davon ausgehen muss dass man auch daran interessiert sein könnte diese Zusammensetzung zu bearbeiten.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Ein Unterschied ist, dass SCL den Parameter nochmal umkopiert.
    Ja, leider ist er dann nicht mehr so gütig ihn am Schluss nochmal zurück zu kopieren...
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  3. #13
    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 PN/DP Beitrag anzeigen
    Nicht gut. Tut es nicht.
    Über den Stack wird nicht der ANY übergeben,
    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    @PN
    Es wird schon ein 10 Byte Any übergeben.
    Hast' recht, da habe ich auf dem nachhause-Weg was verwechselt...


    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Theoretisch könnte jemand deinen Baustein aus AWL heraus mit:

    CALL "FC_GetAny" (
    InDB := #InFIFONr,
    InOffset := #InOffset,
    InLength := #InLen,
    OutAny := P#DB1.DBX 200.0 BYTE 1000)

    aufrufen. Da kommt auch nichts sinnvolles bei heraus. So wird ein Any aber üblicherweise verwendet.
    Genau sowas macht z.B. der SFC20 BLKMOV: da wird der DSTBLK-ANY als OUT übergeben, und niemand wundert sich!


    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    So wie du das in AWL verwendest, ist eigentlich nicht das wozu ein Any-Pointer vorgesehen ist.
    Richtig, die ANY-Sache ist vielleicht ein großes Missverständnis.

    ANY erstellen macht man eigentlich nicht um die Adresse von Variablen zu erhalten im Sinne eines Adress-Operators. ANY heißt nicht "Adresse" sondern "beliebig". ANY wird benutzt um Aktualwerte beliebigen Datentyps übergeben zu können. Der aufgerufene Baustein teilt mit, daß er mit verschiedenen Datentypen an IN/OUT/IN_OUT-Parametern umgehen kann und der Aufrufer übergibt dem Baustein die unterschiedlichsten Variablen per ANY-Pointer. Egal ob bei IN/OUT/IN_OUT deklariert - die Übergabe der ANY-Pointer ist nur in dieser Richtung vorgesehen. Nach dem Aufruf werden ANY-OUT/-IN_OUT-Werte auch NICHT in die Aktual-Variablen kopiert, der Baustein muß selber zu den übergebenen Adressen schreiben!

    Eine Rückgabe von ANY-Pointern ist nicht vorgesehen. Daher das vielleicht unverständliche Verhalten von SCL. Weiters kann SCL auch keine Function (FC) aufrufen, deren RETURN als ANY deklariert ist - das ist einfach nicht vorgesehen.

    Um von einer FC einen Wert in eine ANY-Variable zurückzugeben, muß:
    - der Aufrufer die Adresse der ANY-Variable an die FC übergeben
    - die FC zu dieser Adresse schreiben

    SCL übergibt aber nicht die Adresse von ANY-Variablen, sondern kopiert den Wert der ANY-Variable in eine temporäre Variable im Lokaldatenstack und übergibt deren Adresse. Die Adresse der original-Variable bleibt der FC verborgen. Es ist nicht möglich, die Adresse der original-Variable zu ermitteln um dahin zu schreiben. Außerhalb der FC im aufrufenden SCL kommt man nicht an die temporär im Stack benutzte Variable ran, SCL verwendet den Wert dieser Variable auch nicht weiter - eine Rückgabe von irgendwas über diese Variable ist nutzlos.

    Daß SCL die Adresse einer ANY-Variablen übergibt geht nur über den Trick, die Adresse einer anderen nicht-ANY-Variable oder Struktur zu übergeben, welche per AT auf der Adresse der ANY-Variable liegt.
    Auf diese Weise kann man dann doch ANY-Pointer an SCL zurückgeben.

    Zitat Zitat von Hilfe zu STEP7
    Verwenden des Parametertyps ANY

    Sie können für einen Baustein Formalparameter definieren, die für Aktualparameter mit beliebigen Datentypen geeignet sind. Dies ist vor allem dann nützlich, wenn der Datentyp des Aktualparameters, der beim Aufrufen des Bausteins bereitgestellt wird, unbekannt ist oder variieren kann (und wenn ein beliebiger Datentyp zulässig ist). In der Variablendeklaration des Bausteins deklarieren Sie den Parameter als Datentyp ANY. In STEP 7 können Sie dann einen Aktualparameter eines beliebigen Datentyps zuordnen.

    Zitat Zitat von Löwensenft Beitrag anzeigen
    Da kommt mir mal wieder die Frage hoch, ob es bei Siemens nicht zum guten Programmierstil dazugehört definierte Funktionen in eben solche zu verpacken.
    Apropos guten Programmierstil:
    Man sollte mal darüber nachdenken, ob man heute noch Bausteine mit solch unsauberem nicht in den Referenzdaten auftauchendem Absolut-Adress-Gebastel im Stile des vorigen Jahrhunderts entwickelt. Ich sehe schon in 2 Jahren die Frage: "Hilfe, das TIA mag meinen Baustein nicht ..."

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  4. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    RONIN (02.04.2015)

  5. #14
    Registriert seit
    10.10.2008
    Beiträge
    43
    Danke
    1
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi Leute,

    danke für die vielen Erklärungen. Ich hatte gestern abend und gerade noch einmal ein wenig getestet und mir die Ergebnisse nochmal mit der "DotNetSiemensPLCToolBoxLibrary" (ein richtig tolles Tool! ) angeschaut. Dabei ist mir aufgefallen, dass das Tool so clever ist und versucht UC-Aufrufe in CALL-Aufrufe zu wandeln. Häkchen raus und schon sehe ich die wahren Innereien meines AWL-Codes.

    Dort passiert, wenn ich bspw. BLKMOV mit "P#DB1.DBX0.0 BYTE 100" aufrufe, genau das gleiche. Er kopiert die ANY-Daten in freien Lokaldatenspeicher und übergibt (natürlich) nur 32bit, den Speicherbereich+Byte+Bit-adresse. Wie ihr weiter richtig bemerkt habt, will BLKMOV natürlich wissen, was in dem ANY steht, der an der übergebenen (32bittigen) Adresse steht. AWL spart sich hier einfach das Erstellen einer Kopie der angegebenen temporären ANY-Variable.

    Das heißt für mich im Moment weiter, dass mein GetAny-Baustein mehr aus "Zufall" funktioniert.

    Wegen des Programmierstils: Das ist so eine Sache. Wenn ich aufgrund von Eingangsparametern auf Daten zugreifen muss, die aufgrund der Menge der Daten über mehrere DBs verteilt sind, dann bin ich doch froh, dass ich mir da einen Pointer auf die richtige Stelle bauen kann... Wenn es diese bösen DB-Grenzen nur nicht gäbe, dann könnte man sicherlich wunderbar ohne Auskommen ...

    Apropos habe ich das gleiche "Problem" in SCL: Wenn ich dynamisch per WORD_TO_BLOCK_DB auf einen DB zugreifen will/muss, dann habe ich hier noch nichtmal die Möglichkeit dem Compiler zu sagen, dass der DB von einem bestimmten "Typ" ist um dann wieder symbolisch drauf zuzugreifen (wie gesagt, ich komme aus der Hochsprache und bin auf SPS-Seite also absoluter Verfechter von symbolischen Zugriffen!). Typecasting (ohne BLKMOV in eine entsprechende Struktur) wäre was schönes...

    Vielen Dank für die Aufklärung über die Interna! Wieder was gelernt.

    Viele Grüße
    Max

Ähnliche Themen

  1. ANY Pointer als In Parameter...
    Von haraldign im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 05.02.2016, 13:35
  2. ANY als Parameter in SCL
    Von Züttu im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 08.01.2013, 19:43
  3. UDT als FC-Parameter
    Von Reinhard.Steinbrueck im Forum Simatic
    Antworten: 13
    Letzter Beitrag: 15.07.2011, 18:01
  4. UDT als IN-Parameter am FB
    Von OB21 im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 15.08.2010, 17:14
  5. SCL - OB und Array als Parameter
    Von Bluescreener im Forum Hochsprachen - OPC
    Antworten: 1
    Letzter Beitrag: 15.02.2008, 15:21

Lesezeichen

Berechtigungen

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