-
Total de ítens
7 -
Registro em
-
Última visita
Contact Methods
-
Website URL
http://www.idealsis.com.br
Últimos Visitantes
534 visualizações
fabio.idealsis's Achievements
-
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.
-
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.
-
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. ACBrBAL.pasACBrBALLenkeLK2500.pas
-
OK, vou baixar e efetuar os teste, qualquer novidade aviso. Obrigado pela atenção. Att.
-
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
-
fabio.idealsis changed their profile photo
-
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 -----------> PARIDADE Esse é 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 C Alguma dica do que possa estar acontecendo. Desde já muito obrigado.
-
Leandro_Silva started following fabio.idealsis
-
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 !
-
Impressão AcbrEtq GS1-128
fabio.idealsis replied to fabio.idealsis's tópico in Dúvidas Gerais sobre o ACBr
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 !
-
fabio.idealsis joined the community
-
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.