Erro ao enviar a imagem QRCode para o PIN PAD utilizando o componente ACBrAbecsPinPad

[WINDEL]

Estou utilizando o componente ACBrAbecsPinPad para enviar a imagem do QRCode para o PIN PAD. Notei que esse erro ocorre aleatoriamente, em alguns momentos funciona o envio da imagem sem erros e em outras causas o erro aparece. 

O erro ocorre quando aciono o comando "ACBrAbecsPinPad1.DSI" para enviar imagem ao PIN PAD. Para simular o erro segui os seguintes passos utilizando o aplicativo demo PinPadTest.

- Abrir o aplicativo e clicar no botão "Activate"

- Ir na aba Multimedia e clicar no botão "Send To PinPad".

A imagem aparecerá no visor do Pin Pad, porém ocorrerá um erro de timeout e isso impossibilita a execução dos próximos comandos. 

Estou utilizando para testes o PIN PAD PPC-930 versão 2.12 e estou com os drivers do fabricante instalados e atualizados.

Pode fazer alguns testes com esse equipamento?

LogArqPinPad.txt

[Juliana Tamizou]

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

[Daniel Simoes]

Eu não consegui reproduzir erros de TimeOut, com nosso PinPad PPC930

Que valor está na sua propriedade TACBrAbecsPinPad.TimeOut ?

A última chamada a DSI, parece ter ocorrido com sucesso...

Citar

-- 08/02 09:33:08:990 - DSI( QRCODE01 )
-- 08/02 09:33:08:991 - ExecCommand: DSI
-- 08/02 09:33:08:992 -   Command, Blocks: 1
-- 08/02 09:33:08:994 -     Block: 1, Size: 12, Data: \x00\x1E\x00\x08QRCODE01
-- 08/02 09:33:08:995 -       SPE_MFNAME, Size: 8, Data: QRCODE01
-- 08/02 09:33:08:997 -   SendCommand: DSI, BlockStart: 0
-- 08/02 09:33:08:999 -     DataPacket, 18 Bytes, 1 Blocks
-- 08/02 09:33:09:001 -   TX -> \x16DSI012\x00\x1E\x00\x08QRCODE01\x17e_
-- 08/02 09:33:09:001 -     WaitForACK
-- 08/02 09:33:09:005 -     RX <- 6
-- 08/02 09:33:09:007 -   WaitForResponse
-- 08/02 09:33:09:008 -   WaitForSYN
-- 08/02 09:33:10:928 -     RX <- 22
-- 08/02 09:33:10:930 -   SYN received
-- 08/02 09:33:10:931 -   WaitForDataPacket
-- 08/02 09:33:10:933 -   DataPacket: DSI000
-- 08/02 09:33:10:934 -     ReadCRC
-- 08/02 09:33:10:935 -     CRC: \x95E
-- 08/02 09:33:10:936 -   Response.STAT: 0
-- 08/02 09:33:10:938 -   Response, Blocks: 0
-- 08/02 09:33:10:939 -   EvaluateResponse: 0

Qual Linha do Log, você notou o Timeout ?

[WINDEL]

Estou utilizando o padrão TACBrAbecsPinPad.TimeOut = 10000. Vou aumentar para 20000 para verificar se pode ser esse o problema.

Sei que para nesse momento porque no debug interrompe no comando " FACBrAbecsPinPad.DSI('QRCODPIX')" e capturo as seguintes mensagens de exceção (imagens em anexo).

Estou constantemente usando esses comandos para ir enviando múltiplas vezes o QRCode.

FACBrAbecsPinPad.LoadMedia('QRCODPIX', ms, mtPNG);

FACBrAbecsPinPad.DSI('QRCODPIX');

Não preciso excluir a imagem antes de enviar novamente? Posso simplesmente sempre enviar direto o DSI pro pinpad?
 

[Daniel Simoes]

1 minuto atrás, WINDEL disse:

Não preciso excluir a imagem antes de enviar novamente? Posso simplesmente sempre enviar direto o DSI pro pinpad?

não precisa excluir, ele sobrepõem...

Consegue criar um "mini-demo", que eu possa usar para simular o problema ?

[WINDEL]

Sim, eu consegui simular com o Demo Pin Pad Test mesmo realizando os seguintes passos

- Abrir o Aplicativo Teste ABECS Pin Pad
- Clicar no Botão "Ativar"
- Ir na Aba Multimedia e clicar no botão "Send to PinPad"
- Ir na Aba Display e clicar no botão "Clear Display".
- Voltar para a Aba Config e clicar no botão "Desativar"
- Fechar a aplicação

Repetir algumas vezes esse processo em modo debug para poder verificar a exceção levantada.

[Daniel Simoes]

Olá @WINDEL,

Eu não consegui reproduzir o problema no meu PinPad Gertec PPC930

Você pode anexar o Log desse último teste ?

[WINDEL]

Segue em anexo o vídeo e log. É necessário rodar em modo debug para visualizar a exceção levantada.

Como o tamanho máximo para upload é de 2mb, compartilhei o vídeo no google drive. Segue o link para verificar o vídeo de simulação

Vídeo: https://drive.google.com/file/d/1FWKW7mR4eHvlVqSEtm28QZDNJtPVNqiu/view?usp=sharing

Log.txt

[WINDEL]

Quero apenas reforçar que para ver a exceção ocorrendo, é necessário rodar em modo debug, conforme o vídeo demonstra. Inclusive no memo foi logado que ocorreu a exceção.

Pode ser que se rodar em modo normal sem ser por debug, a exceção não ocorra, mas porque ela esteja sendo mascarada.

Meu receio quanto a isso é se depois de muitas vezes que rode o processo, o programa ir acumulando exceções mascaradas e assim possa acontecer de estourar e a aplicação se fechar sozinha devido a esse motivo.

[Daniel Simoes]

Olá @WINDEL,

Desculpe a demora na resposta...

Em 12/02/2024 at 10:31, WINDEL disse:

Como o tamanho máximo para upload é de 2mb, compartilhei o vídeo no google drive. Segue o link para verificar o vídeo de simulação

Pode por favor, pressionar Break nesse momento do Timeout, e enviar Print da tela no momento em que a IDE parou ?

Eu creio que seja um Exception controlado... A rotina do ABECS já preconiza tentar ler o ACK por até 3 vezes, em até 2 segundos.. eu acho que esses exceptions são tratados pelo código abaixo

procedure TACBrAbecsPinPad.ExecCommand(DoEvaluateResponse: Boolean); 
....
      // Send Data and Wait for ACK
      while (AckByte <> ACK) do
      begin
        BlockStart := max(BlockStart, 0);
        SendCommand(BlockStart, BlocksRead);
        AckByte := WaitForACK;

        if (AckByte = NAK) then
        begin
          Inc(ACKFails);
          if (ACKFails >= MAX_ACK_TRIES) then
            DoException(CERR_READING_ACK);
        end
        else if (AckByte <> ACK) then
          DoException(CERR_READING_ACK);
      end;  

 

 

[WINDEL]

Segue as imagens das exceções que ocorrem. No memo está logando essa exceção como EACBrAbecsPinPadTimeout: Timeout reading Response

Essas exceções "controladas" não podem resultar em algum crash se forem disparadas muitas vezes?

[Daniel Simoes]

@WINDEL, obrigado pelas telas...

Analisando o seu CallStack, notei que os Exceptions ocorriam dentro de WaitForSYN... na verdade eram Exceptions controlados.. ou seja, bastava ignorar...

Entretanto apliquei modificações nos fontes, que devem ficar mais claro, e sem a necessidade do Exception controlado.. Commit [r32492]

Citar

- melhoria em TACBrAbecsPinPad.SetIsEnabled , para limpar variáveis de Cache

- Ajuste em TACBrAbecsPinPad.ExecCommand para logar falhas no ACK
- Ajustes em TACBrAbecsPinPad.WaitForResponse,
- não levantar Exception de Timeout quando estiver aguardando SYN,
- Gravar bi log o "Time Left"
- Melhoria em TACBrAbecsPinPad.CancelWaiting, para não verificar desnecessariamente

 

PS: Também atualizei os Demos, com um botão interessante, para tentar Detectar a presença do PinPad

[Daniel Simoes]

2 horas atrás, WINDEL disse:

@WINDEL, nesse caso aqui.. parece que o próprio componente disparou o Exception..

Isso ocorre porque o TimeOut definido no componente foi atingido.. acho que você deixou o valor dele muito baixo.. (o default é 10000)

[WINDEL]

Sim, por isso que estou achando estranho essas exceções que estão sendo geradas. No caso configurei o timeout para o dobro do default. Tentei colocar o valor de 20000 (dobro) e mesmo assim está ocorrendo isso.

[Daniel Simoes]

por favor também atualize os fontes...

a versão atual, está logando o quanto falta para o TimeOut

 

[WINDEL]

Baixei os fontes, instalei novamente e com alguns testes que fiz rodando em modo Debug não ocorreu mais aquela exceção do componente. 

Foi realizado algum ajuste para tratar a exceção? Continuo usando o timeout de 20000

 

[Daniel Simoes]

A Exceção era prevista no código anterior.. tratava-se de um try/except controlado...

O Exception nunca ocorreria em produção, mas em Debug seria necessário marca a IDE para ignorar aquele tipo de exception...

Eu refatorei o código, removendo o fluxo por Exception