Intro:
Wer sich einen Roboter kauft erwartet meist, dass dieser auf Knopfdruck ein vorgewähltes Programm ablaufen lassen kann. Genau hierfür gibt es bei einem normalen Kuka-Roboter die Betriebsart "Automatik". Bei der VKRC1-Steuerung fehlt diese Betriebsart, aber es gibt die Betriebsart "Automatik extern". In diesem Modus braucht es eine bestimmte Sequenz von externen Signalen und Impulsen, um ein vorher angewähltes Programm zu starten. Im Folgenden wird beschrieben wie man dies realisieren kann.
Zusammenfassung:
Details:
Die benötigte Sequenz um ein Roboterprogramm extern zu starten ist:
Leider gibt es die genannten Eingänge so gar nicht am KRC1, denn genaugenommen sind die beschriebenen Eingänge eher Systemvariablen, welche erst mit externen Eingängen verknüpft werden müssen.
Die KRC1 kann prinzipiell 1024 Eingänge und 1024 Ausgänge verwalten. Zusätzlich stehen eine Reihe von Treibern zu gängigen Feldbussen wie DeviceNet, Profibus oder Interbus zur Verfügung. Mit einer entsprechenden Erweiterungskarte kann man dann einen Feldbusscontroller oder eine SPS an die KRC1 anschließen, über die man dann die benötigten Signale einlesen kann.
Netterweise befindet sich an der MFC-Karte bereits ein DeviceNet-Interface welches ich im Folgenden nutzen werde um die Betriebsart Automatik-Extern zu realisieren. DeviceNet ist ein Feldbus der sich scheinbar eher im englischsprachigen Raum durchgesetzt hat, wohingegen anderswo auf Profibus gesetzt wurde. Dementsprechend kommen die meisten Angebot auf Ebay aus Übersee. Dafür ist die Nachfrage nach Gebrauchtteilen in Europa eher gering. Wer also etwas Geduld hat, kann durchaus günstig an solche Controller und IO-Module kommen.
Wichtig zu wissen ist, dass es programmierbare (z.B. Wago 750-806) und nicht-programmierbare Controller gibt (z.B. Beckhoff BK5200 oder Wago 750-306). Von den programmierbaren rate ich ab, denn ich habe es nicht hingekriegt, die Ausgänge darauf durch den Kuka setzen zu lassen.
Details zum Anschluss des Controllers an die Roboter-Steuerung findet ihr im Datenblatt des Controllers und dem Dokument "DeviceNet for KR C2 …" von Kuka. Achtung, der Controller benötigt drei(!) Spannungsversorgungen von 24V. Eine am Bus, eine für den Controller und eine für die Sammelschiene zu den Modulen. Ich habe für alle drei das Netzteil des PC's im KRC1 genommen. Dort konnte ich auch die Abschirmung erden. Nur die Relais-Module zum Ansteuern der Pneumatikventile wollte ich galvanisch trennen, daher das 24V Netzteil auf dem Bild.
Den Dateien DEVNET.INI und IOSYS.INI habe ich die unten abgebildeten Zeilen hinzugefügt. Beide Dateien findet ihr im Ordner C:\KRC\Roboter\INIT\.
Um über den KCP an die genannten Dateien zu gelangen muss man in den Expertenmodus wechseln.
Erklärung: "INB0" steht für die ersten 8 Eingänge am KRC1 Controller. B = Byte = 8 Bit = 8 Eingänge.
0 = ab dem nullten Byte im Controller IO Speicher.
"=5,0" steht für das nullte Eingangsbyte im DeviceNet Controller mit der MacID 5.
Die 8 Eingänge können dann in Programmen mit $IN[1 bis 8] angesprochen werden.
Auch wenn es nicht eindeutig dokumentiert ist, so muss die Anzahl der physikalisch vorhanden Eingänge meines Erachtens exakt mit der Anzahl an reservierten Bits übereinstimmen. Es dürfen nicht mehr und nicht weniger sein. Die Anzahl an digitalen Ein- oder Ausgängen muss also ein mehrfaches von 8 sein.
Jetzt die Dateien DEVNET.INI und IOSYS.INI schließen und die Änderungen über „Menü / Konfig. / E/A-Treiber / E/A Rekonfigurieren“ aktivieren.
Wer sich übrigens nicht am KCP abmühen will, um die Dateien zu editieren,
kann die KRC1 auch an sein Heimnetzwerk anschließen und von einem anderen Rechner aus bequem
in einem Editor die Änderungen vornehmen.
Der Ethernetanschluss befindet sich an der MFC-Karte und wird standardmäßig auf den KCP geführt.
Tatsächlich befindet sich auf der Rückseite des KCP eine Gummikappe hinter der sich der
Netzwerkanschluss befindet. Nichts spricht aber dagegen das Netzwerkkabel dauerhaft an der
MFC-Karte anzustecken.
Beschreibungen wie ihr Filesharing zwischen eurer Windowsversion und Windows 95 ans laufen kriegt,
findet ihr im Internet.
Im Menüpunkt Konfig/Ein-Ausgänge/Automatik Extern könnt ihr nun den Systemvariablen eine Kuka-Eingangsnummer zuordnen. Ich habe die Eingänge 10 bis 14 gewählt.
Jetzt könnt ihr im Idealfall jetzt bereits einen externen Start auslösen, aber zunächst solltet ihr überprüfen, ob die Connect-Leuchte am DeviceNet-Controller leuchtet. Ist dies nicht der Fall kontrolliert etwaige Fehlermeldung am KCP oder im DeviceNet-Logfile. Über den Menüpunkt Anzeige/Ein-Ausgänge/Digitale Eingänge könnt ihr kontrollieren ob gesetzte Eingänge vom Kuka erkannt werden. Gesetzte Eingänge leuchten rot.
Am unteren Bildschirmrand könnt ihr auch zu den Ausgängen wechseln. Um diese testhalber zu setzen, müsst ihr einen der Totmannschalter drücken und könnt dann unten "Ändern" wählen. Die entsprechenden Ausgänge sollten dann schalten.
Wenn das alles klappt, könnt ihr die Eingänge $MOVE _ENABLE und $DRIVES_OFF fest mit 24V verbinden. Alternativ könnt ihr auch die beiden Variablen dem Eingang 1025 zuweisen was dauerhaft logisch eins entspricht. Anschließend ein Roboter-Programm laden und die erste Zeile anwählen. Nun einen kurzen 24V-Impuls auf den Eingang $DRIVES_ON geben und warten bis die Anzeige "Antriebe EIN" auf dem KCP grün wird. Anschließend einen kurzen 24V-Impuls auf die Eingänge $CONF_MESS und $EXT_START geben. Jetzt sollte das Programm starten. Alternativ könnt ihr die Antriebe auch über den Taster am KCP aktiv schalten und die Fehlermeldungen auf dem KCP quittieren. In dem Fall reicht nur ein Impuls auf $EXT_START.
Wenn ihr keine zusätzliche externe Steuerung verwenden wollt, um die Impulssequenz automatisiert auf die drei Eingänge zu geben, dann kann dies auch von der KRC1 selbst übernommen werden. Zugegeben es ist etwas seltsam, wenn sich die KRC1 die Signale selber generiert die sie benötigt um anzulaufen, aber was solls.
Wenn der Submit-Interpreter läuft, dann wird der Programmcode in der Datei sps.sub beim Hochfahren des Roboters gestartet und selbst beim Aufrufen eines Roboterprogramms im Multitasking weiter ausgeführt. Die Programmierung in der sps.sub kann man nun so erweitern, dass sie nach dem Aktivieren eines Eingangs am DeviceNet-Controller die Impulssequenz an drei Ausgängen erzeugt, welche wiederum mit den Eingängen $DRIVES_ON, $CONF_MESS und $EXT_START verbunden werden.
Bevor ihr aber Änderungen an der sps.sub vornehmt, muss die Kuka-Software angehalten werden. Die sicherste Variante ist, dass ihr den PC neu startet und nach dem Erscheinen von VxWorks beide CTRL-Tasten auf einer externen Tastatur drückt. Siehe auch den Artikel zur Inbetriebnahme. Nun könnt ihr die sps.sub problemlos editieren. Dies gilt ebenfalls für die $config.dat in der die Variablen definiert werden, die ihr in der sps.sub benötigt. Beide Dateien findet ihr im Ordner C:\KRC\Roboter\KRC\R1\System\.
Hier die Zeilen welche ich am Ende der $config.dat hinzugefügt habe.
Hier die Programmierung in der sps.sub. Die Initialisierung der Variablen kommt vor LOOP.
Die Erzeugung der Signalsequenz kommt vor ENDLOOP.
Nun könnt ihr den PC neu starten, in den Expertenmodus gehen, im Navigator in den Ordner KRC\R1\System\ wechseln und dort kontrollieren ob das Icon der sps.sub Datei einen Grünen Pfeil hat, dann ist alles ok. Ist das Icon aber mit einem roten X markiert könnt ihr die Datei anwählen und euch die Fehlermeldungen anzeigen lassen. Eventuell müsst ihr noch den Submit-Interpreter im MenüPunkt Konfig/Submit-Interpreter starten, so dass das S unten in der Taskleiste grün wird.
Jetzt seid ihr über den Berg und braucht nur noch:
Viel Spass beim Nachmachen.
Alternative:
Eine Alternative zum Verwenden eines DeviceNet Controllers könnte die IO-Karte von Manolo Maravillas sein, welche direkt auf die die unbelegten IO Pins an der MFC zurückgreift.
Dank:
Auch hier geht wieder ein großer Dank an Helmut Rohe, der mir immer mit Rat und Tat zur Seite Stand.
Haftungsausschluss:
Das vorliegende Projekt erfordert Fachkenntnisse. Nachmachen auf eigene Gefahr und Haftung.
Nächste Themen: