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

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

Thema: SCL Daten von FB in beliebigen DB schreiben

  1. #11
    ChrissT ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    23.07.2013
    Beiträge
    16
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    @ Bapho:

    Vielen Dank für den Tipp. Das passt so nicht ganz. Ich will dem FB3 einfach einen globalen DB nennen indem er die Diagnosedaten legen soll. Nichts auswerten.
    Eleganter geht dein vorhaben mit BLOCK_MOV.

    @Thomas_v2.1
    C-Code:

    int diagnose (int* buffer)
    {
    memcpy(diagnose, buffer, sizeof(buffer)) //jaja ich weiss sizeof ist nur die länge der Adresse ist aber klar was ich meine
    }

    int buff[10];

    diagnose(int* buff) //Aufruf der Funktion und übergabe des Zeigers auf den Speicherbereich.

    An deiner Idee bin ich gerade am basteln. Da Teilnehmer 1 der DB1, Teilnehmer 2 der DB2, usw zugordnet ist, würde ich aber gerne die DB-Nummer als Variable übergeben. Da die DB's alle gleich aufgebaut sind.
    Bsp:

    Teilnehmer := 1
    DB[Teilnehmer].Array1 //in dieses Array könnte ich dann die Daten mit BLOCK_MOV kopieren.

    Geht sowas?? Also die DB Nummer als Variable. WORD_TO_BLOCK_DB gibts in TIA nicht....
    Ich flipp noch aus...........

  2. #12
    Registriert seit
    29.03.2004
    Beiträge
    5.741
    Danke
    143
    Erhielt 1.687 Danke für 1.226 Beiträge

    Standard

    Ich versteh nicht wozu die der Zugriff über DB Nummern, sowas würde ich nur machen wenn es absolut nicht anders geht. Und in 99% der Fälle geht es anders - wenn man die Daten richtig strukturiert hat.

    Man kann in einem DB auch Arrays anlegen, oder Arrays of Struct (oder besser noch UDT), oder Array of Array, oder...
    Code:
    DATA_BLOCK "Global_DB"
    
    STRUCT
        Data : ARRAY[0..10] OF STRUCT
            iVal1 : INT;
            iVal2 : INT;
        END_STRUCT;
    END_STRUCT
    Zugriff geht dann über Index:
    Code:
    "Global_DB".Data[#Index].iVal1 := 123;
    Kopieren geht ohne Blockmove
    Code:
    "Global_DB".Data[1] := "Global_DB".Data[2];

  3. #13
    Registriert seit
    29.03.2004
    Beiträge
    5.741
    Danke
    143
    Erhielt 1.687 Danke für 1.226 Beiträge

    Standard

    Zitat Zitat von ChrissT Beitrag anzeigen
    C-Code:

    int diagnose (int* buffer)
    {
    memcpy(diagnose, buffer, sizeof(buffer)) //jaja ich weiss sizeof ist nur die länge der Adresse ist aber klar was ich meine
    }

    int buff[10];

    diagnose(int* buff) //Aufruf der Funktion und übergabe des Zeigers auf den Speicherbereich.
    Soetwas geht in SCL nicht, bzw. macht keinen wirklichen Sinn.
    Man legt vorher fest wie ein Datensatz der Diagnose auszusehen hat, und macht daraus optimalerweise einen UDT.
    Dann legst du einen FC an, der als IN_OUT Parameter eine Variable vom Typ des UDTs hat.
    In dem FB der den FC aufruft, legst du z.B. im Stat-Bereich ebenfalls eine Variable vom Typ des UDTs an. Wird der FC aufgerufen bekommt er als Parameter die Instanz-Variable übermittelt.

    Hier mal ein Beispiel wie ich das vom Prinzip her meine (Programm ist so ohne sinnvolle Funktion, nur als Demonstration):
    Code:
    // Datensatz für Diagnosedaten
    TYPE "tDiagSet"
        STRUCT
            Status : INT;
            FehlerNr : INT;
        END_STRUCT
    END_TYPE
    
    
    // Global-DB mit Speicher für 10 Diagnosesätze
    DATA_BLOCK "Global_DB"
    STRUCT
        Data : ARRAY[1..10] OF "tDiagSet";
    END_STRUCT
    BEGIN
    END_DATA_BLOCK
    
    
    // Funktion die Diagnosedaten einsammelt
    FUNCTION "GetDiagData" : VOID
    VAR_IN_OUT
        DiagData : "tDiagSet";
    END_VAR
    
    BEGIN
        DiagData.Status := 100;
        DiagData.FehlerNr := 1;
    END_FUNCTION
    
    
    // Übergeordnete Funktion
    FUNCTION_BLOCK FB901
    VAR
        DiagBuf : "tDiagSet";
    END_VAR
    
    // Diagnosedaten holen
    "GetDiagData"(DiagData := DiagBuf);
    
    // Diagnosesatz in Global DB kopieren
    "Global_DB".Data[1] := DiagBuf;
    
    END_FUNCTION_BLOCK

  4. #14
    Registriert seit
    01.10.2012
    Beiträge
    203
    Danke
    12
    Erhielt 56 Danke für 36 Beiträge

    Standard

    Irgendwie habe ich das Gefühl wir reden aneinander vorbei.

    Du hast 10 Teilnehmer und 10 DBs mit gleicher Struktur, wenn ein Teilnehmer Probleme macht, werden diverse Diagnosedaten in dem DB abgelegt. Du willst nun im Fehlerfall die Daten in aus dem entsprechenden DB in einen anderen DB kopieren um das dann da zu puffern oder was auch immer. Dein Problem ist nun, wie du die Daten aus dem richtigen DB kopierst, oder?
    Also machste dir einen Fehler FC/FB (Methode), legst da als Input die Nummer des entsprechenden DB an und kopierst dann die Geschichte mit Blockmove oder mit einer Schleife.
    Ich habe den Blockmove immer nur in AWL verwendet, in SCl spar ich mir das Pointerbasteln und mach es mit einer For Schleife.

  5. #15
    ChrissT ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    23.07.2013
    Beiträge
    16
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo,

    nochmal viele Dank für eure Bemühungen. Ich versuche es jetzt mal so darzustellen wie ich es habe.


    DATA_BLOCK "Global_DB1"
    Liste_1: ARRAY[1..10] OF "Byte";
    Liste_2: ARRAY[1..10] OF "Byte";
    Liste_3: ARRAY[1..10] OF "Byte";
    BEGIN
    END_DATA_BLOCK

    DATA_BLOCK "Global_DB2"
    Liste_1: ARRAY[1..10] OF "Byte";
    Liste_2: ARRAY[1..10] OF "Byte";
    Liste_3: ARRAY[1..10] OF "Byte";
    BEGIN
    END_DATA_BLOCK

    //Teilnehmer 1 fehlerhaft FB1-->FB2
    FUNCTION "GetDiagData" : VOID
    VAR_IN_OUT
    DB : "Global_DB1"; // Das hier geht schon nicht in TIA V12 wie soll ich einem FB einen DB mitteilen?
    END_VAR

    //FB2->FB3 //holt Diagliste 1
    //get liste 1 und lege sie in
    Global_DB1.Liste_1 := (Daignose Daten für Liste 1)
    //get liste 2 und lege sie in
    Global_DB1.Liste_2 := (Daignose Daten für Liste 2)

    Ich will doch nur, dass jeder Teilnehmer einen eigenen DB hat indem man, sollte er fehlerhaft (gewesen) sein, die Diagnosedaten findet. Die Diagnosedaten zu holen soll eine Funktion übernehmen, der ich aber noch mitteilen will wohin sie die Daten kopieren soll. Ich habe bei einem fehlerhaften Teilnehmer immer den gleichen DB, aber unterschiedliche "Listen" (ARRAYs) die gefüllt werden müssen.

    Letztendlich brauche ich doch nur eine Art referenz um offen für Erweiterungen zu sein. Mein Ziel ist es, sollte ein weiterer Teilnehmer dazu kommen, dass man lediglich den DB kopieren und diesen als neuen Parameter weiter geben muss.

    Das muss gehen, da bin ich mir sicher.... Ich will doch nur einen Zeiger auf ein globalen DB und dann einen Zeiger auf ein ARRAY in diesem DB.
    Geändert von ChrissT (02.09.2013 um 17:26 Uhr)

  6. #16
    Registriert seit
    29.03.2004
    Beiträge
    5.741
    Danke
    143
    Erhielt 1.687 Danke für 1.226 Beiträge

    Standard

    Wie viele Teilnehmer hast du denn, und auf wieviele soll das ggf. erweitert werden?
    Wenn es nur 10 sind, würde ich wohl eine Case-Abfrage machen in der dann für den Teilnehmer auf den zugehörigen Datenbereich geschrieben wird.

    Vielleicht ist dein Konzept mit deiner zentralen Diagnosefunktion die alle Teilnehmer abfragt auch nicht ganz optimal.
    Wenn du einen FB pro Teilnehmer hättest der nur sich selber diagnostiziert ist das einfacher zu handhaben. Kommt ein neuer Teilnehmer hinzu, fügst du einfach eine neue FB-Instanz hinzu und fertig.

  7. #17
    ChrissT ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    23.07.2013
    Beiträge
    16
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich habe anfänglich drei Teilnehmer und will bis 16 erweitern können.

    An die CASE Abfrage hab ich auch schon gedacht. Ich könnte eine Teilnehmernummer weiterreichen. Aber dann müsste ich doch auch über einen INDEX auf den DB zugreifen können oder?
    Auch das ist mir bis jetzt noch nicht gelungen.

    Die Idee mit dem FB finde ich gar nicht so schecht. Erhöhe ich dadurch nicht die CPU-Last? Ich meine ich hab ein vielfaches an FBs.
    Aber kennst du das, wenn du dir einen Weg ausgedacht hast, der sicherlich gut ist, aber nur an der Umsetzung scheitert, dann verfolge ich den bis es passt. Und eine Referenz zu übergeben muss in TIA SCL doch gehe oder?

    Kannst du dir mittlerweile vorstellen was ich machen will?

  8. #18
    ChrissT ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    23.07.2013
    Beiträge
    16
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Also,

    jetzt hab ich was gefunden. Mit POKE kann man anscheinend über einen Index auf einen DB zugreifen. Was ich allerdings nicht geschafft habe, ist daten in ein array des DB zu schreiben.

    //DB1
    DATA_BLOCK "Global_DB1"
    Liste_1: ARRAY[1..10] OF "Byte";
    Liste_2: ARRAY[1..10] OF "Byte";
    Liste_3: ARRAY[1..10] OF "Byte";
    BEGIN
    END_DATA_BLOCK

    FOR #count := 0 TO 10 DO
    POKE(area:=16#84,
    dbNumber:=#teilnehmer,
    byteOffset:=(#offset+#count),
    value:=#data_recv[#count]);
    ;
    END_FOR;

    Sollte das nicht funktionieren? Offset ist für die erste Liste ->Liste_1 doch 0, oder?

Ähnliche Themen

  1. TIA Daten von Sentron PAC 3200 in DB schreiben
    Von 4nD1 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 09.07.2013, 13:25
  2. Wie Daten von SMA OPC in S7-300 schreiben?
    Von Klärmolch im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 08.06.2012, 15:52
  3. Status 8F62 beim Schreiben von FTP - Daten
    Von CrazyCat im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 10.05.2010, 18:39
  4. Antworten: 2
    Letzter Beitrag: 10.04.2009, 14:10
  5. Daten von TP170B Color auf CF-Card schreiben
    Von elektro_hirs im Forum HMI
    Antworten: 0
    Letzter Beitrag: 04.04.2006, 09:51

Lesezeichen

Berechtigungen

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