Próton Sistemas

Bom dia todos! Estou realizando alguns testes utilizando o exe do ACBrPosPrinter e estou recebendo um erro de timeout seguido de impressão de caracteres estranhos. 1 - Ocorre com bitmaps grandes (impressão com muitas linhas); 2 - Defini vários valores para BytesCount e Interval, entre outros, mas sempre retorna o mesmo erro de timeout(16.384 kb enviados para USB); 3 - Não tenho driver spooler instalado, mando direto para a USB; 4 - Porta ativada ou desativada / ACBrPosPrinter ativado ou desativado 4 - Segue imagem do exe: Algo adicional que possa ser feito?

Boa tarde a todos. Obrigado pelo retorno @Daniel Simoes

Poderia compartilhar o "dependendo do status envio o comando imprimir"? Sob qual status vc libera a impressão? Eu estou precisando de uma maior precisão para permitir a próxima impressão. Qual ou quais os status que vc utiliza para determinar que a impressora está "livre" para uma nova impressão?

Obrigado pelo retorno. Mas mesmo nos testes no ACBrPosPrinter Teste, se mando imprimir o conteúdo do memo e durante a impressão solicito o status, não tenho como retorno um stImprimindo, me retorna um "Nennhum Erro encontrado", ou seja, nenhum status Preciso de fato saber que a impressora está "ocupada", não concluiu a impressão.

Complementando, Faço a definição da porta para componente: ACBrPosPrinter.Porta := porta; E não possuo a impressora instalada no windows.

Boa tarde a todos! Senhores, retomando o problema... Demorei em dar retorno para ter um maior tempo de testes, gostaria de avaliar um cenário com vocês. Faço o envio das impressões por meio de tasks, mais precisamente, task IFuture. Se envio mais de um documento (DANFE e CCD, por exemplo), controlo se a task atual, DANFE, ainda está em execução para só depois permitir que a segunda task de impressão, CCD, seja executada. A questão é que esporadicamente ocorre da segunda task iniciar com a impressora ainda realizando a impressão anterior, com isso, erros de impressão. Gostaria de obter o status da impressora para determinar que ainda está ocorrendo uma impressão e não iniciar a segunda até a conclusão, contudo, o método TACBRPosPrinter.LerStatusImpressora() me retorna apenas o status de stGavetaAberta, isso quando não tenho retorno de tampa aberta quando a mesma não está. Como posso utilizar o TACBRPosPrinter de forma a ter status reais para definir que a impressora ainda está "ocupada", há algum outro componente que precise trabalhar em conjunto ou alguma outra coisa? O controle da porta se dá por meio da ativação e desativação do próprio TACBRPosPrinter.

Obrigado.

Bom dia, Gostaria de tirar uma dúvida. Sei que há no ACBr métodos para truncar ou arredondar valores, contudo, o que seria mais correto, truncar ou arredondar? Há uma legislação que defina qual o comportamento? Vejo cenários muito híbridos, havendo um pouco dos dois, quando não misturados, hora trunca, hora arredonda.

Logo após identificarmos essa questão do reenvio, iniciamos de imediato os testes do envio completo. Assim que tiver algum retorno, atualizo vocês aqui. Obrigado pela atenção.

@Daniel Simoes @Daniel InfoCotidiano @Victor H. Gonzales - Panda Uma informação que pode ajudar a entender o que pode estar ocorrendo. Observem que na imagem que enviei onde ocorreu o erro, a informação do CNPJ e IE, compõem a primeira linha do cabeçalho, ou seja, estariam no primeiro pacote de 16.384k enviados. Contudo, observem que informações deste primeiro pacote voltam a aparecer erroneamente mais abaixo, quebrando a impressão, conforme imagem a seguir (Ressalto que observando a primeira imagem, completa, que postei e que deu origem ao tópico, o mesmo erro ocorre, ou seja, informações do primeiro pacote de 16.384kb são reimpressos erroneamente, e com isso, a impressão se perde). Fico no aguardo.

Segue um exemplo recente onde no envio de um dos blocos de 16kb, algo de muito estranho ocorreu...

Uma outra questão a ser ressaltada, é que temos clientes que não usam logo, mas ocorre o problema. Relatórios de fechamento e abertura não possuem logo, mas também ocorrem

Bom dia! @Daniel Simoes @Daniel InfoCotidiano @Victor H. Gonzales - Panda "Você envia o Logotipo ? Se SIM, Seria mais rápido (e livre de problemas) gravar o Logo na memória da impressora, e só enviar o comando de impressão de Logo" Sim, enviamos a logo. Como fazemos? 1 - Temos um TACBrNFeDANFCEFR conectado ao TACBrNFe e a partir dele fazemos um export para um TfrxBMPExport. 2 - Fazemos um render bitmap a partir do arquivo exportado para passarmos como parâmetro para o TACBrPosPrinter.ImprimirCmd(RenderBitmap). 3 - Como mencionado, não mandamos a imagem de uma única vez, "fatiamos" em blocos de aproximadamente 16k, com intervalos de 100ms entre os blocos. Sua sugestão, se entendi bem, seria não carregarmos a logo como fazemos e passarmos a enviá-la para a memória da impressora. Mas isso precisaria ser feito através do software de cada impressora. Hoje temos mais mil impressoras ativas, o que tornaria complexa essa mudança. Teríamos alguma outra alternativa para evitarmos o problema, mas mantendo nossa arquitetura??

Ou seja, neste caso o texto era relativamente "grande", mas já houve ocorrência em cenários menores. Tendo havido um caso onde o problema ocorreu na abertura do caixa no momento da impressão da abertura (primeira impressão do dia).

@Victor H. Gonzales - Panda Varia bastante. Mas por exemplo, a imagem que anexei a este post como exemplo da ocorrência do problema, completa, possui 193K. Para a impressão de imagem algumas impressoras não suportavam enviar toda a imagem de vez. 18k é o máximo que observamos em alguns modelos e por isso definimos como quantidade de envio ACBrPosPrinter1.Device.SendBytesCount := 1024 * 16; Controlamos tb o intervalo de envio, pois algumas impressoras não suportaram o envio completo e por garantia, definimos o mesmo tempo para todas ACBrPosPrinter1.Device.SendBytesInterval := 100;