Problem Interconnect Signale (RJ3/S430 mit ProfibusDP)

  • Hallo erstmal ,
    ich bin neu hier , und auf euer Forum gestossen beim googlen nach meinem Interconnect Problem. Vielleicht hat hier schon jemand ein ähnliches Phänomen gehabt.


    Nun zur Sache :)


    Ich habe hier in der Firma 23 Roboter die mit Klebeapplikation ausgestattet sind (SCA) . Um verschiedene Signalzustände an die SPS (BoschCL550) durchzureichen , benutzen wir Interconnect Signale , die dann weiter verarbeitet werden.
    10 Signale sind nach unserem Standard parametriert und funktionieren auch.


    Ich habe ein weiteres Signal das von einem Initiator der Klebeanlage kommt zu den vorhandenen hinzugefügt , und werte es in der Sps aus.


    Konkret heisst das :


    DI255 ---> DO113


    Dabei ist mir folgendes aufgefallen. Nach dem "enablen" des Interconnects konnte ich zwar den DI255 als "high" sehen (bei bedämpftem Ini) , aber an DO113 tat sich nichts. Nach einigem Probieren gelang es mir das durchschalten des Signals zu "reaktivieren" , indem ich einen anderen DI nahm. In diesem Fall war es DI2 , der die Betriebsart der Anlage darstellt.


    Zusammengefasst wars also so , das sich am Eingang etwas tat , und am Ausgang nicht. Erst durch DI2 (DI5 ging auch) lies sich DO113 dazu überreden mit meiner SPS zu reden.
    Dieses Phänomen trat an ALLEN RJ3 Steuerungen auf . Damit nicht genug , nach einer Zeit von 1-2 Wochen (genau weiss ich es leider nicht) , ist das Signal (DO113) wieder "eingefroren".



    Da ich schon mit 2 Fanuc Service-Technikern telefoniert habe , und die mir auch nicht weiter helfen konnten , probiere ich es nunmal hier. Vielleicht kennt jemand das Problem und/oder kann mir einen Tip geben. Sollte noch etwas unklar sein , einfach Fragen :zwink:


    mfG Fossi

    Einmal editiert, zuletzt von Fossi ()

  • ANZEIGE
  • Hallo Fossi,


    wie groß ist denn dein SLAVE-Bereich zur Kommunikation mit der SPS?
    Ich gehe davon aus, dass das Signal DI255 nicht von irgendeinem anderen Signal überschrieben wird.
    (z. B. einem GI)


    Vielleicht ist auch die Grenze der Interconnect-Verbindungen erreicht?
    (=> siehe Variable $THRTABLENUM[3]; lässt sich im INIT-Start verändern)


    Welches Signal von der SCA willst Du denn durchreichen?


    Gruß
    mwe

  • Hallo mwe ,


    Eingangseitig am Interconnect hab ich keine Probleme , nur der DO "friert" ein . DI255 iss in unserem Standard für das "Vorwarnung Fasswechsel" Signal der SCA vorgesehen. Abweichend davon , benutze ich lediglich nicht DO103 sonder DO113 um das Signal in der SPS auszuwerten . Auch das funzt , wenn der DO mal aktiv ist.



    Zitat

    Vielleicht ist auch die Grenze der Interconnect-Verbindungen erreicht?
    (=> siehe Variable $THRTABLENUM[3]; lässt sich im INIT-Start verändern)


    Das ist ein Ansatz , ich werde es heute Nacht kontrollieren.


    Danke für den ersten Tip hier aus dem Forum :)


    mfG Fossi

  • Hallo Fossi,


    nun ja, auch auf Ausgangsseite kann ja der DO von einem GOUT überschrieben oder beschrieben werden.
    Ob dies der Fall ist, kann man sich in einem Backup in der Datei SUMMARY.DG anschauen.
    (man scrolle zeimlich ans Ende der Datei ...)
    Das sieht dann für einen GOUT ungefähr so aus:
    GOUT[ 3] Wkz.frg. an SPS
    GOUT 3 RACK: 95 SLOT: 1 PORT: 57 #NUM: 8


    Bei Fragen einfach wieder hier rein posten ...


    Viel Erfolg ...


    Gruß
    mwe :zwink:

  • Hi mwe ,


    Muss ich mir auch angucken heute Abend . Würde aber ein überschreiben des Ausgangs nicht zyklisch stattfinden und das Problem
    sofort wieder aufteten ? Der Signalaustausch funktioniert mehrere Tage/Wochen , bis der DO mal wieder "einfriert" .
    Kann es vielleicht ein Problem sein , wenn der DI-->DO 2 mal parametriert ist ? Standardmässig steht in den Interconnects bei uns unter anderem :


    DI255 disabled ---> DO103 <-- Standard
    DI255 enabled ---> DO113 <-- von mir hinzugefügt



    mfG Fossi

    Einmal editiert, zuletzt von Fossi ()

  • Hi Fossi,
    grundsätzlich würde ich Dir bei der zyklischen Sache zustimmen wenn ich wüsste wann der GO verwendet wird.


    Wenn er aber bei der Parametrierung 'disabled' ist sollte er eigentlich keinerlei Schwierigkeiten machen. Aber zur Sicherheit ersetze doch einfach DO103 mit DO113. Wenn Du diesen Link eh nicht mehr benötigst ist es doch naheliegend diesen dafür zu verwenden. Damit klärt sich eventuell auch Dein 'Anzahl der Interconnect'-Problem?


    robotic74

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Moin Moin :)


    Zitat


    wie groß ist denn dein SLAVE-Bereich zur Kommunikation mit der SPS


    Ich habe jeweils 512 DO und DIs zur Verfügung , die aber nicht alle benutzt werden.



    Zitat

    ersetze doch einfach DO103 mit DO113


    Das habe ich zuerst probiert , als ich auf dieses Problem gestossen bin , brachte aber kein anderes Ergebniss. Die Position innerhalb der Interconnects war auch nicht die Ursache , der DO hatte nicht auf den DI (der high war) reagiert. Das Prob tritt sowohl bei bedämpften Initiator als auch simuliertem Eingang auf . Auch ein "gepulstes" bedämpfen des Initiators hat den DO nicht dazu bewegt zu schalten.



    Hab mir mal ein aktuelles Backup eines der Robots gezogen und auch die Variable $THRTABLENUM[3] angeschaut.


    In meinem "All of above" Backup konnte ich leider keine SUMMARY.DG finden. Ich schliesse einfach mal ein überschreiben aus , da die Parametrierung unserer 700 Robots
    (23 mit Klebeapplikation) bei allen gleich ist . an 2 Robots musste ich auf einen anderen DO ausweichen, da der DO113 schon belegt war. Das Phänomen verlagerte sich dann auf den anderen Ausgang.


    Unter der Variable steht bei uns folgendes :


    $THRTABLENUM[5] of short


    1 [1] 8
    2 [2] 8
    3 [3] 32
    4 [4] 16
    5 [5] 14


    Wobei ich dabei ganz ehrlich sagen muss , das ich nicht weiss was es bedeutet ;)


    Insgesamt werden 17 Interconnect Signale benutzt.



    Ich hoffe , ich hab jetzt richtig für Verwirrung gesorgt , denn mir geht es auch nicht besser :D


    nächtliche Grüsse Fossi

  • Hi Fossi,
    ich habe die Summary.dg aber bei all meinen letzten Robotern im backup gehabt. Von wann sind Deine Roboter?
    Hast Du die Möglichkeit mit dem Rechner per FTP auf die Roboter zuzugreifgen?


    Zum Thema überlagerte Gruppenausgänge: Hast Du mal geschaut bei den Gruppenausgängen ob die Definition der einzelnen in diesen Bereich fallen könnte?


    Kurze Erklärung zu der Variablen: Unter Pkt. 3 befindet sich die Anzahl der defienierbaren Interconnect Verbindungen wenn ich das von mwe richtig interpretiert habe. Bei einem Init-Start kannst Du mehrer systembedingte Beschränkungen verändern. Anzahl der Register, Positionsregister, etc. eventuell findest Du darunter auch etwas für die Interconnect Sachen.


    Ich hoffe ich konnte Dir etwas helfen.


    robotic74

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Moin,


    robotic74 hat alles gesagt, was ich deinem Problem noch hinzufügen wollte.


    Bei der Variable $THRTABLENUM[5] of short beschreibt der 3. Wert (32)
    die max. Anzahl der DI => DO - Verbindungen.
    Ich hatte mal ein Projekt, bei dem das nicht ausgereicht hat ... deshalb weiß ich das.


    Ansonsten wünsche ich noch viel Glück ...


    Gruß
    mwe

  • Zitat

    ch habe die Summary.dg aber bei all meinen letzten Robotern im backup gehabt. Von wann sind Deine Roboter?
    Hast Du die Möglichkeit mit dem Rechner per FTP auf die Roboter zuzugreifgen?


    Die Roboter sind etwa 5 Jahre alt , ich hab mir auch ältere Backups angeschaut von etlichen Robots , aber keine entsprechende Datei gefunden. Ich werd heute Nacht nochmal per ftp probieren und gucken ob sie da ist.


    Bis hierher erstmal vielen Dank euch beiden für die Unterstützung ! :danke:


    mfg Fossi




    Ps.: Hab 2 RJ3 Steuerungen mit Klebeapplikation gefunden , bei denen das Problem NICHT auftritt. Diese wurden nachträglich vor etwa 2 Jahren eingebaut . Jetzt muss ich nur noch rausfinden was an denen anders ist :o

  • Hi Fossi,
    Sind die beiden neuen Roboter auch wirklich als werksneue Roboter installiert worden? Wenn Ja muss auch hier die Summary.dg zufinden sein!
    Bei den anderen die 5 Jahre alt sind kann es durchaus sein das Ihr die vor dem Betriebsversion entstanden sind bei der eine Summary ausgegeben wurde!
    Also ich glaube mich zu erinnern das ich bei einigen älteren der Rj3 auch keine der Summary.dg dabei hatte. Diese Datei kam erst später hinzu.


    Per ftp hast Du zugriff auf mehrere Laufwerke. Wenn Du mit FileZilla online gehts! Bei andern kann sich das unterscheiden.
    Nimm bitte das Laufwerk md: hier sollten sich auch zu jedem tp-File das dazugehörige ls-File befinden. War zumindestens bei meinen letzten drei Robotern so!


    Also meldest Dich halt einfach!


    robotic74

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden