Ethernet KRL: Nachrichten bewusst ignorieren

  • Hallo zusammen


    Es ist mir gelungen eine Kamera mit integrierter Bildverarbeitung (eine Cognex In-Sight 7905C) mit einer KRC 4 Steuerung zu verbinden. Die Kamera generiert Positionsdaten und schickt sie als XML über TCP/IP an die Steuerung. Auf der Steuerung läuft Ethernet KRL.

    Funktionierender Beispielcode

    Dies ist die Konfiguration in Config:\User\Common\EthernetKRL\CognexServer.xml:

    Hinweis: Wird o.g. Datei geändert, ist unter Umständen (mutmaßlich beim erstmaligen Inbetriebnehmen, Ändern des TYPE, des Ports oder der IP-Adresse) ein Kaltstart mit "Neueinlesen der Konfiguration" notwendig. Ein WorkVisual deploy reicht nicht aus.


    Dies ist das KRL Programm:

    Problembeschreibung

    Die Kamera sendet Positionsdaten, sobald sie welche hat. Das tut sie alle 100ms und auch während der Roboter sich schon bewegt. Ich bin immer nur am aktuellsten Datum interessiert, weshalb ich den Puffer als LIFO der Größe 1 eingestellt habe. Leider hält das Programm mit dem Fehler CBuffer: Buffer limit! Max size 1 of buffer reached. Buffer expanded. an. Der Puffer wird mit jeder Meldung um 1 vergrößert.


    Ich habe in der Dokumentation gelesen, dass man mit EKI_Lock den Empfangspuffer explizit sperren kann. Das führt jedoch bei mir nur zu der Fehlermeldung CConnection: Can't LOCK receive process!!!!.


    Das Programm funktioniert ansonsten gut. Ich kann die Fahrt nach der Fehlermeldung wiederaufnehmen lassen und der Roboter tut seine Arbeit. Daher habe ich die Anzeige der EthernetKRL EKI Fehler abgeschaltet. Das hilft, fühlt sich aber falsch an. Es könnten andere Fehler auftreten, welche tatsächlich wichtig sind. Wie könnte der offizielle richtige Weg aussehen, das Programm ordentlich laufen zu lassen?


    Viele Grüße

    Hermann

  • KUKA Handwerk
    Anzeige
  • Quote

    Hinweis: Wird o.g. Datei geändert, ist ein Kaltstart mit "Neueinlesen der Konfiguration" notwendig. Ein WorkVisual deploy reicht nicht aus.

    Wieso?


    Ich benutze oft EthernetKRL und habe XML hundertmal geändert - ohne Probleme.

    Das Zurücksetzen des Programms reicht aus, um die Konfigurationsdatei erneut zu lesen.

    Ein Neustart oder WorkVisual deploy war dafür nie notwendig ...

  • Roboter Programm kann EKI_STATUS auswerten auch wehn die Anzeige der EthernetKRL EKI Fehler abgeschaltet ist,

  • Moin panic mode


    Danke für deine Antwort.


    Ein Neustart oder WorkVisual deploy war dafür nie notwendig ...

    Ist wohl auch nur beim ersten mal und mit <EXTERNAL><TYPE>Client</TYPE></EXTERNAL> notwendig. Ich will das im Eröffnungsbeitrag erwähnen. EKI_Init und EKI_Open werden zwar ohne Fehlermeldung ausgeführt, der Server macht den TCP Port jedoch nicht auf. Nach einem Kaltstart funktioniert es dann (mit derselben XML und SRC). KSS ist Version 8.3.20.


    Quote from panic mode

    Roboter Programm kann EKI_STATUS auswerten auch wehn die Anzeige der EthernetKRL EKI Fehler abgeschaltet ist.

    Damit kann ich in der Tat überprüfen, ob EKI_GetReal arbeiten konnte. Es gibt allerdings auch Fehlermeldungen, die auftreten, während sich das Programm gerade in einem WAIT befindet, die erwische ich damit nicht. Auch mir bisher unbekannte aber wichtige Fehlermeldungen könnte ich damit versehentlich "verpassen".


    Insgesamt ist dies eine Liste aller Fehlermeldungen, die ich gesehen habe:

    Code
    ERROR  tEkiNetRcv : CBuffer: Buffer limit! Max size of buffer reached. Buffer expanded.
    ERROR  tEkiNetRcv : CConnection: Close connection. Not able to process data.
    ERROR  tEkiNetRcv : CConnection: Could not receive.
    ERROR  tEkiNetRcv : CIoDevice: Error while recv data. code:-3
    ERROR  tEkiNetRcv : CProcessData: Failed to get single data from received buffer. (Code=)
    ERROR  tEkiNetRcv : CTcpSock::Recv: No socket with index '1'
    ERROR  tFctCall   : CConnection: Can't LOCK receive process!!!!
    ERROR  tFctCall   : EFC_eki_LockUnLock: Failed to lock channel 'XmlServer'. (Code=33280)
    ERROR  tFctCall   : EFC_eki_LockUnLock: Failed to lock channel 'XmlServer'. (Code=34048)


    Ich denke, ich muss das so lassen und hoffe, dass – selbst wenn im Laufe der Projektentwicklung neue Fehlerkategorien dazu kommen –sich keine einzige Fehlermeldung als problematisch der Kategorie "der Roboter hätte mal lieber anhalten sollen" herausstellt. :)


    Viele Grüße

    Hermann

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now