Serieller Port

  • Hallo Forum!


    Weil ich ne ganze Weile vom Roboterprojekt weg war, war ich lange still. Jetzt habe ich wieder ein Problem, bei dem ihr hoffentlich helfen könnt:


    Über die SPS sendet der Kuka zyklisch Statusmeldungen an einen zweiten PC, von dem er auch einfache Kommandos erhält. Dabei kommt es vor, das der Kuka plötzlich aufhört über den seriellen Port zu senden und auch keine Nachrichten mehr empfängt. Plötzlich meint, das dies zwar oft, aber nicht reproduzierbar passiert, ich kann nicht erkennen, das dies von irgendetwas ausgelöst wird. Verwirrrenderweise lief der Roboter mehrere Jahre, ohne dieses Problem zu haben, ein zweiter baugleicher Roboter hat das Problem nicht.


    Der STATE-Rückgabewert von CWRITE ist dabei nach wie vor OK, so als ob gesendet würde, die übrigen Berechnungen, die die SPS vornimmt werden nach wie vor abgearbeitet. Telnet zeigt den Datenstrom allerdings nicht an. Die Variable $DATA_SER ist unabhängig von der Menge der epfangenen Daten 0, wird zu viel empfangen erscheint irgendwann die Meldung "Empfangspuffer voll", also scheint schon etwas mit den Daten des seriellen Port zu passieren.
    Wenn von Auto auf T1 umgeschaltet wird funktioniert plötzlich wieder alles.
    Als Workaround habe ich versucht den seriellen Port regelmäßig (alle paar minuten) zu schließen und wieder zu öffnen, ohne Erfolg.


    Kennt jemand das Problem? Habt ihr einen Tip, was ich versuchen könnte?


    Vielen Dank schon mal,


    Kai

    If you and DEAD people can read Hex, how many people can read Hex?

  • Schritt für Schritt zum Roboterprofi!
  • Das steht leider schon auf #sync.
    Hier der interessante Teil der SPS.sub:


    serialHandle ist ne globale Variable.
    Und noch der interessante Teil der serial.ini:


    Danke schon mal!

    If you and DEAD people can read Hex, how many people can read Hex?

  • Hallo Kai,
    sorry, bin immer noch krank zuhause.


    Du hast ein Integerfeld, wobei ein Integer 4 Bytes hat.
    Probier mal:


    cwrite(serialHandle , STATE , MODUS , "%.18r" , all[]);send out
    oder
    cwrite(serialHandle , STATE , MODUS , "%4.18r" , all[]);send out


    Kann das leider Zuhause nicht ausprobieren.
    a+

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Das ist schon Absicht so, der soll nur die beiden niederwertigen Bytes des INT raus senden. Das klappt ja auch so weit, ich bekomme für gewöhnlich Daten gesendet. Von Zeit zu Zeit - mal erst nach ein paar Stunden, mal nach ein paar Minuten - bricht die Kommunikation ab, dem KRL-Programm wird aber ein erfoglreiches Senden mitgeteilt (Telnet zeigt dann keine gesendeten Daten an).
    Das kann für ein paar Sekunden so sein, mitunter auch für ein paar Stunden.

    If you and DEAD people can read Hex, how many people can read Hex?

  • Guten Morgen Kai,


    - im Telnet siehst Du nur die Übergabe der Daten an den seriellen Treiber
    d.h. bei Dir wird das CWRITE nicht ausgeführt
    - beim Protokoll 4 (XONXOFF) gibt es keine "Überprüfung" des Sendens,
    d.h. wenn kein Kabel angeschlossen ist fallen die Bytes auf den Boden.
    Bitte sofort aufräumen - elektrisch geladen :icon_rofl:
    - serielle Kommunikation im Kontext des SPS.SUBs hatte schon immer
    kleinere Macken
    ==> wäre es für Dich möglich die Kommunikation vom Roboterinterpreter
    ausführen zu lassen ?
    a+

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Hui,


    möglich ist prinzipiell alles, ist ja "mein" Roboter.
    Was heißt vom Roboterinterpreter ausführen lassen? Gibts da ne Doku, nen Tip oder so?

    If you and DEAD people can read Hex, how many people can read Hex?

  • Hallo zusammen,


    er meinte wohl im die Kommunikation aus dem Submit raus direkt in das Roboterprogramm.
    also von der vom Code ändert sich erstmal wenig nur wo er ausgeführt wird ändert sich


    Gruß Loipe

  • genau Loipe !!


    da gibt es keinen Trick. Was jetzt im SUB steht kommt in den R1.
    Problem ist wahrschein deine kommunikation in einer Loop laufen zu lassen.
    Lösung: CWRITE ausführen wenn Du ein Telegramm vom ext. Gerät bekommtst

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • So, ich war wieder ne ganze Zeit woanders eingebunden, aber dieses Problem muss auch noch gelöst werden.


    Die vorgeschlagene Änderung wäre sehr aufwändig umzusetzen, deswegen würd ich gerne vorher verstehen was sie bewirken soll um abschätzen zu können ob sich daslohnt.


    Wo liegt denn der Unterschied in der Abarbeitung wenn das nicht mehr von der SPS gesendet wird?


    Irgendwo hier im Forum steht, das Telnet nur die Kommunikation zum Treiber darstellt. Wenn also Telnet keine Kommunikation anzeigt, dann sollte doch schon beim seriellen Treiber nix mehr ankommen. Da sollte CWRITE dann doch schon nen Fehler zurückgeben, oder? Das hat dann ja mit dem physischen Senden noch nichts zu tun.

    If you and DEAD people can read Hex, how many people can read Hex?

  • Theoretisch sollte es keinen Unterschied machen ob die serielle Kommunikation im SINT oder RINT abläuft. Meine Erfahrung zeigt aber bei Benutzung des SINT und XONXOFF manchmal Probleme auftauchen. Ob das jetzt an der (wenigen) Rechenzeit des SINT liegt kann ich nicht sagen.
    Die serielle Anzeige im Telnet wirkt nur wenn TESTPRINT=1 in der serial.ini eingeschaltet ist. Da ist nur ein PRINTF im Telnet - das Telnet hat mit der seriellen Kommunikation nichts zu tun.
    Das CWRITE gibt (voraussetzung Format stimmt, Kanal offen) beim XONXOFF keinen Fehler zurück wenn keine serielle Verbindung besteht.
    Ist TESTPRINT=1 muss aber im Telnet beim Aufruf CWRITE oder CREAD die Debuginfos erscheinen - wenn nicht - wurde CREAD oder CWRITE NICHT aufgerufen.


    Kannst Du mir mal die Applikation genau erkären. Wann sendet wer was und warum ?
    a+

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Es geht um die Kommunikation zwischen dem Kuka-Roboter-Steuer-PC und einem zweiten PC, der dem Kuka sagt, was er tun soll. Also Anwahl von Programmen, übertragen von Koordinaten etc. In der gegenrichtung sagt der Kuka dem zweiten, wo er gerade ist, nen paar Messwerte von ner AD Karte und so. Diese Nachrichten vom Kuka kommen zyklisch, so oft die SPS das schafft (etwa 10 Hz). Manchmal fällt aber die Kommunikation aus, der Kuka hört auf zu senden. Dann erscheint auch im Telnet keine nachricht mehr, der CWRITE setzt aber keinen fehler. Das kann schon mal nen paar Stunden dauern, dann fängt der ohne erkennbaren Grund wieder an. Wenn jemand das merkt (es also nicht zB nachts passiert) reicht es den Not aus auszulösen und der sendet sofort wieder zyklisch.


    Schon mal Danke für die Tips!

    If you and DEAD people can read Hex, how many people can read Hex?

  • Bei solchen Kommunikationsproblemen lasse ich immer einen Softwaresniffer mitlaufen um rauszubekommen wer zu letzt gesendet hat und ob sich im Senderythmus was geändert hat. Also ob es stätig schlechter wird bis es abbricht. Das würde dann wahrscheindlich darauf deuten das irgendwo der Speicher vollläuft. Das würde zumindest zu so unregelmässigen Fehlern führen.

  • Kai,
    kann es vorkommen das da ein Sendekonflikt auftritt, d.h. KRC sendet und während dieser Zeit sendet auch der ext. PC ?
    Das XONXOFF-Protokoll ist normalerweise nur da um Daten zu senden (serieller Drucker, etc.). Eine Frage/Antwort (Ping/Pong) Applikation funktioniert auch.
    Bei unsynchronisiertem Telegrammverkehr (auch nicht von KUKA getestet) wird irgendwann wahrscheinlich ein Konflikt auftreten.
    ==> unsynchronisierten Telegrammverkehr vermeiden !


    Und nicht vergessen, wegen eines Bugs (Speicherfresser) muss bei vielen CWRITES der Modus #SYNC verwendet werden.
    a+

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

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