Aggiornamento I/O tramite FB o su immagine di processo

[Anonimo]

Sto lavorando con uno Slim Line ed un terminale Weintek connessi tramite modbus ethernet.

Lavorando al mio progetto mi trovo di fronte a questo dubbio, cosa cambia tra gestire gli I/O del sistema tramite immagine di processo, e quindi puntando la variabile input ad esempio come %IX3.1 e la variabile output ad esempio come %QX1.0, ed invece gestirle tramite le function block di get/set degli I/O ?

Forse la differenza è che se attivo una uscita tramite la function block essa viene attivata immediatamente (a parte i 300us per eseguire il comando), mentre se la gestisco ad immagine di processo essa verrà attivata alla fine della task plc ?

Se così è, a quale task fanno riferimento le immagini di processo, a quella slow o a quella di back ?

[Sergio Bertana]

La domanda è interessante e dà modo di chiarire come il sistema Slim Line aggiorna gli I/O.

Tutti i moduli di I/O logici connessi al modulo CPU sono aggiornati automaticamente (Immagine di processo) e mappati nella tabella %IX e %QX nella task slow. Gli ingressi sono acquisiti prima e le uscite sono gestite dopo, l’esecuzione del programma utente. Quindi l’immagine dello stato di un I/O è valida per tutta l’esecuzione della task slow.

Per la task back, viene creata una immagine di processo “parallela” che riporta lo stato degli ingressi prima della esecuzione e gestisce le uscite dopo l’esecuzione del programma utente, anche questa “immagine” dello stato di un I/O è valida per tutta l’esecuzione della task back. Attenzione! la gestione della stessa uscita logica sia nella task slow che back crea disallineamenti tra le due tasks ed è da evitare.

Nella task fast se si vuole gestire gli I/O alla velocità di esecuzione della task, occorre acquisirne il valore e gestirne l’attivazione con le apposite FB. Se si utilizza quelli mappati nella tabella %IX e %QX essi saranno aggiornati comunque alla velocità di esecuzione della task slow. Attenzione! l’esecuzione della task fast interrompe l’esecuzione della task slow, quindi agendo sulle variabili %IX e %QX “sporco” l’immagine di processo della task slow.

L’utilizzo delle FB di gestione I/O come dicevi tu permette di acquisire e gestire direttamente i moduli di I/O indipendentemente dalla immagine di processo. Attenzione! la gestione di un modulo di uscita và fatta considerando che la task slow ne gestirà l’immagine di processo, quindi potrebbe settare nelle uscite un valore diverso da quello settato dalla FB provocando un lampeggio delle uscite.

[Sergio Bertana]

Per quanto riguarda la gestione degli I/O analogici occorre utilizzare le apposite FB. E’ possibile inserire le FB indifferentemente in tutte le tasks, ma se non per casi eccezzionali, il mio consiglio è di inserirne la chiamata nella task back.

E’ possibile anche acquisire un ingresso e/o gestire una uscita su un modulo analogico in una task ed acquisire un’altro ingresso e/o gestire un’altra uscita dallo stesso modulo in un altra task.

Se un valore analogico in ingresso è utilizzato in più tasks, si acquisisce nella task eseguita piu velocemente e si utilizza il valore acquisito nell’altra task, senza eseguire nuovamente la FB.

[Fabio]

Non capisco perché gli esempi tipo FBOnOffCycle non fanno vedere ne in simulazione ne provando a  dare tensione al morsetto DI00 della CPU gli ingressi che cambiano.  Pensavo che dichiarando %XI0.0 fosse sufficiente perchè venga letto l’ingresso senza dover aggiungere FB opportuni di lettura. Sto sbagliando qualcosa ?

[Sergio Bertana]

Siccome al bus di estensione del modulo CPU possono essere connessi 16 moduli (Indirizzi da 0 a 15) , gli I/O del modulo CPU sono indirizzati con indirizzo di modulo 255. Quindi se utilizzi la mappatura in immagine di processo devi mappare gli ingressi come %IX255.0, %IX255.1, … e le uscite come %QX255.0, %QX255.1, … Se gestisci gli I/O direttamente con i blocchi funzioni relativi devi definire indirizzo di modulo 255.

Attenzione, Questa regola non vale per i moduli CPU NetlogIII, in quel caso gli I/O del modulo CPU sono mappati ad indirizzo 0.

Il motivo di questa differenza è che il modulo NetlogIII è basato su di un modulo CPU OEM, il quale ha già degli I/O cablati (Indirizzo modulo 255). La parte hardware fisica di I/O non è altro che un modulo di espansione 20 I/O (Con indirizzo 0) connesso al bus di estensione del modulo CPU. Eventuali altri moduli di espansione connessi al bus assumeranno automaticamente indirizzi da 1 a 15.

[Autore]

Post