Ansatz gesucht: manuelle Kuka-Steuerung via LAN

rsi xml

das ist ne separate netzwerkkarte im robot und ne zusatzsoftware.

Na gegen die SPS spricht die Anforderung in Deinem ersten Satz:

Zitat von CrazyD

...
bei der untersucht werden soll, ob es möglich ist einen KUKA KR 30 über WLAN per PC zu (manuell) steuern. Die Software für den PC muss ich selbst schreiben.
...

Wenn die Steuerung per PC gemacht werden soll, warum dann noch eine SPS zwischenschalten
Ausser man verfährt nach dem Prinzip: Warum einfach, wenn's auch kompliziert geht.

begründung?

das ist die dafür vorgesehene echtzeit-schnittstelle beim kuka.

warum was neues erfinden, wenn es genau das was gesucht wird schon seit jahren gibt?

diese studienarbeit scheint schon ein paar jahre lang in der schublade gelegen zu haben, oder?

Hallo,

Zitat von CrazyD

Diese ist soweit einsatzbereit und wird momentan auch schon genutzt um den Roboter über ein Simantic Touchpanel MP 377 anzusteuern. Ich müsste das Ganze also "nur" softwaremäßig anpassen

das ist relativ unwahrscheinlich.

Du solltest dir erstmal klar werden, was für Bewegungen du eigentlich machen willst.

Soll der Roboter nur simple Bewegungen machen, wie z.B. "Fahre zu Position X und melde dich, wenn du da bist" ?

Oder soll der Roboter wirklich in Echtzeit (bei einem Kuka wäre das sein Interpolationstakt von 12 ms) auf eine externe Eingabe reagieren ?

Letzteres geht bei Kuka nur über RSI. Wenn du aber schreibst, mit der SPS funktioniert es schon, dann kann eine Echtzeitsteuerung nicht sein, was du willst, weil es damit nicht geht.

Werde dir also erstmal klar, was du eigentlich willst.

Grüße

Urmel

Zitat von CrazyD

...über WLAN per PC zu (manuell) steuern. Die Software für den PC muss ich selbst ...

SPS über Wlan?
Wohl kaum mit Siemens.
Und RSI XML wird evtl. auch nicht so gut über Wlan gehen, weil ja hier auch eine gewisse Paketlaufzeit nicht überschritten werden soll.

Oder um es mal aus sicherheitstechnischem Aspekt zu sagen:
Ein Produktiveinsatz über WLan mit den momentan erhältlichen, handelsüblichen Komponenten muss als Gefahrenquelle angesehen werden und ist aus sicherheitstechnischen Gründen strikt abzulehnen!

Eine Realzeitsteuerung ist praktisch nur über RSI XML möglich.
Nicht in Realzeit würde eine Positionsvorgabe über SPS (12 Worte Position plus Status und Turn plus Handshake) laufen. Der Robot gibt Signal "Bereit" liest vom Bus die neue Zielvorgabe, prüft Erreichbarkeit, quittiert Datensatz und fährt los. Nach Erreichen der Position gibt er wieder "Bereit"...
Das sieht aber genauso bescheuert aus, wie es klingt.
Das gibt ein Gezappel, wie wenn Kinderschänder-Jackson wiederauferstehen würde...

Noch möglich wäre Bahnplanung auf nem fest verkabelten Steuerungs-PC. Dieser steuert den Robot in "Echtzeit". Der Steuerrechner kann dann vielleicht über WLan mit einem Datensatz gefüttert werden, der die Bahn beschreibt. Das ist aber nie in "Echtzeit".

Zitat von WolfHenk

Oder um es mal aus sicherheitstechnischem Aspekt zu sagen:
Ein Produktiveinsatz über WLan mit den momentan erhältlichen, handelsüblichen Komponenten muss als Gefahrenquelle angesehen werden und ist aus sicherheitstechnischen Gründen strikt abzulehnen!

sag wer?
es ist doch egal, ob der Roboter seine Positionsdaten über W-Lan oder z.B. über irgendwelche Berechnungen im Programm bekommt. Sicherheitsrelevant ist doch, das der Roboter seinen Arbeitsbereich nicht verlassen kann. Das lässt sich z.B. mit SafeOperation => Zellbereich und Arbeitsbereiche, sowie Hardwareanschläge und Achsbereichsüberwachung realisierten, oder sehe ich das etwa falsch ???

Gruß Chili1886

Zitat von WolfHenk

Oder um es mal aus sicherheitstechnischem Aspekt zu sagen:
Ein Produktiveinsatz über WLan mit den momentan erhältlichen, handelsüblichen Komponenten muss als Gefahrenquelle angesehen werden und ist aus sicherheitstechnischen Gründen strikt abzulehnen!

Eine Roboterzelle muss sicher sein.
Das schließt Fehler des Roboters oder des Programmieres mit ein.
Also spricht nichts dagegen den Roboter über WLAN, oder von einer Südseeinsel aus zu steuern - wenn die Zelle sicher ist. (Was sie so und so sein muss.) Weil sicher heißt, es passiert nix, wenn der Roboter unerwartete Bewegungen macht.

Zitat von WolfHenk

Eine Realzeitsteuerung ist praktisch nur über RSI XML möglich.

Geht auch ohne RSI.
Bietet die Firma eines Bekannten an. Echtzeitbahnplanung eines KUKA ohne RSI.
Wies genau geht hab ich nicht aus ihm rausbekommen, jedenfalls spielen Interrupts eine Rolle.

Zitat von Chili1886

sag wer?

Sag ich.

Und warum?
Weil beim WLan einfach auch mal ne Sekunde oder zwo keine Daten rüberkommen.
Das ist alles 2,4 GHz. Und nur 11 Kanäle. Und jeder stellt sein sch... WLan auf größte Geschwindigkeit ein und brennt so über 6 oder 7 Kanäle weg...
Kollissionen im Datenverkehr sind alltag. Und deswegen sag ich, dass das mit den handelsüblichen Geräten nicht gehen wird weil einfach zuviel Müll auf dem Band ist.

Beim Surfen oder Mails holen spielt das keine Rolle. Selbst beim Filme gucken nicht, denn es wird ja schneller übertragen, als Du gucken kannst.
Aber wenn Du über WLan (2,4GHz) Echtzeitsachen machen willst, dann wirst Du scheitern. Spätestens wenn der zweite und dritte Smartfon-User da vorbeitapert...

es geht ja nicht um die Praxistauglichkiet sondern um die Sicherheit, und dafür spielt es keine Rolle, oder?

@Sicherheit: Es gibt NOT-HALT Anwendungen (Failsafe usw...) via WLAN.

Aber es geht hier nicht um Sicherheit des WLAN, da die Sicherheit durch die sichere Zelle gewährleistet wird. In einer sicheren Zelle kannst Du den Roboter auch mit einer Fernseher-Fernbedienung mit fast leerer Batterie steuern.
Praxistauglichkeit ist eine andere Frage.

Nun, all das war in meinem Satz ausdrücklich erwähnt.

Ja, zum mal probiern wirds vielleicht gehn. Es wird alle Augenblicke ausfallen Und es wird sicher nicht zuverlässig sein, aber es könnte gehen.
Aber denk weiter:
Da ist 'n Student. Einer, der dran forschen soll.
Warum ihn sinnlos in die falsche Richtung jagen, von der man klar weiß, dass das Zeug mit den normalen Mitteln abkackt?
Vielleicht (für ’n paar Monate) mit 5GHz-Komponenten. Da ist net soviel los.
Aber auch da wird die Nutzung mehr und die Frequenzen werden voll.
Und wenn Du höhere Frequenzen nutzt, wird das Funkverhalten für bewegliche Bedienteile unsauber. Da kommen dann schon auf kurzen Strecken Reflexionen und Auslöschungen zustande, die auch das Signal empfindlich beeinflussen.
Gehst Du in den Frequenzen runter, hast Du allerhand schon vorhandene Störquellen. So z.B. im UHF-Bereich das LTE-Internet oder ab 900 MHz die Telefone...

Ja, es gibt Notaus über Funk. Es soll auch ProfiNet über Funk geben, aber einen Roboter damit sicher steuern?
Er will, wenn ich ihn richtig verstehe ja die Bahnplanung außerhalb tun. Da muß er ne Menge Daten schaufeln. Und da wirds heikel...

Ich bleib dabei, vom WLan rate ich ab. Ich halte es nicht für tauglich für die Anwendung.

Wolfram

Zitat von WolfHenk

Ja, es gibt Notaus über Funk. Es soll auch ProfiNet über Funk geben, aber einen Roboter damit sicher steuern?

Ja für Not-Aus usw. gibt es sicheres WLAN.

Ob Verzögerungen in der Datenübertragung eine Auswirkung auf die Sicherheit der Roboterbewegung haben, hängt davon ab, wie das implementiert ist. Wenn der Roboter weiterfährt, weil keine Daten übers Netzwerk kommen, hat man da in der Tat ein Problem.

In der Regel wird das aber anders gelöst. Hier ein paar Beispiele:

Zitat von Stäubli

Die Änderung muss sehr sorgfältig berechnet werden, damit die sich daraus ergebenden Befehle zu
Position und Geschwindigkeit des Arms ununterbrochen und geräuschlos ausgeführt werden. Manchmal
muss zuvor [...] gefiltert werden, um gewünschte Qualität auf der Bahn und Verhalten des
Arms zu erreichen.

Zitat von Mitsubishi

When the controller receives the command value from the personal computer, it will output the received command value to the servo within the next control process cycle.
[...]
If the data is not received, the current position is maintained.
[...]
If a filter is applied on the reception position data, an obtuse command value is created and output to the servo.

Alles anzeigen

Man kann Unregelmäßigkeiten bei eintreffenden Steuerbefehlen durch digitale Filter ausbügeln. Die Echtzeitbefehle werden quasi verschleift, wie normale Roboterbewegungen. Das hat Auswirkungen auf die erreichbare Geschwindigkeit und Beschleunigung, aber nicht auf die Sicherheit.

Zitat von WolfHenk

....
Ja, es gibt Notaus über Funk. Es soll auch ProfiNet über Funk geben, aber einen Roboter damit sicher steuern?
...

Immerhin traut sich Comau das zu (und zwar serienmäßig):
http://www.comau.com/ger/offer…trol_unit/Pages/witp.aspx

Wir haben im August 2011 einen neuen Comau in einer Schleif-und Polierzelle verbaut. Da gab es das Kabellose Bedienpanel schon, aber wir konnten es noch nicht bekommen (in Deutschlan). Bisher habe ich nur erfahren, daß es in Italien eingesezt wurde. Ist aber auch schon fast wieder 1 Jahr her. Wenn Comau das vorstellt, gehe ich davon aus, daß Sie sich das nicht nur zutrauen, sondern das es auch Fehlerfrei funktioniert.
Und mit der Frequenz da hat der Wolf recht. Comau 5Ghz (nicht ohne Grund).

hallo,

die comau-lösung scheint wirklich klasse. aber wenn ich den sinn des thread richtig verstehe, geht es NICHT darum, das bedien-/programmierpanel drahtlos zu machen, sondern den roboter LIVE über wlan fahren zu lassen und dass die verfahrbefehle auch über funk kommen sollen, und zwar nicht nur beim programmieren/teachen, sondern IMMER, wenn der roboter sich bewegen soll.
dass roboter auch ohne angestecktes panel laufen sieht man ja zb bei mitsubishi, bei dem kannst du im laufenden betrieb einfach das panel abmelden und abziehen, der roboter läuft trotzdem weiter. aber soweit ich das sehe, ist das hier nicht das zu lösende problem.

Zitat von SpeedFreak

sondern den roboter LIVE über wlan fahren zu lassen und dass die verfahrbefehle auch über funk kommen sollen, und zwar nicht nur beim programmieren/teachen, sondern IMMER, wenn der roboter sich bewegen soll.

Ja, so habe ich das auch verstanden, siehe meine vorherigen Antworten.

Ich bitte daher darum, dass wir bei Thema bleiben und den Fragesteller nicht weiter verwirren. Wenn ihr über drahtlose Pads diskutieren wollt, könnt ihr das auch da tun
http://www.roboterforum.de/rob…ein/reispad-t10284.0.html
auf der Automatica gibt es gerade neues zum Thema.

Ist zwar jetzt mal keine Antwort, aber das Thema passt gerade so gut:

Wenn ich den KUKA via RSI steuern will, möchte der ja wohl mindestens alle 12ms ein neues Telegramm haben.

Wenn ich nun standardmässig als PC Plattform von Windows (XP, Vista, 7 etc.) ausgehe, kann das doch so eigentlich doch gar nicht funktionieren? Will meinen das Windows ja nicht echtzeitfähig ist und garantiert so ein Festplattenzugriff oder was auch immer meine Telegrammausgabe verzögert?

Hat mal jemand sowas ohne Echtzeiterweiterung auf einem Standard WinPC programmiert, und wenn, geht das mit den 12ms wirklich so ohne weiteres?