HBComm

[Hasse]

Estou com algumas dúvidas em relação ao funcionamento das funções desta LIB.

Em:

Código: Selecionar todos

Bytes  := InbufSize(nHandle)
TmpBuf := TmpBuf + InChr( Bytes)                // Lê Buffer.
OutChr( nHandle, @Ack )                         // Envia um Ack (06) para a central.

Sempre quando temos a função InChr(Bytes) ela prende a execução do programa até que o Buffer lido se esvazia ?
Ou isto depende do aparelho que está enviando os dados...

A informação ACK sempre deve ser enviada para informar o recebimento dos dados, ou isto também depende do aparelho ?

[vagucs]

Você tem que informar um timeout para saida no caso de nao haver resposta, a versão que tenho da hbcomm aqui os ela recebe mais parametro, a antigo IOLIB do clipper que funciona apenas com 1 port aberta, era so mesmo dar o INCHR.

No xHarbour seria aog assim
buffer=""
lidos=inchr(handle_da_porta,@buffer)

[Hasse]

Boa tarde Wagner.

Pesquisei na documentação da HBcomm.lib e nada encontrei que se relacionasse com timeout.

[Hasse]

Acredito que já "matei" o meu problema com o TIMEOUT. Verifiquei no Fórum, no post do leandrolinauer, até com exemplo.

Outro detalhe:

Estou adquirindo um adaptador de cabo SERIAL para USB, visto que o meu Notebook não tem mais entrada Serial. O vendedor informa que há necessidade de usar "portas altas", mas não sabe informar o que isto significa. Lendo instruções de HBComm, acredito que "portas altas" devem ser aquelas com números acima de COM9, ou então que sejam acessadas via sintaxe geral.

Seria muito importante contar com a experiência de colegas que já fizeram uso deste dispositivo.

Na documentação da HBComm.lib informa que para portas maiores que COM9 é necessário o uso da sintaxe geral, tipo "\\.\COMn". Algum colega pode aclarar, com um exemplo, como é que é esta sintaxe ? Como se usa ela. Como ela funciona...

[vagucs]

Hasse, so passar na init_port a porta como o descricato "\\.\COM9" por exemplo

[Hasse]

OK Wagner.

Obrigado pela tua atenção.

Assim que eu receber o dispositivo coloco os resultados aqui.

[Hasse]

Bom dia colegas.

Voltando ao tópico.
Testando a rotina abaixo:

Código: Selecionar todos

FUNCTION recebedados()
*
Local cArqDados := 'ComDados.txt'
Local cArqTmp   := 'ComTmp.txt'
Bytes           := InbufSize( nHandle )
InBuff          := Space( Bytes )
*
IF Bytes > 0
      n_TmpBuff := InChr( nHandle, @InBuff, Bytes )
      OutChr( nHandle, ACK )
      FGravaTxt( cArqTmp, InBuff )
   ENDIF
RETURN( InBuff )

Esta rotina deve receber dados do aparelho remoto, porém entram somente espaços vazios. Por exemplo, se a variável Bytes retorna 140, recebo 140 caracteres vazios (32) na variável InBuff

Ela deveria conter o "STX + resultados + ETX", que deveria ter um comprimento de 140 bytes de dados.

Alguém pode me ajudar ? Algum colega tem uma LUZ ?

[leandrolinauer]

Boa tarde Hasse

Da uma lida no post em CONTRIBUIÇÕES o título "ECF - Comunicação direta - Presentão", lá eu tenho exemplificado o fonte comunicando diretamente com a ECF pela HBCOMM.LIB

Quanto a este erro que esta dando, eu tive o mesmo problema creio que seria mais ou menos igual, eu lia o buffer ora pegava dados ora não, descobri que tinha que dar um tempo para o programa pegar o retorno de cada comando lá eu coloquei um tempo relativo a cada um e deu certo de acordo com o tamanho do buffer que tinha que receber.

Da uma olhada se tiver alguma dúvida a respeito de alguma linha, me poste que te explico.

Um xHarbraço. :xau

[Hasse]

Boa noite Leandro.

Vou tentar esta opção, e volto ao assunto.

Obrigado pela dica.

[sygecom]

Olá Hasse,
Quando vc fala em aparelho REMOTO, vc se refere que o aparelho que você vai se comunicar vai ser usando remotamente como por exemplo o TS, ou pela internet ?
Se for isso, fiz varios teste e não obtive exito nem com hbcomm e nem com as funções da fivewin para comunicação serial, a unica que teve exito foi com o a versão Demo da HBCOMM do xharbour comercial, com essa consegui me comunicar remotamente usando o TS. porem comprar uma licença do xharbour comercial para min por enquanto esta fora de cogitação.

[Hasse]

Boa noite Leonardo.

Obrigado pela tua atenção. Valeu.

Quando menciono aparelho remoto refiro-me a um aparelho automático de análises laboratoriais.

Envia-se para ele uma WorkList, ele elabora os exames solicitados e devolve os resultados ao computador que chamamos de interface.

Sábado à tarde consegui contornar o problema. O meu erro era acessar o Buffer do aparelho uma só vez com a função InChr(), como você pode ver na rotina postada. Eu imaginava que a leitura viria de uma forma contínua e de uma só vez.

Bastou mudar para vários acessos, com um DO WHILE, como abaixo, que tudo começou a acontecer. Os dados vinham a jato.

Código: Selecionar todos

DO WHILE InBufSize( nHandle ) > 0
   nRead := InBufSize(nHandle)
   cRead := Space(nRead)
   InChr( nHandle, nRead, @cRead)
   cRet += cRead
   Regua()
ENDDO
FGravaTxt( cArqTmp, cRead )

Interessante, que um mesmo arquivo, é divido em várias partes de tamanho aleatório. Em cada leitura de dados, o tamanho da linha lida é diferente das demais, e raramente temos 2 blocos de tamanho igual. Já o tamanho final da linha é sempre exatamente igual.

Este assunto está resolvido. Porém, como pouca porcaria é bobagem, surgiu outra, que é a "tradução" da linha de dados. Não é ASC e não é Hexadecimal. Os dados lidos variam do CHR(0) a CHR(254). Uma "doidura só". Estou preparando o material para postar, e estou estudando para tornar este material de fácil entendimento. Assim que estiver OK, eu posto.

[sygecom]

Entendi Hasse, questionei pq minha situação é realmente de acesso remoto usando o TS, ou seja o aparelho que é uma balança eletronica esta LOCAL, porem o sistema esta rodando direto no servidor com TS, e tem caso que é ao contrario, a balança esta longe e o sistema esta local. Mas vlw...

[Hasse]

Boa noite colegas.

Conforme comentado acima estou postando o meu atual problema com a comunicação serial.

A linha de dados que está na área de download, e recebida via serial do aparelho, que está entre as setas "Linha-> <-", é composta por 175 caracteres.

Muito estranho os 175 caracteres... se fosse hexadecimal não deveria ser número par ? Mas também não parece ser código hexadecimal, já que o hexadecimal deveria conter somente caracteres de 0(zero) até F.
Vejam abaixo, os acaracteres recebidos, sem qualquer tratamento, somente separados por "," (vírgula)

Código: Selecionar todos

  ,   , ÿ , Ç ,   ,  , ­ ,  ,   , ÿ , x , ¦ , ¾ ,  , Ç ,  , ­ ,  , ¤ ,
 ÿ , x , ¦ , ¾ ,  , Ç ,  ,   ,  ,   ,  ,   ,  ,   ,  ,   ,  ,   ,  ,
   ,  ,   ,  ,   ,  , + , ÿ , x ,  ,  ,  ,   , ÿ , Ç ,  ,  ,   ,  ,
   ,  , + , 3 ,   , ÿ ,  , 3 , + ,  ,   ,  , + , 3 , Ç , å , ÿ ,  , + ,
  , Ç ,  , + , ÿ , Ó ,  ,   ,  , + ,  , + , ÿ , Ó , ÿ ,  ,  , 0 ,  ,
 x ,  ,  ,  ,  ,  , 0 ,  , ` ,  , + ,  , Ç ,  ,   ,  ,   ,  ,   ,
  ,   , ÿ , f ,  , x ,  , å ,  ,  , f ,  , ` ,  , å , ÿ ,  , 3 , ` ,
 ¾ , 3 ,  , x ,  , ­ ,  , Ç ,  , + , ÿ , Ó ,  ,   ,  , + ,  , ­ ,  ,
   , ÿ , ÿ ,   ,  , ? , 3 ,   ,  , + ,  , + ,  , 3 , ­ ,  ,   , ÿ , Ç ,
 ` ,   , ÿ , Ç ,

========== seguem os mesmos valores ASC, separdos por '|'

Código: Selecionar todos

006|000|152|128|000|024|240|024|000|152|120|204|243|024|128|024|240|024|207|
152|120|204|243|024|128|024|000|024|000|024|000|024|000|024|000|024|000|024|
000|024|000|024|000|024|192|152|120|012|006|012|000|152|128|024|015|000|024|
000|024|195|051|000|152|006|051|195|024|000|024|192|051|128|134|152|006|192|
012|128|024|192|152|224|024|000|024|192|024|192|152|224|152|030|003|048|006|
120|012|030|003|030|003|048|006|096|012|192|024|128|024|000|024|000|024|000|
024|000|152|102|012|120|012|134|030|015|102|015|096|015|134|152|030|051|096|
243|051|006|120|012|240|024|128|024|192|152|224|024|000|024|192|024|240|024|
000|152|152|000|024|063|051|000|024|192|024|192|024|051|240|030|000|152|128|
096|000|152|128|

========== pelos resultados fornecidos pelo aperelho, deveríamos encontrar, mais ou menos, os dados abaixo:

Código: Selecionar todos

SOHLF                                                       (02)
08 COBAS MIRA 03LF                                          (18)
STXLF                                                       (02)
20RA1PCR 010001nome pacie+2.40000E+0001??ON00               (46)
LF                                                          (01)
ETXLF                                                       (02)
ETOLF                                                       (02) = 73 x 2 = 146

=================================================
Conforme o manual, esta comunicação deve ter a seguinte estrutura:

Código: Selecionar todos

SOH+LF
08 COBAS MIRA 03LF
STX+LF
dados
ETX+LF
EOT+LF

onde:
1- a seqüência "SOH+LF+08 COBAS MIRA" ou "SOH+LF+07 COBAS MIRA" identifica o modelo do aparelho que está enviando os dados;
2- a seqüência "03+LF" identifica o tipo de bloco de dados que serão transmitidos pelo aparelho, seguido do LF.
-opções para o tipo de bloco de dados: "00, 01, 03, 05, 10, 11, 15, 16, 70, 71, 94 e 95" (um tipo de bloco de cada vez).
3- a seqüência "STX+LF+dados+ETX+LF+EOT+LF" pode repetir-se até a término de envio dos dados do tipo de bloco selecionado.
4- 'dados' deve ter os seguintes valores:
20RA1PCR 010001??????????+2.40000E+0001??ON00LF

Na linha de "dados" lidos, em alguma posição deveria conter os valores:
064 (identificação da amostra)
PCR (tipo de exame realizado na amostra)
2.4 (valor do resultado)
08 (tipo de unidade, neste caso mg/l)

Os únicos valores, pelas suas posições e repetição, que aparentemente fazem sentido são:
152 e 128 = LF ?? = (0AH = 10 decimal)
96 e 0 = EOT ?? = (04H = 4 decimal)
30 e 0 = ETX ?? = (03H = 3 decimal)
6 e 0 = SOH ?? = (01H = 1 decimal)
mas que código matemático transforma estes valores em LF, EOT, ETX e SOH ?
=========================

A coisa ficou "preta", e preciso de ajuda, de sugestões, de orientações.

[sygecom]

Hasse, vc tem alguma documentação do aparelho que vc deseja se comunicar ? Muitas vez alguns aparelho como por exemplo balanças eletronicas esperam receber um comando para depois enviar algo para a porta serial, outro coisa, vc tentou se comunicar usando o Hyper Terminal do Windows, para ver se esta chegando tudo como deve chegar mesmo.

[Hasse]

Boa noite Leonardo.

Sim, tenho documentação do aparelho. Só tem um pequeno detalhe, ele é tremendamente lacônico a respeito.

A documentação diz exatamente aquilo que postei acima e que repito abaixo:

Código: Selecionar todos

SOHLF                                               (02 caracteres)
08 COBAS MIRA 03LF                                  (18 caracteres)
STXLF                                               (02 caracteres)
20RA1PCR 010001nome pacie+2.40000E+0001??ON00       (46 caracteres)
LF                                                  (01 caracter)
ETXLF                                               (02 caracteres)
ETOLF                                               (02 caracteres) = 73 x 2 = 146 (total de caracteres)

Especificamente, este aparelho não aguarda qualquer comando, e sim o computador deve estar continuamente aguardando a recepção de dados, pois conforme o aparelho vai realizando os testes e exames, vai emitindo os resultados, automaticamente. No máximo, pode-se configurar, 1)só imprimir; 2)só enviar via serial; ou 3)imprimir e enviar via serial.

É por este motivo é que sei que os valores que mencionei e que repito abaixo devem estar presentes em alguma parte da linha de dados, pois estes valores foram impressos ao mesmo tempo em que foram enviados via serial.
Nesta linha de "dados" recebidos, em alguma posição, deve conter os valores:

Código: Selecionar todos

064         (identificação da amostra)
PCR         (tipo de exame realizado na amostra)
2.4         (valor do resultado)
08          (tipo de unidade, neste caso mg/l)

Não, não tentei comunicar-me usando o Hyper Terminal do Windows. Não tenho experiência com este tipo de conexão. Em quê e de que forma esta operação pode ajudar ?