Protocolo LSV2: El lenguaje de telegramas de Heidenhain

Al analizar una sesión TNC en el nivel físico de la red, los datos se reducen a lo esencial: un encabezado de longitud de cuatro bytes, un código de comando de cuatro caracteres ASCII y el bloque de datos correspondiente. No existen estructuras JSON complejas, esquemas XML extensos ni cabeceras HTTP convencionales. Al adentrarse en los sistemas de control de Heidenhain, esta estructura elemental y directa constituye el protocolo LSV2.

Su sobriedad no debe inducir a engaño. LSV2 es un protocolo de telegramas binarios basado en TCP diseñado para las unidades Heidenhain TNC, orientado a gestionar transferencias de ficheros de programa, monitorizar el estado operativo, registrar cotas de ejes y examinar registros de PLC. Heidenhain no ha divulgado una especificación pública abierta. La comprensión de este mecanismo se ha consolidado mediante inspección de paquetes en red, catalogación de respuestas de error y el análisis del comportamiento de aplicaciones como TNCremo. Este artículo expone los fundamentos de esta comunicación técnica con rigor industrial.^[1][2]

LSV2 de un vistazo

Delimitación técnica de LSV2

LSV2 actúa como el enlace de comunicación básico entre los controles Heidenhain y las redes de planta. Cuando un paquete de escritorio como TNCremo transmite programas de mecanizado, examina directorios o consulta el estado operativo, lo realiza enviando telegramas LSV2 mediante un socket TCP. En el sector suele utilizarse el término «DNC» de forma indistinta; conviene separar con claridad los términos: DNC engloba una arquitectura y una gama de software, mientras que LSV2 es el protocolo de transporte binario subyacente.^[1][6]

Asimismo, identificar LSV2 con MTConnect induciría a error. MTConnect es una norma abierta, exclusivamente de lectura, estructurada en XML o JSON sobre interfaces HTTP REST. LSV2 es un protocolo cerrado y con estado, concebido para Heidenhain, con rutinas de transferencia de archivos y capacidad de escritura activa. MTConnect estandariza el seguimiento global de una fábrica; LSV2 interactúa de forma directa con la memoria de la máquina.^[1]

Cabecera de ocho bytes y comandos de cuatro caracteres

El diseño de tramas en LSV2 destaca por su concisión. Cada mensaje se inicia con una cabecera de ocho bytes: un entero de 32 bits en formato big-endian que detalla la longitud de los datos, sucedido por cuatro caracteres ASCII que representan el comando. Esta longitud computa únicamente la carga posterior y omite el encabezado de comando. Las órdenes mantienen una sintaxis fija de cuatro caracteres: A_LG, R_RI, S_RI, T_OK o T_ER.^[2]

Petición:   [len:u32 BE] [A_LG] [nombre de usuario + 0x00]
Respuesta:  [len:u32 BE] [T_OK] [bloque de datos opcional]

Petición:   [len:u32 BE] [R_RI] [subidentificador:u16 BE]
Respuesta:  [len:u32 BE] [S_RI] [datos de estado retornados]

El establecimiento de sesión contempla dos modalidades: A_LG permite acceder mediante nombre de usuario simple, en tanto que P_LG exige una contraseña. En simuladores y bancos con compatibilidad TNCremoNT se aprecian claves de prueba como PASSWORD o REMOTE; estos valores no deben emplearse en celdas de fabricación real. Una respuesta satisfactoria devuelve T_OK, mientras que un rechazo genera T_ER junto a un código numérico.^[1][2]

En la transferencia de ficheros, LSV2 distingue entre modo ASCII y binario. La modalidad binaria se activa añadiendo el byte 0x01 a continuación del nombre del archivo. Esta diferenciación resulta crítica: enviar ficheros binarios bajo reglas ASCII provocará daños irreversibles en el archivo almacenado en el control. Asimismo, las rutas deben seguir la sintaxis interna del sistema TNC (por ejemplo TNC:\nc_prog\); utilizar rutas locales del sistema operativo anfitrión causará errores inmediatos.^[2]

El registro de incidencias se distribuye por rangos. Según pyLSV2, los números 0 a 19 cubren anomalías de comunicación y transporte, de 20 a 99 fallos sintácticos en telegramas, y de 100 a 200 errores en bloques de ficheros. Al registrarse una respuesta T_ER, anotar el código exacto es imperativo para discernir entre caídas de línea, archivos bloqueados o autorizaciones insuficientes.^[3]

El comando R_RI: sondeo de variables activas

En lugar de enviar un bloque continuo masivo de datos, LSV2 consulta parámetros concretos a través del comando R_RI (Read Running Info). El cliente adjunta un subidentificador de 16 bits en formato big-endian, al que la máquina contesta con una trama S_RI. Los cuatro subidentificadores más relevantes en planta son:^[1][2]

En el subidentificador 25 interviene una regla de escala decisiva: el entero bruto 10000 equivale al 100%. El control transmite la posición del potenciómetro en centésimas de porcentaje. Tratar este dato como un porcentaje directo introduce un error de visualización de dos órdenes de magnitud. Las librerías procesan este campo de diferente forma: algunas normalizan a un valor unitario (1.0) y otras proporcionan porcentaje directo (100.0). Esta conversión debe definirse contractualmente antes del despliegue.^[2]

El subidentificador 24 requiere atención en su procesamiento: el texto de la ruta comienza tras el byte 4 y varios programas pueden aparecer separados por caracteres nulos (0x00). Aunque el programa principal suele ocupar el primer espacio, el orden puede variar según la versión. El software de lectura debe interpretar estos delimitadores sin provocar fallos de ejecución.^[2]

Roles de sesión: niveles de autorización

El control de acceso en LSV2 no se limita al mero enlace del socket. Durante el inicio de sesión, el cliente declara un rol que determina las instrucciones permitidas por el control. pyLSV2 detalla roles como INSPECT, FILE, DNC, MONITOR, DIAGNOSTICS, PLCDEBUG, SCOPE y DATA. El rol INSPECT posibilita la lectura de estados y posiciones; FILE gestiona ficheros; DNC efectúa el seguimiento de programa; y PLCDEBUG brinda acceso directo a la memoria del PLC.^[3]

Estos perfiles deben emplearse como barreras de seguridad. Un software de adquisición pasiva debe solicitar únicamente INSPECT o MONITOR. Asignar PLCDEBUG a tareas de monitorización amplía innecesariamente la superficie de riesgo. La asignación de roles constituye una directriz clave de seguridad operativa.^[3]

Primer giro: estructura ligera, especificación reservada

La concisa cabecera de ocho bytes de LSV2 incita con frecuencia a subestimar su grado de dificultad. El desafío real no radica en el análisis de las tramas, sino en resolver el significado de variables no publicadas: verificar qué subidentificador corresponde a cada parámetro, comprobar la compatibilidad de órdenes entre versiones y comprender los códigos de retorno. Ante la ausencia de un estándar abierto de Heidenhain, los desarrolladores independientes han debido deducir estas reglas empíricamente.^[1][2]

Con miras a una implantación en taller, es necesario distinguir entre estudiar el protocolo y desplegarlo en producción activa. El paquete pyLSV2, distribuido bajo licencia MIT, incluye en su archivo README una advertencia expresa desaconsejando su empleo en máquinas en producción. Las actualizaciones de firmware de los fabricantes pueden alterar los tiempos internos o invalidar secuencias de telegramas previamente aceptadas.^[1]

Segundo giro: el control de acceso en dos fases

La autorización se verifica en dos planos separados. El primero es el rol escogido durante la autenticación; el segundo, mucho más estricto, reside en las opciones licenciadas en la máquina. En particular, la extracción de estados avanzados requiere la activación de la opción DNC Option 18 mediante la clave SIK. Si esta opción no se encuentra activada, la máquina acepta la sesión inicial pero deniega las peticiones de estado avanzadas con fallos de permiso.^[6]

La carencia de la Option 18 no bloquea por completo la extracción de información: es factible monitorizar variables básicas leyendo directamente las marcas de memoria o registros del autómata (PLC). Si bien este procedimiento precisa conocer la tabla de asignación configurada por el constructor de la máquina, ofrece una alternativa funcional en máquinas veteranas sin requerir costosas ampliaciones de software. Reconocer la diferencia entre conectar al puerto y disponer de permisos de lectura es un principio fundamental en la integración de Heidenhain.^[6]

Tercer giro: disparidad entre familias y configuración de puertos

Presentar a LSV2 como una solución homogénea oculta diferencias apreciables entre generaciones de control. Entre iTNC 530, TNC 640, TNC7, CNCpilot 640 y MillPlus IT, las instrucciones soportadas, los tiempos de respuesta y los métodos de transporte difieren de manera sustancial. Las unidades contemporáneas tienden a canalizar las tramas mediante túneles SSH cifrados (puerto 22), mientras que los equipos anteriores responden directamente por el puerto TCP 19000.^[1][5]

A ello se añaden los puertos utilizados por los entornos propietarios del fabricante. En instalaciones DNC con controles TNC640 se han documentado perfiles vinculados al puerto 19003, mientras que LSV2 puro permanecía en el 19000. El puerto 19003 responde a la arquitectura COM de Heidenhain y no debe extrapolarse como un puerto general. Las asignaciones deben cotejarse individualmente.

Asimismo, la administración de ficheros muestra comportamientos variados: un modelo puede admitir transferencias fluidas mientras otro exige autenticaciones específicas. Mencionar que un equipo «soporta LSV2» carece de rigor técnico si no se precisa el modelo exacto y la versión de software instalada.

Matriz comparativa: LSV2, DNC COM y MTConnect

La adopción de cada tecnología debe responder a las necesidades funcionales del taller. Si se pretende distribuir ficheros de mecanizado, MTConnect resulta inadecuado. En cambio, si solo se requiere registrar tiempos de parada, habilitar las opciones de escritura de LSV2 introduce exposiciones de seguridad innecesarias.

Siete pautas para la implantación operativa

1. Habilitar la comunicación externa en el CNC: La conexión será declinada si no se configuran previamente los permisos y contraseñas correspondientes en el panel TNC.
2. Confirmar puerto y modo de transporte: Efectúe las pruebas iniciales en TCP 19000; si se trata de modelos modernos TNC640 o TNC7, prevea túneles SSH por el puerto 22.
3. Asignar el rol de menor privilegio: Limite la supervisión a INSPECT o MONITOR; restrinja FILE a la gestión documental y aísle completamente PLCDEBUG.
4. Comprobar el estado de Option 18: Verifique la licencia en la llave SIK; si no está disponible, plantee la lectura mediante marcas del autómata PLC.
5. Unificar los accesos en un único colector: Múltiples conexiones simultáneas desestabilizan las versiones de firmware más antiguas; consolide las consultas en un nodo intermedio.
6. Formalizar el factor de escala: Especifique en la documentación técnica el cálculo del potenciómetro (10000 = 100%) para evitar lecturas distorsionadas en los paneles de control.
7. Registrar las respuestas de error de telegrama: Monitorice de forma continua los códigos T_ER con sus identificadores para distinguir incidencias de red frente a denegaciones de acceso.

Conclusión: la brevedad del formato no elimina la exigencia técnica

El esquema central de LSV2 se estructura en ocho bytes, pero su aprovechamiento eficaz exige coordinar privilegios de sesión, habilitaciones de software, variaciones de hardware y códigos de fallo. Asumir que el protocolo es elemental por contar con un encabezado reducido equivale a examinar el picaporte de una puerta sin considerar la complejidad del edificio que custodia.

¿Qué nivel de rol tienen asignado sus aplicaciones de supervisión en sus máquinas TNC? Y en los controles sin Option 18, ¿su método de lectura mediante registros de PLC responde a un plan estructurado o a una solución coyuntural?

Este artículo representa la tercera entrega de nuestra serie sobre protocolos de control CNC. Para consultar los fundamentos del transporte serie físico, explore nuestro manual técnico sobre RS-232; los principios de las señales de bajo nivel se detallan en el análisis de I2C, SPI y UART.