Configurações Portas Mestre/Escravo

De Wikiplenix
Ir para: navegação, pesquisa

Tabela de conteúdo


É possível configurar em detalhe o que a plataforma vai fazer quando um equipamento ou rede se conecta a ela. Tanto as portas Escravas quanto as portas Mestres podem ser configuradas para atenderem as necessidades específicas de cada equipamento ou rede.

Estas configurações segue o formato "ini": trata-se de uma série de pares chave=valor separados por seções demarcadas por títulos entre colchetes. Chaves e seções inválidas são ignoradas.

As configurações gerais são definidas no início, antes de qualquer seção. E quando existirem múltiplas configurações, estas terão as suas próprias sessões.

Configurações gerais

Em princípio não é necessário existir qualquer configuração para que a porta tenha um comportamento padrão.


O comportamento padrão de uma porta Escrava é estabelecer a conexão com o equipamento ou rede e esperar que alguma porta Mestre que esteja ligada a ela receba uma conexão. A partir disso os comandos fluem entre a porta Mestre e a porta Escrava. Este comportamento é chamado de "switchboard", pois permite que mais de uma porta Mestre esteja ligada a porta Escrava e as comunicações delas são chaveadas de forma que os dados não se misturem.

Já o comportamento padrão de uma porta mestre é conectar-se a porta escrava na qual está ligada e passar todos os dados que receber para ela, e retornar as respostas vindas para quem se conectou.


As portas escravas e as portas mestres podem ter outros tipos de comportamentos que determinam a forma como os dados recebidos por elas são tratados. Estes devem ser especificados nas configurações. O atributo "plugin" que em versões anteriores da plataforma se chamava "format" é responsável por determinar o comportamento de cada porta.


As chaves que podem estar presentes na configuração geral são as seguintes:


plugin

Indica o comportamento que a porta deve ter quando for estabelecida uma conexão com ela. Existem várias possibilidades que serão descritas abaixo, e para cada uma existem configurações específicas:

Valores possíveis para "plugin" em Portas Escravas

Os "plugin"s a seguir estão disponíveis apenas para portas Escravas.


E pode ser especificado um "Mestre Interno", um agente da plataforma que estará também ligado a esta porta Escrava e que terá comportamentos configuráveis como:
E pode ser especificado um "Mestre Interno", um agente da plataforma que estará também ligado a esta porta Escrava e que terá comportamentos configuráveis como:


O comportamento "default" é atuar como "switchboard".


Valores possíveis para "plugin" em Portas Mestre

Os "plugin"s a seguir estão disponíveis apenas para portas Escravas.



config_refresh_frequency

Estas configurações são lidas pela plataforma no momento em que o equipamento ou rede estabelece a conexão com a plataforma através da porta Escrava, ou porta Mestre. Estas configurações são re-lidas pela plataforma enquanto a conexão permanece estabelecida. Este comportamento permite fazer alterações nas configurações sem que seja necessário desconectar o equipamento ou rede da plataforma. A chave "config_refresh_frequency" especifica qual a frequência em que o Gateway relê estas configurações. O tempo de re-leitura deve ser especificado em segundos, sendo que o menor tempo possível é de 60 segundos, e o maior é de 300 segundos que equivalem a 5 minutos. Se for colocado qualquer valor fora destes limites eles serão ajustados para estarem dentro dos limites.

Se a chave não estiver presente, o padrão é de 300 segundos.


connection_timeout

Disponível para especificar qual o tempo máximo em segundos que o equipamento conectado pode ficar sem enviar dados para a plataforma. Muito útil para conexões que usam GPRS como meio de transporte. A tecnologia GPRS pode deixar conexões "zumbis", que parecem vivas para a plataforma e para o equipamento, mas que na verdade não levam os dados de um lado ao outro. Ou seja, os dados enviados pelo equipamento não chegam na plataforma. Por isso controlar o tempo de inatividade é importante. Alguns modems possuem mecanismos que para manter a conexão GPRS ativa, para isso eles enviam com determinada frequencia uma mensagem de "keep-alive", ou eles também podem ter configurado com um tempo máximo de inatividade que os faça reconectar. Para estes casos o valor do "connection_timeout" deve ser um pouco superior ao tempo de envio de um "keep-alive", ou de re-conexão do modem.

É possível também especificar que não deve ser controlada a inatividade da conexão. Esta configuração é útil quando o meio usado é mais confiável como redes locais e broadband. Para isso basta colocar 0 (zero) como o valor da chave "connection_timeout".

Se a chave não for especificada o tempo de inatividade é de 600 segundos que equivalem a 10 minutos.


Exemplos

Exemplo "rawdata"

Tratamento "rawdata". As configurações serão re-lidas a cada 10 minutos, e esta porta mantém a conexão ativa por até 5 minutos sem qualquer tráfego de dados vindo do equipamento ou rede de equipamentos.

plugin=rawdata
config_refresh_frequency=600
connection_timeout=300

[rawdata]
timeout=20


Exemplo "master"

Portas Mestre tem com padrão o "plugin=mastar", portanto este não precisa estar declarado. A re-leitura das configurações será feita a cada 5 minutos, e o tempo máximo que a conexão será mantida se não houver tráfego será de 200 segundos.

config_refresh_frequency=300
connection_timeout=200

Configurações específicas

Cada um dos "plugin"s, tem as suas próprias configurações.


rawdata

O comportamento especificado por "rawdata" é a mais simples de todos. Na verdade a plataforma simplesmente recebe os dados vindos do equipamento ou rede conectado a porta Escrava, coloca todos estes dados em arquivos e armazena na plataforma. Estes arquivos de dados estarão acessíveis a partir da interface web do site Iplenix.

timeout

É a única configuração necessária para este comportamento. O tempo em segundos que a plataforma deve esperar sem receber dados do equipamento ou rede para decidir que encerrou este envio, e dai gerar o arquivo e armazenar. Por exemplo, se for especificado o valor 20 para a chave "timeout", a plataforma esperará 20 segundos desde o recebimento do último byte para decidir que foi encerrada a transmissão, e dai armazenar todos os dados recebidos até agora em um arquivo.

Quando esta chave não estiver especificada, o tempo esperado será de 20 segundos.


Exemplo "rawdata"

Neste exemplo a plataforma ficará esperando por dados vindos do equipamento ou rede conectado a esta porta Escrava. A chave "timeout" com o valor de 20 determina que uma vez enviado algum dado, a plataforma espera por 20 segundos para determinar que este pacote de dados foi terminado. E os dados recebidos até ai serão armazenados como um arquivo acessível através da interface web do site Iplenix.

plugin=rawdata
config_refresh_frequency=600
connection_timeout=300

[rawdata]
timeout=20


modbus_rtu

Na terminologia do Modbus-RTU, em uma conexão há um "mestre" que envia comandos Modbus para dispositivos "escravos". Para evitar confusão com o suporte mestre-escravo do Iplenix Plug, chamaremos estes de "mestre Modbus" (o código rodando no Pecon) e "escravos Modbus" (os dispositivos).

O Pecon recebe como parâmetro no arquivo de configuração os nomes dos dispositivos escravos Modbus. Cada um destes por sua vez define uma seção com seu nome no arquivo de configuração. Nesta seção é definido um identificador, uma lista de nomes de comandos, a frequência com que os comandos são executados e o tempo de resposta máximo para execução dos comandos.

Cada comando por sua vez tem uma seção que leva seu nome. Essa seção conterá a pergunta Modbus que será executada, uma lista numerada de sensores a partir da qual é interpretada a resposta, o tempo de resposta máximo e o estado que os códigos de erro devem gerar caso sejam recebidos.

myname_rule

A regra de geração para o "myname" da RTU. Valores válidos são:

Se ausente, a regra default usa ambos os valores citados acima, gerando um nome que contém os nomes do escravo RTU e o gerado pelo protocolo de transporte, separados por um hífen.

slaves

Lista com os nomes dos escravos Modbus, separados por vírgula. Cada escravo Modbus deve ter uma seção para si abaixo no arquivo de configuração. Exemplo:

slaves=primeiro,segundo

[primeiro]
# ...
[segundo]
# ...

frequency

Tempo em segundos. A frequência com que o Pecon irá realizar a série de perguntas Modbus para cada comando de cada escravo. Se definido na seção global, este valor se aplicará a todos os comandos de todos os escravos Modbus, a não ser que seja sobrescrito nas seção específica do escravo Modbus.

Configuração por escravo Modbus

Em cada seção relativa a um escravo Modbus devem estar presentes as chaves slave_id e commands.

slave_id

O identificador Modbus-RTU do escravo Modbus. É um número hexadecimal de dois dígitos. Exemplo:

slave_id=01

commands

Lista com os nomes do comandos a serem executados. Assim como os nomes dos escravos Modbus na chave global slaves, estes nomes devem corresponder a seções do arquivo de configuração. Desta forma, a especificação dos comandos podem ser compartilhados por diferentes escravos Modbus. Exemplo:

commands=comando1,comando2

[comando1]
# ...
[comando2]
# ...

timeout

Valor de timeout por mensagem, em segundos. Para o protocolo modbus_rtu significa o tempo de timeout aguardando a resposta por uma requisição enviada antes de considerá-la descartada e enviar a seguinte.

Se a chave não for especificada será usado o valor de 300 segundos como padrão.

Configuração por comando

Cada seção de comando possui a pergunta Modbus a ser realizada e instruções de como converter a resposta em valores de sensores a serem armazenados na plataforma. As chaves possíveis são explicadas abaixo. Exemplo:

[comando1]
query=0400000008
1=sensor1,ieee754,big
2=sensor2,short,little
error_03=fatal

query

Comando Modbus RTU em hexadecimal, sem o identificador do escravo Modbus no início nem o CRC16 no final.

1, 2, 3...

As chaves numeradas indicam como interpretar a sequência de bytes respondida pelo escravo Modbus. O valor da chave contém três dados separados por vírgula:

Podem ser definidos até 100 sensores por comando.

error_01, error_02, ...

Podem ser especificadas chaves relativas aos códigos de erro retornados pelo protocolo Modbus-RTU. Nestas chaves pode-se indicar qual o status de erro deve ser gerado na plataforma. (TODO: isto não parece estar implementado!) Os valores válidos são:

Os códigos de erro suportados vão de error_01 a error_08.


lua

O comportamento do tipo "lua" determina a execução de um programa específico existente na plataforma. Lua é uma linguagem de programação na qual os programas de tratamento das conexões são escritos. É uma linguagem oficial www.lua.org que foi adotada pelo Iplenix para estes e outros desenvolvimento da empresa. Por exemplo, o tipo "modbus_rtu" de tratamento das conexões é um programa escrito com a linguagem Lua.

Para serem usados através desta chave, os scripts já devem estar configurados na plataforma. Ainda não oferecemos a possibilidade de baixar novos programas. Por enquanto somente programas avaliados pelo Iplenix e colocados a disposição podem ser acionados.

A única chave obrigatória é a "lua_script" que indica o nome do programa Lua a ser executado. E outras chaves podem ser necessárias dependendo do programa Lua, pois estas são passadas para ele no início da execução.


lua_script

Especifica o nome de arquivo do script Lua a ser carregado.


tee

O comportamento do tipo "tee" está disponível para que mais de uma porta Mestre possa receber os dados vindos de um equipamento ou rede conectada a uma porta Escrava. Todas as portas Mestres que estiverem conectadas a determinada porta Escrava receberão os dados vindos do equipamento ou rede conectado a esta porta Escrava. Uma aplicação para este tipo de comportamento é a leitura da saída de dados de um equipamento conectado na porta Escrava, e esta leitura pode ser feita por várias pessoas cada uma conectada a uma porta Mestre diferente.

A única chave que pode ser usada junto com "tee" é a "internal_master".


internal_master

Esta chave se comporta de forma muito similar a chave "plugin". Ela também especifica um comportamento de tratamento da conexão. A diferença é que ela só pode ser usada nos comportamentos de tratamento de conexões "tee" e "switchboard" das portas Escravas. Por exemplo a combinação de um "plugin=tee" com um "internal_master=rawdata" permite ter o comportamento do "rawdata" de salvar os dados que chegarem do equipamento ou rede em arquivos, e ao mesmo tempo permite que portas Mestre estejam conectadas recebendo estes dados. Se for usado somente "plugin=rawdata" os dados serão armazenados em arquivos, mas não será possível ter portas Mestre conectadas e esta porta Escrava recebendo os dados simultaneamente.


A chave "internal_master" quando usada junto ao "tee" só pode ter os seguintes valores:

A configuração destes comportamentos são iguais as feitas quando eles são declarados na chave "plugin".


switchboard

O comportamento "switchboard" está disponível para compartilhar uma porta Escrava com mais de uma porta Mestre que envie comandos para o equipamento ou rede de equipamentos ligada a porta Escrava. O comportamento é de comutar a comunicação entre cada uma das portas Mestre a e porta Escrava. Funciona da seguinte forma, quando uma porta Mestre enviar um comando, este é passado para o equipamento ou rede conectado nesta, e será esperado um tempo especificado na chave "slice_time" por uma resposta, e tudo o que chegar pela porta Escrava neste tempo será enviado para a porta Mestre que enviou o comando. Foi desenvolvido para compartilhar comunicação com equipamentos escravos que falem MODBUS RTU, mas pode ser usado em outros protocolos similares onde exista um escravo que recebe comandos, e que só comunica quando receber algum comando.


As chaves que podem estar presentes com o "switchboard" são:


internal_master

Esta chave se comporta de forma muito similar a chave "plugin". Ela também especifica um comportamento de tratamento da conexão. A diferença é que ela só pode ser usada nos comportamentos de tratamento de conexões "tee" e "switchboard" das portas Escravas. Por exemplo a combinação de um "plugin=switchboard" com um "internal_master=modbus_rtu" permite ter o comportamento do "modbus_rtu" de enviar comandos para monitoramento e aquisição de dados a partir da própria plataforma, ao mesmo tempo que programas supervisórios conectados a portas Mestre façam o monitoramento e aquisição de dados do equipamento ou rede conectada a porta Escrava.


A chave "internal_master" quando usada junto ao "switchboard" só pode ter os seguintes valores:

A configuração destes comportamentos são iguais as feitas quando eles são declarados na chave "plugin".



slice_time

Tempo em segundos que o comutador aloca para um mestre após receber um envio. Respostas enviadas pelo escravo dentro deste tempo serão enviadas para este mestre, e o comutador trancará envios de outros mestres até que este seja respondido ou a fatia de tempo especificada nesta chave expire.


Se não especificado, o valor default é 5 segundos.


single_tx (somente switchboard)

Quando esta chave é configurada com "yes", um mestre pode realizar somente um envio por vez na sua fatia de tempo até receber uma resposta. Isto gera o descarte de reenvios do mestre, o que pode ser útil caso este esteja operando com timeout muito baixo.


Se não especificado, o valor default é "no", ou seja, a restrição não se aplica.


master

O Iplenix Plug é um serviço que permite a conexão entre RTUs, onde uma RTU opera como escravo e permite a conexão de uma ou mais RTUs mestres. O protocolo master recebe os dados enviados pela RTU mestre e os repassa para a RTU escrava para a qual ele é configurado. Além disso, ele detecta desconexões e tenta manter uma conexão com a RTU escrava. As chaves específicas do mestre tratam destas reconexões:


reconnection_retries

Número de tentativas de reconexão ao perder a ligação com a RTU escrava, ou não conseguir uma ligação inicial.

Se não especificado, o valor default é 2.


reconnection_delay

O tempo em segundos a aguardar entre cada tentativa de reconexão.

Se não especificado, o valor default é 1 segundo.

Ferramentas pessoais
Espaços nominais
Variantes
Ações
Navegação
Ferramentas