Avvertenza. Documentazione di un’esperienza personale, non istruzioni: i lavori su tensioni pericolose vanno eseguiti solo da personale qualificato.
IL PROGETTO
KUKA, movimento e visione
L’esperienza con un KR5 e il progetto di visione artificiale per guidare la presa dei pezzi.
Il robot
Ho un KUKA KR5 arc con controllore KRC2 ed05, comprato usato. È arrivato senza il cavo tra braccio e armadio, e il controllore non partiva più. Il ripristino ha richiesto un’alimentazione trifase ricavata dalla monofase, un cavo motore costruito in casa, la catena di sicurezza, la reinstallazione del software e il mastering degli assi. Il 30 settembre 2026 il robot si è mosso di nuovo.
La visione artificiale
Tra i miei progetti c’è un sistema di visione artificiale per guidare il robot nella presa dei pezzi, con una webcam montata sul polso. La calibrazione della camera è fatta, e ho scritto in C la cinematica diretta e inversa del KR 5 arc. Il collegamento con il robot e le prove di presa sono ancora da fare.
Dal progetto al diario
Il ripristino è raccontato nel diario. La visione avrà un articolo suo quando ci saranno prove da mostrare.
Il punto di partenza
Ho un KUKA KR5 arc con controllore KRC2 ed05. Rimetterlo in funzione ha voluto dire affrontare più problemi insieme: il trasporto, l’alimentazione, i disturbi elettrici, il circuito di sicurezza, i cavi, il PC di controllo e infine il software e la calibrazione degli assi.
In origine il robot lavorava in una cella di floccatura. A luglio 2026 il controllore aveva smesso di partire: circa tre minuti dopo l’avvio il kernel si bloccava, l’interfaccia restava ferma e nei log comparivano sempre gli stessi messaggi (2804 errore interno, 223 errore di collegamento con il modulo di potenza, 6504 sottotensione). La firma era quella di una mancanza di rete rilevata dal controllore.
L’ho comprato usato in Puglia, vicino a Bari, ed è arrivato con un corriere. Al momento dell’arrivo non funzionava nulla: mancava il cavo di alimentazione tra il braccio e l’armadio di controllo, quindi non c’era modo di provare niente.
Il viaggio in Puglia
Per l’acquisto sono andato in Puglia. Queste foto raccontano anche quella parte: il viaggio in treno, un giro in città e il primo incontro con il KR5, prima della spedizione.
Il viaggio in treno.
Un giro in città durante il viaggio per l’acquisto.
Il robot e l’armadio prima della spedizione.
Il primo incontro con il KUKA.
Bari Centrale, durante lo stesso viaggio.
L’arrivo
Armadio e robot sono arrivati su pallet, con un furgone, un transpallet e una rampa di compensato.
L’armadio KRC2 durante il trasporto.
Il braccio appena scaricato.
Robot, armadio e KCP2 nella prima sistemazione.
Erano due bancali, uno per il braccio e uno per l’armadio, da circa 150 kg ciascuno. Li abbiamo scaricati a mano.
Dentro l’armadio
Il KRC2 contiene il PC di controllo, gli azionamenti degli assi, l’alimentazione e il modulo di I/O. Aperto, l’armadio mostra bene come è organizzato.
L’armadio aperto: azionamenti degli assi e PC di controllo.
Il PC, il KPC ed05, è montato sulla porta e lavora a 24 V DC. I cavi verso l’armadio arrivano su connettori D-sub etichettati, come A32/ST4 e A32/ST6.
Il PC di controllo sulla porta dell’armadio.
La targhetta del KPC ed05.
Ogni asse ha il suo azionamento. Sul modulo KSD1-16 l’etichetta è chiara: fino a 780 V DC, con 180 secondi di attesa prima di poter lavorare in sicurezza dopo lo spegnimento.
Un azionamento KSD1-16 con l’avviso di tensione residua.
Prima di tutto c’era da pulire. I pannelli laterali raccontano da soli in che condizioni lavorava il robot.
Un pannello pulito accanto a uno ancora da pulire.
La polvere aveva intasato gran parte dei passaggi d’aria per il raffreddamento. Ho smontato i componenti e pulito tutto con stracci, sgrassante e aspirapolvere.
La catena di alimentazione
L’alimentazione che arriva al controllore passa per una catena precisa:
VFD → autotrasformatore → KRC2
Il VFD è un VEVOR: secondo l’etichetta sui morsetti accetta un ingresso monofase a 220 V su R e T e fornisce un’uscita trifase su U, V e W.
Il VFD che alimenta la catena.
All’interno dell’armadio l’alimentazione arriva alla morsettiera X2: morsetti da 1 a 5, i conduttori di protezione PE, i morsetti da 24 a 29 e i fusibili F11, F12 e F14.
La morsettiera X2.
Interruttori e alimentatore all’interno della porta.
Il motivo è semplice: in garage c’è solo la monofase a 230 V, mentre il KRC2 vuole la trifase a 400 V. Il VFD ricava una trifase dalla monofase, e l’autotrasformatore la alza alla tensione richiesta dal controllore.
Il VFD è da 7,5 kW. Non lo uso per comandare un motore, ma come generatore di trifase: ho impostato una frequenza fissa a 50 Hz e le rampe di accelerazione e decelerazione.
L’autotrasformatore trifase porta la tensione da 230 a 400 V ed è da 5,5 kW.
Inverter e autotrasformatore sul banco.
Lo schema concettuale della catena di alimentazione.
Il differenziale che scattava
Il filtro EMI sul retro dell’armadio faceva scattare il differenziale da 30 mA. Le correnti di dispersione verso terra di un sistema con inverter e filtri non sono quelle per cui è pensato un differenziale comune.
Il filtro EMI sul retro dell’armadio.
La soluzione è stata passare a un differenziale Type B da 300 mA, adatto alle correnti di guasto con componente continua tipiche degli inverter.
Attenzione: questa è la soluzione adatta al mio impianto. La scelta del differenziale va fatta in base all’impianto e alle norme applicabili, possibilmente con un elettricista, e non copiata da questo articolo.
Il raffreddamento
La ventola dell’armadio è una ebm-papst DV4114/2N: 24 V DC, 850 mA, 20,5 W, con un campo di alimentazione da 12 a 30 V DC. L’ho alimentata a 12 V con un convertitore DC-DC step-down basato su LM2596, chiuso in una guaina termorestringente verde e montato sulla piastra accanto al termostato.
La ventola con il convertitore e il termostato.
Il convertitore LM2596 prima della guaina.
Il convertitore finito, nella guaina verde.
A 12 V la ventola gira più piano e fa molto meno rumore. Il termostato fa da bypass: sopra i 35 °C scavalca il convertitore e dà alla ventola i 24 V pieni. Il componente che si vede collegato all’uscita del convertitore, nella foto, è proprio il termostato di bypass.
Il cablaggio di sicurezza X11
Sul pannello connessioni del KRC2 ed05 ci sono, tra gli altri, X1/XS1 per l’alimentazione, X20 per i motori, X11 per l’interfaccia cliente, X19 per il KCP e X21 per l’RDC. Il connettore X11 porta i segnali di sicurezza: arresti di emergenza e consensi. Senza un cablaggio corretto il robot non si muove, ed è giusto così.
Cablaggio con morsetti numerati nella parte bassa dell’armadio.
Su X11 ho collegato una scheda relè chiusa in una cassetta, che raccoglie i dispositivi di sicurezza della cella: un interruttore di consenso, un pulsante di emergenza e due interruttori sul cancello della cella.
La cassetta con la scheda relè; l’interruttore bianco è il consenso del robot.
Ho provato ogni dispositivo: premendo l’emergenza o aprendo il cancello il robot si ferma, e sul KCP compare il messaggio corrispondente.
I cavi verso il robot
Tra controllore e robot serve il cavo motore X20–X30, che mancava: l’ho costruito io, lungo 7 m, con conduttori da 1,5 mm². Nel connettore X20 ogni asse occupa tre contatti per le fasi U, V e W: A1–A3 per l’asse 1, B1–B3 per l’asse 2 e così via fino a F1, F4 e F6 per l’asse 6. I freni usano D3, E3 e F3 per il positivo e D5, E5 e F5 per il negativo, più il conduttore di terra da 6 mm².
Sul lato robot i conduttori arrivano ai moduli dei connettori, numerati uno per uno.
Il connettore X20 durante il lavoro sul cablaggio.
Il lato dei contatti del connettore X20.
I moduli dei connettori sul lato robot.
Un modulo del connettore con i conduttori ricollegati.
La posizione degli assi arriva invece dall’RDC, sulla base del robot, collegato con un cavo separato.
L’RDC sulla base del robot.
Finito il cablaggio, ho controllato il cavo con il tester in continuità, contatto per contatto.
Gli I/O su DeviceNet
Gli ingressi e le uscite del controllore passano da un accoppiatore Beckhoff BK5220 su DeviceNet, seguito da un modulo di ingressi digitali KL1408, uno di uscite digitali KL2408 e dal terminale di chiusura KL9010.
Il BK5220 con i moduli di I/O.
Indirizzo e velocità del nodo si impostano con i DIP switch sul lato: i DIP da 1 a 6 danno l’indirizzo, i DIP 7 e 8 la velocità (125, 250, 500 kBd o automatica). Il bus arriva su un connettore a cinque poli: V+ rosso, CAN-H bianco, schermo, CAN-L blu, V− nero.
I DIP switch e la tabella stampata sul modulo.
Il cablaggio del connettore DeviceNet.
Sui moduli ho collegato l’alimentazione a 24 V e 0 V e i primi ingressi e uscite.
I primi I/O cablati.
Il nodo è configurato con MAC-ID 5 a 125 kbaud. Nel file IOSYS.INI del controllore è mappato un byte di uscite e uno di ingressi: le uscite da $OUT[1] a $OUT[8] funzionano e si accendono dall’interfaccia, alla voce Ingressi/Uscite, tenendo premuto il pulsante di consenso in T1.
Per ora le uscite comandano solo qualche relè di prova, e gli ingressi non sono ancora collegati a niente.
Il PC di controllo
Il PC del KRC2 è basato su una scheda madre Fujitsu Siemens con PhoenixBIOS, un Celeron a 2,0 GHz, 512 MB di RAM e un disco IDE da 80 GB. Ci sono anche la scheda video Chips & Technologies 65550, una scheda di rete Intel PRO/1000 CT, la scheda KUKA MFC3 e una Siemens CP1616 per PROFINET. Smontarlo ha mostrato un problema classico: la pasta termica era secca, al punto che il processore è rimasto attaccato al dissipatore.
La scheda madre del PC di controllo.
Il processore uscito insieme al dissipatore.
La pasta termica originale.
Il Celeron pulito.
Pasta termica nuova prima di rimontare il dissipatore.
Anche il disco originale era coperto di polvere. Prima di toccare qualsiasi cosa l’ho estratto, collegato al mio PC con un adattatore IDE-USB e messo offline e in sola lettura. Poi l’ho copiato settore per settore in un file .vhd, con un piccolo script Python, e ho verificato la copia con l’hash SHA256 su due letture complete. La copia è finita anche sul NAS, controllata di nuovo con l’hash.
La prima prova di copia direttamente sul NAS, via Wi-Fi, andava a poco più di 1 MiB/s: circa 18 ore. Copiando prima su un disco locale, a 28 MiB/s, sono bastati circa 45 minuti.
Il disco originale.
I dischi preparati sul banco.
I dati del robot (configurazione, file di calibrazione, programmi) li ho ricostruiti da più copie, dalla più recente alla più vecchia, in un unico pacchetto con l’elenco dei file e i loro hash. Un centinaio di file che esistevano solo nell’archivio del 2021, relativi alla vecchia cella, li ho messi da parte: si aggiungono solo dopo un avvio che funziona.
Sul banco ho preparato anche alcuni dischi IDE vuoti di scorta per il KRC2.
Reinstallare il software
Il PC del KRC2 gira su Windows XP. Dopo la formattazione ho reinstallato il software di sistema KUKA, KR C V5.5.14.
La formattazione e l’installazione di Windows XP.
L’installazione di KR C V5.5.14 vista dal KCP.
Il primo tentativo è finito con 8 errori. Mancava il .NET Framework 2.0, da cui dipendono alcune librerie KUKA, e un file in C:\KRC era bloccato dai servizi KUKA ancora attivi. Il setup vuole anche una vera partizione D: su disco, dove copia il CD e tiene l’archivio. Dopo aver installato .NET 2.0 SP2, fermato i servizi e creato D:, il setup è andato a buon fine con 0 errori.
Durante il setup si scelgono il tipo di robot, in questo caso il KR5 a pavimento, e i driver dei bus di campo. Qui c’è una trappola: lasciando selezionati tutti i 14 driver I/O, l’avvio si ferma al caricamento dei PlugIn. Va scelto solo DeviceNet, l’unico bus usato da questo controllore.
La scelta del tipo di robot.
Le opzioni dei bus di campo.
Il log dell’installazione mostra Windows XP con Service Pack 3 e alcuni avvisi durante la lettura dei file di configurazione.
Il log del setup.
Dopo l’installazione, in Gestione dispositivi la rete virtuale VxWin/RTAcc Shared Memory Network era presente, ma due controller Ethernet e il controller video risultavano senza driver. Il driver della scheda di rete Intel e quello video si trovano sul CD KUKA. Uno dei due “Ethernet Controller”, invece, è la scheda PROFINET: non deve ricevere il driver Windows di Siemens, perché deve restare al sistema real-time; il CD KUKA ha un driver segnaposto apposta. Anche la risoluzione dello schermo andava riportata a 800 × 600, quella del KCP.
I dispositivi senza driver dopo la reinstallazione.
La risoluzione impostata per il KCP.
All’avvio del software è comparso anche l’errore IKukaDBOLE (RELEASE) – OLE Exception #800706ba – The RPC server is unavailable.
L’errore IKukaDBOLE all’avvio.
La causa era la stessa del setup con 8 errori: mancava il .NET Framework 2.0. Dopo averlo installato e rifatto il setup, l’errore non si è più presentato.
HAL, FTP e i file del robot
Il problema più subdolo era nascosto in Windows. Il sistema originale era un Windows XP Embedded con HAL “Standard PC”, non ACPI. Reinstallando XP, Windows aveva scelto da solo l’HAL “ACPI Uniprocessor PC”. Risultato: schermata blu IRQL_NOT_LESS_OR_EQUAL (0x0A) a ogni spegnimento e, soprattutto, il sistema real-time VxWorks che non partiva.
Ho cambiato l’HAL in “Standard PC” da Gestione dispositivi, tenendo prima una copia dei file di sistema e una voce di avvio di emergenza con il vecchio HAL. Le schermate blu sono sparite e VxWorks ha cominciato a rispondere. L’effetto collaterale: con l’HAL Standard PC Windows non spegne più il PC da solo, e il driver video originale dà uno schermo nero.
Il menu di avvio con la voce di emergenza, poi tolta quando l’HAL nuovo si è dimostrato stabile.
Poi l’interfaccia si fermava a “Start 10%”. VxWorks legge i file del robot da Windows via FTP, attraverso un’interfaccia del software KUKA che sul CD è disattivata di fabbrica. Abilitandola nel registro, VxWorks si è collegato e l’avvio è andato avanti.
L’ultimo passo è stato rimettere la configurazione originale del robot (i dati macchina) e i suoi file di calibrazione, che dopo il setup erano spariti, con gli azionamenti accesi fin dall’avvio. Con queste tre condizioni insieme l’interfaccia è arrivata a “Ready 100%”, per la prima volta dal guasto di luglio.
Backup, mastering e finecorsa
Una volta alimentato e messo in sicurezza, il lavoro si sposta sul software: backup della configurazione, programmazione in KRL sotto KSS, mastering degli assi e recupero dei finecorsa software quando un asse è finito fuori campo.
Il disco completo, con il controllore funzionante e il robot che si muove, l’ho clonato di nuovo e verificato con l’hash: è il backup di riferimento, e quelli intermedi li ho eliminati.
Il finecorsa che ho incontrato più spesso è il 1447 SOFTEND +A5, sull’asse 5. Sul KR 5 arc A5 negativo porta l’utensile verso il basso, e la direzione dell’utensile è l’asse Z della flangia, non la X. Scrivere a mano l’orientamento dei punti cartesiani mi ha portato due volte fuori campo. Il metodo che funziona è partire da una posa definita sugli assi e costruire il percorso relativo alla posizione attuale.
I finecorsa meccanici in plastica, fatti al tornio.
Il mastering l’ho fatto con un comparatore.
I pezzi bianchi nella foto sono finecorsa meccanici in plastica, che ho fatto al tornio.
I primi movimenti
Il primo programma di prova è semplice: qualche punto PTP, il ritorno in HOME e un movimento LIN, eseguiti in modalità T1 con l’override al 75%.
Il programma di prova sul KCP.
Il robot nella sua sistemazione attuale.
Il primo movimento è arrivato la sera del 30 settembre 2026, poco dopo il “Ready 100%”, comandato a mano dal KCP. Sotto carico è ricomparso però il messaggio 1043, tensione difettosa sul bus di carica del modulo di potenza, insieme all’avviso 284: batterie tampone sotto i 22 V. Le batterie del KRC2 vanno sostituite ogni due anni, e il guasto di luglio aveva tutta l’aria di essere legato proprio all’alimentazione.
Due dettagli utili per chi programma un KRC2 in T1:
- In questo controllore i movimenti PTP in T1 sono limitati al 7% e quelli cartesiani a 0,1 m/s: cambiare la velocità nel programma, in T1, non cambia nulla.
- Con A5 = 0 gli assi 4 e 6 sono allineati: è la singolarità del polso, e i movimenti LIN e CIRC a orientamento costante si bloccano. Le pose di partenza vanno tenute con A5 diverso da zero.
Il robot in movimento.
Il messaggio 1043 dipendeva dall’inverter: la tensione del bus del modulo di potenza risentiva di come il VFD generava la trifase. Le batterie tampone, invece, non le ho ancora cambiate.
Un agente sul controllore
Per collegare il robot ad altri programmi ho installato sul KRC2 un piccolo agente: uno script crea un’attività pianificata, KukaAgent, eseguita come utente di sistema all’avvio di Windows. L’installazione comprende anche Python 3.4.4, una delle ultime versioni compatibili con Windows XP.
L’installazione dell’agente, sul KCP2 e sul monitor esterno.
Gran parte del lavoro da remoto (diagnosi dei log, script di clonazione e caricamento, agente) l’ho fatta insieme a Claude, che lavorava sul mio computer mentre io mi occupavo della parte fisica: interruttori, cavi, LED e misure.
Il PC di controllo e il mio computer sono collegati con un cavo diretto, su una rete privata con indirizzi fissi. L’agente ascolta su una porta TCP e accetta comandi solo dall’indirizzo del mio computer. Sa rispondere a un ping, eseguire un comando, leggere e scrivere file, avviare un processo in background e riavviarsi. Ogni richiesta finisce in un log, che una finestra sul PC del KRC mostra in tempo reale. Un secondo strumento cattura lo schermo e invia clic e tasti, utile per completare le procedure che Windows XP vuole fare con il mouse.
Con l’agente carico i programmi KRL da rete. Ci sono alcune regole da rispettare:
- caricare sempre la coppia
.srce.dat, con codifica Windows-1252 e fine riga CRLF; - i programmi caricati da rete compaiono nel Navigator solo con il gruppo utenti Esperto;
- prima di caricare, il programma va deselezionato: se è aperto nell’editor, alla deselezione l’interfaccia salva la sua copia e sovrascrive quella appena caricata.
Per sicurezza, mentre lavoro da remoto gli azionamenti restano spenti con un interruttore: il robot non può muoversi. L’override si regola solo dal KCP, mai dal programma.
L’agente lavora solo su comandi e file: non legge e non scrive le variabili del robot. Per quelle esiste un client separato per KUKAVARPROXY, nel progetto che collega il robot alla realtà virtuale.
Cosa ho imparato
- Clonare il disco prima di tutto e verificare la copia: ogni tentativo successivo è stato possibile perché c’era un punto da cui ripartire.
- Prima la copia, poi la cancellazione, in due passi separati. Un programma di prova è andato perso perché la copia era fallita in silenzio e la cancellazione, lanciata subito dopo, è andata avanti lo stesso.
- I dettagli dell’immagine originale contano: l’HAL, la partizione D:, l’FTP interno, i driver I/O selezionati. Ognuno da solo bastava a bloccare l’avvio.
- Registrare tutto: un log con data, ora e risultato di ogni azione ha reso possibile capire che il blocco di settembre era lo stesso guasto di luglio.
Restano aperti alcuni punti: il messaggio 1043 sotto carico, le batterie da cambiare, il driver video e il PC che dopo lo spegnimento resta acceso a batteria. Per quest’ultimo la pista è il driver che stacca le batterie a fine spegnimento: il setup copia il file ma non installa il dispositivo.
Il prossimo passo è la visione: una webcam montata sul polso del robot, per riconoscere un pezzo e calcolarne la posizione rispetto alla base. La calibrazione della camera è già fatta. Per la cinematica ho scritto in C la cinematica diretta e inversa del KR 5 arc, verificata su 20.000 pose casuali.