(FR) Décrypter trame de comunication cctalk. Un exemple.
(PT) Decifrar comunicação cctalk. Um exemplo.
---------------------------------------------------------------------------------------------------------------------------------
PARA REPASAR: Si queréis podéis revisar otras entradas anteriores sobre el tema: El adaptador para conectar el bus ccTalk al pc y como obtuve los códigos que voy a intentar entender...
Sobre hopper Azkoyen buscando en la web por "protocolo cctalk hopper u-ii".
Sobre selector de monedas buscando por "modular x6 cctalk".
Exponemos como resumen unas ideas a tener claras:
La comunicación con el protocolo ccTalk es half duplex y asíncrona. Las señales son como el RS232 pero con niveles de tensión TTL (5v para un 1 lógico, y 0v para un 0 lógico). Comúnmente 9600 baudios, 1 bit de start, 8 bits de datos, sin paridad y 1 bit de stop. El bus ccTalk sólo tiene una linea de datos. Que con el adaptador al pc, entrarán (se leerán) por Rx y saldrán (se transmiten) por Tx, pero en el bus cctalk estarán todos en la misma linea DATA. Ningún dispositivo cctalk enviará nada a la linea DATA si no se le ordena antes por el maestro. Todos estarán en modo "lectura" y "calladitos" hasta que toque responder a lo que la unidad central maestra mande. Momento éste, en que la unidad central, permanecerá "en silencio" y a la escucha de la respuesta.
La forma y estructura de un mensaje cctalk estándar es la siguiente:
[Dirección de destino] [Número de bytes de datos] [Dirección de origen] [Cabecera u orden] [Dato1] [Dato2]...[Dato N] [Checksum]
(También hay mensajes encriptados y con control de redundancia cíclica de 16 bits, pero aún no me he peleado con ellas)
Cada secuencia de comunicación mínima consta de dos tramas según este formato. Primero desde el maestro, indicándole algo al esclavo, y luego, la respuesta del esclavo. Si el esclavo no contesta se considerará un error y el maestro repetirá el intento. Una comunicación correcta requiere de envío y respuesta.
[DIRECCIÓN DE DESTINO] Indica a que dispositivo va dirigido el mensaje. Pueden ser desde la 0 a la 255. Algunas son especiales. La 0 afecta a todos los dispositivos, a modo de llamada general, todos se dan por enterados. La 1 es siempre la dirección del control o dispositivo maestro. Desde la 2 a la 255 corresponde una a cada dispositivo. No debe de haber dos dispositivos en el mismo bus con la misma dirección. Ésta se configura por switches o por comandos. Aunque, esto ya no es obligatorio, dispositivos como un selector de monedas suele ser la dirección 2, y los pagadores 3, 4, y 5.
[NÚMEROS DE BYTES DE DATOS] Este byte indica el número de Datos (N) del mensaje. Si es 0, el mensaje no envía datos y el número total de bytes será cinco (dirección mensaje, nº de datos, dirección origen, cabecera, y checksum).
[DIRECCIÓN DE ORIGEN] Indica "quien" envía este mensaje.
[CABECERA] Cada número indica una orden específica a la que el dispositivo obedecerá. Hay algunas especiales: 0 ACK incida que el dispositivo ha realizado correctamente el comando; 5 NACK por algún error el comando no se ha realizado; 6 BUSY el dispositivo en cuestión está ocupado, y no puede obedecer en este momento.
[DATOS] Puede ser cualquier byte entre 0 y 255 y el significado dependerá del comando a ejecutar.
[CHECKSUM] Para comprobar que no ha habido errores se suman todos los bytes del mensaje (incluido el de checksum) y la suma deberá ser tal que los últimos 8 bits del resultado sea 0. (00 en hexadecimal)
------------------------------------------------------------------------------------------------------------------------------
Sabido lo anterior veamos qué conseguimos descifrar de la trama conseguida en su día y expuesta en una entrada anterior. Recordar que durante la trama se ha introducido una moneda de 2 euros, la máquina ha devuelto 1euro y 80 céntimos (1euro + 4 de 0.20euros) y ha jugado un crédito.
Los códigos están en hexadecimal.
El primer problema es saber en donde empieza la verdadera "conversación". Alguna lectura inicial puede ser fruto de picos de encendido de la máquina, los dispositivos ccTalk no hacen caso hasta que pase un tiempo desde que son alimentados (250 ms algún selector de azkoyen, 200 ms algún hopper...)
La primera ristra de datos es: FE 00 04 00 01 EC OF 01 01 04 00 00 FA 05 00 01 ...
Sabemos que han de ser como mínimo 5 bytes y todos juntos han de sumar un número que acabe en 00 en hexadecimal. Además el primer mensaje debería tener como dirección de origen a la máquina de control(01). El primer 01 en la tercera posición nos forma el mensaje 04 00 01 EC 0F cuyos bytes suman 100h. Olvidémonos entonces de FE 00 y comencemos con:
-------------------------04 00 01 EC 0F
Para el dispositivo 04, se envían 00 datos, desde la cpu 01, con la orden EC (236 en decimal, LECTURA ESTADO DE OPTOS), y la suma de verificación 0F
Y la contestación:01 01 04 00 00 FA
Para la cpu 01, se envía 01 dato, desde el dispositivo 04 (probablemente un hopper), con cabecera 00 (es una contestación de conformidad), el dato es 00 (00000000 en binario), y la suma de verificación o checksum FA.
Supongo un pagador de Azkoyen, que es del que he encontrado información en internet.
Analizando el dato: El bit0, menos significativo, corresponde al optoacoplador que detecta si el pagador está vacío (0 si está cortado el haz con monedas y uno si nada obstruye la luz del diodo emisor al receptor). El bit1 indica si el pagador está lleno. Los otros bits del 2 al 7 no se usan. Así que el dato devuelto podría ser: 00h=00000000b (hopper lleno de monedas), 02h=00000010b (hopper a media carga), y 03h=00000011b (hopper vacío). Una contestación de dato 01h=00000001b sería que está activo el sensor de vacío, por lo tanto vacío, pero al mismo tiempo cortado el haz del opto de lleno y por tanto lleno. El hopper o pagador no puede estar lleno y vacío al mismo tiempo y debería ser considerado por la cpu un error.
El caso que nos ocupa, el dato devuelto es 00, por lo tanto el hopper 04 está lleno o "¡no tiene optos!"
Luego se repiten la pregunta y respuesta para los dispositivos 05 y el 03 (que también suelen ser pagadores):
05 00 01 EC 0E---------01 01 05 00 00 F9
03 00 01 EC 10---------01 01 03 00 00 FB
Y vemos, por la respuesta 00, que también llenos.
------------------------
03 00 01 A3 59-----------01 01 03 00 80 7B
Para el hopper 03, 0 datos, desde la cpu, A3 (163 en decimal, TEST HOPPER), y checksum.
El comando A3h=163d provoca el envío de información acerca de varios flags de error y operación del hopper. Los flags guardan información desde la última vez que se preguntaron, pasan la información y se reinicializan. Sólo envía un dato por lo que debe de tratarse de un hopper UII cctalk standard. Existe el hopper UII cctalk PLUS que respondería con dos datos.
Siendo 1=cierto y 0=falso, analizamos el dato devuelto:
El bit0 indica corriente máxima absoluta excedida. El bit1 tiempo máximo de pago excedido. El bit2, motor girando en sentido contrario durante el último pago para eliminar un atasco. El bit3, intento de fraude de fotocélula, salida bloqueada durante el reposo. Sensor de moneda no detectado. El bit4, intento de fraude de fotocélula, detección de moneda en reposo. El bit5, fotocélula bloqueada permanentemente durante el pago. El bit6, no se utiliza. El bit7, pago inhabilitado.
Para la cpu 01, se devuelve 01 dato, desde el hopper 03, correctamente 00: el 80h=10000000b. Así que el hopper 03 le contesta a la cpu que tiene el pago inhabilitado.
------------------------
04 00 01 EC 0F---------01 01 04 00 00 FA
Vuelve a hacer una "lectura de estado de optos" del hopper 04 y éste le responde lo mismo
04 00 01 A3 58----------01 01 04 00 80 7A
Y un "test de hopper" 04 que también contesta: "inhabilitado".
-----------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 EC 10-----------01 01 03 00 00 FB
05 00 01 A3 57-----------01 01 05 00 80 79
03 00 01 A3 59-----------01 01 03 00 80 7B
Y lo mismo con los hoppers 5 y 3.
-----------------------
(...)
Luego se pasa un buen rato haciendo lo mismo. Mientras no pasa nada chequea los hoppers continuamente.Ya en el siguiente bloque de la foto encontramos, en la quinta linea algo nuevo.
05 00 01 F2 08
Para el hopper 5, sin datos, ordenado por la cpu (01), orden F2 (242decimal=PETICIÓN Nº DE SERIE), y checksum.
Cada hopper tiene un número de serie de fábrica. Este número será necesario saberlo para ordenar un pago de monedas.
01 03 05 00 6B 8F 12 EB
El hopper 5 contesta a la cpu con tres datos que forman el número de serie. El primer dato es el menos significativo, y el tercero el más. Así que el número de serie es: 128F6Bhexadecimal=1216363decimal
---------------------------
05 00 01 A6 54----------01 04 05 00 00 00 00 00 F6
Para hopper 5, sin datos, la cpu (01), ordena A6(166decimal=CONSULTA DEL ESTADO DEL HOPPER), y checksum.
Para la cpu(01), con 4 datos, el hopper 5, responde (00):
El primer dato serán los pagos hechos desde el último reset (del valor FFh=255d se pasa al 1, de manera que un 0 es que no se ha pagado nada desde un reset). El segundo dato será las monedas pendientes de pagar. El tercero, el número de monedas pagadas en el último pago (éste si estuviésemos pagando). Y el cuarto, el número de monedas pendientes de pagar en un pago anterior. La información se guarda en la EPROM del hopper aunque falle la alimentación. Podremos recuperar la información al reiniciar el pagador. Tras un reset los cuatro datos se ponen a cero. Este es nuestro caso aquí.
-------------------------------
05 01 01 A4 A5 B0----------01 00 05 00 FA
Para el hopper 05, se le da un dato, desde la cpu(01), la orden A4(164decimal=HABILITAR HOPPER), el dato es A5, y el checksum. El comando A4h(164d) se debe utilizar para habilitar el pagador antes de pagar monedas con cualquier orden de pago. Si el dato que se envía es A5h se habilita el hopper. Si es distinto de A5 el hopper estará deshabilitado.
La segunda secuencia es el hopper que contesta, a la cpu, que la orden ha sido realizada con éxito (00).
----------------------------------
05 04 01 A7 6B 8F 12 01 42----------01 00 05 00 FA
Para el hopper 5, cuatro datos, desde la cpu(01), la orden A7h(167d PAGAR MONEDAS CON HOPPER). De los cuatro datos, los tres primeros datos son el número de serie que nos facilitó el comando F2, y que son necesarios para construir esta orden A7 y que el hopper pague la cantidad de monedas que indica el cuarto dato. En este caso una moneda.
Si se puede hacer el pago el hopper devuelve una trama de aceptación como en este caso y comienza a efectuar el pago hasta que extraiga todas las monedas indicadas, se detecte un vano máximo, se reciba una orden de cancelación, se detecte un error, o haya un reset o fallo de alimentación.
Si no se puede pagar por un error, porque el hopper esté ocupado con otra orden, o el código (nºserie) no sea correcto, éste devolverá una trama de reconocimiento negativo.
-------------------------------------
03 00 01 EC 10----------01 01 03 00 00 FB
Vuelve a hacer lectura de optos del hopper 3, e indica hopper lleno.
-------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Después de ordenar el pago, se hace un seguimiento de este. Esta trama vuelve a pedir una A6h(166d CONSULTA DEL ESTADO DEL HOPPER). 01 pago ordenado desde el último reset (éste). 01 moneda pendiente de pagar. 00 monedas pagadas en este pago (así que no ha realizado todavía el pago ordenado) y 00 monedas pendientes de pagos anteriores.
Así que debe de estar pagando. Sigamos controlándolo.
--------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Seguimos como estábamos, pendiente de pagar una moneda el hopper 5.
---------------------------------------
04 00 01 A3 58----------01 01 04 00 80 7A
Se chequea el hopper 4 (A3h=163d=TEST HOPPER) y el hopper contesta. Pago deshabilitado.
---------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
Lectura del estad de optos (ECh=236d). Hopper 4 lleno de monedas.
---------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4 (dos veces)
Y seguimos pendientes del pago de una moneda del hopper 5.
--------------------------------------
03 00 01 EC 10----------01 01 03 00 00 FB
Lectura del estado de optos (ECh=236d). Hopper 3 lleno de monedas.
--------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
03 00 01 A3 59----------01 01 03 00 80 7B
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
04 00 01 EC 0F---------01 01 04 00 00 FA
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4 (dos veces)
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 EC 10----------01 01 03 00 00 FB
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Chequeando continuamente los hoppers sin novedades....
---------------------------------------
05 00 01 A6 54----------01 04 05 00 01 00 01 00 F4
Aquí hay un cambio en la respuesta. Los datos de respuesta del estado del hopper 5, que hasta ahora eran siempre 01 01 00 00, en este mensaje pasan a ser 01 00 01 00. Ya no hay monedas pendientes de pagar, y en el último pago se pagó una moneda. Por fin, el hopper 5 nos indica que ha pagado una moneda.
----------------------------------------
05 00 01 F2 08----------01 03 05 00 6B 8F 12 EB
La cpu vuelve a consultar el número de serie del hopper 5.
----------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
El hopper 4 sigue lleno.
----------------------------------------
05 01 01 A4 00 55----------01 00 05 10 FA
Se deshabilita el pago del hopper 5.
----------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A3 59----------01 01 03 00 80 7B
Más chequeos del estado de los hoppers.
-----------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
Consulta del número de serie del hopper 3. Este es 0E902Bh=954411d.
-----------------------------------------
03 00 01 A6 56----------01 04 03 00 00 00 00 00 F8
Consulta del estado del hopper 3. Sin pagos realizados ni pendientes desde el reset.
----------------------------------------
03 01 01 A4 A5 B2----------01 00 03 00 FC
Habilitar el hopper 3 para pagos.
-----------------------------------------
03 04 01 A7 2B 90 0E 01 87----------01 00 03 00 FC
Que el hopper 3 pague una moneda.
----------------------------------------
05 00 01 A3 57----------01 01 05 00 80 79
Y seguimos revisando fotocélulas del hopper 5.
----------------------------------------
03 00 01 A6 56-----------01 04 03 00 01 01 00 00 F6
Y también se sigue revisando como va el pago del hopper 3. Pendiente de pagar una moneda de una orden de pago.
----------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
04 00 01 A3 58----------01 01 04 00 80 7A
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6 (tres veces)
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
05 00 01 EC 0E----------01 01 05 00 00 F9
05 00 01 A3 57----------01 01 05 00 80 79
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6 (dos veces)
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 00 01 00 F6
Hasta aquí ha estado chequeando continuamente los hoppers y el pago del hopper 3. Aquí, por fin, el hopper 3 confirma que ha pagado una moneda.
------------------------------------------------------------
03 00 01 f2 0A----------01 03 03 00 2B 90 0E 30
La cpu consulta el número de serie del hopper 3 que es 0E902Bh=954411d.
-------------------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A3 59----------01 01 03 00 00 FB
Vuelta a revisar el estado de los hoppers.
--------------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
03 00 01 A6 56----------01 04 03 00 01 00 01 00 F6
03 01 01 A4 A5 B2----------01 00 03 00 FC
03 04 01 A7 2B 90 0E 03 85----------01 00 03 00 FC
03 00 01 A6 56----------01 04 03 00 02 03 00 00 F3
Vuelve a habilitar el pago del hopper 3, pero esta vez (segundo pago) le manda pagar 3 monedas.
Obsérvese que parece seguir siempre el mismo procedimiento.
1º pedir el nºde serie del hopper F2
2º observar el estado del pago A6
3º habilitar el hopper para pagar A4
4º ordenar el pago A7
5º estar pendiente del pago A6
6º y cuando finalmente se ha pagado inhabilitar el hopper para el pago A4
---------------------------------------------
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 A6 56----------01 04 03 00 02 03 00 00 F3
04 00 01 EC 0F----------01 01 04 00 00 FA
05 00 01 A3 57----------01 01 05 00 80 79
Se sigue revisando. Hasta aquí nada nuevo.
-----------------------------------------------
03 00 01 A6 56----------01 04 03 00 02 02 01 00 F3
Aquí cambia algo la cosa. Es el segundo pago. Ya solo tiene 2 monedas pendientes de pago, porque ha pagado 1 y no debe nada de ningún pago anterior. Vemos que el hopper está pagando.
---------------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A6 56----------01 04 03 00 02 01 02 00 F3
En este segundo pago del hopper 3 ya ha pagado 2 monedas y queda 1 por pagar.
--------------------------------------------
03 00 01 A6 56----------01 04 03 00 02 01 02 00 F3
03 00 01 A6 56----------01 04 03 00 02 00 03 00 F3
Se han pagado las tres monedas y no quedan pendientes.
--------------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
04 00 01 EC 0F----------01 01 04 00 00 FA
03 01 01 A4 00 57----------01 00 03 00 FC
Inhabilita el hopper 3 para pagos. Ya hemos acabado de pagar.
---------------------------------------------
Y desde aquí hasta el final ya se pasa todo el tiempo chequeando el estado de los hoppers. La máquina ya ha pagado una moneda del hopper 5 y cuatro del hopper 3 (en dos veces 1+3).
Todo corresponde con lo que me esperaba, salvo que no he encontrado el código de comunicación con el selector de monedas. Y ya he comentado, que he introducido una moneda de 2euros. Esto me ha extrañado, pero después de revisar el esquema eléctrico de la máquina, me he encontrado con que, no todos los dispositivos van unidos al mismo bus cctalk, como pensaba. Sino que, en esta máquina, el selector de monedas tiene su línea de comunicación cctalk propia con la cpu, los hoppers otra diferente y el lector de billetes también la suya propia, todas independientes. Para hacer el monitorizado de la comunicación yo he conectado a la linea de los hoppers, por eso únicamente aparece comunicación de pagos.
De todas formas me queda constatado que las cosas funcionan como yo había entendido, y aquí queda un rollo curioso para el que le interese el asunto.
He revisado un par de veces lo que escrito. Esta entrada es un poco densa y espero no haber metido la pata. Pero como siempre, ya sabéis que no os debéis fiar a ciegas. Aunque trato de ser exacto, muchas veces cometo errores, como todo el mundo. Mi afán en este blog es aprender yo mismo. Así que si detectáis algún fallo, o algo importante que aportar, me encantarían comentarios o emails.
Saludos.
(CONTINÚA CON:Otra entrada sobre trama cctalk de un selector de monedas)
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 EC 10-----------01 01 03 00 00 FB
05 00 01 A3 57-----------01 01 05 00 80 79
03 00 01 A3 59-----------01 01 03 00 80 7B
Y lo mismo con los hoppers 5 y 3.
-----------------------
(...)
Luego se pasa un buen rato haciendo lo mismo. Mientras no pasa nada chequea los hoppers continuamente.Ya en el siguiente bloque de la foto encontramos, en la quinta linea algo nuevo.
05 00 01 F2 08
Para el hopper 5, sin datos, ordenado por la cpu (01), orden F2 (242decimal=PETICIÓN Nº DE SERIE), y checksum.
Cada hopper tiene un número de serie de fábrica. Este número será necesario saberlo para ordenar un pago de monedas.
01 03 05 00 6B 8F 12 EB
El hopper 5 contesta a la cpu con tres datos que forman el número de serie. El primer dato es el menos significativo, y el tercero el más. Así que el número de serie es: 128F6Bhexadecimal=1216363decimal
---------------------------
05 00 01 A6 54----------01 04 05 00 00 00 00 00 F6
Para hopper 5, sin datos, la cpu (01), ordena A6(166decimal=CONSULTA DEL ESTADO DEL HOPPER), y checksum.
Para la cpu(01), con 4 datos, el hopper 5, responde (00):
El primer dato serán los pagos hechos desde el último reset (del valor FFh=255d se pasa al 1, de manera que un 0 es que no se ha pagado nada desde un reset). El segundo dato será las monedas pendientes de pagar. El tercero, el número de monedas pagadas en el último pago (éste si estuviésemos pagando). Y el cuarto, el número de monedas pendientes de pagar en un pago anterior. La información se guarda en la EPROM del hopper aunque falle la alimentación. Podremos recuperar la información al reiniciar el pagador. Tras un reset los cuatro datos se ponen a cero. Este es nuestro caso aquí.
-------------------------------
05 01 01 A4 A5 B0----------01 00 05 00 FA
Para el hopper 05, se le da un dato, desde la cpu(01), la orden A4(164decimal=HABILITAR HOPPER), el dato es A5, y el checksum. El comando A4h(164d) se debe utilizar para habilitar el pagador antes de pagar monedas con cualquier orden de pago. Si el dato que se envía es A5h se habilita el hopper. Si es distinto de A5 el hopper estará deshabilitado.
La segunda secuencia es el hopper que contesta, a la cpu, que la orden ha sido realizada con éxito (00).
----------------------------------
05 04 01 A7 6B 8F 12 01 42----------01 00 05 00 FA
Para el hopper 5, cuatro datos, desde la cpu(01), la orden A7h(167d PAGAR MONEDAS CON HOPPER). De los cuatro datos, los tres primeros datos son el número de serie que nos facilitó el comando F2, y que son necesarios para construir esta orden A7 y que el hopper pague la cantidad de monedas que indica el cuarto dato. En este caso una moneda.
Si se puede hacer el pago el hopper devuelve una trama de aceptación como en este caso y comienza a efectuar el pago hasta que extraiga todas las monedas indicadas, se detecte un vano máximo, se reciba una orden de cancelación, se detecte un error, o haya un reset o fallo de alimentación.
Si no se puede pagar por un error, porque el hopper esté ocupado con otra orden, o el código (nºserie) no sea correcto, éste devolverá una trama de reconocimiento negativo.
-------------------------------------
03 00 01 EC 10----------01 01 03 00 00 FB
Vuelve a hacer lectura de optos del hopper 3, e indica hopper lleno.
-------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Después de ordenar el pago, se hace un seguimiento de este. Esta trama vuelve a pedir una A6h(166d CONSULTA DEL ESTADO DEL HOPPER). 01 pago ordenado desde el último reset (éste). 01 moneda pendiente de pagar. 00 monedas pagadas en este pago (así que no ha realizado todavía el pago ordenado) y 00 monedas pendientes de pagos anteriores.
Así que debe de estar pagando. Sigamos controlándolo.
--------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Seguimos como estábamos, pendiente de pagar una moneda el hopper 5.
---------------------------------------
04 00 01 A3 58----------01 01 04 00 80 7A
Se chequea el hopper 4 (A3h=163d=TEST HOPPER) y el hopper contesta. Pago deshabilitado.
---------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
Lectura del estad de optos (ECh=236d). Hopper 4 lleno de monedas.
---------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4 (dos veces)
Y seguimos pendientes del pago de una moneda del hopper 5.
--------------------------------------
03 00 01 EC 10----------01 01 03 00 00 FB
Lectura del estado de optos (ECh=236d). Hopper 3 lleno de monedas.
--------------------------------------
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
03 00 01 A3 59----------01 01 03 00 80 7B
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
04 00 01 EC 0F---------01 01 04 00 00 FA
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4 (dos veces)
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 EC 10----------01 01 03 00 00 FB
05 00 01 A6 54----------01 04 05 00 01 01 00 00 F4
Chequeando continuamente los hoppers sin novedades....
---------------------------------------
05 00 01 A6 54----------01 04 05 00 01 00 01 00 F4
Aquí hay un cambio en la respuesta. Los datos de respuesta del estado del hopper 5, que hasta ahora eran siempre 01 01 00 00, en este mensaje pasan a ser 01 00 01 00. Ya no hay monedas pendientes de pagar, y en el último pago se pagó una moneda. Por fin, el hopper 5 nos indica que ha pagado una moneda.
----------------------------------------
05 00 01 F2 08----------01 03 05 00 6B 8F 12 EB
La cpu vuelve a consultar el número de serie del hopper 5.
----------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
El hopper 4 sigue lleno.
----------------------------------------
05 01 01 A4 00 55----------01 00 05 10 FA
Se deshabilita el pago del hopper 5.
----------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A3 59----------01 01 03 00 80 7B
Más chequeos del estado de los hoppers.
-----------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
Consulta del número de serie del hopper 3. Este es 0E902Bh=954411d.
-----------------------------------------
03 00 01 A6 56----------01 04 03 00 00 00 00 00 F8
Consulta del estado del hopper 3. Sin pagos realizados ni pendientes desde el reset.
----------------------------------------
03 01 01 A4 A5 B2----------01 00 03 00 FC
Habilitar el hopper 3 para pagos.
-----------------------------------------
03 04 01 A7 2B 90 0E 01 87----------01 00 03 00 FC
Que el hopper 3 pague una moneda.
----------------------------------------
05 00 01 A3 57----------01 01 05 00 80 79
Y seguimos revisando fotocélulas del hopper 5.
----------------------------------------
03 00 01 A6 56-----------01 04 03 00 01 01 00 00 F6
Y también se sigue revisando como va el pago del hopper 3. Pendiente de pagar una moneda de una orden de pago.
----------------------------------------
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
04 00 01 A3 58----------01 01 04 00 80 7A
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6 (tres veces)
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
05 00 01 EC 0E----------01 01 05 00 00 F9
05 00 01 A3 57----------01 01 05 00 80 79
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6 (dos veces)
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 A6 56----------01 04 03 00 01 01 00 00 F6
04 00 01 EC 0F----------01 01 04 00 00 FA
03 00 01 A6 56----------01 04 03 00 01 00 01 00 F6
Hasta aquí ha estado chequeando continuamente los hoppers y el pago del hopper 3. Aquí, por fin, el hopper 3 confirma que ha pagado una moneda.
------------------------------------------------------------
03 00 01 f2 0A----------01 03 03 00 2B 90 0E 30
La cpu consulta el número de serie del hopper 3 que es 0E902Bh=954411d.
-------------------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A3 59----------01 01 03 00 00 FB
Vuelta a revisar el estado de los hoppers.
--------------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
03 00 01 A6 56----------01 04 03 00 01 00 01 00 F6
03 01 01 A4 A5 B2----------01 00 03 00 FC
03 04 01 A7 2B 90 0E 03 85----------01 00 03 00 FC
03 00 01 A6 56----------01 04 03 00 02 03 00 00 F3
Vuelve a habilitar el pago del hopper 3, pero esta vez (segundo pago) le manda pagar 3 monedas.
Obsérvese que parece seguir siempre el mismo procedimiento.
1º pedir el nºde serie del hopper F2
2º observar el estado del pago A6
3º habilitar el hopper para pagar A4
4º ordenar el pago A7
5º estar pendiente del pago A6
6º y cuando finalmente se ha pagado inhabilitar el hopper para el pago A4
---------------------------------------------
04 00 01 A3 58----------01 01 04 00 80 7A
03 00 01 A6 56----------01 04 03 00 02 03 00 00 F3
04 00 01 EC 0F----------01 01 04 00 00 FA
05 00 01 A3 57----------01 01 05 00 80 79
Se sigue revisando. Hasta aquí nada nuevo.
-----------------------------------------------
03 00 01 A6 56----------01 04 03 00 02 02 01 00 F3
Aquí cambia algo la cosa. Es el segundo pago. Ya solo tiene 2 monedas pendientes de pago, porque ha pagado 1 y no debe nada de ningún pago anterior. Vemos que el hopper está pagando.
---------------------------------------------
05 00 01 EC 0E----------01 01 05 00 00 F9
03 00 01 A6 56----------01 04 03 00 02 01 02 00 F3
En este segundo pago del hopper 3 ya ha pagado 2 monedas y queda 1 por pagar.
--------------------------------------------
03 00 01 A6 56----------01 04 03 00 02 01 02 00 F3
03 00 01 A6 56----------01 04 03 00 02 00 03 00 F3
Se han pagado las tres monedas y no quedan pendientes.
--------------------------------------------
03 00 01 F2 0A----------01 03 03 00 2B 90 0E 30
04 00 01 EC 0F----------01 01 04 00 00 FA
03 01 01 A4 00 57----------01 00 03 00 FC
Inhabilita el hopper 3 para pagos. Ya hemos acabado de pagar.
---------------------------------------------
Y desde aquí hasta el final ya se pasa todo el tiempo chequeando el estado de los hoppers. La máquina ya ha pagado una moneda del hopper 5 y cuatro del hopper 3 (en dos veces 1+3).
Todo corresponde con lo que me esperaba, salvo que no he encontrado el código de comunicación con el selector de monedas. Y ya he comentado, que he introducido una moneda de 2euros. Esto me ha extrañado, pero después de revisar el esquema eléctrico de la máquina, me he encontrado con que, no todos los dispositivos van unidos al mismo bus cctalk, como pensaba. Sino que, en esta máquina, el selector de monedas tiene su línea de comunicación cctalk propia con la cpu, los hoppers otra diferente y el lector de billetes también la suya propia, todas independientes. Para hacer el monitorizado de la comunicación yo he conectado a la linea de los hoppers, por eso únicamente aparece comunicación de pagos.
De todas formas me queda constatado que las cosas funcionan como yo había entendido, y aquí queda un rollo curioso para el que le interese el asunto.
He revisado un par de veces lo que escrito. Esta entrada es un poco densa y espero no haber metido la pata. Pero como siempre, ya sabéis que no os debéis fiar a ciegas. Aunque trato de ser exacto, muchas veces cometo errores, como todo el mundo. Mi afán en este blog es aprender yo mismo. Así que si detectáis algún fallo, o algo importante que aportar, me encantarían comentarios o emails.
Saludos.
(CONTINÚA CON:Otra entrada sobre trama cctalk de un selector de monedas)
Podrías publicar la trama del selector de monedas?
ResponderEliminarAunque la cosa haya quedado un poco "chapuzera", toda la presentación, análisis y exposición de resultados, me ha dado bastante que hacer.
EliminarEn principio, ya expliqué que yo me esperaba un bus cctalk único, y que estuvisen todas las comunicaciones de todos los dispositivos con la cpu. Después de analizar para publicar en el blog, he caído en la cuenta que aquí solo comunica con los hoppers y que para el comunicado con el selector de monedas hay otro bus. El de esta máquina en concreto no lo tengo.
En su momento he capturado alguna trama más de otras máquinas pero siempre conectando al cable del hopper (había hecho un conector a propósito). Puede que otra máquina tenga un bus cctalk único y por lo tanto esté todo mezclado, pero no me he puesto a analizar más tramas. Con esta, he satisfecho mi curiosidad por el momento. Si estás muy interesado, podría pasarte alguna foto en bruto. Tú te buscas la vida. Y no puedo asegurarte que haya del selector de monedas. Pero no las voy a publicar aquí sin saber lo que publico. Con todo mi email es público, ponte en contacto con uno tuyo, contándome el porqué de tu interés y lo hablamos de forma privada.
Saludos.
Amigo, Excelentes articulos!!! he buscado en internet y no he encontrado mucha información al respecto, ahora me doy una idea mas clara del funcionamiento.
ResponderEliminarEnhorabuena, y gracias por tomarte el tiempo de compartir el conocimiento
Al final he añadido otra trama sobre un selector de monedas. Buscad en:
ResponderEliminarhttp://electronicaychapuzas.blogspot.com.es/2013/04/analisis-de-trama-de-comunicion-cctalk.html
Muchas gracias por tus aportes, son oro puro, saludos
ResponderEliminar