Usando a versão 32 bits do Elipse SCADA
Com a versão 32 bits do Elipse SCADA, é possível que cada driver de comunicação trabalhe separadamente, o que melhora muito a performance da aplicação. Este desempenho pode ser notado principalmente quando utilizados modems ou drivers seriais com baixa velocidade (1200, 9600, ou 19200 bps, por exemplo). Para colocar os drivers de comunicação em background, clique o botão Avançado da janela de configuração do driver (dentro do Organizer), desmarque a opção Manter compatibilidade 16 bits e escolha se o driver escreverá ou não em background. Note que alguns drivers de comunicação não podem ser colocados em background.
Usando tags bloco
Deve ser incentivada a criação do máximo número possível de tags bloco, em vez de tags PLC. Tags blocos são conjuntos de tags PLC que transferem muito mais informações (tags) em menos tempo. São aplicados principalmente para a monitoração de alarmes e tags registrados em históricos (que ficam sempre comunicando) ou de telas carregadas de dados, agilizando assim o processo de comunicação. Normalmente, tags blocos são sequências de memórias (ou de entradas e saídas) onde são indicados os endereços inicial e final do bloco. Os elementos de bloco não utilizados podem ser deletados no Organizer. Utilize a página de Cross-Reference para verificar os elementos utilizados.
Tempo de scan
Os tempos de scan dos tags bloco e PLC do aplicativo requerem um planejamento cuidadoso. Para cada tag bloco ou PLC presente no sistema, faça a si mesmo a seguinte pergunta: “Qual é o tempo ideal de atualização deste tag?”. Esta pergunta geralmente gera outras perguntas, como “Qual é o tempo de atualização do sistema/PLC?”, ou ainda “Necessito realmente que esta variável seja atualizada de 1 em 1 segundo, ou o seu valor poderia ser atualizado a cada 5 segundos sem comprometer o sistema?”. O resultado destes questionamentos levará as variáveis com maior prioridade a serem lidas mais frequentemente que outras, o que faz com que o Elipse SCADA trabalhe mais suavemente. Outro ponto importante é que variáveis apenas de escrita não precisam ter suas opções Habilita leitura pelo scan nem Habilita leitura automática habilitadas, evitando assim a leitura desnecessária destas variáveis.
Velocidade de comunicação
A velocidade de comunicação do driver deve ser ajustada, sempre que possível, para o valor máximo permitido pelo equipamento, o que por consequência aumenta o desempenho do sistema monitorado. Se forem verificados muitos erros de comunicação (erros ocasionais podem ser suprimidos com 1 ou 2 retentativas de comunicação), primeiro tente ajustar o time-out de comunicação (normalmente entre 20 e 50 ms) e, caso seja necessário, vá baixando a velocidade gradativamente até encontrar a condição ideal. As distâncias e condições de instalação são fatores decisivos para a comunicação dos dados entre o computador e o equipamento de aquisição de dados.
“Advise” de tags
O Elipse SCADA não mantém comunicação periódica com todos os tags do sistema ao mesmo tempo; isto geraria o caos em termos de performance. O que existe é o que chamamos de “advise” para gerenciar e priorizar a comunicação. Quando se fala que um determinado tag está em “advise” (propriedade do tag), isto significa que o Elipse SCADA está preparado para que ele seja periodicamente atualizado, e seu valor informado àqueles objetos conectados a ele. Por exemplo: quando uma tela é acionada, o Elipse SCADA mostra todos os objetos desta tela e começa o “advise” de todos os tags conectados a estes objetos. Em outras palavras: cada tag referenciado naquela tela será lido automaticamente, na frequência informada no scan do tag. Outros exemplos de objetos que forçam o “advise” de tags são históricos ativados e alarmes habilitados para o objeto. Esta é a forma como o Elipse SCADA gerencia a comunicação dos tags, evitando a comunicação com variáveis desnecessárias em determinadas circunstâncias.
Uso do script OnCommError
Sempre que um erro de comunicação ocorrer, o Elipse SCADA automaticamente chamará um script OnCommError para efetuar tarefas específicas, conforme o desejo do usuário. Um erro de comunicação somente será gerado após o número de retentativas definido nos parâmetros de comunicação do driver. Uma das tarefas desejáveis deste script pode ser o desativamento do driver ou da leitura/escrita do tag que causou o erro de comunicação, em caso de pane geral em um determinado equipamento do sistema. Para isto, é necessário filtrar os tags desejados através da função AddFilter() do driver de comunicação.
Telas janeladas
É importante notar que a performance das telas janeladas têm um comportamento diferenciado: os tags pertencentes a uma tela aberta no sistema têm sua comunicação ativada de acordo com o scan definido para cada tag, por isto quando sobrepomos telas janeladas, estamos abrindo mais “janelas” de comunicação, mantendo a comunicação com as variáveis das telas escondidas, mas ainda ativas. Isto, evidentemente, degrada a performance de todo o sistema sem necessidade, não apenas no que diz respeito à comunicação, mas também pela memória utilizada. Para resolver esta situação, é necessário fechar as telas sobrepostas (função Hide) com o mesmo comando que abre outras telas. Uma outra opção é utilizar “telas cheias” ao invés das janeladas, pois estas são desativadas automaticamente na abertura de outra tela cheia.
Telas ativas
São consideradas telas iniciais do aplicativo todas as telas que tiverem a propriedade Visível ligada. Sendo assim, todas estas telas serão carregadas juntamente com a aplicação, tornando este carregamento lento e ocupando recursos desnecessários. Além disto, estas telas estarão todas sobrepostas, o que dará ao sistema uma má aparência inicial. Por isto, recomenda-se ativar somente a tela que deve ser vista no início da aplicação, mantendo todas as demais telas fechadas e melhorando o carregamento da aplicação. Isto é válido também para as aplicações em tempo de desenvolvimento, pois quando salvamos uma aplicação com várias telas abertas, todas elas serão carregadas novamente na próxima abertura do aplicativo pelo configurador. Portanto, feche todas as telas (ou mantenha apenas uma aberta) antes de salvar a sua aplicação. Com certeza, isto melhorará seu posterior carregamento.
Scripts WhileRunning
São scripts que rodam constantemente sempre que a aplicação é executada ou que uma tela é aberta, geralmente gastando mais tempo de processamento que outros scripts. Através da função ScriptWindow(), é possível verificar, em runtime, quanto tempo cada script leva para ser executado. A definição dos tempos (ciclo de execução) destes scripts, quando bem estimada, garante um bom desempenho do sistema.
Botões Compile Script, Build Scripts e Rebuild All Scripts
Antes de executar uma aplicação no Elipse SCADA, é necessário verificar se ela não contém erros. Esta tarefa é muito importante, uma vez que scripts com erros de sintaxe não são executados. Estas verificações podem ser feitas rapidamente através dos botões Compile Script, Build Scripts e Rebuild All Scripts, localizados na parte inferior do Organizer. O botão Compile Script verifica a presença de erros no script que está sendo editado no momento; no entanto, note que este botão não verifica se os demais scripts da aplicação possuem erros. O botão Build Scripts verifica somente os scripts que ainda não foram checados. O botão Rebuild All Scripts verifica todos os scripts da aplicação, sem levar em conta se foram modificados ou não. A diferença de tempo entre as operações geradas pelos botões Build Scripts e Rebuild All Scripts é considerável no caso de aplicações maiores, mas este tempo extra é bastante útil para evitar erros de execução nos scripts.
Históricos
O tempo de gravação de Históricos deve ser ajustado de acordo com a necessidade real da aplicação, levando-se em conta o tempo de scan dos tags: de nada adianta gravar o Histórico a cada 1 segundo se o scan dos tags é de 5 segundos. Como o Histórico utiliza acesso a disco, é importante evitar tempos de scan pequenos sempre que possível. Uma boa opção neste caso são os Históricos ativados por evento, ou seja, Históricos que são ativados quando a função WriteRecord() é executada em algum script, evitando os tempos de scan (é necessário desabilitar a opção Habilita histórico por scan).
Também é importante lembrar que todos os tags pertencentes a um Histórico ativo ficam em constante atualização, comunicando a cada período de scan.
Animações
Os objetos de animação, com bitmaps grandes e com muitas cores (high ou true color), tornam mais lenta a execução do sistema. Os bitmaps para animação devem ser criados no exato tamanho que serão utilizados e com poucas cores, sempre que possível.
