Tiago Tarifa Munhoz

@Ricardo Timm Bonsembiante Me parece ser alguma configuração de página de código. Além do teste do Daniel, que é importante fazê-lo, emita também uma página de teste. Se não me engano, nela informa qual a página de código está configurada na impressora. Em algumas impressoras, há também a opção de habilitar/desabilitar caracteres chineses (mandarim) independente da página de código configurada. Não lembro se é o caso da drm-380. Para verificar e alterar essas configurações, normalmente usa-se o "Tool" do fabricante. Ele está disponível neste link: http://desenvolvedoresdaru

@licerio e @William F. L. Os drivers estão sim no portal da Bematech. Só estão um pouco "escondidos". Acesse o link: http://bematechpartners.com.br/portalPartners/index.php/impressoras-termicas-windows/ Clique em Utilitários: Os drivers aparecerão:

Essa impressora usa o ESC/Pos Epson. Creio que o comando seja este: ESC p #1 50 100 onde: #1: é o valor decimal 1 da tabela ASC 50: Valor em milissegundos x2 que mantém a chave da gaveta ligada (eu acho) 100: Valor em milissegundos x2 que mantém a chave da gaveta desligada (eu acho) A referência do manual é esta: O comando ESC/Pos, nos fontes, para abrir a gaveta, está na linha 552 do arquivo ACBrEscPosEpson.pas localizado em 'Fontes\ACBrSerial' Espero ter ajudado.

Resumindo: O problema não está no ACBrUtil, aparenta ser a aplicação mesmo. De qualquer forma, obrigado. Explicando: Eu suspeitava que por não haver uma saída padrão(stdout) e para erros (stderr), o componente ACBrUtil ficava "travado" aguardando alguma "saída padrão". Porém, eu estava enganado. No Xorg + LXDE exite sim uma saída padrão, fica em: /home/usuário/.cache/lxsession/LXDE/run.log. Neste mesmo lugar encontrei a saída de erro citada no meu primeiro comentário. Maiores detalhes neste link: https://unix.stackexchange.com/questions/86698/where-does-the-output-from-an-app

Estou trabalhando em um caso, em um programa interno da empresa, que trava ao ser chamado diretamente pelo ícone do ambiente gráfico (Xorg+LXDE) se o SAT estiver desligado e/ou desconectado. Ainda com o SAT desligado, se executado pelo terminal ou pelo próprio Lazarus, o programa abre normalmente. Investigando, descobri que ao carregar a biblioteca do SAT, neste caso o da Elgin (libsatprotocolELGIN64bits.so), ela gera uma saída de erro, mas que aparentemente não atrapalha a sua execução. A saída de erro é esta: ou pelo terminal: Suspeito que, quando nosso programa é executa

@Andremomb, no windows 10 habilite a opção SMB 1.0 CIFS Client e desabilite Remoção Automática do SMB 1.0/CIFS. No seu Windows 10, o servidor de compartilhamento está usando o CIFS 1.0, mas o cliente não. É o cliente que fará o acesso no Windows 7. Também desative o firewall e antivírus para verificar se funciona. Obs.: Talvez eu não te responda por esses dias. O motivo é que estou de férias. Tanto que estou lhe respondendo no computador da minha cunhada, aproveitando e fazendo um teste nele. Ela mora em Ubatuba, à uns 800 metros da praia. Rá! Eu ia colocar um GIF animado,

Introdução: Recebemos gentilmente da Epson, a impressora não fiscal TM-T88V, para testes, utilizando os exemplos do ACBr: PosPrinterTeste.exe e SATTeste.exe. Computador Desktop Sistema Operacional Windows 10 64Bit atualizado (12/02/2018) Processador Intel Core 2 Duo E4500 2.20GHz Memória 2 GB USB 2.0 Impressora TM-T88V Protocolo

Olá @Andremomb Vi sua mensagem, enviada no particular pelo fórum. Vou tentar respondê-la aqui, pois pode ser a dúvida de outras pessoas também. Lembrando que meu sistema operacional principal é o Linux (Gentoo). Não uso o Windows, como sistema operacional principal, desde o Windows XP. Você tentou mudar as configurações de compartilhamento avançada? Tente deixar o mais "promiscuo" possível, liberando todas opções: Talvez essa opções, principalmente a circulada em vermelho, te ajude. Obs.: Lembrei também que o Windows 10, desabilita por padrão, o protocolo SMB1 (SMB

Estamos, em conjunto com a Control iD, verificando este problema. Já detectamos qual a causa do problema. A Control iD está trabalhando na correção, que será disponibilizada no próximo firmware. Descobrimos também que existe uma solução paliativa para o problema. Basta definir, no componente ACBrPosPrinter, o tamanho do espaço entre linhas para 50. Desta forma, todos os caracteres acentuados serão impressos. Exemplo: Nosso objeto exemplo chama-se ACBrPosPrinter1, usando a classe TACBrPosPrinter (Componente: ACBrPosPrinter) ou

Fala Renato! Eu realizei um teste com o SATTeste e a comunicação funcionou normalmente. As configurações que usei são as mesmas que a sua. Tenho 4 perguntas para você: Você está usando a ultima versão da DLL do fabricante? Se sim, testa com alguma mais antiga. Se não, testa com uma mais nova. Veja se alterando essas bibliotecas o problema para de ocorrer; Os componentes do ACBr que você está usando estão na ultima versão? O SATTeste que usei está na versão 2.2, compilado com os componentes atualizados. Ele está disponível no link: Se você usar o SATTeste do fórum,

Atualização da homologação - Rev. 1: O ACBr é um projeto vivo que recebe atualizações diárias. Essas atualizações, normalmente, envolvem correções e novas funcionalidades. Para acompanhar esta realidade, adição de novos testes e revisão dos existentes são frequentes em novas homologações. Fica evidente também, que homologações antigas necessitam de revisões. Por conta disso, adicionamos nesta postagem, informações adicionais e novos testes comumente encontrado em homologações recentes. Quando houver novas funcionalidades nos componentes ocasionando a necessidade de novos testes, serão fe

Atualização da homologação - Rev. 1: O ACBr é um projeto vivo que recebe atualizações diárias. Essas atualizações, normalmente, envolvem correções e novas funcionalidades. Para acompanhar esta realidade, adição de novos testes e revisão dos existentes são frequentes em novas homologações. Fica evidente também, que homologações antigas necessitam de revisões. Por conta disso, adicionamos nesta postagem, informações adicionais e novos testes comumente encontrado em homologações recentes. Quando houver novas funcionalidades nos componentes ocasionando a necessidade de novos testes, serão fe

Atualização da homologação - Rev. 1: O ACBr é um projeto vivo que recebe atualizações diárias. Essas atualizações, normalmente, envolvem correções e novas funcionalidades. Para acompanhar esta realidade, adição de novos testes e revisão dos existentes são frequentes em novas homologações. Fica evidente também, que homologações antigas necessitam de revisões. Por conta disso, adicionamos nesta postagem, informações adicionais e novos testes comumente encontrado em homologações recentes. Quando houver novas funcionalidades nos componentes ocasionando a necessidade de novos testes, serão fe

Atualização da homologação - Rev. 1: O ACBr é um projeto vivo que recebe atualizações diárias. Essas atualizações, normalmente, envolvem correções e novas funcionalidades. Para acompanhar esta realidade, adição de novos testes e revisão dos existentes são frequentes em novas homologações. Fica evidente também, que homologações antigas necessitam de revisões. Por conta disso, adicionamos nesta postagem, informações adicionais e novos testes comumente encontrado em homologações recentes. Quando houver novas funcionalidades nos componentes ocasionando a necessidade de novos testes, serão fe

Atualização da homologação - Rev. 1: O ACBr é um projeto vivo que recebe atualizações diárias. Essas atualizações, normalmente, envolvem correções e novas funcionalidades. Para acompanhar esta realidade, adição de novos testes e revisão dos existentes são frequentes em novas homologações. Fica evidente também, que homologações antigas necessitam de revisões. Por conta disso, adicionamos nesta postagem, informações adicionais e novos testes comumente encontrado em homologações recentes. Quando houver novas funcionalidades nos componentes ocasionando a necessidade de novos testes, serão fe