-
Total de ítens
7 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por fabio.idealsis
-
-
Boa tarde pessoal.
Estou desenvolvendo um app FMX, e ao utilizar essa procedure da classe ACBrImage, me retorna o seguinte erro: [dcc32 Error] Model.AcertoPsj.pas(1323): E2010 Incompatible types: 'Vcl.Graphics.TBitmap' and 'FMX.Graphics.TBitmap'.
Alguém saberia responder ?
Obrigado.
-
Não tenho, não encontrei nenhuma documentação, fiz a implementação analisando a comunicação. Está funcionando 100% de acordo com os testes que eu fiz.
- 3
-
Bom dia pessoal,
Alterei o pacote ACBrSerial -> ACBrBAL, fiz uma implementação do seguinte modelo de balança:
Lenke LK2500
alguém poderia validar e adicionar no repositório por favor?
Att.
- 2
-
OK, vou baixar e efetuar os teste, qualquer novidade aviso.
Obrigado pela atenção.
Att.
- 1
- 1
-
Daniel, o modelo da Precison foi criado não existia.
Os outros modelos da Toledo, seguem a mesma linha, utilizando o modelo toledo "Universal", não obtive êxito na comunicação, daí criei as units especificas pra cada modelo.
Att.
-
boa tarde, alterei o pacote ACBrSerial -> ACBrBAL, fiz uma implementação dos seguintes modelos de balanças:
Precision
Toledo 2090N
Toledo BCS21
alguém poderia validar e adicionar no repositório ?
Att.
ACBrBAL.pas ACBrBALPrecision.pas ACBrBALToledo2090N.pas ACBrBALToledoBCS21.pas
- 1
- 1
-
Já testei com outro protocolo disponível P03C, e também não funcionou. Utilizando o modelo 2180 disponível no componente ele conseguiu fazer a leitura, porém o peso está incorreto, exemplo no display 0,90, no software 9,000. Os testes realizados com esse formato novo "eth", foi com qual balança? Era uma tcp ?
wPosIni := PosLast(STX, aResposta);
if (Copy(aResposta, wPosIni + 1, 2) = '02') and
(Copy(aResposta, wPosIni + 60, 1) = ETX) then
wResposta := InterpretarProtocoloEth(aResposta)Nessa verificação " if (Copy(aResposta, wPosIni + 1, 2) = '02') and (Copy(aResposta, wPosIni + 60, 1) = ETX) then" que não satisfaz, fiz um teste comentando e forçando ele chamar o InterpretarProtocoloEth, e o resultado fica igual ao da unit toledo2180, ele consegue ler mais o peso vem incorreto.
-
Boa Tarde,
Pessoal, estou fazendo a implementação no meu sistema usando uma balança com protocolo TCP. Eu consigo fazer a comunicação tudo certinho, porém utilizando os exemplos do Acbr, o retorno é sempre 0. Verificando os fontes (baixei a utlima versão do trunk) percebi que o retorno da balança não atende as clausulas para a função InterpretarProtocoloEth o retorno da balança é bem diferente do previsto na clausula. O protocolo de comunicação da balança é o P03 que segundo o manual do fabricante tem esse formato.
16.4 Protocolo P03
Canal de Comunicação: Rede Ethernet ou Wlan (WiFi).
A interface de comunicação rede dispõe de um socket do tipo Server,
que pode ser acessado por qualquer programa do tipo Client capaz de
abrir uma conexão TCP/IP. O protocolo disponibilizado neste socket é
para envio de dados contínuo.
16.4.1 Formato do protocolo
STX SWA SWB SWC IIIIII TTTTTT CR (CS)
STX - Start of Text = 02
CR - Carriage Return = 0DH
CS - Byte de Checksum
I - Peso indicado no Display (Líquido ou Bruto)
T - Tara
SWA - STATUS WORD “A”
BIT 2, 1 e 0 ----> 001 = DISPLAY x 10
010 = DISPLAY x 1
011 = DISPLAY x 0.1
100 = DISPLAY x 0.01
101 = DISPLAY x 0.001
110 = DISPLAY x 0.0001
BIT 4 e 3 -------> 01 = TAMANHO DO INCREMENTO I 1
10 = TAMANHO DO INCREMENTO I 2
11 = TAMANHO DO INCREMENTO I 5
BIT 6 e 5 -------> 01 = SEMPRE
BIT 7 -----------> = PARIDADE
SWB - STATUS WORD “B”
BIT 0 -----------> PESO LÍQUIDO = 1
BIT 1 -----------> PESO NEGATIVO = 1
BIT 2 -----------> SOBRECARGA = 1
BIT 3 -----------> MOTION = 1
BIT 4 -----------> SEMPRE = 1
BIT 5 -----------> SEMPRE = 1
BIT 6 -----------> SE AUTO ZERADO = 1
BIT 7 -----------> PARIDADE
SWC - STATUS WORD “C”
BIT 0 -----------> SEMPRE = 0
BIT 1 -----------> SEMPRE = 0
BIT 2 -----------> SEMPRE = 0
BIT 3 -----------> TECLA IMPRIMIR = 1
BIT 4 -----------> EXPANDIDO = 1
BIT 5 -----------> SEMPRE = 1
BIT 6 -----------> SEMPRE = 1
BIT 7 -----------> PARIDADEEsse é o retorno do log.
--------------------------------------------------------------------------------
ATIVAR - 10/07/17 14:11:44:461 - Modelo: Toledo - Porta: tcp:192.168.0.25:9000 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0
--------------------------------------------------------------------------------- 14:11:46:805 TX -> [ENQ]
- 14:11:47:024 RX <- [STX]4p`000098000000[CR][FS][STX]4p`000098000000[CR][FS][STX]4p`000098000000[CR][FS]
UltimoPesoLido: 0 - Resposta: [STX]4p`000098000000[CR][FS][STX]4p`000098000000[CR][FS][STX]4p`000098000000[CR][FS] - Protocolo: Protocolo CAlguma dica do que possa estar acontecendo.
Desde já muito obrigado.
-
Boa Tarde Pessoal,
Estou fazendo uma impressão de uma etiqueta do padrão ean 128, (ucc/128) cujo o código no momento da impressão é o '1E', utilizando o componente acbretq EPLII em uma impressora Zebra. O que ocorre é o seguinte, a impressão do código de barras está tudo ok, porém na impressão das informações do código de barras (becSIM), a forma como ele vem impresso segundo uma rede de supermercados está incorreta. Vou exemplificar.
Essa é a impressão que sai na etiqueta: (15)160619(11)150619(70)3007612345100001
E o pessoal diz que o correto é nesse formato: (15)160619(11)150619(7030)07612345(10)0001
Observem que são apenas os parenteses que não estão da forma "correta" como o pessoal da rede diz que tem que ser.
Alguém já fez esse tipo de etiqueta, ou já passou por situação parecida ?
Desde já obrigado pela atenção !
-
Bom dia Pessoal,
Estou fazendo uma impressão de uma etiqueta do padrão ean 128, (ucc/128) cujo o código no momento da impressão é o '1E', utilizando o componente acbretq EPLII em uma impressora Zebra. O que ocorre é o seguinte, a impressão do código de barras está tudo ok, porém na impressão das informações do código de barras (becSIM), a forma como ele vem impresso segundo uma rede de supermercados está incorreta. Vou exemplificar.
Essa é a impressão que sai na etiqueta: (15)160619(11)150619(70)3007612345100001
E o pessoal diz que o correto é nesse formato: (15)160619(11)150619(7030)07612345(10)0001
Observem que são apenas os parenteses que não estão da forma "correta" como o pessoal da rede diz que tem que ser.
Alguém já fez esse tipo de etiqueta, ou já passou por situação parecida ?
Desde já obrigado pela atenção !
Alguma dica pessoal !?
-
Bom dia Pessoal,
Estou fazendo uma impressão de uma etiqueta do padrão ean 128, (ucc/128) cujo o código no momento da impressão é o '1E', utilizando o componente acbretq EPLII em uma impressora Zebra. O que ocorre é o seguinte, a impressão do código de barras está tudo ok, porém na impressão das informações do código de barras (becSIM), a forma como ele vem impresso segundo uma rede de supermercados está incorreta. Vou exemplificar.
Essa é a impressão que sai na etiqueta: (15)160619(11)150619(70)3007612345100001
E o pessoal diz que o correto é nesse formato: (15)160619(11)150619(7030)07612345(10)0001
Observem que são apenas os parenteses que não estão da forma "correta" como o pessoal da rede diz que tem que ser.
Alguém já fez esse tipo de etiqueta, ou já passou por situação parecida ?
Desde já obrigado pela atenção !
-
Daniel boa tarde,
Daniel descobri qual o problema desse erro do CMC7, na verdade o erro não está no componente não, porém descobri algo que se passar despercebido pelo programador pode gerar o mesmo erro que aconteceu comigo. No meu caso após ler o cheque, o próximo passo era terminar o lançamento do mesmo, um dos processos era efetuar a distribuição de custo para o cheque, era aí que acontecia o erro, em determinado momento eu setava o SetRoundMode para rmDown, quando eu ia ler outro cheque o componente utiliza a função round, porém ela estava setada para rmDown, e aí o componente acusa CMC7 inválido. Minha sugestão nesse caso, seria na função CalcDigitoCMC7 setar o SetRoundMode para rmNearest antes de executá-la . Bom fica aí minha dica, eu fiz no fonte do componente e funcionou perfeitamente. Não sei como e se posso replicar isso pra vocês. Espero ter contribuído de alguma forma.
-
Bom dia Daniel,
Daniel fiz os teste com o exemplo e não consegui reproduzir o erro, analisando o meu projeto a unica coisa que tem de diferente é que após a leitura ele chama uma segunda tela com showmodal, para que o usuário termine o lançamento dos dados do cheque, quando essa tela é fechada a próximo leitura já não funciona mais. Fiz um debug, para verificar o componente e o que pude perceber é que o erro esta na validação do digito, a mesma string retorna valores diferentes na validação do digito. Ex. na primeira execução ele retorna um valor e o round aproxima pra 2 e depois na segunda vez com a mesma string o round traz 1 e aí gera o erro de CMC7 inválido.
-
Boa Tarde pessoal,
Pessoal seguinte, estou utilizando o acbrcmc7 e esta ocorrendo o seguinte, na primeira vez que ele analisa a string ele valida tudo certinho, se eu tentar ler uma segunda string ainda que seja a mesma que foi validada normalmente ele manda a mensagem cmc7 inválido. Eu tenho que fechar o sistema e abrir novamente para que ele possa ler e validar corretamente. Alguém já passou por alguma situação igual ou parecida ? Desde já agradeço a atenção.
-
Bom dia pessoal,.. Pessoal eu utilizo o componente acbr etiqueta para impressão térmica e ocorre que depois da ultima atualização que eu fiz do componente, mudou algumas configurações do componente, até aí tudo bem, fiz uma correção no meu sistema e voltou a funcionar, porém eu utilizo a chama ACBrETQ.ImprimirCaixa para imprimir uma caixa, o que ocorre é que depois da atualização a caixa imprime uma tarja preta, sendo que antes imprimia somente o contorno da caixa. Alguém sabe dizer se mudou alguma coisa no componente ? Obrigado pela atenção.
Erro no comando BitmapToRasterStr.
em ACBrSerial
Postado
sim, está definido sim, um detalhe é que, se você compilar para Android funciona normalmente daí quando muda para plataforma windows é que o erro acontece.
O mesmo erro ocorre ao tentar compilar o projeto de exemplo do ACBrPosPrinter Firemonkey.