Valor do ponto pode não ser confiável


#1
Boa  Tarde à todos
Estou iniciando o estudo no ScadaBR.
 
Possuo um controlador Presys DCY-250 Light onde le esta conectado um termopar.
 
Sua comunicao com esse Scada esta sendo efetuada por um Novus USB-I485(485 para USB).
 
Em data Sources configuro como:
 
tipo: Modbus Serial
Baud RAte: 9600
Controle de fluxo de entrada: nenhum
Controle de Fluxo de Sada: Nenhum
 
data Bits:8
Stop Bits:1
Paridade: nenhum
Codificao: RTU.
 
No controlador esto setados os mesmos parmetros e seu endereo como 47.
 
Quando efetuado o "Teste de localizador de ponto" ele encontra o valor exebido perfeitamente
 
Detalhes do data point;
 
 
ID escravo: 47
Faixa do registro: Registrador Holding
tipo de Dados modbus: Inteiro de 2b sem sinal
offset:0
multiplicador : 1
aditivo:0
 
 
Porémm , no Watch List apresenta o erro: Valor do ponto pode no ser confiável.
 
Ja li mesmo forum onde citam como soluo a instalao do scadabr em Windows 7, bibliotecas RXTX,
Verso do java, apenas o navegador chrome e firefox como compativel.
J verifiquei todos esses tpicos e continuo sem sucesso.
 
Por ultimo fiz o teste em registradores da Novus e Kron, porm o mesmo erro: Valor do ponto pode no ser confiável
 
Poderiam me ajudar?
 
obrigado
Paulo
 

#2

Paulo,

Mesmo com esta mensagem aparecendo, o valor lido está correto ou não? Como diz a mensagem, o valor "pode" não ser confiável, mas pode estar correto.

Você tem apenas este datapoint cadastrado, ou vários datapoints no mesmo datasource modbus?

Existe apenas este slave cadastrado na rede?

"O valor do datasource pode não ser confiável" acontece quando em uma operação de polling ocorre uma falha parcial na leitura, por exemplo um timeout em um dos slaves. Ou se algum dos datapoints solicitados não existirem, o equipamento pode se recusar a responder.

 

Se vc está lendo múltiplos pontos e apenas 1 deles falhar, todos os outros serão marcados como "pode não ser confiáveis". Do site do mango m2m: 

Point current value reliability
A point attribute has been added such that the current value of a point can be considered "unreliable". Currently this feature is only available in Modbus and proprietary data sources. The specifics of operation differ between data sources, but in Modbus, if a polled slave read fails, all of the points being read are marked as unreliable. This indication appears in watch lists and graphical views. Along with the indication is the ability to force an individual point read to "refresh" the point value. 
 

Vc pode experimentar algumas variações do seu teste

- verifique se no datasource, além deste controlador 47, não há outros caras configurados;

- aumentar o intervalo entre os pollings (na configuração do datasource).

- aumentar o timeout em milissegundos dos pollings  (na configuração do datasource);

- certifique-se de que o resultado do [timeout X número de retries], é bastante menor que a taxa de atualização do datasource (para não ter pacotes de pollings sucessivos esbarrando na porta)

- restringir a quantidade máxima de pontos lidos em cada operação (na configuração do datasource);

- iniciar com o cadastro de menos datapoints (foque apenas em 1 slave e 1 datapoint, desabilitando quaisquer outras fontes de interferência como outros datasources na mesma porta serial), e expanda o teste à medida que obter mais sucesso;

- certificar-se de que todos os componentes estão com baudrate, paridade, etc. idênticos (alguns conversores são auto-baud rate, mas se o equipamento estiver digamos em 9600, o conversor em 115200 e o PC em 9600, efeitos indesejados podem ocorrer - melhor normalizar todo mundo em 9600 ou 115200)

- verificar a instalação física da rede incluindo shield do cabo 485 e terminador de conexão;

O seu caso não é trivial, afinal o 485 em si já é um barramento mais complexo do que parece; o uso de conversores USB é uma fonte clássica de incomodação no windows (apesar de eu gostar muito dos equipamentos da Novus);  e existem ainda múltiplas fontes possíveis de interferência em comunicação modbus (o fato de vc ter testado com outros equipamentos, reduz a chance de o problema estar no CLP em si).

Caso todas as alternativas acima não funcionem, vc precisará usar um sniffer de porta serial e debugar em nível de frames&bytes, ou eventualmente instrumentar melhor o código-fonte para ter mais saídas de debug do que as tradicionalmente disponíveis, para ter mais subsídios e aprofundar no problema.

Em um mundo ideal, migre sempre para Modbus TCP! ;-)

 

Por favor poste aqui se funcionar, para manter a informação fluindo...

bom trabalho!

 


#3
 
 
1 - Mesmo com esta mensagem aparecendo, o valor lido está correto ou não? 
 
  R.Não apresenta o valor no Watch list somente esta mensagem e um símbolo de carregando
 
 
2 - Você tem apenas este datapoint cadastrado, ou vários datapoints no mesmo datasource modbus?
  R. somente este..
   Mesmo alterando para outros dispositivos eu criava a comunicação separada; ou seja um Data source e um DAta point   para casa instrumento.
 
 
3 - Existe apenas este slave cadastrado na rede?
 
   R.sim estou ligando um equipamento por vez
 
 
4 - Vc pode experimentar algumas variações do seu teste
 
   R.Fiz todas, mas sem sucessp
 
 
OBS: apenas lembrando que do computador sai um cabo USB   para o conversor USB- 485 e este esta conectado no CONTROLADOR.
 
obrigado
 

#4

Olá!

No meu caso, mudei, no Data Source, "Período de atualização" de 1s para 500ms.Saiu a mensagem.

 

Usando TCP/iP


#5

Boa tarde Paulo, tudo bem ?

Tive esse problema utilizando o Windows XP na versão do ScadaBR 1.0, tentei exatamente tudo o que foi recomendado e nada resolveu, a solução que obtive exito foi realizar um dowgrade do ScadaBR para a versão 0.9.1 e utilizei o JRE6U45 ( Baixar no site da Oracle ), a partir dai o sistema funcionou sem grandes problemas.

Outro erro que acontecia no meu caso era que lendo os ponto individuais no datasource, quando eu salvava os pontos e habilitava o datasource aparecia um " erro interno no servidor ", depois disso, so aparecia esta mesmo mensagem na WatchList.

Eu, particularmente, recomendaria testar essa solução, se rodar com o SBR 0.9.1, acredito que temos um BUG no Modbus Serial do SBR 1.0.

 


#6

Boa noite Martine,
Não sei se ainda está em aberto esse tópico, porém, estou com um problema ao acessar um plc da atos, o expert dx, por modbus serial. Estou tendo o mesmo erro… “valor do ponto pode não ser confiável”, ao ler o dado pela leitura de dados modbus e pelo teste de localizador de ponto, consigo efetuar a leitura de forma correta, porém, ao adicionar o ponto e ir para watch list, o ponto aparece com essa mensagem. Já tentei tudo o que foi informado aqui pelo forum por vocês. Você ou alguem daqui poderia me ajudar?
No momento estou utilizando o scadabr 1.0 com java jre6u45, ja tendo tentado com a versão 0.9 e 0.9.1 do scadabr, sem obter sucesso.
Espero que possam me auxiliar!

Desde já agradeço.


#7

Bom dia !! Esta aberto sim !!

Ao que parece e mais problema com a porta do PC do que o SBR em si, mas vamos por partes:

1 - Voce adicionou o datapoint e ativou o mesmo ?

2 - Salvou o Datasource ?

3 - Clica em datasource no menu do SBR e verifica se o icone do datasource que voce criou está verde, se não, habilite ele.

4 - Verifique na Watchlist agora

Outro ponto importantíssimo, qual é o tipo de dado que você esta lendo ? binário, word, INT ? é necessário estar bem configurado no datapoint se não na watchlist pode dar esse erro.

Qualquer duvida, chama ae !!

Saudações


#8

Boa tarde!

Segui todos os passos que você me falou e consegui efetuar a leitura dos dados, porém, continua a aparecer a mensagem “valor do ponto pode não ser confiável” para alguns casos. Isso tá acontecendo para clp’s que ficam mais distantes, em que a comunicação é feita por rádio modem ou em um caso que temos um cabo de uns 200m para comunicação via RS485. Temos, hoje, instalado o supervisório Elipse “rodando” nesta mesma situação, estamos migrando do Elipse para o ScadaBR, acontece que no Elipse, nesses pontos informados, o supervisório consegue efetuar a leitura dos dados sem maiores problemas, sem erros, estamos utilizando o mesmo computador, mesmo cabo USB/SERIAL e mesmos clp’s para comunicação, só estou mudando de um supervisório para o outro. Preciso muito fazer o ScadaBR funcionar de forma correta, sem erros e com um período de atualização aceitavel, que faça com que não deixemos de verificar qualquer alteração no sistema.
Como você havia falo… Será se pode ser problema da porta USB do PC? eu, descartei essa possibilidade porquê o Elipse consegue ler as informações sem problemas.

Desde já agradeço pela ajuda!


#9

Sanmir_Reis,

acho muito importante fixarmos nossa atenção nesse ponto.
Se funciona em um… tem que funcionar no outro. Mas veja que o próprio software pode ter algum sistema de consolidação dos dados.

Nesse caso, acho importante olhar detalhes da comunicação RS485.


#10

Olá, bao noite Farmsid!

É justamente o fato de está funcionado, conseguindo ler todos os dados em um sistema, e não está conseguindo o mesmo com outro supervisório, que tá me deixando um tanto sem entender o que deva tá acontecendo.

Você acha que o problema possa está na comunicação RS485?

Att.
Sanmir.


#11

Sanmir_Reis,

eu tenho as minhas dúvidas. Não acredito bem que o problema está no RS485/MODBUS.
Como você disse, tudo é o mesmo. Mas veja: posso ter um sistema de checagem no elipse que não está configurado no ScadaBr.
Vamos investigando. Eu estou curioso também.


#12

Sanmir,

Você esta com os dois suérvisorios rodando no mesmo PC ao mesmo tempo ?

Se for isso você esta com conflito nos server, por que ambos vão tentar acessar a mesma porta fisica.

Faça o seguinte teste, desative o Elipse, se no caso for o E3, clique no server e feche o servidor, depois reinicie o Tomcat e teste novamente no ScadaBR.

Para rodar simultaneamente nos dois server você ( Elipse e SBR ) so conseguira se utilizar um outro software chamado OPC server, o qual para modbus so existe um gratuito no site integrationobjects ( procure no google, facil de achar ), porem configurar um OPC server no SBR, sinceramente e muito chato, mas funciona bem.

Se a ideia e substituir o Elipse ( Coisa que eu ja fiz em pelo menos em 30 clientes ), desabilite o Elipse e reinicie o Tomcat, acredito que seja isso o problema, pois portas seriais so podem ser acessadas por um unico programa por vez.

Qualquer duvida estou a disposição,

Saudações,


#13

Farmsid,

Estou verificando cada configuração dos dois sistemas e comparando. Coloquei o período de atualização para 5 segundos com timeout de 400ms e tentativa igual a 10. Só assim consegui ler os dados, mas, mesmo assim de tempos em tempos a mensagem “valor do ponto pode não ser confiável” aparece!
Teria uma configuração mais especifica para esses parametros ou só fazendo o que eu fiz hoje? Sair testando e acompanhando as respostas.

Att.
Sanmir


#14

Boa noite Martine,

Tive esse problema no inicio e foi onde desinstalei e reinstalei por varias vezes o SCADABR sem saber onde estava o erro e pensado ser no software. Porem, era o fato de tá utilizando o SCADABR junto com o Elipse ou até mesmo lendo os dados com o data source ativo. Agora, toda vez que vou rodar um ou outro, finalizo os serviços de cada e habilito somente do que irei utilizar.
Eu consigo ler os dados, porem, com uma inconstancia muito grande. Às vezes lê e às vezes não lê.

Não fugindo desse assunto… mas, são tantas perguntas com relação ao SCADABR… já li o manual e venho lendo muito aqui pelo forum.
Consigo “medir” Nível de reservatório e pressao da rede que tem como clp uma Brio da schneider?
Digo uma fórmula que eu faça isso diretamente pelo SCADABR sem ter que passar por outro clp e fazer em ladder?
Dito que os medidores são de 4ma a 20ma. Desse eu consigo lê os dados, só queria saber se tem como transformar os dados em “numeros” m³ ou % e bar
Seria possivel?

Estarei fazendo testes na comunicação alterando os valores de (periodo de atualização, timeout e tentativa), foi alterando esses campos que consegui lê alguns dados.

Att.
Sanmir

Pessoal, desde já agradeço pela ajuda que estou recebendo de todos vocês!


#15

Sanmir_Reis,

tranquilo que dá para ler. O CLP deve ter uma entrada analógica com um AD, portanto já sai um número.
Mas ainda tenho curiosidade quanto à comunicação. Precisamos descer mais fundo no entendimento da comunicação.
Quanto mais descrever seu sistema, com detalhes da instalação, mas é possível descobrir o que pode estar acontecendo.
Quando eu usava o SBR com um arduino com bibliotecas diferentes tinha resultado diferente.

Vamos discutindo.


#16

Bom dia Farmsid!

Irei descrever minha rede;

Servidor com ScadaBR instalado, porém, com Elipse, ainda rodando, conectado a um conversor RS232/RS485. Na 485 tenho ligado dois CLPs Expert DX com cabos de mais ou menos uns 70m de distância cada. No CLP 1 tenho 20ED (bomba ligada, válvula com defeito, soft start com defeito…) 4SD (ligar e desligar bombas) e 3EA (pressão e nível), na 485 do CLP 1 temos um multimedidor e um medidor de vazão ligados. No CLP 2 tenho 10ED (bomba ligada, válvula com defeito, soft start com defeito…), 2SD (ligar e desligar bombas) e 1EA (pressão), na 485 do CLP 2 temos um multimedidor e um rádio modem que tá conectado com outros dois CLPs. No CLP 3 - BRIO - tenho 1EA (nível), na 485 do CLP 3 temos o rádio modem. No CLP 4 tenho 10ED (bomba ligada, defeito soft start, defeito válvula…), 2SD (ligar e desligar bombas), 2EA (nível e pressão), na 485 do CLP 4 temos dois rádios modem, um multimedidor e um medidor de vazão. No CLP 5 temos a mesma configuração do CLP 4, porém sem os rádios esse é o último ponto, último CLP.
O meu problema com o ScadaBR, está em obter os dados dos CLPs mais distantes, porém, com o Elipse consigo lê esses dados. Ontem, resolvi dividir as entradas e saídas, digitais e analógicas em data source diferentes, porém, o resultado obtido foi pior, ao habilitar todos os datas source, 5 ao todo, alguns data point foram lidos e outros não, pelo que percebi, dependia da configuração do período de atualização, do timeout e da tentativa configuradas, a medida que eu ia alterando os valores o data source começa a ler os dados. Desculpa a falta de conhecimento, porem, como é um contato recente com o SCADABR, estou passando por alguns erros e acertos e nesse ponto, descobri que só posso ter um único data source rodando, habilitado por vez. O erro que está acontecendo ao habilitar o data source com todos os data points é: Exceção do modbus master: Function code: 0x7f

Mais uma vez agradeço pela ajuda de vocês!
Não sei o que possa tá acontecendo!

Att.
Sanmir Reis.


#17

Boa noite Farmsid!

Estive analisando varias postagens aqui no fórum, fazendo uma pesquisa muito intensa para deixar o supervisório rodando perfeitamente. Porem, tenho me deparado com alguns erros e problemas que até o momento não estou conseguindo contornar. Estou conseguindo toda a comunicação para dados de CLPs mais próximos, os mais distantes que levam um pouco de tempo a mais para “responder” não estou conseguindo obter uma resposta de forma confiável, aceitável. Posso está errando em alguma coisa, alguma configuração incorreta… Preciso muito da ajuda de todos vocês no que puderem.
Me deparei hoje, com esse tópico: Módulo comunicação Modbus serial com bug
onde fala sobre a inconstância da leitura/escrita de dados e remotas/escravos através do SCADABR!
minha pergunta é a seguinte:
Vocês sabem informar se esses problemas citados acima foram sanados? Qual a versão estável que eu poderia tá utilizando sem maiores problemas? Uma versão confiável.
Após concluído o projeto terá ao todo 1 elevatória com 1 CLP (20ED, 12SD e 4EA), 2 conjuntos motor bomba, cada um com (comandos de ligar/desligar, defeito na soft start, defeito válvula, defeito na bomba, emergência, local/remoto, bomba ligada/desligada), 1 Multimedidor, 1 Sensor de Nível, 2 Medidores de Vazão e 2 Medidores de Pressão. Teremos mais 1 CLP (10ED, 2SD, 1EA), 1 conjunto motor bomba com as mesmas funções do CLP 1 ligado ao CLP 1 pela rede 485 (Conversor 232/485) para termos acesso pelo supervisório. Temos mais 2 CLPs com a mesma configuração do CLP 1, porem, está bem distante, sendo interligado por rádio modem. Temos também, mais 3 reservatórios todos interligados por rádio modem e com CLP BRIO, medindo somente nível.
Como já havia falo aqui, o software tá comunicando, com alguns erros, aos CLPs, está trazendo informações “não precisas”, demoradas e por muitas vezes sem repostas, sem atualização por mais de 5… 6 minutos ou até mesmo sem conseguir atualizar.
Peço ajuda de vocês para saber se dá pra fazer esse sistema exposto aqui, rodar no SCADABR sem maiores problemas?!

O erro que está acontecendo ao habilitar o data source com todos os data points é: Exceção do modbus master: Function code: 0x7f

Att.
Sanmir Reis.


#18

Conseguiram descobrir a solução do erro?


#19

Em 2019 e esse erro ainda persiste comigo também, já fiz de tudo até trocar de PC porém o erro continua. Alguém já achou a solução.


#20

Boa noite
Sou novato no assunto e como esse fórum me ajuda muito, vou deixar minha contribuição sobre esse assunto. No meu caso estava com mesmo problema apresentado e quando colocava para rodar, no Watch List também apresentava o erro: Valor do ponto pode no ser confiável. Fiz de tudo que o pessoal sugeriu e nada. Somente consegui contornar utilizando um emulador de porta virtual (VSPE) , onde eu criei um TCP SERVER com endereço localhost e porta do 502 e direcionei pra entrada serial Com1 do pc, na qual utilizo com conversor para RS-485 que esta ligado ao Multimedidor de grandezas. No Scadabr criei um datapoint modbus ip (marcar encapsulado).
Não sei qual problema para o Scadabr não esta conseguindo ler, tentei com outro supervisorio e leu. Bom essa foi a minha solução após quebra muito a cabeça e conseguir continuar com os estudos.