Quit Stop wegen Feldbusfehler

    Hallo!

    Ich habe bei einer KRC2 von 4.1.7 auf 5.2.20 hochgerüstet, weil es sporadisch Probleme beim Hochlauf gab.

    Aber jetzt kommt der Fehler: 2858 Quit Stop wegen Feldbusfehler (Profibus)

    So oft bis der Meldungspuffer voll ist. Quittiert man, werden alle gelöscht, und das gleiche passiert wieder.

    Ich habe auch schon eine CP5614A2 Profibuskarte probiert. Das gleiche Problem.


    Man sieht aber die Eingänge und die Ausgänge lassen sich schalten.

    Ich habe auch schon absichtlich Fehler konfiguriert, dann kommen andere Fehler.

    Also die Anzahl der I/Os passt. Hat ja auch vorher funktioniert.


    Hat jemand einen Tip?

    • Schritt für Schritt zum Roboterprofi!

    Servus,


    was heißt die Ausgänge lassen sich schalten. Am KCP wirst du die Ausgänge immer schalten können. D.h. aber nicht das sie an der SPS oder so ankommen.

    Wenn du in der iosys.ini alles für den Profibus auskommentierst => was macht er dann beim Booten?

    pfbms.ini auch korrekt?


    Auch immer Kaltstart gemacht?


    Gruß

    Martl

    Zitat von roabtec

    Aber jetzt kommt der Fehler: 2858 Quit Stop wegen Feldbusfehler (Profibus)

    Ist das der einzige Fehler?

    Eigentlich sollte dazwischen auch mal eine Meldung mit "Fehler Profibus..." kommen.

    Vielleicht mal im Log nachsehen, könnte sein, dass der Fehler so kurz ansteht, dass er gar nicht richtig ausgegeben wird.

    Hallo!

    Ja, die Ausgänge lassen sich einschalten und kommen auf der SPS an. Ich sehe auch die Eingänge.

    Wenn ich alles in der IOSYS auskommentiere, dann kommt der Fehler: Fehler beim Schreiben und Lesen.

    pfbms.ini ist korrekt. habe auch schon versucht die Einstellungen zu ändern. Ohne Erfolg.

    Ich habe jetzt wieder die alte Festplatte mit 4.1.7 eingebaut, weil der Kunde produzieren will. Da funktioniert alles.

    Kaltstart immer gemacht bei pfbms.ini Änderungen


    Gruß Willi

    Servus,


    wenn alles in der iosys.ini auskommentiert ist => woher sollte dann ein Schreib/Lesefehler kommen?

    Da ist was faul.

    Immer auch einen Kaltstart gemacht am Roboter?

    Bei iosys.ini Änderungen musst du immer Kaltstart machen.


    Hängt auch was am PB-Master des Roboters, würde die funktionierende Kommunikation zur SPS und dann die dennoch auftretenden Fehler erklären.


    Poste mal die beiden Dateien (iosys und pfbms) der beiden Stände.


    Gruß

    Martl

    Hallo,


    am besten wären halt mal wieder aus beiden Softwarständen die Dateien.

    Glaskugel ist bei mir wieder zur Reparatur.;(


    Wenn ich solche Fehler habe dann einfach mal alles deaktivieren und Stückweise wieder in Betrieb nehmen. Bei der KRC2 sind halt die Fehlermeldungen teilweise nicht besonders Aussagekräftig.


    Gruß

    Martl

    Hallo!

    Hat leider bis jetzt gedauert wegen Produktionsbetrieb.

    Es ist nur der Slave in Betrieb.

    Immer Kaltstart gemacht.


    1.Versuch mit A1 Karte, Original IOSYS.ini(alles deaktiviert) und PFBMS.ini MAster=0,SLAVE=0

    -> Keine Fehlermeldung

    2.Versuch IOSYS (Treiber aktiviert) ohne IOs, PFBMS Master=0,Slave=1

    -> Fehler Konfiguration E/A Treiber PBMASL

    3.Versuch IOSYS jetzt mit IOs, PFBMS Slave=0

    -> Fehler Konfiguration E/A Treiber PBMASL

    4. Slave=1

    -> Fehler beim Lesen Treiber CP561DRV

    -> Fehler Überlauf Meldungspuffer

    Eingänge funktionieren

    5. Versuch A2 Karte mit den gleichen Einstellungen

    ->nur Fehler beim Schreiben nach vielen blinkenden Meldungen


    Anbei die gewünschten Dateien.

    Kann es sein, das bei Version 5 der Steckplatz woanders ist?


    Nach Wechsel auf V4.1.7 und A1 keine Probleme mehr.



    V4.1.7.iosys log.txtV4.1.7.IOSYS.txtV4.1.7.pfbms log.txtV4.1.7.PFBMS.txtV5.2.20.iosys log.txtV5.2.20.iosys.txtV5.2.20.pfbms log.txtV5.2.20.pfbms.txt

    Nach Deinen Angaben sollte dies eigentlich ein typisches Treiber- oder Konfigurationsproblem sein.


    Pfbms.ini:

    Versuch es bitte mal 1:1 mit den untenstehenden Einstellungen.

    Gab es einen speziellen Grund für Dich, OLD_ERROR_DB abzuändern gegenüber dem Standard ?ACCEPTABLE_XXXXXX_LENGTH=244 ändert normalerweise niemand.

    Datenkonsistenz im Bus macht nur Sinn, wenn sie auch in VxWorks "scharf" ist.


    Steckplatz ist Mainboard-, nicht Softwareabhängig.


    Die V5.2.20 hat eine Treiberversion V2.4 Build 1.

    Auch mal versucht, diesen zu Tauschen und einen zu verwenden, z.B. von der V5.2.19 oder V5.2.21 ?

    Diese haben andere Treiberversionen.



    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

    Danke für die Hilfestellung.

    Morgen nach der Produktion teste ich Deine Einstellungen und danach wenn nötig einen anderen Treiber. (V5.2.12 habe ich)

    Laut einer Doku lief der Robi mal mit 5.2.19 bei BMW. Ich werde da mal anklopfen um den Treiber zu bekommen. Oder hast Du den zufällig?

    ACCEPTABLE_XXXXXX_LENGTH=244 habe ich schon getestet, ohne Erfolg.

    OLD_ERROR_DB auch schon getestet.

    Ich melde mich wieder nach den Tests.

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