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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: fc als multiinstanz gut oder böse?

  1. #1
    Registriert seit
    16.06.2003
    Ort
    88356 Ostrach
    Beiträge
    4.812
    Danke
    1.231
    Erhielt 1.101 Danke für 527 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    angeregt durch ein beispiel vonserem geschätzten mtglied "onkel dagobert" (welcher übrigens einen klasse programmierstil hat), habe ich das beim letzten projekt so gemacht.

    ich bastel erst einen udt mit allen variablen.

    den setz ich in einem aglobal db beliebig oft in ein array.

    ich mache das was vorher ein fb gemacht hat mit einer fc, diese fc hat neben sonstigen in und out auch eine inout die als mein udt deklariert ist.

    beim aufruf kommt eine instanz in form eines arrayelementes aus dem global db an den inout.

    schöne sache, vor allam in sachen konfigurierbarkeit und flexibilität.

    ich habe zb 20 anlagenteile, die sind aber alle etwas anders, nicht jeder teil hat jeden sensor...

    der udt definiert den maximalausbau.

    jetzt bastel ich mir den "grund-multi-fc" der für alle anlagenteile aufgerufen wird. dann gibst fc mit der selben inout schnittstelle für sonderfuntionen. wird an einem anlagenteil diese funktion nachgerüstet, reicht ein aufruf mit dem ensprechenden arrayelement und der sensorik.
    oder wenn ich nur einen einzelnen messwert habe schreibe ich mit dem scalierungsbaustein direkt in die variable des elements.
    ich kann bits aus dem element auch nach herzenslust auf e/a legen.

    von der sache her gefällt mir das ganz gut, würde gerne mal eure meinung dazu hören.

    nachteil, es scheint als würden die aufgeblasenen inout gewaltig auf die zykluszeit schlagen...
    "Es ist weit besser, große Dinge zu wagen, ruhmreiche Triumphe zu erringen, auch wenn es manchmal bedeutet, Niederlagen einzustecken, als sich zu den Krämerseelen zu gesellen, die weder große Freude noch großen Schmerz empfinden, weil sie im grauen Zwielicht leben, das weder Sieg noch Niederlage kennt." Theodore Roosevelt - President of the United States (1901-1909)
    Zitieren Zitieren fc als multiinstanz gut oder böse?  

  2. Folgender Benutzer sagt Danke zu Markus für den nützlichen Beitrag:

    Onkel Dagobert (01.10.2007)

  3. #2
    Registriert seit
    07.05.2004
    Ort
    Campbelltown
    Beiträge
    2.437
    Danke
    131
    Erhielt 276 Danke für 86 Beiträge

    Standard

    Hallo Markus.

    Eine Frage vorweg, wo liegt der Vorteil gegenüber einem FB?

    Klar hauen die IO´s mit großen UDT´s in den Zyklus, FB´s tun das auch.

    Ich finde das unflexibler, bei einer Änderung des UDT´s kracht das an allen möglichen Stellen. Ich wüsste natürlich auch Vorteile durch diese Art, bei 100 Zylindern z.b. ist ein ARRAY gut lesbar.

    Grundsätzlich ist es aber schwirig auf deine Beschreibung sich einen Reim zu machen.

    Gruß, pt
    Gegen Schwachsinn, Schwachköpfe und armselige Trittbrettfahrer kann man nicht argumentieren.

    Gott sieht alles, auch Signaturen in Geheimschrift,,... aber er petzt nicht.

  4. #3
    Registriert seit
    19.08.2004
    Beiträge
    46
    Danke
    5
    Erhielt 8 Danke für 5 Beiträge

    Standard

    Diesen Programmierstil habe ich mir vor einigen Jahren auch angewöhnt,
    ich möchte gar nicht anders programmieren

    ..es scheint als würden die aufgeblasenen inout gewaltig auf die zykluszeit schlagen...
    In irgend einer Siemens FAQ (find ich grad nicht) habe ich mal gelesen, dass je nach Zugriffsart der Zugriff um Faktor 5..20 mal länger dauert, da der Zugriff nicht direkt sondern über Pointer erfolgt.

    Klar hauen die IO´s mit großen UDT´s in den Zyklus
    Es kommt nicht auf die Datenmenge in der UDT an, es ist egal ob ich der Funktion eine Variable(UDTx) mit 2 Byte oder 200 Byte gebe.
    Es sind die Zugriffe auf diese Variable innerhalb der FC, die entscheidend sind. Wenn man einer FC eine Variable vom typt UDTx übergibt, sieht die FC an ihrem Eingang einen 6 Byte Pointer (DB-NR|Bereichszeiger) und nicht die tatsächliche Datenmenge.

    Um die Zugriffszeit erträglicher zu machen gehe ich so vor :

    1- UDT definieren
    2- Variable im DB vom Typt UDTx anlegen
    3- FC Eingangsvariable definieren , aber der Eingang ist vom Typ "Any-Pointer" und nicht UDTx
    4- In der FC kopieren des Any-Pointers mit Hilfe der Adressregister auf einen temp. Any-Pointer
    5- Definieren einer Temp. Variablen vom Typ UDTx
    5- Mit SFC 20 (Quelle = temp. Any Pointer, Ziel = temp. Variable vom Typ UDTx) den Inhalt der DB-Variablen in Temp. Bereich kopieren
    6- Nun erfolgt der Zugriff auf UDT Variablen "Lokal"
    7- Nach der Verarbeitung mit SFC 20 die Temp. Variable in DB kopieren (Quelle = Temp. Variable(UDTx), Ziel = Temp. Any Pointer)

    Und so sieht es als Code aus :
    Code:
          i_apDaten = IN-Variabel vom Typ Any-Pointer
          t_apDaten = TEMP-Variable vom Typ Any-Pointer
          t_DATEN   = TEMP-Variable vom Typ UDTx
    
    
          TAR1  #t_AR1.Sicherung            // Adressregister 1 sichern
          TAR2  #t_AR2.Sicherung            // Adressregister 2 sichern
    
          L     P##i_apDaten       
          LAR1  
          LAR2  P##t_apDaten
          L     W [AR1,P#0.0]
          T     W [AR2,P#0.0]
          L     D [AR1,P#2.0]
          T     D [AR2,P#2.0]
          L     D [AR1,P#6.0]
          T     D [AR2,P#6.0]
          CALL  "BLKMOV"
           SRCBLK :=#t_apDaten
           RET_VAL:=#t_Fehlerwort
           DSTBLK :=#t_DATEN
          LAR2  #t_AR2.Sicherung
    
    
    Irgend eine Verarbeitung
                .........
                 .........
         U  t_Daten.Freigabe
         U  t_Daten.BlaBla
         =  t_Daten.Ergebnis
                .........
                .........
    
    Nach der Verarbeitung zurück kopieren
    
    
         CALL  "BLKMOV"
           SRCBLK :=#t_DATEN
           RET_VAL:=#t_Fehlerwort
           DSTBLK :=#t_apDaten
    
          LAR1  #t_AR1.Sicherung            // Adressregister 1 wiederherstellen
          LAR2  #t_AR2.Sicherung            // Adressregister 2 wiederherstellen
    Sieht sehr aufwendig aus, ist aber immer die gleiche Sequenz.
    UDT kann sich Ändern, nach einer Konsistenzprüfung ist die Welt aber wieder in Ordnung, wenn man den "Operandenvorrang" richtig gesetzt hat (symbolisch / Absolut)
    Vorteil gegebnüber FBs: Man spart Instanz-DBs. So kann ich meine Anlagenteile in einem DB halten und beliebig Gruppieren.
    Beispielsweise kann ich die Variablen
    Motor ARRAY[1..10] of UDT x
    Ventil ARRAY[1..20] of UDT y
    Platz ARRAY[1..15] of UDT z
    .........
    alle in einem DB halten.
    Der Nachteil ist, dass je nach Größe der definierten UDTs der Lokaldatenstack aufgebläht wird.
    Das nehme ich in Kauf, weil es sehr übersichtlich bleibt und die FCs nahezu "wartungsfrei" sind. (Achte natürlich drauf, dass meine UDTs nicht unnötig aufgebläht sind)

    Bei FBs mache ich das auch so ähnlich (da muß man bei der obigen Sequenz noch auf den AR2 und Instanzanfang achten). Dann sind die Variablen vom Typt UDTx so zu sagen die öffentlichen Daten des Objekts.
    Geändert von SinusQuadrat (30.09.2007 um 10:01 Uhr)

  5. #4
    Avatar von Markus
    Markus ist offline Administrator
    Themenstarter
    Registriert seit
    16.06.2003
    Ort
    88356 Ostrach
    Beiträge
    4.812
    Danke
    1.231
    Erhielt 1.101 Danke für 527 Beiträge

    Standard

    hast du shconmal was von multiinstanz fbs gehört?
    ich sehe bei der art zu programmieren keinen vorteil was den verbrauch von dbs angeht.

    der einzige vorteil für mich ist das beliebig viele bausteine auf die instanz oder teile davon (instanz = udt) zugreifen können.

    und ich je nach ausbau einfach module auf die instanz stecken muss.
    "Es ist weit besser, große Dinge zu wagen, ruhmreiche Triumphe zu erringen, auch wenn es manchmal bedeutet, Niederlagen einzustecken, als sich zu den Krämerseelen zu gesellen, die weder große Freude noch großen Schmerz empfinden, weil sie im grauen Zwielicht leben, das weder Sieg noch Niederlage kennt." Theodore Roosevelt - President of the United States (1901-1909)

  6. #5
    Registriert seit
    29.03.2007
    Beiträge
    123
    Danke
    17
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Hmm... eigentlich ja nicht schlecht. Frage. Wofür machst du die INOUT variable wo du dein UDT angibst?

    Wenn ich das richtig verstehe, brauchst du doch nur einen pointer angeben, damit der FC weiß, welche structur vom array er nutzen soll?

    Das andere ist, wie greifst du bei einer Visu auf diesen DB zu, der ja eigentlich nur den Array enthält!?


    Vielleicht bin ich auch falsch abgebogen, nicht so einfach deine Beschreibung, wenn mans nicht selber gemacht hat.

  7. #6
    Avatar von Markus
    Markus ist offline Administrator
    Themenstarter
    Registriert seit
    16.06.2003
    Ort
    88356 Ostrach
    Beiträge
    4.812
    Danke
    1.231
    Erhielt 1.101 Danke für 527 Beiträge

    Standard

    INOUT weils am einfachsten ist, der Baustein kopiert beim öffnen die Daten des anparametrierten Arrayelementes das ja aus dem selben UDT besteht in den UDT der INOUT, und am schluss automatisch wieder zurück.
    Man muss sich also im gegensatz zur Pointerlösung um nix kümmern.
    sicher geht das mit Pointern auch, wobei das meiner meinung nur dann ein vorteil wäre, wenn es wirklich schondender für die Zykluszeit wäre.

    Wenn ich im UDT aus einem Reserve BOOL zb. das Symbol "Ventil_AUF" mache, dann habe ich das in allen DBs und auch in den "lokalen" Daten der entsprechenden FC´s auf einmal geändert...


    Was soll die Visu dabei für ein Problem haben?
    Das Array besteht aus n UDTs und gut ist.

    die Visu greift auf "Anlage.Teil[x].Tasten.Funktion_Start" oder auf Anlage.Teil[x].Parameter.Vordruck_Max" zu...
    "Es ist weit besser, große Dinge zu wagen, ruhmreiche Triumphe zu erringen, auch wenn es manchmal bedeutet, Niederlagen einzustecken, als sich zu den Krämerseelen zu gesellen, die weder große Freude noch großen Schmerz empfinden, weil sie im grauen Zwielicht leben, das weder Sieg noch Niederlage kennt." Theodore Roosevelt - President of the United States (1901-1909)

  8. #7
    Registriert seit
    29.03.2007
    Beiträge
    123
    Danke
    17
    Erhielt 9 Danke für 9 Beiträge

    Standard

    Joa, stimmt... Man kann den index angeben... Alles klar, dann zieh ich die Visu-frage zurück!

  9. #8
    Registriert seit
    19.08.2004
    Beiträge
    46
    Danke
    5
    Erhielt 8 Danke für 5 Beiträge

    Standard

    Zitat Zitat von Markus Beitrag anzeigen
    hast du shconmal was von multiinstanz fbs gehört?
    ich sehe bei der art zu programmieren keinen vorteil was den verbrauch von dbs angeht.

    der einzige vorteil für mich ist das beliebig viele bausteine auf die instanz oder teile davon (instanz = udt) zugreifen können.

    und ich je nach ausbau einfach module auf die instanz stecken muss.
    Natürlich benutze ich Multiinstanz FBs.
    Den letzten Satz hast du wahrscheinlich überflogen. Ich benutze die Methode für FBs, um global Daten dem FB zu geben/holen. Instanzdaten bleiben in der Instanz, aber der FB erzeugt ja auch Zustände für die restlichen Programmteile. Diese Zustände kann man teilweise auf den Ausgang legen, oder bei "grösseren Sachen" mit UDTs abwickeln.
    Ich gebe beispielsweise einem FB einen Datensatz (irgendWasTypUDT)
    Der FB soll mit den Daten etwas machen (manipulieren) und mir den manipulierten Datensatz wieder global zur verfügung stellen, damit ich bei Bedarf an jeder beliebeigen Stelle dran kommen kann. Zum Arbeiten braucht der FB Variablen (aktuelle Zeit, Flanke,....) Dies sind die Instanzdaten. Nach getaner Arbeit will ich aber meinen Datensatz wieder haben, ich will nicht daß der Datensatz in der Instanz gekapselt ist. Was ich meine hat nichts mit Instanzdaten zu tun, die bleiben, es geht um Übergabe von zusammengesetzten Daten.

    Es gibt Kollegen, die geben dem FB DB-Nr, Anfangsadresse, den Rest (was nach dem Offset wo liegt) haben sie im Kopf und toben sich dann im FB mit AUF [DN-NR], .... , L DW xx, .... aus. Ich will im FB überhaupt keine Absoulutzugriffe haben, deshalb mache ich die Datenübergabe mit Variable(UDTx) -> AnyPointer-> TempVariable.
    Klar kostet das mehr Speicher und auch mehr Zykluszeit, als wenn ich U M3.4 sage. Wenn man den Zugriff über Any-Pointer-> LokalVariable macht hält sich das aber in Grenzen.

    Es kommt darauf an, welche Visualisierung man benutz, wir benutzen zu 99% Siemens (Flexible und WinCC). Dort kann man Strukturen definieren (Kopie der UDTs) und die Visu-Variablen vom Typ dieser Struktur definieren. In Bildbausteinen wird dann dem Bildobjekt die Strukturvariable übergeben.
    Ist man nur an einer Variable interessiert, so definiert man die Variable einzeln, die Daten stehen ja global zur Verfügung,da sehe ich kein Problem.

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

    Markus (29.09.2007)

  11. #9
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.728
    Danke
    398
    Erhielt 2.406 Danke für 2.002 Beiträge

    Standard

    Hallo Markus,
    ich mache bei unseren Anlagen etwas ähnliches ... Die Anlagen sind meisst Rundtisch-Anwendungen. Hier habe ich für die max. mögliche Anzahl von Stationen einen DB mit Array of UDT aus dem ich mir für jede der Sationen die Einzel-UDT's heraushole und wieder hineinschreibe.
    Der Vorteil, der sich für mich daraus ergeben hat ist :
    - ich habe einen SCL-Baustein, der die Liste scannt und aus Einzel-Info's Sammel-Info's baut.
    - derselbe Baustein macht eine Laufzeit- und Timeout-Messung der Stationen.
    - ich muss den Baustein nicht für jede Anlage neu schreiben, sondern er passt für alle Anlagen (Standard-Baustein).

    Ich habe es so verstanden, dass du etwas ähnliches vorhast.
    Für mich ist es so, dass ich durch den Standard-Baustein mit den x-mal Allgemein-UDT's eine Menge Grundarbeit gespart habe. Die Zykluszeit ist dabei aber um einige ms gestiegen. Komfort hat halt auch seinen Preis.

    Das schöne an der Geschichte ist, dass auch meine Mitarbeiter das Werk einsetzen können, ohne es selber programmieren zu können oder dessen Teilfunktionen. Es gibt dann halt ein paar Standard-FC's und die erledigen bei richtiger Parametrierung die ganze Grundarbeit im Programm.

  12. #10
    Registriert seit
    20.11.2004
    Ort
    Linz, OÖ
    Beiträge
    1.365
    Danke
    96
    Erhielt 177 Danke für 133 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von SinusQuadrat Beitrag anzeigen
    Es kommt nicht auf die Datenmenge in der UDT an, es ist egal ob ich der Funktion eine Variable(UDTx) mit 2 Byte oder 200 Byte gebe.
    Es sind die Zugriffe auf diese Variable innerhalb der FC, die entscheidend sind. Wenn man einer FC eine Variable vom typt UDTx übergibt, sieht die FC an ihrem Eingang einen 6 Byte Pointer (DB-NR|Bereichszeiger) und nicht die tatsächliche Datenmenge.
    Stimmt, das Problem ist, dass der Compiler vor jedem Zugriff auf die INOUT-Variablen das Adressregister neu berechnet und dann indiziert (speicherindirekt) darauf zugreift. Das schlägt sich (meiner Erfahrung nach) beim Speicher mit dem faktor 1,5 - 4 nieder, bei der Zykluszeit im Faktor 5-20 (je nachdem, wieviele Daten per INOUT übergeben werden).

    Um die Zugriffszeit erträglicher zu machen gehe ich so vor :

    1- UDT definieren
    2- Variable im DB vom Typt UDTx anlegen
    3- FC Eingangsvariable definieren , aber der Eingang ist vom Typ "Any-Pointer" und nicht UDTx
    4- In der FC kopieren des Any-Pointers mit Hilfe der Adressregister auf einen temp. Any-Pointer
    5- Definieren einer Temp. Variablen vom Typ UDTx
    5- Mit SFC 20 (Quelle = temp. Any Pointer, Ziel = temp. Variable vom Typ UDTx) den Inhalt der DB-Variablen in Temp. Bereich kopieren
    6- Nun erfolgt der Zugriff auf UDT Variablen "Lokal"
    7- Nach der Verarbeitung mit SFC 20 die Temp. Variable in DB kopieren (Quelle = Temp. Variable(UDTx), Ziel = Temp. Any Pointer)
    Löse ich genauso. Diese Variante hat zudem den Vorteil, dass - sollte man wider Erwarten den UDT so ändern müssen, dass sich der Zeitstempel ändern - man nur den UDT-Aufruf in den Lokaldaten des FC 1 x ändern muss + die DB-Deklaration aktualisieren (also ca. 3 Minuten Arbeit).

    Hab das zuletzt bei einer Anlage mit 68 identischen Kühlkreisen so gelöst. Zykluszeit auf einer 317-2PN/DP mit INOUT 65ms, mit Lokaldaten 4ms.

    Um den FC problemlos erweiterbar zu machen, liegen die gesamten daten (z.B. Eingänge/Ausgänge), welcher vom aufrufenden FC an die einzelnen FC-Instanzen übergeben werden bzw. welche dieser rausgibt, ebenfalls im UDT. Diese werden dann im aufrufenden FC direkt per DB-Zugriff zugewiesen bzw. gelesen.

    mfg
    Maxl
    Bin aufgrund §2 der "Rechte des Betreibers" der Forum-Regeln nicht mehr aktiv, da nicht nicht akzeptiere, dass Informationen und Erkenntnisse ohne Quellangabe weitergegeben werden sollen. Jedem steht frei, auf die gleichen Erkenntnisse durch Eigenversuche zu kommen, vor allem Buchautoren.

Ähnliche Themen

  1. Multiinstanz in SCL
    Von godi im Forum Simatic
    Antworten: 11
    Letzter Beitrag: 08.03.2015, 19:59
  2. TIA V11 SCL TON Multiinstanz
    Von MrEASY im Forum Simatic
    Antworten: 14
    Letzter Beitrag: 04.03.2013, 15:17
  3. Multiinstanz
    Von focus81 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 25.05.2010, 14:27
  4. Böse Erfahrung mit OpenDownload.de
    Von Alexander75 im Forum Stammtisch
    Antworten: 10
    Letzter Beitrag: 01.10.2009, 11:55
  5. Multiinstanz
    Von godi im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 01.05.2006, 20:31

Lesezeichen

Berechtigungen

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