ModbusTCP invece di segnali hardwired

[kaifa.ab]

Salve a tutti,

Sto affrontando un progetto di un impianto con una CPU 1516-F in cui ho almeno 4 partner (ovvero altri PLC) con cui scambiare segnali/dati. Non sono ancora sicuro ma vorrei che lo scambio dei segnali/dati fosse realizzato in modo uniforme con ModbusTCP, sia per quanto riguarda i segnali "funzionali" come stati dei sistemi (pronto/marcia/allarme/...) sia per i dati "accessori" come conteggi/statistiche/storici/... I 5 sistemi si toccano dal punto di vista fisico e con questo intendo che i segnali di pronto/marcia/allarme servono per stabilire se e come fare interagire i sistemi, facendoli partire o fermare. In questo senso ho la sensazione che in molti preferirebbero avere pochi segnali hardwired per le logiche "funzionali" e comunicazioni ModbusTCP per conteggi/statistiche/storici/... però in linea iniziale ho pensato di mettere tutto su ModbusTCP, visto che si parla di sistemi che comunque possono interagire su tempi non strettissimamente legati (valutazione mia personale).

Non so se sono sufficientemente chiaro e nemmeno se sto chiedendo qualcosa a cui può essere data una risposta con questi pochi dettagli ma la mia domanda è:

"è un azzardo pensare che 4 canali di lettura/scrittura in ModbusTCP con al massimo 10/20 byte da scambiare per ciascun canale possano essere serviti in 2/3 secondi stando che tutte le comunicazioni siano funzionanti?" (se qualche canale comincia a dare time-out so che devo pagare retries etc... ma me la posso giocare)

 

Grazie in anticipo.

 

 

 

[Lucky67]

2 ore fa, kaifa.ab scrisse:

"è un azzardo pensare che 4 canali di lettura/scrittura in ModbusTCP con al massimo 10/20 byte da scambiare per ciascun canale possano essere serviti in 2/3 secondi stando che tutte le comunicazioni siano funzionanti?" (se qualche canale comincia a dare time-out so che devo pagare retries etc... ma me la posso giocare)

 Direi che 2/3 secondi per 4 stazioni 10/20byte (5/10 word) sono un'eternità....io già lo faccio senza problemi

[kaifa.ab]

"io già lo faccio senza problemi"

 

grazie mille per la tua esperienza, ti racconterò come procede.

[pedlo]

Quando non sai che protocollo usare, usa Modbus TCP. 

A vedere la mole di dati e la tua applicazione, così ad occhio puoi impostare il timeout della comunicazione ben sotto i 500ms. 

[kaifa.ab]

Vorrei aggiungere una domanda connessa alla CPU che sto usando CPU 1516-F e alle librerie software disponibili: io sto usando una sola FB di tipo MB_CLIENT e con un ciclo adeguato eseguo le varie richieste verso i vari slave (in un momento T0 è attiva una sola richiesta di lettura o scrittura verso un solo slave). So tuttavia che ModbusTCP è un protocollo orientato alla connessione e quindi mi chiedo se sia possibile usare contemporaneamente più FB di questo tipo che gestiscano ognuna uno slave distinto. Non so se sono stato chiaro.

[kaifa.ab]

Aggiornamento

Ho messo in comunicazione 2 partner dei 4 e funziona tutto a meraviglia, attendo di integrare gli ultimi 2 partner.

 

Chiarisco anche come sto usando MB_CLIENT:

- ho dedicato a ciascun partner una MB_CLIENT facendo attenzione al ConnectionId che deve essere unico per ciascuna FB, così facendo tengo attiva la comunicazione con tutti i partner contemporaneamente (senza dover sequenziare come si fa per un canale seriale, che a differenza del canale Tcp è a mutua esclusione);

- ciascuna MB_CLIENT segue una sequenza composta di 2 passi, uno per FC03 (Read Holding Registers) e uno per la FC16 (Write Multiple Registers);

- nei due passi della sequenza logicamente il codice modifica i parametri dell'operazione e esegue le operazioni coi buffer di lettura/scrittura a seconda del passo.

 

 

[TomCastagna]

Il 2/12/2019 alle 18:03 , kaifa.ab ha scritto:

Aggiornamento

Ho messo in comunicazione 2 partner dei 4 e funziona tutto a meraviglia, attendo di integrare gli ultimi 2 partner.

 

Chiarisco anche come sto usando MB_CLIENT:

- ho dedicato a ciascun partner una MB_CLIENT facendo attenzione al ConnectionId che deve essere unico per ciascuna FB, così facendo tengo attiva la comunicazione con tutti i partner contemporaneamente (senza dover sequenziare come si fa per un canale seriale, che a differenza del canale Tcp è a mutua esclusione);

- ciascuna MB_CLIENT segue una sequenza composta di 2 passi, uno per FC03 (Read Holding Registers) e uno per la FC16 (Write Multiple Registers);

- nei due passi della sequenza logicamente il codice modifica i parametri dell'operazione e esegue le operazioni coi buffer di lettura/scrittura a seconda del passo.

 

 

Ciao Kaifa.ab,

mi sto trovando nella stessa tua situazione, ma ancora in fase di progettazione. Io sul banco invece ho:
- 2 PLC Omron;

- 1 PLC Allen Bradley;

- 1 Applicativo Windows Based;

Il mio intento, forse non troppo diverso dal tuo, sarebbe quello di poter raccogliere i dati da ogni PLC, concentrarli ed immagazzinarli in un PLC 1.500 e poi consultarli / manipolarli su SCADA Siemens.

Come te vorrei adottare il Modbus TCP IP con la funzione MB_Client. Ti chiedo:

- anche nel tuo progetto stabilivi una connessione con PLC non Siemens come me?

- con tutti i tuoi 4 partner, riesci a non perdere mai dati o ricevere errori dal blocco MB_Client?

- un'applicazione con OPC UA non ti avrebbe servito meglio?

Io, per il momento, mi sono limitato a sperimentare tutto in fase di test con PLC 1214 ed un PC con Software Modbus Slave.

Grazie mille per l'attenzione!

Modificato: 5 gennaio 2020 da TomCastagna

[kaifa.ab]

Allora, due parole per TomCast:

- sto usando per ora 2 MB_CLIENT contemporanemente, alla fine ce ne saranno 4 e scambieranno tutte dati in parallelo coi rispettivi partner (basta fare attenzione all'univocità del mb_unit_id);

- la mole di dati che scambio coi partner dipende, da pochi byte 1/2 fino a 20/30 (quindi ancora pochi) e suppongo che le transazioni coinvolgano veramente pochi telegrammi ethernet (anche se è un azzardo dirlo visto che lo strato ethernet è più sofisticato di come lo sto figurando);

- la velocità delle comunicazioni è assurda, indefinibile, velocissima e robustissima, nessun errore, mai mai mai;

- un partner è un PLC Saya, l'altro partner è un PLC che non conosco e non ricordo, comunque non Siemens;

- in prova ho simulato comunicazioni del mio PLC 1500 con server ModbusTCP su macchine virtuali, fisiche, etc ... tutto ottimamente promettente!

 

Allora, i miei dubbi iniziali alla fine sono proprio scomparsi: diciamo che erano legittimi e prudenti quei dubbi in fase di progetto ma la prima risposta avuta da Lucky67 mi ha fatto ragionare e rischiare. MB_CLIENT è fatta veramente bene e ho usato solo MB_MODE 0 per leggere e 2 per scrivere.

 

Una sola cosa mi ha fatto imbestiare: col PLC Saya, non so perché, forse per colpa sua o forse per colpa di un dispositivo intermedio che fa da NAT per simulare che fosse nella mia rete (imprevisto) o forse per colpa di una sua errata configurazione da parte degli integratori, prima di riuscire a comunicare ho dovuto cambiare la porta di partenza della mia MB_CLIENT mettendo 100 invece di 0 (0 che funziona con tutto il resto). Mi sono imbestiato per modo di dire perché ho risolto io l'inghippo ma la faccenda che mi si è presentata era tale per responsabilità di una errata implementazione di aspetti che avevo progettato e indicato a tutti i coinvolti mesi e mesi prima! E vedete un po voi, come ca**o ho fatto a immaginare che fosse la mia porta di partenza non lo so ma alla fine l'ho cambiata e sono riuscito a comunicare. Ripeto che in prova ma anche in produzione la porta 0 di partenza non da alcun problema.

 

OPC UA non lo conosco così bene però grazie, vedrò di aggiornarmi. Nella mia mente quando penso a OPC UA penso a comunicazioni tra componenti eterogenee non tanto tra PLC e PLC, vedi tu quanto gnurant sono in materia. Nel mio caso ho un PLC di impianto con altri 5 piccoli impiantini all'interno e dovevo comunicare tra PLC e PLC.

 

MB_CLIENT su 1500 e un Modbus Slave (server) su PC e un altro su una macchina virtuale su stesso PC è quanto ti basta per simulare. Se dovessi avere problemi per fare diagnostica usa un Modbus Client (master) su PC ma considera sempre che stai simulando. La faccenda della porta 0 non avveniva ad esempio quando comunicavo da tool software con il PLC Saya, o meglio, il software Modbus Client che usavo per collegarmi a Saya in test magari si collegava partendo da un porta diversa da 0 e io non lo sapevo. Sempre per diagnostica potrà servirti Wireshark per vedere se stanno girando pacchetti ModbusTCP ma considera sempre se sei su reti switch-ate.

 

In bocca al lupo, sarà un successo sicuramente

 

[Marco Mondin]

Anche i normali socket TCP e i datagrammi UDP svolgono bene lo scopo!
Molte volte noi usiamo quelli senza scomodare tutto l'overhead del Modbus (Totalmente inutile in apparecchiature che supportano direttamente i socket).
I datagrammi sono i più semplici in assoluto per mappare strutture di campo fino a circa 4K di dimensione. Fino a quella dimensione sono più banali ed efficienti da gestire di un socket TCP, oltre è il contrario, con un filo in più di overhead.
Alla fine noi mappiamo tutte le strutture di processo in UDP con sincronizzazioni medie da 2 a 20mS (Dipende un po' dall'applicazione), quelle di Setup, Ricette, Supporto etc in TCP on demand con un nostro protocollo layer 7 proprietario.

Se tra le apparecchiature c'è un PC solitamente sviluppiamo un applicativo (servizio) che nominiamo Gateway su tale PC, concentriamo e smistiamo da lui tutte le comunicazioni.
Il ModBus TCP lo usiamo ancora, ma solo su quei PLC un po' arcaici che non hanno supporto diretto ai socket.

Il vantaggio di un socket TCP con apparecchiature moderne è anche quello di poter usare SSL (Disponibile solo con alcuni PLC e Runtime), garantendo una certa sicurezza dagli smanettoni in grosse reti aziendali. 

[kaifa.ab]

Marco, verissimo quel che dici, come sempre dipende dai vincoli dei sistemi che si devono scambiare dati: plc, schede elettroniche, microcontrollori, dcs, compact-pc, pc-in-one-board, etc... mi sono trovato in situazioni in cui perfino il ModbusTCP non era supportato (per quanto vecchio e standard).

Mi permetto solamente un'altra nota: sia ModbusTCP che SocketTCP/UDP viaggiano su Industrial Ethernet e questo è un aspetto che va tenuto in considerazione visto che non è raro che le connessioni attraversino hub, switch o altri dispositivi di rete che hanno un impatto sulla funzionalità e sull'affidabilità del collegamento. Oggi come oggi qualcuno preferisce ancora passarsi i dati sia digitali che analogici in modo hard-wired, i motivi possono davvero sussistere.