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

Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 29 von 29

Thema: ANY-Pointer auf temporären Struct im FB

  1. #21
    Registriert seit
    14.10.2008
    Beiträge
    44
    Danke
    8
    Erhielt 3 Danke für 2 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Aha, verstehe jetzt wie du das meinst. Da meine Version mit dem BLKMOV aber schon hinhaut werd ich es mal dabei lassen.

    Eine Frage zur Theorie noch: Während ein Zeiger vom Typ Pointer nur ein Zeiger auf eine Adresse ist, beschreibt ein Zeiger vom Typ Any (über den Wiederholfaktor) eine ganzen Speicherbereich.

    Kann man das so sagen oder is es grundweg falsch?
    If at first you don't succeed, you're not Chuck Norris.

  2. #22
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    ... das ist so ...

    Was mir aber in Anlehnung an den Beitrag von MSB noch einfällt ...
    etwas Ähnliches mache ich auch.
    In der Instanz eines (SCL-)FB's verwalte und verarbeite ich die Daten von mehreren Stationen (eines Rundschalttisches). Dieser FB hat eine IN_OUT-Variable vom Typ UDT über die die Stations-Dazen ausgegeben und auch wieder eingelesen werden können. Die jeweilige Richtung bestimme ich über IN-Parameter vom Typ BOOL. Außerdem übergebe ich die Index-Nummer der gewünschten Station. Auf diese Weise habe ich einen Baustein, der mir die gewünschten Daten direkt in den Ziel-Bereich des Stations-FC's liefert und auch von dort ausliest und verarbeitet.
    Vielleicht auch noch ein Denk-Ansatz für dich ...

    Gruß
    LL

  3. #23
    Registriert seit
    14.10.2008
    Beiträge
    44
    Danke
    8
    Erhielt 3 Danke für 2 Beiträge

    Standard

    @ Larry

    Wie übergebe ich einen solchen udt an meinen FB. Denn wenn ich im in/out-Bereich eine Variable mit dem Typ udt anlage ist der Datentyp rot hinterlegt und wird vom compiler nicht geschluckt.
    If at first you don't succeed, you're not Chuck Norris.

  4. #24
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    ... ich habe dir da mal einen Screenshot mit angehängt ...
    Wichtig hier ist natürlich, dass der UDT des FC's und der des FB's vom gleichen Typ sind ...!

    Gruß
    LL

  5. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    ChristianPaier (16.07.2009)

  6. #25
    Registriert seit
    14.10.2008
    Beiträge
    44
    Danke
    8
    Erhielt 3 Danke für 2 Beiträge

    Standard

    Vielen Dank für den Screenshot, ich hab jetzt auch geschafft einen udt an einen FB zu übergeben, hab also wieder was gelernt.

    Das Problem ist jetzt nur, ich eigentlich vergessen euch noch was zu über den Programmaufbau zu sagen. Ich sagte es geibt einen Motor-UDT. Stimmt auch so mehr oder weniger.

    Auf Grund der Großen Anzahl an Antrieben, Klappen, Sensoren usw. haben wir in der Firma beschlossen für jedes Objekt einen eigenen UDT anzulegen (Der eigentlicht nur eine Kopie des anderern ist, jedoch mit anderen Kommentaren usw.). Vorteil dran ist die einzelnen Antriebe sind vom Datenbestand leichter zu verwalten und zu bearbeiten. Sind doch weit über 100.

    Der Nachteil allerdings ist das für den Compiler alles unterschiedlische Datentypen sind und deshalb die obige Methode nicht hinhaut.

    Sorry ich hab wieder zu sehr auf hellseherische Fähigkeiten vertraut.

    Aber trotzdem Danke
    If at first you don't succeed, you're not Chuck Norris.

  7. #26
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.404 Danke für 2.002 Beiträge

    Standard

    Tja, ob es durch die vielen UDT's allerdings übersichtlicher wird ...
    Ich würde einen UDT nehmen, den man für Alles verwenden kann und in dem man dann nach Aufgabe mal den und mal den Bereich verwendet. Ob das so sinnvoll ist hängt natürlich auch stark an den "kleinsten gemeinsamen Vielfachen" deiner Einzelfunktionen. Es sollte aber auch nur ein Vorschlag sein ... manchmal kommt man so ja auch auf ganz andere Gedanken ...

    Gruß
    LL

  8. #27
    Registriert seit
    14.10.2008
    Beiträge
    44
    Danke
    8
    Erhielt 3 Danke für 2 Beiträge

    Daumen hoch

    Naja trozdem danke. Mit der jetzigen Lösung kann ich auch gut leben.
    Ich häng den funtkionieren Code mal unten an, falls es noch wer braucht.

    mfg Christian

    Code:
    Funktion: Daten mittels BLKMOV aus einem Db in den Temp-Bereich eines FB kopieren.
    
    //Quellzeiger aufbreiten
     LAR1  P##Ptr_Quelle               //Zeiger in Adressregister laden
          L     W#16#10                     //SyntaxID. bei S7 immer 10 
          T     LB [AR1,P#0.0]
          L     W#16#2                      //Datentyp: Byte
          T     LB [AR1,P#1.0]
          L     #DB_Laenge                  //Wiederholfaktor (Anzahl Bytes)
          T     LW [AR1,P#2.0]
          L     #DB_DbNr                    //Quell-DB Nummer
          T     LW [AR1,P#4.0]
          L     #DB_ByteNr                  //Quelle_Anfang
          SLD   3
          OD    DW#16#84000000              //Speicherbereich (DB) und Byteadresse
          T     LD [AR1,P#6.0]
    
    //Zielzeiger aufbreiten
      LAR1  P##Ptr_Ziel                 //Zeiger in Adressregister laden
          L     W#16#10                     //SyntaxID. bei S7 immer 10 
          T     LB [AR1,P#0.0]
          L     W#16#2                      //Datentyp: Byte
          T     LB [AR1,P#1.0]
          L     #DB_Laenge                  //Wiederholfaktor (Anzahl Bytes)
          T     LW [AR1,P#2.0]
          L     0                           //Quell-DB Nummer 0
          T     LW [AR1,P#4.0]
          L     P##Motordaten               //Pointer auf Motordaten im Temp-Bereich
          OD    DW#16#87000000              //Speicherbereich (Vorherige Lokaldaten) und Byteadresse
    
    //Daten kopieren
          CALL  "BLKMOV"
           SRCBLK :=#Ptr_Quelle             //Any-Ptr Source
           RET_VAL:=#Fehlercode             //Error-Code
           DSTBLK :=#Ptr_Ziel               //Any-Ptr Destination
    If at first you don't succeed, you're not Chuck Norris.

  9. Folgender Benutzer sagt Danke zu ChristianPaier für den nützlichen Beitrag:

    rerdma3s (21.03.2010)

  10. #28
    Registriert seit
    14.10.2008
    Beiträge
    44
    Danke
    8
    Erhielt 3 Danke für 2 Beiträge

    Daumen hoch

    Sorry... Doppelpost
    Geändert von ChristianPaier (16.07.2009 um 13:09 Uhr) Grund: Doppelt gepostet
    If at first you don't succeed, you're not Chuck Norris.

  11. #29
    Registriert seit
    18.02.2009
    Ort
    Köln
    Beiträge
    196
    Danke
    54
    Erhielt 15 Danke für 5 Beiträge

    Daumen hoch


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    wollte nur mal sagen, dass mir der Beitrag gut geholfen hat.
    Habe eine sehr ähnliche Anwendung und kam nicht so richtig weiter.

    Danke
    Gruß rene

Ähnliche Themen

  1. Antworten: 5
    Letzter Beitrag: 08.04.2011, 14:36
  2. Struct vergleich mit pointer und sizeof
    Von hago10 im Forum CODESYS und IEC61131
    Antworten: 17
    Letzter Beitrag: 31.01.2011, 18:22
  3. SCL: Pointer auf Struct in DB
    Von DunderHEAD im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 13.08.2010, 10:05
  4. Twincat POINTER STRUCT
    Von Basstarono im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 21.07.2008, 11:30
  5. pointer über temp struct...
    Von Jochen Kühner im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 24.09.2006, 10:23

Lesezeichen

Berechtigungen

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