Sviluppare un semplice protocollo di comunicazione

[Anonimo]

Avrei la necessità di utilizzare un Vs prodotto SlimLine ARM7 come estensione di I/O remota connessa ad un PC via linea seriale. In pratica collegherei gli I/O del sistema SliLine all’impianto da gestire ed il programma sul PC eseguirà tutte le logiche acquisendo gli ingressi e gestendo le uscite tramite connessione seriale e/o TCP/IP.

Avete un esempio da cui partire per realizzare il programma sullo SlimLine ?

[Sergio Bertana]

Tutti i moduli CPU SlimLine gestiscono il protocollo Modbus ascii ed RTU su porta seriale ed over IP su connessione TCP/IP, in modo nativo. Il modo più semplice è quindi di gestire la comunicazione da PC utilizzando il protocollo modbus, con modbus è possibile leggere e scrivere registri nella memoria del modulo CPU. Il programma PLC eseguirà il semplice trasferimento degli ingressi digitali sui registri modbus letti ed il trasferimento dei registri modbus scritti sulle uscite digitali.

Ho realizzato un semplice programma DIOManage che con un programma FBD trasferisce 16 ingressi digitali nella WORD di memoria DInputs (Allocata a MX100.16) e trasferisce il valore della WORD DOutput (Allocata a MX100.18) su 16 uscite digitali. E’ possibile modificare il programma per gestire più registri di I/O, stampa e download programma.

Per accedere da modbus alla DB100 dove sono presenti i registri da gestire occorre definire indirizzo modbus 40000 seguito dall’indirizzo del registro da leggere (Nel caso di variabili WORD l’indirizzo deve essere diviso per 2). Quindi accedendo da modbus in lettura (Comando modbus 03 Read holding registers al registro 40008) sarà possibile leggere lo stato dei 16 ingressi digitali. Accedendo da modbus in scrittura (Comando modbus 10 Preset multiple registers al registro 40009) sarà possibile impostare lo stato delle 16 uscite digitali.

[Sergio Bertana]

Se l’implementazione del protocolo modbus sul PC fosse complessa ho pensato di realizzare un semplice blocco funzione EasyProtocol che gestisce lo scambio bidirezionale verso il PC. In pratica l’FB gestisce la ricezione di una stringa binaria di 4 bytes del tipo <STX><DOHigh><DOLow><LRC> e se corretta aggiorna lo stato delle uscite e trasmette una stringa binaria del tipo <STX><DIHigh><DILow><LRC>.

STX: Start of text (16#02)
DIHigh – DILow: Stato dei 16 ingressi digitali
DOHigh – DOLow: Stato delle 16 uscite digitali
LRC: Longitudinal redundancy check (Vedi Wikipedia)

L’uso di un LRC di controllo secondo me è essenziale per garantire la correttezza dei dati ricevuti specie su connessioni seriali. Naturalmente avendo scelto di utilizzare un protocollo binario al posto di uno ascii (Così ho dimezzato il numero di bytes da inviare) pone il problema della univocità del carattere si <STX>, nel campo dati potrebbero esserci valori che posono essere uguali a 16#02.

Per ovviare a questo inconveniente ho eseguito un padding dei dati, in pratica se uno dei dati assume valore 16#02 viene inviato prima il dato 16#FF e poi il dato invertito (Diventa <FF><FD>). Usando il dato 16#FF come padding è evidente che anche alla trasmissione del dato 16#FF deve essere aggiunto il padding (Diventa <FF><00>).

Allego stampa e programma sorgente LogicLab, dove viene utilizzata per la comunicazione la porta seriale COM0, basterà modificare la definizione dello stream sulla funzione Sysfopen per poter utilizzare un’altra porta COM e/o un socket TCP/IP.

Inviando la stringa binaria 02 01 03 FA, si attiveranno le uscite Do00M00, Do01M00, Do08M00, e verrà ricevuta la stringa con lo stato degli ingressi logici così come si evince dallo screenshot del programma Toolly. Da notare la stringa 02 01 FF FD FB, che attiva le uscite Do01M00, Do08M00 (Essendo il dato output low 16#02 viene fatto il padding e diventa FF FD).

Nella finestra di ricezione sono visualizzate 4 stringhe ricevute, nella prima nessun ingresso logico è attivo, nella seconda è attivo Di00M00, nella terza attivi  Di00M00 e Di01M00, nella quarta attivi Di00M00, Di01M00 e Di08M00.

[Autore]

Post