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

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

Thema: Bereichslängenfehler bei einem Multiinstanz-FC

  1. #11
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hmm, ein Aufrufzähler im FC wäre eine schöne schnelle Lösung, wenn alle FC-Aufrufe immer ausgeführt werden würden. (Die Idee ist gut: Der FC produziert unique Diagnosewerte und der OB121 sichert die weg - so'rum funktioniert das auch bei sporadisch auftretenden Fehlern.) Doch da der FC nur bei Bedarf aufgerufen wird hilft der Aufrufzähler nicht (liefert vermutlich immer 1). Das Wegsichern eines Diagnosewertes im OB121 kann man aber schonmal nutzen (*).

    Sind eigentlich bei den FC-Aufrufen jeweils andere DB/IDB geöffnet? Dann könnte man auch die DBNO/DINO wegsichern und damit die Aufrufstelle einkreisen.

    Du mußt da wohl die bisher genannten Varianten zur Erzeugung von Diagnosewerten passend zu Deinem Programm etwas flexibel kombinieren um die Fehlerstellen einzukreisen. z.B. am Anfang der übergeordneten Förderer-FC setzt Du MW100 auf 1000, 1100, 1200, 1300 ... und hast dadurch schon mal den FC, in dem der fehlerhafte FC-Aufruf liegt. Dann in diesem Förderer-FC (schrittweise) vor jedem FC-Aufruf den MW100 individuell setzen zu 1201, 1202, 1203 ... oder zunächst jeden zehnten Aufruf zu 1210, 1220, 1230, ...

    Wie häufig kommen die Fehler eigentlich?
    Magst Du uns den Code des FC vielleicht mal zeigen? Vielleicht sehen wir da den Fehler oder weitere Ansatzpunkte zum Finden der individuellen Instanz. (Vielleicht ist da ja einfach nur eine 16-Bit-Operation verwendet wo eine 32-Bit-Operation hingehört?)
    Welches Step7 verwendest Du eigentlich?


    (*) Allerdings würde ich jetzt nicht den FIFO in den OB121 programmieren (im OB121 darf man keinen Programmierfehler machen!). Ein Kopieren des MW100 auf ein zweites MW reicht zum finden jeweils einer Stelle im laufenden Programm.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  2. #12
    Pimp.my.PC ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    05.11.2014
    Beiträge
    13
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Wie häufig kommen die Fehler eigentlich?
    Magst Du uns den Code des FC vielleicht mal zeigen? Vielleicht sehen wir da den Fehler oder weitere Ansatzpunkte zum Finden der individuellen Instanz.
    Den Fehler kenne ich ja bereits.
    Also, ich erkläre mal kurz den Ablauf (Vereinfacht mit 10 Förderern):

    - DB1 enthält 100 STRUCTs in denen Teileinformationen enthalten sind: Charge, Menge, Produktionsdatum, Artikelnummer, usw.
    - DB2 enthält 10 STRUCTs, die wiederum zu jedem Förder einen INT enthält, dessen Inhalt der Zeiger zu dem jeweiligen STRUCT in DB1 ist (den sog. Index).
    - FC100 ist der oft aufgerufene Kopierbaustein

    Jeder Förderer hat seinen eigenen FC, der sich um die Ansteuerung und deren Logik kümmert.

    Wenn jetzt das Teil von Förderer 1 (FC1) auf Förderer 2 (FC2) fährt, ruft FC1 den den FC100 auf und übergibt als Quelle 1 und als Ziel 2.
    FC100 kopiert dann den Inhalt des Quell-INTs in den Ziel-INT im DB2.

    Der Vorteil hierbei ist, dass immer nur der Verweis umkopiert werden muss und die Daten immer am selben Ort liegen bleiben.

    Das Problem scheint zu sein, dass der FC100 in irgendeinem Fördererbaustein (ein Nebenabzweig, der nicht oft befahren wird) eine ungültige Zahl als Quell- oder Ziel bekommt (in unserem Beispiel, sagen wir 13).
    Das ganze ist aber zu komplex um das einfach zu suchen, da hier auch nur mit Verweisen gearbeitet wird, da sich ein Förderer ja auch andersrum drehen kann und dann ein anderes Ziel hat. Zumal sind auch Abzweigungen enthalten.

    Als ich meine Frage gestellt hab, dachte ich, STEP7 bringt eine Funktion mit, mit der ich nachsehen kann, aus welchem Aufruf der Fehler kommt und dass ich diese Funktion einfach nicht finde.
    Ich werde mir nun aus den hier gegebenen Tipps eine Lösung zusammenbauen.
    Vielen Dank an euch für die sehr guten und hilfreichen Tipps.

    LG
    Sebastian

    PS: Ich denke, ich verwende die neueste Version. Lade regelmäßig Updates. Bin schon aufm Heimweg, kann nicht mehr nachsehen.

  3. #13
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Bei meiner Frage nach Deiner Step7-Version meinte ich, ob Du Step7 "classic" V5.5 oder Step7 TIA V13.x benutzt.
    In Step7 V5.5 gibt es meines Wissens keine Möglichkeit, den Aufrufpfad eines FC zur Laufzeit herauszubekommen (vermutlich im B-Stack). Höchstens wenn man die CPU in Stop gehen läßt, dann kann man in den Baustein-Stack, den L-Stack und den U-Stack schauen.
    In Step7 TIA weiß ich nicht, vermutlich gibt es da aber auch nicht mehr Diagnosemöglichkeiten.


    Werden die Daten nur so "aus Spaß" mitgereicht oder bleibt das Fördergut irgendwo nach dem Fehler stehen? Gibt es Folgefehler?
    Kann der Fehler nicht logisch gesucht werden, indem man sich die Transfer-DB ansieht, wo denn Daten fehlen?
    Kann anhand des Fehler-Zeitstempels mit einer anderen Datenbank verglichen werden, wo ein Fördergut zu der Zeit unterwegs war?

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  4. #14
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    775
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Kannst du uns den code des FC100 zeigen?
    Kann man die Zweige die zum Fehlerzeitpunkt genutzt wurden irgendwie nachvollziehen? Damit könnte man die Fehlersuche mit der AufrufID etwas einschränken.
    Unbedingt PN/DPs Hinweis beachten. Ein Fehler im OB121 in einer Produktiven Anlage ist schlecht. Mach darin nur einfache Anweisungen z.B die AufrufID wegsichern.
    Solltest du den FIFO da machen wollen, unbedingt vorgängig im Simulator testen OB121 auslösen und schauen ob er einen Eintrag macht.
    Dann erst den FehlerDB in die produktive CPU laden.

    Da deine FC100 teilweise übersprungen werden, nützt dir das Inkrementieren der ID im FC100 nichts.
    Da wirst du nicht darumherum kommen die aufrufpfade erstmal einzuschränken, das kann recht lange dauern wenn der fehler sehr selten auftritt.

    Am besten die IDkopierung beim ersten Zweig der nicht ausgeschlossen werden kann vor die FC100 in die er verzeigt setzen. Damit kannst du dir den Pfad bis zum Fehler ebnen.
    ggf wird die Verzweigung ja mit einem CASE oder so gemacht, dann die Casevariable als AussprungID hernehmen spart Tiparbeit.

    Es sieht so aus. Als wirst du nicht drum herumkommen den Fehler systematisch einzukreisen.

    mfG René

  5. #15
    Registriert seit
    11.12.2009
    Beiträge
    2.113
    Danke
    388
    Erhielt 390 Danke für 271 Beiträge

    Standard

    Was mir auffällt:

    Dein FC Kopiert nur INT... somit ist dort meiner Meinung nach kein Bereichslängenfehler möglich -> Außer du verlässt den Struct in DB2.
    Nehmen wir mal an Du bekommst nen falschen INT Wert (Warum auch immer) könnte der Fehler wo anders auftreten als dort wo er verursacht wird.

    Beispiel: Der FC kopiert eine falsche ID, und erst bei Verwendung in einem anderen Baustein gibt es einen Bereichslängenfehler, da dort etwa so aufgerufen wird "STRUCT_IM_DB1[FEHLERHAFTER_INDEX].CHARGENNUMMER := 1;"
    Was könnte die Ursache für ne falsche ID sein? Kopierst Du sie wirklich? Ich schätze eher Du verschiebst!

    Also etwa so:

    Code:
    ID_ZIEL := ID_QUELLE;
    ID_QUELLE := LEER;
    Kann es Dir ggf. passieren, dass du diese aktion zweimal machst (Sensor flackert, etc) und Leer dann zufällig 0 ist, dein Ziel wird 0 und dein Struct von 1..100 geht... dann hast Du einen Bereichlängenfehler.
    (Kann das noch jemand nachvollziehen? ich versteh mich selbst nur halb)

    Alternativ:

    Du bindest irgendwo deinen DB1 als INOUT an, und ein Baustein bildet das gleiche Array of Struct intern ab.
    Die länge der Arrays unterscheidet sich, und keiner merkts (weil ggf. gepointert wird o.ä.).

    Nur mal zwei Ansätze zum Suchen.

    Grüße

    Marcel
    Stell Dir vor es geht, und keiner kriegts hin!

  6. #16
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    775
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Da wir ja nicht wissen wie Ziel und Quelle am FC definiert werden. Ich mein um INT auf INT zu kopieren braucht man keinen Baustein. Habe ich jetzt mal angenommen das da irgendwas gepointert wird

    mfG René

  7. #17
    Pimp.my.PC ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    05.11.2014
    Beiträge
    13
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ja, da wird ja nur der Pointer verschoben und noch eine vorherige ID gesichert.
    Der DB besitzt (in meinem Beispiel) ja nur 10 "Datenfächer" (Einen für jede RoBa). Es wird hier aber ein nicht vorhandener Eintrag gepointet.
    Die Nummern der Förder sind z.B. 92421 oder 97122.

    Eine Förderervariable sieht dann so aus:
    DB10."92421.Index" = 15

    Wenn ich mir nun die Artikelnummer eines Teils auf Förderer 92421 ansehen will, muss ich folgende Variable anschauen:
    DB1."Eintrag"[DB10."92421.Index"]."Artikelnummer"

    Ich vermute irgendwo ist eine Variable tippfehlerbehaftet und er will in (z.B.) 924212 einen Index kopieren, den Förderer gibt es aber nicht, der DB geht nur bis 99999
    und 99999 steht irgendwo bei Byte 44.000 im DB und im Diagnosepuffer steht, er will auf Byteadresse 52636 zugreifen.

    Aber ich hab noch ne Idee:
    Ich werde im FC100 einen Bereichsfehler abfangen und im Fehlerfall die Lokaldaten wegsichern. Dann weiß ich, welcher Förderer übergeben wird und finde so bestimmt den Tippfehler.

    Das mit den INT war jetzt hier von mir so geschrieben, ich bin mir nicht sicher ob es wirklich nen INT ist.
    Ich nutze das klassische Step7. Mit TIA-Portal werde ich nicht warm.

    Ich habe auch leider nicht die Möglichkeit in einer anderen Datenbank o.ä. nachzusehen und einen Vergleich zu ziehen.
    Mir ist auch noch nie aufgefallen, dass die Daten irendwo fehlen, da alle paar RoBas ein RFID-Chip ausgelesen wird, auf dem die Daten gesichert sind, und zurückgeholt werden.

    Ich scheue mich auch nicht, den Fehler "manuell" zu suchen, wollte halt nur wissen, was es sonst noch so an Möglichkeiten gibt.

    LG

  8. #18
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Zitat Zitat von Pimp.my.PC Beitrag anzeigen
    Aber ich hab noch ne Idee:
    Ich werde im FC100 einen Bereichsfehler abfangen und im Fehlerfall die Lokaldaten wegsichern. Dann weiß ich, welcher Förderer übergeben wird und finde so bestimmt den Tippfehler.
    Ja, wenn Du in dem FC100 außer den fehlerhaften Quell-/Ziel-Angaben auch übergeben bekommst (oder errechnen kannst), zu welchem Förderer die Daten gehören, dann kannst Du mit diesen Angaben auch gezielt auf die Suche nach der problematischen Aufrufstelle gehen. Die Förderernummer könnte so eine Signatur ähnlich einer Aufruf-ID sein, mit der Du den Fehler einem oder nur wenigen FC-Aufrufen zuordnen kannst. Wo welcher Förderer bearbeitet wird sollte in dem strukturierten Programm ja leicht zu finden sein.

    Merkwürdig finde ich nur, daß die nicht geschriebenen (weil falsch adressierten) Daten anscheinend nirgends vermisst werden oder bisher unbemerkt Datensätze mehrfach vorkommen. Da kann man ja fast froh sein, daß die Fehler Diagnosepuffereinträge verursachen, sonst würden sie wohl gar nicht auffallen.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  9. #19
    Pimp.my.PC ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    05.11.2014
    Beiträge
    13
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Merkwürdig finde ich nur, daß die nicht geschriebenen (weil falsch adressierten) Daten anscheinend nirgends vermisst werden oder bisher unbemerkt Datensätze mehrfach vorkommen. Da kann man ja fast froh sein, daß die Fehler Diagnosepuffereinträge verursachen, sonst würden sie wohl gar nicht auffallen.
    Das wundert mich auch sehr an der ganzen Sache, aber das kommt halt daher, dass das System so gebaut wurde, dass keine Daten verloren gehen können...
    Naja, ich werde mich am Montag mal an den FC geben.

    Nochmal vielen Dank an alle für die guten und hilfreichen Tipps!

    Schönes Wochenende,
    Sebastian

Ähnliche Themen

  1. Step 7 Bereichlängenfehler beim schreiben
    Von Enti im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 26.08.2015, 17:18
  2. Antworten: 2
    Letzter Beitrag: 21.05.2014, 13:15
  3. Step 7 Bereichlängenfehler bei Funktionsaufruf
    Von fk- princess im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 31.01.2014, 10:40
  4. Step 7 Bereichlängenfehler beim Lesen
    Von Vokal12 im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 05.11.2013, 10:58
  5. Antworten: 9
    Letzter Beitrag: 16.03.2012, 19:39

Lesezeichen

Berechtigungen

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