Vai al contenuto
PLC Forum


Modbus RTU pic


EmilioP

Messaggi consigliati

Buonasera, sto cercando di implementare il MODBUS Rtu su un pic24f, fin'ora ho testato l'UART con un discreto successo ed anche il MODBUS Ascii sembrerebbe funzionare. 

Invece l'Rtu sembra necessiti di qualcosa di diverso rispetto alla periferica uart.

Avevo provato a cercare in rete, ma molte librerie per il modbus rtu sono obsolete con link non più funzionanti.

Se qualcuno mi può aiutare a gestire l'rtu, grazie.

 

Emilio

Link al commento
Condividi su altri siti


Che interfaccia Hw hai usato? Non puoi uscire direttamente dai piedini dell'uart ed andare sulla linea modbus.

Devi usare un drive RS485 o un drive RS422

Qui trovi tutti i comandi e gli esempi per implementare un colloquio con protocollo modbus RTU (Remote Terminal Unit).

Il link è un po' lento ma funziona. Ovviamente è un documento in inglese.

Link al commento
Condividi su altri siti

6 ore fa, EmilioP ha scritto:

Invece l'Rtu sembra necessiti di qualcosa di diverso rispetto alla periferica uart

No. L'UART è il cosiddetto Layer Fisico, cioè si occupa di inviare e ricevere dei byte su seriale.

Il ModBus (RTU, ASCII o altri protocolli) utilizzano il layer fisico per veicolare i frame (messaggi) composti secondo protocollo.

Cioè, il Modbus è un protocollo a messaggi con una struttura ben definita e standardizzata, che usa la UART del processore per inviare e ricevere i messaggi.

Siccome la UART ce l'hai già funzionante, il Modbus userà le funzioni di libreria solo per inviare e ricevere.

La libreria Modbus si occuperà quindi di preparare il messaggio da inviare (se è un master), calcolare il CRC, inviare il messaggio, attendere la risposta entro un timeout definito. A ricezione messaggio, verifica eventuali errori, estrae i dati richiesti dal messaggio entrante.

Di librerie Modbus in C ce ne sono un sacco (anche per altri micro), e se appunto hai la UART sicuramente funzionante, devi solo impacchettare i dati e inviarli.

Link al commento
Condividi su altri siti

Grazie delle rapide risposte!

4 ore fa, Livio Orsini ha scritto:

Che interfaccia Hw hai usato? Non puoi uscire direttamente dai piedini dell'uart ed andare sulla linea modbus.

Devi usare un drive RS485 o un drive RS422

Ho usato un'interfaccia da TTL a USB così da poter leggere su un terminal a pc, in futuro userò un'interfaccia che mi permetta di andare su rs485.

Il Plc con cui mi interfaccerò sarà della elsist, mi permette di comunicare in modbus anche su rs232.

I test di comunicazione sono andati a buon fine, anche la lettura del protocollo ASCII non mi da problemi.

5 ore fa, Ctec ha scritto:

La libreria Modbus si occuperà quindi di preparare il messaggio da inviare (se è un master), calcolare il CRC, inviare il messaggio, attendere la risposta entro un timeout definito. A ricezione messaggio, verifica eventuali errori, estrae i dati richiesti dal messaggio entrante.

Di librerie Modbus in C ce ne sono un sacco (anche per altri micro), e se appunto hai la UART sicuramente funzionante, devi solo impacchettare i dati e inviarli.

Se non ho capito male l'UART in ogni caso invia dati in caratteri da 8 bit, mentre per l'Rtu necessito di inviare 16 bit, quindi basterebbe inviare 2 caratteri assieme.

Il problema resta con i 3,5 bytes all'inizio ed alla fine, devo calcolare un tempo di attesa iniziale e finale? 

Provando a connettere il plc al pc e passando da ASCII ad Rtu non riesco più ad interpretare i messaggi del Plc.

 

Spero abbiate capito il problema, grazie

Link al commento
Condividi su altri siti

Anche il Modbus RTU invia byte (8bit), solo i registri scambiati sono a 16bit, pertanto due byte successivi. Se prendi il numero di nodo e il comando, per esempio, sono dati a 8bit.

1 ora fa, EmilioP ha scritto:

Il Plc con cui mi interfaccerò sarà della elsist

Uhm... Bisognerebbe capire chi dei due è il client (master) e il server (slave). Il comportamento è leggermente diverso.

Nel caso che il tuo circuito sia client (master), sarà lui che comincia la comunicazione, inviando un messaggio al server (slave) cioè il PLC. Questo deve rispondere qualcosa entro un timeout da te definito, altrimenti avrai un avviso di mancata risposta (server sconnesso). In questo caso dei 3,5bytes (che sono un tempo ben calcolabile in base al baud rate) di attesa te ne freghi. L'unica cosa è che tra la fine della ricezione del messaggio di risposta e l'invio del successivo dovrai mettere tale attesa, per garantire che l'altro lato si sia rimesso in ascolto.

Se il tuo circuito è un server (slave), dovrà stare in ascolto (oltre a fare le sue cose), e appena arriva un messaggio per lui (basta guardare il primo byte che è l'indirizzo di destinazione), passerà all'analisi della risposta da inviare. Se deve inviare un messaggio di errore (dati non coerenti, errore CRC), dovrà aspettare quei 3,5bytes per consentire al master di passare in ascolto.

Tra ASCII (oramai non più utilizzato e molto più lento) e lo RTU, il protocollo è abbastanza diverso, per cui le routine (PLC e PC) dovranno essere adattate.

Link al commento
Condividi su altri siti

44 minuti fa, Ctec ha scritto:

Uhm... Bisognerebbe capire chi dei due è il client (master) e il server (slave). Il comportamento è leggermente diverso.

Rispondo alla tua domanda: in futuro il master sarà il plc, questo andrà ad interrogare i vari pic, 24f04ka201, e questi saranno collegati a dei sensori di temperatura.

Nei miei test il master, cioè il PLC, è stato collegato al pc tramite interfaccia ttl - 232 - USB, leggendo in modalità modbus ASCII ricevevo la serie :0x0x0x0x0x0x0x0x0x0x, in modalità Rtu i caratteri non erano comprensibili, che non sia leggibile con tale interfaccia? 

Quindi, se non ho capito male, con la stessa periferica Uart ed aggiungendo solo le due pause all'inizio ed alla fine (non trasmetto alcun dato?) di 3,5 bytes, dovrei riuscire a far funzionare tutto?

Link al commento
Condividi su altri siti

8 minuti fa, EmilioP ha scritto:

Quindi, se non ho capito male, con la stessa periferica Uart ed aggiungendo solo le due pause all'inizio ed alla fine (non trasmetto alcun dato?) di 3,5 bytes, dovrei riuscire a far funzionare tutto?

Si, esatto, sono solo pause lunghe 3,5 byte (che se prendiamo una velocità di 9600baud, un byte [in effetti 10bit se 8N1) sono circa 1.04ms quindi basta una pausa di 3.6ms circa. Se vai più veloce, ancora meno).

Se colleghi il PLC al PC, immagino che il primo abbia una RS232, pertanto NON E' TTL. Dovresti mettere solo un adattatore RS232-USB dal lato PC per leggere i messaggi. Ammetto che non ricordo per nulla il modbus Ascii, praticamente mai usato. Sono andato a rivedere: ogni messaggio inizia con il carattere 58 (:) o 0x3A, seguito dai caratteri del frame e termina con caratteri 13+10 (CR+LF) (0x0D+0x0A). Quindi il carattere 58 di inizio messaggio deve essere per forza presente. Se così non è, controlla i parametri di trasmissione (spesso l'ASCII lavora con 7 bit di dati e verifica parità e stop).

 

PS: ovviamente quando vorrai leggere tramite PLC più sensori sulla stessa linea, dovrai abbandonare la RS232 per passare alla RS485 (la RS422 in modbus serve a poco, nessuno risponde finché c'è una trasmissione in corso, tanto vale usare 2 fili anziché 4).

Link al commento
Condividi su altri siti

2 ore fa, Ctec ha scritto:

Si, esatto, sono solo pause lunghe 3,5 byte (che se prendiamo una velocità di 9600baud, un byte [in effetti 10bit se 8N1) sono circa 1.04ms quindi basta una pausa di 3.6ms circa. Se vai più veloce, ancora meno).

Ok, potrei farlo con un interrupt 

2 ore fa, Ctec ha scritto:

Se colleghi il PLC al PC, immagino che il primo abbia una RS232, pertanto NON E' TTL. Dovresti mettere solo un adattatore RS232-USB dal lato PC per leggere i messaggi. Ammetto che non ricordo per nulla il modbus Ascii, praticamente mai usato. Sono andato a rivedere: ogni messaggio inizia con il carattere 58 (:) o 0x3A, seguito dai caratteri del frame e termina con caratteri 13+10 (CR+LF) (0x0D+0x0A). Quindi il carattere 58 di inizio messaggio deve essere per forza presente. Se così non è, controlla i parametri di trasmissione (spesso l'ASCII lavora con 7 bit di dati e verifica parità e stop).

Si si, mi ero confuso, l'adattatore è un 232 - USB, il modbus Ascii è come dici tu, inizia con il 58 etc etc, quindi su quello nessun problema.

Il modbus Rtu mi dava p$dp$dp$dp$d, ed è qui il mio problema!

 

2 ore fa, Ctec ha scritto:

PS: ovviamente quando vorrai leggere tramite PLC più sensori sulla stessa linea, dovrai abbandonare la RS232 per passare alla RS485 (la RS422 in modbus serve a poco, nessuno risponde finché c'è una trasmissione in corso, tanto vale usare 2 fili anziché 4).

Si si, per quello ci avevo già pensato, ma prima devo sistemare la parte software 

 

 

Link al commento
Condividi su altri siti

Considera che in RTU non appaiono caratteri, ma dati binari puri. Cioè se invii un messaggio al destinatario 1, il primo byte sarà 0x01, quindi non appare niente su un emulatore di terminale. Devi usare una visualizzazione in esadecimale.

Link al commento
Condividi su altri siti

  • 1 month later...

Perfetto, grazie, ho ripreso in mano una settimana fa il progetto e lavorando direttamente con il Pic son riuscito a leggere i dati.

L'emulatore del terminale non mi faceva leggere i valori in esadecimale.

Ho creato le funzioni del Modbus sul pic e tutto funziona regolarmente.

Grazie della disponibilità 

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...