Primeiramente, saudações e parabéns pelo fantástico software disponibilizado ao público!
Já faz dois meses que estou interagindo e analisando o software ScadaBR, realizando comunicação com dois equipamentos que tenho disponíveis para testes, que são um CLP TRI-PLC e o Arduino UNO. Coloquei ambos para comunicar como escravos com o ScadaBR como Mestre. Escolhi o módulo (datasource) Modbus para comunicar com ambos. Tive sucesso, no início comecei com dificuldades e dúvidas que foram sendo sanadas à medida que apareceram os problemas (consultei exaustivamente os foruns do ScadaBR e do Mango).
Minha intenção inicial para os meus ensaios consistiram no seguinte: realização de comunicação de leitura e escrita de bit e byte. Ou seja, o mestre lê bits e bytes do escravo, e o mestre escreve bits e bytes no escravo. Com o CLP foi possível realizar a todas as operações pretendidas para os meus ensaios, já com o arduino fui obrigado a realizar somente leitura e escritas de bytes, pois operações somente com bits não são suportadas pelo software do arduino (o pessoal do arduino deu um jeito de transmitir os bits dentro dos bytes, realizando somente as operações 3 e 16 da especificação modbus).
Gostaria de utilizar o ScadaBR para realizar a construção de sistemas automáticos com repetibilidade e confiabilidade para residências e pequenas máquinas.
O que me surpreendeu foi que... o sofware desenvolvido pela Mango M2M, com anos de existência, não possui repetibilidade e confiabilidade na comunicação modbus deste sistema. Desconfio, por tudo que li nos foruns do Mango e também do ScadaBR, que existem bugs surgidos na integração do conjunto. Percebi que, mesmo usuários experientes não conseguem extrair a performance desejada do sistema para a operação do protocolo Modbus Serial do ScadaBR .
Quero deixar claro que não se trata de críticas a quem está há anos trabalhando no desenvolvimento do sistema, apenas constato o óbvio que se observa nos fóruns de ambos os softwares. Acho também que a comunidade tem que agradecer todo esse esforço e todo esse trabalho realizado por programadores durante muito tempo, sem exigir nenhuma retribuição e colocando um excelente produto de software de graça ao alcance de muitas pessoas que de outra forma não teriam acesso ao mesmo.
Agora, do que se trata aqui é que tem bugs no software que diz respeito ao interfaceamento da coleta de dados e seu manejo ao módulo de comunicação modbus4j.
A comunicação funciona perfeitamente enquanto é realizada a leitura de dados do escravo (período de atualização), que é uma operação de rotina do mestre. Tanto a requisição de dados (mestre) quanto a resposta (escravo) funcionam perfeitamente, enquanto não houver evento que perturbe o tráfego de dados.
A escrita de dados do mestre para o escravo também transcorre normalmente, enquanto esta for realizada FORA da rotina de troca de dados do "período de atualização", ou seja, enquanto a linha estiver sem tráfego de dados. O mestre consegue escrever os dados no escravo sem problema.
Mas os problemas aparecem quando há sobreposição de operações. O alarme de erro de comunicação do módulo modbus4j, e consequentemente do sistema todo, acontece de forma consistente mediante a execução do seguinte cenário:
Na minha aplicação do ScadaBR, inseri na interface gráfica um botão de LIGA/DESLIGA (datapoint de escrita), que deve atuar num bit do escravo. Igualmente inseri um datapoint de escrita que é um registrador holding que deve ter seu valor numérico entrado via teclado.
Tenho igualmente dois outros datapoints de leitura, que são "pollados"/lidos durante a atualização.
Quando o botão LIGA/DESLIGA é acionado, ou
quando um valor é entrado através do ENTER no registrador holding,
ENQUANTO é realizada a "atualização" ou troca de dados periódica (leitura do escravo), DISPARA o alarme de erro de comunicação modbus.
A atualização ou "polling" acontece muito rapidamente, dependendo do baudrate (bps) e do "periodo de atualização", mas quem usa o datasource modbus serial percebe que existe COLISÃO de dados entre os dados coletados da interface gráfica (escrita) e as operações de "polling" (leitura)ocasionalmente. RESULTADO: o alarme de comunicação.
Uma forma fácil de constatar isso é dar um "periodo de atualização" de 5 segundos e enviar / clicar o botão de escrita (poucas vezes) entre as operações de troca de dados de leitura, durante os intervalos grandes: dificilmente acontece colisão. Agora dá um "periodo de atualização" de 100 ou 200 milissegundos, e começa clicar o botão de escrita(com muita frequência): não demora a aparecerem as colisões e os alarmes. Eu tive a sorte de conseguir enxergar os pacotes de dados passando pela minha interface RS485 através dos leds de comunicação, e perceber como tudo isso acontece.
SUGESTÃO
Minha sugestão de solução é para os desenvolvedores criarem um serviço de interrupção (interrupt) para os datasources modbus seriais para cada escravo( ID1, ID2,... IDn), quando forem feitas as "atualizações" ou operações de troca de dados de leitura respectivas.
Por exemplo, durante a troca de dados do IDn (ou seja, quando uma atualização ou operação de leitura ocorrer), uma interrupção INT_IDn será acionada, e qualquer operação de escrita para aquele escravo DURANTE o periodo de atualização será armazenada num buffer. Quando finalizarem as operações de comunicação entre mestre e escravo para aquele ID, e que a INT_IDn seja liberada pelo mestre, o conteudo do buffer será disponibilizado para a execução respectiva.
Melhor ainda: operações de leitura deverão ser sinalizadas por interrupção. Verificando a existência de interrupções, toda operação de escrita para um determinado escravo deverá ser gerenciada pelo software internamente, armazenada em buffer e liberada quando não houver outras operações acontecendo (quando não houver interrupções acionadas).
Abraços,
Rafael