Alles anzeigenHallo, ich bin frisch von der Uni und sehr neu in der Fanuc und Siemens SPS Programmierung. Gibt es Handbücher o.ä. die mir Schritt für Schritt erklären wie ich eine erfolgreiche Kommunikation zwischen SPS und Fanuc Roboter via Profinet herstellen kann?
Ziel ist es z.B. Werte vom HMI an den Roboter zu senden um diese dann in einem PR zu nutzen.
Vielen lieben Dank im Voraus!
LG
Zum Einstieg könnte folgendes Dokument helfen:
Moien,
Falls es noch Klärungsbedarf gibt, dann hilft vielleicht folgende Anleitung weiter, ansonsten hilft der Fanuc Helpdesk auch gerne gratis weiter.
Siemens PLC Fanuc Roboter ProfiNet Kommunikation
Grüße, Claude.
Danke für die Infos. Im Moment habe ich noch keine Ahnung von der KRC2. Das Angebot lautet zur Zeit „Transportkosten“, das scheint mir sehr nahe an unschlagbar, von daher wollte ich nicht allzuviel überlegen, vor allem wenn man die Robotik nur als Hobby betreibt.
Andererseits habe ich ein „running system“ aber halt etwas betagt. Deshalb scheint mir der Upgrade interessant.
Merci. Was wären denn die richtigen KSD's? Im Anhang weitere Fotos von der angebotenen VKRC2 welche an einem KR180-2 betrieben wurde.
Hallo,
Ich habe einen VKR200/2, den ich bisher an einer VKRC1 betrieben habe. Letztere wurde auf KRC1 Software (v4.1.7 SP08 HF1) umgestellt. Nun hat man mir günstig eine VKRC2 angeboten, aber ich bin mir nicht sicher, ob ich meinen VKR200 an der VKRC2 betreiben kann. Was mich stutzig macht, ist dass am Motorkabel der VKRC2 bei drei Achsen nur 3 Pins sind statt 5 wie an meinem Robi. Siehe Anhang. Es sieht also so aus, als wenn an 3 Achsen die Bremsen nicht auf den Stecker geführt wären. Kann das trotzdem mit Adpaterkabel klappen, oder lass ich das besser?
Grüße, Claude.
Hier das passend Video zum Thema:
Ich habe eine 20 Jahre alte VKRC1. Kein Ahnung wie lange die rumstand bevor ich sie vom Schrott geholt habe, aber die Kondensatoren des ZK haben keine Probleme gemacht. Ich nehme an die Hochspannungselkos sind da schon etwas robuster.
Der Kapazitätsverlust ist allerdings messbar. Statt 330uF habe ich teils nur noch 270uF. Geht trotzdem. Zur Not könnte ich ein weiteres Paar Kondensatoren hinzulöten um den Kapazitätsverlust zu kompensieren. In der PM6-600 sind auf der Elko-Platine interessanterweise schon Plätze dafür vorgesehen.
Ich habe auch jahrelang an Röhrenverstärkern gebastelt, auch dort ist mir nie ein Hochspannungselko um die Ohren geflogen.
Wie bereits erwähnt, werden eher die Akkus Probleme machen und die Knopfzelle auf dem Motherboard (wenns dies bei der KRC2 noch gibt). Zuletzt haben bei mir 3 Stromwandler auf einen Schlag den Geist aufgegeben. Sehr zeitintensiv, das herauszufinden.
Merci Woodworker. Ich hatte beim Zusammenbau der PM6-600 genau diesen Stecker vergessen anzuschließen und kann bestätigen, dass dies zu einer zufälligen Zahl an Überstromfehler führt.
Schlussendlich habe ich mir eine PM6-600 mit Artikelnummer 00-103-494 geholt und siehe da es klappte auf Anhieb. Also Finger weg von der 71-039-278 zumindest mit „neueren“ Softwarenständen.
Merci. Ich habe keinen Jumper auf dieser PM6-600, also gehe ich mal davon aus, dass die immer im Programmiermodus ist. Ich bin wie folgt vorgegangen:
Resultat: Immer noch Fehlermeldung "Maximales Getriebemoment Achse A6"
Danke für die Bestätigung, dass es keine Rückmeldung gibt wenn man die $PROG_EEPOT programmiert, mit oder ohne Schreibschutz.
Zur Illustration hier zwei Fotos wie die PM6-600 mit und ohne Schreibschutzjumper aussieht.
Was aber bisher gänzlich unerwähnt blieb ist, dass es wohl Varianten der PM6-600 gibt, die untereinander nicht kompatibel sind. Die Artikelnummer der PM6-600 scheint beim Austausch also eine Rolle zu spielen! Siehe auch Thread „KRC1 Fehler maximales Getriebemoment auf alle Achsen beim Handverfahren nach Austausch PM6-600„.
Laut Verkäufer läge es daran, dass die Artikelnummern meiner defekten PM6-600 und der gebraucht gekauften sich unterscheiden würden. In der Tat haben meine defekte PM6-600 und die funktionierende PM6-600 aus dem baugleichen Roboter die Artikelnummer 00100323, dagegen hat die gebraucht gekaufte PM6-600 die Artikelnummer 71039278.
Ein gewisse Logik hat es, nur höre ich das erste Mal, dass es unterschiedliche Varianten der PM6-600 gibt die nicht kompatibel untereinander sind.
Was sagt Ihr dazu?
Vielen Dank SJX für die detailierte Antwort. Die Motoren habe ich alle mit dem Ohmmeter durchgemessen, nix auffälliges. Zudem läuft es ja mit der PM6-600 vom Parallelroboter.
Vom DSE-RDW Tool habe ich erst kürzlich das erste Mal gehört. Den Menüpunkt habe ich schon mal gefunden.
Dokumentation finde ich leider keine, weder hier im Forum noch bei my.kuka. Im Kapitel Inbetriebnahme zur KRC1 steht: "Hinweise ... finden Sie im Handbuch Service Elektrik im Hauptkapitel [Diagnose], Kapitel [DSE-RDW]."
Aus dem Handbuch "Service Elektrik" habe ich aber nur einen Auszug und natürlich fehlt der Teil über das DSE-RDW-Tool. 
Ich habe mal in Punkt 7 (RDW Kommunikation) und 8 (PowerModul Register) reingeschaut nachdem ich den maximalen Getriebemomentfehler provoziert habe. Beim Interpretieren tue ich mich aber ohne Dokumentation schwer.
Moin.
Ich habe eine VKRC1 mit KRC1 Software (v4.1.7 SP08 HF1) und VKR200/2 Roboter.
Die KRC1 fing letztens an zu mucken, um sich kurze Zeit später mit einem ordentlichen Kurzschluss zu verabschieden. Ich hab versucht die PM6-600 zu reparieren aber sobald ich z.B. die Achse A6 verfahren wollte, hörte man wie sich die Bremsen lösten, dann sackte die Achse A3 ein paar Grad ab (der Roboter steht in der Kalibrierposition) und dann stiegt die KRC1 mit dem Fehler Maximales Getriebemoment Achse A3 aus.
Mit der PM6-600 von einem anderen baugleichen Roboter läuft alles einwandfrei, also habe ich eine gebrauchte PM6-600 von einem Industrieschrotthändler geholt um die defekte zu ersetzen. Seltsamerweise verhält sich der Roboter mit der gebrauchten PM6-600 ebenfalls wie oben beschrieben, also Bremsen lösen sich, Achse A3 sackt ab und es erscheint der Fehler "Maximales Getriebemoment Achse A3".
Wenn ich den Roboter stütze, kommt der Fehler auf einer anderen Achse. Man hat den Eindruck, dass keiner der Motoren Saft kriegt.
Folgendes habe ich bereits kontrolliert/versucht:
Klar kann ich die gebrauchte PM6-600 zurückschicken und mir eine andere organisiern, aber da ich das gleiche Verhalten an der pseudo-reparierten PM6-600 habe, hätte ich schon ganz gerne verstanden woher dieser Fehler kommen kann. Wieso gibt die PM6-600 die Bremsen frei, um dann doch keinen Saft auf die Motoren zu geben?
Richtig, nur liegen dennoch an dieser PM6-600 keine Jumper direkt hinter diesem Ausschnitt, daher die vielen Fragezeichen meinerseits.
Das war immer ein Steckjumper über 2 Pins ...
Ja so hatte ich mir das auch vorgestellt. Ich habe zwei PM6-600 und keines von beiden hat Jumper, nur 3 Federkontakte. Die sind aber alle nur schwer erreichbar, ohne dass man die Abdeckung abnimmt. Ich nehme mal an die Steckjumpern waren über einen Ausschnitt im Blech gut erreichbar, oder?
Ich schlussfolgere also, dass man besser die Finger von den Federkontakten läßt.
Bleibt die Frage, wie man vorgeht, wenn man keine Jumper hat. Ist man dann immer im Programmiermodus bzw. ohne Schreibschutz?
Hallo Allerseits,
Prinzipiell habe ich mein PM6-600 durch ein Gebrauchtes ersetzt, nachdem mir zweimal ohne offensichtlichen Grund das IGBT-Modul der Achse A6 abgeraucht ist. Trotzdem kriege ich jetzt auf jeder Achse den Fehler "Maximales Getriebemoment Achse Ax" sobald ich die Achse fahren will. Man hört die Bremsen aufschalten, die Motoren scheinen angesteuert zu werden und dann kommt gleich der Fehler.
Grüße, Claude.
Bremsen lösen über Stecker X30, jedes Steckermodul ist für eine Achse, von Oben nach Unten gezählt. Dabei ist immer Pin 3 der Plusanschluss der Bremse und Pin 5 der Minusanschluss der Bremse. Die von Spacefire beschriebene Brücken für alle Bremsen befinden sich im Anschlusskabel(X30) welches aber abgesteckt werden muss um an die Kontakte im Stecker X30 zu gelangen. Bei den Leistunganschlüssen an den Motoren ist immer Pin 4 der Plusanschluss der Bremse und Pin 5 der Minusanschluss der Bremse.
Danke Rauschi. Genau die Info habe ich jetzt gebraucht. Die Achsen ließen sich alle mit etwas Kraftaufwand drehen, nachdem sich die jeweilige Bremse höhrbar gelöst hatte. Die Polarität spielt wohl keine Rolle. Es scheint eine Schaltspule angesteuert zu werden. An meinem KR200/2 waren die Spulenwiderstände 28 Ohm (A1-A3) und 44 Ohm (A4-A6). Idealerweise dreht ihr vor dem Lösen der Verbindung die Spannung von 24V zu 0V runter, sonst zieht ihr einen Funken. Die Freilaufdiode sitzt wohl in der KRC und nicht am Roboter. Andernfalls würde die Polarität auch eine Rolle spielen.
Aber keine Sorge wenn ihr kein einstellbares Netzteil habt, das eine oder andere Mal ohne Freilauf sollte sie Spule abkönnen.
...This function does the same for earlier versions:
The thread has moved here:
Zeichenketten aus Datenliste in andere Zeichenkette schreiben
Hallo allerseits.
Ich glaube eine einfache, saubere und definitive Lösung zum Problem gefunden zu haben. Zumindest funktioniert sie an meiner KRC1 (v4.1.7 SP08) tadellos. Die Lösung mit dem COUNTER hat bei mir nämlich gar nichts gebracht. Das Programm ist damit einfach nur endlos in der Zählerschleife gelaufen, da $MSG_T.VALID auch nach x Aufrufen der Meldung nie FALSE wurde.
Was aber bei mir geholfen hat, ist einfach ein WAIT SEC 0.2 hinter dem Setzen des Meldungstyps. Also z.B.:
$MSG_T.TYP=#STATE
WAIT SEC 0.2Zusätzlich solltet ihr bei Statusmeldungen ein WAIT SEC 0.5 hinter $MSG_T.RELEASE=TRUE setzen, denn meiner Analyse nach bleibt das Programm immer dann in der WHILE-Schleife hängen, wenn der Release einer Statusmeldung nicht geklappt hat oder einfach im Programm fehlt. Dies erkennt man daran, dass die Statusmeldung im Meldungsfenster nicht verschwindet wenn sie sollte. Die Wartezeit hinter dem Release verringert die Häufigkeit mit der das Release ausfällt. Sollte es dennoch passieren löst die Wartezeit hinter $MSG_T.TYP das Problem.
Auf die Lösung bin ich gekommen, weil mir aufgefallen ist, dass die original MSG_DEMO.src aus dem TP-Verzeichnis in der Ablaufart "Inkremental Step" einwandfrei lief. In den anderen Ablaufarten dagegen funktionierte das Programm nicht zuverlässig. Ich schlussfolgerte, dass der Steuerung irgendein Schritt zu schnell ging und setzte einfach hinter jede Zeile ein WAIT SEC 0.2 und siehe da das Problem war gelöst. Anschließend habe ich die Wartezeiten Schritt für Schritt wieder entfernt und beim $MSG_T.TYP tauchte das Problem wieder auf.
Hier also meine Version der MSG_DEMO.src. Wäre cool zu wissen ob das auch bei anderen funktioniert.
&ACCESS RVP
&COMMENT Example on user messages
DEF msg_demo_vLoulli( )
DECL INT ANSWER, OFFSET
DECL STATE_T STATE
DECL MSG_T EMPTY_MSG
;---------------------Acknowledgement-Message----------
;The programm is stopped until this message is acknowledged over the softkeys.
EMPTY_MSG={MSG_T: VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[] " ",KEY[] " ",PARAM_TYP #VALUE,PARAM[] " ",DLG_FORMAT[] " ",ANSWER 0}
$MSG_T=EMPTY_MSG
$MSG_T.KEY[]="DEMO1: Acknowledgement%1" ;%1 will be replaced by $MSG_T.PARAM[]
$MSG_T.PARAM[]="-Message"
$MSG_T.PARAM_TYP=#VALUE
$MSG_T.TYP=#QUIT
WAIT SEC 0.2 ;mandatory to solve a bug with unreleased status messages
$MSG_T.VALID=TRUE
WHILE $MSG_T.VALID WAIT SEC 0.05
ENDWHILE
;---------------------Status-Message----------
;This message should disappear after it is released.
EMPTY_MSG={MSG_T: VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[] " ",KEY[] " ",PARAM_TYP #VALUE,PARAM[] " ",DLG_FORMAT[] " ",ANSWER 0}
$MSG_T=EMPTY_MSG
$MSG_T.KEY[]="DEMO2: Status-Message"
$MSG_T.TYP=#STATE
WAIT SEC 0.2 ;mandatory to solve a bug with unreleased status messages
$MSG_T.VALID=TRUE
WAIT SEC 4 ;the status-message should disappear after this delay
$MSG_T.RELEASE=TRUE
WAIT SEC 0.5 ;mandatory to help reducing a bug with unreleased status messages
;-------------------Dialog-Query----------------
;This message allows user reply over the softkeys.
EMPTY_MSG={MSG_T: VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[] " ",KEY[] " ",PARAM_TYP #VALUE,PARAM[] " ",DLG_FORMAT[] " ",ANSWER 0}
$MSG_T=EMPTY_MSG
$MSG_T.KEY[]="DEMO3: DIALOG-Message, Please choose one of the below options:"
$MSG_T.DLG_FORMAT[]="A|B|C"
$MSG_T.TYP=#DIALOG
WAIT SEC 0.2 ;mandatory to solve a bug with unreleased status messages
$MSG_T.VALID=TRUE
WHILE ($MSG_T.VALID==TRUE) WAIT SEC 0.05
ENDWHILE
ANSWER=$MSG_T.ANSWER
;---------------------Notification-Message----------
;This message is displayed until it is acknowledged but the programm is not stopped.
EMPTY_MSG={MSG_T: VALID FALSE,RELEASE FALSE,TYP #NOTIFY,MODUL[] " ",KEY[] " ",PARAM_TYP #VALUE,PARAM[] " ",DLG_FORMAT[] " ",ANSWER 0}
$MSG_T=EMPTY_MSG
OFFSET=0
;SWRITE converts ANSWER to a string and represents also an alternative to using $MSG_T.PARAM[]
SWRITE($MSG_T.KEY[],STATE,OFFSET,"DEMO4: Notification, The previously chosen option was number: %d",ANSWER)
$MSG_T.TYP=#NOTIFY
WAIT SEC 0.2 ;mandatory to solve a bug with unreleased status messages
$MSG_T.VALID=TRUE
END
