Comunicazione Plc - C#

[walterword]

Sto cercando di capire quale sarebbe la miglior tecnologia per scambiare dati tra un plc simatic e .NET , C# .

Tra le varie che ho realizzato finora vi sono opc server cari , client - server su tcp etc .

Lo scambio dati tra i due dispositivi deve essere il piu' veloce possibile .Sto pensando ad una connessione su protocollo UDP , anche se perdo qualche pacchetto non fa nulla , faccio dei controlli di integrità e se anche mi arriva subito dopo va bene lo stesso . Il pc deve ricevere continuamente lo stato di movimentazione di un complesso magazzino automatico e rispondere altresi.Salvare dati su sql database , eseguire logiche etc .

Sto scaricando tutta la documentazione di Snap7 e lo voglio provare .

Avete qualche idea?

 

[walterword]

Sto studiando Snap7 , è un progetto sviluppato da un professionista con le contropalle.

Bravo Davide Nardella 

[dan64100]

Grazie

Qualche considerazione che può tornarti comoda:

 

S7Protocol ha come unità base il PDU (protocol data unit) che è il più grande pacchetto dati, compreso l'header che puoi scambiare con la CPU.

Per tutta la serie 300, compresi i CP34X, è di 240 byte a cui corrisponde un payload di 222 byte. I 400/WinAC hanno 480 byte.

 

Il trasferimento dati con Snap7 è trasparente rispetto al PDU : i dati vengono "splittati" in pacchetti sequenziali ed ogni telegramma, tranne l'ultimo, viene saturato per la massima quota permessa dal PDU.

 

Ogni transazione (telegramma+risposta) richiede circa 5ms e se la funzione ritorna 0 sei certo che i dati sono stati letti/scritti correttamente.

 

Lavorando con UDP puoi risparmiare qualcosa come tempi ma, in caso di pacchetti multipli, devi assolutamente metter su un meccanismo di verifica della sequenza : nessuno ti assicura che due pacchetti vengano spediti e/o ricevuti nell'ordine in cui li hai commissionati, anche in una lan chiusa.

Abbiamo avuto molti mal di testa a causa di questo comunicando via UDP con alcune telecamere, in un collegamento praticamente peer to peer.

 

Se il pacchetto è autoconsistente, cioè non dipende dagli altri, allora non hai problemi : la perdita di un telegramma UDP in una lan è una leggenda, arrivano sempre

 

Per te che sai programmare una scelta vale l'altra, dipende solo dal contesto di sicurezza (un minimo di verifica di coerenza o di handshake se ti serve) e dalla velocità che vuoi ottenere.

 

Ciao

[walterword]

ok. 

E' molto veloce .Se il mio payload supera il limite che mi dicevi posso fare due tranches ...

comunque sto leggendo tutta la doc dalla prima pagina , è ben fatta  

[walterword]

dovrei progettare un 3-4 threads per questa applicazione, comprensivi di mutex etc

L'architettura sarebbe quella di leggere il max numero di bytes possibile e poi utilizzare i metodi del wrapper per "codificarli" in reali , interi , bool etc

 

[dan64100]

Se la CPU non ha molte risorse di comunicazione impegnate puoi allocare 3 o 4 client indipendenti (in thread diversi ovviamente) senza la necessita' di usare mutex aprendo quindi connessioni diverse sullo stesso indirizzo IP.

Le connessioni, lato CPU, vengono gestite "quasi" contemporaneamente, c'e' una coda ma e' abbastanza ottimizzata in quanto il processore di comunicazione e' indipendente dalla unita' logica.

 

Non devi preoccuparti del payload, le tranches vengono gestite automaticamente dalla libreria. Fino a 64kb non hai problemi.

E' un ulteriore vantaggio nel caso tu decida di usare mutex o critical section: schermi una funzione e sei certo che quello che trasferisci e' consistente (lato PC).

[walterword]

perfetto  

L'unico problema e' che qua al service non mi danno una cpu , alla ricerca e sviluppo nemmeno e nell'ufficio sviluppo manco a parlarne 

Per cui per ora solo teoria e studio a tempo perso e a mie spese....questo è il bel paese , va bene cosi 

Quote

 

 

[dan64100]

Se vuoi solo collaudare la comunicazione la soluzione c'è

In \utility\Windows\HMITracer\Win32 (o Win64) c'è HMITracer

 

 

ne ho parlato quì:

 

 

 

[walterword]

favoloso....un emulatore plc con cp server .... sei un genio   

Winsocket pipeline ...

[stilnovo]

Un saluto a tutti. E' veramente tanto che non scrivo in questo forum.

Approfitto della discussione per ringraziare Davide Nardella per aver partorito Snap7 e soprattutto di averlo condiviso con il mondo.

La documentazione supera per chiarezza e completezza tanti prodotti a pagamento, tuttavia ho difficoltà a comprendere bene cosa sia lo "smartconnect", e quale problema dobrebbe prevenire.

Inoltre, nei vari test che ho compiuto, ti confermo l'affidabilità / semplicità nell'uso. Solo su una cosa ho avuto dei problemi, ma non essendo una funzionalità fondamentale, non ho approfondito la cosa. Si tratta delle funzione che recupere la lista delle DB sul PLC. Praticamente, se non ci sono troppo DB, mi viene ritornato l'array con il numero delle DB trovate, ma se la lista è molto molto ricca (roba del tipo 500 DB), mi viene restituito un errore. Avevo pensato proprio ad un discorso di PDU, ossia che se eccede la capacità del PDU, ci potrebbe essere un problema di decodifica su frame splittati. Può essere ? o il problema è da cercare altrove ?

 

Ancora grazie di tutto

 

[dan64100]

Quote

 favoloso....un emulatore plc con cp server

No, e' solo un emulatore CP, a volte si hanno HMI senza sorgente e non si sa di cosa hanno bisogno in termine di risorse (DB ecc..)

Pero' attento se devi fare il profiling della tua app, e' multithread, se hai un numero di connessioni alto su un PC performante con una scheda a 1Gb/s ha delle prestazioni superiori a quelle di una CP reale (connessioni in coda e 100Mb/s)

 

Quote

ma se la lista è molto molto ricca (roba del tipo 500 DB), mi viene restituito un errore.

Si, e' un errore, ci sto lavorando (ad avere tempo....)

[walterword]

si infatti , l'emulatore va bene per testare le logiche , mentre per velocità e sincronismi ci vuole un plc o piu plc veri ovviamente