skip to the main content area of this page
Driver Details

Download complete driver list...


 

XLI4278: Motorola LI-4278 BarCode Reader Serial Driver v10.0


XLI4278: Motorola LI-4278 BarCode Reader Serial Driver

General Information:


El driver XLI4278 permite comunicarse con los lectores de codigo de barra Motorola LI-4278 mediante una comunicacion de tipo serie como alternativa a la comunmente utilizada emulacion de teclado que viene establecida de fabrica.

CONEXION:

Si la base se conecta mediante USB, previamente se la debe configurar para que trabaje en modo 'Simple COM Port Emulation' y ademas se debe tener instalado en la PC el emulador de puerto serie virtual denominado 'Symbol COM Port Emulation Driver v 1.8.5.zip' y que esta disponible en el siguiente link:
https://atgsupportcentral.motorolasolutions.com/ewa/pub/ getFile.do?fileName=/ssi/emb/downloads/Symbol%20COM%20Port %20Emulation%20Driver%20v%201.8.5.zip.
Los pasos para configurar la base en modo 'Simple COM Port Emulation' se encuentran en la pagina 178 del manual del equipo, que se puede descargar del siguiente link:
http://www.posmicro.com/downloads/li4278_manual.pdf.
FUNCIONAMIENTO:

Este driver comienza poniendose en modo 'escucha', quedando atento a lo que el lector le envia a la PC y sin transmitir nada hacia el lector. El principio de funcionamiento entonces es que al activar el driver (mediante HMITalk o mediante NetTalk), el mismo se queda directamente esperando a que le llegue un codigo de barras, sin enviar previamente ningun mensaje. Para detectar la llegada de un codigo se utilizan dos mecanismos: por tiempo entre caracteres y/o por longitud del codigo. En casos como el EAN13 se puede utilizar la deteccion por longitud ya que los codigos son siempre fijos de 13 caracteres. En casos como el EAN128 los codigos pueden ser de longitud variable por lo que se debe aplicar la deteccion por timeout entre caracteres. No obstante, ambos mecanismos de deteccion pueden utilizarse combinadamente en casos especiales (terminar por longitud o por tiempo, lo que ocurra antes). El timeout entre caracteres, definido en DriverP1, se utiliza para establecer una condicion de terminacion de los telegramas basada en tiempo, para todos aquellos casos en los que no es aplicable establecer una longitud de telegrama especifica a ser esperada. El tiempo que se utilice en el timeout debe ser del orden de algunos milisegundos, mayor que el tiempo que pueda haber entre dos porciones de un mismo codigo (por ejemplo si estuviera siendo tipeado remotamente caracter por caracter por un operador o si el lector lo subdividiera en partes al transmitirlo). A su vez debe ser menor que el tiempo que pueda haber entre dos codigos consecutivos, para que las lecturas puedan ser correctamente individualizadas como dos codigos diferentes. Un valor adecuado podria rondar los 100 a 500 ms. En el caso que se utilice deteccion por timeout entre caracteres, lo que se evalua es el tiempo transcurrido entre la recepcion de un caracter individual y la recepcion del siguiente caracter individual, de manera tal que cuando se haya recibido un caracter y haya pasado el timeout entre caracteres establecido sin recibirse otro caracter, se considerara que se ha recibido un mensaje o codigo completo desde el lector, dando por finalizada la lectura y retornando los datos del codigo a la aplicacion. Este mecanismo permite detectar multiples tipos de codigo al mismo tiempo. Los mecanismos de deteccion que utiliza el driver no dependen del formato propio de cada tipo de codigo por lo que es aplicable a todos los casos donde el lector transmita espontaneamente una secuencia de caracteres alfanumericos por cada codigo, separados un tiempo uno del otro (UPC/EAN: UPC-A, UPC-E, UPC-E1, EAN-8/JAN 8, EAN-13/JAN 13, Bookland EAN, Bookland ISBN, Codigo Extendido de cupones UCC, Codigo ISSN EAN 128 incluyendo GS1- 128, ISBT 128, Concatenacion ISBT, Codigo 39 incluyendo Codigo 39 Trioptico, Conversion Codigo 39 a Codigo 32 (Codigo farmaceutico de Italia), Codigo 39 Full ASCII Conversion, codigo 93 Codigo 11, Matriz 2 de 5, Intercalado 2 de 5 (ITF), Diferenciado 2 de 5 (DTF), Codabar (NW – 7), MSI Chino 2 de 5, IATA Inverso 1D (salvo todos los DataBars GS1) GS1 DataBar, incluyendo GS1 DataBar-14, GS1 DataBar Limitado, GS1 DataBar Extendido). Queda luego a cargo de la aplicacion la interpretacion del contenido de cada codigo recibido. Por otra parte el driver ofrece la posibilidad de establecer otro tiempo mediante su parametro DriverP3, en el que se le informa cuantos segundos debe esperar a que llegue un codigo. Por ejemplo, si se coloca el valor 7200, el objeto esperara 2 horas a que llegue un codigo antes de devolver a la aplicacion un error de timeout. Si se deja en 0, el objeto nunca saldra por error de timeout y se quedara eternamente esperando un codigo.

En resumen, al dispararse el driver, el objeto que lo maneja (HMITalk o NetTalk) quedara a la espera indefinidamente hasta que ocurra alguna de estas situaciones:
  • Que entre una secuencia de caracteres y por un periodo de Timeout no hayan llegado mas caracteres, en cuyo caso se considerara un codigo completo.

  • Que haya expirado el tiempo de espera maximo a que llegue un codigo definido en DriverP0.

  • Que la aplicacion haya abortado la espera mediante la llamada al metodo de abortar la comunicacion. En el caso que haya llegado un codigo, el objeto terminara su ejecucion y la aplicacion debera asegurarse de ponerlo nuevamente en modo escucha para que quede en condiciones de recibir un nuevo codigo. Cuando llega un codigo y el driver esta siendo manejado por HMITalk, este emitira los eventos correspondientes. Se recomienda escuchar el evento OnSuccessfullyReceived ya que el OnPointValueChanged puede no resultar de utilidad. Para que el objeto quede escuchando nuevamente otro codigo, puede dejarse activada la propiedad ScanActive o bien llamar explicitamente al metodo Trigger una vez procesado el codigo recibido. Si el driver esta siendo manejado desde NetTalk, este devolvera el control a la aplicacion donde se debera procesar el codigo recibido y luego volver a llamar al metodo ReadNumeric para ponerlo otra vez en modo escucha. Dado que NetTalk bloquea el flujo del programa cuando se lo utiliza en modo bloqueante, se recomienda manejarlo mediante un hilo secundario (por ejemplo con un control .NET para multitarea tipo BackgroundWorker).

  • SETTINGS:

    Tanto el puerto virtual como el HMITalk o NetTalk que se utilicen se deben configurar con los siguientes settings:
    9600,N,8,1 Si la base se conecta mediante un puerto serial, se puede utilizar un conversor/adaptador ethernet/serial para enlazarla a la PC a traves de la red LAN. En este caso, el adaptador es quien debera trabajar con los settings 9600,N,8,1 y los objetos HMITalk y NetTalk se deberan apuntar a una direccion IP en lugar de a un puerto serie.

    Available Commands:



    Supported Devices:

    (This list is only indicative and may exist other unlisted equipment that are also communicable with this driver).


    This driver includes:



    Available Downloads:



    To purchase a license please contact Engineering CPKSoft to any of our contact options.
    Return to All Drivers
    Licenses

    The licenses of all our drivers are unlimited in terms of the number of machines where they can be used, the number of I/O that can read or written, and the number of components that can be included in each application.

    After purchasing a license, the owner can use the driver and all its components to assemble and distribute as many applications to as many users as needed.

    The license owner retains full control of his applications by deciding himself what target machines can they be run at. For this, each driver is provided with two runtime license management tools: GetPCId.exe and MakeLic.exe.