Download del PDF dell’intera serie di articoli sul Modbus
Il “Data Link layer” rappresenta il primo dei livelli di tipo software del protocollo Modbus e definisce come i bytes vengano scambiati tra un dispositivo e l’altro prescindendo tuttavia dal loro specifico significato. Questo livello prevede due diversi metodi di trasmissione delle informazioni.
La trasmissione di tipo Modbus RTU comporta uno scambio di frames binari dove i bytes possono assumere tutti i possibili valori 0÷255. Non potendo identificare l’inizio ed il termine di ogni frame di comunicazione in base a valori specifici dei bytes (caratteri di sincronizzazione) è necessario ricorrere alla gestione di timers che controllino l’esatta temporizzazione della trasmissione. In alcuni sistemi la gestione di queste temporizzazioni, i cui tempi possono essere anche molto brevi alle più elevate velocità di comunicazione, può essere onerosa e costituire un problema.
La trasmissione ASCII invece è ottenuta codificando il valore di ogni byte dell’informazione con la sequenza di due caratteri di testo esadecimali (cifre 0÷9, A÷F). Il protocollo ASCII è meno efficiente del protocollo RTU in quanto ogni byte di informazione è codificato da due caratteri. Tuttavia questa codifica consente di riservare dei caratteri speciali allo scopo di essere utilizzati come indicatori (caratteri di sincronizzazione) di inizio e fine frame. Questo semplifica notevolmente la gestione della trasmissione in particolare in sistemi più lenti o non dotati di particolari dispositivi hardware per implementare il controllo di temporizzazione necessario invece al protocollo RTU.
In questa serie di articoli sarà trattato solo il protocollo seriale Modbus RTU.
La comunicazione su rete seriale RS485 è di tipo half-duplex e ciò significa che solo un dispositivo alla volta può trasmettere informazioni sul bus. Questo richiede che la trasmissione effettuata dai vari nodi della rete sia coordinata in modo tale che non ci siano sovrapposizioni del pilotaggio della linea differenziale da parte di più di un dispositivo alla volta.
Il coordinamento della comunicazione è ottenuto assegnando ad uno dei nodi il ruolo di Master mentre a tutti gli altri quello di Slave. In genere la funzione di Master viene assunta dal dispositivo di controllo della logica dell’impianto, ad esempio il PLC, mentre tutti i dispositivi periferici e di espansione degli I/O operano come Slave.
Il Master controlla la comunicazione nel senso che è l’unico autorizzato ad iniziare uno scambio di informazioni. Periodicamente o su necessità, il Master inizia la comunicazione con uno degli Slave, inviando un pacchetto di bytes sul bus contenente l’indirizzo dello Slave interessato, la funzione da eseguire, gli eventuali dati associati alla funzione ed il checksum di controllo del pacchetto:
Il campo Address è costituito da un solo byte contenente l’indirizzo dello Slave interessato. I valori ammessi dal protocollo sono nel range 0÷247.
Anche per il campo Function è utilizzato un solo byte e questo contiene il codice comando della specifica richiesta allo Slave. Al codice funzione possono essere associati anche alcuni bytes di Dato specifici del comando fino ad un massimo di 252 bytes. I valori dei codici funzione ed il significato dei dati associati al comando saranno definiti nel livello successivo del protocollo (Application layer). L’insieme del campo funzione e del campo dati viene denominato Protocol Data Unit (PDU) e rappresenta la parte utile della comunicazione.
Al termine del frame sono aggiunti due bytes contenenti la parte bassa e la parte alta della word di checksum (CRC) calcolata su tutti i bytes precedenti. Questa word costituisce una firma relativa al contenuto del frame al fine di identificare eventuali errori nella trasmissione dei bytes.
Tutti gli Slave, normalmente in “ascolto” sul bus, riceveranno il frame trasmesso dal Master ma solo quello indirizzato continuerà la comunicazione mentre gli altri ignoreranno la richiesta.
Lo Slave interessato risponderà al Master inviando a sua volta un frame con la stessa struttura di quello appena descritto.
Il Master, una volta terminato lo scambio dei frames con uno Slave, potrà iniziare una nuova sequenza di comunicazione con lo stesso Slave oppure con uno degli altri procedendo allo stesso modo:
Lo Slave interrogato deve rispondere entro il più breve tempo possibile anche per non rallentare le operazioni di comunicazione con tutti gli altri Slave. Inoltre è importate gestire nel Master un tempo massimo prefissato (Timeout) entro il quale lo Slave deve rispondere per evitare di bloccare la comunicazione nel caso di Slave assente o guasto.
Il protocollo Modbus non specifica come eseguire l’aggiornamento delle informazioni nei confronti degli Slave per cui è possibile che il Master esegua le richieste in modo arbitrario, a seconda delle necessità, oppure in modo periodico (polling) per mantenere costantemente aggiornato la stato delle risorse degli Slave.
Ciascun byte del frame è trasmesso sul bus di campo RS485 mediante l’invio seriale di un totale di 11 bits, comprendendo il bit di start, il bit di parità ed il bit di stop:
Il bit di start vale sempre 0 e costituisce un riferimento di sincronismo per inizializzare la ricezione di tutti i bits del carattere. Dopo il bit di start sono inviati gli 8 bits del byte da trasmettere iniziando dal bit meno significativo. Successivamente è trasmesso un bit di parità per il controllo degli errori su un bit del dato ed infine un bit di stop (valore fisso ad 1).
Il protocollo Modbus permette di utilizzare una delle seguenti modalità per il bit di parità:
In realtà la specifica Modbus, anche se lascia piena libertà all’utilizzatore del dispositivo nella scelta della parità, obbliga al produttore di implementare nel dispositivo almeno la parità Even mentre raccomanda la disponibilità anche della configurazione “No parity”.
Si noti che, nel caso di “No parity“ il bit di parità è comunque presente in decima posizione e fisso al valore logico 1. Considerato anche il bit di stop in undicesima posizione, il carattere trasmesso ha quindi sempre un totale di 11 bits, anche in assenza di parità, come se la configurazione “No parity“ corrispondesse alla presenza di due bits di stop:
E’ piuttosto comune, in varie implementazioni del protocollo Modbus, trovare una configurazione di bits del carattere al di fuori della specifica ufficiale. Infatti, nel caso di “No parity“, alcuni dispositivi considerano la totale assenza del bit di parità portando a 10 il numero di bits totali del carattere. Questa configurazione corrisponde, per esempio, alla classica “9600,N,8,1” (nel caso di velocità di comunicazione a 9600b/s) particolarmente utilizzata su sistemi che non consentono di gestire la parità oppure su sistemi PC.
Nel protocollo Modbus RTU, tutti i bytes appartenenti allo stesso frame devono sottostare a delle rigide specifiche temporali, proprio perché, non disponendo di caratteri speciali da utilizzare come sincronismo, i pacchetti vengono riconosciuti ed isolati gli uni dagli altri in base esclusivamente alle loro temporizzazioni:
Ogni frame deve necessariamente avere tutti i propri bytes vicini tra loro con un tempo massimo, tra la fine di trasmissione di un byte e l’inizio di trasmissione del successivo, pari a 1.5
volte la durata del carattere stesso.
Inoltre per distinguere un frame da quello adiacente occorre che, dopo la trasmissione di un frame, ci sia una pausa pari a 3.5 volte la durata di un carattere. Questa pausa a fine frame, abbinata alla “compattezza” dei bytes dello stesso frame, garantisce la possibilità di distinguere e separare tutti i frames tra loro.
Un dispositivo in trasmissione dovrà quindi assicurare l’invio contiguo dei bytes del frame, per esempio preparando tutti i bytes fino al checksum in un buffer di trasmissione ed attivando successivamente l’invio dell’intero buffer sulla linea seriale.
In ricezione i dispositivi dovranno “catturare” immediatamente tutti i bytes di un frame riattivando ad ogni byte ricevuto un timer (a 1.5 caratteri) per controllare la contiguità dei bytes ed un timer (a 3.5 caratteri) per verificare l’effettiva fine di un frame. Dopo la ricezione di tutto il frame verrà controllata la correttezza del checksum e la corrispondenza dell’indirizzo di Slave.
Solo il livello successivo del protocollo (Application layer) analizzerà la correttezza della PDU ricevuta e in caso positivo provvederà a processarla.
Riguardo al campo indirizzo del frame di comunicazione, il protocollo Modbus utilizza i valori nel range 1÷247 per comunicare con un solo specifico Slave alla volta (modalità Unicast) mentre l’indirizzo speciale 0 è utilizzato per la modalità Broadcast. Una richiesta del Master con indirizzo 0 viene processata da tutti gli Slave ma nessuno di questi provvederà a rispondere al Master proprio per evitare conflitti di trasmissione sul bus. Questa modalità è utilizzata per inviare lo stesso comando contemporaneamente a tutti gli Slave senza però ricevere risposta e quindi senza alcuna conferma dell’avvenuta esecuzione del comando da parte degli Slave.
Infine gli indirizzi da 248 a 255 sono “riservati” e consentono al produttore di implementare delle specifiche funzionalità.
Il campo terminale del frame è costituito da due bytes corrispondenti alla parte bassa e alta della word di checksum (CRC). Questo valore permette di verificare l’integrità dei bytes del pacchetto in quanto costituisce una firma relativa ai valori dei bytes che precedono il campo CRC. In trasmissione il checksum è calcolato su tutti i bytes dal primo (indirizzo) all’ultimo del campo Dati ed aggiunto al termine del frame. In ricezione viene calcolato il checksum su tutti i bytes del frame ricevuto (campo CRC compreso). In tal caso, solo un risultato pari a zero indica la correttezza del frame ricevuto.
Per il calcolo del CRC si possono adottare due differenti approcci. Il primo è quello di un algoritmo completo che elabora i valori di tutti i bytes considerati e determina il valore a 16 bit del CRC. Il secondo è più semplice e veloce dal punto di vista del calcolo ma richiede l’utilizzo di una tabella di 256 bytes costanti precalcolate e questo su microprocessori con poca memoria programma può risultare più oneroso. Per maggiori dettagli su questi algoritmi fare riferimento al documento ufficiale del protocollo Modbus seriale:
http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Durante la comunicazione dei frames possono verificarsi situazioni anomale come la ricezione di un frame incompleto oppure con checksum errato. In tal caso i dispositivi Slave devono scartare questi frames e non rispondere mentre il Master, se verifica degli errori in una risposta degli Slave, potrebbe decidere di ritentare lo scambio dei frames.