Un KR C2 edition05 con tarjeta PROFINET CP 1616. Se sustituye el disco duro, se reinstala el driver, y la red PROFINET no levanta. Todos los indicadores del lado robot decían que ahí estaba todo bien. Y tenían razón. El problema es que eso me mandó a buscar al sitio equivocado.
El síntoma
La célula: la CP 1616 del KRC2 va como IO-device colgando del PLC en TIA Portal, con dos áreas de transferencia de 100 bytes —salidas del PLC hacia el robot, entradas del PLC desde el robot—. Solo señales digitales.
Tras el cambio de disco:
- LED BF de la CP 1616 parpadeando.
- La CP 1616 no aparecía en la lista de nodos accesibles de la red.
Los pasos que di
Primero, comprobar lo que ya estaba hecho. El driver de PROFINET estaba instalado en el disco nuevo. El IOSYS.INI tenía su sección [PNET] activa con el mapeo de entradas y salidas. Y el pnioDrv.ini declaraba el nombre de dispositivo, coincidiendo con el del proyecto de TIA Portal. Al no haber señales analógicas en esta célula, las secciones de analógicas no hacían falta.
Todo correcto. Y la red seguía sin levantar.
Segundo, un aviso que me costó tiempo: el manual que circula para esta combinación es bastante anterior al software que llevaba instalado la máquina. No todo lo que dice aplica. Antes de seguir un procedimiento al pie de la letra, conviene comprobar que corresponde a lo que tienes delante y no a una versión de hace unos años.
Tercero, preguntarle al driver. Con ENABLEDEVICE=1, la salida de pnioShow:
EnableController 0
EnableDevice 1
DriverState 1
DeviceState 0
PNIO Mode = OFFLINE
DaemonState 0
Num of SubMods 0
Traducido: el driver está cargado y el modo device habilitado, pero el dispositivo no tiene estado, no hay submódulos y la pila está offline. Eso es lo que se ve cuando nadie ha llegado a establecer la relación de aplicación con la tarjeta.
Cuarto, reconfigurar el driver mirando lo que dice por Telnet. Y ahí la tarjeta respondía, y respondía bien:
SAME CP detected
register application success
PNIODRV Device part waits for configuration from upper controller
PNIODRV DevStart ok
Quinto, comparar contra el backup. Firmware y s7prj de la tarjeta idénticos a los de la copia. Y en el Administrador de dispositivos, la tarjeta reconocida bajo Realtime OS Devices.
Sexto, irme al otro extremo. Todo lo anterior dice lo mismo: el lado robot arranca correctamente. Era verdad. Así que me fui al PLC y a la red a buscar el problema allí. La frase que más me despistó fue justamente waits for configuration from upper controller, porque parece señalar con el dedo al controlador.
Aquí es donde se me fue el tiempo.
La llamada
En algún punto de todo esto hubo también ayuda telefónica por parte del fabricante. Y quiero mencionarlo porque en estas averías se tiende a contar solo la parte heroica.
Hablar el problema en voz alta con alguien que conoce el equipo tiene un valor que no está en ningún manual: te obliga a ordenar lo que has hecho, a decir en alto lo que has descartado y por qué, y a escuchar tus propias suposiciones. Muchas veces es ahí, explicándolo, cuando te oyes decir la frase que no te habías cuestionado.
El dato que no encajaba
Había una cosa que no cuadraba con mi teoría, y la tenía desde el primer minuto: la CP 1616 no aparecía como nodo accesible.
Si un dispositivo no contesta ni al listado de nodos, el problema no es que el controlador no le esté hablando. Es que no hay nadie con quien hablar.
La solución
Descargar la configuración hardware del proyecto de TIA Portal en la propia CP 1616 del robot, y después hacer un arranque en frío del robot.
Con eso funcionó.
Qué me llevo
1. La CP 1616 guarda configuración propia. No vive solo en el disco duro del KRC ni solo en el proyecto del PLC: la tarjeta tiene su parte. Reinstalar el driver en un disco nuevo deja el lado software impecable y no toca eso. «El driver arranca bien» y «la tarjeta está configurada» son dos afirmaciones distintas, y yo las traté como si fueran la misma.
2. Un dispositivo que no aparece en nodos accesibles manda sobre cualquier otro indicio. Es el dato más barato de obtener y el que más acota. Lo tenía desde el principio y le hice menos caso que a los logs del driver, porque los logs eran más vistosos y daban sensación de progreso. Los logs te cuentan lo que hace el software; el listado de nodos te cuenta lo que pasa en el cable.
3. Tras tocar la configuración de la tarjeta, arranque en frío. No un reinicio normal.
4. Cuando cambies el disco de un KRC2, la lista de comprobación no termina en el driver. Termina cuando la tarjeta responde en la red.
5. Llamar no es rendirse. Con la máquina parada, media hora de teléfono con quien conoce el equipo sale más barata que media jornada dándole vueltas solo.
Y una última, por honestidad: no puedo asegurarte al cien por cien qué estaba exactamente mal dentro de la configuración de la tarjeta. No me paré a diseccionarlo con la máquina parada y el cliente esperando, y creo que cualquiera habría hecho lo mismo. Lo que sí sé es qué la devolvió a la vida, y para quien esté ahora mismo mirando un BF parpadeando, eso vale más que una explicación bonita.
Este artículo describe una intervención propia. Se han omitido el nombre y la ubicación del cliente. Las salidas de diagnóstico son del driver y de las herramientas del fabricante, sin datos de proceso.
Ovi — SSERAC. Automatización industrial: programación de PLC, robots KUKA y FANUC, redes industriales y puestas en marcha. Comunidad Valenciana y resto de España.
