Daniel Simoes

Qual a msg de erro ? Adicione o Log

Se vc apenas instalou o com0com, precisa modificar os nomes das portas... por default o com0com cria com nomes: CNCA0 e CNCB0, use o próprio utilitário do com0com para modificar os nomes (setup.exe) As portas do com0com devem aparecer no gerenciador de dispositivos do Windows

Qual é o modelo e versão do ECF ? Por favor anexe o log...

O Cielo Premia pode retornar, descontos... O Saque da Visa irá alterar o Valor Total da Transação TEF (forçando um Troco)... O Troco de dezlão de SC é diferente de ambos

Uma ideia... Como você designa o endereço TCP ? Por numero de IP (192.168.0.1) ou por Nome (servidortal.com.br) ... Se for por nome, a lentidão pode estar no DNS

Uma suspeita pode ser a pinagem do Cabo... A Sweda usa DTR/DSR e não RTS/CTS... e isso exige uma pinagem própria... Já vi casos de alguns adaptadores USB não contemplarem DTR/DSR...] Lembrei de outro caso, em que o ECF Sweda com STX só funcionou após o handshake ser modificado para ACBrECF1.Device.HandShake = hsRTS_CTS Lembre-se de atualizar seus fontes... pois foi feita uma modificação recente na Classe da SwedaSTX, pois ela sempre tentava usar DTR/DSR, ignorando o Handshake anteriormente ajustado...

Vc criou um par de portas virtuais, certo ? Então se o Emulador está na COM2 o ACBrECF deve ser ligado na outra porta do Par... A COM2 está sendo usada pelo Emulador

A COM2 está ocupada por outro processo... a busca deve estar encontrando o ECF em outra porta diferente da COM2

Apenas ajuste um valor diferente de 0 para a propriedade... o TEFD permitirá transações que retornem Troco até esse limite... Isso visa atender a última aberração de lei do PAF-ECF imposta por SC (troco de R$ 10,00) para vendas em cartão

A leitura das informações da Z é demorada... pois há muita comunicação com o ECF... Isole o problema... Se você quer saber se o ACBrECF está lento para se comunicar com o ECF, use o ECFTeste, diretamente com a serial do ECF.. A analise do LOG gerado pelo ACBrECF vai lhe dar mais detalhes sobre o tempo de processamento do ACBrECF

Apliquei uma possível correção... favor verificar... (necessita reinstalar o Package ACBrSerial)

Reproduzi o problema... analisando solução...

O problema seria nos fontes do ACBrECFDaruma.pas ... Tente atualiazar apenas os fontes do ACBrECF

O ACBrInstall não é compatível com o Lazarus... As instruções para instalação do ACBr no Lazarus estão no arquivo LEIA-ME.TXT (item 5)

Humm.. na classe da Daruma tem um mecanismo de Buffer, que aproveita a resposta do comando... Exemplo, ao vender o Item, o comando de Venda de Item retorna o SubTotal, e o ACBrECF faz uso desse retorno para evitar uma leitura desnecessária ao ECF... Lembro de haver problemas com o "descarte" do buffer a muito tempo atrás... mas isso já foi reportado e corrigido nos fontes... Seus fontes do ACBr estão atualizados para a última versão ??

Analise o LOG, aparentemente essa mensagem é retornada pelo G.P.

Você poderia verificar a existência do .EXE do Gerenciador

O log do ACBrMonitor não ajudou muito, pois não tem data/hora A ideia é montar um laboratório de testes, para testar o dempenho de sua rotina, em localhost Com um PING vc poderia medir a velocidade da rede...

Você NÃO deve ajustar quais TEFs serão ativados via ObjectInspector... Isso deve ser definido em tempo de execução, após alguma rotina de leitura de parâmetros da sua aplicação (um .INI por exemplo)

Tente com o Demo ECFTeste... compile-o e teste nos seus Delphis... Se não for capaz de reproduzir o problema então está no seu código... Se o erro ocorrer no Demo, informe em detalhes o passo a passo sobre como reproduzir o erro... Para ativar o Log ajuste a propriedade: ACBrECF.ArqLog

Por favor estude detalhadamente o Demo ECFTeste... Tudo relacionado ao ACBrECF está lá.. ACBrECF1.IdentificaOperador( Operador );

Sim, eu utilizo essa lógica... COOInicial = COO da Ultima Red.Z + 1

Tente em Localhost (127.0.0.1)... Se ficar rápido (TCP é extremamente rápido em Localhost), então não há problema na sua rotina... Se a lentidão persistir provavelmente o problema é na sua rotina... A Analise do LOG do ACBrMonitor pode prover mais informações

O ACBrETQ só funciona se o sensor de GAP estiver ativado

Use as 2 DLLs do OpenSSL na pasta do ACBr\DLLs Se necessário copie-as para o diretório do Delphi