Entre o L5X e o Alarms.xml do FactoryTalk, nos dois sentidos

A extração percorre os comentários de bit dos membros de falha do L5X (como TIO_D) e entende os dois formatos que o Logix produz: o texto em <Comment> com CDATA das exportações do RSLogix 5000 v20.05 e o <LocalizedComment> das exportações multilíngues do Studio 5000 v34.01, escolhido pelo idioma corrente do projeto.

As instruções COP que remapeiam bits entre membros de larguras diferentes — um DINT de 32 bits copiado para um INT de 16, por exemplo — são resolvidas para que a mensagem saia com o comentário da origem, que é o que de fato descreve a falha.

A cor de cada mensagem vem do primeiro termo do texto, seguindo a norma FCA: M/A de anomalia e EMG de emergência em vermelho, M/E de erro em vermelho, M/T de time-out em roxo, M/G de estado genérico em ciano, M/P de pedido do operador em amarelo, M/V de portão em laranja e M/AV de aviso de cartão em verde. Tipo fora da tabela fica em cinza, o que denuncia na hora o comentário fora do padrão.

Prefixo digitado errado no CLP — M/T. ou M/AVMAIS — é apontado com a sugestão do tipo válido e pode ser acertado de uma vez em Corrigir prefixos. Bits comentados sem descrição, com só o prefixo ou só a referência de origem, entram como pendência e não viram alarme enquanto não receberem texto.

As ressalvas de cada linha ficam reunidas na coluna Observações, ao lado do texto: sem uso na lógica, sem descrição — não será gerado, prefixo desconhecido — talvez M/T. A revisão do que precisa de atenção passa a ser a leitura de uma coluna só.

Um bit de falha só deveria ter comentário se o programa usar aquele bit. Mas o template FCA chega com o array inteiro documentado e cada projeto aproveita uma parte dele — o resto vira alarme fantasma na IHM. Em um dos projetos usados na validação, 1619 dos 2215 comentários de bit não eram usados por rotina nenhuma: 1677 mensagens caíram para 436 alarmes reais.

Depois da análise, essas linhas são marcadas na coluna Observações e o botão Eliminar comentários sem uso tira todas de uma vez, registrando a remoção do comentário no PLC — que sai no CSV de correções como descrição vazia, que é justamente como o Logix apaga um comentário na importação. Nem o L5X nem o CSV original são alterados: o comentário só some do projeto depois que a cópia é importada no Logix.

O critério é conservador de propósito. Conta como uso o endereço do bit citado por extenso em qualquer rotina e o COP que leva o bit do RQT ao TIO_D; não contam as instruções que varrem a palavra inteira só para zerá-la ou testá-la, como FLL, CLR, MOV e EQU. Quando o endereço é montado por variável, o membro inteiro daquela tag é dado como usado — sem saber quais bits entram, nada é apagado.

Corrigir o texto só na tabela não resolve nada a longo prazo: o comentário errado continua no projeto do CLP e volta na próxima geração. Por isso as edições feitas na tabela podem ser exportadas para o CSV de Tools > Import/Export > Tag and Logic Comments do Logix.

O ciclo é: exportar o CSV de comentários no Logix, abrir L5X e CSV no FaltGenerate, corrigir os textos, exportar a cópia corrigida — o arquivo original nunca é alterado —, importar essa cópia no Logix e reexportar o L5X para gerar o Alarms.xml definitivo.

A reescrita do CSV é cirúrgica: apenas o campo de descrição das linhas corrigidas é trocado, preservando codificação cp1252, quebras CRLF, cabeçalhos e os escapes do Logix. Sem nenhuma correção, o arquivo sai byte a byte idêntico ao de entrada. As linhas de definição de tag ficam de fora, porque reimportá-las faria o Logix tentar criar tags de I/O e derrubaria a importação inteira.

A aba IHM → PLC atende o caso inverso: a IHM já está com as mensagens cadastradas e o PLC está sem a documentação, ou com ela velha. O programa lê o Alarms.xml — que não é alterado — e escreve cada texto como comentário do bit a que o alarme se refere, no mesmo CSV de Tag and Logic Comments que o outro sentido usa.

O endereço vem do trigger de cada mensagem e o texto vem da própria mensagem, sem o sufixo de endereço que a convenção pendura no fim. Mensagem sem trigger, endereço fora do formato ou trigger sem mensagem viram aviso no log e ficam de fora; o resto é convertido normalmente, inclusive em arquivo montado à mão na IHM.

O Alarms.xml guarda só o endereço de destino, mas dentro da faixa que o COP copia o comentário mora na origem. Informando também o L5X do projeto — campo opcional —, as instruções COP reais são lidas e o endereço de cada mensagem é reconstruído com exatidão: nos dois projetos usados na validação, de 232 e 1677 alarmes, nenhuma mensagem ficou no lugar errado. Sem o L5X vale a faixa da convenção FCA, que já vem preenchida na tela, e as mensagens que caem nela sem confirmação ficam sinalizadas em Observações.

Com o CSV do projeto informado, a saída é uma cópia dele com os textos da IHM aplicados nos bits de falha e criados onde ainda não havia comentário; todo o resto da documentação sai igual. Uma coisa não volta: o texto na IHM é de uma linha só, então as quebras de linha do comentário original não estão no Alarms.xml e não podem ser recuperadas.