Posts by Grubba

Hallo SJX,

der Roboter ist zwar von 2014, hat aber nur bei uns seinen Dienst versehen, nur an dieser Anlage und es hat auch niemand diese Werte zusätzlich eingetragen. (Außer mir stellen die Bediener maximal die Betriebsart um).

Angeschlossen ist das Netzwerkkabel an der KLI Buchse.

Ich bin mit KUKA durch die KRL Konfigurationsdatei durchgegangen, da war am Anfang tatsächlich ein Zahlendreher drin.

Stand jetzt sagt mir KUKA sinngemäß: Wenn sie keine Verbindung per Beispielprogramm herstellen können, muss es wohl eine fehlerhafte Schnittstellenkonfiguration sein.

Nicht, dass die damit nicht Recht haben können, hilft mir aber erst einmal nicht weiter

Unsere IT hat mir noch ein paar Kommandozeilenbefehle gegeben, mit denen ich mal die freien Ports checken kann. Vielleicht liegt der Fehler ja doch auf der PC Seite. Dummerweise sind meine Netzwerkkenntnisse doch eher rudimentärer Art.

Hallo SJX,

stimmt, der Roboter soll Client sein. Die Verbindung soll aus einem Roboterprogramm heraus geöffnet werden.

Die Wartezeit habe ist nur zu Testzwecken drin.

EKI_Init läuft fehlerfrei durch.

Bei EKI_Open kommt dann der Fehler, dann aber auch wirklich erst nach der TimeOut-Zeit.

Der Rückgabewert ist EKI00014, also "Verbindung zu externem System konnte nicht heregestellt werden...."

RET=EKI_Init("XmlServer")
wait sec 3
RET=EKI_Open("XmlServer")

; wait until server is conntected
wait for $FLAG[1]
; wait until server is deconnected
wait for $FLAG[1]==FALSE

RET=EKI_Clear("XmlServer")

Habe gerade sicherheitshalber noch einmal nachgesehen, es steht "TCP" drin.

Habe auch schon die anderen Ports ausprobiert, mit bekanntem Ergebnis

(Ich schaff's nicht mit KUKA )

Wie angedroht, hier die Bilder von den Netzwerkeinstellungen:

Bis auf den hinzugefügten Port 59152 habe ich keine Änderungen vorgenommen.

Über WorkVisual lässt sich der Roboter übrigens auch problemlos erreichen.

Mache ich dann am Montag, bin schon im Wochenende.

Zur Info:

Bin nach Anleitung vorgegangen, was ich sagen kann, sind dort aber zumindest keine tiefergehenden Einstellungen erwähnt oder beschrieben.

Im Prinzip habe ich eine Konfiguration aus der KUKA Demo genommen und auf meine IP abgeändert. Den Port 59152 habe ich ebenfalls aus der Demo, habe aber auch alle möglichen anderen versucht.

Ansonsten habe ich keine Änderungen vorgenommen, außer den Vorschlag vom Programmiersklaven umzusetzen, und den Port 59152 in die NAT zu übernehmen.

Auch die KUKA Hotline hat mir bis jetzt noch keine anderen Stellschrauben genannt.

Was ich sagen kann ist, dass zumindest die physikalische Verbindung steht, weil sich beide Teilnehmer gegenseitig anpingen können.

Das Testprogramm scheint auch irgendetwas zu machen, weil:

- Bei Aufruf der Funktion, die die Verbindung herstellt, an der Ethernet Dose zumindest einmal kurz die Aktivitäts-Led am PC aufleuchtet.

- Eine Verbindung über den Port 139 vom KUKA-Programm aus wertet der Roboter hingegen immer als erfolgreich zurück. Dazu braucht es dann aber auf der PC-Seite aber keinerlei zutun, weil der wohl vom Betriebssystem automatisch beantwortet wird (Hab da was von Netbios gelesen) Meine kleine Testanwendung (und auch der Demo Server von KUKA melden dann aber auch keinen Verbindungsaufbau)

Wenn ich das Netzwerkkabel abziehe, geht dann auch der Port 139 nicht mehr. Ist also wirklich an die physikalische Verbindung gebunden.

Mein PC blockiert auch den Port 59152 nicht, das habe ich schon getestet.

Danke schon einmal für die Vorschläge, Montag lade ich mal ein paar Screenshots hoch.

Ein schönes WE schon einmal an alle Foristen....

Habe ich gerade einmal nachgetragen, neu gestartet. Geht aber trotzdem nicht...

Aber trotzdem danke , hatte gerade immerhin für 5 Minuten Hoffnung

Wertes Forum,

ich möchte von einem PC zu einer KRC4 (8.3) Daten übertragen. Dazu verwende ich das Softwarepaket KRL (Ver 2.2)

Problem ist:

Ich bekomme keine Verbindung (Weder vom KUKA zum PC noch umgekehrt) aufgebaut.

- Ich kann Roboter und PC gegenseitig anpingen. (KUKA IP 172.31.1.147 - KUKA Standard)

- Roboter und PC sind direkt per Kabel verbunden

Nachdem ich es zuerst vom KRC Programm aus erfolglos versucht habe, habe ich es dann direkt von der KUKA Windows Oberfläche aus versucht, mit ebenso wenig Erfolg.

Zum Verbindungstest verwende ich ein kleines Tool, welches sowohl als TCP Server oder als TCP Client fungieren kann. Auch mit der KUKA Demo-Software funktioniert es nicht.

(Tool funktioniert, ich kann z.B. eine Verbindung vom Office Lite (wenn auch KRC2) aufbauen, bzw. von Office Lite aufbauen lassen.)

Die XML-Datei, in der sich die Verbindungsdaten befinden, sollte korrekt sein (Mein PC hat 172.31.1.111):

Quote

<ETHERNETKRL>

<CONFIGURATION>

<EXTERNAL>

<IP>172.31.1.111</IP>

<PORT>59152</PORT>

</EXTERNAL>

<INTERNAL>

<ALIVE Set_Flag="1"/>

<TIMEOUT Connect="10000"/>

</INTERNAL>

</CONFIGURATION>

<RECEIVE>

<XML>

<ELEMENT Tag="Sensor/A" Type="BOOL"/>

</XML>

</RECEIVE>

<SEND>

<XML>

<ELEMENT Tag="Robot/B"/>

</XML>

</SEND>

</ETHERNETKRL>

Display More

Gibt es irgendetwas, was ich da übersehen habe?

Der Datenverkehr als solches ist erst einmal egal, ich wäre schon froh, das überhaupt mal eine Verbindung aufgebaut wird.

Auch wenn ich noch immer nicht weiß, wo $drive_load herkommt :

Wenns wirklich so ist, dass beim Zugriff erst Achsdaten ausgelesen werden müssen, geht die Zeit dann doch beim internen Zugriff auf die Achsregler etc. verloren und nicht beim Umkopiervorgang auf Steuerungsebene.

Vielleicht mal versuchen, alles auf einmal mit SWRITE umzukopieren ?

Was sagt denn KUKA dazu?

Was ist denn "$drive_load" ?

Habe mal die Doku durchsucht, in Work visual gesucht, aber nirgendwo was gefunden.

Wenn es aber wirklich eine Systemvariable ist, könnte es aber sein, dass die bei jedem Zugriff aktualisiert wird um immer die aktuellen Daten zur Verfügung zu stellen. Vielleicht geht dann intern bei der Abfrage der Ist-Motordaten die Zeit verloren.

Was ist denn das für ein Array, bei dem ein Zugriff auf 10 Felder die KRC langsamer macht??

Dafür musst du dann wohl erst einmal deine Buskonfiguration überprüfen. Bei einer Profibus Konfiguration ist beispielsweise ein Watchdog von 30ms eingestellt. Somit sollten zumindest über den Bus alle 30ms Daten über den Bus eintrudeln. Das hat aber weniger mit der KRC4 zu tun als mit der Buskonfiguration. Die ist genormt.

Und so wie ich es verstanden habe, sollten nach dem Empfang der Daten diese auch zur Verabeitung bereit stehen.

Ansonsten:

Ein Produkt mit unterschiedlichen Geschwindigkeiten suchen lassen und die Ergebnisse vergleichen. Daraus kannst du dann auch Rückschlüsse über die Geschwindigkeit der Verabeitungskette ziehen.

Eine Struktur, die du anderswo verwendest als dort, wo du sie deklariert hast, muss auch mit GLOBAL STRUC... definiert werden.

Quote

Wenn du ihn selber programmiert hast, dann verstehe ich nicht ganz was es da für rechtliche Probleme geben kann.

- Arbeitgeber
- SDK evtl. nur Lite-Version, d.h. nicht für kommerzielle Zwecke nutzbar
- keine Freigabe von KUKA, damit nicht jeder "Nerd" Software für die KRC4 verbreitet, die evtl. ins System eingreift und zu Crashes führt, für die KUKA verständlicherweise nicht geradestehen will

und und und....

Alles klar. Ich hatte schon alle Optionen durchgesehen und war mir schon fast sicher, da irgendwas übersehen zu haben.

Danke für die prompte Antwort

Mal eine (hoffentlich) nicht ganz doofe Frage:

wie kann ich ein komplettes KRC4 Projekt laden?

Die Projektsicherungsdateien haben ja die Änderung .wvs

Wie öffne ich ein Projekt? Oder wie öffne ich ein einzelnes Modul ohne voriges exportieren unter WoV?

Entweder in WorkVisual direkt in der Achskonfiguration einstellen oder (eh ich es jetzt selber die Verzeichnisse suche....)
in WorkVisual nach "RampUpTimeUnderLoad" suchen lassen. Dann listet er die alle Stellen in den Dateien auf, wo die Variable vorkommt.

Aha.

Wenn du jetzt den Override auf 100% setzt, und die Geschwindigkeit im Spline vorgibst (ohne OVR-Änderung), beschleunigt er dann schnell genug?

Wenn du die Beschleunigung errechnen kannst, kannst du vielleicht auch ermitteln, ob der KUKA das überhaupt kann?

Wenn du doch aber die Geschwindigkeit so vorgeben kannst wie oben beschrieben, brauchst du den Override doch nicht mehr ändern?

Ich habs nicht ausprobiert, ob die Geschwindigkeitsangabe per Variable übergeben werden darf:
Dann könnte es so gehen:

spl Punkt A with $Vel = Vel[1]
spl Punkt B with $Vel = Vel[2]
spl Punkt C with $Vel = Vel[3]

Die Geschwindigkeiten könnte man dann vorher berechnen.

D.h., du willst, dass der Bediener ein Programm manuell teacht (mit Spline Block) und die KRC4 dann selbstständig die Geschwindigkeit nachregelt?