¿Qué es FOCAS? La API nativa para CNC FANUC

Abril de 2026. En una red de laboratorio aislada, un servidor experimental que emulaba un control FANUC 31i escuchaba peticiones entrantes en el puerto TCP 8193. El propósito resultaba directo: hacer dialogar a la biblioteca cliente oficial de FANUC con una máquina virtualizada sin contar con las bibliotecas dinámicas del fabricante. El servidor envió un paquete de bienvenida ajustado milimétricamente al formato binario de la trama. La biblioteca cliente analizó el mensaje, evaluó las cabeceras internas y cortó la comunicación. En el registro quedó un único código: -16, la constante EW_PROTOCOL.

Este rechazo inicial condensa la primera lección sobre FOCAS: no se trata de un protocolo de comunicaciones genérico, sino de una arquitectura cerrada desarrollada por FANUC. La biblioteca cliente verifica internamente el comportamiento esperado del interlocutor; simular el tráfico en red rara vez basta. En la misma jornada se probó una alternativa técnica: prescindir de la biblioteca propietaria y comunicarse directamente mediante sockets TCP puros. Aquel método dejó al descubierto la mecánica real de la comunicación.

FOCAS (FANUC Open CNC API Specifications) es la familia de interfaces de programación nativas empleadas para acceder a los datos internos del CNC y del PLC (PMC) en controles FANUC. Identificada habitualmente como FOCAS1 y FOCAS2, opera mediante enlaces Ethernet o bus serie óptico de alta velocidad (HSSB). Su funcionamiento se basa en la apertura de un identificador de sesión (handle), sobre el cual se ejecutan todas las funciones de lectura y escritura. A diferencia de iniciativas abiertas como MTConnect, FOCAS es una tecnología propietaria cuyas especificaciones y módulos son distribuidos bajo control del fabricante.^[1][2][3]

FOCAS de un vistazo

Delimitación técnica: qué es y qué no es FOCAS

Equiparar FOCAS con MTConnect induce a severos fallos de diseño en planta. MTConnect constituye un estándar abierto, exclusivamente de lectura y diseñado para interoperar entre marcas diversas. FOCAS, por el contrario, representa un ecosistema cerrado exclusivo de FANUC, con acceso profundo y capacidad de escritura directa en los registros de la máquina. El primero homogeneiza la información de toda una nave; el segundo dialoga con la intimidad electrónica del control. Asimismo, FANUC comercializa el paquete MT-LINK i para monitorización de planta mediante Ethernet y OPC UA; dicha solución conforma un nivel aplicativo superior y no sustituye la API de bajo nivel de FOCAS.^[1][2][6]

FOCAS no se agota en un archivo aislado. Aunque FWLIB32.DLL actúa como pasarela principal, requiere dependencias específicas según el modelo de máquina: FWLIB30i, FWLIB0iD, FWLIB0i, FWLIB16W o FWLIBNCG. Una aplicación cliente puede compilar sin advertencias y fallar de inmediato en planta si no se incorporan las bibliotecas correspondientes a la generación del control numérico. Afirmar que FOCAS está operativo sin precisar la serie y versión de firmware equivale a omitir el dato técnico crítico.^[2][3]

La distribución y uso de estas bibliotecas están reglamentados por acuerdos de licencia comercial. No tratándose de código abierto, cualquier desarrollo industrial debe contemplar en sus presupuestos de integración las autorizaciones formales y las opciones habilitadas en cada control.^[2]

Dos vías de transporte, un descriptor común

FOCAS ofrece dos modalidades de conexión: red Ethernet y bus óptico HSSB. Ethernet emplea sockets TCP estándar, donde el puerto 8193 constituye la convención establecida. El enlace HSSB recurre a tarjetas físicas específicas que garantizan tiempos de respuesta deterministas sin interferir en el tráfico de red de la empresa. En la matriz funcional oficial, cada llamada indica su disponibilidad con los códigos O (ambos medios), E (exclusivo Ethernet) o H (exclusivo HSSB).^[1][2]

El modelo de programación opera mediante descriptores (handles). La función cnc_allclibhndl3 recibe la dirección IP, el puerto de destino y un tiempo de espera, devolviendo un identificador numérico. Todas las operaciones siguientes deben reutilizar dicho descriptor. Mantener abierto el handle durante la adquisición de datos evita sobrecargas por negociaciones sucesivas; sin embargo, obliga a implementar una rutina de recuperación ante cortes de red, pues ejecutar consultas sobre un handle caído provoca fallos continuos no controlados.^[3]

Estructura binaria de las tramas en el cable

El formato binario que circula por el cable ha sido analizado exhaustivamente por proyectos independientes (como pyfanuc) y mediante inspecciones con analizadores de tráfico en planta. Estos datos ilustran el comportamiento real de las tramas sin constituir una especificación contractual de FANUC.^[4][5]

Cada paquete arranca con una cabecera de 10 bytes: una secuencia constante de cuatro bytes A0 A0 A0 A0, seguida de los campos de versión, tipo de trama y longitud de carga útil. Todos los enteros multibyte se codifican en formato big-endian:

Cabecera de trama (10 bytes):
[A0 A0 A0 A0] [versión:u16] [tipo:u16] [longitud:u16]

0x0101 / 0x0102  Apertura de sesión: petición / respuesta
0x0201 / 0x0202  Cierre de sesión: petición / respuesta
0x2101 / 0x2102  Transmisión de datos: petición / respuesta
0x2103           Trama de descarte observada ante discordancias de formato

Dentro de una petición de datos se estructuran subpaquetes de 28 bytes de longitud: tamaño del bloque (frecuentemente 0x001C), tres bytes identificadores de comando y cinco argumentos numéricos de 32 bits. Si la consulta tiene éxito, el control responde confirmando el comando y entregando la carga útil; en caso de fallo, retorna un bloque resumido de 14 bytes con el código de error. Este diseño posibilita solicitar de manera simultánea el estado de la máquina, el programa en curso, las velocidades reales y las alarmas vigentes en un único paquete TCP.^[4]

La tabla refleja con claridad el motivo por el cual FOCAS se considera una interfaz profunda: mediante una única vía es factible sondear parámetros de control, registros del PLC y variables macro que quedan fuera del alcance de los estándares genéricos.

Primer giro: una familia de API, no un protocolo aislado

Tratar a FOCAS como si fuese un simple protocolo de red representa una equivocación habitual. En la capa superior existe un catálogo de funciones escritas en lenguaje C: cnc_statinfo, cnc_absolute, cnc_rdprgnum, cnc_exeprgname, cnc_rdopnlsgnl, cnc_rdmacro o pmc_rdpmcrng. En el nivel inferior se encuentra la trama TCP y las bibliotecas dinámicas adaptadas a cada control.^[1][2]

Por consiguiente, una rutina diseñada para un equipo 30i-B no se comportará necesariamente igual en una unidad 0i-F. La matriz oficial detalla qué llamadas están implementadas en cada medio físico y modelo; la marca X indica expresamente ausencia de compatibilidad. Muchos problemas atribuidos a deficiencias del cableado obedecen a llamadas no soportadas por la versión del control instalado.^[1]

Segundo giro: el riesgo operacional de la escritura remota

La característica más sobresaliente de FOCAS es a su vez su mayor factor de riesgo: la potestad de escribir en el sistema. Es posible modificar compensaciones de herramienta, orígenes de pieza, variables macro, bits del PLC e incluso la hora del reloj. Semejante capacidad no está orientada a la simple monitorización de métricas, sino a tareas de integración robótica y mantenimiento especializado. Un cambio indebido en un offset puede provocar una colisión grave en máquina o inutilizar una pieza de alto valor.^[2]

El acceso de escritura requiere normas estrictas: los clientes con permiso para alterar registros deben operar en un segmento de red independiente, con autenticación reforzada, control estricto de versiones y protocolos de respaldo previos a cualquier cambio, validando siempre los parámetros en entornos de simulación. Las advertencias de seguridad divulgadas por FANUC confirman la necesidad de acotar estrictamente estas conexiones.^[7]

Tercer giro: la barrera de las bibliotecas y dos rutas de integración

Retomemos la anomalía con la que iniciamos el análisis. La biblioteca cliente del fabricante no aceptó la respuesta de nuestro simulador y retornó -16 EW_PROTOCOL. Las inspecciones de tráfico confirman que el código cliente abre dos canales de comunicación concurrentes y comprueba firmas internas específicas. Ello demuestra que conocer la estructura del paquete resulta insuficiente para engañar a la biblioteca oficial.

Esta realidad abre dos alternativas de ingeniería: emplear las bibliotecas propietarias de FANUC o desarrollar un cliente de red propio a nivel de sockets TCP (como realiza pyfanuc). La comunicación directa brinda flexibilidad en plataformas Linux y arquitecturas ARM sin instalar dependencias de Windows, pero carece de certificación del fabricante y puede presentar comportamientos dispares entre distintas series de CNC.^[4][5]

En el diseño de la solución, resolver qué tipo de cliente se implementará resulta prioritario sobre la configuración del puerto de red. La biblioteca oficial ofrece estabilidad y mantenimiento garantizado; los desarrollos socket reducen ataduras pero exigen asumir el mantenimiento ante eventuales desajustes de protocolo. Mezclar ambos esquemas en una misma celda de mecanizado genera fuentes de error innecesarias.

Asimismo, los entornos emulados como NCGuide difieren en ciertos comandos respecto a las máquinas físicas. En nuestros ensayos, CMD_READ_OPNLSGNL (0x61) arrojó un código E6, CMD_READ_MACRO (0x15) ocasionó un rechazo 0x2103 y CMD_READ_PMC (0x02) provocó el cierre abrupto de la conexión. Sin embargo, el número de herramienta activa pudo recuperarse sin problemas en el byte 24 de la respuesta a CMD_READ_MODAL_AUX (0x22). Estas observaciones empíricas deben revalidarse obligatoriamente sobre el hardware real.

Comparativa técnica: ¿FOCAS o MTConnect?

La arquitectura recomendada integra ambas tecnologías de forma sinérgica: un módulo intermedio se enlaza mediante FOCAS a las máquinas FANUC para recopilar variables exhaustivas, y las expone en formato normalizado MTConnect hacia los servidores de planta. Mantener la capa de recolección con permisos de solo lectura para la telemetría general garantiza una operación protegida frente a maniobras no deseadas.^[8]

Siete directrices para la puesta en marcha

1. Verificar la opción Ethernet: FOCAS requiere que la opción de comunicación en red esté habilitada físicamente y soportada por el software del control.
2. Segmentar el acceso al puerto 8193: Restrinja la comunicación exclusivamente al servidor de adquisición mediante reglas estrictas de cortafuegos.
3. Revisar las dependencias de DLL: Asegúrese de que FWLIB32.DLL y las bibliotecas específicas de la serie coincidan en arquitectura (32 o 64 bits) y versión con la CNC.
4. Controlar la vida del descriptor: Mantenga abierto el handle durante las lecturas periódicas y libérelo adecuadamente al cerrar el servicio, programando reconexiones ante cortes de red.
5. Ajustar temporizaciones y frecuencia: No sature el procesador del control con peticiones excesivas; utilice estrategias de espera exponencial ante fallos repetidos.
6. Separar perfiles de lectura y escritura: Las tareas de modificación deben restringirse a operadores acreditados en redes dedicadas y auditadas.
7. Registrar códigos de error: Monitorice de forma centralizada todas las respuestas anómalas de la biblioteca (incluyendo EW_PROTOCOL) para anticipar anomalías operativas.

Conclusión: el dominio técnico radica en saber prescindir de la escritura

El valor de FOCAS no reside en la vasta cantidad de funciones disponibles, sino en la cautela con la que se seleccionan. El mismo descriptor que reporta la coordenada de un eje puede alterar el decalaje de una pieza. Trazar esa línea divisoria constituye una responsabilidad organizativa de primer orden.

¿Operan sus clientes de supervisión FANUC en modalidad estrictamente pasiva? Y si precisa capacidades de escritura, ¿se encuentran definidos con claridad los planes de contingencia y los registros de auditoría correspondientes?

Este artículo forma parte de nuestra serie técnica sobre protocolos de control CNC. Conozca las ventajas del estándar abierto en nuestra guía de MTConnect; analice el transporte físico de datos en nuestro manual técnico sobre RS-232; y explore la física de las señales en el análisis de I2C, SPI y UART.