>
DOMANDA
Con
quali meccanismi diversi si possono trasferire in modo consistente
i dati nel S7-400?
RISPOSTA
Dati consistenti
Dati che per il loro contenuto vanno
assieme e descrivono uno stato di processo in un determinato
istante vengono chiamati dati consistenti. Affinché i dati siano
consistenti, essi non devono essere modificati o aggiornati
durante l'elaborazione o il trasferimento.
Esempio 1
Affinché la CPU, per la durata
dell'elaborazione ciclica del programma, abbia a disposizione una
immagine consistente dei segnali di processo, i segnali di processo
prima dell'elaborazione del programma vengono letti nell'immagine
di processo degli ingressi opp. dopo l'elaborazione del programma
vengono scritti nell'immagine di processo delle uscite. Poi il
programma applicativo, durante l'elaborazione del programma nella
chiamata di campi operandi Ingressi (I) e uscite (O) non accede
direttamente alle unità di periferia, ma bensì solo al campo di
memoria interna della CPU nel quale si trova l'immagine di
processo.
Esempio 2
Una inconsistenza può nascere se un
blocco di comunicazione (p. es. SFB 14 "GET", SFB 15 "PUT") viene
interrotto da un OB di interrupt di processo con priorità
superiore. Se il programma applicativo in questo OB di interrupt di
processo modifica i dati che in parte erano stati già elaborati dal
blocco di comunicazione, succede che i dati trasmessi sono in parte
relativi al tempo prima dell'elaborazione dell'interrupt di
processo ed in parte sono relativi al tempo dopo l'elaborazione di
interrupt di processo.
Questo significa che
questi dati sono inconsistenti (non vanno insieme).
Lo
SFC 81
"UBLKMOV"
Con
loSFC 81 "UBLKMOV"
si copia in modo consistente il contenuto di un campo di memoria (=
campo sorgente) in un altro campo di memoria (= campo di
destinazione). L'operazione di copiatura non può essere interrotta
da altre attività del sistema operativo.
Con lo SFC 81
"UBLKMOV" si possono copiare i seguenti campi di
memoria:
La massima quantità dei
dati che si possono copiare vale 512 byte. Tenere conto delle
limitazioni specifiche della CPU che si possono trovare ad esempio
nella lista operazioni.
Poiché l'operazione di
copiatura non può essere interrotta, il tempo di reazione agli
interrupt da parte della CPU nel caso di impiego dello SFC 81
"UBLKMOV", può aumentare.
Campo sorgente e campo di
destinazione non devono sovrapporsi. Se il campo di destinazione
indicato è maggiore del campo sorgente, allora vengono copiati solo
tanti dati quanti ce ne sono nel campo sorgente. Se campo di
destinazione indicato è più piccolo del campo sorgente, allora
vengono copiati solo tanti dati quanti il campo di destinazione può
accogliere.
Consistenza con i blocchi e le funzioni di
comunicazione
Con le S7-400 i job di
comunicazione non vengono elaborati al punto di controllo ciclo, ma
bensì in intervalli di tempo fisso durante il ciclo di programma.
Lato sistema si possono elaborare, sempre in modo consistente, i
formati dati byte, parola e doppia parola, cioè il trasferimento
opp. l'elaborazione di 1 byte, 1 parola (= 2 byte) opp. 1 doppia
parola (= 4 byte) non può essere interrotto.
Se nel programma
applicativo vengono richiamati blocchi di comunicazione (p. es. SFB
12 "BSEND"), che vengono impiegati sola in coppia (p. es. SFB 12
"BSEND" e SFB 13 "BRCV") e che accedono a dati comuni, allora
l'accesso a questi dati può essere coordinato dal parametro "DONE"
stesso. La consistenza dei dati che vengono trasferiti localmente
con questi blocchi di comunicazione, può perciò essere garantita
nel programma applicativo.
Altrimenti si comportano
le funzioni di comunicazione S7, con le quali nell'apparecchio di
destinazione non è necessario alcuno blocco nel programma
applicativo (p. es. SFB 14 "GET", SFB 15 "PUT"). Qui occorre tener
conto dei dati consistenti già nella programmazione.
Accesso alla memoria di lavoro della
CPU
Le funzioni di comunicazione del sistema operativo accedono,
in blocchi di grandezza fissa, alla memoria di lavoro della CPU. La
grandezza dei blocchi è specifica per ogni CPU; essa per le CPU
S7-400 vale 32 byte. In questo modo viene garantito che il tempo di
reazione agli interrupt nell'impiego delle funzioni di
comunicazione non si allunga. Poiché questo accesso avviene in modo
asincrono rispetto al programma applicativo, non si possono
trasferire in modo consistente tanti byte quanto si
vogliono.
Quali
regole si devono rispettare per garantire la consistenza dei dati
viene chiarito nel seguito.
Regole della
consistenza per SFB 14 "GET" opp. Lettura variabili
Con lo SFB 14 "GET" vengono
trasferiti i dati in modo consistente se si rispettano tutte le
regole della consistenza citate nel seguito.
-
CPU attive (riceventi i dati):
leggere il campo di ingresso nel OB nel quale si chiama lo SFB 14
opp., se questo non è possibile, leggere il campo delle ingressi
solo quando l'elaborazione dello SFB 14 è conclusa.
-
CPU passive (trasmittenti i
dati): scrivere al massimo così tanti dati nel campo di
trasmissione quanti indica la dimensione di blocco della CPU
passiva (trasmittente i dati).
-
CPU passive (trasmittenti i
dati): scrivere i dati da trasmettere sotto il blocco di interrupt
nel campo di trasmissione.
Nella figura seguente viene
indicato un esempio per il trasferimento dati per il quale non può
essere garantita alcuna consistenza dati, poiché la seconda regola
della consistenza è stata infranta: vengono infatti trasferiti 32
byte, nonostante la dimensione di blocco della CPU passiva
(trasmittenti i dati) sia di soli 8 byte.
Figura 1 Esempio per il trasferimento dati
Regole per la consistenza per lo SFB 15 "PUT" opp.
Scrittura delle variabili
Con lo SFB 15 "PUT" i dati
vengono trasmessi in modo consistente solo se si rispettano tutte
le regole di consistenza seguenti.
-
CPU attive (trasmittenti i
dati): scrivere il campo di trasmissione dal OB nel quale si
richiama lo SFB 15 opp., se questo non è possibile, scrivere il
campo di trasmissione solo quando il primo richiamo dello SFB 15 è
concluso.
-
CPU attive (trasmittenti i
dati): scrivere il maggior numero dei dati nel campo di
trasmissione quanto indica la grandezza di blocco delle CPU passive
(riceventi i dati).
-
CPU
passive (riceventi i dati): leggere i dati ricevuti sotto blocco
dell'interrupt dal campo di ricezione.
Nella figura seguente viene
indicato un esempio per il trasferimento dati per il quale non può
essere garantita alcuna consistenza dei dati, poiché è stata
infranta la seconda regola di consistenza: vengono infatti
trasferiti 64 byte, nonostante la grandezza di blocco della CPU
passiva (ricevente dei dati) valga solo 32 byte.
Figura 2 Trasferimento dati
senza la garanzia di consistenza dei dati
Il trasferimento consistente di grandi
blocchi di dati tramite più variabili può essere garantito nel
programma applicativo del S7-400 con lo SFC 81 "UBLKMOV"
(uninterruptable block move).
A questi dati si può poi accedere in modo
consistente p. es. con lo SFB 14 "GET", SFB 15 "PUT opp. tramite
Lettura/scrittura di variabili.
Lettura consistente di dati da uno slave DP
standard e scrittura consistente su uno slave DP
standard
Lettura consistente
di dati da uno slave DP standard con lo SFC 14 "DPRD_DAT"
Con lo SFC 14 "DPRD_DAT"
(read consistent data of a DP-normslave) si leggono in modo
consistente i dati di uno slave DP standard. Se nel trasferimento
dati non è comparso alcun errore, i dati letti vengono registrati
in un campo di destinazione definito tramite RECORD.
Il campo di destinazione
deve presentare la stessa lunghezza che è stata progettata con STEP
7 per l'unità selezionata. Con un richiamo dello SFC 14 si può
accedere ogni volta solo ai dati di una unità/codice identificatore
DP all'indirizzo di inizio progettato.
Scrittura
consistente di dati su uno slave DP standard con lo SFC 15
"DPWR_DAT"
Con lo SFC 15 "DPWR_DAT"
(write consistent data to a DP-normslave) si trasferiscono i dati
in modo consistente in RECORD allo slave DP standard
indirizzato.
Il campo sorgente deve
presentare la stessa lunghezza che è stata progettata con STEP 7
per l'unità selezionata.
Avvertenze
La norma PROFIBUS DP
definisce limiti superiori per il trasferimento di dati utili
consistenti (vedi il paragrafo successivo). Slave DP standard di
uso corrente rispettano questi limiti. Con le CPU più vecchie (>
1999) esistevano limitazioni per il trasferimento di dati utili
consistenti che erano specifiche per ogni CPU.
Con queste CPU la lunghezza massima dei dati che la CPU
può leggere in modo consistente da uno slave DP standard opp. che
può scrivere in modo consistente su uno slave DP standard è
indicato dei dati tecnici della CPU alla voce " Master DP– Dati
utili per slave DP". Le CPU più recenti superano con questo valore
la lunghezza dei dati che uno slave DP standard mette a
disposizione opp. riceve.
Massimi limiti superiori
per il trasferimento di dati utili consistenti su uno slave
DP
Per il
trasferimento di dati utili consistenti ad uno slave DP vengono
fissati, da parte della norma PROFIBUS DP, limiti superiori. Per
questo in un slave DP standard possono essere trasferiti in modo
consistente in un blocco max. 64 parole = 128 byte di dati
utili.
Nella progettazione
fissare quanto è grande il campo consistente. Per questo in un
formato codice speciale (SKF) è possibile impostare una lunghezza
massima dei dati consistenti pari a 64 parole = 128 byte (128 byte
per gli ingressi e 128 byte per le uscite). Una lunghezza maggiore
non è possibile.
Questo limite superiore vale solo per i puri dati utili.
Dati di diagnostica e dei parametri vengono raccolti in set di dati
e quindi di principio trasferiti in modo consistente.
Nel formato codice
generale (AKF) è impostabile una lunghezza massima dei dati
consistenti pari a 16 parole = 32 byte (32 byte per gli ingressi e
32 byte per le uscite). Una lunghezza maggiore non è
possibile.
In questo contesto fare
attenzione anche al fatto che una CPU 41x come slave DP in un
contesto generale deve essere configurabile su un master di terzi
(collegamento tramite GSD) tramite il formato codice generale. Per
questo motivo la memoria di trasferimento di una CPU 41x come slave
DP su PROFIBUS DP vale max.16 parole = 32 byte.
Accesso dati consistente senza
l'impiego di SFC 14 opp. SFC 15
Con le CPU elencate nel seguito è possibile un accesso
consistente ai dati > 4 byte anche senza l'impiego di SFC 14
opp. SFC 15. Il campo dati di uno slave DP che deve essere
trasferito in modo consistente, viene trasferito ad una immagine di
processo parziale. Le informazioni in questo campo sono poi sempre
consistenti. Poi è possibile accedere all'immagine di processo
tramite istruzioni di caricamento/trasferimento (p. es. L EW
1).
Questo offre possibilità
di accesso ai dati consistenti particolarmente confortevoli e di
elevate prestazioni (carico per il tempo di esecuzione molto
limitato). In questo modo è possibile un collegamento e una
parametrizzazione efficiente di p. es. azionamenti e altri slave
DP.
Questo vale per le seguenti CPU a partire
dalla versione firmware 3.0.
|
CPU S7-400
|
LISTINO |
| CPU 412-1 |
6ES7 412-1XF03-0AB0 |
| CPU 412-2 |
6ES7 412-2XG00-0AB0 |
| CPU 414-2 |
6ES7 414-2XG03-0AB0 |
| CPU 414-3 |
6ES7 414-3XJ00-0AB0 |
| CPU 416-2 |
6ES7 416-2XK02-0AB0 |
| CPU 416-3 |
6ES7 416-3XL00-0AB0 |
| CPU 417-4 |
6ES7 417-4XL00-0AB0 |
| CPU 414-4H |
6ES7 414-4HJ00-0AB0 |
| CPU 417-4H |
6ES7 417-4HL01-0AB0 |
Tabella 1 CPU che consentono l'accesso dati consistente senza
SFC14/SFC15
In caso di accesso diretto (p.
es. L PEW opp. T PAW) non si ha alcun errore di accesso alla
periferia .
Importante per il passaggio
dalla soluzione SFC 14/15 alla soluzione immagine di
processo
-
Nel passaggio dalla soluzione
SFC 14/15 alla soluzione dell'immagine di processo non è
raccomandato contemporaneo utilizzo di funzioni di sistema e
dell'immagine di processo. Di principio l'immagine di processo in
scrittura con la funzione di sistema SFC 15 viene aggiornata, cosa
che non succede in lettura. Questo significa che non è garantita la
consistenza tra valori dell'immagine di processo ed i valori della
funzione di sistema SFC 14.
-
Lo SFC 50 "RD_LGADR" con la
soluzione SFC 14/15 indica altri campi di indirizzo rispetto alla
soluzione con l'immagine di processo.
-
Se si impiega un CP 443-5 ext
il contemporaneo utilizzo della funzione di sistema e dell'immagine
di processo porta ai seguenti errori: non è possibile alcuna
lettura/scrittura nell'immagine di processo e/o non è più possibile
alcuna lettura/scrittura tramite SFC 14/15.
Esempio
Il seguente esempio (per l'immagine di processo parziale
3 "TPA 3") mostra una possibile progettazione nella HW
Config.
-
TPA 3 in uscita: questi 50 byte si trovano consistenti
nell'immagine di processo parziale 3 (Lista "Consistente su ->
tutta la lunghezza") e possono quindi essere letti tramite i
normali comando di "Carica ingresso xy".
-
La scelta nella lista "Immagine di processo parziale
-> ---" sotto lo input significa: nessun deposito in una
immagine di processo. Esso è possibile solo con l'impiego delle
funzioni di sistema SFC 14/15.
Figura
3 Progettazione delle proprietà dello slave DP nella HW Config
|