Dubbio su lettura/scrittura perifieria con DPRD_DAT e DPWR_DAT

[Cesare Nicola]

Da una vita leggo e scrivo dati da e verso una periferia utilizzando DPRD_DAT e DPWR_DAT. Leggendo l'. delle istruzioni ho notato una raccomandazione che mi era sempre sfuggita:
 

Quote

Note

If you are using the DPRD_DAT and DPWR_DAT instructions with consistent data, you must remove this consistent data from the process-image automatic update. Refer to "PLC concepts: Execution of the user program" for more information.

 

Non mi è molto chiaro cosa significhi e se sia realmente necessario farlo. Ne sapete qualcosa?

Grazie

 

[ifachsoftware]

Buongiorno , in pratica con DPRD_DAT e DPWR_DAT fai una lettura o scrittura immediata di dati senza passare dall'immagine di processo e questo potrebbe sballare la consistenza di certi dati che vengono garantiti dall'immagine di processo.

 

Personalmente al posto di queste istruzioni mantengo l'immagine di processo creando un udt che mappo all'indirizzo di partenza (come da questo esempio)

 

con il vantaggio di avere dei dati parlanti (naturalmente i dati vanno mappati nell'udt tenendo conto del little/big endian e del fatto che se devo prendere un solo bit , devo fare una struttura di 8 se no sballo le corrispondenze).

La stessa cosa vale per le uscite.

 

DPRD_DAT e DPWR_DAT Valgono per dati che magari devi leggere o scrivere immediatamente sotto interrupt , ed allora bisogna prestare attenzione a quel warning.

 

 

 

[Cesare Nicola]

Il 23/09/2025 alle 11:54 , ifachsoftware ha scritto:

Buongiorno , in pratica con DPRD_DAT e DPWR_DAT fai una lettura o scrittura immediata di dati senza passare dall'immagine di processo e questo potrebbe sballare la consistenza di certi dati che vengono garantiti dall'immagine di processo

 

A dire il vero io avevo capito che  fosse proprio il metodo che usi tu, che conosco, a poter "sballare" la consistenza dei dati. Qui un estratto dell'. di DPRD_DAT:
 

Quote

"DPRD_DAT" è necessaria in quanto con i comandi di caricamento che hanno accesso alla periferia e all'immagine di processo degli ingressi è possibile leggere in modo coerente un massimo di quattro byte contigui. È possibile leggere dati coerenti eventualmente anche tramite l'immagine di processo degli ingressi. Per verificare se la CPU utilizzata supporta questa funzionalità, leggere la documentazione corrispondente

 

E, sempre nell'., in "coerenza dei dati", si legge
 

Quote

Coerenza dei dati

Definizione

Un blocco di dati che non può essere modificato da processi simultanei viene definito come area di dati coerente. Un blocco di dati le cui dimensioni superano l'area di dati coerente può essere falsato nel suo insieme in fase di trasmissione. Ciò significa che un blocco di dati correlati che abbia dimensioni maggiori dell'area di dati coerente può essere costituito in uno stesso momento da blocchi di dati coerenti in parte nuovi e in parte vecchi.

Esempio

Si può verificare un'incoerenza quando un'istruzione di comunicazione viene interrotta ad es. da un OB di interrupt di processo con priorità maggiore. Se ora il programma utente modifica in questo OB i dati che in parte sono già stati elaborati dall'istruzione, i dati trasferiti risultano:

Pur non essendomi tutto chiaro, anzi, mi sembra che gli . dicano il contrario di ciò che sostieni? Cosa mi sta sfuggendo?

 

[ifachsoftware]

Rischi di inconsistenza

1. Accesso diretto all'immagine di processo

• Se leggi manualmente più byte (es. IB, IW, ID) in momenti diversi del ciclo PLC, potresti leggere dati parzialmente aggiornati.
• Esempio: leggi i primi 2 byte del peso, poi il PLC aggiorna il valore, e leggi gli altri 2 → risultato corrotto.

2. Dati non allineati o non contigui

• Se i dati sono sparsi o con padding, la lettura diretta può essere complicata e soggetta a errori di interpretazione.

3. Record aciclici con DPRD_DAT

• Se usi DPRD_DAT ma non gestisci correttamente il flag di completamento (DONE, ERROR), potresti usare dati incompleti o vecchi.
• Inoltre, la lettura aciclica è asincrona, quindi va gestita con attenzione.

---

✅ Come garantire consistenza

🔹 Metodo consigliato: copia atomica in un DB

• Usa un DB intermedio dove copi tutti i byte in un solo ciclo.
• Se possibile, usa blocchi di sistema o funzioni di copia strutturata (BLKMOV, MOVE_BLK, ecc.).

🔹 Usa UDT e strutture

• Se i dati sono strutturati, crea un UDT coerente e mappa i dati direttamente.
• Questo riduce il rischio di errori di interpretazione.

🔹 Sincronizzazione con flag

• Se la bilancia invia un flag di validità o aggiornamento, usalo per sapere quando i dati sono pronti.
• Leggi i dati solo quando il flag è attivo, e ignora letture intermedie.

---

🧪 Esempio di strategia robusta

1. Bilancia invia 12 byte ciclici via PROFINET
2. PLC copia i 12 byte in un DB strutturato in un solo ciclo
3. Usa CAST o MOVE per convertire i dati in REAL, INT, ecc.
4. Verifica il flag di validità prima di usare i dati