RETAIL EBDS PROTOCOL SPECIFICATION With MPOST G2.en - Es

Sitio aplicable ÁRBITRO 20105-002.850.
131-PS
West Chester
(s) PCN 500000008441
Al por menor - eBDS Protocolo de Especificaciones Problema G2

Tema
(Con M / POST para eBDS) Página 1 de 128
MENOR eBDS PROTOCOLO

ESPECIFICACIÓN
(con M / POST para eBDS)
TÍTULO MENOR eBDS Especificación del protocolo (con M / POST para eBDS)
NÚMERO 20105-002.850.131-PS
PROBLEMA G2
PCN 500000008441
FECHA 11 de agosto de, 2008
AUTORES Peter Camilleri
Copyright © 2008 MEI Inc
La información contenida en este documento es la propiedad de MEI, Inc. y no ha de ser divulgada o se usa sin
el permiso por escrito de MEI, Inc. Esta copyright se extiende a todos los medios de comunicación en el que
dicha información puede ser conservada incluyendo almacenamiento magnético, tarjetas perforadas , cinta de
papel, impresión de la computadora o la pantalla de visualización.
Aunque se ha hecho todo lo posible para garantizar la exactitud e integridad de la información

contenida en este documento, MEI no garantiza que esa información esté libre de errores u omisiones.
Además MEI se reserva el derecho a actualizar este documento en cualquier momento.
Derechos de autor © 2008 MEI, Todos los derechos reservados

Sitio aplicable ÁRBITRO 20105-002.850.131-PS
West Chester
(s) PCN 500000008441

Tema
cambia la historia
Fecha de asunto Descripción Autor (s)
N / A 2 de marzo de, de 2006 Borrador inicial Peter Camilleri
N/A 26 de de junio de, de 2007 Continua Trabajo en Progreso Peter Camilleri
N/A 9 de julio de, de 2007 Continua Trabajo en Progreso Peter Camilleri
Añadido capítulo para la sección eBDS del Punto de Servicio MEI
N/A 13 de julio de, de 2007 Peter Camilleri
Toolkit (M / POST).
N/A 24 de de julio de, de 2007 En primer borrador completo. Peter Camilleri
Añadido secciones para fijaciones para ActiveX, Linux,
N/A 27 de de julio de, de 2007 .tablas
NET yde
Java
conversión
para ser binaria
rellenados
Peter
enCamilleri
un momento posterior. Se agregó una referencia rápida y Hex /
Se ha actualizado la introducción a cubrir M / POST. Añadido advertencia

N/A Aug 23 de, de 2007 Peter Camilleri
sobre el modo de fallo de bucle de retorno.
Añadido algunas notas breves sobre los enlaces de .NET y el manejo
N/A 10 sept, de 2007 Peter Camilleri
recomendado de eventos.
comando QueryDeviceCapabilities actualizados. Agregado
QueryBNFStatus, QueryAcceptorApplicationID y
QueryAcceptorVariantID comandos. También se ha añadido
N/A 19 de sept, de 2007 Peter Camilleri
CapBNFStatus, BNFStatus, CapApplicationID, ApplicationID,
CapVariantID, VariantID y propiedades CapTestDoc a M / POST
Se agregó la propiedad DebugLogPath y una sección para el programa de

N / A 31 de Oct, de 2007 Peter Camilleri
demostración M / POST.
Agregado sección de manejo de eventos VB.NET. Se ha agregado una entrada de erratas a los detalles
N / A Nov 12, de 2007 BillTypeEnables propiedad. Peter Camilleri
Se ha corregido los valores de ID de modelo para Zt1200 estadounidense y las

N / A 16 de Nov, de 2007 entradas para las tablas de facturas asociadas con esas tablas. Peter Camilleri
N / A 28 de Nov, de 2007 los comentarios de Dave McLaughlin Incorporated Peter Camilleri

N/A 7 jan, 2008 Se ha añadido la sección de enlaces de OLE Peter Camilleri
N/A 9 jan, 2008 Se agregó una tabla aclarar el uso de tipo de mensaje 7x. Peter Camilleri
N/A Jan 10, 2008 Se ha añadido una tabla de conversión ASCII. Peter Camilleri
N/A 22 de jan, 2008 Se ha añadido el comando Set Bisel. Peter Camilleri
Actualizado el comando Conjunto del bisel. descripciones
N/A 29 de jan, 2008 Peter Camilleri
actualizadas de la demo M / POST.
Se aclaró la intención de (0) bits no utilizados en los comandos y
N/A 22 de Feb, 2008 respuestas. Actualizado los SetExpandedNoteInhibits comando para Peter Camilleri
indicar las dos respuestas posibles.
Documentado la secuencia alterna para determinar capacidades del
N/A 25 de Feb, 2008 Peter Camilleri
dispositivo.
N/A 4 de abril de, 2008 Actualizado respuesta tiempos de espera para permitir conexiones USB. Peter Camilleri
N/A 18 de de abril de, 2008 Añadido preliminar información de enlaces de Linux. Peter Camilleri
N/A 23 de de abril de, 2008 Agregado configuración PID y VID para conexiones USB. Peter Camilleri
G1 13 de mayo de, 2008 Primer lanzamiento. Peter Camilleri
G2 11 de agosto de, 2008 Actualizado con los datos de la Nota alimentador Manojo Peter Camilleri

West Chester
(s) PCN 500000008441

Tema
Tabla de contenido
1. Introduction______________________________________________________________ 7
1.1 Alcance _________________________________________________________________________7
1.2 Recomendación / advertencia Icons__________________________________________________8
1.3 Iconos Producto __________________________________________________________________8
1.4 Variedades de eBDS ______________________________________________________________9
2. Un protocolo general ______________________________________________________ 10
3. Capa Física La _______________________________________________________ 11

3.1 RS-232 _______________________________________________________________________ 11
3.2 RS-485 _______________________________________________________________________ 11
3.3 ópticamente Isolated______________________________________________________________11
3.4 USB _________________________________________________________________________11

3.4.1. Los identificadores de dispositivos USB ____________________________________________________________12
4. El enlace de datos 13 Layer______________________________________________________
4.1 Paquetes de Datos Construction_______________________________________________________13

4.1.1 Más sobre STX / ETX y CHK ____________________________________________________13
4,2 Normal (Polled) Mode__________________________________________________________13

4.2.1 Modo Normal sincronización _______________________________________________________________14
4.3 Especial (Interrupción) Modo _______________________________________________________14

4.3.1 Modo Especial Timing________________________________________________________________15
4.3.2 ABDS y (Interrupción) Modo especial ____________________________________________________15
4.3.3 Flash Descargar y (Interrupción) Modo especial ____________________________________________15
4.4 Recepción de una respuesta ______________________________________________________________16

4.4.1 Control de errores de bucle invertido ____________________________________________________________17
4,5 ACK Procesamiento / NAK __________________________________________________________17

4.5.1 Ejemplos ACK / NAK: _______________________________________________________________18
4.5.2 Requisitos de temporización ACK / NAK ______________________________________________________19
5. La red de capa _______________________________________________________ 20

5.1 Tipo de dispositivos de enrutamiento de mensajes ___________________________________________________20
5.2 ABDS de enrutamiento de mensajes ________________________________________________________21

5.2.1 ABDS temporización Requirements__________________________________________________________22
5.2.2 ABDS y (Interrupción) Modo especial ____________________________________________________22
6. La Sesión de capa ________________________________________________________ 23
6.1 Las variaciones en la presentación de informes Power Up ________________________________________________23
6.2 A partir del modo de descarga _____________________________________________________23
6.2 Terminar la Session_____________________________________________________________24
7. La capa de presentación (por aceptador de billetes) ____________________________________ 25
7.1 El Omnibus Command________________________________________________________25

West Chester
(s) PCN 500000008441

Tema
7.1.1 Ómnibus Command_________________________________________________________________26

7.1.2 Estándar Ómnibus Reply_____________________________________________________________29
7.1.3 extendido Ómnibus de código de barras de respuesta ____________________________________________________33
7.1.4 extendido Nota Ómnibus Ampliado Reply________________________________________________33
7.1.5 extendido Ómnibus Ampliado cupón de respuesta _____________________________________________36
7.2 El orden de calibración _______________________________________________________37
7.3 El comando Descarga de firmware ______________________________________________38

7.3.1 El ritmo de las comunicaciones durante la descarga. ___________________________________________38
7.3.2 Descripción general del proceso de descarga de Flash ________________________________________________38
7.3.3 Descarga de flujo Diagram_____________________________________________________________40
7.4 El Commands_______________________________________________________42 auxiliar

7.4.1 Consulta de software CRC________________________________________________________________42
7.4.2 Consulta de Cash Box total _______________________________________________________________43
7.4.3 dispositivo se restablece de consulta ________________________________________________________________44
7.4.4 Borrar Cash Box Total________________________________________________________________45
7.4.5 Consulta aceptador Type________________________________________________________________45
7.4.6 Consulta aceptador Número de serie ________________________________________________________46
7.4.7 Número de pieza de consulta aceptador de arranque _____________________________________________________48
7.4.8 Consulta Aceptador Number________________________________________________48 Parte de Aplicación
7.4.9 Nombre de la consulta aceptador variante ________________________________________________________49
7.4.10 Número de pieza de consulta aceptador variante __________________________________________________50
7.4.11 consulta de totales aceptador de Auditoría de Life Time ________________________________________________51
7.4.12 Consulta aceptador medidas de auditoría QP ___________________________________________________53
7.4.13 Medidas de consulta aceptador de rendimiento Auditoría ___________________________________________54
7.4.14 de consulta Capacidades de dispositivo ___________________________________________________________56
7.4.15 consulta Aceptador Aplicación ID_______________________________________________________57
7.4.16 consulta Aceptador Variant ID __________________________________________________________58
7.4.17 Consulta BNF Estado _________________________________________________________________59
7.4.18 Conjunto Bisel ________________________________________________________________________59
7.4.19 aceptador Restablecimiento ordenado ________________________________________________________________60
7.5 El Commands_______________________________________________________61 Extended

7.5.1 Especificación de consultas expandido Nota ____________________________________________________61
7.5.2 conjunto ampliado Nota Inhibe ___________________________________________________________63
7.5.3 Conjunto de depósito de garantía Timeout_________________________________________________________________64
7.5.4 Conjunto de Activos Número __________________________________________________________________65
7.5.5 Consultar valor Table__________________________________________________________________65
7.5.6 Conjunto modo extendido PUP _____________________________________________________________66
7.6 Procesamiento de Estados ______________________________________________________________67

7.6.1 Unidos Procesamiento en plica para no Mode__________________________________________________68
7.6.2 Procesamiento de los Estados en el modo de fideicomiso _____________________________________________________69
8. La capa de aplicación (por Bill aceptor) _____________________________________ 70
8.1 Tareas de inicio de aplicaciones ______________________________________________________70
8.2 Aplicación de divisas Handling__________________________________________________71

8.2.1 Manejo de dinero en el modo Conciso: _____________________________________________________ 71
8.2.2 Manejo de Dinero en modo expandido: _________________________________________________71
8.2.3 manejo de dinero diagrama de flujo recomendada: _____________________________________________72
8.2.4 El control de la orientación de las facturas aceptadas: ____________________________________________ 73
8.2.5 Mejora el control de la orientación en modo expandido: ___________________________________74
8.3 La determinación de la Version_______________________________________________74 firmware

8.3.1 Versión de firmware en el Clásico eBDS: ____________________________________________________74

West Chester
(s) PCN 500000008441

Tema
8.3.2 Versión de firmware en eBDS extendido: __________________________________________________75
8.4 Controlar excepciones aceptoras ___________________________________________________75

8.4.1 aceptador de billetes no responde a una encuesta: _________________________________________________ 75
8.4.2 aceptador de billetes no responde durante un período prolongado: _____________________________________75
8.4.3 aceptador de billetes Estado: Cheated _________________________________________________________75
8.4.4 aceptador de billetes Estado: Rejected_________________________________________________________76
8.4.5 aceptador de billetes Estado: atascado _________________________________________________________76
8.4.6 aceptador de billetes Estado: Stacker completa ______________________________________________________76
8.4.7 aceptador de billetes Estado: Cashbox Removed_________________________________________________76
8.4.8 aceptador de billetes Estado: En pausa __________________________________________________________76
8.4.9 aceptador de billetes Estado: Calibración en curso _____________________________________________76
8.4.10 aceptador de billetes Estado: Poder Up_______________________________________________________77
8.4.11 aceptador de billetes de estado: no válido Comando ________________________________________________77
8.4.12 aceptador de billetes Estado: Fallo _________________________________________________________77
8.4.13 aceptador de billetes Estado: Stalled _________________________________________________________77
8.4.14 aceptador de billetes Estado: Flash Download__________________________________________________77
9. MEI Punto de Servicio Toolkit (M / POST) ______________________________________ 78
9,1 M / POST para eBDS general: ___________________________________________________78

9.1.1 M / POST para eBDS Aceptador Propiedades: ______________________________________________78
9.1.2 M / POST para eBDS Cuenta Propiedades: ___________________________________________________ 80
9.1.3 M / POST para eBDS Cupón Propiedades: ________________________________________________80
9.1.4 M / POST para eBDS DocType Enumeración: ____________________________________________80
9.1.5 M / POST para eBDS Orientación Enumeración: _________________________________________81
9.1.6 M / POST para eBDS OrientationCtl Enumeración: _______________________________________81
9.1.7 M / POST para eBDS Encender Enumeración: ___________________________________________81
9.1.8 M / POST para eBDS PupExt Enumeración: _____________________________________________81
9.1.9 M / POST para eBDS Estado Enumeración: _______________________________________________81
9.1.10 M / POST para eBDS BNFStatus Enumeración: ___________________________________________81
9.1.11 M / POST para eBDS Bisel Enumeración: ________________________________________________82
9.1.12 M / POST para eBDS Aceptador Métodos: ________________________________________________ 82
9.1.13 M / POST para eBDS Aceptador Eventos: 82 __________________________________________________
9.1.14 M / POST para eBDS Aceptador Propiedades Detalles: _________________________________________83
9.1.15 M / POST para eBDS Aceptador Métodos Detalles: _________________________________________94
9.1.16 M / POST para eBDS Aceptador Eventos Detalles: ___________________________________________97
10. M / POST Bindings para ActiveX ___________________________________________ 101
10.1 Conexión al POST DLL M / _______________________________________________101
10.2 Gestión de eventos en Visual Basic 6 ______________________________________________101
10.3 Diferencias con el modelo M / POST ___________________________________________102
10.4 Una nota sobre los valores de índice de matriz. __________________________________________________103
10.5 Una nota sobre los valores de propiedad de Boole. _____________________________________________103
11. M / POST Bindings para .NET _____________________________________________ 104
11.1 Conexión al POST DLL M / _______________________________________________104
11.2 Gestión de eventos M / POST en C # _______________________________________________105
11.3 Manipulación M / POST Eventos en VB.NET __________________________________________106
12. M / POST Bindings para Linux ____________________________________________ 107
12.1. Uso de la biblioteca MPOST_Linux ____________________________________________107

West Chester
(s) PCN 500000008441

Tema
12.2. Gestión de eventos M / POST en Linux___________________________________________107
12.3. Mpost Linux demo Program_______________________________________________108
13. M / POST Bindings para JAVA ____________________________________________ 109
14. El Programa M / POST demostración ____________________________________________ 110
14.1 El Launcher_______________________________________________________________110
14.2 El panel de control ___________________________________________________________111

14.2.1 El principal Ficha ___________________________________________________________________112
14.2.2 Las funciones de la ficha ______________________________________________________________115
14.2.3 El Propiedades Tab________________________________________________________________115
14.2.4 El proyecto de ley Conjunto Tab__________________________________________________________________118
14.2.5 El proyecto de ley Valores Tab_______________________________________________________________119
14.2.6 La Información del dispositivo Tab ______________________________________________________________120
15. Dispositivo arnés y Connection__________________________________________ 121
15.1 Opciones del arnés eBDS para el aceptador de billetes de la serie 2000: __________________________121
Diseño arnés 14.1.1 personalizado para la serie 2000 aceptador de billetes: ________________________________121
15.2 Opciones del arnés eBDS para el Cashflow SC-aceptador de billetes: 122 _________________________
14.2.1 RS-232 de configuración de arnés: ______________________________________________________ 122
Configuración de arnés 15.2.2 USB: ________________________________________________________123
15.3 Legacy, la serie (ZT) 1000 Opciones del arnés ______________________________________124
15.4 Legacy, la serie 3000 Opciones del arnés ___________________________________________124
dieciséis. Referencia rápida ______________________________________________________ 127
17. Hex / binario y ASCII de datos Conversion___________________________________ 128

West Chester
(s) PCN 500000008441

Tema
1. Introducción
1.1 Alcance
El objetivo de este documento es especificar el protocolo eBDS con el objetivo de hacer más fácil incorporar dispositivos eBDS en
soluciones de negocio. Con este fin, las audiencias se definen en este documento son anfitrionas desarrolladores de software del
sistema, especialistas de soporte técnico e integradores de sistemas.
En primer lugar, para servir mejor a este grupo, en este documento emplea un enfoque estructurado basado en el modelo de red OSI.
Este modelo ha demostrado ser una base sólida para la aplicación del dispositivo de comunicaciones de dispositivos de todo tipo.
En segundo lugar, este documento se centrará en las necesidades de los desarrolladores en los mercados al por menor, quiosco, fuera auto-limitación y el dinero en efectivo y
soltar.
En tercer lugar, este documento sirve para documentar el MEI / Punto de Servicio Toolkit (M / POST). Esta herramienta es compatible con TCA y reduce
considerablemente el esfuerzo requerido para implementar un anfitrión eBDS. Los usuarios de M / POST pueden desear pasar directamente a la sección 9 y
se refieren a las secciones anteriores, según sea necesario. Por último, este documento examinará eBDS tal como se utiliza en los siguientes productos al
por menor:
Familia Modelo variantes

serie 2000 AE2600 Estados Unidos, Australia, Canadá,
AE2800 Estados Unidos, Argentina, Brasil
Cashflow SC SC-66 variantes flexibles

SC-83 variantes flexibles
SC-85 Producto especial Reino Unido
Los siguientes productos anteriores también se discuten para ayudar en el proceso de migración de códigos de host:
Familia Modelo variantes Descripción

serie 1000 ZT1200 Estados Unidos, Australia, Canadá Productos descontinuados
serie 2000 AE2600 NOSOTROS A principios de hardware modelo.
serie 3000 LE, RS, EX Estados Unidos, Australia Productos descontinuados
Cashflow SC SC-66 Estados Unidos, Australia A principios de la versión de software.
En todos los casos, MEI informa que se obtiene el mejor funcionamiento de los dispositivos de efectivo cuando se cargan con el
firmware más actual para ese producto.

West Chester
(s) PCN 500000008441

Tema
Las rutas de migración recomendados de productos más antiguos a más reciente se ilustra a continuación:
ZT1200 ZT1200 ZT1200 serie

Australia EE.UU. Canadá 3000
Aplicaciones Las nuevas

New aplicaciones de gama
International baja de EE.UU.
Las nuevas
aplicaciones de gama
alta de los Estados Unidos
Cashflow Cashflow serie

SC-66 SC-83 2000
Iconos 1,2 Recomendación / advertencia

Los siguientes iconos de advertencia se pueden utilizar para destacar las mejores prácticas y las posibles áreas problemáticas.
Recomendado Una característica que se recomienda como un “mejor” práctica.
No al por menor Una característica que no es adecuado para aplicaciones comerciales.
Incompatible Las características que son incompatibles o mutuamente excluyentes.
Obsoleto Una característica que ya no se recomienda.
Obsoleto Una característica que se utiliza para ser soportado, pero ya no lo es. En general,
cualquier característica o comandos de modo marcados deben ser evitados.
1.3 Iconos Producto

Algunas características de eBDS afectan especial o varían según el producto implementarlas. Para indicar esto, se utilizan los
siguientes iconos:
S1K Todas las series 1000 productos al por menor (ZT120x)
S2K Todos los productos de la serie 2000 al por menor (AE2600, AE2800)
Gen2D Serie 2000, AE2800 y AE2600 nuevos productos estadounidenses.
Gen2B / C Serie 2000 productos más viejos AE2600 estadounidenses.
S3K Todos los productos de la serie 3000 (LE / RS / EX).
CCS Todo Cashflow SC-productos al por menor.
BNF Un flujo de caja-SC con la opción de fajos de billetes alimentador
CFMC productos al por menor con el software antiguo flujo de caja 66 SC.

West Chester
(s) PCN 500000008441

Tema
1.4 Variedades de eBDS

El protocolo eBDS ha evolucionado con el tiempo. Ya que ha cambiado, la designación de las versiones también ha cambiado. El árbol de
la familia eBDS se ilustra a continuación.
BDS
eBDS ABDS
eBDS
Plus
Acrónimo Significado
BDS si yo re irectional S Protocolo erial Obsoleto
eBDS mi volución si yo re irectional S Protocolo erial
ABDS UNA ddressable si yo re irectional S Protocolo erial
eBDS Plus mi volución si yo re irectional S Protocolo erial Más
El protocolo BDS ya no es compatible en cualquier producto de manejo de efectivo actuales. Este protocolo se discute aquí sólo para
medida necesaria para señalar las cuestiones de migración. El protocolo eBDS es ampliamente utilizado en la serie 2000, así como el
legado de la serie 1000, 3000 y más viejos modelos SC-66.
El protocolo ABDS es apoyado por la serie 3000 y el Flujo de Caja-SC con la opción RS-485 instalado. Este protocolo permite
que varios aceptores de efectivo para ser conectadas a una única multi-drop, puerto, host.
EBDS Plus es similar a eBDS con la opción adicional de informes nota extendida y varias extensiones orientadas comando-al
paquete de órdenes ómnibus originales.

West Chester
(s) PCN 500000008441

Tema
2. Descripción general del protocolo
La red OSI Modelo ISO se utiliza para describir las redes de todo tipo y un ordenador conectado a un dispositivo eBDS no es una
excepción. Esto se ilustra en la siguiente distribución en capas de una conexión al dispositivo de un tal.
El dispositivo
Capa Unidades de Transmisión
ordenador anfitrión eBDS
7 Solicitud Acciones / Eventos Solicitud
6 Presentación Comandos / respuestas Presentación
5 Sesión mensajes Sesión
4 Transporte mensajes Transporte
3 Red Los paquetes Red
2 Enlace de datos marcos Enlace de datos
1 Físico Los bits Físico
comunicadas Medio
El propósito de estas capas se explica a continuación:
Capa Descripción
Este es el software de alto nivel en el equipo y la funcionalidad del

Solicitud
dispositivo.
La capa de comando / respuesta que interactúa con la aplicación.

Presentación
Este nivel se ocupa de múltiples interacciones entre el ordenador y el

Sesión dispositivo. En eBDS Esto corresponde al poder arriba / abajo e inicio de
la aplicación / acabado.
La ruptura y la recombinación de las transacciones más grandes en paquetes

Transporte más pequeños. En la mayoría de los casos, las transacciones eBDS caber dentro
de un solo paquete.
dirección de red y de acceso utilizados para guiar el paquete al destino

Red
correcto
La colección de muchos bits en una unidad de significado o paquete,

Enlace de datos
incluyendo la detección de errores.
La tensión / corriente y de temporización para un único bit en un marco.

Físico
comunicadas Medio El medio de conectores y cables / transmisión de la conexión.

West Chester
(s) PCN 500000008441

Tema
Capa 3. La Física
Los datos en eBDS se transmite utilizando bytes de datos asíncronos. Estos pueden ser formateados como:
9600 bps, 7 bits de datos, paridad par, 1200bps un bit de parada, 7
bits de datos, paridad par, un bit de parada Obsoleto
Los protocolos eBDS apoyan un número de diferentes tipos de capas físicas. Estos se presentan a continuación:
3.1 RS-232
La interfaz RS-232 es compatible en todos los productos. Cabe señalar sin embargo, que algunos productos requieren el uso de un
arnés adaptador para ser utilizado en este modo. EBDS utiliza el mínimo, tres hilos, de configuración (GND, TXD, RXD) sin líneas
de toma de contacto. La transmisión de datos a través de la línea corresponde a la EIA RS-232 de especificaciones, que no se
repite aquí. La especificación formal puede encontrarse en Recomendación UIT-T (formalmente Recomendación CCITT) V.24. A, si
la especificación formal más útil inferior se puede encontrar en la página web de Wikipedia con el tema de RS-232.
3.2 RS-485
La interfaz RS-485 es una interfaz especializado que se utiliza para apoyar la multi-drop características del protocolo ABDS. Es
apoyado por el RS-485 adaptador de interfaz de arnés de la Serie 3000 y por el flujo de caja-SC con la opción de tarjeta de interface
RS-485. Cuando se utiliza RS-485, todas las comunicaciones ocurren a través de una sola línea de datos par equilibrado en un
cierto modo semidúplex. No se utilizan líneas de apretón de manos.
3.3 con aislamiento óptico
No al por menor Este tipo de interfaz utiliza conductores aislados ópticamente. Para mantener el aislamiento, la referencia de tierra y
potencia requerida por el lado del anfitrión de la conexión de todo deben ser suministrados por el anfitrión. La interfaz aislado ópticamente no
se utiliza normalmente en aplicaciones al por menor. Sin embargo, esta interfaz puede encontrar aplicación en los casos en que el sistema
host está físicamente alejado del dispositivo en un entorno ruidoso electrónicamente.
3.4 USB
El protocolo eBDS también puede ser embebido dentro del protocolo de puerto de comunicaciones USB virtuales. Esto se puede
lograr con un RS-232 Virtual Com Port cable o mediante el uso del arnés apropiado (por Series 2000) o placa de interfaz (por
Cashflow-SC). No se utilizan líneas de diálogo.
Las capas de protocolo implicadas en la incorporación de eBDS en USB se cubren en las especificaciones USB disponibles al público y no se
tratan en este documento.
Incompatible Algunos cables COM virtual USB no son compatibles con los parámetros de transferencia de datos requeridos por eBDS
(9600, 7, E, 1). Estos cables no funcionarán con un dispositivo eBDS. Además, algunos de estos cables introducir retrasos que puedan
interrumpir algunas operaciones eBDS.

West Chester
(s) PCN 500000008441

Tema
3.4.1. Los identificadores de dispositivos USB
Normalmente, los dispositivos de MEI que utilizan una conexión USB se suministran con un programa de instalación que configura los
controladores y dispositivos necesarios ajustes. En los sistemas embebidos o algunos sistemas operativos, este no es el caso y los
integradores de sistemas tendrá que configurar los controladores manualmente.
Para ayudar en la configuración manual, los siguientes conjuntos de mesa fuera de los parámetros cruciales USB para diversos productos MEI:
ID de proveedor para MEI Identificación del producto para el dispositivo

Dispositivo
(VID) (PID)
Flujo de Caja-SC o Cashflow- SCL,
modelos 6628 o 0x1100
8328.
0x0BED
Serie 2000 modelos AE2800 o
AE2600 con 0x1101
Juego de cables USB opcional.
Para más información sobre los controladores, consulte la página web de Silicon Laboratories en:
http://www.silabs.com/ y buscar controladores de comunicaciones virtuales para el CP2102. para WinCE •
anfitriones, una integración personalizada con el USBXpress • Se requerirá kit de desarrollo.

West Chester
(s) PCN 500000008441

Tema
4. La capa de enlace de datos
4.1 Construcción de Paquetes de Datos
Los paquetes de datos, ya sea desde el host o el dispositivo, se establecen de acuerdo con el siguiente plan:
Byte 1 2 3 4 .. L-2 L-1 L
nombre STX Len CTL Bytes de datos ETX CHK
del valor 0x02 L norte n .. n 0x03 norte
comienzo Bytes cubierto por CHK Detener
carga útil del paquete
Dónde:
STX El carácter STX ASCII. valor hexadecimal 0x02. El inicio de un paquete.

Len El recuento de todos los bytes en el paquete.
Byte CTL Una mezcla del campo ACK / NAK, un área reservada, y la zona de mando.
Bytes de datos La bytes de datos del paquete. Esta es Len-5 vale bytes.
ETX El carácter ETX ASCII. valor hexadecimal 0x03. El final de un paquete.
Checksum La suma de comprobación XOR de bytes 2 a través de Len-2.
4.1.1 Más sobre STX / ETX y CHK

Es muy importante tener en cuenta que los valores utilizados para STX y ETX, es decir, 0x02 y 0x03 no son únicos dentro de la estructura de
paquetes. Es posible (aunque poco probable) para cualquiera de los bytes de datos o el byte cheque para ser uno de estos valores. Así, el código
de host no debe ser escrito para siempre comenzar un paquete cuando se encuentra un 0x02 o finalizar una cuando un 0x03 se encontraron
entradas. En su lugar, el byte de longitud se debe utilizar para determinar cuándo termina un paquete y el tiempo de espera cuando se pierde. La
capa de enlace de datos puede funcionar en uno de dos modos, el modo normal o modo especial.
4,2 Normal (Polled) Modo

En el modo normal, eBDS opera como un sistema huésped / periférico estándar con todas las transacciones iniciadas por el anfitrión
y sólo responde generada por el periférico. Todas las comunicaciones se realizan en paquetes que siguen las reglas de la sección
3.1.
En modo de sondeo, el sistema anfitrión es responsable de ejecutar las transacciones de lograr tres objetivos: 1) el envío de los comandos
a las necesidades de acogida para configurar el periférico en el modo correcto.

2) Dar el periférico la oportunidad para informar a la serie de eventos que pueden requerir atención por el anfitrión.
3) Asegurar el periférico que el anfitrión sigue funcionando correctamente y que está bien aceptar dinero de los clientes.

West Chester
(s) PCN 500000008441

Tema
4.2.1 Modo Normal Timing

Límite Limite
Parámetro Descripción
inferior superior
Si se excede el tiempo máximo entre caracteres,

El tiempo entre el receptor de el paquete
0 ms 20ms
caracteres debe descartar el paquete actual y reanudar la búsqueda
de un carácter STX.
Si el dispositivo periférico no ha comenzado a responder dentro de
esta cantidad de tiempo después de un paquete
Tiempo de respuesta
0 ms 35ms se envía a la misma, el anfitrión debe asumir
periférica
que no hay respuesta va a ser enviado por el periférico.
Esta es la velocidad a la que el anfitrión debe comunicarse

50ms 1s con el periférico. El intervalo de sondeo recomendada es
de 200 ms.
Intervalo de votación
es
50ms 250 ms BNF Cuando un alimentador

instalado, de fajos
se requiere una de billetes
velocidad de votación más alta para
mantener el rendimiento del sistema.
Si el periférico no recibe una encuesta de la acogida dentro
Periférica desactivar el de este plazo, será inhabilitado para evitar seguir
3s -
tiempo aceptando dinero en un sistema con una serie
discapacitados.
4.3 Especial (Interrupción) Modo
Obsoleto
En el modo especial, eBDS añade una instalación para el dispositivo periférico a la petición de que el anfitrión realizar una operación de sondeo. El
anfitrión es todavía responsable de dirigir las operaciones de:
1) el envío de cualquier comando las necesidades de acogida para configurar el periférico en el modo correcto.
2) Asegurar el periférico que el anfitrión sigue funcionando correctamente y que está bien aceptar dinero de los clientes.
Cuando el periférico detecta un evento que requiere la atención de host, envía un solo ENQ (0x05). El carácter ENQ Nunca se
enviará una respuesta mientras se está enviando, pero se puede enviar un comando mientras se está enviando anfitrión. Cuando el
host recibe el ENQ, se debe sondear el periférico.
Tenga en cuenta que mientras que los eventos suelen seguir un cierto orden, no es prudente asumir que ciertos eventos seguirán siempre
de una manera predecible. Así, cada ENQ se debe tratar como si lo hay, o incluso ningún caso pudo haber sido el detonante.
Además, el código de host debe ser escrito con la conciencia de que un ENQ se puede enviar en cualquier momento, sin tener en
cuenta otras actividades eBDS. Por ejemplo, el dispositivo podría enviar un ENQ en medio del envío de un comando de acogida.

West Chester
(s) PCN 500000008441

Tema
4.3.1 Modo Especial Momento
Límite Limite
inferior superior
Si se excede el tiempo máximo entre caracteres, el

El tiempo entre receptor del paquete debe descartar el paquete actual y
0 ms 20ms
caracteres reanudar la búsqueda de un carácter STX.
Si el dispositivo periférico no ha comenzado a responder

dentro de esta cantidad de tiempo después de un
Tiempo de respuesta
0 ms 35ms paquete es enviado a él, el anfitrión debe asumir que no
periférica
hay respuesta va a ser enviado por el periférico.
Esta es la velocidad a la que el anfitrión debe

Intervalo de votación 50ms 30s comunicarse con el periférico. El intervalo de sondeo
recomendada es de 1 s.
Si el periférico no recibe una encuesta de la acogida
dentro de este plazo, será inhabilitado para evitar
Periférica desactivar el
33s - seguir aceptando dinero en un sistema con una serie
tiempo
discapacitados.
Si el host no responde a la ENQ dentro del tiempo

ENQ Tiempo de
0 ms 100 ms requerido, el periférico volverá a intentar el envío del
respuesta
ENQ.
Si un ENQ se envía y el anfitrión no responde por este
límite, el periférico será inhabilitado para evitar seguir
Tiempo de espera de
3s - aceptando dinero en un sistema con una serie
respuesta ENQ
discapacitados.
Los comandos se utilizan para controlar los modos de capa de enlace de datos se tratan en la sección 7.1.1
4.3.2 ABDS y (Interrupción) Modo Especial

Incompatible
Modo especial no puede ser utilizado en un sistema donde ABDS (ver sección 5.2) está en uso. Esto se debe al hecho de que todos
los dispositivos múltiples podría intentar enviar un carácter ENQ al mismo tiempo, y el resultado sería la corrupción de datos. El
half-duplex, carácter multi-gota de la capa física RS-485 de ABDS hace que sea incompatible con el modo especial (interrupción).
4.3.3 Flash Descargar y (Interrupción) Modo Especial

Incompatible
Modo especial no puede ser usado en conjunción con los protocolos descargar Flash (ver sección
7.3). Si se desea la capacidad de firmware del dispositivo de actualización a través eBDS, a continuación, de modo especial no debe ser empleado.

West Chester
(s) PCN 500000008441

Tema
4.4 Recepción de una respuesta
El siguiente es un diagrama de transición de estado para el código de acogida para recibir un paquete de respuesta. Este modelo incorpora las mejores
prácticas conocidas para esta tarea.
Comience a Otro
Uso 200 ms en modo de
conseguir la contestación
descarga. Véase la
sección 7.3
COMIENZO 50 ms de tiempo de espera Responder
STX
20ms entre
caracteres
Se acabó el tiempo
LONGITUD
(L)
Contar <L-1
GATHER (Count = L-1) y Otros

BYTES
(Count = L-1) y ETX
Suma de Mala suma de comprobación de
Comprobación
buena suma de comprobación
Hecho bien Done Malo

Responder Responder
Paquete de Respuesta de Estado Recibir Diagrama

West Chester
(s) PCN 500000008441

Tema
4.4.1 Control de errores de bucle invertido
En algunas condiciones, el huésped puede encontrar un fallo en el que los datos enviados al dispositivo se repite o bucle de vuelta al
servidor. Para controlar esto, el anfitrión debe marcar tan malo, cualquier paquete que coincide exactamente con el paquete que fue
enviado por el host al dispositivo. detectar de forma fiable este tipo de error se reduce todo tipo de problemas en el campo. El autor
habla de la experiencia personal en lo que respecta a este asunto.
4,5 ACK / NAK Processing

En una transacción eBDS cada lado puede decidir reconocer la transferencia mediante el envío de un ACK, o para denegar el
reconocimiento mediante el envío de un NAK. Esta información se transmite en el byte de control. El byte de control se presenta de la
siguiente manera:
Byte de control - Los bits
6 5 4 3 2 1 0
bit ACK / NAK
Tipo de dispositivo
Tipo de mensaje
La funcionalidad de ACK / NAK está incrustado en el juego del bit enviado por el anfitrión, en comparación con el enviado de forma
poco por el dispositivo. En general, los sistemas host indican un ACK al alternar su ACK / NAK de bits entre transacciones, e indican
una NAK utilizando el mismo valor dos veces en una fila. Dispositivos indican un ACK emparejando del huésped ACK / NAK bits y
un NAK devolviendo un diferente valor de ACK / NAK de bits del host. Esto se ilustra en la siguiente sección.

West Chester
(s) PCN 500000008441

Tema
4.5.1 Ejemplos ACK / NAK:
Anfitrión Dispositivo
En circunstancias normales, los suplentes de acogida

el valor del bit ACK en el byte de control envía al
dispositivo y el dispositivo vuelve un valor coincidente 1
en su bit ACK
en la respuesta. Esto es
1
se ilustra en este ejemplo:
A veces, el dispositivo no es capaz de responder al 0

comando de acogida. En estos casos, el anfitrión vuelve
a enviar el comando con el mismo valor de ACK. Esto se 0
ilustra en el primer ejemplo. los dispositivos más
antiguos son más propensos a este escenario, ya que
tienen menos procesamiento “poder”, sin embargo todos
los dispositivos de vez en cuando ser incapaz de
responder a un paquete de acogida. El sistema anfitrión 1
debe volver a intentar el comando. Véase el parámetro
de “no reconocer Tiempo de espera” de espera
en
la sección 4.5.2 para más detalles. Tiempo
Nota: Este caso es equivalente a los casos en que el

Procesar de nuevo
comando host o respuesta dispositivo se pierde en el
11
tránsito.

West Chester
(s) PCN 500000008441

Tema
En este ejemplo, el dispositivo no está listo para

procesar el paquete y explícitamente envía un NAK
para indicar esto al host. El anfitrión vuelve a intentar y
se acepta el comando.
1
NAK
Nota: Este caso también se produce durante la descarga 0
de flash donde un simple reintento no es suficiente. Véase
la sección 7.3 para más detalles.
Procesar de nuevo
1
4.5.2 Requisitos de temporización ACK / NAK
En general, un ACK a una respuesta puede esperar hasta la próxima encuesta programada y no se requiere tiempo especial. Un NAK sin
embargo, está sujeta a un límite especial. Bajo ciertas condiciones, el anfitrión debe NAK el dispositivo en menos de 100 ms para asegurar que
el dispositivo no proceder con el procesamiento de dinero. Si hay más de 100 ms tiempo transcurrido, el dispositivo procederá en el supuesto
de que el ACK de acogida está en camino. Dado que no hay manera de estar seguro cuando se dan estas condiciones la especificación
siguiente se aplica a todas las respuestas NAK:
Límite Limite
inferior superior
Tiempo de respuesta
50ms 100ms Cuando
anfitrión
se detecta
debeuna
comunicarse
condición con
de NAK,
el periférico
el en menos
inicial NAK
de 100 ms.
Siguiendo NAK Tiempo Si se requieren NAK posteriores, este tiempo más
50ms 3s
de respuesta relajado puede ser utilizado.
Si un dispositivo no responde con el tiempo, el anfitrión
No liberado Tiempo de
3s debe tener en cuenta el dispositivo a estar fuera de servicio.
espera

West Chester
(s) PCN 500000008441

Tema
Capa 5. La Red
Esta sección trata de las partes del protocolo eBDS que tratan el enrutamiento de los paquetes al dispositivo correcto. Hay dos
protocolos para hacer esto: Tipo de dispositivo de enrutamiento de un (propuesto) de protocolo para el enrutamiento basado en el tipo
de dispositivo y ABDS, una extensión a eBDS para apoyar conexión multi-gota de múltiples aceptadores de billetes a un solo puerto
host.
5.1 Tipo de dispositivos de enrutamiento de mensajes
Desde su creación, ha sido eBDS un protocolo utilizado para el control de aceptadores de billetes. Con los años, la necesidad existe para soportar
diferentes tipos de hardware de transacciones (como aceptadores de monedas, lectores de tarjetas inteligentes, y recicladores de facturas) con
TCA. Esta extensión protocolo propuesto permitiría a nuevos tipos de equipos que se añade con el daño a cualquier código de host existente.
Dispositivo de tipo de mensaje de enrutamiento es un método de envío de órdenes a diferentes tipos de dispositivos en un único sistema. Los
paquetes enviados por el anfitrión son enviados a tipos específicos de dispositivos. Dispositivos ignoran los mensajes no dirigidas a ellos. En los
paquetes de respuesta, dispositivos transmiten la espalda tipo de dispositivo al host para su confirmación.
El encaminamiento dispositivo de eBDS está codificada por el byte de control. El campo de tipo de dispositivo en este byte se utiliza para
identificar el tipo de dispositivo destinado a recibir un comando y para identificar el tipo de dispositivo que genera la respuesta.
6 5 4 3 2 1 0
bit ACK / NAK
Tipo de dispositivo
Tipo de mensaje
El campo Tipo de dispositivo del byte de control se decodifica la siguiente manera:
Bit 3 Bit 2 Bit 1 Valor Descripción

0 0 0 0 Aceptador de billetes con un solo depósito de garantía.
0 0 1 1 Reservado para uso futuro.


West Chester
(s) PCN 500000008441

Tema
Dispositivo de tipo de mensaje de encaminamiento no implica que los dispositivos están conectados en un bus multi-drop como en ABDS.
En general, el anfitrión tendrá que determinar el tipo de dispositivo conectado a cada puerto. Esto se realiza al tratar de comunicaciones
con los diferentes tipos de dispositivos a partir de 0 y procediendo hacia arriba hasta un dispositivo responde. Una vez que un dispositivo
responde, el anfitrión debe validar el tipo de dispositivo en el campo de respuesta para confirmar el tipo de dispositivo conectado.
5.2 ABDS de enrutamiento de mensajes
CCS S3K
El protocolo de enrutamiento de mensajes ABDS está diseñado para manejar múltiples aceptadores de billetes en una sola, multi-drop,
RS-485 línea de datos. En teoría, hasta 31 dispositivos se puede conectar a una sola línea, sin embargo, en la práctica un número mucho
menor (por lo general 2 a 5) son factibles. Se requiere que la capa física RS-485, ya que es la única interfaz que soporta la capacidad
requerida multi-drop. Cuando todavía era un interfaz actual, ABDS enrutamiento se considera un enfoque más. En los sistemas más
modernos, varios aceptadores de billetes están mejor acomodados con conexiones USB. El número de dispositivos que se está limitado
por la necesidad de sondear todas las unidades en la cadena de una manera oportuna. Por ejemplo, si se desea una tasa de sondeo de
200 ms, entonces el número máximo de dispositivos que se pueden conectar es de 200 ms / 50 ms o aproximadamente 4.
ABDS es una extensión de TCA que se identifica por el uso de paquetes especialmente diseñada. El diseño de estos paquetes para
el anfitrión y el dispositivo se ilustran a continuación.
El formato de un comando ABDS desde el host es:
Byte 1 2 3 4 .. 6 7 8 9
nombre STX Len CTL Bytes de datos ADR ETX CHK n
del valor 0x02 0x09 norte n .. n una 0x03

West Chester
(s) PCN 500000008441

Tema
El formato de una respuesta ABDS del dispositivo es:
Byte 1 2 3 4 .. 9 10 11 12
nombre STX Len CTL Bytes de datos ADR ETX CHK n
del valor 0x02 0x0C norte n .. n una 0x03
Dónde:
La dirección del dispositivo. (1..31, 0x01..0x1F). Esto se corresponde con el valor de dirección binaria establecido
ADR
en los interruptores DIP del dispositivo.
5.2.1 Requisitos de temporización ABDS
Desde ABDS se implementa en una compartida bus RS-485, es necesario el control de cuál de las partes tiene sus autobuses “drivers”
encendido. Para evitar conflictos en el bus, el conductor del autobús debe estar encendido no más de 1 ms antes de la transmisión
comienza y debe estar apagado no más tarde de 1 ms después de que se complete la transmisión.
Límite Limite
inferior superior
El puerto RS-485 Los conductores deben ser encendidos antes

El conductor del autobús Turn- de datos pueden ser enviados, pero no deben estar encendidos
0 1ms
Tiempo de entrega más de 1 ms antes del inicio de la transmisión de datos.
El RS-485 Los conductores no deben estar apagados

Conductor del autobús Turn antes del final de la transmisión de datos, pero deben
0 1ms
Off Hold Time estar fuera por no más de 1 ms después.
5.2.2 ABDS y (Interrupción) Modo Especial

Incompatible
Modo especial no puede ser utilizado en un sistema donde ABDS está en uso. Esto se debe al hecho de que todos los dispositivos
múltiples podría intentar enviar un carácter ENQ al mismo tiempo, y el resultado sería la corrupción de datos. El half-duplex,
carácter multi-gota de la capa física RS-485 de ABDS hace que sea incompatible con el modo especial (interrupción).

West Chester
(s) PCN 500000008441

Tema
Capa 6. La Sesión
En eBDS no existe el concepto de un ingreso o salida u otros conceptos que normalmente se asocian con una capa de sesión. No
obstante, la gestión de sesiones es crucial para el manejo adecuado del dinero del cliente.
En general, una sesión comienza cuando los iniciados del programa de acogida
comunicaciones con el dispositivo y termina cuando se termina que las comunicaciones. Esto se complica por el hecho de que el
anfitrión y el dispositivo pueden no ser en sincronía. Uno puede apagar sin el otro ser afectada:
La aplicación es responsable de manejar sus propios problemas de puesta en marcha y parada. El dispositivo informa a la aplicación de su
estado de la sesión a través del evento de encendido. Cuando el anfitrión detecta este evento, debe manejar los problemas de inicio de sesión
con el aceptador de billetes. Hasta ahora, todos los intentos para que el dispositivo envía un evento de apagado después de una pérdida de
alimentación han sido sin éxito.
El control de la potencia de la aceptación de billetes se detalla en el apartado 8.1.
6.1 Las variaciones en la presentación de informes Power Up
Existen en el campo, dos métodos distintos para un dispositivo aceptador de billetes para informar de que un evento de puesta en marcha se ha
detectado:
S1K CFMC CCS
Estos dispositivos siguen informando el estado de encendido hasta que el anfitrión ha completado tratar con todos los billetes que pueden
haber estado en la unidad en el momento.
S2K S3K
Estos dispositivos notifican el evento de encendido hasta que estén listos para procesar comandos desde el host.
Se observará que estos dos enfoques son incompatibles y que el código de host puede:
Código para el encendido de respuesta de los dispositivos conectados al host. Basado en el

dispositivo conectado aplicar el algoritmo apropiado.
Esperar hasta tres segundos para el estado de puesta en marcha a limpiar antes de proceder a ejecutar comandos para el aceptador
de billetes.
6.2 A partir del modo de descarga
Es posible que el dispositivo estará en modo de descarga de flash en el arranque. Hay un número de maneras que esto pueda
ocurrir:
• El dispositivo puede ser una unidad en blanco, simplemente carece de código de la aplicación.
• El anfitrión puede haber estado descargando el código a la unidad, y mientras lo hace, el anfitrión era de reposición, reiniciado o reiniciado. El
dispositivo se encuentra todavía en el modo de descarga.

West Chester
(s) PCN 500000008441

Tema
• El anfitrión puede haber estado descargando el código a la unidad, y mientras lo hace, todo el sistema se apaga. El dispositivo
se encuentra todavía en el modo de descarga. Cuando esto ocurre, el anfitrión tiene dos cursos de acción distintos. Puede:
1. Ir fuera de servicio. Este es el curso de acción que se espera de hosts que no admiten la descarga de flash del dispositivo.
2. Continuar descarga del firmware del dispositivo. Para facilitar esto, el anfitrión debe almacenar la ruta y el nombre del archivo de firmware
del dispositivo de almacenamiento no volátil de manera que se puede tener acceso si la sesión se abre en modo de descarga.
Para obtener más información sobre el modo de descarga y detectar el modo de descarga por favor ver secciones
7.1.2 y 7.3.
6.2 Finalización de la sesión
Cuando el sistema anfitrión se prepara para terminar las operaciones, se debe asegurar que el dispositivo se coloca en un modo
seguro para que no siga operando sin una aplicación o retener la moneda después del cierre de la aplicación. Con este fin, la
aplicación debe garantizar que:
• Cualquier moneda actualmente en proceso (fideicomiso) se devuelve al consumidor.

• El dispositivo está completamente desactivado de manera que ninguna moneda más será aceptada. Ver las secciones 7, 8 y 9
para más detalles sobre los comandos que se utilizan para lograr esto.

West Chester
(s) PCN 500000008441

Tema
7. La capa de presentación (por aceptador de billetes)
La capa de presentación de eBDS es específico para cada tipo de dispositivo soportado. En la actualidad, solamente un dispositivo de aceptación de
billetes con un solo depósito de garantía nota se define en eBDS.
La capa de presentación de la aceptación de billetes es impulsado desde el campo de tipo de mensaje en el byte de control. Este campo de
tres bits determina cómo se procesa el paquete.
6 5 4 3 2 1 0
bit ACK / NAK
Tipo de dispositivo
Tipo de mensaje
Bit 6 Bit 5 Bit 4 Valor Cuando enviada por el anfitrión Cuando enviado por el dispositivo
0 0 0 0 Reservado Reservado
0 X 1 1/3 Comando Ómnibus No utilizado
0 1 0 2 No utilizado Responder ómnibus
1 0 0 4 Solicitud Calibrar Calibrar Responder
1 0 1 5 Firmware Solicitar Descarga de firmware Responder
1 1 0 6 Solicitud de mando auxiliar Comando auxiliar Responder
Responder extendido de comandos o
1 1 1 7 Comandos extendidos
extendido Ómnibus Responder
7.1 El Comando de Ómnibus
Ómnibus, adj .:
Incluyendo o cubrir muchas cosas o clases: un ómnibus proyecto de ley comercial.
El concepto detrás del comando de ómnibus es sencilla. El host envía un paquete con prácticamente todo lo necesario para
controlar un aceptador de billetes en el dispositivo, y los dispositivos responde con un paquete con prácticamente todo lo que
necesita el huésped. Por lo tanto, en teoría, sólo se necesita un comando. En la práctica, la sofisticación del conjunto de comandos
hace mucho tiempo llegó al punto en que no era factible para encajar en todos los datos todo el tiempo. De este modo se han
creado los comandos auxiliares y extendidos. A pesar de esto, el comando general sigue siendo la misma base de TCA y el
comando de uso más frecuente. Cuando se habla de “sondeo” el aceptador de billetes, es este comando que se está refiriendo
también.

West Chester
(s) PCN 500000008441

Tema
7.1.1 Comando Ómnibus

El diseño de un comando de ómnibus desde el host es (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
nombre CTL 0 datos 1x Datos 1 Datos 2
del valor / 3x nn nn nn
Comando grados - CTL Byte Bit #

Nombre valor Descripción
0 ACK X valor de ACK / NAK. Ver sección 4.5 para más detalles.
1 - 0 debe ser 0
2 - 0 debe ser 0
3 - 0 debe ser 0
4 - 1 debe ser 1
No al por menor . Un marcador es un pedazo de papel apilado por el aceptador como un marcador
de evento en la caja. Por ejemplo, una disputa con el cliente. En algunas aplicaciones, especialmente
aquellos con casetes con cerradura no puede ser factible para examinar la caja de dinero en efectivo
inmediatamente. Un marcador puede utilizarse para marcar el lugar de la disputa para su posterior
examen.
CCS : Las dimensiones del marcador son 2,6” por 4”

5 Marcador S1K , S2K , S3K , CFMC : Las dimensiones del marcador son
2,6” por 5” 0
Discapacitado. Recomendado.
Habilitado. Advertencia: Dejando marcador activado puede causar billetes doblados a

ser tratado como marcadores resultantes de crédito perdido al cliente. Además,
1 algunas monedas tienen billetes de banco válidos que están muy cerca de dimensión
a un marcador. Esto aumenta el riesgo de un ser válida nota “robado”.
6 - 0 debe ser 0
Comando ómnibus - Datos Byte 0 (Conciso Nota de Información) Bit #

0123456 Denom1
Denom2 0 Disable Denominación n
Denom3
Denom4
Denom5
Denom6 1 Habilitar Denominación n
Denom7

West Chester
(s) PCN 500000008441

Tema
Comando ómnibus - Datos Byte 0 (Nota de Información Ampliada) Bit #

0x00 Todas las facturas están desactivadas.
0..6 billetes
Otro Facturas están habilitados basan en la nota extendida activar los valores.
Tenga en cuenta que las denominaciones también se pueden desactivar mediante la configuración del aceptador de billetes (por cualquiera cupón
de configuración o en algunos modelos, “DIP” cambia). En ese caso, el proyecto de ley
permanezca desactivada, incluso si se envía el comando eBDS habilitar.
Comando ómnibus - Datos Byte 1 Bit #

Enlace de datos de control del modo de capa. Ver secciones 4.2 y 4.3 para obtener detalles sobre el modo Normal
(sondeo) y los modos especiales (interrupción).
Modo
0
especial 0 Normal (sondeo) Modo. Recomendado.
1 Especial (Interrupción) de modo. Obsoleto

Este campo controla los criterios de validación se aplican a los billetes de banco.
0 Aceptan billetes en modo de alta aceptación. Recomendado.

1 Alta seguridad
Aceptan billetes en modo de seguridad alta. Tenga en cuenta que la aceptación de billetes válidos
1
puede sufrir.
Este campo controla la aceptación de billetes de banco en base a la orientación de las notas a medida que
entran en el aceptador de billetes. Tenga en cuenta que las orientaciones de cuentas también pueden ser
controlados por un cupón de configuración o en algunos modelos, “DIP” cambia. En todos los casos, se
utiliza lo más cálido de la configuración. Consulte las secciones 8.2.4 y 8.2.5 para más detalles sobre el
2..3 Orientación control de la orientación de la aceptación factura. 00
Controlar
1-manera: aceptan billetes alimentados borde derecho primero, boca arriba solamente. 01
2 vías: aceptan billetes alimentados boca arriba solamente.
1x De 4 vías: aceptan billetes alimentados ninguna manera.
Este modo determina cómo se manejan las cuentas después de las facturas han sido validados. Tenga en
cuenta que las facturas que no pueden ser validados siempre son rechazadas.
Modo de depósito de garantía está desactivado. (Non-escrow modo) Obsoleto

Cuando el aceptador de billetes valida un proyecto de ley, esta se acumula inmediatamente la
0
Modo de nota en la caja de efectivo. El anfitrión sólo recibe una notificación cuando se apila la nota.
4
depósito de garantía
Modo de depósito de garantía está activado. Recomendado.
Cuando el aceptador de billetes valida un proyecto de ley, se informa a la gran cantidad de la factura
1 mediante el envío de un evento de plica. Entonces el anfitrión decide si el proyecto de ley debe ser
apilado o devuelto al consumidor. Véase la sección 8.2.3 para las mejores prácticas de manejo de billetes.
0
No operacion.
Si hay un billete en depósito, la pila en la caja de efectivo. Tenga en cuenta que este comando sólo
Bill Comando
5 es válido si el modo de fideicomiso está habilitado y es un proyecto de ley en depósito. Este
Pila 1
comando y el comando Bill regreso son mutuamente excluyentes.

West Chester
(s) PCN 500000008441

Tema
0 No operacion.
Si un proyecto de ley se encuentra en depósito en garantía, devuélvalo al consumidor. Tenga en cuenta que
Bill comando
6 este comando sólo es válido si el modo de fideicomiso está habilitado y es un proyecto de ley en depósito.
de retorno 1
Este comando y el comando Bill Pila son mutuamente excluyentes.
Comando ómnibus - Datos Byte 2 Bit #

S2K , S3K : Hay momentos en que el aceptador de billetes es incapaz de dar crédito a una nota
debido a un problema en el transporte de la factura, y la factura no puede ser devuelto al cliente. En
estos casos, este bit determina cómo se deben manejar este tipo de cuentas.
Modo Empuje las notas sin crédito en el apilador y seguir operando.

0 0
NoPush Recomendado.
No empuje notas sin crédito. Estancar el aceptador de billetes con la nota todavía en la
trayectoria del billete. Se requiere una intervención a nivel de director / técnico. En la mayoría de
1
aplicaciones al por menor, teniendo el sistema fuera de servicio no es una opción deseable.
No al por menor , S1K , CFMC , CCS . Un cupón con código de barras es un documento con un número
de identidad de un código de barras único codificado en ella. Estos números de identidad se hace referencia
en contra de una base de datos externa por el anfitrión para determinar la validez y el valor del bono. Notas:
Bar vales de código deben insertarse “boca arriba”. cupones con código de barras sólo pueden ser
procesados si está activado el modo de depósito de garantía.
1 Código de barras
0 cupones con código de barra están desactivados.
cupones con código de barra están habilitadas. Con código de barras vales son reportados a la central
1 a través de los paquetes de respuesta de código de barras ómnibus expandidas. Véase la sección
7.1.3 para más detalles.
S1K , CHMC , CCS . Estos bits se utilizan para controlar el comportamiento del aceptador de billetes cuando un proyecto
de ley se encuentra en la trayectoria de billetes durante el encendido.
Véase la sección 6.1 para obtener más infor metro ación en la p Ower hasta cuestiones.
Bill Posición Pre- Post-fideicomiso

Fideicomiso Fideicomiso
Esperar a que
23 PUP-B-C proyecto de host con valor Pila con valor
00 Poder Política Up - A:
PUP ley de retorno desconocido. desconocido.
proyecto de Fuera de servicio Pila con la nota

01 Poder Política Up - B:
ley de retorno valor actual.
Fuera de Pila con valor
10 Potencia Política Up - C: Volver
cuenta servicio desconocido.
11 Reservado. - - -

West Chester
(s) PCN 500000008441

Tema
Hay dos métodos de presentación de informes el valor de los billetes de banco validado / apilada por el
aceptador de billetes. Para más detalles sobre el manejo de los valores de facturas ver sección 8.2.
Utilice escueta nota de informes. Las notas se presentan como la Denom1 genérica,
aunque 7.
Facturas son activar / desactivar a través de la Denom1 través de los bits de comando
0
Denom7 en todos los grados - Byte 0 facturas sean notificados al host a través del campo
Expandido
Denominación de tres bits en ómnibus Responder - Byte 2.
4 nota de
Información
CCS El uso adicional correspondió nota.
Todas las facturas se pueden desactivar a través del campo Bills en ómnibus Comando
- Byte 0.
1 Las facturas se activar / desactivar a través de la nota conjunto de comandos Inhibe. Véase la sección
7.5.2 a continuación para más detalles. Las cuentas son reportados a la central a través de los paquetes
de respuesta Resolución Miscelánea expandidos. Véase la sección 7.1.4 para más detalles. 0
Sin gastos de envío de cupones genéricos especial. Cupones MEI ™ genéricos (si es
compatible) se informan lo mismo que un billete de banco del mismo valor. cupones de
Ampliar los venta libre no son compatibles.
5 informes de S2K-EEUU , Activar informes detallados de cupones MEI ™ genéricos. El host recibe
cupón detalles sobre el tipo y la identificación de cupones genéricos alimentados en el aceptador de
1
billetes. Véase la sección 7.1.5 para más detalles.
6 Reservado 0 Actualmente 0, RFU
7.1.2 Estándar Ómnibus Responder

La respuesta más común a un Comando de Omnibus es la respuesta estándar. Sin embargo, si se habilitan o bien cupones con código de barras o
de informes nota extendida, entonces son posibles otros formatos de respuesta. Consulte las secciones 7.1.3 y 7.1.4 para más detalles sobre estas
respuestas, respectivamente.
La respuesta estándar a una orden de ómnibus tomar la siguiente forma (STX, Longitud = 0x0B, ETX y CHK omitida).
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 2n Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
del valor nn nn nn nn nn nn
Los bytes transmite CTL no hay datos más allá de identificar el tipo de respuesta y no se volverá a analizar.
Byte de datos 0 se utiliza para describir el estado actual o la actividad del aceptador de billetes. Esto se logra a través de un mapa de bits de
eventos, estados y condiciones, que se enumeran a continuación:

West Chester
(s) PCN 500000008441

Tema
Responder ómnibus - Datos Byte 0 Bit #

0 De marcha en vacío 1 El aceptador de billetes está en punto muerto entre los procesos de facturación.
1 aceptando 1 El aceptador de billetes está dibujando en un proyecto de ley.
de depósito en garantía
2 1 Existe un proyecto de ley válida en depósito.
Evento
3 Apilado 1 El aceptador de billetes está apilando un proyecto de ley.
Stacked
4 1 El aceptador de billetes ha apilado un proyecto de ley.
Evento
5 volviendo 1 El aceptador de billetes está volviendo una factura al cliente.
Devolución de
6 1 El aceptador de billetes ha vuelto una factura al cliente.
Evento
Hay algunos puntos que llevan un examen más detenido.

Si los siete bits son 0, entonces el aceptador de billetes está fuera de servicio.
Todos los bits que terminan en “ing” son condiciones de estado transitorio. Eso significa que, dependiendo de la tasa de votación, velocidad de
alimentación de la factura, o simplemente suerte, estos estados pueden ser o no ser “visto” por el sistema anfitrión. Es por ello que el uso de estos bits
para impulsar cualquier acción que se anfitrionas obsoleto .

La unidad ha detectado condiciones compatibles con un intento de defraudar al sistema.
Esto también puede ocurrir cuando hay un problema de transportar el billete a la caja de
0 Engañado 1
dinero en efectivo. MEI no lo hace
ofrecer un método para eventos de trucos del sistema / de la prueba.
El documento presentado a la aceptación de billetes no se pudo validar y fue
1 Rechazado 1
devuelto al cliente. 0
La trayectoria del billete es clara.
2 Apretado La trayectoria del billete se bloquea y el aceptador de billetes ha sido incapaz de resolver el
1
problema. Se requiere la intervención. 0
Operación normal
3 apiladora completa La caja de efectivo está lleno de billetes de banco y no más pueden ser aceptados. Se
1
requiere la intervención. 0
Cassette La caja de efectivo se ha eliminado. Sin facturas pueden ser aceptados.
4
Attached 1 La caja de efectivo está unido a la unidad.
S2K , S3K . El cliente está tratando de alimentar otra nota mientras que la nota anterior
5 En pausa todavía
1 se está procesando. El cliente debe retirar la nota para permitir que continúe el
procesamiento. Es posible aceptadores de billetes campo Calibrar. En general, debido a los
avances en los procesos utilizados en la fabricación y la calibración auto continuo, esto no es
necesario. Calibración de una unidad con un documento incorrecto reducirá en gran medida el
rendimiento. Para obtener más información sobre la calibración de campo por favor refiérase a la
Calibración en sección 7.2
6
Progreso
0 Operación normal
La unidad está en modo de calibración. Se requiere la intervención para alimentar un documento de
1
calibración especial en el aceptador de billetes.

West Chester
(s) PCN 500000008441

Tema

El aceptador de billetes se ha encendido. El anfitrión debe hacer frente a cualquier nota en
0 Encender 1 fideicomiso, y reinicializar el aceptador de billetes a los ajustes de funcionamiento
deseadas.
Comando
1 1 El aceptador de billetes recibido un comando no válido.
inválido
El aceptador de billetes ha encontrado un problema y está fuera de servicio. Se
2 Fracaso 1
requiere la intervención.
El campo de valor factura conciso. Este campo es válida cuando el aceptador de billetes está en terso modo
y, o bien el depósito o los bits apiladas son conjunto. (Ver Ómnibus Responder - Datos Byte 0 para los
detalles de esos eventos)
Desconocido / Sin crédito. Esta condición se devuelve para una amplia variedad de
razones:
Cuando un marcador o bien se fideicomisado o apilado. Cuando una barra codificada
bono se escrowed o apiladas. Cuando se apila un documento engañado o atascado.
000 Cuando un documento atascado se devuelve al consumidor. En el modo de nota
extendida, una nota es en depósito o apiladas. Al encender o dinero en efectivo caja de
3..5 Bill Valor instalación cuando los realiza la unidad de un “ensayo y pila” de acción.
001 Denom1 - Típicamente $ 1 010

Denom2 - Típicamente $ a 2 011 Denom3 -
Típicamente $ 5 100 Denom4 -
Típicamente $ 50
111 Denom7 - Normalmente $ 100
6 - 0 Actualmente 0, RFU

El aceptador de billetes está estancado (en modo NoPush), con un billete de banco todavía en la
0 estancado 1
trayectoria del billete.
flash Una descarga de flash esté listo para comenzar. El anfitrión puede comenzar a enviar los
1 1
Descargar registros de descarga. Ver sección 7.3 y @ para más detalles.
No al por menor , Obsoleto . Este bit indica que el proyecto de ley ha llegado a un
2 Pre-stack 1
punto en el proceso de apilamiento en que ya no se puede recuperar. 0
24 códigos de barras de caracteres se convertirán a 18 códigos de barras de caracteres.

prima de
3
código de barras 24 códigos de barras de caracteres no se convertirán a 18 códigos de barras de caracteres. 0
1
No se admite el comando de consulta capacidades del dispositivo. (* 1)

4 casquillos de dispositivos
1 se admite el comando de consulta Capacidades de dispositivo.

West Chester
(s) PCN 500000008441

Tema
Nota: En algunas implementaciones de eBDS, el bit Caps de dispositivo se suprime para mantener la compatibilidad con los
sistemas host no conformes. Véase la sección 7.4.14 para más detalles.

Número de
0..6 nn valor A que representa el modelo del aceptador de billetes. Esto es
modelo interpretado en las tablas siguientes.
serie 1000 Hex decimal ASCII Producto

0x01 1 Descontinuado, ZT1000, EE.UU.
0x0C 12 Descontinuado, ZT1107, EE.UU.
0x0F 15 Descontinuado, ZT1200, Australia
0x14 20 Obsoleta, ZT1200, EE.UU.

0x41 sesenta y cinco UNA AE2600 Gen2D, Australia
0x42 66 si AE2800 Gen2D, Rusia
0x43 67 C AE2600 Gen2D, Canadá
0x44 68 re AE2800 Gen2D, Euro
0x45 69 mi Reservados (economía de EE.UU. VN2300)
0x46 70 F Reservados (VN2600 Gen2B y 2D, China)
0x47 71 sol Reservados (AE2800 Gen2D, Argentina)
0x4D 77 METRO AE2800 Gen2D, México
0x50 80 PAG AE2600 Gen2B, C y D, US premium
0x51 81 Q Discontinuas, Filipinas
0x57 87 W AE2800 Gen2D, Brasil
0x58 88 X AE2800 Gen2D, Estados Unidos se expandió

0x1E 30 Descontinuado, Serie 3000 VFX (BDS)
0x1F 31 Obsoletos, serie 3000 eBDS
Casflow SC Hex decimal ASCII Producto

0x4A 74 J Descontinuado, Cashflow SC 66, Código monolítico
0x54 84 T Cashflow SC 83, estratificación de Notas / Extendido
0x55 85 T Cashflow SC 66, estratificación de Notas / Extendido

El número de versión del código de firmware en el aceptador de billetes. Esto puede ser
codificada como:
código de S1K , S3K , CFMC , CCS : A siete bit de valor binario con una división
0..6 nn
revisión implícita por 10. (versiones 0.0 a través de 12.7)
S2K : Un valor BCD 1 ¾ dígitos con una división implícita por 10. (versiones 0.0 a
través de 7.9).
Tenga en cuenta que, en general, el número de versión del código no es suficiente para identificar ese software. Esto debido a que diferentes
partes de software utilizan números de versión independientes. Los números de versión son

West Chester
(s) PCN 500000008441

Tema
sólo es útil para comparar el firmware de la misma parte del software. Véase la sección 8.3 para más detalles sobre cómo determinar el
software en una unidad.
7.1.3 Extensión de código de barras ómnibus Responder
S1K CFMC CCS No al por menor
Si se habilitan cupones con código de barras, a continuación, el aceptador de billetes enviará esta respuesta cuando un cupón con código de
barras es en depósito. Esta respuesta contiene un 28 bytes adicionales de datos de códigos de barras decimales codificados en ASCII. Datos 0 a
través de datos 5 se interpretan igual que en la respuesta estándar detalla en el apartado 7.1.2. Esto termina de datos cuando la primera 0x28,
ASCII “(” carácter se produce el siguiente es el diseño de este paquete (STX, Longitud = 0x28, ETX y CHK omitida).:
Byte 3 4 5 6 7 8 9
nombre CTL Tipo sub Los datos 0 Datos 1 Datos 2 Datos 3 Datos 4
del valor 0x7n 0x01 nn nn nn nn nn
10 11 12 38
Datos 5 Ext datos 0 Ext datos 1 Ext datos 27

ooo
nn nn nn nn
Una carga útil de datos típico para un comprobante de código de barras 18 dígitos podría ser codificada como:
012345678901234567 ((((((((((
Es entonces la responsabilidad del sistema host para determinar lo que (si lo hay) valor a asignar a este bono. El anfitrión debe comandar el
aceptador de billetes a cualquiera pila o devolver el bono. Es importante tener en cuenta que cuando se apila el bono, una respuesta ómnibus
estándar con un valor factura concisa de desconocido es enviado por el aceptador de billetes. Por lo tanto, la única posibilidad de que el sistema
anfitrión tiene que capturar los datos de código de barras es cuando el bono está en depósito en garantía.
Nota: En algunas versiones comerciales de la línea de productos Cashflow-SC, soporte para documentos con códigos de barras se ha
eliminado.
7.1.4 extendido Ómnibus Ampliado Nota Responder
CCS
Si la presentación de informes nota ampliada está activada, el aceptador de billetes enviará esta respuesta cuando un billete de banco
es en depósito o se apila. La respuesta contiene 18 bytes de datos adicionales que describen el billete de banco con gran detalle. Datos
0 a través de datos 5 se interpretan igual que en la respuesta estándar detalla en el apartado 7.1.2. El siguiente es el diseño de este
paquete (STX, Longitud = 0x1E, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6 7 8 9
10 11 12 28

ooo
nn nn nn nn
Los datos de factura extendida se describe a continuación:
El Valor de ejemplo
Campo campo Descripción
desplazamiento de bytes (2000 Yen nota)
Índice 0 No se utiliza para plica o apilados notas 0x00
Un código de moneda de tres caracteres ASCII. Véase la norma ISO 4217 para
Código ISO 1..3 "GUAY"
los detalles
Valor base 4..6 Un código ASCII valor decimal de tres caracteres “002”
Un valor de signo codificado ASCII para el exponente. Este campo
Firmar 7 “+”
es o bien un “+” o “-”
ASCII valor decimal codificado para la potencia de diez que la
Exponente 8..9 base debe multiplicarse ya sea por (si Signo es “+”) o dividido por “03”
(si es Señal “-“)
Un campo binario único personaje que codifica la orientación de la
factura. 0x00 = borde derecho, boca arriba 0x01 = borde derecho,
boca abajo 0x02 = Borde izquierdo, boca arriba 0x03 = Borde
izquierdo, boca abajo Nota: En general, este campo sólo es correcta
Orientación 10 si el bit de orientación extendido 0x00
Está establecidoen el dispositivo
capacidades mapa. Véase la sección 7.4.14.

Una carta ASCII que documenta el tipo de nota. Esto
Tipo 11 corresponde a los datos de la tarjeta de identidad variante. "UNA"
Una carta ASCII que los documentos de la serie de notas. Esto

Serie 12 corresponde a los datos de la tarjeta de identidad variante. "UNA"
Una carta ASCII que los documentos de la revisión del núcleo

Compatibilidad 13 reconocimiento utilizados. Esto corresponde a los datos de la tarjeta "SI"
de identidad variante.
Una carta ASCII que documenta la versión de criterios de
Versión 14 reconocimiento de la nota. Esto corresponde a los datos de la "UNA"
tarjeta de identidad variante.

Reservado 15..17 3 bytes reservados para uso futuro. N/A
En este ejemplo: Bill Valor = 002 x 10 + 03 = 2 x 1.000 = 2.000 ¥ alimentados borde derecho primero, boca arriba.

West Chester
(s) PCN 500000008441

Tema
Una traza típica de la actividad implicada en el procesamiento de un proyecto de ley se ilustra a continuación: (HOST / DISPOSITIVO )
Un proyecto de ley llega al depósito de garantía (se puede saber qué tipo de factura? Vea la respuesta más abajo)
02 08 10 12 03 7F 1C 69
02 1E 70 02 04 10 00 00 55 12 00 55 53 44 30 30 31 2B 30 30 00 43 41 42 42 00 00 00 03
65
Los comandos host pueden apilar la factura.

02 08 11 12 03 7F 3C 48
02 1E 71 02 04 10 00 00 55 12 00 55 53 44 30 30 31 2B 30 30 00 43 41 42 42 00 00 00 03
64
Apilado
02 08 10 12 03 7F 1C 69
02 0B 08 10 00 20 00 55 12 03 74
Apilado
02 08 11 12 03 7F 1C 68
02 0B 08 10 00 21 00 55 12 03 75
Apilado
02 08 10 12 03 7F 1C 69
02 0B 08 10 00 20 00 55 12 03 74
Apilado
02 08 11 12 03 7F 1C 68
02 0B 08 10 00 21 00 55 12 03 75
Apilado
02 08 10 12 03 7F 1C 69
02 0B 08 10 00 20 00 55 12 03 74
apilada
02 08 11 12 03 7F 1C 68
02 1E 71 02 11 10 00 00 55 12 00 55 53 44 30 30 31 2B 30 30 00 43 41 42 42 00 00 00 03
71
Respuesta: USD $ 1, el borde derecho, boca arriba, C, A, B, B.
Un caso especial es el de una pila elemento desconocido en el modo de nota extendida. En este caso la totalidad de los dieciocho bytes de datos
de notas extendidas son nulos o cero bytes. Un ejemplo de un paquete de este tipo se muestra a continuación: Host - Comando:
02 08 10 12 03 7F 1C 69
Device - Responder:
1E 70 02 02 11 10 00 00 55 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
2A

West Chester
(s) PCN 500000008441

Tema
7.1.5 extendido Ómnibus Ampliado cupón de respuesta
S2K-EEUU
Si la presentación de informes nota gastado está activada, el aceptador de billetes enviará esta respuesta cuando un billete de
banco es en depósito o se apila. La respuesta contiene 6 bytes adicionales de datos que describen el cupón en detalle. Datos 0 a
través de datos 5 se interpretan igual que en la respuesta estándar detalla en el apartado 7.1.2. El siguiente es el diseño de este
paquete (STX, Longitud = 0x12, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9 10
nombre CTL Sub Tipo Los datos 0 Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
del valor 0x7n 0x04 nn nn nn nn nn nn
11 12 13 14 15 dieciséis
Cupón 1 Cupón 2 Cupón 3 Cupón 4 relleno relleno
0x0n 0x0n 0x0n 0x0n 00 00
El cupón 1 a través de 4 bytes representan un valor de 16 bits que pueden extraído como sigue (usando “C” array estilo indexación
comenzando en 0 en vez de 1).
CouponData = ((respuesta [11] y 0x0F) << 12) +

((Respuesta [12] y 0x0F) << 8) + ((respuesta [13] y
0x0F) << 4) + ((respuesta [14] y 0x0F)
+ 1);
Este valor de dieciséis bits puede ser entonces más futuro analizado como:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Descripción
vvv valor del cupón 3 bits
0 0 0 0 0 Vend Libre 1 $ 1 de
descuento 0 1 0 $ La cupón 2 0
1 1 cupón de $ 5
1 xx Reservado
nnnnnnnnnnnn norte ID de proveedor 13 bit

West Chester
(s) PCN 500000008441

Tema
7.2 El orden de calibración

Obsoleto
Todos los aceptadores de billetes tratados en este documento tienen la capacidad de realizar un procedimiento de calibración de campo. En
este procedimiento el host emite un comando de calibración y un documento de calibración se introduce en el aceptador de billetes. Los
documentos de calibración están diseñados específicamente para este propósito y se deben mantener limpios y sin arrugas. En particular, lo
siguiente debe NO ser utilizado como un documento de calibración:
Banco nota de la moneda de ningún tipo.

Trozos de papel en blanco o revistas cortan a la forma y tamaño de una factura. El documento de calibración de
un modelo de proyecto de ley aceptor diferente.
aceptadores de billetes modernos contienen rutinas de auto-calibración que continuamente ajustar y afinar el subsistema de
reconocimiento. Por lo tanto rara vez es necesario calibración de campo. Sin embargo, si se requiere un documento de calibración,
se debe obtener de un centro de servicio autorizado. El diseño de una orden de calibración desde el host es (STX, Longitud = 0x08,
ETX y CHK omitido):
Byte 3 4 5 6
nombre CTL Datos 0 Datos 1 Datos 2
del valor 0x4n nn nn nn
Los aceptores responde con una respuesta ómnibus estándar con un valor de CTL de 4x.
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
del valor 0x4n nn nn nn nn nn nn
Cuando el receptor está listo para comenzar el proceso de calibración, se establece la calibración mordió en Datos1, bit 6 (véase la
sección 7.1.2 Ómnibus Responder - Datos Byte 1). Después de este bit se establece el anfitrión debe regresar a la votación a través del
comando estándar de ómnibus (ver sección 7.1.1) En este punto el documento de calibración puede ser insertado en la unidad. El
documento se aspira y regresó. Cuando se retira de la unidad, se completará el procedimiento de calibración. El aceptador indicará que
la calibración se ha realizado correctamente restableciendo misma e informar de un evento de encendido (véase la sección 7.1.2
Ómnibus Responder - Byte de datos 2). Si la calibración falla, la unidad permanecerá en el modo de calibración hasta restablecer
manualmente.
Nota: El comando calibrar un no debe intentarse si el aceptador de billetes indica que su estado es distinto de “ralentí” nada (véase
la sección 7.1.2 Ómnibus Responder - Datos Byte 0).

West Chester
(s) PCN 500000008441

Tema
7.3 El comando Descarga de firmware

S1K Gen2D S3K CFMC CCS
La mayor parte de MEI aceptadores de billetes se pueden actualizar con el nuevo software a través de la interfaz eBDS. compatibilidad
con el host del proceso de descarga permite que el aceptador de billetes que se actualiza al nivel de código actual, sin necesidad de
intervención manual. El anfitrión puede ser remotamente mandó a actualizar las unidades, ahorrando tiempo y dinero.
7.3.1 El ritmo de las comunicaciones durante la descarga.

el modo de descarga es algo diferente en el enfoque que otros modos. Normalmente, las transacciones se envían a una velocidad que permite a los
eventos desde el aceptador de billetes que deben procesarse sin necesidad de utilizar una gran cantidad de ancho de banda. Este no es el caso en el
modo de descarga. En el modo de descarga, una gran cantidad de necesidades de datos que se enviará a la aceptación de billetes. Por lo tanto se espera
que el anfitrión enviará los datos tan rápidamente como el protocolo permite.
Otra consideración sin embargo, es el hecho de que muchos dispositivos son incapaces de procesar el tráfico de comunicaciones
mientras están en medio de la programación de la memoria flash. Para permitir esto, el tiempo de espera de respuesta para
respuestas de dispositivo debería aumentarse de 50 ms a 200 ms. Este cambio en el algoritmo de recibir respuesta se llama en el
punto 4.4.
7.3.2 Descripción general del proceso de descarga de Flash
El proceso de descarga tiene tres fases distintas: A partir, la descarga y el acabado.
Comenzando: El propósito de la fase de arranque es conseguir que el dispositivo fuera del modo de funcionamiento normal y en modo de
descarga. Esto se realiza por primera votación la unidad, con un comando como se muestra a continuación (STX, Longitud = 0x08, ETX y CHK
omitido):
Byte 3 4 5 6
del valor 0x1n 00 00 00
Este es un comando ómnibus estándar (como se especifica en la sección 7.1.1) con toda la aceptación y las opciones de apagado. Hay
dos respuestas posibles que puedan ocurrir. Si la unidad no está actualmente en modo de descarga, se le enviará una respuesta
ómnibus estándar. Esto se detalla en la sección 7.1.2. Si la unidad ya está en modo de descarga, la siguiente respuesta se enviará
(STX, Longitud = 0x09, ETX y CHK omitido):
Byte 3 4 5 6 7
nombre CTL Pkt # Pkt # Pkt # Pkt #
del valor 0x5n 0n 0n 0n 0n
El número de paquete de 16 bits se codifica, cuatro bits a la vez, en los bytes 4 a 5 (nibble alto primero). Si la unidad ya está en
modo de descarga a continuación la fase de arranque se ha completado. De lo contrario será necesario colocar el dispositivo en
modo de descarga. Esto se logra con el inicio

West Chester
(s) PCN 500000008441

Tema
comando de descarga. Este comando se muestra a continuación (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x5n 00 00 00/10
La respuesta a esta orden es (STX, Longitud = 0x0B, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 Datos 1 2 Datos Datos 3 Datos 4 Datos 5
del valor 0x5n XX XX XX 00/02 XX XX
Donde “XX” son valores ignorados y datos 3 contiene el estado de la unidad. Mientras la descarga de Flash bits (ver sección 7.1.2) no
está establecido, el dispositivo aún no está en modo de descarga y el comando Descarga de inicio debe ser reenviado. Cuando se
establece que los bits, la unidad está a la espera del huésped para entrar en la fase de descarga del proceso de descarga.
Descargar: En esta fase, el nuevo código se envía a la unidad y programado en la memoria flash. Comenzando en el inicio del
archivo, el host envía 32 bloques de bytes de datos al dispositivo (Nota: se requiere el archivo a un múltiplo de 32 bytes largos).
Esto se hace a través de la descarga de datos a continuación el comando show (STX, Longitud = 0x49, ETX y CHK omitido):
Byte 3 4 5 6 7
nombre CTL Pkt # pkt # Pkt # Pkt #
8 9 70 71
Datos 1 Hola Datos 1 Mín Datos de 32 Hola Datos Mín 32

ooo
0n 0n 0n 0n
La respuesta a este comando es la descarga en respuesta progreso (ya se ha visto más arriba) se muestra aquí (STX, Longitud =
0x09, ETX y CHK omitido):
Byte 3 4 5 6 7
nombre CTL Pkt # Pkt # Pkt # Pkt #

West Chester
(s) PCN 500000008441

Tema
Crucial para el proceso está respondiendo correctamente a los dispositivos de ACK / NAK de los datos.
• Si el dispositivo de ACKs el paquete, el anfitrión debe pasar a la siguiente paquete.

• Si los dispositivos NAK al paquete, entonces el huésped necesita “resincronización” con el dispositivo. Esto se logra cambiando el
número de bloque para el valor contenido en la respuesta más uno. Esto se muestra a continuación (utilizando “C” array estilo
indexación comenzando en 0 en vez de 1).
ReplyBlockNum = (((respuesta [3] y 0x0F) << 12) +

0x0F) << 4) + ((respuesta [6] y 0x0F)
+ 1)) y 0xFFFF;
Si el dispositivo envía más de 10 NAK consecutivos, paquetes inesperados, suma de comprobación u otros errores, el anfitrión debe
abortar el proceso de descarga. En este punto, el dispositivo es probable fuera de servicio y se requiere una intervención para restablecer
el funcionamiento normal.
Refinamiento: Una vez que el último bloque de datos se han enviado al dispositivo, el anfitrión debe esperar. Hay dos fases en esta
espera.
En una fase (pasivo), el anfitrión no hace nada. Simplemente se encuentra inactivo (por lo menos con respecto a la
siendo el dispositivo programado) y espera. Esto tiene una duración de al menos quince segundos. Después de este tiempo, el dispositivo también
haber terminado la fase de descarga y el anfitrión puede comenzar a esperar a que las comunicaciones de reinicio y reinicio.
En la fase dos (activo), el anfitrión lentamente encuestas (aproximadamente una vez por segundo) el dispositivo, esperando a que el reinicio. Cuando
el dispositivo responde, el proceso de descarga se ha completado. Si una respuesta normal fue dada por el dispositivo, a continuación, la
programación está completa y el dispositivo está listo para volver a entrar en servicio. Si la unidad se encuentra todavía en el modo de descarga en
este punto, significa que existe una de dos situaciones:
1) La descarga falla por alguna razón. (Archivo no válido, tipo equivocado de archivo, archivo / dispositivo son incompatibles, los errores en
la comunicación, etc.)
2) En los dispositivos con los programas de flash multi-parte, el anfitrión tiene que descargar el siguiente componente de archivo de la
aplicación del dispositivo. Actualmente en el Casflow-SC66, SC83 y SC85 productos soportan múltiples partes de flash
(específicamente dos partes, la aplicación y variante).
7.3.3 Descargar Diagrama de Flujo
El siguiente es un resumen diagrama de flujo del proceso de descarga:

West Chester
(s) PCN 500000008441

Tema
Comience Flash Descargar
Modo de
interrupción
Comenzando Encuesta
especial debe estar
aceptador de billetes
en OFF
No en modo de descarga Enviar Inicio

En el modo de descarga
Descargar
En el modo de descarga
descarga
Inicializar al primer
bloque de datos.
descargan Descargar
Enviar
Datos
Consigue
Paquete de
Respuesta
ACK NAK
Bloquear ++; Pausa 200 ms Bloquear =

Errores = 0; ReplyBlock + 1;
Errores ++;
Hecho
Espere 60
segundos
Refinamiento
Encuesta
aceptador de billetes
Sin respuesta
Espere 1
segundo good Demasiados errores
Responder
descarga Succeds descarga falla

West Chester
(s) PCN 500000008441

Tema
7.4 Los comandos auxiliar

Los Comandos auxiliares se utilizan para proporcionar funcionalidad fuera del alcance de la orden Omnibus (s) en las secciones
anteriores. Estos comandos son específicos tanto de código base y no hay instrumentos de base de código de todos los comandos, así
que asegúrese de comprobar los iconos de compatibilidad antes de cada sección.
Todos los comandos auxiliares toman la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
nombre CTL A los datos Los datos B Mando
del valor 0x6n X Y Z
Donde el campo Cmd es el valor del comando de la operación y de datos A y B Los datos son argumentos a ese comando. Los
comandos soportados son los siguientes:
A los datos de datos B Comando Descripción

0x00 0x00 0x00 consulta de software CRC
0x00 0x00 0x01 consulta Cash Box total
0x00 0x00 Dispositivo se restablece 0x02 Query
0x00 0x00 0x03 Claro Cash Box total
0x00 0x00 0x04 Tipo de consulta aceptador
0x00 0x00 Número de serie de consultas 0x05 aceptador
0x00 0x00 Número de pieza de arranque 0x06 consulta aceptador
0x00 0x00 Número Parte de Aplicación de 0x07 consulta Aceptador
0x00 0x00 0x08 consulta aceptador nombre de variante
0x00 0x00 Número de parte Variante 0x09 consulta aceptador
0x00 0x00 Los totales de consulta 0x0A aceptador de Auditoría tiempo de la vida
0x00 0x00 Medidas 0x0B consulta aceptador de auditoría FC

0x00 0x00 Medidas de rendimiento Auditoría 0x0C consulta aceptador
0x00 0x00 Capacidades de dispositivo 0x0D de consulta
0x00 0x00 ID 0x0E Consulta a una aplicación Aceptador
0x00 0x00 0x0F consulta Aceptador Variant ID
0x00 0x00 0x10 consulta BNF Estado
Bisel 0x00 0x11 Conjunto Bisel
0x7F 0x7F Restablecer 0x7F aceptador suave
Todos los demás valores están reservados para uso futuro.
7.4.1 Consulta de software CRC
S1K Gen2D S3K CFMC CCS
Este comando se utiliza para consultar el dispositivo para la CRC de 16 bits de los contenidos de flash. El comando de consulta CRC
toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6
nombre CTL A los datos Datos B Mando
del valor 0x6n 00 00 00
La respuesta desde el dispositivo toma la forma (STX, Longitud = 0x0B, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 1 Datos 2 Datos Datos 3 Datos 4 Datos 5
del valor 0x6n CRC CRC CRC CRC XX XX
Cuando los datos CRC de 16 bits es enviado en datos 0 a través de datos 3, cuatro bits a la vez. Esto puede ser extraído como se muestra a
continuación (utilizando “C” array estilo indexación comenzando en 0 en vez de 1).
CRC_Value = ((respuesta [3] y 0x0F) << 12) +

0x0F) << 4) + ((respuesta [6] y 0x0F)
);
7.4.2 Consulta de Cash Box total
Gen2D
Este comando se utiliza para consultar la cantidad de moneda que se ha contado de entrar en la caja de efectivo. Este conteo, almacenado en un
almacenamiento no volátil, se representa como un número entero de 24 bits, aunque la mayoría de los ejércitos lo almacenará como un valor de 32.
El comando caja de efectivo total de la consulta toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x01
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 1 Datos Los datos Los datos 4 de datos 5 Datos
del valor 0x6n Datos Datos de datos 2 de datos 3 de datos Datos
Cuando el valor total es enviada en datos 0 a través de datos 5. Esto puede ser extraído como se muestra a continuación (utilizando “C” array estilo
indexación comenzando en 0 en vez de 1).

West Chester
(s) PCN 500000008441

Tema
TOTAL_VALUE = ((respuesta [3] y 0x0F) << 20) +

0x0F) << 12) + ((respuesta [6] y 0x0F) << 8) +
((respuesta [7] y 0x0F ) << 4) + ((respuesta [8] y
0x0F)
);
NOTA: Cuando se quita la caja de efectivo (véase la sección 7.1.2, Casete adjunta) se supone que se está vaciando. Así, cuando
se emite este mandato al aceptador de billetes después de que la caja de efectivo se restaura, el recuento proyecto será devuelto
al host y luego la cuenta se pone a cero para comenzar a contar billetes en la caja vacía.
Si el host “sabe” que la caja de efectivo se retira posiblemente mientras el sistema estaba apagado, puede utilizar el comando Borrar
Cash Box total (sección 7.4.4) para borrar la cuenta.
7.4.3 dispositivo se restablece de consulta
Gen2D CCS
Este comando se utiliza para consultar el número de veces que el dispositivo se ha restablecido. Esto se representa como números enteros de 24
bits, aunque la mayoría de los anfitriones se almacena como un valor de 32. El comando de consulta de dispositivo se restablece toma la forma
(STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 1 Datos Los datos Los datos 4 de datos 5 Datos
del valor 0x6n Datos Datos de datos 2 de datos 3 de datos Datos
Cuando el Contador de Reinicio es enviada en datos 0 a través de datos 5. Esto puede ser extraído como se muestra a continuación (utilizando “C”
array estilo indexación comenzando en 0 en vez de 1).
Reset_Count = ((respuesta [3] y 0x0F) << 20) +

0x0F) << 12) + ((respuesta [6] y 0x0F) << 8) +
((respuesta [7] y 0x0F ) << 4) + ((respuesta [8] y
0x0F)
);

West Chester
(s) PCN 500000008441

Tema
7.4.4 Borrar Cash Box total

Gen2D
Este comando se utiliza para restablecer el recuento de billetes que entran en la caja de efectivo. El comando clara cuadro total de efectivo
toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
No se devuelven datos al host en la respuesta, se muestra a continuación forma (STX, Longitud = 0x19, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9
del valor 0x6n 00 00 00 00 00 00
7.4.5 Tipo de consulta aceptador
CCS
Este comando se utiliza para determinar el tipo de aceptador de billetes instalado. El comando de consulta de tipo aceptor toma la
forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
Los datos devueltos por el dispositivo toma la forma de una cadena ASCII que es o 20 bytes de longitud o es terminada por un
carácter no imprimible. El paquete de respuesta se muestra a continuación (STX,
Longitud = 0x19, ETX y CHK omitido):
Byte 3 4 5 22 23
nombre CTL Datos 0 1 Los datos 18 de datos 19 datos

ooo
del valor 0x6n ASCII ASCII ASCII ASCII
Una gran cantidad puede determinarse a partir de la información devuelta. A continuación se muestra cómo esta serie están codificados para los
productos Cashflow SC-:

West Chester
(s) PCN 500000008441

Tema
Bill Camino Interfaz

Cassette producto
Talla Ancho Opción Descripción Opciones
CAROLINA DEL SUR Flujo de Caja-SC
<Ninguno> cassette de 600 nota

L 1200 casete nota
METRO cassette de 900 nota
66 trayectoria de billetes 66mm
83 trayectoria del billete de 83 mm (Internacional)
85 trayectoria del billete de 85 mm (Reino Unido)
01 RS-485 estándar
04 EBDS aislamiento óptico
07 RS-232 estándar
21 RS-485 al por menor
27 RS-232 al por menor
28 Interfaz USB al por menor
<Ninguno> Ninguno
Kit al por menor (Hood, pestillo de cerradura, y
-R
firmware específico al por menor)
Lo mismo que -R con la adición de

- RB un alimentador Nota Bunch.
Lo mismo que -R con la capacidad de

- RE notas manejar hasta 177 mm de largo.
Lo mismo que -R con la adición de un

- RL
bloqueo cinta.
- RLB El mismo que -R

Además decon el
un bloqueo cinta y una
nota Manojo alimentador.
Nota: si se ha sustituido la unidad de reconocimiento (cabeza), es posible que el tipo de cadena aceptora será incorrecta si la
unidad de reemplazo no era exactamente del mismo tipo.
7.4.6 Consulta aceptador Número de serie
CCS
Este comando se utiliza para devolver el número de serie de la unidad de reconocimiento (cabeza). La consulta de comandos
aceptor número de serie toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6
Byte 3 4 5 22 23
nombre CTL Datos 0 1 Los datos 18 de datos 19 datos

ooo
Algunos datos útiles se pueden determinar a partir del número de serie devuelto. A continuación se muestra cómo esta serie están codificados
para los productos Cashflow SC-:
Semana El último
Secuencial
de dígito del Configuración de ubicación Descripción
Código Contar
Año año
El número de la semana
00..51 cuando la unidad fue
fabricada.
El número del año, cuando la

0..9 unidad fue fabricada.
El sitio donde se fabricó la

0..9
unidad.
El código de configuración
00..99
(estándar build)
00 000 a Un número secuencial de

través de unidades hizo esa semana.
99.999

West Chester
(s) PCN 500000008441

Tema
7.4.7 Consulta de Número de pieza de arranque aceptador
CCS
Este comando se utiliza para devolver el número de parte del software del componente de arranque del firmware del dispositivo. El
comando boot número de pieza consulta aceptor toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
Los datos devueltos por el dispositivo toma la forma de una cadena ASCII que es de 9 bytes de longitud. El paquete de respuesta se muestra a
continuación (STX, Longitud = 0x0E, ETX y CHK omitido):
Byte 3 4 5 11 12
nombre CTL Datos 0 1 Los datos 7 Los datos 8 Datos

ooo
El número de pieza se presenta de acuerdo con las siguientes reglas:
Proyecto dígito de
Prefijo Descripción de la versión
Número control
28 General de Software de prefijo
000 .. 999 número de pieza secuencial
0..9 Dígito de control.
000..999 formateado como V1.23
Nota: El componente de software de arranque está instalado en fábrica y no debe ser cambiado, ajustado o utilizado como un disparador / entrada
para cualquier acción del sistema anfitrión, función o modo.
7.4.8 Consulta de Número de Parte de Aplicación del aceptador
CCS
Este comando se utiliza para devolver el número de pieza de software del archivo que contiene el componente de aplicación del
firmware del dispositivo. La aplicación de comandos número de pieza consulta aceptor toma la forma (STX, Longitud = 0x08, ETX y
CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6
Byte 3 4 5 11 12

ooo
Proyecto dígito de
Número control
000 .. 999 número de pieza secuencial.
7.4.9 Consulta aceptador nombre de variante
CCS
Este comando se utiliza para devolver el nombre del componente variante del firmware. Los determina software variante que los
billetes de banco son aceptadas por la unidad y el nombre de la variante, identifica el país de origen de los billetes de banco. El
comando de consulta aceptor nombre de variante toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 34 35
nombre CTL Datos 0 1 Los datos Los datos Los datos

ooo
del valor 0x6n ASCII ASCII ASCII 30 ASCII 31
Los nombres de las monedas soportadas son representados como códigos ISO de tres caracteres. Si se admite más de una
moneda, que están separadas por guión bajo “_” caracteres. Por ejemplo “USD_CAD” significaría un conjunto mixto factura EE.UU.
/ Canadá. Para más información sobre los descriptores de divisa, consulte http://en.wikipedia.org/wiki/ISO_4217 .
7.4.10 Consulta de Número de parte Variante aceptador
CCS
Este comando se utiliza para devolver el número de pieza de software del archivo que contiene el componente variante del firmware
del dispositivo. La variante de comando número parte de consulta aceptor toma la forma (STX, Longitud = 0x08, ETX y CHK
omitido):
Byte 3 4 5 6
Byte 3 4 5 11 12

ooo
Proyecto dígito de
Número control
28 archivo combinado Software Prefijo

49 Prefijo variante de software

West Chester
(s) PCN 500000008441

Tema
Archivos combinada y la parte aplicación / Variante Números: Es posible cargar una unidad tanto con una aplicación y una variante, al
mismo tiempo, con un archivo llamado un archivo combinado. En este caso, las unidades de venta al por menor devolverán el número
de parte del archivo combinado tanto para el componente de aplicación (ver sección 7.4.8) y el componente de variante. Esto se puede
deducir por el hecho de que la variante y la aplicación tendrán el mismo número de referencia. Si los componentes de software se
instalan normalmente, los números de pieza de cada componente individual se devuelve para la aplicación y la variante.
No al por menor
Para algunas versiones del producto Cashflow SC-no minorista, números de parte de los componentes de software individuales se
devuelven independientemente de la forma en que se cargaron y la referencia del archivo combinado no se devuelve.
7.4.11 consulta de totales aceptador de Auditoría Tiempo de la vida
CCS
Este comando se utiliza para los datos de auditoría durante la vida útil de retorno guardados en ciertos datos operativos esenciales. El comando de
consulta aceptador de la vida de auditoría totales de tiempo toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0A
Estos datos se formatea como una matriz de enteros de 32 bits, donde cada entero es codificado nibble como ocho bytes de datos
extendidos. Los datos toma la siguiente forma (STX, Longitud = variables, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 10 11
nombre CTL 0x6n datos datos datos

ooo
del valor Field1.0 Datos Field1.1 Field1.6 Field1.7
Similar para el campo 2
Similares para el campo N-1
datos datos datos datos

ooo
FieldN.0 FieldN.1 FieldN.6 FieldN.7
Cuando la gama de campos se asignan como:
Campo Datos
Tamaño númerobytes
en Descripción Ancho
Los datos del mapa ID. La revisión de los datos reportados en esta orden, Medidas
de consulta aceptador de Auditoría de QP y Medidas de consulta aceptador
1 8 32
desempeño de la auditoría. 1 - La revisión inicial.
2 8 32 Horas de trabajo
3 8 32 Inicia total del motor
4 8 32 Alcanzado el total de los documentos del fideicomiso de Posición
5 8 32 Notas total Reconocido

6 8 32 Total de billetes validados
La gama de campos se puede extraer como se muestra a continuación (utilizando “C” array estilo indexación comenzando en 0 en vez de 1).
num_fields = ((respuesta [1] - 5) / 8; for (i = 0; i <num_fields; i

++) {
Los campos [i] = ((respuesta [8 * i + 4] y 0x0F) << 28) +

((Respuesta [8 * i + 5] y 0x0F) << 24) + ((respuesta [8 * i + 6] y
0x0F) << 20) + ((respuesta [8 * i + 7] y 0x0F) < <16) +
((respuesta [8 * i + 8] y 0x0F) << 12) + ((respuesta [8 * i + 9] y
0x0F) << 8) + ((respuesta [8 * i + 10] y 0x0F) << 4) +
((respuesta [8 * i + 11] y 0x0F)
);
}

West Chester
(s) PCN 500000008441

Tema
Nota: En teoría, hasta 15 valores de datos pueden ser devueltos por este comando.
7.4.12 Medidas de consulta aceptador de Auditoría QP
CCS
Este comando se utiliza para devolver “QP” datos de auditoría guardados en la tasa general de aceptación factura. La auditoría
consulta aceptor de comandos medidas QP toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0B
Estos datos se formatea como una matriz de enteros de 16 bits, donde cada entero es codificado nibble como cuatro bytes de datos
extendidos. Los datos devueltos toma la siguiente forma (STX, Longitud = Variable, ETX y CHK omitido):
Byte 3 4 5 6 7
Similar para el Campo 1
ooo
Campo Datos
0 4 dieciséis Última 100 billetes de tasa de aceptación.
1 4 dieciséis Inicia total del motor.

2 4 dieciséis Total de documentos apilados.
3 4 dieciséis Alcanzado el total de los documentos del fideicomiso de Posición
4 4 dieciséis Total de documentos han pasado Reconocimiento

West Chester
(s) PCN 500000008441

Tema
Campo Datos
5 4 dieciséis Total de documentos han pasado Validación
6 4 dieciséis Reconocimiento total Rechazos
7 4 dieciséis Rechazo Total Security
8 4 dieciséis Los rechazos de orientación total movilidad reducida
9 4 dieciséis Rechazo total del documento de movilidad

10 4 dieciséis Los rechazos totales de error de alimentación rápida
11 4 dieciséis Total de documentos insertados mientras está incapacitado
12 4 dieciséis Total anfitrión documento de devolución de Rechazos
13 4 dieciséis Los códigos de barras decodificado total
num_fields = (respuesta [1] - 5) / 4; para (i = 0; i

<num_fields; i ++) {

0x0F) << 4) + ((respuesta [4 * i + 7] y 0x0F)
);
}
7.4.13 Medidas de rendimiento de las consultas aceptador de auditoría
CCS
Este comando se utiliza para devolver datos de auditoría guardados en el funcionamiento básico del mecanismo aceptador de billetes.
La auditoría consulta aceptor de comandos medidas de rendimiento toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0C
Estos datos se formatea como una matriz de enteros de 16 bits, donde cada entero es codificado nibble como cuatro bytes de datos
extendidos. Los datos devueltos toma la siguiente forma (STX, Longitud = Variable, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6 7
ooo
Campo Datos
0 4 dieciséis Total transversal del canal 0 Rejects
1 4 dieciséis Total transversal del canal 1 Rechazos
2 4 dieciséis Total de todos los tipos de atascos
3 4 dieciséis Los esfuerzos de recuperación total de atascos
4 4 dieciséis Total de rechazar los intentos con el atasco
5 4 dieciséis Stacker total de atascos

6 4 dieciséis Número total de atascos sin recuperación Activado
7 4 dieciséis Número total de Fuera de las condiciones de servicio
8 4 dieciséis Número total de Fuera de Condiciones de pedir
9 4 dieciséis Número total de horas de funcionamiento
Número total de documentos de más de longitud máxima permitida
10 4 dieciséis
Número total de documentos menos de longitud mínima permitida

11 4 dieciséis
Número total de documentos que no pudo llegar a posición de custodia

12 4 dieciséis
13 4 dieciséis Número total de calibraciones

14 4 dieciséis Número total de Restablece
15 4 dieciséis Número total de intentos de descarga de Flash
dieciséis 4 dieciséis Número total de condiciones de casete completa
17 4 dieciséis Número total de casete condiciones han quitado las

West Chester
(s) PCN 500000008441

Tema
num_fields = (respuesta [1] - 5) / 4; para (i = 0; i

<num_fields; i ++) {

0x0F) << 4) + ((respuesta [4 * i + 7] y 0x0F)
);
}
7.4.14 Capacidades de dispositivo de consulta
Este comando se utiliza para consultar las capacidades del dispositivo. En general, este comando sólo se debe enviar a los dispositivos que
cuentan con el apoyo indicada mediante el establecimiento de los DeviceCaps bit en un sondeo de respuesta (véase la sección 7.1.2). Sin
embargo esto no siempre es posible. Dado que algunos hosts no toleran el ajuste de los DeviceCaps mordió, un método alternativo se debe
encontrar para la determinación de las capacidades del dispositivo. En este método, Query Software CRC y una consulta de los comandos de
capacidades del dispositivo se envían al dispositivo. Si los datos 0 ... 5 bytes de datos de respuesta son no se admite lo mismo, entonces
capacidades del dispositivo de consulta. Si los resultados son diferentes, entonces los datos devueltos por Capacidades de dispositivo de consulta
puede ser procesada. Las capacidades del dispositivo de consulta de comandos CRC toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0D
Byte 3 4 5 6 7 8 9
del valor 0x6n CAP0 Cap1 Cap2 Cap3 Cap4 CAP5
Los bytes Cap se utilizan para representar diferentes capacidades de los dispositivos. Se especifican en la tabla siguiente:

West Chester
(s) PCN 500000008441

Tema
Gorra Poco Capacidad

0 1 = modo PUP Extended es compatible. 1
1 = manejo orientación Extended es compatible. 2
1 = QueryAcceptorApplicationID y
QueryAcceptorVariantID son compatibles. 3
0
1 = QueryBNFStatus se apoya 4
1 = documentos de prueba son compatibles. 5
1 = Set bisel es compatible.
6 Reservados, 0
1 Todas Reservados, 0
Tenga en cuenta que los campos reservados se pueden utilizar para describir nuevas capacidades en cualquier momento. código anfitrión debe no interrogar a
dichos campos reservados.
ID 7.4.15 Consulta a una aplicación Aceptador
CCS
Este comando se utiliza para devolver el número de parte del software del componente de aplicación real del firmware del
dispositivo. La aplicación de comandos número de pieza consulta aceptor toma la forma (STX, Longitud = 0x08, ETX y CHK
omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0E
Byte 3 4 5 11 12

ooo

West Chester
(s) PCN 500000008441

Tema
Número de dígito de
proyecto control
7.4.16 consulta Aceptador Variant ID
CCS
Este comando se utiliza para devolver el número de parte del software del componente variante actual del firmware del dispositivo.
La variante de comando número parte de consulta aceptor toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 00 00 0x0F
Byte 3 4 5 11 12

ooo
Proyecto dígito de
Número control
28 archivo combinado Software Prefijo

49 Prefijo variante de software

West Chester
(s) PCN 500000008441

Tema
7.4.17 Consulta de Estado BNF
CCS
Este comando se utiliza para determinar el estado del accesorio Nota alimentador Bunch. Este comando sólo se puede llamar si el
bit QueryBNFStatus se encuentra en el mapa de capacidad del dispositivo (ver sección 7.4.14). El comando toma la forma (STX,
Byte 3 4 5 6
La respuesta toma la forma (STX, Longitud = 0x0B, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9
nombre CTL Los datos 1 Los datos Datos 2 Datos 3 Datos 4 Datos 5
del valor actuales 0 0x6n de estado 00 00 00 00
Dónde:
Nombre valor Significado

0 Un BNF no se detecta. 1
Presente A BNF se detecta.
Otro reservado 0
OK 1
Estado Se ha detectado un error
Otro Reservado
7.4.18 Conjunto Bisel
CCS
Este comando se utiliza para anular la configuración por defecto del bisel de la cubierta del aceptador de billetes. Este comando sólo se puede
llamar si el bit SetBezel se encuentra en el mapa de capacidad del dispositivo (ver sección
7.4.14). El comando toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n Bisel 00 0x11

West Chester
(s) PCN 500000008441

Tema
Cuando el valor bisel es:
Código Bisel Bisel

0x00 bisel estándar
0x01 plataforma bisel
0x02 Bisel de diagnóstico mejorada
Byte 3 4 5 6 7 8 9
del valor 0x6n 0x00 0x00 0x00 0x00 0x00 0x00
Nota: Bajo ciertas condiciones, el aceptador de billetes se realice un restablecimiento automático después de este comando. En los modelos actuales, esto se
produce cuando se cambia de un bisel de plataforma para un bisel diferente. El ajuste del bisel se encuentra actualmente almacenado en la tarjeta de interfaz de
microcontrolador.
Restablecer 7.4.19 aceptador suave
Gen2D S3K CCS
Este comando se utiliza para restablecer el aceptador de billetes. No hay necesariamente una respuesta a esta orden, pero algunos datos
pueden ser enviados por el dispositivo. El sistema anfitrión debe ignorar todos los datos enviados por el dispositivo durante al menos un
segundo. Además, el dispositivo puede tomar tanto como quince segundos para volver a la operación normal después de estar de reset y el
anfitrión debe sondear, una vez por segundo, durante al menos quince segundos hasta que las respuestas de dispositivos. El comando de
restablecimiento aceptor suave toma la forma (STX, Longitud = 0x08, ETX y CHK omitido):
Byte 3 4 5 6
del valor 0x6n 0x7F 0x7F 0x7F
PRECAUCIÓN: La intención de este comando es permitir que un sistema host para establecer una condición inicial cuando se inicia
el software. El uso del comando de reinicio del aceptador de suave a condiciones de error claros (como atascado, fracaso o caja
completa) no se recomienda ya que esto puede causar un problema para ser más severa.

West Chester
(s) PCN 500000008441

Tema
7.5 Los comandos extendidos
Los comandos extendidos utilizan tipo de mensaje 7 para proporcionar fuera de la funcionalidad que proporciona los comandos estándar
combinadas. El uso de mensaje de tipo 7 se complica por el hecho de que se utiliza para los comandos especiales de acogida, responde a
los comandos de acogida especiales y respuestas especiales a los comandos estándar. Para facilitar estos usos, se proporciona la
siguiente tabla:
Tipo
Tipo Longitud Anfitrión Dispositivo
sub
Un código de barras de respuesta a la norma
0x01 0x28 No utilizado
mando.
Nota consulta extendido
0x0A No utilizado
comando Especificación
La respuesta a la extendida Nota mandatos
0x02
de Query Especificación
0x1E No utilizado
Una nota de respuesta ampliada a la
comando estándar.
La respuesta a las Inhibe la nota conjunto ampliado para
0x0C No utilizado. algunos aceptadores de billetes. Véase la sección 7.5.2
0x03 para más detalles.
Inhibe establecidos Nota expandidas

0x11 No utilizado.
mando.
Establecer tiempo de espera de depósito de garantía
7x 0x0B No utilizado.
mando.
La respuesta al conjunto de depósito de garantía
0x04 0x0C No utilizado.
comando de tiempo de espera.
Una respuesta a Cupón Ampliado

0x12 No utilizado.
el comando estándar.
La respuesta al conjunto de activos
0x0C No utilizado.
Número de comandos.
0x05
Establecer el número de activos
0x19 No utilizado.
mando.
0x06 No utilice / Reservados
La respuesta al conjunto extendido
0x0C No utilizado.
comando PUP.
0x07
Conjunto PUP extendido
0x0E No utilizado.
mando.
Nota: Las longitudes distintas de las enumeradas en la tabla representan paquetes inválidos.
7.5.1 Consulta Especificación Nota Ampliado

CCS
Cuando se habilita el procesamiento de billetes de banco ampliado, este comando se utiliza para recuperar la especificación de una
nota. El formato de este comando se muestra a continuación (STX, Longitud = 0x0A, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6 7 8
nombre CTL subtipo Los datos 0 Datos 1 Datos 2 Índice
del valor 0x7n 0x02 nn nn nn nn
Donde los datos de 0 a través de datos 2 se definen los mismos que los valores similares en el comando estándar ómnibus (ver
sección 7.1.1), pero tenga en cuenta que la posición de estos bytes se desplaza una posición debido a la presencia de un byte
subtipo. El valor del índice es el índice de la nota se va a consultar. Este índice va de 1 a 1, aunque más allá de la última nota
definida. Los datos devueltos por el aceptador de billetes está formateado como (STX, Longitud = 0x1E, ETX y CHK omitidas):
Byte 3 4 5 6 7 8 9
10 11 12 28

ooo
nn nn nn nn
Los datos de factura extendida se describe a continuación:
El Valor de ejemplo
Si se trata de un billete válido, entonces el valor de este byte
debe coincidir con el valor del índice en el comando. Si este valor
Índice 0 es cero, entonces el anfitrión ha llegado al final de la tabla factura 2
y debe dejar de iterar.
Un código de moneda de tres caracteres ASCII. Véase la norma ISO 4217 para
Código ISO 1..3 "GUAY"
los detalles
Valor base 4..6 Un código ASCII valor decimal de tres caracteres “002”
Un valor de signo codificado ASCII para el exponente. Este campo
Firmar 7 “+”
es o bien un “+” o “-”
ASCII valor decimal codificado para la potencia de diez que la
Exponente 8..9 base debe multiplicarse ya sea por (si Signo es “+”) o dividido por “03”
(si es Señal “-“)
Orientación 10 No utilizado. Siempre 0x00. 0x00
Una carta ASCII que documenta el tipo de nota. Esto
Tipo 11 corresponde a los datos de la tarjeta de identidad variante. "UNA"
Una carta ASCII que los documentos de la serie de notas. Esto

Serie 12 corresponde a los datos de la tarjeta de identidad variante. "UNA"

West Chester
(s) PCN 500000008441

Tema
El Valor de ejemplo
Una carta ASCII que los documentos de la revisión del núcleo
Compatibilidad 13 reconocimiento utilizados. Esto corresponde a los datos de la tarjeta "SI"
de identidad variante.
Una carta ASCII que documenta la versión de criterios de
Versión 14 reconocimiento de la nota. Esto corresponde a los datos de la "UNA"
tarjeta de identidad variante.

Reservado 15..17 3 bytes reservados para uso futuro. N/A
7.5.2 conjunto ampliado Nota Inhibe
CCS
Este comando se utiliza para controlar la aceptación de billetes de banco en una base del tipo de nota. Este comando tiene el
siguiente formato STX, Longitud = 0x11, ETX y CHK omitido):
Byte 3 4 5 6 7
nombre CTL Tipo sub Los datos 0 1 datos datos 2
del valor 0x7n 0x03 nn nn nn
8 9 15
Activar 1 Habilitar 2 Habilitar 8

ooo
nn nn nn
Donde los datos de 0 a través de datos 2 se definen los mismos que los valores similares en el comando estándar ómnibus (ver sección
7.1.1), pero tenga en cuenta que la posición de estos bytes se desplaza una posición debido a la presencia de un byte subtipo. El permitir
que los datos se utiliza para activar las facturas por el índice. Esto se muestra a continuación:
El bit 6 bit 5 Bit 4 Bit 3 bit 2 Bit 1 Bit 0

Activar 1 Bill 7 Bill 6 Bill 5 Bill 4 Bill 3 Bill 2 Bill 1
Habilitar 2 Bill 14 Bill 13 Bill 12 Bill 11 Bill 10 Bill 9 Bill 8
Habilitar 3 Bill 21 Bill 20 Bill 19 Bill 18 Bill 17 Bill Bill 16 15
Habilitar 4 Bill Bill 28 27 26 Bill Bill 25 Bill 24 Bill 23 de la ley 22
Habilitar 7 Bill Bill 49 48 47 Bill Bill 46 Bill 45 La ley 44 de Ley 43
Habilitar 8 - - - - - - Bill 50
Datos 0 a través de datos 5 se interpretan igual que en la respuesta estándar detalla en el apartado 7.1.2. La respuesta no contiene
datos extendidos (STX, Longitud = 0x0B, ETX y CHK omitido):

West Chester
(s) PCN 500000008441

Tema
Byte 3 4 5 6 7 8 9
nombre CTL Datos 0 0x2n Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
del valor nn nn nn nn nn nn
En algunos aceptadores de billetes, se le da una respuesta alternativa. Esta respuesta también contiene datos extendidos (STX, Longitud =
0x0C, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9 10
nombre CTL Tipo sub Los datos 0 Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
7.5.3 Establecer tiempo de espera de depósito de garantía
CCS No al por menor
Este comando se utiliza para establecer el tiempo de espera de depósito en garantía del aceptador de billetes. Este comando tiene el siguiente
formato (STX, Longitud = 0x0B, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9
Nombre CTL Tipo sub Los datos 0 Datos 1 Datos 2 notas Código de barras
Valor 0x7n 0x04 nn nn nn nn nn
Donde los datos de 0 a través de datos 2 se definen los mismos que los valores similares en el comando estándar ómnibus (ver sección 7.1.1),
pero tenga en cuenta que la posición de estos bytes se desplaza una posición debido a la presencia de un byte subtipo. Las notas y los campos
de código de barras establecer el tiempo de espera para los billetes de banco y códigos de barras, respectivamente. Este es un valor de 1 a 127
segundos, o cero para deshabilitar el tiempo de espera. Por defecto, los dos tiempos de espera están desactivados. La respuesta no contiene
datos extendidos (STX, Longitud = 0x0C, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9 10
Datos 0 a través de datos 5 se interpretan igual que en la respuesta estándar detalla en el apartado 7.1.2.

West Chester
(s) PCN 500000008441

Tema
7.5.4 Conjunto Número de activos
CCS No al por menor
Este comando se utiliza para escribir una cadena en el número de activos del aceptador de billetes y la etiqueta de la memoria no volátil opcional
instalada en la caja de efectivo. Esto permite que la caja de dinero en efectivo para vincularse de nuevo a un aceptador de billetes específica en un
momento posterior cuando se lee la etiqueta. Este comando se muestra a continuación (STX, Longitud = 0x19, ETX y CHK omitida).
Byte 3 4 5 6 7
nombre CTL Tipo sub Los datos 0 1 datos datos 2
8 9 23
activos 0 1 del activo, activos 16

ooo
nn nn nn
subtipo. Los bytes de activos contienen una cadena activo (número) que está programado en la unidad.
En la respuesta, los datos del 0 al 5 de datos se interpretan como en la respuesta estándar detalla en el apartado 7.1.2. La
respuesta no contiene datos extendidos (STX, Longitud = 0x0C, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9 10
Nota: este comando no es compatible con el actual código base menor.
7.5.5 Consulta Tabla de valores
CCS Obsoleto No al por menor
Este comando es específico para un cliente particular y no debe utilizarse. No se documenta aquí.
Nota: este comando no es compatible con el actual código base menor.

West Chester
(s) PCN 500000008441

Tema
7.5.6 Ajuste del modo PUP extendido
CCS
Este comando se utiliza para establecer el modo de procesamiento PUP extendida en aquellos aceptadores de billetes que la soportan. Esto puede
determinarse mediante el examen del mapa de capacidad de dispositivo (véase la sección 7.4.11 para los detalles). Este comando tiene el formato de la
siguiente manera STX, Longitud = 0x0E, ETX y CHK omitido):
Byte 3 4 5 6 7
nombre CTL Tipo sub Los datos 0 Datos 1 Datos 2
8 9 10 11 12
modo Pre_Escrow At_Escrow Post_Escrow Pre_Stack
nn nn nn nn nn
subtipo. El valor del modo se interpreta como sigue:
Modo Descripción
Utilice el modo PUP-A. Pre_Escow, At_Escrow, Post_Escrow y Pre_Stack se ignoran. "SI"
"UNA"
Utilice el modo PUP-B. Pre_Escow, At_Escrow, Post_Escrow y Pre_Stack se ignoran. "C"
Utilice el modo PUP-C. Pre_Escow, At_Escrow, Post_Escrow y Pre_Stack se ignoran. "MI"
Utilice el modo PUP-E. En este modo, los bits PUP normales son ignorados y Pre_Escow,
At_Escrow, Post_Escrow y Pre_Stack especifican el comportamiento PUP. Vea abajo.
Utilice el modo PUP-A. Pre_Escow, At_Escrow, Post_Escrow y Pre_Stack se ignoran.

Otro
PUP procesamiento es controlado por donde el proyecto de ley fue cuando la energía falló. Las siguientes posiciones se definen para los
fines de potencia hasta la manipulación.
Bill Posición Descripción

está en el proceso de elaboración en la unidad. La determinación del tipo de
El proyecto de ley Pre_Escrow
proyecto de ley aún no se ha hecho.
At_Escrow El proyecto de ley está en plica y ha sido verificado.
Post_Escrow El comando de apilar se le dio la nota, pero el proyecto de ley todavía puede ser
devuelto.
Se da la orden para apilar la nota, pero el proyecto no puede ser devuelto.
Pre_Stack

West Chester
(s) PCN 500000008441

Tema
El control del proceso de encendido se muestra en la tabla siguiente:
Pre
Valor
Al depósito de garantía
Mensaje de depósito
Pre de
depósito
garantía Acción
de garantía pila
0 Ir fuera de servicio.
1 Apilar la factura sin crédito.
2 - Devolver el proyecto de ley.
3 - Apilar el proyecto de ley con el crédito.
4 - - - Erase de crédito y esperar a que el anfitrión para decidir.

5 - - - Preservar crédito y esperar a que el anfitrión para decidir.
En la respuesta, los datos del 0 al 5 de datos se interpretan como en la respuesta estándar detalla en el apartado 7.1.2. La
respuesta no contiene datos extendidos (STX, Longitud = 0x0C, ETX y CHK omitido):
Byte 3 4 5 6 7 8 9 10
Nombre CTL Tipo sub Los datos 0 Datos 1 Datos 2 Datos 3 Datos 4 Datos 5
Valor 0x7n 0x07 nn nn nn nn nn nn
7.6 Procesamiento Unidos
En esta sección se deberá describir los estados de procesamiento asociados con el manejo de los billetes y documentos bancarios en dos
modos básicos de operación.

West Chester
(s) PCN 500000008441

Tema
7.6.1 Unidos Procesamiento en Modo No-plica
Obsoleto
Lo siguiente ilustra los estados de procesamiento que normalmente se encuentran durante la manipulación de un proyecto de ley en el modo de no escrow:
UNA
De marcha en vacío Rechazado UNA
Ocurre 0 o más
veces
aceptando
Se produce 1 o
más veces
Ocurre 1 vez
Apretado
Apilado
apilada
apilada Sin
crédito
UNA UNA
Tenga en cuenta que el valor de los billetes sólo se transmite al host cuando se apila la nota. En caso de un problema de apilamiento de la
nota o un atasco, no hay manera de determinar el valor de los billetes aceptados. Esto se puede contrastar con el modo de fideicomiso (se
ilustra en la siguiente sección) donde el anfitrión es capaz de registrar el valor de los billetes en plica.

West Chester
(s) PCN 500000008441

Tema
7.6.2 Procesamiento de los Estados en el modo de depósito de garantía
Recomendado
Lo siguiente ilustra los estados de procesamiento que normalmente se encuentran durante la manipulación de un proyecto de ley en el modo de plica:
UNA De marcha en vacío Rechazado UNA
Ocurre 0 o más
veces
Se produce 1 o
aceptando más veces
Ocurre 1 vez
Fideicomiso
Las Anfitrión
devoluciones pilas de
de acogida Nota billetes
volviendo Apilado Apretado
apilada
devuelto apilada Sin
crédito
UNA UNA UNA

West Chester
(s) PCN 500000008441

Tema
8. La capa de aplicación (por aceptador de billetes)
8.1 Tareas de inicio de aplicaciones
Cuando la primera aplicación comienza a comunicarse con el aceptador de billetes, que comienza el sondeo del dispositivo. Dependiendo de la
respuesta del dispositivo, se tomarán las medidas oportunas para establecer el aceptador de billetes. Esto se describe a continuación:
CONEXIÓN
encuesta de la
Ninguna respuesta aceptador
de billetes
En el modo de descarga.
encuesta OK
espera de depósito de garantía
Establecer indicadores
de capacidad de dispositivo,
Tiempo de
PUP_ESCROW
Configurar
las Tablas
Bill
DESCARGAR
DESCONECTADO CONECTADO REINICIO
Hay cuatro resultados posibles: Conectado
El aceptor está listo para otros comandos.

PUP_ESCROW Un estado intermedio en el que el anfitrión debe decidir aceptar o rechazar una nota en depósito
en el momento de aceptación de billetes encendido.
REINICIO descargar el receptor tiene que tener una aplicación cargado en él. DESCONECTADO
El intento de conexión no tuvo éxito

West Chester
(s) PCN 500000008441

Tema
Manejo 8.2 Aplicación de divisas
8.2.1 Manejo de dinero en el modo Conciso:
Aunque se prefiere el modo expandido, que no es compatible con todas las plataformas de producción. En esos casos, se debe
utilizar el modo conciso. Un problema que se plantea por terso modo es que los billetes de banco no son identificados en cuanto a
su valor, pero se dan meramente un identificador de 1 a 7. La tabla siguiente muestra cómo, con la ayuda del byte número de
modelo definido en la sección 7.1. 2 por lo general es posible determinar el valor de la moneda:
País Estados UnidosArgentina Australia Brasil Canadá Europa México Desconocido Rusia
Código ISO ARS
Dólar estadounidense MXN BRL CAD EUR MXP RUR ***
Modelo
"SOL" "UNA" 15 “W” "C" "RE" "METRO" "SI" Otro
Números 20,“J”,
31, “X” “P”
Índice
1 $1 $1 - $ 5 de - 1R - 5€ 20P 10R $1
2 $2 $2 2P $ 10 - 2R - 10 € 50P 50R $2
3 $5 $5 5P $ 20 $ 5 5R $5 - - 100R $5
4 $ 10 $ 10 10P - $ 10 $ 10 10R - - 500R $ 10
5 $ 20 $ 20 20P - $ 20 20R $ 20 - - - $ 20
6 $ 50 - 50P - $ 50 $ 50 50R - - - $ 50
7 $ 100 - 100P - $ 100 $ 100 100R - - - $ 100
Tenga en cuenta que para la mayoría de los casos, la mesa de los Estados Unidos de $ 1 a $ 100 puede ser utilizado. Esas entradas anteriormente marcados con
(US) se pueden utilizar con seguridad la mesa de los Estados Unidos. Cuando nos enfrentamos a un modelo desconocido, esta tabla debe ser utilizado por defecto.
En otros casos, una tabla de factura alternativa necesitará sustituido para la tabla predeterminada cuando se detecta el número de modelo requerido.
8.2.2 Manejo de Dinero en modo expandido:
Si el número de modelo de la unidad eBDS es “T” o “U”, entonces los soportes de dispositivos expandido informes nota. Siempre que
sea posible, la presentación de informes nota ampliado se debe utilizar para mejorar la portabilidad de código y fiabilidad. informes
nota expandida permite que las aplicaciones pueden utilizar en varios lugares sin tener que volver a escribir. Se permite que los
cambios en la moneda y ofrece por mucho mayor control sobre el tipo y la orientación de notas aceptados.
La cantidad de un informe nota expandido puede extraerse con el siguiente fragmento de código “C”.
unsigned long N, D; // Numerador y denominador.

int E; // multiplicador exponente.
cantidad doble; // cantidad de moneda.
int i;
N = (ExtData [4] - '0') * 100 +

(ExtData [5] - '0') * 10 + (ExtData [6] - '0');

West Chester
(s) PCN 500000008441

Tema
E = (ExtData [8] - '0') * 10 +

(ExtData [9] - '0');
si (ExtData [7] == '+') {
for (i = 0; i <E; i ++)

N * = 10;
Cantidad = (Doble) N; }
else if (ExtData [7] == '-') {
D = 1;
for (i = 0; i <E; i ++)

D * = 10;
Cantidad = (Doble) N / (Doble) D; } Else {
= Cantidad (Doble) 0,0; }
8.2.3 recomendada diagrama de flujo de manejo de dinero:
El siguiente diagrama muestra el método recomendado de manejo de dinero. Hay dos cosas principales a nota:
• El modo no plica en desuso se sustituye por el concepto de la propiedad “auto-pila”. Si la aplicación está diseñada para
aceptar simplemente los billetes de banco a medida que llegan, la propiedad de auto-pila debe ser verdad, de manera que el
apilamiento se produce de forma automática. Si la aplicación necesita más control sobre el cual se aceptan notas, entonces
la propiedad de auto-pila debe ser falsa. Cuando auto-pila es falsa, la aplicación recibirá un evento “fideicomiso” y luego
puede utilizar los métodos StackEscrowNote () o ReturnEscrowNote () para aceptar o rechazar la nota.
• El valor de la factura se graba mientras se está en la plica. Es este valor registrado que se utiliza cuando se apila la factura y la
aplicación recibe un evento de “Stacked”. Se necesita esta manipulación del valor de la factura para manejar los casos en que
un proyecto de ley se apila sin crédito. Dado que el valor se mantiene en custodia, se evitan errores en el recuento de caja de
caja de crédito y.

West Chester
(s) PCN 500000008441

Tema
EMPEZAR
UNA De marcha en vacío
Conjunto T = Bill Valor en fideicomiso
Fideicomiso
SI Auto-Pila NO
Habilitado?
SI Nota NO
Aceptable
?
Apilar la nota. Devolver la nota.
Enviar la solicitud de un evento

apilado con Valor (T). Claro T.
apilada devuelto
Enviar la solicitud de una

Devolución de Evento. No
Valor. Claro Claro T.
UNA UNA
8.2.4 El control de la orientación de las facturas aceptadas:
En algunas aplicaciones, se desea para controlar la orientación de billetes aceptados. Para lograr esto, los bits de control de orientación del
comando, todos se pueden utilizar para establecer la orientación (véase la sección 7.1.1). Este método es de control limitado sin embargo.
La razón es que el aceptador de billetes también tiene un control de orientación interna. Ambos de estos ajustes determinan la
configuración de orientación real que se utiliza de acuerdo con la siguiente tabla:

West Chester
(s) PCN 500000008441

Tema
Ajuste
efectiva eBDS
combinada
4 Ajuste
2 1
4 4 4 4
22
residencia
2 2
Marco
44
1 1
Se puede observar que el ajuste sea posible más “liberal” es utilizado por el receptor. En esta situación, la única manera de que el
anfitrión tiene el control completo sobre la orientación de los billetes de banco aceptados es tener los ajustes internos unidades
configuradas para 1 vía aceptación. A la inversa, si se desea tener el control sobre la orientación de notas por medio de la configuración
interna de la aceptación de billetes, la interfaz eBDS tendrá que ser establecido en 1-way aceptación.
8.2.5 Mejora de control de la orientación en el modo ampliado:
Para aquellos dispositivos que el apoyo de informes nota expandido, es posible para el anfitrión para alcanzar un nivel mayor de control
sobre la orientación de notas aceptados. En pocas palabras, cuando las notas llegan al depósito de garantía, el anfitrión puede examinar el
campo de orientación (véanse las secciones 7.1.4 y 7.4.14) en los datos de notas expandidas y devuelva todas las notas que corresponden
a la orientación deseada. En este modo, el sistema anfitrión tiene la última palabra en cuanto a la idoneidad de la nota.
8.3 Determinación de la versión del firmware
Cuando un sistema host se conecta a un aceptador de billetes, a menudo es útil para determinar la versión y el tipo de software
instalado en la unidad. Si el anfitrión puede determinar esto, es capaz entonces de tomar decisiones sobre el firmware como
realizar una actualización al firmware deseado o señalización de un error que el software de la unidad no coincide con el software
esperado.
8.3.1 Versión de firmware en el Clásico eBDS:
En eBDS clásicos, generalmente no es posible determinar el firmware exacta almacenada en la memoria flash de un dispositivo.
Sin embargo, es posible construir una “firma” única del código y utilizar esto como una forma de identificación. Esto se logra
mediante el byte Número de modelo, el byte Código Revisión y el flash CRC. En conjunto, estos forman una firma de código de 32
bits que debe ser único. Si esta firma no coincide con la firma esperada, la acción correctiva puede ser tomada en forma de subir el
firmware apropiado o la señalización de una condición de error. Esta firma de código de 32 bits podría ser presentado de la
siguiente manera:

West Chester
(s) PCN 500000008441

Tema
32 Bits
0 Modelo 0 Versión CRC-16
El valor entero creado entonces podría utilizarse para llave en una base de datos o algún esquema similar.
8.3.2 Versión de firmware en eBDS extendido:
En los sistemas que soportan el conjunto de comandos de tiempo, es posible consultar directamente el número de parte de la aplicación y la
variante instalada en la unidad. Esto devuelve dos cadenas que permiten el sistema host para determinar directamente si el manifiesto de
software del aceptador de billetes es correcta. Como anteriormente, las acciones correctivas pueden incluir la posibilidad de subir el firmware
apropiado o la señalización de una condición de error.
8.4 Controlar excepciones aceptoras
Algunas excepciones aceptores llevan un examen más detenido. En esta sección se revisará acciones de corrección recomendadas que deben
tomarse cuando se devuelven los valores de estado inusuales.
8.4.1 aceptador de billetes no responde a una encuesta:
No es inusual para el aceptador de billetes para ser ocupado y a “perder” un sondeo. Bajo estas condiciones, el anfitrión debe reintento
al tipo de encuesta normal con el mismo valor ACK (ver sección 4.5). Si después de diez intentos, no ha habido ninguna respuesta
debe cambiar el valor ACK y seguir tratando de diez veces más.
8.4.2 aceptador de billetes no responde durante un período prolongado:
Si el aceptador de billetes no responde después de treinta segundos de volver a intentar, el anfitrión debe “declarar” la unidad está
fuera de servicio y que se requiere la intervención del servicio. La causa más probable del problema es que hay un problema de
cableado o la potencia con la unidad o hay algo mal con el aceptador de billetes. El anfitrión debe ir fuera de servicio y solicitar una
llamada de servicio de campo.
8.4.3 aceptador de billetes Estado: Cheated

Si un estado aceptador de billetes de engañados (ver sección 7.1.2) se devuelve al host, significa que hubo un problema de transportar el billete a
la caja del dinero. De hecho, esto podría ser el resultado de la manipulación fraudulenta de la factura o de la unidad. También podría ser tan
inofensivo como un billete de banco de edad se queda pegada. En la mayoría de los casos, el anfitrión debe simplemente ignorar este evento. MEI
no ofrece un método para eventos de trucos del sistema / de la prueba.

West Chester
(s) PCN 500000008441

Tema
8.4.4 aceptador de billetes Estado: Rechazado
Si el aceptador de billetes devuelve un estado de rechazo (véase la sección 7.1.2) simplemente significa que un proyecto de ley no fue reconocido como un proyecto
de ley buena. El anfitrión debe tomar ninguna acción.
8.4.5 aceptador de billetes Estado: Jammed
Si el aceptador de billetes devuelve un estado de atascado (véase la sección 7.1.2) que significa que un problema se ha encontrado con
el transporte de la factura (ya sea para su aceptación o rechazo). Cuando se detecta un atasco, rutinas antiperturbación se ejecutan para
eliminar el atasco. Si tiene éxito, el estado atascado se borrará, de lo contrario, persistirá. Si el host detecta una condición atascada, que
debería ir fuera de servicio durante la duración de la mermelada.
8.4.6 aceptador de billetes Estado: Stacker completa
Si el aceptador de billetes devuelve un estado de completa apiladora (ver sección 7.1.2) significa que no hay más documentos pueden ser
colocados en la caja del dinero. El anfitrión debe ir fuera de servicio y solicitar un intercambio efectivo de caja de la operadora.
8.4.7 aceptador de billetes Estado: Eliminado Cashbox
Si el aceptador de billetes devuelve un estado de caja de efectivo retirado (ver sección 7.1.2) que significa que la unidad ya no puede
aceptar dinero. Esto ocurrirá como una cuestión de rutina cuando la caja del dinero se intercambia al final del turno. También puede
ocurrir si la caja no está colocada correctamente y la vibración normal de funcionamiento hace que se aflojen. En este caso, el
anfitrión debe ir fuera de servicio y solicitar un encargado de examinar la caja del dinero.
8.4.8 aceptador de billetes Estado: En pausa
Si el aceptador de billetes devuelve un estado de pausa (ver sección 7.1.2), significa que el consumidor está alimentando facturas demasiado
rápido y necesidades para eliminar la cuenta corriente de la boca del aceptador de billetes para que se pueda proceder. El anfitrión debe indicar
esto al consumidor.
8.4.9 aceptador de billetes Estado: Calibración en Progreso
Si el aceptador de billetes devuelve un estado de calibración en curso (ver sección 7.1.2) y una calibración no fue solicitada, significa
que hay un problema con el aceptador de billetes y el anfitrión debe ir fuera de servicio y solicitar una llamada de servicio de campo .

West Chester
(s) PCN 500000008441

Tema
8.4.10 aceptador de billetes Estado: Encendido
Si el aceptador de billetes devuelve un estado de encendido (véase la sección 7.1.2) significa que algo ha hecho que la unidad se
restablezca o que ha perdido el poder y se recuperó. El anfitrión debe proceder a realizar sus tareas de inicialización una vez más
(ver sección 8.1)
8.4.11 aceptador de billetes Estado: Comando no válido
Si el aceptador de billetes devuelve un estado de comando no válido (véase la sección 7.1.2) significa que hay un defecto en el código
de acogida. Normalmente este error nunca debe ocurrir fuera del desarrollo y depurar las fases del sistema. En el campo, este error
se debe registrar como un problema con la programación del sistema anfitrión.
8.4.12 aceptador de billetes Estado: Fracaso
Si el aceptador de billetes devuelve un estado de fallo (ver sección 7.1.2) que significa que hay un problema grave, ya sea con el
aceptador de billetes, el chasis o la caja de efectivo. Este problema requiere atención y el anfitrión debe ir fuera de servicio y solicitar
una llamada de servicio de campo.
8.4.13 aceptador de billetes Estado: Stalled
Si el aceptador de billetes devuelve un estado de estancamiento (véase la sección 7.1.2) que significa que la unidad ha detectado un
problema transportar el billete a la caja del dinero y que ahora está estancado, con la factura cerca o justo en la caja. Se requiere un
asistente para examinar el origen del problema con la factura y para restablecer la unidad. Esta condición sólo se produce si el host
permite No Modo de transferencia (véase la sección 7.1.1)
8.4.14 aceptador de billetes Estado: Flash Descargar
Si el aceptador de billetes devuelve un estado de descarga rápida (véase la sección 7.1.2) y no se espera, significa que la unidad
se carece de código de aplicación o que una descarga anterior intento fue interrumpido o no. el huésped puede o bien intentar
descargar el firmware correcto o puede ir fuera de servicio y solicitar una llamada de servicio de campo.

West Chester
(s) PCN 500000008441

Tema
9. MEI Punto de Servicio Toolkit (M / POST)

dispositivos de protocolo eBDS también se puede acceder a través de la porción eBDS el Punto MEI de Servicio Toolkit (M / POST). El M /
POST proporciona un importante ahorro de tiempo y esfuerzo para la codificación, depuración y despliegue de aplicaciones que requieren
la aceptación y el manejo de dinero en efectivo.
9,1 M / POST para eBDS general:
El M / POST se basa en el modelo Eventos Propiedades / Métodos / de programación utilizado en los sistemas orientados objeciones
y la descripción de la misma será a lo largo de esas líneas. notas:
Para los sistemas que no soportan directamente las propiedades de programación, se utilizan las funciones de acceso. El prefijo “qry”
se utiliza para la función de acceso de lectura y el prefijo “Set” se utiliza para la función de acceso de escritura.
Para los sistemas que no soportan la programación de espacios de nombres, todas las siguientes definiciones (a excepción de los más
comunes como BOOLEANA, CADENA etc) tienen el prefijo “eBDS”. Cuando se necesitan tanto espacio de acceso y nombre de prefijos,
el prefijo “eBDS” aparece por primera vez en el nombre de la entidad. Esto daría lugar a nombres de funciones como
“EbdsQryCapOrientationExt ()”.
9.1.1 M / POST para eBDS Aceptador propiedades:
Nombre Tipo Vers Acceso Cuando utilizable?

ID de aplicación CUERDA 1,00 R CapApplicationID
ApplicationPN CUERDA 1,00 R CapApplicationPN
AuditLifeTimeTotals INT32 [] 1,00 R CapAudit.
AuditPerformance INT32 [] 1,00 R CapAudit.
AuditQP INT32 [] 1,00 R CapAudit.
AutoStack BOOLEANA 1.00 R / W Conectado.
Código de barras CUERDA 1,00 R DocType == DocBarCode.
Cuenta Cuenta 1,00 R DocType == DocBill.
BillTypes Cuenta[ ] 1,00 R Conectado.
BillTypeEnables Boolean [] 1.00 R / W Conectado.
BillValues Cuenta[ ] 1,00 R Conectado.
BillValueEnables Boolean [] 1.00 R / W Conectado.
BNFStatus BNFStatus 1,00 R CapBNFStatus
BootPN CUERDA 1,00 R CapBootPN.
CapApplicationID BOOLEANA 1,00 R Conectado.
CapApplicationPN BOOLEANA 1,00 R Conectado.
CapAssetNumber BOOLEANA 1,00 R Conectado.
CapAudit BOOLEANA 1,00 R Conectado.
CapBarCodes BOOLEANA 1,00 R Conectado.
CapBarCodesExt BOOLEANA 1,00 R Conectado.
CapBNFStatus Boole 1,00 R Conectado.
CapBookmark BOOLEANA 1,00 R Conectado.
CapBootPN BOOLEANA 1,00 R Conectado.

West Chester
(s) PCN 500000008441

Tema

CapCalibrate BOOLEANA 1,00 R Conectado.
CapCashBoxTotal BOOLEANA 1,00 R Conectado.
CapCouponExt BOOLEANA 1,00 R Conectado.
CapDevicePaused BOOLEANA 1,00 R Conectado.
CapDeviceSoftReset BOOLEANA 1,00 R Conectado.
CapDeviceType BOOLEANA 1,00 R Conectado.
CapDeviceResets BOOLEANA 1,00 R Conectado.
CapDeviceSerialNumber BOOLEANA 1,00 R Conectado.
CapEscrowTimeout BOOLEANA 1,00 R Conectado.
CapFlashDownload BOOLEANA 1,00 R Conectado.
CapNoPush BOOLEANA 1,00 R Conectado.
CapOrientationExt BOOLEANA 1,00 R Conectado.
CapPupExt BOOLEANA 1,00 R Conectado.
CapSetBezel BOOLEANA R 1.10 Conectado.
CapTestDoc BOOLEANA 1,00 R Conectado.
CapVariantID BOOLEANA 1,00 R Conectado.
CapVariantPN BOOLEANA 1,00 R Conectado.
CashBoxAttached BOOLEANA 1,00 R Conectado.
CashBoxFull BOOLEANA 1,00 R Conectado.
CashBoxTotal INT32 1,00 R CapCashBoxTotal.
Conectado BOOLEANA 1,00 R Siempre.
Cupón Cupón 1,00 R DocType == DOC_COUPON
Registro de depuración BOOLEANA 1.00 R / W Siempre.
DebugLogPath CUERDA 1.00 R / W Lee: Siempre

Escribir: Cuando DebugLog es falsa.
DeviceBusy BOOLEANA 1,00 R Conectado.
DeviceCRC INT32 1,00 R Conectado.
DeviceFailure BOOLEANA 1,00 R Conectado.
DeviceJammed BOOLEANA 1,00 R Conectado.
DeviceModel INT32 1,00 R Conectado.
DevicePaused BOOLEANA 1,00 R CapDevicePaused.
DevicePortName CUERDA 1,00 R Conectado.
DevicePowerUp Encender 1,00 R Conectado.
DeviceResets INT32 1,00 R CapDeviceResets.
DeviceRevision INT32 1,00 R Conectado.
DeviceSerialNumber CUERDA 1,00 R CapDeviceSerialNumber.
DeviceSignature INT32 1,00 R Conectado.
DeviceStalled BOOLEANA 1,00 R CapNoPush.
DeviceState Estado 1,00 R Siempre.
Tipo de dispositivo CUERDA 1,00 R CapDeviceType
DocType DocType 1,00 R Después DeviceState == fideicomiso.
EnableAcceptance BOOLEANA 1.00 R / W Conectado.
EnableBarCodes BOOLEANA 1.00 R / W CapBarCodes.
EnableBookmarks BOOLEANA 1.00 R / W CapBookmark.
EnableCouponExt BOOLEANA 1.00 R W CapCouponExt /
EnableNoPush BOOLEANA 1.00 R / W CapNoPush.
Después DeviceState == fideicomiso.
EscrowOrientation Orientación 1,00 R
cuando CapOrientationExt.

West Chester
(s) PCN 500000008441

Tema

Alta seguridad BOOLEANA 1.00 R / W Conectado.
OrientationCtl OrientationCtl 1.00 R / W Conectado.
OrientationCtlExt OrientationCtl 1.00 R / W CapOrientationExt.
VariantID CUERDA 1,00 R CapVariantID.
VariantNames CUERDA[ ] 1,00 R Conectado.
VariantPN CUERDA 1,00 R CapVariantPN.
Versión CUERDA 1.00 R Siempre
9.1.2 M / POST para eBDS Cuenta propiedades:
Nombre Tipo Vers Acceso Valores

País CUERDA 1,00 R Código de tres letras ISO o “*”.
Valor DOBLE 1,00 R
Tipo CARBONIZARSE 1,00 R 'A' .. 'Z' o '*'
Serie CARBONIZARSE 1,00 R 'A' .. 'Z' o '*'
Compatibilidad CARBONIZARSE 1,00 R 'A' .. 'Z' o '*'
Versión CARBONIZARSE 1.00 R 'A' .. 'Z' o '*'
9.1.3 M / POST para eBDS Cupón propiedades:
Nombre Tipo Vers Acceso Valores

ID_Propietario INT32 1,00 R Un entero asignado al propietario
del cupón
Valor DOBLE 1,00 R El valor monetario del cupón
genérico.
0.0D == libre de venta de cupones
1,0 D == $ 1 cupón
2.0D == $ 2 la cupón
5.0D == cupón de $ 5
9.1.4 M / POST para eBDS DocType Enumeración:
DocType = {Ninguno, NoValue, Bill, código de barras, Cupón}
Este tipo describe el tipo de documento que se está procesando. Este puede ser uno de:
Tipo Descripción
Ninguna Ningún documento está siendo procesada.
Sin valor se está procesando un documento con ningún valor.
Cuenta Un billete de banco se está procesando.
Código de barras Un código de barras se está procesando.
Cupón Un cupón genérico se está procesando.

West Chester
(s) PCN 500000008441

Tema
9.1.5 M / POST para eBDS Orientación Enumeración:
Orientación = {RightUp, Rightdown, Leftup, LeftDown,

Desconocido}
Este tipo describe la orientación de una nota. Se espera que las descripciones son evidentes por sí mismas.
9.1.6 M / POST para eBDS OrientationCtl Enumeración:
OrientationCtl = {FOUR_WAY, TWO_WAY, ONE_WAY}
Este tipo se describen las formas en que la orientación de notas puede ser controlada. Esto se muestra en la tabla siguiente:
Controlar Derecha-Arriba Derecha-Abajo Izquierda-Up Izquierda hacia abajo
FOUR_WAY
TWO_WAY
ONE_WAY
9.1.7 M / POST para eBDS Encender Enumeración:
PowerUp = {A, B, C, E}
9.1.8 M / POST para eBDS PupExt Enumeración:
PupExt = {PUP_RETURN, PUP_OOS, PUP_STACK_NC, PUP_STACK,

PUP_WAIT_NC, PUP_WAIT}
9.1.9 M / POST para eBDS Estado Enumeración:
Estado = {DESCONECTADO, CONEXIÓN, PUP_ESCROW, al ralentí,

ACEPTAR, FIDEICOMISO, amontonamiento, apilado, volviendo, volvió, rechazado,
atascado, estancado, fracasado, CALIBRATE_START, de verificación,
DOWNLOAD_START, DOWNLOAD_RESTART, DESCARGAR}
9.1.10 M / POST para eBDS BNFStatus Enumeración:
BNFStatus = {DESCONOCIDO, OK, NOT_ATTACHED, ERROR}

West Chester
(s) PCN 500000008441

Tema
9.1.11 M / POST para eBDS Bisel Enumeración:
Bisel = {Estándar, Plataforma Diagnóstico}
9.1.12 M / POST para eBDS Aceptador Métodos:
Nombre / Tipos Cuando utilizable? Vers

vacío abierto (port_name CADENA,
DeviceState == desconectado. 1.00
PowerUp POWER_UP)
Cerrar (void) Conectado 1.00
Calibrar vacío (vacío) No DeviceBusy y CapCalibrate 1.00
EscrowReturn vacío (vacío) DeviceState == fideicomiso o DeviceState ==
POWER_UP_ESCROW 1,00
EscrowStack vacío (vacío) DeviceState == fideicomiso o DeviceState ==

POWER_UP_ESCROW 1,00
FlashDownload vacío (ruta_archivo CADENA) no DeviceBusy y CapFlashDownload 1.00 vacío ClearCashBoxTotal (void)
No DeviceBusy y CapCashBoxTotal. 1.00
SoftReset vacío (vacío) CapDeviceSoftReset 1.00
SetAssetNumber vacío (activo CADENA) No DeviceBusy y CapAssetNumber. 1.00
void SetBezel (Bisel b) No DeviceBusy y CapSetBezel. 1.10
SpecifyEscrowTimeout vacío (
INT32 bill_timeout, INT32 CapEscrowTimeout 1.00
barcode_timeout)
SpecifyPupExt vacío (pup_mode CHAR,
tPupExt pre_escrow, tPupExt
at_escrow, tPupExt No DeviceBusy y CapPupExt. 1.00
post_escrow tPupExt
pre_stack)
9.1.13 M / POST para eBDS Aceptador Eventos:
Nombre datos de parámetro Vers

CONECTADO ninguna 1.00
DESCONECTADO ninguna 1.00
FIDEICOMISO ninguna 1.00
PUP_ESCROW ninguna 1.00
EMPILADA ninguna 1.00
DEVUELTO ninguna 1.00
RECHAZADO ninguna 1.00
ENGAÑADO ninguna 1.00
CALIBRATE_START ninguna 1.00
CALIBRATE_PROGRESS ninguna 1.00
CALIBRATE_FINISH ninguna 1.00
DOWNLOAD_START TOTAL_NUM INT32 1.00
DOWNLOAD_RESTART ninguna 1.00
PROGRESO DE DESCARGA sector_num INT32 1.00
DOWNLOAD_FINISH éxito BOOLEANA 1.00

West Chester
(s) PCN 500000008441

Tema

PAUSE_DETECTED ninguna 1.00
PAUSE_CLEARED ninguna 1.00
STALL_DETECTED ninguna 1.00
STALL_CLEARED ninguna 1.00
JAM_DETECTED ninguna 1.00
JAM_CLEARED ninguna 1.00
CASHBOX_REMOVED ninguna 1.00
CASHBOX_INSTALLED ninguna 1.00
ENCENDER ninguna 1.00
9.1.14 M / POST para eBDS Aceptador Detalles propiedades:

ID de aplicación CUERDA 1,00 R CapApplicationID
punto de lectura: aceptador de consulta en la demanda. punto de escribir: n/A
Esta cadena propiedad contiene el ID de la aplicación. Esto toma la forma de una cadena. Para más detalles véase la sección 7.4.15.
Si CapApplicationID es falsa, el valor es una cadena vacía.

ApplicationPN CUERDA 1,00 R CapApplicationPN
Esta cadena propiedad contiene el número de parte de la aplicación. Esto toma la forma de una cadena. Para más detalles véase la
sección 7.4.8. Si CapApplicationPN es falsa, el valor es una cadena vacía.

AuditLifeTimeTotals INT32 [] 1,00 R CapAudit.
Esta propiedad contiene una matriz de enteros con los datos de toda la vida. Para más detalles, véase la sección
7.4.11. Si esta propiedad no está disponible, el valor es una matriz vacía.

AuditPerformance INT32 [] 1,00 R CapAudit.
Esta propiedad contiene una matriz de enteros con los datos de rendimiento. Para más detalles, véase la sección

West Chester
(s) PCN 500000008441

Tema

AuditQP INT32 [] 1,00 R CapAudit.
Esta propiedad contiene una matriz de enteros con los datos de rendimiento. Para más detalles, véase la sección

AutoStack BOOLEANA 1.00 R / W Conectado.
punto de lectura: variable del sistema principal local. punto de escribir: Inmediatamente cuando se escribe.
Esta propiedad controla el manejo de documentos. Si se activa, los documentos se apilan automáticamente cuando se reciben. Si no se
establece la aplicación se informó a través de FIDEICOMISO caso cuando un documento llega. Para más detalles véase la sección
8.2.3. Si esta propiedad no se puede utilizar, se ignora.

Código de barras CUERDA 1,00 R DocType == DocBarCode.
punto de lectura: En plica código de barras. punto de escribir: n/A
Esta propiedad contiene la información de código de barras extraído del documento más reciente de código de barras. Véase la sección 7.1.3
para más detalles. Si un documento con código de barras no se está procesando, esta propiedad tiene un valor indefinido.

Cuenta Cuenta 1,00 R DocType == DocBill.
punto de lectura: En plica factura. punto de escribir: n/A
Esta propiedad contiene la información de la factura extraído de la nota más reciente del banco. ver secciones
7.1.4, 8.2 y 9.1.2 para más detalles. Si un billete de banco no está siendo procesada, esta propiedad tiene un valor indefinido.

BillTypes Cuenta[ ] 1,00 R Conectado.
punto de lectura: Caché de conexión. punto de escribir: n/A
Esta propiedad es una matriz de todas las facturas de que sean aceptadas por el dispositivo. Esto incluye entradas para cada variedad
de billetes de banco. Esta tabla se construye cuando se establece la conexión con el receptor. Véase la sección 9.1.2 para más
detalles. Si esta propiedad no está disponible, el valor es una matriz vacía.
Un ejemplo de una copia impresa de esta propiedad para un aceptador de billetes cargado con la parte variante dólar estadounidense número 490320223 se
muestra a continuación:
1 USD 1 CABB
2 USD 2 CABA
3 USD 2 CBBA

West Chester
(s) PCN 500000008441

Tema
4 USD 5 CABB
5 USD 5 DABC
6 USD 10 Dabb
7 USD 10 EABC
8 USD 10 FABB
9 USD 20 CABB
10 USD 20 DABC
11 USD 20 EABB
12 USD 50 CABB
13 USD 50 DABC
14 USD 50 DBBC
15 USD 50 FABB
16 USD 100 CABB
17 USD 100 DABD
18 USD 100 DBBC

BillTypeEnables Boolean [] 1.00 R / W Conectado.
Enviado a la aceptación de billetes en la próxima
punto de lectura: Creado en conectar. Pre- punto de escribir:
lleno de entradas verdaderos. ranura de tiempo disponible.
Esta propiedad es una matriz de Boolean valores que corresponden a las entradas de la propiedad BillTypes. La aceptación de las
facturas que corresponden a esos valores puede controlarse con entradas verdaderos que aceptan billetes y falsas entradas
rechazarlas. Consulte las secciones 7.1.1 y 7.5.2 para más detalles. Si esta propiedad no está disponible, el valor es una matriz vacía.
Nota: Los cambios en la propiedad BillValueEnables dará lugar a cambios en la propiedad BillTypesEnables. Sin embargo, los
cambios realizados en los BillTypesEnables no se propagan de vuelta a la propiedad BillValueEnables. En general, la aplicación
debe utilizar uno de la factura permiten propiedades y no alternar entre ellos ya que esto puede causar resultados inesperados.
FE DE ERRATAS: En algunos aceptadores de billetes con fuera de fecha del firmware hay un defecto en el código que hará que las unidades
que no se activará hasta que la propiedad se establece BillTypeEnables. Para solucionar este defecto de la aplicación puede colocar una línea
de código que establece esta propiedad en su controlador de eventos Conectado. Un ejemplo, la línea inofensiva de código podría ser:
billAcceptor.BillTypeEnables = billAcceptor.BillTypeEnables;

BillValues Cuenta[ ] 1,00 R Conectado.
Esta propiedad es una matriz de todas las facturas de que sean aceptadas por el dispositivo. Las variaciones en los billetes de banco valorados
como-se ignora, de manera que cada entrada tiene un valor monetario o país diferente. Esta tabla se construye cuando se establece la
conexión con el receptor. Véase la sección 9.1.2 para más detalles. Si esta propiedad no está disponible, el valor es una matriz vacía. Un
ejemplo de una copia impresa de esta propiedad para un aceptador de billetes cargado con la parte variante dólar estadounidense número
490320223 se muestra a continuación:

West Chester
(s) PCN 500000008441

Tema
1 USD 1****
2 USD 2****
3 USD 5****
4 USD 10 * * * *
5 USD 20 * * * *
6 USD 50 * * * *
7 USD 100 * * * *
Tenga en cuenta que la vista del conjunto de la factura es más sencilla que en la propiedad BillTypes, pero que la información detallada sobre los
distintos tipos de facturas y variaciones no está disponible.

BillValueEnables Boolean [] 1.00 R / W Conectado.
Enviado a la aceptación de billetes en la próxima ranura
punto de lectura: Creado en conectar. Pre- punto de escribir:
lleno de entradas verdaderos. de tiempo disponible.
Esta propiedad es una matriz de Boolean valores que corresponden a las entradas de la propiedad BillValues. La aceptación de las
facturas que corresponden a esos valores puede controlarse con entradas verdaderos que aceptan billetes y falsas entradas
rechazarlas. Consulte las secciones 7.1.1 y 7.5.2 para más detalles. Si esta propiedad no está disponible, el valor es una matriz vacía.
Nota: Los cambios en la propiedad BillValueEnables dará lugar a cambios en la propiedad BillTypesEnables. Sin embargo, los
cambios realizados en los BillTypesEnables no se propagan de vuelta a la propiedad BillValueEnables. En general, la aplicación
debe utilizar uno de la factura permiten propiedades y no alternar entre ellos ya que esto puede causar resultados inesperados.

BNFStatus BNFStatus 1,00 R CapBNFStatus
Esta propiedad se puede utilizar para determinar el estado del accesorio alimentador manojo nota opcional. Esta propiedad sólo es
válida cuando CapBNFStatus es cierto. Cuando es falso, el estado será siempre desconocido.

BootPN CUERDA 1,00 R CapBootPN.
Esta cadena propiedad contiene el número de pieza de arranque. Esto toma la forma de una cadena. Para más detalles véase la sección
7.4.7. Si CapBootPN es falsa, el valor es una cadena vacía.

Gorra*** BOOLEANA 1,00 R Conectado.

West Chester
(s) PCN 500000008441

Tema
Las propiedades que comienzan con “Cap” son todos indicadores de capacidad que indican qué características están presentes en el
aceptador de billetes conectado. En su mayor parte, estas banderas se derivan del campo de número de modelo enviado por el aceptor
(véase la sección 7.1.2)
Nombre modelo # otros criterios

CapApplicationID Capacidad del dispositivo Mapa se establece para
consulta ID de aplicación aceptor.
CapApplicationPN “T”, “U”
CapAssetNumber “T”, “U”
CapAudit “T”, “U”
CapBarCodes 15, 23, “T”, “U”
El bit RawBarcodes en
Está establecido
CapBarCodesExt
respuestas de dispositivo (véase la sección 7.1.2)
CapBNFStatus Capacidad del dispositivo Mapa se establece para consulta de
estado BNF.
CapBookmark Cierto
CapBootPN “T”, “U”
CapCalibrate Cierto
CapCashBoxTotal “A”, “B”, “C”, “D”, “G”, “M”, “P”, “W”, “X”
CapCouponExt “P”, “X”

CapDevicePaused 31, “P”, “X”
CapDeviceSoftReset 31, “A”, “B”, “C”, “D”, “G”, “M”, “P”,
“T”, “U”, “W”, “X”
CapDeviceType “T”, “U”
CapDeviceResets “A”, “B”, “C”, “D”, “G”, “M”, “P”, “T”, “U”,
“W”, “X”
CapDeviceSerialNumber “T”, “U”
CapEscrowTimeout “T”, “U”
CapFlashDownload Cierto
CapNoPush 23, 31, “P”, “X”
CapOrientationExt Capacidad del dispositivo Mapa se establece para el
control de orientación extendida.
CapPupExt Capacidad del dispositivo mapa está activado para el
modo PUP extendida.
CapSetBezel Capacidad del dispositivo Mapa se establece para bisel
engastado.
CapTestDoc Capacidad del dispositivo mapa está activado para el
documento de prueba aceptada.
CapVariantID Capacidad del dispositivo Mapa se establece para

consulta ID variante aceptor.
CapVariantPN “T”, “U”
Véase la sección 7.4.11 para una descripción del mapa de capacidad de dispositivo.

West Chester
(s) PCN 500000008441

Tema

CashBoxAttached BOOLEANA 1,00 R Conectado.
punto de lectura: Actualizado en cada sondeo. punto de escribir: n/A
Esta propiedad es verdadera cuando una caja de efectivo se une a la aceptación de billetes. Véase la sección 7.1.2 para más detalles sobre esta
bandera.

CashBoxFull BOOLEANA 1,00 R Conectado.
Esta propiedad es cierto cuando una caja de dinero en efectivo está llena y ya no puede aceptar letras. Consulte las secciones 7.1.2 y 8.4.6 para más detalles
sobre esta bandera.

No DeviceBusy y
CashBoxTotal INT32 1,00 R
CapCashBoxTotal.
Esta propiedad contiene refleja la cantidad de moneda cree que presentar en la caja. Véase la sección 7.4.2 para más detalles.

Conectado BOOLEANA 1,00 R Siempre.
La propiedad conectado es cierto si un dispositivo está conectado y de responder al sistema anfitrión. Esto se convierte en falsa cuando el
dispositivo no responde a las encuestas desde hace más de un límite permisible, o la conexión se cierra por el anfitrión. Este límite es de
cinco segundos para el modelo “T” y “U” dispositivos y treinta segundos para todos los demás.

Cupón Cupón 1,00 R DocType == DOC_COUPON
punto de lectura: En plica cupón. punto de escribir: n/A
Esta propiedad contiene la información extraída de cupón del cupón más reciente genérico. Consulte las secciones 7.1.5, 9.1.3 y
para más detalles. Si una nota cupón no se está procesando o EnableCouponExt es falsa, esta propiedad tiene un valor indefinido.

Registro de depuración BOOLEANA 1.00 R / W Siempre.
punto de lectura: variable del sistema principal local. punto de escribir: Establecido por el código de aplicación.
Esta propiedad se utiliza para controlar la generación de un archivo de registro de depuración. En la fase de desarrollo de una aplicación, este
registro puede ser útil para diagnosticar cualquier problema o problemas que puedan surgir.

West Chester
(s) PCN 500000008441

Tema
Tenga en cuenta que el archivo de registro de depuración está bloqueado mientras la aplicación está utilizando. Este indicador debe ser falsa para aplicaciones
desplegadas.
DebugLogPath CUERDA 1.00 R / W Lee: Siempre

Escribir: Cuando DebugLog es falsa.
punto de lectura: variable del sistema principal local. punto de escribir: Establecido por el código de aplicación.
Esta propiedad se utiliza para controlar la ubicación del archivo de registro de depuración. Cuando la propiedad DebugLog se establece en true,
el valor de esta propiedad se utiliza para determinar la ubicación del archivo de registro. Por defecto, el archivo de registro se crea en la misma
carpeta en la que se despliega la aplicación.

DeviceBusy BOOLEANA 1,00 R Conectado.
Esta bandera es cierto si el aceptador de billetes está en estado de reposo. En este estado, es posible llevar a cabo comandos más complejos
que podrían interferir con la aceptación factura.

DeviceCRC INT32 1,00 R Conectado.
Este valor es el CRC de la memoria flash (con exclusión de arranque y áreas “especiales”). Mira la sección

DeviceFailure BOOLEANA 1,00 R Conectado.
Cuando se establece este indicador, el aceptador de billetes está fuera de servicio y requiere atención, por lo general en forma de una llamada
por un técnico de servicio. Ver secciones 7.1.2 y 8.4.12 para más detalles sobre esta bandera.

DeviceJammed BOOLEANA 1,00 R Conectado.
Cuando se establece este indicador, el aceptador de billetes se ha encontrado con una condición de atasco y requiere atención, típicamente en la forma de un
escombros de compensación de la trayectoria del billete. Véase la sección 7.1.2 para más detalles sobre esta bandera.

DeviceModel INT32 1,00 R Conectado.

West Chester
(s) PCN 500000008441

Tema
Este número se establece desde el campo de número de modelo devuelto por el aceptador de billetes para cada sondeo. Si el valor está
entre 32 y 126, que deben ser tratados como un solo carácter imprimible. Mira la sección
7.1.2 para más detalles sobre este valor.

DevicePaused BOOLEANA 1,00 R CapDevicePaused.
Esta bandera se establece cuando el aceptador de billetes está en la condición de pausa. Esto ocurre cuando el consumidor intenta
insertar otro proyecto de ley mientras que la anterior todavía se está procesando. Las pausas del sistema para evitar agarrar dos
cuentas y “robar” la segunda. Véase la sección 7.1.2 para más detalles sobre este valor. Si esta propiedad no es compatible,
siempre será falsa.

DevicePortName CUERDA 1,00 R Conectado.
Esta es una copia del parámetro port_name pasado en el método Open. Es el puerto serie en serie o virtual utilizado para
comunicarse con el aceptador de billetes.

DevicePowerUp Encender 1,00 R Conectado.
Esta es una copia del parámetro POWER_UP pasado en el método Open. Es de tipo tPowerUp y controlar el comportamiento de la
aceptación de billetes, cuando un billete se está procesando durante un fallo de alimentación. Véase la sección 7.1.1 para más detalles.

DeviceResets INT32 1,00 R CapDeviceResets.
Esta propiedad devuelve el número de veces que el aceptador de billetes se ha restablecido. Mira la sección
7.4.3 para más detalles. Si esta propiedad no es compatible, siempre será 0.

DeviceRevision INT32 1,00 R Conectado.
Esta propiedad es el valor numérico contenido en el campo eBDS revisión estándar. Mira la sección

West Chester
(s) PCN 500000008441

Tema

DeviceSerialNumber CUERDA 1,00 R CapDeviceSerialNumber.
Esta propiedad es el número de serie del dispositivo adjunto en formato de cadena. Véase la sección 7.4.6 para más detalles sobre esta
propiedad. Si esta propiedad no está soportado, siempre va a ser la cadena vacía.

DeviceSignature INT32 1,00 R Conectado.
Esta propiedad devuelve un valor que corresponde a la firma de dispositivo en modo legado describen en la sección 8.3.1. Esta firma
puede ser utilizado para afirmar que el código contenido dentro de una unidad coincide con el código esperado.

DeviceStalled BOOLEANA 1,00 R CapNoPush.
Esta bandera se establece cuando el aceptador de billetes está en la condición estancado. Esto ocurre cuando se detecta un atasco y el
modo NoPush está activo. El sistema entra en pausa para que el operador pueda examinar el proyecto de ley que causó el atasco y para
comprobar si hay un posible fraude. Ver secciones 7.1.2 y 8.4.13 para más detalles sobre este valor. Si esta propiedad no es compatible,
siempre será falsa.

DeviceState Estado 1,00 R Siempre.
punto de lectura: variable del sistema principal local. punto de escribir: n/A
Esta variable refleja el estado actual del aceptador de billetes. Véase la sección 9.1.9 así una sección

Tipo de dispositivo CUERDA 1,00 R CapDeviceType
Esta propiedad es el tipo de dispositivo del dispositivo adjunto en formato de cadena. Véase la sección 7.4.5 para más detalles sobre esta
propiedad. Si esta propiedad no está soportado, siempre va a ser la cadena vacía.

DocType DocType 1,00 R Después DeviceState == fideicomiso.
Esta propiedad es el tipo de documento que está siendo procesado. Típicamente esta propiedad es interrogado en plica y cuando
se apila un documento para determinar cómo debe ser procesada. Véase la sección 9.1.4 para obtener una lista de posibles tipos
de documentos. Si esta propiedad no está actualizada, se refleja el valor del último documento procesado por el aceptador.

West Chester
(s) PCN 500000008441

Tema

EnableAcceptance BOOLEANA 1.00 R / W Conectado.
punto de lectura: variable del sistema principal local. punto de escribir: Actualizado en cada sondeo.
Esta propiedad se utiliza para controlar la aceptación de los documentos por el aceptador de billetes. Si es falso, el aceptador de billetes aceptará
ningún documento, si es cierto, entonces las cuentas seleccionadas, y será aceptado otros documentos.

EnableBarCodes BOOLEANA 1.00 R / W CapBarCodes.
Esta propiedad se utiliza para controlar la aceptación de documentos con códigos de barras. Si es falso, el aceptador de billetes no aceptará los
códigos de barras, de ser cierto, entonces la barra se aceptarán los códigos si la propiedad EnableAcceptance es cierto. Esta propiedad se ignora si
CapBarCodes es falsa.

EnableBookmarks BOOLEANA 1.00 R / W CapBookmark.
Esta propiedad se utiliza para controlar la aceptación de documentos marca de libro. Si es falso, el aceptador de billetes no aceptará
marcas de libro, si es cierto, entonces el libro se aceptarán marcas si la propiedad EnableAcceptance es cierto. Esta propiedad se ignora
si CapBookmark es falsa.

EnableCouponExt BOOLEANA 1.00 R W CapCouponExt /
Esta propiedad se utiliza para controlar la aceptación de documentos de descuento genéricos. Si es falso, el aceptador de billetes tratará
los cupones lo mismo que un proyecto de ley del mismo valor. Si esto es cierto, entonces cupones reciben un tratamiento especial y más
detalles sobre el cupón están disponibles vie la propiedad de cupón. Esta propiedad se ignora si CapCouponExt es falsa.

EnableNoPush BOOLEANA 1.00 R / W CapNoPush.
Esta propiedad se utiliza para controlar el manejo de las condiciones de atasco que requieren una pila del documento infractor. Si es falso, el
aceptador de billetes funcionará normalmente, si es cierto, el aceptador entrará en el estado DETENIDO cuando un atasco de las
necesidades de recuperación para apilar. Esta propiedad se ignora si CapBookmark es falsa.

West Chester
(s) PCN 500000008441

Tema

EscrowOrientation Orientación 1,00 R Después DeviceState == fideicomiso.
cuando CapOrientationExt.
punto de lectura: En plica factura. punto de escribir: n/A
Esto se refleja en la orientación de los billetes de banco que se introducen en el aceptador de billetes. Tenga en cuenta que códigos de barras,
cupones o marcadores no tienen datos de orientación. Los valores de orientación se especifican en la sección 9.1.5. Tenga en cuenta que si
CapOrientationExt es falsa entonces la orientación devuelto es siempre ORIENTATION_UNKNOWN.

Alta seguridad BOOLEANA 1.00 R / W Conectado.
Esta propiedad se utiliza para controlar los criterios de seguridad aplicadas al procesamiento de facturas. Este es un concepto un tanto obsoletos en
que la aceptación factura es normalmente a optimizar para la máxima aceptación y seguridad. Por lo tanto la mayoría de los aceptadores de billetes
ignoran este valor. Véase la sección 7.1.1 para más información sobre este parámetro.

OrientationCtl OrientationCtl 1.00 R / W Conectado.
Esta propiedad se utiliza para controlar los criterios de orientación aplicadas al procesamiento de billetes. Consulte las secciones 7.1.1 y 8.2.4
para más detalles sobre este ajuste.

OrientationCtlExt OrientationCtl 1.00 R / W CapOrientationExt.
Esta propiedad se utiliza para controlar los criterios de orientación aplicadas al procesamiento de billetes. Consulte las secciones 7.1.1,
8.2.4 y 8.2.5 para más detalles sobre este ajuste. Si CapOrientationExt es falsa, esta propiedad se ignora.

VariantID CUERDA 1,00 R CapVariantID.
Esta cadena propiedad contiene el ID variante factura. Esto toma la forma de una cadena. Para más detalles véase la sección 7.4.10.
Si CapVariantID es falsa, el valor es una cadena vacía.

VariantNames CUERDA[ ] 1,00 R Conectado.

West Chester
(s) PCN 500000008441

Tema
Esta propiedad es una matriz de cadenas que representan los códigos de país de las monedas aceptadas por el aceptador de billetes. Véase
la sección 7.4.9 para más detalles.

VariantPN CUERDA 1,00 R CapVariantPN.
Esta cadena propiedad contiene el número de pieza variante factura. Esto toma la forma de una cadena. Para más detalles véase la
sección 7.4.10. Si CapVariantPN es falsa, el valor es una cadena vacía.

Versión CUERDA 1,00 R Siempre
punto de lectura: los datos constantes. punto de escribir: n/A
Esta propiedad contiene la cadena de versión en el código M / POST. Para la versión 1.00 esta es la cadena “V1.00, 283792100”.
9.1.15 M / POST para eBDS Aceptador Métodos Detalles:
vacío abierto (CADENA port_name, tPowerUp POWER_UP)
Esta función se utiliza para abrir una conexión con el aceptador de billetes. Esta función sólo puede ser llamada cuando el
aceptador de billetes está en el estado desconectado. En cambio, se iniciará el proceso de conexión. Este proceso se completa
cuando el evento CONECTADO se envía a la aplicación y el estado de los aceptador de billetes se mueve pasado el estado de
conexión. Si no se puede establecer una conexión, el evento DISCONNECTED se envía a la aplicación para indicar el fracaso.
Si la unidad está “atascado” en el modo de descarga, el evento se envía DOWNLOAD_RESTART que la aplicación pueda reiniciar
la descarga de flash o señalar un error si esa opción no es compatible.
Excepción (s):
INVALID_PORT, INVALID_STATE
Cerrar (void)
Esta función se utiliza para cerrar la conexión con el aceptador de billetes. Esta función encapsula todos los requisitos de cierre de
sesión de aplicación descritos en la sección 6.3. Cuando se haya completado este proceso, el evento DISCONNECTED se envía a
la aplicación. Excepción (s):
ESTADO INVÁLIDO

West Chester
(s) PCN 500000008441

Tema
Calibrar vacío (vacío)
Esta función se utiliza para iniciar el proceso de calibración. Cuando el aceptador de billetes está dispuesto a aceptar el documento
de calibración, el CALIBRATE_START será enviado a la aplicación. A medida que progresa la calibración, el evento
CALIBRATE_PROGRESS informa al anfitrión. Cuando se ha completado la calibración, el evento CALIBRATE_FINISH informa a la
aplicación. Excepción (s):
INVALID_STATE, UNSUPPORTED_COMMAND
EscrowReturn vacío (vacío)
Esta función se utiliza para devolver el documento actualmente en depósito en garantía. Esto sólo puede hacerse cuando el estado es
FIDEICOMISO o PUP_ESCROW. Excepciones (s)
ESTADO INVÁLIDO
EscrowStack vacío (vacío)
Esta función se utiliza para apilar un documento actualmente en depósito en garantía. Esto sólo puede hacerse cuando el estado es FIDEICOMISO
o PUP_ESCROW. Excepciones (s)
ESTADO INVÁLIDO
FlashDownload vacío (ruta_archivo CADENA)
Esta función se utiliza para iniciar el proceso de actualización de la memoria flash del aceptador de billetes. Progreso
en La descarga se señala con la DOWNLOAD_START eventos,
DOWN_LOAD_PROGRESS y DOWNLOAD_FINISH. Excepción (s):
INVALID_STATE, FILE_NOT_FOUND, INVALID_FILE
ClearCashBoxTotal vacío (vacío)
Esta función se utiliza para borrar el recuento de billetes almacenados en la caja. Esta función sólo se puede llamar si el no
DeviceBusy y CapCashBoxTotal. Excepción (s):
INVALID_STATE, UNSUPPORTED_COMMAND, INVALID_ARG

West Chester
(s) PCN 500000008441

Tema
SetAssetNumber vacío (activo CADENA)
Esta función se utiliza para establecer el número de activos del aceptador de billetes y la caja de dinero en efectivo. Mira la sección
Excepción (s):
SpecifyEscrowTimeout vacío (INT32 bill_timeout,

INT32 barcode_timeout)
Esta función se utiliza para especificar los parámetros de tiempo de espera de depósito en garantía en su uso por el aceptador de billetes. Hay dos
ajustes, uno para billetes de banco y el otro para los códigos de barras. Ambos son en segundos de 0 a 127, donde 0 representa que no hay tiempo
de espera. Véase la sección 7.5.6 para más detalles. Excepción (s):
SpecifyPupExt vacío (pup_mode CHAR,

PupExt pre_escrow, PupExt
at_escrow, PupExt post_escrow,
PupExt pre_stack)
Esta función se utiliza para especificar los parámetros en uso por el aceptador de billetes para recuperarse de un proyecto de ley cuando se está
procesando durante un corte de energía. Véase la sección 7.5.3 para más detalles. Excepción (s):
void SetBezel (Bisel b)
Esta función se utiliza para anular el ajuste del bisel defecto. Tenga en cuenta que la configuración del bisel para el tipo incorrecto puede dar
lugar a ooperación bisel impredecible. Excepción (s):

West Chester
(s) PCN 500000008441

Tema
9.1.16 M / POST para eBDS Aceptador Eventos Detalles:

CONECTADO ninguna 1.00
Este evento se envía cuando se ha establecido la conexión con el aceptador de billetes.

DESCONECTADO ninguna 1.00
Este evento se envía cuando la conexión con el aceptador de billetes se ha terminado o se pierde. Para este último, véase la sección 8.4.2
para más detalles sobre el tratamiento de este evento.

FIDEICOMISO ninguna 1.00
Este evento se envía cuando un documento alcances de plica. El parámetro DOC_TYPE identifica el tipo de documento. Es importante
que pueden procesar todo tipo de documentos, aunque sea sólo para ser devuelto al consumidor. Dejando varados a un documento de
fideicomiso puede hacer que el aceptador de billetes sea incapaz de aceptar más notas.

PUP_ESCROW DOC_TYPE DocType 1.00
Este evento se envía cuando un documento se “encontró” en depósito en garantía durante el encendido. El parámetro DOC_TYPE
identifica el tipo de documento. Es importante que pueden procesar todo tipo de documentos, aunque sea sólo para ser devuelto al
consumidor. Dejando varados a un documento de fideicomiso puede hacer que el aceptador de billetes sea incapaz de aceptar más notas.

EMPILADA DOC_TYPE DocType 1.00
Este mensaje se envía cuando se apila un documento. Es en este momento que la aplicación debe fijar crédito para la transacción.
Cualquier entrega de productos y servicios no debe continuar hasta que este evento se señaliza con el crédito adecuado.

DEVUELTO ninguna 1.00
Este mensaje se envía cuando un documento se devuelve al cliente.

RECHAZADO ninguna 1.00

West Chester
(s) PCN 500000008441

Tema
Este mensaje se envía cuando un documento es rechazado por el aceptador de billetes. Véase la sección 8.4.4 para más detalles sobre el
tratamiento de este evento.

ENGAÑADO ninguna 1.00
Este mensaje se envía cuando se encuentra dificultad para el transporte de un documento que puede haber sido causado por un intento de
trucos. Véase la sección 8.4.3 para más detalles sobre el tratamiento de este evento.
MEI no ofrece un método para eventos de trucos del sistema / de la prueba.

CALIBRATE_START ninguna 1.00
Este mensaje se envía cuando se inicia el proceso de calibración y el usuario tiene que insertar el documento de calibración.

CALIBRATE_PROGRESS ninguna 1.00
Este evento indica que la calibración está en curso. Véase la sección 8.4.9 para más detalles sobre el tratamiento de este evento.

CALIBRATE_FINISH ninguna 1.00
Este evento indica que la calibración se ha completado.

DOWNLOAD_START TOTAL_NUM INT32 1.00
Este evento indica que la descarga de código se han iniciado y sectores TOTAL_NUM necesitan ser enviada al aceptador de billetes.

DOWNLOAD_RESTART ninguna 1.00
Este evento indica que el aceptador de billetes de potencia en modo de descarga. El sistema anfitrión tiene que reiniciar el proceso de
descarga.

PROGRESO DE DESCARGA sector_num INT32 1.00

West Chester
(s) PCN 500000008441

Tema
Este evento indica que la descarga de flash está en marcha y que los sectores sector_num se han enviado.

DOWNLOAD_FINISH éxito BOOLEANA 1.00
Este evento indica que la descarga ha terminado. El parámetro de éxito es cierto para el éxito y falsa para el fracaso.

PAUSE_DETECTED ninguna 1.00
Se envía cuando el aceptador de billetes está en pausa porque el cliente está alimentando facturas demasiado rápido. Véase la sección 8.4.8 para
más detalles sobre el tratamiento de este evento.

PAUSE_CLEARED ninguna 1.00
Se envía cuando la trayectoria del billete aceptador de billetes se borra por el cliente. Véase la sección 8.4.8 para más detalles sobre el

STALL_DETECTED ninguna 1.00
Este evento se envía cuando el aceptador de billetes queda estancado después de un esfuerzo anti-atasco. El aceptador de billetes requiere
atención para resolver el atasco. Véase la sección 8.4.13 para más detalles sobre el tratamiento de este evento.

STALL_CLEARED ninguna 1.00
Este evento se envía cuando el puesto de aceptación de billetes se borra después de la intervención del operador. La condición de error se
borra y la solicitud puede seguir.

JAM_DETECTED ninguna 1.00
Este evento se envía cuando el aceptador de billetes detecta un atasco. El aceptador de billetes requiere atención para resolver el atasco. Véase la
sección 8.4.5 para más detalles sobre el tratamiento de este evento.

JAM_CLEARED ninguna 1.00

West Chester
(s) PCN 500000008441

Tema
Este evento se envía cuando se elimina el atasco de aceptador de billetes, ya sea automáticamente o después de la intervención del
operador. La condición de error se borra y la solicitud puede seguir.

CASHBOX_REMOVED ninguna 1.00
Este evento se envía cuando la caja de efectivo se retira del aceptador de billetes. Esto sólo debería ocurrir como parte de los
procedimientos normales cuando se está recogiendo el dinero. Véase la sección 8.4.7 para más detalles sobre el tratamiento de este
evento.

CASHBOX_INSTALLED ninguna 1.00
Este evento se envía cuando la caja del dinero se devuelve al aceptador de billetes. Esto sólo debería ocurrir como parte de los procedimientos
normales cuando se está recogiendo el dinero. Véase la sección 8.4.7 para más detalles sobre el tratamiento de este evento.

ENCENDER ninguna 1.00
Este evento se envía cuando el aceptador de billetes se haya encendido o puesto a cero. Véase la sección 8.4.10 para más detalles sobre el

West Chester
(s) PCN 500000008441

Tema
10. M / POST Bindings para ActiveX

El objetivo de esta sección es proporcionar información específica OLE para desarrolladores en ese ambiente, especialmente los
desarrolladores que utilizan el lenguaje Visual Basic 6 de programación.
10.1 Conexión al POST DLL / M
Antes de poder utilizar el componente M / POST OLE desde Visual Basic o en otro entorno de desarrollo, la MPOST_OLE.dll debe
estar registrado. Si instala la POST OLE M / utilizando el programa de instalación, el instalador registrar la DLL. Si usas para
instalador sino que simplemente copiar MPOST_OLE.dll a su directorio elegido, tendrá que ejecutar la línea de comandos “regsvr32
MPOST_OLE.dll”. Dependiendo de la configuración de su Sytem, es posible que tenga que especificar la ruta completa para
regsvr32.exe. Esta utilidad debe estar ubicado en uno de los directorios de Windows.
Una vez que se ha registrado MPOST_OLE.DLL, tendrá que añadir una referencia al componente a su proyecto de Visual Basic.
Para ello, seleccione el comando Referencias en el menú Proyecto y seleccione mpost OLE 1.0 biblioteca de tipos (el número de
versión podría ser superior a 1,0).
Después de añadir la referencia, usted será capaz de declarar y utilizar una instancia del objeto aceptante o cualquiera de los otros
M / POST objetos, enumeraciones o declaraciones.
10.2 Gestión de eventos en Visual Basic 6
Visual Basic 6 hace que sea relativamente sencillo de manejar los eventos enviados por M POSTAL OLE /, pero hay que recordar que declarar el
objeto aceptoras, utilizando los WithEvents de palabras clave.

West Chester
(s) PCN 500000008441

Tema
WithEvents pública aceptador Como MPOST_OLELib.Acceptor
Al hacer esto, Visual Basic agregará “aceptador” a la lista de objetos (la lista desplegable en el lado izquierdo por encima del panel
de texto). Si selecciona “aceptador” de esta lista, verá la lista de todos los eventos apoyados en la lista desplegable en la parte
derecha.
Sólo tiene que seleccionar el evento deseado de la lista, y Visual Basic añadirá automáticamente una subrutina controlador para usted.
Private Sub Acceptor_Connected ()

'Añadir el código de controlador de aquí. End Sub
10.3 Diferencias con el modelo M / POST
Debido a las exigencias del entorno de programación OLE, se requirió algunos cambios en el modelo M / POST presentados en la
sección 9. Estos cambios se resumen a continuación:
Para cumplir con la convención, la propiedad se llama OrientationCtrl OrientationControl para que coincida con la enumeración
OrientationControl. Para el BNFStatus la enumeración:
modelo Valor OLE Encuadernación
Desconocido BNFUnknown
Okay BNFOK
NotAttached BNFNotAttached
Error BNFError
Para el tipo de documento enumeración:
Ninguna DocNone
Sin valor DocNoValue
Cuenta DocBill
Código de barras DocBarcode
Cupón DocCoupon
La enumeración Orientación
Hasta Hasta
Justo abajo Justo abajo
Leftup Leftup
Izquierda hacia abajo Izquierda hacia abajo
Desconocido OrientationUnknown

West Chester
(s) PCN 500000008441

Tema
La enumeración PowerUp
UNA CRISÁLIDA
si PUP_B
C PUP_C
mi PUP_E
10.4 Una nota sobre los valores de índice de matriz.
Para mantener la coherencia con el modelo M / POST, las matrices están basadas en cero, en lugar de una base, como es la
convención usual Visual Basic. Así índices válidos van de 0 a N-1, en lugar de 1 a N para una matriz de N elementos.
10.5 Una nota sobre los valores de propiedad de Boole.
Para la constancia con el modelo M / POST, los valores de propiedad booleanas utilizan 0 para falso y 1 para el verdadero, esto es diferente
de la costumbre de VB6. Para realizar pruebas sencillas de una propiedad no hay impacto, sin embargo, si se requieren operaciones más
complejas que será necesario comparar el valor con 1 como en el siguiente ejemplo:
Si cint (Acceptor.Connected) = 0 Entonces ...
en vez de
Si NO Acceptor.Connected Entonces ...
Para mayor compatibilidad, sólo se compara con 0. De esta manera, si el valor de la biblioteca M / POST para la verdadera debe ser cambiado, el
código de la aplicación seguirá funcionando correctamente. Por ejemplo el uso
Si cint (Acceptor.Connected) <> 0 Entonces ...
en vez de
Si cint (Acceptor.Connected) = 1 entonces ...
porque este último se romperá si se cambia el valor TRUE. El valor de FALSO siempre será 0.

West Chester
(s) PCN 500000008441

Tema
11. M / POST Bindings para .NET

Se proporciona el objetivo de esta sección para suministrar información específica para los desarrolladores .NET en ese entorno.
11.1 Conexión al POST DLL / M

La versión completa de M / POST tendrá un sistema de instalación completa. La versión temprana experiencia no lo hace. A fin de
utilizar M / POST es una aplicación, es necesario copiar el archivo MPOST.DLL en la carpeta del proyecto y “Agregar una
referencia” a la misma. En virtud de la entrada del menú Proyecto:
Y a continuación, busque el archivo DLL.

West Chester
(s) PCN 500000008441

Tema
11.2 Gestión de eventos M / POST en C #
Cuando M / POST envía eventos a una aplicación C #, que se manejan con los delegados. Se recomienda que los delegados se declaran
como los datos privados, como se muestra a continuación:
privado EscrowEventHandler EscrowedDelegate;
y que se conecta al controlador de la siguiente manera:
// Función Forma Ventana Constructor.

público EBDS_Bill_Acceptor () {
InitializeComponent ();
// Inicializar los deligates. EscrowedDelegate = nuevo EscrowEventHandler (HandleEscrowedEvent); // Equilibrio retiradas

para mayor claridad.
BillAcceptor.OnEscrow + = EscrowedDelegate; // Equilibrio retiradas para mayor

claridad. }
En el propio manejador, el programador de aplicaciones tiene que lidiar con el hecho de que los eventos M / POST se envían desde un
subproceso de trabajo. Esto significa que:
a) La interfaz de usuario no es directamente accesible debido mismo de la naturaleza única roscado.

b) Que si se envía un comando, o se accede a una propiedad, directamente desde el mismo hilo, el sistema podría encerrar en un
“abrazo mortal”.
Para resolver estos dos problemas, utilice siempre el mecanismo de .NET de invocación a los eventos del proceso. Esto se muestra a continuación:
private void HandleEscrowedEvent ( objeto remitente, EventArgs e) {
Si (InvokeRequired) {
BeginInvoke (EscrowedDelegate, nuevo objeto [] {Remitente, e}); }
más
{
// código de manejo de eventos va aquí! }}
Si el receptor de los acontecimientos no es una especie de ventana del formulario, será necesario el acceso a una ventana u otra forma de control de la ventana
para que esto funcione. Por ejemplo:
private void HandleEscrowedEvent ( objeto remitente, EventArgs e) {
Si (MainWin.InvokeRequired) {
MainWin.BeginInvoke (EscrowedDelegate, nuevo objeto [] {Remitente, e}); }
más
{
// código de manejo de eventos va aquí! }}

West Chester
(s) PCN 500000008441

Tema
11.3 Gestión de eventos M / POST en VB.NET
Cuando M / POST envía eventos a una aplicación VB.NET, que se manejan con los delegados. Se recomienda que los delegados se
declaran como los datos privados, como se muestra a continuación:
Privado EscrowedDelegate Como EscrowEventHandler
y que se conecta al controlador de la siguiente manera:
'Función Forma Ventana Constructor.

Public Sub New ()
InitializeComponent ()
'Inicializar los deligates.

EscrowedDelegate = Nuevo EscrowEventHandler ( Dirección de HandleEscrowedEvent)
'Balance retiradas para mayor claridad.
"Conectar a los eventos.

AddHandler BillAcceptor.OnEscrow, EscrowedDelegate
'Balance retiradas para mayor claridad.
End Sub
En el propio manejador, el programador de aplicaciones tiene que lidiar con el hecho de que los eventos M / POST se envían desde un
subproceso de trabajo. Esto significa que:
c) La interfaz de usuario no es directamente accesible debido mismo de la naturaleza única roscado.

d) Que si se envía un comando, o se accede a una propiedad, directamente desde el mismo hilo, el sistema podría encerrar en un
“abrazo mortal”.
Para resolver estos dos problemas, utilice siempre el mecanismo de .NET de invocación a los eventos del proceso. Esto se muestra a continuación:
Private Sub HandleEscrowedEvent ( ByVal remitente Como objeto , ByVal mi Como EventArgs)
Si InvokeRequired Entonces
BeginInvoke (EscrowedDelegate, objeto nuevo () {Remitente, e})
Más
'Código de manejo de eventos va aquí!
End If End
Sub

West Chester
(s) PCN 500000008441

Tema
12. M / POST Bindings para Linux

Se proporciona el objetivo de esta sección para suministrar información específica para los desarrolladores de Linux en ese entorno.
12.1. Uso de la biblioteca MPOST_Linux
Para instalar la biblioteca M / POST Linux, simplemente descomprimir el archivo MPOST_Linux.tar.gz. Usted tendrá que construir la
biblioteca y, si se desea, el programa de demostración. Estos proyectos fueron creados con Eclipse. Si tiene Eclipse, simplemente
importar los proyectos en su espacio de trabajo y de construcción.
Si usted no tiene Eclipse, puede crear cualquiera de los proyectos correspondientes en el IDE que está utilizando, o se puede construir a
partir de la línea de comandos. Es posible que los archivos make en los directorios de depuración y liberación funcionarán. Si no es así,
tendrá que compilar los archivos utilizando gcc u otro compilador de C ++. Con el fin de construir el proyecto MPOST_Linux_Demo,
necesitará ajustes del proyecto adicionales, que se describen a continuación.
El proyecto de C ++ MPOST_Linux está configurado para producir una biblioteca estática denominada MPOST_Linux (nombre de archivo real
libMPOST_Linux.a).
Todas las funciones M / POST que se necesitan para el acceso se encuentran en el CAcceptor clase. Para acceder a estas funciones, #
include el archivo de cabecera Acceptor.h. Para mayor comodidad, también se debe agregar la siguiente declaración:
utilizando mpost espacio de nombres;
La documentación M / POST en este manual fue escrito originalmente para el lenguaje C #. En algunos casos puede haber
diferencias en la sintaxis para llamar funciones. Consulte el archivo de cabecera Acceptor.h para la denominación exacta y la sintaxis
de las funciones y enumeraciones.
12.2. Gestión de eventos M / POST en Linux
Con el fin de gestionar un evento CAcceptor, primero definir una función con la firma siguiente:
vacío manejador de sucesos (CAcceptor *, int);
Tenga en cuenta que el parámetro int sólo se utiliza por los acontecimientos downloadStart y DownloadProgress. Ajuste el controlador de
eventos con una declaración como la siguiente:
acceptor-> SetEventHandler (ConnectedEvent, ConnectedEvenrHandler);
En la actualidad, cada evento puede tener sólo un manejador.

West Chester
(s) PCN 500000008441

Tema
12.3. Demo Programa de Linux mpost
Se incluye, además de la biblioteca de la POST Linux M / un programa de demostración que puede utilizar para verificar el M / POST está
funcionando correctamente y como se muestra código de ejemplo de cómo se usa la biblioteca. La versión más completa del programa de
demostración (incluye muestras de la mayoría de las funciones) es una aplicación de interfaz gráfica de usuario usando GTK. Si usted no tiene GTK
disponible, todavía se puede hacer referencia a la fuente de demostración para las muestras de llamar a las funciones CAcceptor. Además, se puede
construir una versión limitada de línea de comandos. Consulte el archivo MPOST_Linux_Demo / main.cpp para más información. Si lo hace construir
usando GTK y utilizar Eclipse, los archivos de proyecto proporcionan contener las bibliotecas y directorios correctos. Si se construye desde la línea de
comandos, que tendrá que decir la compilación para buscar la siguiente incluye directorios:

West Chester
(s) PCN 500000008441

Tema
13. M / POST Bindings para JAVA

Una de Java vinculante para M / POST no está previsto en este momento. Para investigar en cuanto a cualquier cambio en esta política por favor,
consulte el sitio Web en MEI www.meiglobal.com .

West Chester
(s) PCN 500000008441

Tema
14. El M / Demo Programa de POST
Las diferentes versiones de M / POST toda la nave con un programa de demostración que sirve para múltiples propósitos:
1. Es un banco de pruebas para validar la instalación del cliente del hardware y el software.
2. Es un vehículo útil para familiarizar a los desarrolladores de aplicaciones con las capacidades del hardware aceptador de billetes y el
software de la biblioteca.
3. El código fuente proporciona ejemplos de la manipulación de eventos y otras tareas de codificación requeridas del desarrollador
de la aplicación.
4. El programa de demostración servido como banco de pruebas para el desarrollo, prueba y depuración de la biblioteca Si bien habrá
varias versiones diferentes del programa de demostración, todo se basa en y similar al programa de demostración .NET presenta
aquí. Cuando se producen diferencias significativas, se resaltarán en el texto.
14.1 El Launcher
La pantalla del iniciador es la ventana inicial mostrado por la aplicación. Se muestra a continuación:
En este cuadro de diálogo simple, los controles se utilizan como sigue:

• El cuadro combinado de la izquierda contiene una lista de puertos disponibles.
• El botón del panel de control de lanzamiento se abre un panel de control en el puerto COM seleccionado en el cuadro combinado.
• El botón Actualizar lista de Puerto-actualiza el cuadro combinado para los casos en los que se añaden los puertos sobre la marcha (por ejemplo, la conexión de un
puerto USB o dispositivo).
• El botón Salir de la aplicación sale de la aplicación. Hubo un esfuerzo realizado para hacer que parezca más dramático, pero
sorta se concretó.
Tenga en cuenta que en la segunda barra de texto de la parte inferior, se muestra la versión y el número de pieza del POSTE DLL / M. Al
informar sobre cuestiones o solicitar ayuda, es importante hacer referencia a este número de referencia. La barra de texto inferior es un
recordatorio de que este es el código de MEI y no de dominio público. Por último, el mapa de bits de fondo está destinado a ser sugerente
del tema general del programa.

West Chester
(s) PCN 500000008441

Tema
14.2 El panel de control
El panel de control para un aceptador de billetes eBDS es un cuadro de diálogo multi-pestañas que permite un gran control y proporciona
información detallada sobre el aceptador de billetes adjunto. Cuando se muestra por primera vez el panel de control, que se encuentra en la ficha
Principal, y mientras el panel está abierto, la conexión con el aceptador de billetes no lo es. Esto se ilustra a continuación.
En esta condición, no hay mucho que se pueda hacer.

• El botón Abrir abre una conexión con el aceptador de billetes.
• El botón Cerrar cierra el panel de control
• El cuadro combinado Modo PUP se utiliza para seleccionar el Protocolo de poder a ser empleado mientras se abre la conexión.
Ver secciones 6.1 y 7.1.1 para más detalles sobre los diferentes modos de PUP. modos PUP sólo pueden ser seleccionados
antes de que se abre la conexión con el dispositivo. El cuadro combinado se ilustra a continuación:
Una vez establecida la conexión con el dispositivo, toda la gama de opciones se abre.

West Chester
(s) PCN 500000008441

Tema
14.2.1 La pestaña principal
La pestaña principal se utiliza para la mayoría de las operaciones de facturas. Desde este panel, el procesamiento de documentos puede ser visto.
Este panel se muestra a continuación:
• El área de eventos se utiliza para comandos de visualización y enviados a los eventos recibidos desde el objeto aceptador de billetes. La lista de
eventos se desplaza según sea necesario.
• El botón Guardar registro Como se puede utilizar para guardar el contenido de la lista de eventos en un archivo de texto.
• El botón Borrar registro borra el contenido de la lista de eventos.

• El botón de la pila sólo se activa cuando hay un documento en el aceptador de billetes a la espera de una decisión. Si se hace clic en este
botón, el proyecto de ley será colocado en la caja de efectivo.
• El botón de retorno sólo se activa cuando hay un documento en el aceptador de billetes a la espera de una decisión. Si se hace clic en
este botón, el proyecto de ley será devuelto al consumidor.
• Calibrar el botón se utiliza para iniciar un procedimiento de calibración de campo. Durante este procedimiento, un documento de
calibración específica del dispositivo se alimenta en la unidad y se analizó para ajustar los ajustes internos de la unidad. Dado que es
crucial que se utilizará el documento de calibración correcta, el programa verifica esto en la siguiente ventana emergente:

West Chester
(s) PCN 500000008441

Tema
Si se selecciona sí, entonces aparece el siguiente diálogo para la duración del proceso de calibración.
• El botón de descarga se utiliza para iniciar una actualización del código contenido en el aceptador de billetes. Cuando se selecciona en
primer lugar requiere la selección de un archivo para cargarlo en el dispositivo. Esto se logra en el cuadro de diálogo siguiente:
Una vez seleccionado el archivo, un diálogo de progreso traza el curso del ejercicio. Esto se muestra a continuación:

West Chester
(s) PCN 500000008441

Tema
Tenga en cuenta que el progreso de descarga es rastreada por tanto la barra de descarga y la lista de eventos en la pestaña principal. Cuando el
proceso de descarga se completa finalmente, se muestra el siguiente:
En caso de fallar la descarga, una descarga falló botón se presentó en su lugar.

West Chester
(s) PCN 500000008441

Tema
14.2.2 Las funciones de la ficha
La pestaña capacidades se utiliza para mostrar los resultados de la encuesta de capacidad de M / POST del aceptador de billetes.
Cada línea de esta tabla corresponde a una propiedad capacidad Boolean describe en las secciones 9.1.1 y 9.1.13. La casilla de
verificación valor refleja el estado de la capacidad. Comprobado estar disponibles y ser sin control no disponible. El campo de valor no
se puede modificar. Para ayudar a entender la naturaleza de cada capacidad, se proporciona una descripción también. Una tabla de
capacidades de muestra se muestra a continuación:
14.2.3 La pestaña Propiedades
La ficha de propiedades se utiliza para controlar las propiedades modificables por el usuario del aceptador de billetes. Las propiedades se discuten
en las secciones 9.1.1 y 9.1.13. Las propiedades que aparecen “en gris” no son compatibles con el aceptador de billetes actual. Un diálogo de
propiedades de la muestra se muestra a continuación:

West Chester
(s) PCN 500000008441

Tema
• El permitir la aceptación de casilla de verificación corresponde a la propiedad EnableAcceptance. Controla la aceptación de todo tipo de
documentos. Al establecer esta propiedad es la forma correcta para controlar la actividad del dispositivo (abusar de los métodos de
apertura y cierre es el camino equivocado).
• La casilla de verificación corresponde Auto Stack a la propiedad AutoStack. Cuando se establece, los documentos se apilan, sin pasar por
el evento de plica. Cuando está desactivada, se genera el evento de plica. En la demo, la disposición del proyecto de ley es entonces
controlado por los botones de la pila y el retorno de la ficha Principal.
• La casilla de verificación de código de barras corresponde a la propiedad Vales EnableBarCodes. Controla la aceptación
de los vales de código de barras.
• Los Marcadores Casilla de verificación corresponde a la propiedad EnableBookmarks. Controla la aceptación de los resbalones de
marcadores.
• La casilla de verificación Cupón extendidas corresponde a la propiedad EnableCouponExt. Cuando se selecciona, se reportan
cupones genéricos con mayor detalle.
• Los Sin empujón caja de verificación modo corresponde a la propiedad EnableNoPush. Cuando se selecciona, el aceptador de billetes pasan de
servicio en lugar de apilar un proyecto de ley para recuperarse de un atasco. se requerirá la intervención del operador para eliminar el atasco.
• La casilla de verificación corresponde modo de alta seguridad a la propiedad de alta seguridad. Cuando se establece, las normas más estrictas se utilizan en la
evaluación de los documentos. Tenga en cuenta que mientras que todos los aceptadores de billetes aceptan esta opción, pocos actúan en él.
• El botón de reajuste del software se utiliza para enviar un comando a SoftReset el aceptador de billetes. Este comando se discute en las
secciones 9.1.10 y 9.1.13. Habrá un retraso de varios segundos, mientras que el aceptador de billetes lleva a cabo esta acción.
• El área de control de orientación se utiliza para controlar la orientación de notas aceptados. El primer control orientación
combo-box corresponde a la capacidad básica de control de orientación. Esto es

West Chester
(s) PCN 500000008441

Tema
describe en la sección 8.2.4. El segundo control orientación combo-box corresponde a la capacidad de control de
orientación extendida. Esto se describe en la sección 8.2.5.
• Los tiempos de espera de depósito en garantía para billetes y documentos de códigos de barras se pueden establecer en la zona de depósito de garantía de
control de tiempo de espera. Los tiempos de espera para las facturas y códigos de barras se marcan con los cuadros de número apropiadas y el establecimiento
enviada al aceptador de billetes con el botón configurado tiempos de espera.
• El área de Control de bisel se utiliza para anular el ajuste del bisel aceptador de billetes.
• El área de comandos Raw permite valores hexadecimales arbitrarios para ser introducidos y enviados al aceptador de billetes. Los datos
se introducen con el STX, Longitud, ETX y el valor Comprobar omite. Para enviar el comando, o bien pulsa enter mientras el foco está en
el área de comando o haga clic en el botón Enviar. El área Responder cruda muestra el paquete de respuesta completa.
• La casilla de verificación del registro de depuración corresponde a la propiedad DebugLog. Cuando está activado, un registro de todo el tráfico se
escribe en la carpeta que aparece en el área de texto a la derecha. El área de texto corresponde a la propiedad DebugLogPath. El botón “...” a la
derecha del área de texto se utiliza para seleccionar una carpeta para colocar el registro en. Tenga en cuenta que la selección de una nueva
carpeta mientras que el registro está activo no tiene ningún efecto. La carpeta debe estar seleccionada antes de se inicia el registro. Se permite
iniciar el registro en una conexión que todavía no está abierto. Cuando se abre la conexión, el registro comenzará inmediatamente. Tenga en
cuenta que el registro puede consumir una gran cantidad de recursos del sistema y espacio en disco y se debe utilizar con cuidado.

West Chester
(s) PCN 500000008441

Tema
14.2.4 El conjunto de pestañas Bill
La pestaña conjunto ley se utiliza para visualizar el conjunto completo de proyecto de ley apoyado por el aceptador de billetes y corresponde a la
BillTypes y propiedades BillTypeEnables. El activar las casillas de verificación permiten un control preciso sobre exactamente qué tipo de cuentas
son aceptados. A continuación se muestra un ejemplo de la ficha tipos de facturas:

West Chester
(s) PCN 500000008441

Tema
14.2.5 El proyecto de ley Valores Tab
La pestaña conjunto ley se utiliza para mostrar una versión resumida del conjunto de proyecto de ley apoyado por el aceptador de billetes y
corresponde a la BillValues y propiedades BillValueEnables. El activar las casillas de verificación permiten un fácil control sobre exactamente lo que se
aceptan denominaciones de billetes. Tenga en cuenta que mientras que los cambios en esta ficha se reflejan en la ficha Tipos de Bill, los cambios en
el proyecto de ley Tipos pestaña Do no reflejar en esta ficha. Por lo tanto, se recomienda que sólo una pestaña se utiliza para controlar la aceptación de
letras. A continuación se muestra un ejemplo de la ficha valores de facturas:
Nota: En los aceptadores de billetes que no soportan la presentación de informes nota ampliada, en la ficha tipos de facturas y la pestaña Valores de facturas contienen
los mismos datos.

West Chester
(s) PCN 500000008441

Tema
14.2.6 La Información del dispositivo Tab
La última pestaña es la información del dispositivo. Esta ficha contiene una gran cantidad de información detallada sobre el aceptador de
billetes. Estos diversos campos se rellenan de acuerdo con la capacidad del dispositivo para informar de la información solicitada. Donde los
campos no están disponibles el texto “no compatible” aparece en lugar de los datos. El botón Actualizar todo actualiza esta ficha con
información fresca. Una muestra de la pestaña de información del dispositivo aparece a continuación:

West Chester
(s) PCN 500000008441

Tema
15. Dispositivo de arnés y Conexión
15.1 Opciones del arnés eBDS para el aceptador de billetes de la serie 2000:
Hay dos opciones principales del arnés para la serie 2000 aceptador de billetes. Estos son los arnés RS232 y el arnés USB. Estas
opciones pueden ser 250078075P - SERIE RS232 2000 CABLE DE INTERFAZ 250079066P1 - SERIE 2000 Interfaz USB ARNÉS
Diseño arnés 14.1.1 personalizada para el aceptador de billetes de la serie 2000:
En algunos casos, puede ser deseable para evitar los cables de intermediación o arneses. En estos casos un cable personalizado debe ser
fabricado para conectarse directamente a la unidad de la serie 2000. Las especificaciones para esta conexión se muestran a continuación: La
serie 2000, conector de 30 pines
12 pin de alimentación sub-conector 18 comunicaciones pines sub-conector
LENGÜETA
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Conexiones eBDS datos: Pin 10 -
Tierra de señal.
Pin 11 - Invertido TTL de datos en serie al Host. Pasador 25 - +5 V
CC a través de un resistor 200 ohm. Pin 26 - Invertido TTL serie de
datos entre el host.
Poder sub-pin Tipo de aceptador de billetes

conector 115V AC 24V AC / DC 12V DC
3 24V caliente
4 115 VAC Neutro

5 Llave Llave
6 Llave
dieciséis 12 VDC “-” neutral

19 Llave 12 VDC “+” Hot
20 115 VCA Vivo 24V Neutro
21 Tierra Llave Llave

West Chester
(s) PCN 500000008441

Tema
15.2 Opciones del arnés eBDS para el Cashflow SC-aceptador de billetes:
Los diversos modelos del soporte Cashflow-SC eBDS a través de un número de interfaces. Estos son controlados por el número de modelo
de la unidad de ordenado. Para obtener información de pedidos, contacto MEI ventas directamente.
14.2.1 RS-232 de configuración de arnés:
Las versiones RS-232 del empleo Cashflow-SC un conector de tipo Molex 12 pin muestran a continuación.
La configuración de pines de este cable se especifican a continuación:
Cashflow SC 12 pines Bloque de pines del conector de salida para la versión RS232 eBDS
Conector pin # Color del cable Señal
1 Blanco Bloqueo externo
2 gris Drive bisel LED

3 No poblado
4 Amarillo Fuera de servicio

5 Azul Suelo 2
6 Rosado RS232 eBDS RXD 1
7 Azul Suministro de energía Retorno 2
8 Púrpura Led de alimentación
9 No poblado
10 No poblado
11 Verde Fuente de alimentación 3
12 Bronceado RS232 TXD eBDS 1

West Chester
(s) PCN 500000008441

Tema
1 RXD es una entrada al aceptador de billetes. TXD es una salida. Todas las señales son verdaderos RS-232
NOTAS:
niveles.
2 Pines 7 y 5 se atan con un lazo de alambre en la parte trasera del conector de 12 patillas.
3 La fuente de alimentación debe estar dimensionado para 24 voltios y 72 vatios en toda la gama de
temperatura del sistema.
Configuración de arnés 15.2.2 USB:
Las versiones USB del Cashflow SC-utilizan dos arneses. La primera es la conexión convencional Molex 12 pin y el segundo es un
conector de tipo “B” USB para comunicaciones de datos con el sistema anfitrión.
Cashflow SC 12 pines Bloque de pines del conector de salida para la versión USB eBDS
Conector pin # Color del cable Señal
1 Blanco Bloqueo externo
2 gris Drive bisel LED

3 No poblado
4 Amarillo Fuera de servicio

5 Azul Suelo 1
6 No poblado
7 Azul Suministro de energía Retorno 1
8 Púrpura Led de alimentación
9 No poblado
10 No poblado
11 Verde Fuente de alimentación 2
12 No poblado
1 Pines 7 y 5 se atan con un lazo de alambre en la parte trasera del conector de 12 patillas.
NOTAS:
2 La fuente de alimentación debe estar dimensionado para 24 voltios y 72 vatios en toda la gama de
temperatura del sistema.
Cashflow SC de conexiones para USB “B” del zócalo.

West Chester
(s) PCN 500000008441

Tema
15.3 de Legacy, la serie (ZT) 1000 Opciones del arnés
El arnés de serie 1000 es un conector de 12 pin similar a la utilizada en la línea de productos Cashflow-SC. La siguiente tabla
resume las opciones eBDS arnés para la línea de productos de aceptación de billetes de la serie 1000. Estos datos se proporcionan
sólo con fines informativos.
señales de interfaz
RTU arnés # 251076029 RTU arnés # 251072043 RTU arnés # 251071030

Chaqueta amarilla Chaqueta roja Chaqueta azul
conector color del

Producto - ZT1207 Productos - ZT1202, ZT1204 Producto - ZT1201
Alfiler # cable Interfaces: IGT® NetPlex,

Interfaces: nisR / EBDS Opto aisladas:
IGT® Pulso,
RS232 eBDS Interfaz
Opto-aislado eBDS
1 Blanco PRESENTE CASSETTE Aux. UNA ----
2 gris BEZ_LED_OUT LED- Aux. si
3 rojo NISR_SEND Vopt Vopt
4 Amarillo FUERA DE SERVICIO Vret Vret
5 Azul SUELO SUELO SUELO
6 Rosado RS232 RXD Restablecer aislado Restablecer aislado
7 Negro NISR_INTERRUPT Aux. si ----

8 Púrpura LED_SUPPLY LED + Aux. C
9 marrón TXD / CRÉDITO TXD TXD
10 naranja OPT_RXD / ACC_EN RXD RXD
11 Verde PODER PODER PODER
12 Bronceado RS232 TXD ---- Aux. UNA
15.4 heredados, serie 3000 Opciones del arnés
Hay una opción principal arnés para la serie 3000 aceptador de billetes. Se trata de un arnés RS232: 111633139 - SERIE 3000
RS232 INTERFACE KIT DE JUNTA

West Chester
(s) PCN 500000008441

Tema
Conexión directa, sin el uso de un arnés No se recomienda ni admite. Alimentación a la unidad de la serie 3000 es proporcionada
por un arnés de nueve pines. Este arnés y su configuración se muestran a continuación:
pin conector de Tipo de aceptador de billetes

alimentación 115V AC 24V AC
4 115 VCA Vivo
5 24 VCA caliente
6 115 VAC Neutro 24 VAC Neutro

West Chester
(s) PCN 500000008441

Tema
Esta página se ha dejado intencionadamente en blanco.

West Chester
(s) PCN 500000008441

Tema
16. Referencia Rápida

Mensaje del controlador Mensaje de aceptor
STX (0x02) STX (0x02)
Longitud (0x08) Longitud (0x0B)
Tipo de mensaje / Ack (véase la descripción del controlador)

Descripción "1" indica
Tipo de mensaje / Ack Descripción "1" indica Byte
El bit 0 de secuencias de mensajes Alterna
0
Bit 1-3 Reservados - siempre 0 Bit 4-6 Tipo de
El bit 0 De marcha en vacío A la espera de un proyecto de ley.
mensaje (ver más abajo)
El bit 1 aceptando Tomando un proyecto de ley
Tipo de alta Nibble
bit 2 de depósito en garantía Bill está en fideicomiso
0x reservados
bit 3 Apilado Apiladora está moviendo
Anfitrión 1x 2x estándar de comandos
bit 4 apilada Bill fue apilada
estándar de dispositivos de respuesta 3x
Bit 5 Volviendo La devolución de un proyecto de ley
Host Comando + Favoritos 4x 5x Calibrar
El bit 6 devueltos Bill fue devuelto
Solicitud de Flash Solicitar 6x auxiliar
Comandos 7x extendido Mensaje Marcar Byte 1
Bit 0 engañados Se detectó un tramposo
El bit 1 Rechazado Bill fue rechazada
bit 2 Apretado Bill se ha atascado
byte 0 bit 3 apiladora completa Stacker es completa
Bit 0 Denom 1 Aceptar habilitar habilitar Bit 1 Denom bit 4 LRC Estado LRC Instalado
2 Aceptar Habilitar Habilitar Bit 2 Denom 3 Aceptar bit 5 En pausa Aceptor está en pausa
Habilitar Habilitar Bit 3 Denom 4 Aceptar Habilitar Bit 6 Calibración Aceptador está calibrando Byte
Habilitar Bit 4 Denom 5 Aceptar Habilitar Habilitar Bit
5 Denom 6 Aceptar habilitar habilitar Bit 6 Denom 7 2
Acepte Habilitar Habilitar El bit 0 Encender El dispositivo fue reinicio
El bit 1 Comando inválido Mal de comandos desde el host
bit 2 Fracaso Fuera de servicio
byte 1 bit 3-5 Bit 5 4 3 Bill Valor / Denom 0x00 0 0 0
El bit 0 Interrupción Modo especial Bit Activado 1 de Alta Ninguno / No valor 0x08 0 0 1 Denom 1 0x10 0 1
Seguridad Activado 0 Denom 2 0x18 0 1 1 Denom 3 0x20 1 0 0
Bit 2-3 Bill Orientación Enable (ver tabla a continuación) Denom 4 0x28 1 0 1 Denom 5 0x30 1 1 0 denom
Bit 3 2 Orientación 6 0x38 1 1 1 denom 7 Bit 6 0 Actualmente
001012
Camino Camino 1
x 4 Way
bit 4 Modo de depósito de garantía plica Habilitado
bit 5 Bit Pila de comandos Apilar el proyecto de ley RFU
Bit Bit 6 comando de retorno Devolver el proyecto de ley
Byte 3
byte 2 El bit 0 Empujar / No empuje Aceptor se estancó.
El bit 0 Modos de empuje de empuje / No Sin Push Mode El bit 1 flash Descargar A partir de Flash D / L.
Bit 1 Códigos de barras Decode Habilitar bit 2 Pre-stack Obsoleto

bit 2 Poder encima de B Secuencia Habilitar El bit 3 del código de barras Raw Soporta 24 códigos de bytes
bit 3 Power Up C Secuencia Habilitar Bit 4 Caps de Dispositivos permite QryDeviceCaps
bit 4 Bill ampliado Conjunto Habilitar bit 5-6 Actualmente 0 RFU

bit 5 Cupón ampliado Habilitar
Byte 4
Actualmente bit 6 0 RFU
Todas Modelo # (00-7FH)
ETX (0x03) byte 5

Todas Código de revisión (00-7FH)
CheckSum
ETX (0x03)
Advertencia
CheckSum
Una y campos RFU ma ybec han de GED en un yti mí.

West Chester
(s) PCN 500000008441

Tema
17. Hex / binario y conversión de datos ASCII

Cuando se desarrolla un anfitrión en un lenguaje de alto nivel, uno a menudo se aisló desde el nivel de “bits” bajas del protocolo. La tabla
siguiente facilita la decodificación de los datos de bits de siete contenida en un flujo de datos eBDS. El bajo y los dígitos altos
hexagonales pueden traducirse en las posiciones de bit correspondientes. Esto a su vez facilita la búsqueda de campos en las diferentes
secciones de esta especificación.
Dígito Maleficio → 0 1 2 3 4 5 6 7 8 9 ABCDEF
El bit 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 Bit
0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 Bit 2
Bajo
0000111100001111
bit 3 0000000011111111
bit 4 01010101
Alto bit 5 00110011
El bit 6 00001111
Dado que muchos paquetes eBDS contienen datos ASCII, se proporciona este Hex a tabla de conversión ASCII para facilitar la interpretación de los
registros de transacciones.
H/L0 1 2 3 4 5 6 7 8 9 ABCDE F
0 NUL SOH STX ETX EOT ENQ ACK BEL BS TAB LF VT FF CR SO SI
1 DLE DC1 DC2 DC3 DC4 NAK SYN ETB LATA EM SUB ESC FS GS RS de EE.UU.
2 ! " # PS ' ( ) * + , - . /
3 0 1 2 3 4 5 6 7 8 9 : ; < => ?
4 @ ABCDEFG H yo JKLMNO
5 PQRSTUVW X YZ [ \ ] ^ _
6 ` una si C re mi F sol h yo j k l Minnesota o
7 pag q r s t u VWX y z { | } ~ DEL
Notas: Entrada 20 es un carácter de espacio. entradas en cursiva son códigos de control no imprimibles.

RETAIL EBDS PROTOCOL SPECIFICATION With MPOST G2.en - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

RETAIL EBDS PROTOCOL SPECIFICATION With MPOST G2.en - Es

Cargado por

Copyright:

Formatos disponibles

Sitio aplicable ÁRBITRO 20105-002.850.

Al por menor - eBDS Protocolo de Especificaciones Problema G2

MENOR eBDS PROTOCOLO

Copyright © 2008 MEI Inc

Aunque se ha hecho todo lo posible para garantizar la exactitud e integridad de la información

Derechos de autor © 2008 MEI, Todos los derechos reservados

Al por menor - eBDS Protocolo de Especificaciones Problema G2

Se ha actualizado la introducción a cubrir M / POST. Añadido advertencia

Se agregó la propiedad DebugLogPath y una sección para el programa de

Se ha corregido los valores de ID de modelo para Zt1200 estadounidense y las

N / A 28 de Nov, de 2007 los comentarios de Dave McLaughlin Incorporated Peter Camilleri

Derechos de autor © 2008 MEI, Todos los derechos reservados

Al por menor - eBDS Protocolo de Especificaciones Problema G2

1.1 Alcance _________________________________________________________________________7

1.2 Recomendación / advertencia Icons__________________________________________________8

1.3 Iconos Producto __________________________________________________________________8

1.4 Variedades de eBDS ______________________________________________________________9

2. Un protocolo general ______________________________________________________ 10

3. Capa Física La _______________________________________________________ 11

3.2 RS-485 _______________________________________________________________________ 11

3.3 ópticamente Isolated______________________________________________________________11

3.4 USB _________________________________________________________________________11

4. El enlace de datos 13 Layer______________________________________________________

4.1 Paquetes de Datos Construction_______________________________________________________13

4,2 Normal (Polled) Mode__________________________________________________________13

4.3 Especial (Interrupción) Modo _______________________________________________________14

4.4 Recepción de una respuesta ______________________________________________________________16

4,5 ACK Procesamiento / NAK __________________________________________________________17

5. La red de capa _______________________________________________________ 20

5.2 ABDS de enrutamiento de mensajes ________________________________________________________21

6. La Sesión de capa ________________________________________________________ 23

6.1 Las variaciones en la presentación de informes Power Up ________________________________________________23

6.2 A partir del modo de descarga _____________________________________________________23

6.2 Terminar la Session_____________________________________________________________24

7. La capa de presentación (por aceptador de billetes) ____________________________________ 25

7.1 El Omnibus Command________________________________________________________25

Derechos de autor © 2008 MEI, Todos los derechos reservados

Al por menor - eBDS Protocolo de Especificaciones Problema G2

7.1.1 Ómnibus Command_________________________________________________________________26

7.2 El orden de calibración _______________________________________________________37

7.3 El comando Descarga de firmware ______________________________________________38

7.4 El Commands_______________________________________________________42 auxiliar

7.5 El Commands_______________________________________________________61 Extended

7.6 Procesamiento de Estados ______________________________________________________________67

8. La capa de aplicación (por Bill aceptor) _____________________________________ 70

8.1 Tareas de inicio de aplicaciones ______________________________________________________70

8.2 Aplicación de divisas Handling__________________________________________________71

8.3 La determinación de la Version_______________________________________________74 firmware

Derechos de autor © 2008 MEI, Todos los derechos reservados

Al por menor - eBDS Protocolo de Especificaciones Problema G2

8.3.2 Versión de firmware en eBDS extendido: __________________________________________________75

8.4 Controlar excepciones aceptoras ___________________________________________________75

9. MEI Punto de Servicio Toolkit (M / POST) ______________________________________ 78

9,1 M / POST para eBDS general: ___________________________________________________78

10. M / POST Bindings para ActiveX ___________________________________________ 101

10.1 Conexión al POST DLL M / _______________________________________________101

10.2 Gestión de eventos en Visual Basic 6 ______________________________________________101

10.3 Diferencias con el modelo M / POST ___________________________________________102

10.4 Una nota sobre los valores de índice de matriz. __________________________________________________103

10.5 Una nota sobre los valores de propiedad de Boole. _____________________________________________103

11. M / POST Bindings para .NET _____________________________________________ 104

11.1 Conexión al POST DLL M / _______________________________________________104

11.2 Gestión de eventos M / POST en C # _______________________________________________105