c# - examples - microsoft pos for.net sdk download
C#SerialPort-emular el teclado pos (2)
Estamos tratando de emular un teclado POS para integrar una aplicación con una aplicación de punto de venta existente.
Nos encontramos con este software: Virtual Serial Port Kit
Básicamente, crea un par de puerto serie virtual para que el envío de datos a COM1 pueda salir de COM4 y viceversa. Esto permite que nuestra aplicación envíe datos a través de COM4 para que aparezca en la aplicación POS que está hablando con un teclado en COM1.
Muy ingenioso, pero parece que hay algún tipo de señalización que no podemos replicar con la clase .Net System.IO.Ports.SerialPort ...
Por lo que podemos decir de los programas de monitoreo de puertos en serie, así es como funciona la secuencia de arranque:
- Comando de 8 bytes enviado al teclado
- Bips de teclado
- Algún tipo de señal se envía desde el teclado
- El segundo comando de 8 bytes se envía al teclado, activado por la señal
- El teclado responde con información sobre el dispositivo y la versión
Cuando usamos nuestro puerto serie virtual, no podemos encontrar la manera de replicar la señal enviada desde el teclado. Podemos ver todos los datos correctamente, por lo que creemos que la configuración en nuestro objeto SerialPort es correcta. Aquí hay un fragmento de nuestra configuración de SerialPort:
_port.BaudRate= 9600;
_port.Parity = Parity.None;
_port.DataBits = 8;
_port.StopBits = StopBits.One;
_port.DtrEnable = true;
_port.RtsEnable = true;
También notamos que al usar Portmon vemos una solicitud GET_MODEM_STATUS que es a lo que la aplicación POS está esperando antes de enviar el segundo comando.
¿Alguna idea sobre cómo diagnosticar esto? Como estamos usando .NET, esta situación es un poco más baja de lo que estamos acostumbrados.
ACTUALIZACIÓN: También quiero señalar que probamos el SDK aquí: Franson Serial Tools, pero ni siquiera pudimos obtener datos para usar cuando usamos este SDK.
ACTUALIZACIÓN: lo hemos descartado utilizando cualquier tipo de puerto serie virtual. Hemos obtenido un cable para ejecutar desde la PC POS a otra y podemos ver los datos que se aproximan para emular el teclado. Ahora nuestro problema es que no podemos encontrar la manera de señalar que el teclado está listo para recibir datos como lo menciona la respuesta principal. Parece que la aplicación POS envía el comando para emitir un pitido y espera hasta 3 segundos esperando una señal. Así que se agota cuando hablamos con nuestra aplicación, pero no cuando hablamos con el teclado real
¿Cómo podemos hacer esto con la clase SerialPort? Ya configuramos DtrEnable y RtsEnable en verdadero, ¿necesitamos establecer algo más? ¿O tenemos que usar un puerto serie p / invoke de menor nivel para lograr esto?
SOLUCIÓN:
_port.RtsEnabled = false;
Thread.Sleep(1000);
_port.RtsEnabled = true;
Esto hace que la aplicación POS piense que el teclado está enchufado, lo que tiene sentido. Marcaré la respuesta número 1 como la respuesta, ya que nos ayudó enormemente a encontrar la solución.
Hace años que no desarrollo el puerto serie, pero cuando lo hacía siempre usaba un Crossover Cable y una segunda PC con Windows HyperTerminal.
EDITADO para dar más perspectiva desde el punto de vista de la simulación del teclado.
Da la casualidad que escribí controladores de bajo nivel para el teclado 92R en el pasado distante.
Realmente necesita la documentación para que el protocolo propietario lo haga correctamente, por ejemplo, los comandos enviados al teclado contienen un número de secuencia y una suma de comprobación. Recomiendo ponerse en contacto con Fujitsu e intentar obtener esta documentación.
De lo que has descrito:
El primer comando de 8 bytes que envió probablemente fue un comando de reinicio (ya que hizo que el teclado emitiera un pitido). El teclado envía una respuesta para confirmar el comando y luego se reinicia.
Después de enviar un comando de reinicio, la aplicación POS necesita esperar a que el teclado se reinicie (creo que aproximadamente 3000 ms) antes de enviar otros comandos.
Parece que el segundo envío es un comando para solicitar la versión de firmware.
La aplicación POS también deberá enviar posteriormente un comando para habilitar "autoinput" antes de que el teclado realmente envíe pulsaciones de teclas.
También hay comandos disponibles para solicitar la posición de bloqueo de teclas, hacer sonar el generador de tonos, habilitar / deshabilitar el MSR y escribir en la pantalla incrustada opcional de 2 líneas. Por lo tanto, su simulador deberá ser capaz de reproducir las respuestas a estos comandos.
Una vez que la aplicación POS ha habilitado la "entrada automática", el teclado enviará mensajes no solicitados con las pulsaciones presionadas (o la posición del bloqueo de teclas cambia, o la entrada de MSR). IIRC estos mensajes también tienen un número de secuencia y suma de comprobación que necesitará reproducir en su simulador.
La única señal que conozco es que el teclado aumenta el CTS cuando está listo para recibir datos. Si conecta dos puertos en una PC, necesita un cable de módem nulo especial (consulte a continuación) para que cuando su simulador active RTS en COM4 se vea como CTS en el otro puerto.
Los puertos COM en una placa base TeamPOS proporcionan energía al teclado. Probablemente no desee conectar estos pines a su puerto COM4, por lo que le sugiero que use un cable de módem nulo que conecte solo los siguientes pines:
2 (datos de Tx) - 3 (datos de Rx)
3 (datos Rx) - 2 (datos Tx)
7 (RTS) - 8 (CTS)
8 (CTS) - 7 (RTS)