Daniel Simoes

A chamada ao Imprimir() pode ficar fora do Loop, se o mesmo não tiver um buffer muito grande... Ou então você usa um Contador dentro do Loop, e imprime a cada múltiplo de 20 (por exemplo) Sobre a lentidão, experimente efetuar um reset no equipamento...

Usando modo Texto é bem diferente... PPLA e PPLB tem métricas próprias e unidades de medida diferente em alguns casos (pixel, mm, etc) O ACBrETQ tenta abstrair a diferença entre os modelos... mas dificilmente o mesmo código servirá para ambos... mesmo a orientação da etiqueta muda para cada protocolo... Nessa pasta, há alguns manuais que podem explicar como calcular o posicionamento dos textos... https://svn.code.sf.net/p/acbr/code/tools/Argox/ Usando o Demo e tentativa e erro também é possível intuir como funciona...

Na verdade a resposta é SIM... Ele emula a memória de um ECF, usando um arquivo .INI

A própria impressora faz o retorno da etiqueta após o avanço... Se isso não estiver ocorrendo, faça um reset na Impressora

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)