Beiträge von kai_n

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!

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.

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?

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.

Das steht leider schon auf #sync.
Hier der interessante Teil der SPS.sub:

DECL STATE_T STATE
DECL MODUS_T MODUS
MODUS= #SYNC 
COPEN(:ser_3,serialHandle)
DECL INT all[18]
.
.
.
  LOOP
.
.
.
cwrite(serialHandle , STATE , MODUS , "%2.18r" , all[]);send out

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

[COM3]


BAUD=38400 ;9600 default
CHAR_LEN=8   ; 7,8
STOP_BIT=1   ; 1,2  at time not changeable
PARITY=2     ; EVEN=2, ODD=1, NONE=0


PROC=4 ;1 default       ; 3964R=1, SRVT=2, WTC=3, XONXOFF=4
.
.
.
[XONXOFF]
CHAR_TIMEOUT=50      ; msec   Timeout after last received character
                     ;        to recognize the end of telegram
MAX_TX_BUFFER=5      ; 1..5
MAX_RX_BUFFER=10      ; 1..20
SIZE_RX_BUFFER=1024   ; 1..2048 longest expected telegram length + 15 characters


XON_VAL=0           ; 0..255  XON  character (decimal)
XOFF_VAL=0          ; 0..255  XOFF character (decimal)
                     ; if XON_VAL=0 and XOFF_VAL=0 then XON/XOFF protocol
                     ; is disabled (pure serial communication)
DSR_LINE=0          ; 0 = DSR line not connected, 1 = DSR line must be high


[TEST]
;testprint (Rx/Tx-telegrams) on telnet if value > 0
TESTPRINT=1 ;0 default

Danke schon mal!

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

Hui,

das ist echt lang her, ich hab das auch seitdem nicht mehr benutzt. Ich weiß auch nicht mehr, ob ich damals noch was geändert hatte, ist einfach zu lang her. Ich fand aber das Listing Paket extrem praktisch, weil sich über markierungen in den Kommentaren des Sourcecode auch Zeilennummern flexibel referenzieren lassen.

Kai

Hallo,

ich sollte das ein wenig genauer beschreiben. Also: Das Programm selbst existiert schon und ist recht komplex, ich will es also nicht umschreiben um alle Variablen in ein Array zu verlegen (sonst ist die Idee aber eigentlich recht elegant).
Es geht um die global ansprechbaren Variablen aus der $config.dat.

ich weiß leider ich nicht, wie das da mit Programmnummern funktionier, währe da für ne Erklärung dankbar, Wasdel.

Für dingis Idee bräuchte ich ja so ne Art INCLUDE Anweisung, die ich in der $config.dat aufrufen kann.
Aber stimmt, ich könnte die Variablen natürlich in der $config.dat deklarieren und bei Programmstart über eines von zwei src files, das ich über IF auswähle, die entsprechenden Werte setzen.

Aber das muss doch direkter gehen?!?

Hallo,

ich habe ein seltsames Problem mit der SPS/dem ganzen Roboter. Manchmal - nicht reproduzierbar und ohne ersichtlichen Grund - stoppt das System die Arbeit und lässt sich nur durch nen Betriebsartswechsel oder ein Not-Aus mit quittierung wieder "aufwecken".
Hat jemand so etwas schon beobachtet?
Woran könnte das liegen?

Kai

Hallo!

Ich war lange nicht mehr hier, habe aber endlich wieder ein Roboterprojekt und prompt eine Frage:

Ich habe zwei Robotersysteme, die ziemlich identisch sind (eines in den USA und eines hier in Deutschland). Der Unterschied besteht in einigen Parametern, die in der $config.dat gespeichert sind. Jetzt suche ich nach einer Methode die Sourcen bequem auszutauschen, ohne die Parameter in der config.dat, die sich unterscheiden, zu überschreiben. Wenn die $config.dat ein normales Programm wäre würde ich mit
IF USA THEN
....
Else
...
ENDIF
arbeiten. Das geht ja nun nicht....

Hat da jemand ne Idee???

Dankeschön!

Wir haben LabView auf einem zweiten PC installiert, da Windows auf den Kuka Rechnern nur einen Bruchteil der Rechenleistung zur Verfügung gestellt bekommt. LabView kann in KRL programmierte Routinen gezielt aufrufen, inklusive fahrten zu berechneten Punkten (an dieser Stelle sehr auf die Sicherheit achten).
Wir haben dafür die RS232 Schnittstelle genutzt, da OPC von Kuka damals noch nicht ausgereift war.
Probiers doch mal aus und lass uns wissen wie das so tut:
http://www.kuka.com/NR/rdonlyr…A7D/0/OPC_Server_Germ.pdf

Konnte man die nicht als avi-Filmchen exportieren?
Das wäre das Einfachste....

WOW!
Das wusste ich nicht. Sprich: Wenn man dem System über den Pfad und Programmnamen mitteilt, welche Varable man meint, dann bekommt man die auch angezeigt.
Danke, der Trick dürfte mir das Leben durchaus erleichtern!

Der kann Dir halt nur globale Variablen anzeigen, bei lokalen kann der Name der Variablen nämlich in mehreren SRCs identisch und damit nicht mehr eindeutig sein. Alles was Du sehen willst muss entweder in die $config.dat oder als GLOBAL deklariert sein. Ich hab mir für den Fall nen paar debug_int debug_str etc angelegt, die ich zum Fehlersuchen flux befülle. Auf die Art hast Du nicht so viele überflüssige globale Variablen.

Die Variable $VEL_CP (oder die heißt ganz ähnlich...) bestimmt die maximale Geschwindigkeit des Robs. Damit kannst Du alles verlangsamen, was nicht eh schon langsamer ist.
Ansonsten bleibt nur die Rob-Geschwindigkeit in % runter zu schrauben. Wenn Du auf Nummer Sicher gehen willst, kannst Du im Falle des Automatikmodus auch in der SPS die Verarbeitungsgeschwindigkeit setzen. Dann kann die kein User raufsetzen.
Dann fällt mir noch ein, ein kleines Tool zu schreiben, das alle Punkte in DAT und SRC insgesamt verlangsamt. Vielleicht gibt es da ja auch was von KUKA?

Es gibt da so nen Kuka-OPC-server. Ohne den wirst Du OPC nicht verwenden können. Weiß leider nicht was der kostet. Der ist, wenn ich das richtig verstanden habe, auch eher für das Visualisieren als fürs übertragen von - eventuell zeitkritischen - Messwerten und steuersignalen gedacht.

Klar kannst Du mit LabView den Roboter steuern. Da gibt es ne ganze Handvoll möglichkeiten, die für verschiedene Anforderungen verschieden gut geeignet sind:
- Digitale Ports
- OPC
- device net
- serieller Port
Was musst Du denn übertragen? willst Du fete Programme aufrufen, oder musst Du koordinaten übertragen? Du kannst auch die Steuerung in KRL schreiben und die von LabView aufbereiteten Sensorsignale als Sensor-Eingang in KRL ansehen.

Ist Dir englisch lieber? Andere Sprachen hab ich leider nicht drauf...

That goes on no cowskin => Das geht auf keine Kuhhaut
Always slow with the young horses => immer langsam mit den jungen Pferden

Aber das hier gibts anscheinend wirklich:
I slept like a stone.

So geschehen.
Danke für die Anleitung, die hilft bestimmt noch so manchem!

Jeder, der mit LabView am seriallen Port was machen will sollte sich mal diese Library ansehen:
http://www.mhst.de/downloads.html
Die heisst lvserial und ist weitaus besser - also verlässlicher und angenehmer zu benutzen - als die eingebauten LabView Befehle.