Referencia de comandos serie RS-232 para lentes zoom motorizados POMEAS
Los lentes zoom motorizados POMEAS se controlan por RS-232 (o Ethernet) mediante un protocolo ASCII compacto de cinco comandos. Cada comando consta de tres bytes: la letra X, una letra de comando y un retorno de carro 0x0D. El controlador responde a las consultas de posición y recorrido con una trama de nueve bytes, y reporta la finalización del movimiento con el byte de estado único 0x55. Esta referencia documenta el protocolo tal como está implementado, incluidas las dos fórmulas de conversión y el comportamiento que más suele sorprender a los integradores: el controlador deja de responder mientras el motor se mueve.
Está escrito para ingenieros que conectan un lente zoom motorizado a un PLC, un controlador de movimiento, una computadora de placa única o un host Linux — situaciones en las que el SDK de Windows no está disponible y la secuencia de bytes en bruto es la única opción.
Datos clave a simple vista
| Elemento | Valor |
|---|
| Comandos | 5 (XH, XG, XZ, XM, XN) |
| Terminador de trama | 0x0D (CR) — en comandos y respuestas |
| Configuración serie | 9600 baudios, 8 bits de datos, sin paridad |
| Puerto Ethernet | 4196 |
| Indicador de parada | 0x55 — cualquier otro valor, o un tiempo de espera de lectura, significa "aún en movimiento" |
| Fórmula de recorrido | maxLength = (readData − 750) × 1.3 |
| Fórmula de posición | pos = (readData − 500) × 1.3 |
| Guía de sondeo | Esperar al menos 50 ms entre consultas de estado; usar un tiempo de espera global de 10 s o más |
Configuración de puerto y requisitos de cableado previos
| Parámetro | Valor | Notas |
|---|
| Capa física | RS-232 (directo o vía USB-a-RS-232) o Ethernet | El controlador admite uno u otro — no ambos a la vez |
| Velocidad en baudios | 9600 | El documento de protocolo y la documentación de la API de la tarjeta de control coinciden en este valor |
| Bits de datos | 8 | — |
| Paridad | Ninguna | — |
| Puerto TCP | 4196 | Se usa al conectar por la interfaz de red |
| Terminador | 0x0D | En ambas direcciones |
Antes de que cualquiera de esto importe, el cableado debe ser correcto: conecte y bloquee el cable del motor y el cable RS-232 antes de aplicar energía. Conectar en caliente el cable del motor mientras el controlador está energizado es la acción más destructiva en campo — puede dañar permanentemente el motor. Si su cable del motor debe superar los 5 m, pida el cable largo de fábrica en lugar de empalmar varios cortos, porque los cables empalmados o hechos a medida no cumplen con los requisitos de impedancia y blindaje.
Los cinco comandos
Cada comando tiene la forma 'X' + <letra de comando> + 0x0D.
| # | Función | ASCII | HEX | Respuesta |
|---|
| 1 | Regreso al origen (home) | X H CR | 0x58 0x48 0x0D | Ninguna |
| 2 | Mover a una posición de pulso objetivo | X G + 6 dígitos HEX + CR | 0x58 0x47 … 0x0D | Ninguna |
| 3 | Consultar estado de movimiento | X Z CR | 0x58 0x5A 0x0D | 1 byte |
| 4 | Leer recorrido total (pulso máximo) | X M CR | 0x58 0x4D 0x0D | 9 bytes |
| 5 | Leer posición actual | X N CR | 0x58 0x4E 0x0D | 9 bytes |
1. Regreso al origen — XH
TX: 0x58 0x48 0x0D # 'X' 'H' CR
El lente regresa a su origen mecánico. Observe que el lente también realiza este reinicio automáticamente cada vez que se enciende, y la inicialización tarda 25–35 segundos, durante los cuales el lente no acepta ningún comando. Una aplicación host debe por tanto esperar al menos 35 segundos después del encendido antes de abrir el puerto.
2. Mover a una posición objetivo — XG
La carga útil se formatea con la cadena de formato C "%C%C%6X%C": la letra X, la letra G, un número hexadecimal de seis dígitos rellenado a la izquierda con caracteres de espacio (0x20) cuando es menor de seis dígitos, y un terminador 0x0D.
| Pulso objetivo | Caracteres ASCII | Secuencia de bytes |
|---|
| 100 | X G ␠␠␠␠ 6 4 CR | 0x58 0x47 0x20 0x20 0x20 0x20 0x36 0x34 0x0D |
| 1000 | X G ␠␠␠ 3 E 8 CR | 0x58 0x47 0x20 0x20 0x20 0x33 0x45 0x38 0x0D |
| 5000 | X G ␠␠ 1 3 8 8 CR | 0x58 0x47 0x20 0x20 0x31 0x33 0x38 0x38 0x0D |
| 10000 | X G ␠␠ 2 7 1 0 CR | 0x58 0x47 0x20 0x20 0x32 0x37 0x31 0x30 0x0D |
Comportamiento importante: si la posición solicitada coincide con la posición actual, el lente no se mueve y no reporta error. Una aplicación host nunca debe por tanto tratar "comando enviado" como prueba de que el enlace funciona. Leer la posición de vuelta es la sonda de enlace fiable.
// Move to an absolute pulse position
int moveTo(int fd, long pulse) {
char buf[16];
// "%C%C%6X%C" - six hex digits, space-padded, CR-terminated
int n = snprintf(buf, sizeof(buf), "%c%c%6lX%c", 'X', 'G', pulse, '\r');
return write(fd, buf, n) == n ? 0 : -1;
}
3. Consultar estado de movimiento — XZ
TX: 0x58 0x5A 0x0D
wait 20 ms
RX: 1 byte
| Respuesta | Significado |
|---|
0x55 | Movimiento terminado — el lente se ha detenido |
| Cualquier otro valor | Aún en movimiento |
| Sin datos en absoluto | También se trata como "aún en movimiento" |
Este es el detalle de comportamiento más importante de todo el protocolo, y está documentado por el fabricante: mientras la tarjeta de control acciona el motor, las comunicaciones se suspenden. El enlace serie o de red puede no devolver nada en absoluto durante un movimiento de zoom.
La consecuencia práctica es que el bucle de sondeo debe construirse en torno a reintentos en lugar de en torno a la detección de fallos. La implementación de referencia es:
- Enviar
XZ.
- Esperar al menos 20 ms.
- Leer un byte.
- Si la lectura agota el tiempo, o el byte no es
0x55, espere y reintente — no declare un fallo.
El propio diagrama de flujo de la API del fabricante usa una espera de 50 ms antes de cada consulta de estado y un tiempo de espera global de 10 segundos o más. Solo cuando ese tiempo de espera global expira sin una respuesta válida debe el host concluir que la conexión del lente ha fallado.
// Wait for motion to complete: 50 ms per poll, 10 s overall timeout
int waitStop(int fd, int timeout_ms) {
int waited = 0;
char c;
while (waited < timeout_ms) {
usleep(50 * 1000); // reference flow chart: wait 50 ms or more
write(fd, "XZ\r", 3); // 0x58 0x5A 0x0D
usleep(20 * 1000); // protocol: wait 20 ms before reading
if (read(fd, &c, 1) == 1 && (unsigned char)c == 0x55)
return 0; // stopped
waited += 70;
}
return -1; // connection or motion fault
}
4. Leer recorrido total — XM
TX: 0x58 0x4D 0x0D
wait 20 ms
RX: 9 bytes
| Byte | Contenido |
|---|
| 1 | 0x58 (fijo) |
| 2 | vacío |
| 3–7 | Datos de recorrido — cinco bytes, analizados como entero con "%5X" en readData |
| 8 | 0x0D |
| 9 | vacío |
sscanf(tbuffer + 2, "%5X", &readData);
maxLength = (readData - 750) * 1.3;
Ejemplo resuelto de la documentación del fabricante: una respuesta de 0x58 -- -- -- '2' '7' '1' '0' 0x0D -- da readData = 10000, por lo que maxLength = (10000 − 750) × 1.3 = 12025.
5. Leer posición actual — XN
TX: 0x58 0x4E 0x0D
wait 20 ms
RX: 9 bytes (identical structure to XM)
sscanf(tbuffer + 2, "%5X", &readData);
pos = (readData - 500) * 1.3;
Ejemplo resuelto: readData = 10000 da pos = (10000 − 500) × 1.3 = 12350.
Secuencia de interacción de referencia
(1) XH return to origin -> poll XZ until stopped
(2) XM read total travel -> validates the link, yields maxLength
(3) XG <6 HEX> move to target position -> poll XZ until stopped
(4) XN read current position -> compare with the target (closed loop)
Dos puntos hacen que esta secuencia funcione de forma fiable:
- El paso 2 es la única sonda de enlace fiable. El paso 3 no puede usarse para ese propósito, porque una solicitud de movimiento igual a la posición actual no produce movimiento ni error.
- El paso 4 cierra el bucle. Solo cuando el valor leído de vuelta coincide con el valor solicitado puede el host confiar en que el cambio de aumento realmente surtió efecto.
Todo el protocolo es estrictamente serial en semántica — comando → movimiento → lectura de estado de vuelta → siguiente comando. No admite emitir comandos de forma concurrente al mismo lente.
Este protocolo solo proporciona lectura de posición de vuelta. No define ni garantiza ninguna cifra de repetibilidad. La metodología de prueba se trata en el artículo complementario sobre mapeo de aumento y pulsos; cualquier afirmación de precisión numérica debe provenir de sus propias mediciones bajo sus propias condiciones.
Conceptos erróneos comunes
«Lente zoom motorizado RS-232» significa una sola cosa
Significa dos cosas muy diferentes, y elegir el modelo equivocado es un error común y costoso.
| Forma | Marcado de modelo | Capacidad real |
|---|
| Retroalimentación pasiva de aumento | Sufijo DS9 o DS6, p. ej. PMS-LZ-63100DS9 | El zoom sigue siendo manual. RS-232 solo emite el aumento actual o la posición de tope. No puede aceptar comandos. |
| Control motorizado activo | Código de tipo de zoom 04, 05, 09 o 10, p. ej. PMS-LZ-650104 | Se aceptan los cinco comandos. RS-232 acciona activamente el aumento. |
Verifique el sufijo del modelo antes de pedir. Un lente DS9 se puede leer pero no mandar.
«Las comunicaciones se cayeron durante el zoom — el enlace está roto»
No es un fallo. La tarjeta de control suspende las comunicaciones mientras acciona el motor. Este es un comportamiento diseñado. Manéjelo con tiempo de espera y reintento, no con una alarma de fallo ni un reinicio.
«Enviar un comando siempre produce movimiento»
Si el objetivo coincide con la posición actual, el lente permanece quieto y tiene éxito en silencio. O bien rastree la posición actual en la aplicación host, o léala de vuelta con XN antes de cada movimiento.
«Cualquier valor de posición puede mandarse»
Las posiciones de pulso son específicas de cada lente. Provienen de la tabla de pulsos por modelo suministrada con el SDK, y el mismo aumento se mapea a diferentes conteos de pulso en diferentes modelos y diferentes tipos de motor. Lea primero el recorrido total con XM y confirme que el objetivo está dentro del rango válido.
¿Comandos serie en bruto o el SDK?
| Comando de protocolo | API SDK heredada | SDK V4.4.7 |
|---|
XH origen | MoveHome(Motor) | GoHome |
XG mover | MoveGoto(Motor, long dest) | MoveTo(pulse) |
XZ estado | MoveStatus(Motor) → 0 en movimiento / 1 inactivo / 2 error | GetStatus |
XM recorrido | MoveMaxLength(Motor) | GetMaxPos |
XN posición | MovePos(Motor) | GetPos |
- Integrar con un PLC, controlador de movimiento o microcontrolador — use los comandos en bruto de arriba. No se requiere DLL, y el protocolo es ASCII puro sin dependencia de plataforma, por lo que también funciona en Linux y macOS.
- Desarrollar en Windows en C++ o C# — use el SDK, que maneja por usted el ensamblaje de tramas, los reintentos y el caso de doble motor.
No mezcle los dos enfoques en el mismo enlace. Ambos acceden a los mismos registros de hardware, y mezclarlos — particularmente alrededor de la referencia de origen — produce un estado inconsistente.
Preguntas frecuentes
¿Qué velocidad en baudios usan los lentes zoom motorizados POMEAS?
9600 baudios, 8 bits de datos, sin paridad. La opción Ethernet usa el puerto TCP 4196.
¿Por qué no puedo leer nada del lente mientras hace zoom?
Porque la tarjeta de control suspende deliberadamente las comunicaciones mientras acciona el motor. Reintente su consulta de estado con un tiempo de espera en lugar de tratar el silencio como un fallo.
¿Cómo sé si un lente admite control RS-232 activo?
Verifique el código de tipo de zoom en el número de modelo. Los códigos 04, 05, 09 y 10 denotan tipos motorizados. Un sufijo DS9 o DS6 denota solo retroalimentación pasiva, donde el zoom permanece manual.
¿Puedo conectar el lente directamente a un PLC?
Sí. El conjunto de comandos son cinco cadenas ASCII, por lo que un PLC con un puerto serie libre puede formatearlas y enviarlas directamente. El programa del lado del PLC es suyo para escribir; POMEAS suministra la definición del protocolo, no un bloque de funciones PLC.
¿Necesito la DLL para controlar el lente?
No. La DLL es una capa de conveniencia de Windows sobre el mismo protocolo a nivel de bytes. Cualquier plataforma que pueda abrir un puerto serie o un socket TCP puede controlar el lente.
Lecturas recomendadas
Productos relacionados