Daniel Simoes

Acho que isso depende exclusivente da DLL... O código fica preso na execução do método da DLL...

Faltou exibir a diferença entre cada medição... Mas ao que parece, o ACBr está mais rápido que a DLL Lembro que a Bematech comentou que esse ECF é mais lento, devido a criptografia necessária...

Ao que parece o ACBr foi muito mais rápido para abrir o cupom... mas mais lento para cancelá-lo... Poderia fazer uma repetição de 3 medições ?

A Sweda, quando criou a nova série de ECFs com MFD, criou um novo protocolo, muito mais otimizado (STX)... mas manteve a compatibilidade com o protocolo anterior (ESC PONTO)... Ou seja, os ECFs com MFD suportam 2 protocolos diferentes... os antigos matricias apenas o (ESC .)

Não há o que fazer via código... O ACBrECF está interrogando o estado do ECF, que está respondendo como "ocupado, trabalhando" [WAK] No comando abaixo, para uma simples leitura do "NumSerie", isso ocorreu 4 vezes...

Você pode chamar novamente ACBrECF.CarregaFormasPagamento, para garantir que todas elas estejam na memória do componente...

A comunicação é realmente bem mais lenta... Mas acho que não chega a tanto... Deixe "IntervaloAposComando" em 0 Reportei isso a Bematech... Veja esse Post: (item 7)

Humm.. acho que precisamos investigar melhor... Creio que toda correção deve ter uma explicação lógica... caso contrário o problema ainda poderá estar oculto... A única coisa que realmente notei nas suas modificações, que poderiam modificar (para melhor) é o fato de apagar o arquivo destino antes de iniciar a geração... Talvez por segurança, a DLL não sobreponha o arquivo quando o mesmo já existe...

Parece que MS tb vai aderir... Veja esse link da AFRAC http://emkt.afrac.org.br/emkt/tracer/?1,1998834,fa7cc83d,7e14

O que vc diz que não funciona ? O Cancelar não cancela ? Todas as demais perguntas são disparadas pelo próprio SiTef... veja os Logs

Provavelmente isso ocorre por se tratar de um emulador... O componente ACBrTEFD não têm nenhum controle sobre a geração desse texto, que vem direto do Gerenciador TEF O correto seria consultar o suporte da Daruma

ACBrTEFD1.BloquearMouseTeclado( True ) ; // bloqueia ACBrTEFD1.BloquearMouseTeclado( False ) ; // desbloqueia

Não entendi a necessidade da correção... Você está chamando o mesmo comando, porém usando um arquivo temporário... ( e este nome não possui barras duplas como mencionado nesse post) Qual era o problema, e como essas alterações podem corrigi-lo ??

Ainda não tive notícias... Não sei se algum estado (UF) já está permitindo o uso delas... Se você vai precisar.. é bom iniciar os testes... use o emulador da Bematech MP4200

Tive um retorno semelhante... usando o ACBrMonitor e o Emulador da Sweda: Pode ser que o problema seja na porta serial ou cabo... Experimente baixar a velocidade do Buffer da Serial: Outra teoria.... você faz uma chamada a: ECF.CarregaFormasPagamento, no inicio da sua aplicação ? Isso é importante para carregar a tabela de Formas de Pagamento na memória do componente

use o modelo ecfSwedaSTX

Use o ECFTeste

Isso é de controle da sua aplicação.... insira uma condição...

Para evitar esse problema, você precisa imprimir as formas de pagamento de Menor valor em primeiro...

Nessa caso SIM... precisa ser CODE128... Não usamos a DLL, mas sim comados ESC P/2, para imprimir o Cod.Barras (em apenas uma linha)... Talvez possa ajudar... https://svn.code.sf.net/p/acbr/code/trunk/Fontes/ACBrSAT/ACBrSATExtratoESCPOS.pas Procure por: "GerarRodape" Talvez você tenha que ajustar para menor a largura das barras...

Se for só números, e uma sequencia par de caracteres, você pode tentar o <Code93> (ficará bem menor)

Isso irá criar uma String de 33 zeros.... ou o mesmo que StringOfChar('0',33) @Juliana, poderia avaliar o manual enviado ?

Você deve nos enviar o manual onde consta essa mudança, para analise...

Por favor abra um novo tópico para uma nova dúvida... Se você usar um ACBrMonitor para cada terminal (local) não terá compartilhamento de informações... e portanto, não haveria problemas... Se você precisa que todos os terminais acessem simultaneamente o mesmo "Monitor"... cabe a sua aplicação ter um controle de acesso ou semáforo... Veja: por TXT ou TCP, ele irá responder a todos os terminais... Porém por TXT, você poderia ter a situação de um terminal estar apagando (ou sobrepondo) o arquivo do outro... Por TCP/IP, não há colisão, (pois cada sessão abre uma nova Thread).... mas no final, todas elas vão alterar o mesmo objeto de memória... e portanto, poderá sim haver perda de informações...

Você deve informar o Indice da Forma de Pagamento de maneira idêntica a retornada em "ACBrECF1.CarregaFormasPagamento"