¿Qué es Heidenhain DNC? Acceso remoto y arquitectura COM

Acceda al modo de programación en un control Heidenhain TNC contemporáneo, abra el menú MOD e introduzca el código numérico SIK: en la pantalla se muestra una casilla de selección rotulada HEIDENHAIN DNC. Esta sencilla opción gráfica representa el primer filtro de control de lo que en el ecosistema de Heidenhain se denomina «DNC». Si permanece inactiva, la máquina opera de forma habitual y ejecuta piezas sin problemas; no obstante, la CNC declina atender las consultas avanzadas de monitorización recibidas a través de la red corporativa.^[1]

En consecuencia, «Heidenhain DNC» no hace referencia a un protocolo de comunicaciones aislado. Describe un conjunto estructurado que engloba una opción de licencia en la máquina, una colección de librerías Microsoft COM, utilidades de línea de comandos (como TNCcmdPlus) y diversos servicios residentes en el control numérico. Este análisis técnico desglosa este ecosistema: identificando las funciones que exigen licencia, cómo se canalizan los datos mediante interfaces COM, en qué puntos la arquitectura enlaza con sockets LSV2 puros y cómo asegurar una operación protegida en planta.^[1][2]

Heidenhain DNC de un vistazo

Delimitación técnica: solución de software frente a protocolo

En el sector fabril, el concepto «DNC» (Direct Numerical Control) identificaba la alimentación ininterrumpida de instrucciones numéricas desde ordenadores centrales hacia máquinas sin lector de cinta. En la terminología de Heidenhain, DNC designa una plataforma de integración que facilita la distribución de programas de mecanizado, la monitorización operativa y el control remoto de ciclos. Esta plataforma aglutina licencias comerciales, librerías COM para Windows, herramientas de usuario y módulos servidores en la máquina. Identificar la palabra «DNC» con un formato de paquete de red da lugar a confusiones conceptuales.^[1]

Es indispensable diferenciar DNC de LSV2: LSV2 es el protocolo de telegramas binarios estructurado en ocho bytes que opera sobre el socket TCP. Heidenhain DNC es el paquete de software comercial que gestiona, licencia y facilita el consumo de esas capacidades en sistemas industriales. De igual modo, DNC no puede equipararse con MTConnect: este último es un estándar abierto y pasivo basado en XML/REST, en tanto que Heidenhain DNC es una solución propietaria, activa y con control de escritura en la máquina.^[1][3]

Primer nivel: comprobación de licencia SIK y permisos en consola

La validación de derechos se inicia en el propio pupitre de la CNC. En modo de programación, el especialista accede al menú MOD, introduce la clave SIK y consulta la relación de opciones. Allí se encuentra la casilla HEIDENHAIN DNC. Si la Option 18 no ha sido adquirida o está desactivada, el control numérico descarta de forma categórica las peticiones de telemetría de alto nivel: la conexión por socket se formaliza con normalidad, pero las peticiones sobre programas en ejecución, correctores o alarmas generan errores de denegación de acceso.^[1]

El segundo control corresponde a la configuración de la máquina: el parámetro EXTERNAL ACCESS debe encontrarse habilitado. En plantas con normativas estrictas de seguridad, cualquier solicitud de enlace requiere adicionalmente una aprobación expresa del operario en la pantalla TNC. Heidenhain DNC no responde a un modelo de conexión desasistida inmediata; licencias, parámetros de máquina y validaciones en planta forman una cadena inseparable.^[1]

Segundo nivel: interfaces COM bajo entorno Windows

En equipos con sistema operativo Windows, Heidenhain DNC articula sus funciones mediante componentes COM. Las aplicaciones inicializan un objeto principal JHMachine, se comunican con la IP de la máquina y enlazan con la interfaz requerida para su tarea. El conjunto de herramientas contempla una estructura modular:

La interfaz JHAutomatic dispone de amplias atribuciones: no solo reporta la posición de los potenciómetros, sino que puede ordenar al control la carga y el arranque de un mecanizado. Transmite estados operativos minuciosos como DNC_STATE_MACHINE_IS_AVAILABLE, DNC_STATE_DNC_IS_STOPPED, DNC_STATE_WAITING_PERMISSION y DNC_STATE_NO_PERMISSION. Los sistemas de monitorización deben tratar estos estados de forma pormenorizada y no reducir el diagnóstico a la mera comprobación del socket.

Asimismo, la consulta mediante JHDataAccess precisa seleccionar un modo específico: TABLEDATAACCESS, PLCDATAACCESS o CFGDATAACCESS, cada uno condicionado a perfiles de autenticación y claves particulares. Que la sesión figure como activa no garantiza que los registros requeridos estén disponibles.

Tercer nivel: transporte de red y vinculación de puertos

Bajo la arquitectura COM, las comunicaciones transitan por diversos canales. La herramienta de comandos TNCcmdPlus establece la comunicación mediante el puerto TCP 19000. Por el contrario, el cliente Heidenhain DNC COM administra sus perfiles de forma independiente, habiéndose observado el puerto 19003 en máquinas TNC640 en entornos de producción.^[2][3]

Ambos puertos responden a propósitos distintos: el 19000 es el puerto convencional del protocolo LSV2 directo. El 19003 corresponde al servicio de abstracción COM del entorno DNC de Heidenhain y no representa un canal universal para LSV2. Los puertos pueden diferir según la versión del software y la generación de la CNC.^[2]

La distribución automatizada de ficheros exige precauciones operativas severas. Una transferencia defectuosa provocada por caídas de red puede dejar un programa incompleto en la memoria de la máquina, con el riesgo de que un operario lo ejecute de forma inadvertida. Los flujos fiables deben cargar los ficheros en directorios provisionales, comprobar su integridad mediante códigos hash y consolidarlos en la ruta de trabajo solo tras verificar su coherencia.

Primer giro: familia de software multiactivo, no un archivo aislado

Al desglosar un paquete de Heidenhain DNC (como la distribución 1.7.1), se encuentra una gama de módulos de servicio especializados según la familia: CNC4290, iTNC, MillPlus y NCKern. Heidenhain provee pasarelas específicas bajo el mismo paraguas comercial de DNC para dar soporte a cada variante.

El primer análisis de integración debe determinar qué generación de control está presente y qué versión exacta del paquete DNC le corresponde. Un sistema iTNC 530 utiliza librerías de conexión distintas a las requeridas por una TNC 640 o TNC7. Por otra parte, las bibliotecas COM de 32 bits no pueden vincularse de manera directa en procesos de 64 bits sin incorporar adaptadores o servicios puente intermedios.

Segundo giro: enlazar al puerto no asegura la lectura

Uno de los equívocos más usuales en planta es considerar que un saludo TCP exitoso confirma la viabilidad del proyecto. Si la Option 18 no está activa o se carece de permisos en pantalla, la conexión persiste pero las consultas devuelven respuestas vacías o errores de protección. Los paneles que registran un estado «conectado» basándose únicamente en la apertura del puerto inducen a una falsa seguridad.^[1]

Ante la falta de la Option 18, existen vías alternativas viables: los parámetros básicos pueden capturarse interrogando de manera directa las marcas de memoria o registros del autómata PLC. Aunque este método precisa disponer de la tabla de direcciones del fabricante y ofrece un volumen de información más acotado, constituye una vía eficaz para incorporar máquinas veteranas sin incurrir en costes de actualización de software.^[1]

Tercer giro: tres rutas de integración

Para comunicar con una máquina Heidenhain existen tres enfoques técnicos: primero, recurrir al paquete homologado DNC COM (estable y verificado, pero dependiente de Windows) ; segundo, entablar comunicación directa por sockets LSV2 (ágil y ejecutable en Linux, pero dependiente de especificaciones no oficiales) ; tercero, procesar las páginas web internas de diagnóstico en equipos antiguos (solución precaria, pero funcional en máquinas antiguas sin opciones).^[2][3]

Un proyecto bien diseñado no mezcla estas alternativas sin orden: define una estrategia prioritaria para cada familia de máquinas y mantiene las demás como opciones de respaldo documentadas.

Comparativa técnica: DNC COM, Raw LSV2 y MTConnect

Siete directrices para la puesta en servicio

1. Comprobar la Option 18: Verificar la disponibilidad de HEIDENHAIN DNC en el menú SIK antes de escribir código.
2. Habilitar permisos en la CNC: Activar EXTERNAL ACCESS y prever la intervención del operador en los avisos de conexión.
3. Segregar perfiles de acceso: Asignar credenciales independientes para tareas de consulta, transferencia de programas y control remoto.
4. Validar versiones de software: Cotejar la compatibilidad entre el paquete DNC y el firmware del control (atendiendo a arquitecturas de 32/64 bits).
5. Registrar la asignación de puertos: Diferenciar claramente los roles de TCP 19000 (LSV2), TCP 19003 (servicio COM) y SSH 22.
6. Proteger el enlace de red: Desplegar las pasarelas DNC en redes industriales aisladas de los accesos de oficina.
7. Verificar la integridad de los ficheros: Almacenar inicialmente los programas en carpetas temporales y cotejar hashes antes de su ejecución.

Conclusión: abrir la conexión no implica disponer de autorización

Establecer un enlace de red con un control Heidenhain TNC constituye solo el paso inicial. La verdadera tarea de ingeniería comprende coordinar el licenciamiento, seleccionar las interfaces adecuadas y administrar las autorizaciones del operador. Un mismo equipo puede habilitar la lectura de parámetros a un servidor mientras deniega la carga de ficheros a otro; esta delimitación depende de la configuración del software y de las políticas de taller.

¿Dispone su parque de máquinas TNC de la Option 18 activada, o recurre a lecturas mediante marcas de PLC? ¿Y cuentan sus rutinas de distribución de ficheros con comprobaciones para evitar la ejecución de programas incompletos?

Este artículo forma parte de nuestra serie técnica sobre protocolos de control CNC. Para consultar los fundamentos de los enlaces serie, explore nuestro manual técnico sobre RS-232; los aspectos físicos de las señales se detallan en el análisis de I2C, SPI y UART.