Nach stundenlangem probieren, der Erfolg:
1. Kuka-Stick wie in der Info von Herrmann formatieren
2. Die Freeware RUFUS von https://rufus.akeo.ie/ herunterladen und damit den Stick wieder bootfähig machen
3. Vorgehen wie in der KUKA Update-Anweisung:
3.1 Verzeichnis RECOVERY aus KUKA.Recovery_V3.0.2_Build10.cab entzippen und auf den Stick kopieren.
3.2 Recovery.exe vom Stick aus ausführen, Update-Funktion starten
Gruss, Peter
Hallo Hermann,
danke für die Hinweise zur Formatierung. Nach dieser Prozedur war es möglich das Update auf dem Stick laufen zu lassen und es beendete ohne Fehlermeldung.
Habe den Recovery-Stick nun auf einer KRC4 (neue Steuerung mit KSS8.3) ausprobiert.
-> Der KUKA-Stick ist jetzt nicht mehr bootfähig 
Dir Update-Software sorgt offensichtlich nicht dafür, dass der Stick wenn er eingerichtet wird auch Bootfähig gemacht wird.
Hattest du mehr Glück, Martl?
K(A)RL, könntest du nicht auch mal von offizieller Seite dazu Stellung nehmen?
Hallo K(a)rl,
ich richte diese Nachricht jetzt einfach mal gezielt an Dich als KUKA-Mitarbeiter, da du freundlicherweise das Update-Package auch hier gepostet hast.
Wie meine und die Erfahrung anderer eurer Kunden aufzeigt, ist das im Topic angebotene Update fehlerhaft bzw. funktioniert entgegen Doku nicht beim Update von Versionen <V2.
Solche Fehler passieren halt, aber inzwischen ist viel Zeit vergangen ohne dass KUKA ein fehlerbereinigtes Update veröffentlicht hat.
Vor zwei Tagen wurde zwar Update-Version 3.0.2 nachgereicht, die aber den genau gleichen Fehler wieder enthält. Ich hatte beim erneuten Versuch zur Sicherheit auch das Antivirusprogramm deaktiviert.
Für KSS8.3-KRC's ist das SW-Update der Recovery-Sticks halt zwingend erforderlich, andernfalls sind die sehr teuer verkauften Sticks trotz perfekter Hardware ein Stück Plastik, dass wegen eines Softwarefehlers auf den Sondermüll muss.
Ich wäre sehr dankbar wenn ein fehlerbereinigtes 
Update >sehr zeitnah< publiziert wird.
Alternativ erlaube ich mir vorzuschlagen, dass als kurzfristige Interimslösung bspw. mit https://www.osforensics.com/tools/write-usb-images.html erstellte Images von V3-Sticks der versch. Grössen (...zunächst 4GB 
) zur Verfügung gestellt werden. Eure Kunden könnten dann die V3-Images mit dieser Freeware auf ihre KUKA-Sticks restaurieren. Da die Recovery-Software ohnehin nur auf den Original KUKA-Sticks läuft, besteht keinerlei Missbrauchs-Risiko. Dieses Tool ist bei mir aktuell auch letzte Rettung um KUKA-Sticks welche durch eure Update-Software zerschossen werden auf den alten Stand zu restaurieren.
Vielen Dank & beste Grüsse,
Peter
Hier noch das Fehlerprotokoll welches das Update-Paket in V3.0.2 erzeugt, exakt der gleiche Fehler wie in V3.0.1
21:37:45 .KUKA.Recovery started at: October 22, 2017 21:37:45
21:37:45 -----------------------------------------------------------------------------
21:37:45 .Command line: -u E:\|F:\KUKA.Recovery_V3.0.2_UpdatePackage\KUKA.Recovery_V3.0.2_Build10.cab
21:37:45 .Start drive: C:\ (C:\)
21:37:45 .LangDBXml open language data base: C:\Users\PETERK~1\AppData\Local\Temp\Recovery\Recovery.kxr
21:37:45 .LangDBXml no KRC software installed. Use windows language.
21:37:45 .LangDBXml use language: en
21:37:45 .LangDBXml set language to: de
21:37:45 .Mainboard: LENOVO 42435JG Not Available
21:37:45 .Bios: 8AET66WW (1.46 )
21:37:45 .CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
21:37:45 .RAM: 4096 MByte
21:37:45 .Available drives 0XBC --> C D E F H
21:37:45 .LogicalDrive 1 -> C: [Windows7_OS] freier Speicherplatz: 158696 MByte
21:37:45 .LogicalDrive 2 -> D: [] freier Speicherplatz: 0 MByte
21:37:45 .LogicalDrive 3 -> E: [KRC_ARCHIVE] freier Speicherplatz: 3640 MByte
21:37:45 .LogicalDrive 4 -> F: [USBSTICK4GB] freier Speicherplatz: 241 MByte
21:37:45 .LogicalDrive 5 -> H: [Daten] freier Speicherplatz: 34422 MByte
21:37:45 .cabinet: F:\KUKA.Recovery_V3.0.2_UpdatePackage\KUKA.Recovery_V3.0.2_Build10.cab files included: 33
21:37:50 .start update Recovery-Stick
21:37:50 .Vds start
21:37:51 .Format drive: E:\ disk name: KRC_ARCHIVE
21:37:51 .Format volume VolumeID = 5206E395-9F4C-42B9-8EEE-31A9ACA0D8A9 drive letter: E:\ disk name: KRC_ARCHIVE
21:37:54 #Query status format partition failed:0X80070057
Hallo Programmiersklave & Stefan
Stefan, wollten wir nicht schon vor laaaaaanger Zeit mal ein Bier trinken gehen? 
Danke für eure Hinweise!
Mit ProConOS & Multiprog habe ich in der Vergangenheit mehrere Projekte gemacht, die Arbeit mit dieser Software war jedes mal wie eine Zahnwurzelbehandlung ohne Narkose. Mein Kunde dürfte wohl auch nicht glücklich sein nachträglich mehrere tausend Euro für SW-Lizenzen auszugeben (sind 2 baugleiche Anlagen), zumal er sich von KUKA beraten lies was er an HW & SW braucht. APT war zu diesem Zeitpunkt noch nicht im Projekt involviert, persönlich hätte ich auch eher zu einem -nicht KUKA- Antrieb geraten & ergänzend dazu eine gute Mayr-Sicherheitsbremse.
Werde es zunächst mal wie von Stefan vorgeschlagen, mit der Ansteuerung aus KRL versuchen. Momentan wird die Mechanik noch montiert, die IB erfolgt kommende Woche.
NotHalt und Bremsrampen sind ein Thema für sich. Der Drehtischmotor ist ein grosser MG-ME-480 der mit einer Übersetzung 1:10 einen Drehtisch antreibt auf dem Produkte mit bis zu 5 tonnen Gewicht mit max. 300 rpm rotieren. Was das Trägheitsmomentverhältnis Motor<>Last & den Regelkreis angeht hat der Konstrukteur bewundernswerten Optimismus. Beschleunigen & Bremsen macht mir solange es geregelt abläuft weniger Sorgen, aber schon generatorisches Bremsen dürfte wegen der immensen kinetischen Energie eine Herausforderung werden. Richtig heikel wird es wenn mal ein Systemfehler oder Stromausfall während hoher Drehzahl einen direkten oder wenig verzögerten STOP 0 bewirkt. Habe noch nie eine Motorbremse leuchten sehen, könnte hier passieren. Auch SBM gibt's keines.
Stefan, die Anlage steht nicht weit weg von dir, falls demnächst eine 5 tonnen schwere Frisbee-Scheibe im Vorgarten liegt ist es unsere
Gruss & Danke für eure Tipps & Unterstützung! 
Guten Morgen,
Es handelt sich um eine Roboterzelle welche vom Integrator mit der beschriebenen Hardwarekonfiguration so konzipiert und montiert wurde. Ich bin als externer Programmierer "nur" mit der Programmierung/Inbetriebnahme beauftragt.
-> Muss kommende Woche so laufen & hab noch keine Idee wie, Yipeeeeee 
Hallo community,
habe für ein Roboterprojekt (KRC4, KSS8.3) mit zwei Zusatzachsen (1x Lineartrack, 1x Drehtisch) folgende Aufgabe:
Der Drehtisch (externe Achse 2) soll asynchron im Drehzahlbetrieb laufen. Der Drehtisch muss nie positionieren, sondern lediglich während der Roboter eine Beschichtung auf das Produkt aufbringt mit definierter Drehzahl laufen, dies allerdings bei einigen Produkten u. U. über mehrere Stunden hinweg. Wichtig ist hierbei lediglich, dass die Drehzahl exakt konstant bleibt.
Die Kuka-Doku für externe Achsen liefert zwar schöne Beispiele wie asynchrone externe Achsen via ASYPTP auf definierte Zielpositionen gefahren werden können, aber was sich mir nicht erschliesst ist wie ich eine externe Achse <wirklich endlos> drehen lassen kann. Wie erwähnt läuft der Prozess sehr lange, die Vorgabe einer sehr grossen Zielposition ist also keine Lösung. Laut Doku kann ASYPTP nicht verschliffen werden, womit eine "Segmentierung" in kleine Bewegungsabschnitte wohl auch als Lösung entfällt. Essentiell ist natürlich auch, dass die KRC mit sich wiederholenden Encoder-Überläufen klar kommt. Eine periodisches Anhalten und Invertieren der Drehrichtung lässt der Prozess nicht zu.
Für Tipps wäre ich dankbar! 
Grüsse, Peter
Hallo K(ar)l,
das Update mit der zum Download angebotenen Version schlägt auf meinem 4GB Kuka Recovery Stick fehl.
Original-Version: KST RecoveryUSB 1.0 V2, also eine Version die gemäss Update-Anleitung funktioniert.
Die Recovery.EXE starte ich natürlich mit Admin-Rechten. Das Update startete, brach aber nach wenigen Sekunden ab.
Endergebnis nach dem Abbruch der KUKA Update-Software ist ein gemäss Windows "unformatierter Stick".
Grüsse & Danke für einen (hoffentlichen) Fix...
Logfile:
20:25:38 .KUKA.Recovery started at: September 11, 2017 20:25:38
20:25:38 -----------------------------------------------------------------------------
20:25:38 .Command line: -u E:\|C:\Users\pk\Desktop\KUKA.Recovery\KUKA.Recovery_V3.0.1_Build0008.cab
20:25:38 .Start drive: C:\ (C:\)
20:25:38 .LangDBXml open language data base: C:\Users\pk\AppData\Local\Temp\Recovery\Recovery.kxr
20:25:38 .LangDBXml no KRC software installed. Use windows language.
20:25:38 .LangDBXml use language: en
20:25:38 .LangDBXml set language to: de
20:25:38 .Mainboard: LENOVO 42435JG Not Available
20:25:38 .Bios: 8AET66WW (1.46 )
20:25:38 .CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
20:25:38 .RAM: 4096 MByte
20:25:38 .Available drives 0X9C --> C D E H
20:25:38 .LogicalDrive 1 -> C: [Windows7_OS] freier Speicherplatz: 167919 MByte
20:25:38 .LogicalDrive 2 -> D: [] freier Speicherplatz: 0 MByte
20:25:38 .LogicalDrive 3 -> E: [KRC_ARCHIVE] freier Speicherplatz: 3640 MByte
20:25:38 .LogicalDrive 4 -> H: [Daten] freier Speicherplatz: 35775 MByte
20:25:39 .cabinet: C:\Users\pk\Desktop\KUKA.Recovery\KUKA.Recovery_V3.0.1_Build0008.cab files included: 33
20:25:44 .start update Recovery-Stick
20:25:44 .Vds start
20:25:45 .Format drive: E:\ disk name: KRC_ARCHIVE
20:25:45 .Format volume VolumeID = 0E1798C1-3AB9-4BB2-8943-8F72FE67BE32 drive letter: E:\ disk name: KRC_ARCHIVE
20:25:48 #Query status format partition failed:0X80070057
Hallo Pat,
anstatt viele Worte zu verlieren, anbei ein Beispiel in dem die Verarbeitung von aus dem Grundsystem eingelesenen Variablen ersichtlich ist. Dieses ist zwar noch von der KRC2, aber prinzipiell hat sich da ja für die KRC4 nichts geändert.
Gruss, Peter
KRC2-Festplatten
Habe in den letzten paar Jahren mehrmals nach HDD-Ausfällen in KRC2-Steuerungen anstelle der preislich in der Tat astronomisch angesiedelten "Original-" KUKA Ersatz-HDD's selbst Ersatzplatten beschafft, von den eingebauten Alternativ-Platten fiel noch nie eine aus, schwer zu Sagen ob "Glück" oder...
Habe bisher soweit verfügbar HDD's von HGST eingebaut, da dieser Hersteller qualitativ hervorragende Festplatten mit erweitertem Temperaturbereich produziert. Alternativ die "einfache" MH-Serie von Fujitsu welche ja auch KUKA selbst meist verbaute.
In einem Notfall wo kurzfristig ein 0815-Geschäft als Festplattenlieferant herhalten musste landete auch eine "Consumer-Quality" SSD in einer KRC (keine Empfehlung so was einzubauen!!!), überraschenderweise läuft aber selbst diese seit nun rund 2 Jahren.
Leider wird es langsam immer schwieriger, noch neue PATA-HDD's zu beziehen...
Archive
Eine wenn auch etwas weniger komfortable Alternative zum Einbau des Floppy-Drive-Ersatzes bei älteren KRC2's auf denen KUKA.USB nicht installiert werden kann / nicht funktioniert oder ein aufwendiges BIOS-Update nötig wäre (aber auch sonst) ist die Verwendung der KrcConfigurator.EXE. Dort einfach den Archivpfad z.B. auf D: abändern, oder (besser) einen weiteren Archiv-Eintrag dafür anlegen. Die Archiv.ZIP auf der HDD lässt sich dann von dort bspw. auf ein Netzlaufwerk oder einen USB-Stick kopieren, oder falls z.B. NSM oder UVNC installiert ist auch auf (s)ein verbundenes Notebook holen, geht schneller als die klassische Disketten-Steckerei. In der KRC2-BOF ist ergänzend zu einem neuen Eintrag in der KrcConfigurator.EXE noch ein Menüpunkt zum Erstellen & Restaurieren des Archivs auf/von der HDD zu ergänzen, sofern auch das Archivieren auf Floppy-Disk trotzdem weiterhin verfügbar sein soll. Wird in der KrcKonfigurator.EXE nur der Pfad geändert (weniger empfehlenswert, da das geänderte Sicherungsziel für Dritte nicht gleich nachvollziehbar ist), dann ist keine Erweiterung des BOF-Menüs nötig.
Schönes Weekend wünscht der APT-ler der eigentlich im Teilzeit-Sabbatical ist
Hallo Floralys,
du musst die Arbeitsraum-Koordinaten in $WORLD ermitteln.
Es ist empfehlenswert, wenn du für's Testen deine WORKSPACES nicht wie du geschrieben hast bei jeder Verletzung auf #OFF umschaltest, sondern wie bereits vorgeschlagen z.B. auf #OUTSIDE_OFF, dann kannst du beliebig fahren und dabei .STATE beobachten, und bist nicht den halben Tag mit Ein- und Ausschalten beschäftigt.
Viel Erfolg!
Gruss, APT
Hallo Floralys,
schalte doch erst mal den Modus auf #OUTSIDE oder #INSIDE um, damit dir der Roboter nicht ständig abschaltet, sonst wirst du mit der Sache ja nie fertig.
Nachdem du alle Arbeitsräume fertig ermittelt & getestet hast, kannst du ja wieder zurück auf #INSIDE_OFF bzw. #OUTSIDE_OFF schalten.
Wenn die Koordinaten nicht aus einem CAD kommen und du diese durch Anfahren ermitteln musst, dann ist es am einfachsten du fährst bevor du was an den Workspaces machst die Eckpunkte deiner Arbeitsräume manuell an und notierst dir die Koordinaten (kartesische Istpositionsanzeige einschalten). Aufpassen, dass du im $WORLD verfährst und das richtige Werkzeug aktiv hast, damit die angezeigten Werte dann auch für's WORKSPACE passen.
Deine Frage nach der Datei steht eigentlich in dem Ausschnitt der Doku den du beigefügt hast beantwortet
Wenn du die Einträge über die BOF oder deinen Programmcode machst (die Werte sind auch zur Laufzeit änderbar), brauchst du die Datei nicht manuell zu Editieren.
Nachdem du die notierten Koordinaten in die WORKSPACES übernommen hast und testen willst ob alle richtig "schalten", ist es am einfachsten die zeigst dir $WORKSPACE[n].STATE im Variablenfenster an, schaltest um auf zyklische Aktualisierung, und fährst mit dem Robbi mal wieder in der der Zelle umher...
Grüsse, APT
PS: Bist du sicher dass der Ursprung für deine WORKSPACES 0,0,0 sein sollte? 
Deine Infos sind ein bisschen sehr sehr spärlich...
Heisst das die Klemme ist rein physikalisch mit der E-Bus Seite dem Master der CX zugeordnet, und RJ-Seite der KRC?
Kannst du die Klemme auf der Sekundärseite (RJ-45) in WorkVisual einbinden? Die beiden Seiten laufen ja unabhängig voneinander.
Warum ein "Simulated Device", und weshalb für den CX-Master die ESI/XML von WorkVisual?
Was zeigt denn CoE Online auf TwinCAT Seite über die Klemme an, dort kannst du ja (unter Identity) auch die Vendor-ID der Klemme anzeigen lassen. Mal einen Konfigurationsvergleich gemacht?
@Jannn: Die neue Klemme bezieht ihre 24V-Versorgung redundant, entweder vom E-Bus oder vom Frontstecker.
Die "normale" Bridge-Klemme hatte ich schon, das lief. Die Spezialvariante -1001 kenne ich nicht.
Auf welcher "Seite" (von welchem der beiden Master aus gesehen) kommst du mit der Klemme nicht in den OP-Status, KRC4 oder CX?
Hast du Distributed Clock ausgeschaltet?
Gruss, Peter
Mache das (wenn es eine externe SPS gibt) mit einem Ausgang der in der SPS.SUB zyklisch getoggelt wird. Das toggeln wird in der SPS ausgewertet.
Alternativ funktioniert auch, in der SPS.SUB mit einer zyklisch aufgerufenen PULSE Anweisung einen Ausgang mit z.B. 100ms zu pulsen. Solange die SPS.SUB läuft ist der Ausgang statisch TRUE, geht aber aus wenn die SPS.SUB stoppt / nicht läuft.
Gruss, Peter
Gijs,
Wenn du TwinCAT kennst, dann müsstest du dich doch auch mit Beckhoffs Kinematic Transformation Package befasst haben. Unter TC3 (TF5113) sind inzwischen auch serielle 6-Achs Transformationen möglich. Beckhoff-Typisch ist die Doku halt wie fast immer unter aller Sau.
Aus meiner Sicht lohnt sich die Steuerung des Roboters via PLC aber nur, wenn es um extrem viele gleiche oder fast gleiche Anlagen geht. Letztlich ist Roboter-Syntax für interpoliertes Bewegen einfach viel effizienter zu Programmieren & besser zu warten als das was Beckhoff anbietet, egal ob du deren Interpolation-Lib, oder G-Code nutzt.
Gruss, Peter
Wenn es nur um wenig KRL-Code geht, der schneller als 48ms bearbeitet werden muss,
gibt es einen Trick der mit der KRC funktioniert:
Du brauchst dazu nur auf deiner Busverbindung zwischen SPS & KRC in jede Richtung ein
binäres Signal:
SPS:
bOutCyclicToggle:=NOT bInCyclicToggle;
KRC:
Im Signal-Mapping das Signal von der SPS direkt auf das Signal an die SPS verknüpfen.
(Wichtig, dies MUSS im Verschaltungseditor geschehen, NICHT im Submit-Interpreter!).
Ausserdem das Signal auf eine $IN Variable legen.
Dies Konstellation führt dazu, dass das Signal im Buszyklus toggelt, wobei bei meinen Tests
nie Toggle-Zeiten kleiner IPO-Takt resultierten.
Nun deklarierst du dir 2 globale Interrupts, beide auf das gleiche Signal, einmal jedoch mit
einer fallenden, einmal mit einer steigenden Flanke. Beide Interrupts verknüpfst du mit dem
gleichen Programm, in das du die Zeilen aus deiner SPS.SUB kopierst mit denen du Istwerte
auf OUT-Signale der Busverbindung kopierst. Den Code in der SPS.SUB würde ich dennoch
stehen lassen. Was noch Sinn macht, ist eine weitere Ausgangsvariable in dem Interrupt-
Code zu ergänzen, die dort auch einfach bei jedem Aufruf getoggelt wird. So hast du eine
perfekte Möglichkeit um zu Messen, mit welcher Frequenz dein Interrupt-Code tatsächlich
bearbeitet wird. In meinem Fall waren dies absolut zuverlässig 12ms. (Aufgezeichnet mit
mit dem Software-Scope der SPS).
Mit diesem simplen Trick, den ich bisher bei 2 Anlagen umgesetzt habe, war es zuverlässig
möglich die Istwerte im 12ms Takt aus der KRC zu bekommen. Setzte dies beispielsweise ein,
um eine externe Servoachse auf den Roboter zu synchronisieren. Klappt tadellos.
Gruss, Peter
PS: Mit ProConOS lässt sich auch zyklisch die Istposition abgreifen, aber das Produkt ist völlig
überteuert, dito dessen Programmiertool. Ausserdem ist es unter den SPS'en was Flexibilität,
Schnittstellen, und Einsatmöglichkeiten angeht das schlechteste Produkt mit dem ich in den
vergangenen 15 Jahren je arbeiten musste.
Hallo Interrupt,
hast du die Beschleunigung bereits reduziert?
BAS(#ACC_CP,<Beschleunigung in %>)
Der % Wert bezieht sich auf DEF_ACC_CP
Gilt so natürlich nur, wenn du die Bewegung nicht mittels Inline-Formular machst.
Gruss, APT
Du bekommst doch in genannten Fenster sowohl von der RDW als auch der Festplatte so Infos wie Seriennummer und Betriebsstunden angezeigt, welche Werte sind denn plausibel? Diese dann übernehmen...
Hatte allerdings auch erst kürzlich eine alte KRC2 die nicht mehr lief, u.a. auch mit dieser Meldung (die AKKU's waren "natürlich" auch kaputt). Dort stand tatsächlich sowohl bei der HDD als auch der RDW bei den Betriebsstunden eine 0 drin, was bei einem 9-jährigen Roboter dann doch eher unwahrscheinlich ist
Gruss, APT
Der KR16-2 hat Bremsen in den Handachsen (...oder die Getriebehemmung ist enorm)
Habe ein halbes Dutzend Robbies dieses Typs programmiert, da bewegt sich bei ausgeschalten Antrieben selbst mit grober Gewalteinwirkung auch bei den Handachsen NIX 
...miss es doch wenn du mal wieder eine KRC4 und ein paar Minuten Zeit hast einfach selbst mal nach
