arduino, eletrônica, robotica...
scadabr
Alguém conhece o scadabr e sabe como usa-lo, caso conheça por favor entre em contato pois preciso de algumas informações.
Uma delas é o protocolo modbus pois queria saber como comunicar um sensor,atuador,etc como o supervisor por meio de um microcontrolador ou coisa paracida, me parece que para poder acionar ou receber informações o supervisorio precisa de um clp (que é caro) ou por um microcontrolador?
se alguém tiver informações sobre como usar e implementar ou pelo menos mostrar o caminho das pedras já agradeço.
adriano
Respostas a este tópico
-
Permalink Responder até Eduardo Romariz Duarte em
-
Marcos já testei com 485 e funciona perfeitamente, porém precisa tomar cuidado com algumas configurações (se montou o conversor ou se usa algum comprado). Se o cabo for muito longo tb precisa usar um resistor de 120R (dependendo da impedância do cabo) nas extremidades da rede para melhorar a comunicação e manter a rede funcionando com menor quantidade de erros possíveis. Estou fazendo um shield que fará interface com o RS485, isolação optica e adequação dos padrões de tensão comando/arduino (para o caso de entradas digitais) e ainda dois relês para comando. Vou apresentar ao pessoal do lab pra entrar como recurso para desenvolvedores futuros do pessoal.Pessoalmente acredito que o timeout da lib (jpzometa) pode ser problema para uso de comandos diretos, pois como bem citou em seu tutorial caso a rede apresente erros, suas saidas serão zeradas, logo deve observar se este detalhe não trará impactos para seu processo!
Vou tentar arrumar um tempo pra tirar umas fotos aqui tb e postar aqui pra vcs tb!
Até
Eduardo
-
Permalink Responder até Wiechert em
-
Eduardo, que legal que funcionou por ai, voce podia postar o esquema do conversor que voce usa pra mim, não precisa ter isolamento óptico só preciso do básico mesmo.
Realmente no sketch as saídas são zeradas após 10 segundos do link parado, o que pode ser bom ou mau, depende do grau de independência desejada para o escravo remoto.
Existem situações em que o escravo deve funcionar independentemente da existência da conexão com o SCADA, cada desenvolvedor deve saber oque se adapta melhor a sua aplicação e deletar ou não o comando de desligamento das saídas.
De qualquer forma, o mais importante é entender como o skecth funciona, pricipalmente a parte da matriz (tabela) onde são armazenados os registradores com os dados que deverão ser trocados entre o escravo e o SCADA .
No mais é adaptar a lógica da função loop de forma a atender as aplicações de cada processo.
Obrigado.
-
-
Certo Marcos! Essa questão é individual de cada projeto com certeza... mas em comparação ao PLCs usaria a tabela de registros de acionamento separada no caso de aplicações de comando.
Para o 485, se não tiver USB no mestre (o que na minha opnião é melhor), é muito simples...
Veja em...
http://dereenigne.org/electronics/arduino/arduino-modbus-rtu-adc
Detalhe: Não use a serial FTDI do arduino quando estiver usando o 485 nos pinos TX e RX.
Boa sorte
Eduardo Duarte
-
-
Obrigado Eduardo, vou montar o circuito como no tutorial.
O MODBUS foi um protocolo originalmente pensado para uso com clp's sem dúvida, e a biblioteca em questão não implementa totalmente o protocolo, apenas as funções de comandos para lidar com os holding registers (comandos 3, 6 e 16) que a princípio eram usadas para comandar as saídas analógicas e memórias auxiliares, mas ainda assim é possível fazer praticamente tudo.
Mas para seguir o protocolo a risca seria necessário implementar as rotinas para tratamentos dos outros comandos de input discrete, coils e input registers. Coisa que não é muito difícil de se fazer, poderíamos até fazer isso aqui no blog e acrescentar as modificações na biblioteca.
Quando se trata de uma "remota", isto é uma unidade que apenas fornece alguma leitura de entradas discretas ou sensores e aciona saídas concordo que o melhor é usar a tabela dos registros de entradas e a tabela de registros de saídas.
Já para controladores que funcionam em modo "stand alone", pode ser ser melhor usar apenas os holding registers como memórias auxiliares e o programa do arduino ler essas memórias e executar os comandos. Aliás isto é o mais comum quando se trata de sistemas SCADA supervisionando CLP's.
Esse assunto é mesmo um tanto polêmico. pois o próprio protocolo deixa abertura para implementações usando as duas linhas de pensamento.
Cabe ao desenvolvedor como sempre escolher o que é mais adequado para o projeto em questão.
Valeu e obriigado pela dica.
-
Permalink Responder até Thiago Pereira Passos em
-
marcos tudo bom? tenho uma duvida de pricipiante. na parte digital do arduino eu so transmito ou recebo tb valor digital?? E na parte analogica eu posso receber e transmitir??
-
-
Olá Thiago,
Deixa ver se eu entendi bem a pergunta, no sketch estamos usando registros do tipo holding registers que são na verdade apenas uma tabela de memórias agrupadas e a princípio tanto o escravo quanto o scada podem ler e escrever nesses registradores.
A questão é que dependendo de como usamos um determinado registro apenas um dos dois deve escrever e o outro apenas ler.
Vou tentar esplicar:
Imagine que o registro MB_0 será usado para armazenar o valor da entrada analógica 0 onde temos um sensor que indica a temperatura de uma sala. Pois bem o programa do arduino deverá fazer periodicamente a leitura do sensor e os devidos tratamentos de valores e salvar o resultado no registro MB_0. O scada por sua vez fará a solicitação da leitura do valor do regsitro MB_0 e de posse do resultado exibir o mesmo na tela de representação gráfica ou no watch list e em todos os eventos em que resolvermos usar este registrono scada. Acontece então que neste caso não tem sentido o scada escrever um valor neste registro, pois é um resgistro de "entrada" e o valor que o scada escrever será apagado na próxima atualização. O mesmo raciocínio deve ser usado para um registro que represente uma entrada digital. Os registros que representam saídas digitais devem a grosso modo ser escritos pelo scada e lidos pelo arduino. Registros que representam variaveis como por exemplo o set-point de temperatura desejada em um ar condicionado podem as vezes serem ajustadas via scada (remoto) ou localmente por meio de um teclado e display LCD, sendo um caso típico de registro onde tanto o arduino quanto o scada lêem e escrevem o mesmo registro.
Por fim, todos os registros podem ser lidos tanto pelo arduino se o programa assim o fizer quanto pelo scada e cabe ao desenvolvedor ter a certeza de quem feve escrever oque e aonde. Para o scada poder alterar o valor de um registro devemos marcar a caixa "Configurável" na tela de "Detalhes do data point" caso essa caixa não estiver marcada o registro pode apenas ser lido pelo scada.
Beleza?
-
-
muito obrigado pela atenção marcos. pq eu perguntei isso. Eu e um grupo de amigos (4 no total) estamos com um projeto como foi dito aqui no forum que é eu term um banco de dados em graficos de sensores de temperatura, sensores de pressão, de vazão, carga de motores, vibração, presostatos entre outros. o scadabr vai fazer a função de me informar, visualizar e registrar isso pra mim. a principio o arduino não vai atuar nada so vai receber e passar para o scadabr (tipo uma manutenção preditiva). preciso de informações de sinal digital (liga/desliga) e analogicos(variavel) para controlar e atacar em alguns pontos da maquina que eu tenha que ter uma atenção maior. sou novato no assunto mais eu peguei o teu tutorial e ja coloquei no arduino e ja fiz algumas simulacoes(so a da porta 13 digital srsrsr) e funcionou perfeitamente. muito obrigado por ta me ajudando nisso e parabens pelo grande conhecimento que vc tem.
valeu!!!
-
-
-
Blz Boa sorte!
Observe a importante alteração:
const char TXENPIN = 2; /* output driver enable pin */
Boa idéia implementar mais funções! Seria um trabalho interessante e deixaríamos o fonte
de acordo com o padrão o que de fato não é!!
At,
Eduardo
-
-
Cara se ajuda a informação estou usando um conversor 485/232 (flexMedia) no PC com ScadaBR, tive pésimas experiências com cabos conversores USB/Serial, e confirmei que estes conversores podem causar muitos erros de timeout dependendo de sua qualidade.
Minhas melhores experiências são com conversores baseados no próprio FTDI.... tenho alguns xing-lings aqui que são problema na certa!!... Portanto se estiver usando atenção!
Do lado do escravo estou usando os Max485... até agora sem problemas.
Faça testes e homologação de seu ambiente de rede ModBus usando o Modbus Poll ou o ModScan... estando ok é só botar o ScadaBR no ar.
At.
Eduardo
-
Permalink Responder até Sidney Alves Bastos em
-
Gente,
estou tão satisfeito que passei para a próxima fase. Queria que nosso amigo Adriano estivesse aqui. Ele também foi um desbravador.
Continuando. Agora tenho 2 arduinos:
o primeiro faz um controle de temperatura, de forma independente, de uma sala. Quando a temperatura atinde determinado valor ele liga um exaustor e liga um alarme sonoro. O ambiente que está instalado possui especificação rígida. Não pode passar de 30 graus. E existe até um procedimento para a atuação no caso de superar este valor. A princípio por questoes de custo não se condicionou o ambiente. O que ficou claro até agora é que uma circulação de ar já seria o suficiente para diminuir a temperatura. O problema é causado pelo telhado de fibrocimento. Foi a matriz de risco do processo que mostrou a importancia deste parâmetro e da atitude de ligar o exaustor. Tal tarefa foi perfeita para o arduino. Mas neste ambiente existia termômetros pendurados e 2 x ao dia um operador deveria verificar a temperatura e se encontrasse um desvio deveria tomar a atitude.
Com a iniciativa podemos validar o processo de monitoramento e garantir, com uma alta probabilidade, que o processo estará sobre controle.
A segunda parte é a presença de umidade e luz. Determinados processos não toleram a umidade e a luz pode prejudicá-los. A filosofia foi a mesma. O arduino liga um desumidificador e controla a intensidade de luz artificial.
O Scadabr veio então para registrar o controle dos parâmetros, produzindo registros e informando ao controle central deste desvio e chamando a atenção para ações corretivas.
Então quero concluir com os ultimos posts que algumas atitudes não podem sofrer influencia do scada e somente monitorá-los e deixar os nossos arduininhos trabalharem sozinhos.
Agora será a hora de começarmos a trabalhar com a modelagem dos dados e a atuanção. Surgirão mais dúvidas e tenhos certeza que traçaremos todas elas.
Parebens equipe Labdegaragem.
-
Permalink Responder até adriano de alcantara em
-
Caros amigos do lab Garagem,
Estou muito contente com trabalho desenvolvido por nós, provamos que somos profissionais e superamos desafios bem dificies, se eu tivesse em uma empresa formada por vcs seria um sucesso concerteza.Eu confesso que travei na programação do modbus, pois meus códigos até hoje estão bugados, (eu ainda não li o material do Marcos), Agradeço a todos, em especial para o Marcos que deu uma guinada na resolução dos códigos modbus, ao Sidney um prático de carterinha, ao Senhor Enio que nos deu todo o Know how sobre RS485, ao Eduardo que nos deu as direções pra melhor desenvolver o projeto. Lembrando que isso é uma Etapa e que agora teremos varias outras. O objetivo desse posts é criar algum como a saber eletrônica, só que especifico nas integrações com sistemas scadas open source, por isso toda a documentação do que foi feito seria bom, assim que eu entender melhor esse código (terrível) do modbus e fazer alguns testes começarei a documentar, Esse é o meu projeto de vida, logo não para por aqui, convido a todos que querem desenvolver o que posso chamar de Linux da automação (o scadabr), para desenvolvermos juntos,Lembrando que qualquer um pode desenvolver com o conhecimento do nosso post uma solução de Scadabr e vende-lo como um produto seu, pelo menos foi o que eu li no Scadabr, é sempre bom fazer uma referencia aos desenvolvedores(questão de educação).
-
-
É isso ai Adriano, Sidney e cia,
Acho que daqui um tempo vamos poder transformar essa discussão em um blog tutorial e talvez alguns webnars. Falta compilar todo o material distribuido e comentado na discussão em tópicos ordenados por categoria, tipo introdução, principios de modbus, descrição da biblioteca, como alterar o sketch conforme as necessidades, rede rs485, introdução ao scada, configuração de data source, telas gráficas, etc...
Realmente é um projeto de vida... ou um projeto pra vida toda rsrsrsrsrs....
Abraços
Bem-vindo a
Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)
© 2024 Criado por Marcelo Rodrigues.
Ativado por
