Migrazione dei commenti ai rung di RSLogix 500: associa i commenti all'indirizzo di uscita

I commenti ai rung in un progetto RSLogix 500 fanno parte del database di ingegneria, non della logica eseguibile del processore. Per questo è facile trascurarli o danneggiarli durante una pulizia o una migrazione. Quando i commenti compaiono sui rung sbagliati dopo l’inserimento, la copia o la riorganizzazione della logica, la risposta corretta è identificare la modalità di associazione, conservare una baseline e convalidare il risultato in una copia offline prima di modificare l’archivio di produzione.

La scelta dell’associazione determina se la documentazione segue un numero di rung o un indirizzo associato al rung.

Capire cosa viene effettivamente spostato

RSLogix 500 può associare la documentazione del rung alla posizione del file e del rung oppure a un indirizzo di uscita. Un commento basato sulla posizione è utile quando un file deve rimanere intenzionalmente invariato, ma le modifiche apportate sopra quel rung possono separare la descrizione dalla logica che doveva spiegare. L’associazione all’indirizzo può fare in modo che il commento segua l’indirizzo di uscita selezionato quando la logica viene spostata. La nota di supporto Rockwell sui titoli AI500 importati conferma che il software espone una modalità di associazione e può convertire la documentazione tra l’associazione all’uscita e quella al numero di rung.

Nessuna delle due modalità è universalmente corretta. Un rung può non contenere alcuna istruzione di uscita, diverse uscite, un’uscita il cui indirizzo viene riutilizzato altrove oppure un’istruzione spostata nell’ambito di un refactoring più ampio. Un commento basato sull’indirizzo può quindi comparire su più rung, mentre un commento basato sul numero di rung può rimanere al suo posto quando la relativa logica viene spostata. Considerare l’associazione come una regola documentale controllata, non come un pulsante di riparazione automatica.

Proteggere la sorgente prima di modificare

Salvare il file RSS originale in sola lettura e registrare il relativo checksum, il nome del controllore, la revisione del programma e la data di upload. Esportare o stampare il database e i commenti ai rung in un formato che possa essere confrontato in seguito. Se il progetto viene caricato da un controllore, ricordare che descrizioni e commenti potrebbero non essere memorizzati nel processore SLC nello stesso modo della logica ladder. Un upload può recuperare la logica lasciando comunque il progetto privo del corretto database offline della documentazione.

Lavorare su un file duplicato. Scegliere diversi casi di test: un rung OTE normale, una coppia OTL e OTU, un rung con più uscite, un rung senza un’uscita evidente e una subroutine a cui verrà aggiunta nuova logica. Registrare per ogni caso il numero di file corrente, il numero di rung, l’indirizzo di ancoraggio selezionato e il testo del commento.

Selezionare l’associazione in base all’intento ingegneristico

Usare l’associazione all’indirizzo di uscita quando l’uscita identifica in modo univoco la funzione e il rung potrebbe essere spostato. Un comando di marcia del motore, un bit di stato della sequenza o un latch di allarme possono fornire un’ancora duratura se quell’indirizzo è regolato da uno standard di denominazione e non viene riutilizzato. Mantenere il commento incentrato sullo scopo, sugli interblocchi e sul comportamento anomalo della funzione, invece di ripetere la descrizione del simbolo.

Usare l’associazione a file e rung quando la descrizione riguarda una posizione o una sezione anziché un singolo indirizzo. Tra gli esempi rientrano le note sulle transizioni, i calcoli diagnostici, la logica di inizializzazione o un rung contenente diverse uscite correlate. In questi casi, forzare un bit destinato esclusivamente alla documentazione nella logica eseguibile solo per trasportare un commento può creare rischi di manutenzione. Non aggiungere istruzioni inutilizzate a una macchina in funzione soltanto per rispettare una convenzione sui commenti.

Le coppie di latch e unlatch richiedono particolare attenzione perché spesso condividono lo stesso indirizzo. Una descrizione a livello di indirizzo dovrebbe spiegare il significato dello stato latched. I commenti specifici del rung dovrebbero spiegare cosa lo imposta, cosa lo azzera e quali condizioni permissive si applicano. Se un unico commento condiviso non può descrivere in modo sicuro entrambe le azioni, mantenere le note dettagliate associate alla posizione e usare simboli e descrizioni degli indirizzi coerenti per il riferimento incrociato.

Gli indirizzi condivisi richiedono una regola documentale che distingua il significato dello stato dal motivo per cui ciascun rung interviene.

Migrare i commenti in batch controllati

Iniziare con un solo file di programma, non con l’intero progetto. Confrontare ogni commento con il report originale prima di modificarne l’associazione. Riassegnare solo i commenti la cui logica prevista è inequivocabile. Inserire un rung di test temporaneo sopra la logica campione nella copia offline, spostare un rung campione all’interno del file e copiare un campione tra i file. Osservare quali commenti si spostano e quali rimangono legati alla posizione.

Dopo ogni batch, cercare commenti vuoti, testi duplicati, commenti associati a indirizzi imprevisti e indirizzi di uscita utilizzati su più rung. Eseguire i riferimenti incrociati su ogni ancora. Un bit dall’aspetto univoco può comunque essere scritto da un unlatch, da un’istruzione di spostamento, da un’operazione sul file o da un’altra routine. Se la relazione è incerta, lasciare invariato il commento sorgente e segnalarlo a un tecnico dei sistemi di controllo che conosca la sequenza della macchina.

Convalidare tra software e archivi

Quando possibile, aprire la copia modificata con la versione esatta di RSLogix 500 utilizzata presso il sito. Quindi riaprire il file salvato e ripetere i test campione di inserimento e spostamento. Le conversioni tra versioni e le importazioni del database devono essere trattate come migrazioni a sé stanti. Il Manuale di riferimento del set di istruzioni SLC 500 ufficiale rimane la fonte primaria per il comportamento delle istruzioni, ma l’associazione della documentazione è un comportamento del database software e deve essere verificata nell’ambiente RSLogix installato.

Eseguire un confronto della logica per confermare che una modifica al progetto limitata alla documentazione non abbia alterato i rung eseguibili, le dimensioni delle tabelle dati, la configurazione dei canali o le impostazioni del processore. La riparazione di un commento non deve trasformarsi in una modifica al controllo non sottoposta a revisione. Seguire le procedure del sito per backup, approvazione e download prima di sostituire il file master.

Rendere la convenzione gestibile

Aggiungere la regola di associazione allo standard di programmazione e alla checklist di revisione del codice. Richiedere un archivio RSS aggiornato per ogni modifica approvata e mantenere sincronizzati i commenti con i simboli, gli schemi elettrici e i testi degli allarmi HMI. Per le macchine che rimangono sulla piattaforma SLC, allineare la responsabilità della documentazione al piano del ciclo di vita più ampio dei sistemi PLC e PAC e alle procedure di modifica online in RSLogix 500 del sito.

La modalità di associazione migliore è quella che preserva il significato attraverso le modifiche effettivamente eseguite nello stabilimento. Una baseline verificata, regole di selezione esplicite, test in batch e un confronto dopo il salvataggio impediscono che un problema estetico del database diventi un rischio durante la ricerca dei guasti.