Bematech MP-4200 th fi entrando em loop

[Daniel Simoes]

Me enganei, confundi com a MP4000... A MP4200,  realmente não tem porta serial...

[Rodrigo de Carvalho Ribeir]

Boa tarde 

Depois alguns teste...Verifiquei o problema de loop sempre dava  no comando 26..

Ai  eu fiz uma modificação no fonte do ACBRECFEscECF.pas

Criei uma variável para armazenar hora de inicio do comando.. depois antes de enviar o comando no evento EnviaComando_ECF eu peguei a hora..

Não compreendi muito bem a sua lógica... Como isso irá trazer a resposta esperada, ao comando enviado ao ECF ?

Então como eu falei o loop acontece sempre no comando 26 que serve para Captura Eletrônica de Dados...

percebi q na impressora bematech ... as vezes com esse comando  a impressora fica respondendo em processamento

Status TX -> [ENQ][NUL]
                RX <- [WAK][NUL][SOH][NUL][NUL][NUL]

Ai que eu fiz ... determinei um tempo para que componente espere essa resposta ... caso tempo seja atingido ele pede comado 26 outra vez....

percebi que segunda chamado do comando ai impressora responde corretamente... porque na verdade ela não esta em processamento.

isso algum bug do ecf... isso tem tando na bematech mp-4200th fi e bematech mp-4200th fi II...

não sei. se minha logica esta escrita na melhora maneira... mais deu certo aqui para min não to tendo mais problema nos cliente...

outra coisa que ta acontecendo com meus cliente é o  bematech mp-4200th fi morrer .. ai tem mandar para fabrica... pq nem autorizada consegue arrumar... ai fabrica manda um ecf novo no modelo bematech mp-4200th fi II.   isso ja aconteceu com 4 clientes meus, incluível com minha ecf de teste aqui.

 

 

[Daniel Simoes]

Compreendi o seguinte:

• Se o comando enviado iniciar com 26 (Leitura de informações da Impressora)
• Você aguarda até o TimeOut, pela resposta do Pedido de Status...
• Se nesse momento, o ECF continuar retornando a resposta de Ocupado, você envia novamente ao ECF, o último comando enviado...

Está correto ?

 

Novos drivers da Bematech

Em conversa com André Munhoz, da Bematech, recebi dele autorização para posta os novos Drivers de USB para criação de COM virtual...

A grande vantagem dessa nova versão, é programa BemaGhost, que permite remover todos os Drivers antigos da Bematech, o que pode resolver vários problemas..

Os Drivers estão disponíveis para Download aqui no fórum:

 

 

[Rodrigo de Carvalho Ribeir]

Isso mesmo

[Daniel Simoes]

Vamos aguardar um feedback dos novos drivers...

Se o problema persistir, tentamos esse workaround

[jonasrockenbach]

Executei dezenas de testes melhorou bastante, peguei a  impressora e a maquina do cliente primeiro emiti cupons com o driver antigo como era esperado os travamentos ocorrem constantemente, atualizei o driver e meu sistema começou a se comportar diferente e consegui achar uma logica para os travamento do meu sistema, tenho que esperar a impressora terminar um comando para enviar outro, por exemplo quando vou vender o primeiro item do cupom mando o comando de abertura do cupom e o comando para inserir item de venda, tenho que esperar a impressora imprimir para enviar um novo comando caso contrario retorna exceção e tenho que fechar a aplicação e abrir novamente, mesma coisa na subtotalização e fechamento se pressiono rapidamente a tecla enter disparando os dois comandos gera a exceção.

Pode ser falha do meu sistema ainda não consegui achar a solução, na MP 4000 não ocorre isso, pode ser pelo fato de usar o modelo Bematech e na na 4200 o modelo ecfEscECF  

Alguém tem uma sugestão de como posso tratar esse erro ?

Tirei os Try Except do meu comando e aparece o erro da imagem anexa

Editado 29 Setembro, 2015 por jonasrockenbach

[Juliomar Marchetti]

Sim .. conforme já tem em posts explicando o componente ACBrECF não funciona igual dll de fabricante que prende pra ela o processo até terminar!

então tu tem que enviar o comando e aguardar para só depois enviar o próximo senão vai ocorrer o problema!

olhe no ECFTeste na pasta de exemplos

[jonasrockenbach]

Sim .. conforme já tem em posts explicando o componente ACBrECF não funciona igual dll de fabricante que prende pra ela o processo até terminar!

então tu tem que enviar o comando e aguardar para só depois enviar o próximo senão vai ocorrer o problema!

olhe no ECFTeste na pasta de exemplos

Obrigado pela dica Juliomar, vou trabalhar nisso, só estranho isso ocorrer somente com este modelo, é o mesmo sistema que rodo nas MP 4000 th fi e não ocorre problema.

[Daniel Simoes]

Para obter um "congelamento" do sistema, algo semelhante ao que ocorre quando o controle do programa está com a DLL... Use:

  ACBrECF1.Device.ProcessMessages := False;

 

[jonasrockenbach]

Para obter um "congelamento" do sistema, algo semelhante ao que ocorre quando o controle do programa está com a DLL... Use:

  ACBrECF1.Device.ProcessMessages := False;

 

Obrigado Daniel Simoes realmente resolveu meu problema.

[Alcione Lofy]

Vamos aguardar um feedback dos novos drivers...

Se o problema persistir, tentamos esse workaround

Realizei  testes em 3 clientes e paralelo...com sistemas operacionais diferentes... windows xp, windows 7 e windows 10..... os resultados foram os seguintes:

no xp e no sete nada mudou parece que nem mudei o driver.. o problema continua com a mesma frequencia. No windows 10 chegou a trabalhar uma noite inteira, inclusive eu achei que "estava resolvido nesse sistema operacional" porem o problema voltou a ocorrer e com a mesma frequencia que ocorria antes, sempre que visualizo os logs consigo verificar que esta retornando "ocupado" , e sempre ocorre no retorno, pois a impressora fiscal faz o que foi "solicitado", independente do comando.

Status TX -> [ENQ][NUL]
          RX <- [WAK][NUL][SOH][NUL][NUL][NUL]

 

[giulianon]

Mesma coisa comigo.

Coloquei hoje pela manhã o sistema a funcionar conforme o recomendado (USB 2.0, Sleep(200) e driver novo), e acabei de receber uma ligação do cliente informando que travou do nada, no meio de um relatório gerencial.

Complicado!

Att.

 

[Daniel Simoes]

Tentou o novo driver ?
 

 

[giulianon]

Tentou o novo driver ?
 

 

Sim Daniel!

Foi foi exatamente com esse driver que você tinha informado que o pessoal da Bematech te passou.

Att.

 

[robatistello]

Foi instalado o novo driver em nossos clientes e o problema continua...  

 

Editado 1 Outubro, 2015 por robatistello

[Alcione Lofy]

Tentou o novo driver ?
 

 

Sim com o novo driver 

[Ryan molina]

Também atualizamos com o novo driver, mas o problema persiste. Já verificamos questão de postas USB 2.0, troca de cabos, sleep. Mas nada gerou alguma mudança significativa nos clientes.

Temos um ECF 4200 de desenvolvimento aqui e acontece também, testamos em alguns computadores diferentes.

Tentamos contato com a Bematech via Skype, porém não dão muita atenção para o problema.

Se alguém conseguir alguma evolução, por favor, compartilhem.

 

Editado 1 Outubro, 2015 por Ryan molina

[Daniel Simoes]

Como reproduzir o problema na máquina de Desenvolvimento, usando o ECFTeste ?

[jonasrockenbach]

Esperei o sistema rodar por dois dias em um cliente, um mercadadinho com movimentação constante antes de postar para ter certeza que havia solucionado o problema, realizei todos os procedimentos USB 2.0, atualizei driver e continuava travando, simplesmente a impressora entrava em Loop respondendo que estava ocupada, a unica coisa que resolveu foi baixar a Unit ecfEscECF do Rodrigo de Carvalho Ribeiro que esta na primeira pagina deste tópico e compilar utilizando esta Unit.

Peguei hoje o log da impressora e notei que havia entrado em Loop varias vezes mas graças a modificação do Rodrigo o sistema depois de 3 segundos se recupera e volta a funcionar, deve existir um problema de projeto o detalhe é que comprei este modelo de impressora logo que foi lançado e a minha nunca deu problema funciona perfeitamente.

Existe um outro problema que ainda não consegui resolver que é o de enviar dois comandos seguidos, analisei meu sistema e ele faz o controle para saber se um comando foi concluído para enviar outro, mas por algum motivo a impressora não responde corretamente e o sistema permite enviar dois comandos em sequencia e travar a aplicação. Isso tem ocorrido quando os usuários decoram o código dos produtos e teclam enter rapidamente, esse problema resolvi setando ACBrECF1.Device.ProcessMessages := False porem o sistema ficou lento e agora a reclamação é a lentidão, mas pelo menos o cliente consegue trabalhar antes não havia maneira de trabalhar;

 

 

 

[Daniel Simoes]

Vou aplicar um workaround para o problema...

procure no fórum, por um tópico chamado "venda frenética". Lá há dicas de uma implementação correta, usando um mecanismo de filas 

[Ryan molina]

Bom dia pessoal,

Consegui mais alguns detalhes referente a este problema. Vejam o anexo, ele foi gerado através do software da Bematech WinITFI2 RAT.

Aparentemente alguns comandos ficam em "loop" pois o ECF está ocupado. O software aparentemente trata o problema e fica tentando enviar o comando até que seja liberado o ECF. Acredito que isso vá de encontro a solução proposta pelo Rodrigo de Carvalho Ribeiro.

Estamos compilando um ACBrMonitor com a alteração proposta pelo Rodrigo e vamos colocar pra testar agora de manhã.

logBematech.txt

Editado 2 Outubro, 2015 por Ryan molina

[Daniel Simoes]

Apliquei no SVN, modificações baseadas na sugestão do Rodrigo...

 Quando ocorrer a situação de Loop infinito, a rotina deverá gravar no Log algo como:

*** Bematech em possível loop: 999 respostas de Ocupada. Reenviando o último comando

 Por favor atualizem os fontes, e testem...

[Eduardo Merico]

Daniel, estive no cliente na sexta e aplicamos as modificações liberadas na sexta mesmo.

Desde sexta a tarde até o momento, está estabilizado, não houve mais erros com o ECF. Irei aplicar estas modificações também em outros clientes para termos mais indícios que as modificações surtiram efeito e o problema, que no meu entender, é do ECF da Bematech ou do Driver deles tenha sido contornado.

[Daniel Simoes]

Obrigado pelo Retorno...

Poderia me trazer um Log de um desses clientes onde a Correção foi aplicada ?

Eu gostaria de passar mais informações para a Bametech, sobre  o problema... para que o mesmo seja corrigido na próxima versão do Sw.Básico desse ECF...

[Ryan molina]

Apenas complementando a resposta do Eduardo, segue anexo o log gerado no cliente.

O "loop" ainda existe mas não afeta mais a comunicação a princípio. 

acbrlog.txt