Snap7 : La famiglia cresce

[dan64100]

Ciao a tutti.

Ho appena pubblicato un nuovo progetto : Sharp7

Come si può immaginare dal nome è il porting del core di Snap7 in C#, non un wrapper quindi, ma proprio l'implementazione di S7Protokol, lo stesso chè è avvenuto per Moka7 e Settimino per capirci.

 

I vantaggi, per chi programma in C# o VB.NET (vedi in seguito) sono i seguenti:

 

- Tutto codice nativo "safe" senza dipendenze da librerie di terze parti.

- Un unico file sorgente che contiene tutto : basta includerlo nel progetto e il gioco è fatto.

- Compatibile con il wrapper Snap7.net.cs, i prototipi dei metodi sono gli stessi con gli stessi parametri.

- Compatibile con Win32/Win64 e soprattutto con Universal Windows Platform, WinPhone e Win10 IoT (testato su Raspberry 3)

 

Al momento è l'unico driver sul mercato compatibile con la nuova tecnologia Microsoft UWP/NET Core/Win10App/Win10 IoT

Se avete quindi intenzione di abbracciare IoT per Industry 4.0 o per divertimento oppure volete scrivere App per Windows Store, avete un punto di partenza.

 

Se ho un po' di tempo cercherò di testare la compatibilità con Xamarin, dato che si appoggia ad UWP non mi aspetto problemi.

Nel qual caso sarà possibile produrre app anche per Android e IOS.

 

Per i programmatori VB purtroppo è necessario anche in questo caso includere l'assembly Sharp7.dll dato che non è possibile aggiungere nativamente in un progetto una classe C#.

Nella distribuzione comunque c'è anche un progetto di esempio VB.NET.

 

Ringrazio walterword per i test  (a proposito, scarica la versione definitiva, ho aggiunto altri metodi).

 

Trovate tutto nella pagina di Snap7 che sta diventando essa stessa una piattaforma 

 

Come sempre buon divertimento.

Davide

[Operational Amplifier]

Grande Davide,

Ti chiedo un consiglio, sono alle prime armi con C# e per ora stò effettuando i primi passi con i controlli base di visual studio 2015 (perchè ho acquistato il libro di Daniele Bochicchio C#6), il prossimo passo sarà quello di implementare la libreria snap7, mi consigli di partire direttamente con sharp7....?

[dan64100]

Se non hai necessità di funzionalità avanzate tipo il Server o il Partner si.

Nella distribuzione trovi anche un programma di esempio in C# che sfrutta la maggior parte delle funzionalità.

 

[Livio Orsini]

Ottimo lavoro come sempre.

[drugo66]

Concordo in pieno con Livio: complimenti !!!

[walterword]

oggi la scarico e la provo .

comunque funziona tutto correttamente , l'ho appena sostituita senza problemi.

Appena riesco faccio un video

[batta]

Sei un mito

 

[salto]

Ottimo lavoro, complimenti

[rmaz99]

Salve Davide,

tra poco dovro' iniziare un progetto software .net dove utilizzo per la prima volta le tue snap7. A proposito, complimenti per il lavoro, veramente completo, enorme e accurato!

A parte imparare l'utilizzo della libreria, vorrei chiederti se a livello di prestazioni c'e differenza tra l'implementazione nativa originale Snap7 e questa ultima Sharp7.

A naso direi che quella nativa e' piu' performante di quella in codice 'managed' di .net. Hai fatto qualche benchmarch? Io purtroppo non ho ancora a disposizione i PLC delle macchine, sono ancora in fase di 'studio', piu' avanti nello sviluppo faro' qualche prova e riferiro' i risultati.

Quello che devo implementare e' un modulo di lettura dati dai PLC (fino a una ventina, credo) , sia dai db sia altre variabili, allarmi ecc.. (non sono esperto di PLC, non conosco la terminologia corretta..) e riversare tutto su db SQL Server, da cui poi con altri software ricavo grafici e info sulle macchine. Dovrei leggere alcune variabili da ogni PLC ogni secondo, o anche piu frequentemente, mentre altre con periodi piu' lunghi e mi chiedevo se c'erano differenze significative di performance tra le due versioni di libreria o mi sto solo fasciando la testa prima di averla rotta...

 

Grazie 

Roberto

[dan64100]

Ciao,

Il tempo maggiore nelle comunicazioni e' quello dello scambio dati su ethernet, di elaborazione c'e' ben poco.

Fare dei benchmark accurati non e' facile, Snap7 (se compilata sotto Windows) setta ad 1 ms. la risoluzione del timer multimediale di sistema utilizzato per cronometrare le transazioni.

Sharp7, dovendo essere compatibile con UWP, utilizza Environment.TickCount la cui risoluzione va da 10 a 15 ms.

Inoltre l'efficienza delle VM .NET e' cresciuta enormemente (JIT, blocchi nativi, ecc..).

In ogni caso Sharp7 ed il wrapper Snap7.net.cs sono compatibili, puoi passare dall'uno all'altro in pochi secondi.

Ti consiglio ovviamente un'architettura multithread : un thread per ogni PLC.

I tempi di cui parli non sono assolutamente preoccupanti per Sharp7/Snap7, io utilizzo Snap7 "clockato" a 50-75 ms, ogni transazione compresa in un PDU rimane sotto i 10ms, quindi vai tranquillo.

 

Nel tuo caso invece, il collo di bottiglia del quale comincerei a preoccuparmi seriamente e' l'accesso al DB SQL.

Progetta attentamente l'architettura (anche hardware) altrimenti dopo gia' qualche mese di utilizzo gli accessi al DB superano il tempo di scansione dei PLC.

 

Per esperienza personale:

- Usa tabelle separate, una per PLC.

- Registra i dati grezzi senza modificarli, sposta tutto nella post-elaborazione che non e' realtime.

- Non ti "allargare" con i controlli eventuali prima degli insert, ogni select costa, se poi vai in joint su altre tabelle sei finito.

- Non lockare il DB, usa client separati (lui e' multiuser, i pool di connessioni li gestisce egregiamente).

- Crea dei trigger per la cancellazione dei vecchi record

- Gestisci la deframmentazione/cancellazione del log delle transazioni : cresce a dismisura e rallenta notevolmente il DB.

 

infine, anche se l'estate e' finita:

- Bevi tanta acqua, anche 2 o 3 litri al giorno

- Non uscire nelle ore piu' calde della giornata.

- Evita i cibi grassi, mangia frutta e verdura.

 

Saluti

[rmaz99]

Grazie mille per la risposta.

Per la parte di lettura dei dati mi tranquillizzano i tempi di cui mi parli. 

Oltretutto mi hai confermato il tipo di architettura multi-thread che volevo mettere in piedi.. non osavo sperare tanto!

Per la parte SQL sapevo già di dover penare, ma li' sono su un terreno piu familiare... comunque quella che mi suggerisci mi sembra la strada migliore.

I dati grezzi (insert 'secca' senza join o controlli approfonditi) verranno 'spostati'  periodicamente in un db differente, riordinati e catalogati con le dovute join per poi essere analizzati, in modo che il db di produzione non superi mai una certa dimensione.

 

infine, si' sara' una bella sudata... anche se e' quasi inverno terro' presente i consigli...

Grazie ancora

Roberto

 

[dan64100]

Dato che non hai ancora i PLC può interessarti un po' di "attrezzatura".

Qui trovi la presentazione di HMI-Tracer

Prepara i tuoi thread con i client e falli connettere tutti allo stesso indirizzo, quello del PC che ospita Hmi-Tracer (che può essere lo stesso PC di sviluppo).

Accetta fino a 1024 connessioni e qualunque operazione di lettura/scrittura.

Non puoi debuggare completamente il tuo protocollo ma puoi simulare le tue connessioni, verificare gli indirizzi delle aree che vai a leggere ecc.

[rmaz99]

Ciao Davide, 

in effetti ho passato la serata a spulciare il PLC Forum per vedere i post su snap7 e avevo visto anche questo interessante strumento..

Appena posso lo provo, devo ancora mettere in piedi un minimo di infrastruttura, anche perchè devo ancora discutere le esatte specifiche col cliente.

Sicuramente mi faro' sentire piu' avanti.

Nel frattempo grazie ancora. 

Roberto

 

[Operational Amplifier]

Diciamo che attualmente sto effettuando dei test tra un S71500 ed un Pc, di conseguenza utilizzo la libreria Snap7 Client, ma se io in futuro volessi usufruire di una tipologia tipo Server/Client, come dovrei procedere, per esempio accedere da più Pc con la stessa applicazione, cosa dovrei installare a livello di libreria Snap7 sui PC e cosa sul Server?  

[dan64100]

Non mi è chiaro chi è il client (quello che effettua la connessione e decide quando spostare i dati) e chi è il server nell' architettura che vuoi realizzare.

Se vuoi che la comunicazione sia gestita dai PLC, sul PC devi instanziare un S7Server il quale può servire fino a 1024 client ed i PLC diventano i Client.

I PLC comunicano con il server mediante GET/PUT e devi progettare una connessione "attiva" verso un partner generico.

Un altro modo è instanziare un S7Partner, puoi decidere chi apre la connessione ed in questo caso devi usare BSEND/BRECV lato PLC. Il vantaggio è che puoi trasferire più dati del singolo PDU, lo svantaggio è che la configurazione è un tantino più complicata (non tantissimo e ci sono gli esempi).

Comunque trovi tutto sul manuale 

In ogni caso la libreria è sempre la stessa che contiene i tre oggetti.

Se ho capito male spiegami meglio...

[Operational Amplifier]

Ciao Davide,
Effettivamente non mi sono spiegato benissimo, vediamo di chiarire il tutto, supponiamo di avere a livello hardware i seguenti dispositivi:

 

n°2 Plc S71500 in Campo

n°1 Pc Server (Sistema Operativo Windows Server 2012)
n°2 Pc come postazioni in Sala Regia (Windows 7)
 

I due Pc posizionati in Sala Regia hanno la funzione di supervisore impianto, in poche parole l'obbiettivo è quello di riprodurre un Sistema Scada Server/Client dove i Pc Client riescono ad accedere ai dati salvati sul Pc Server, ogni Plc comunica e scambia i dati dell'impianto che gestisce con il Pc Server.

Come svilupperesti con C# ed i pacchetti Siemens necessari un progetto del genere?

[dan64100]

Di strumenti ce ne sono tanti e sicuramente potresti anche spendere 0 (zero) utilizzando un'architettura adeguata.

Bisogna capire le funzionalità che vuoi implementare.

 

Se sui PC della sala regia hai WinCC o un'altro scada commerciale, le architetture possibili si riducono a quelle permesse dalle modalità d'interscambio degli scada.

Oggi gli scada (non winCC flexible ovviamente) possono accedere direttamente ai server SQL via ODBC.

In questo caso avresti gli scada collegati al server via ODBC ed i PLC collegati al server con Snap7.

 

Se poi hai degli HMI fatti da te il discorso cambia notevolmente, puoi fare praticamente ciò che ti pare.

 

Per capire che architettura utilizzare devi stabilire le parti in-process, quelle di supervisione e quelle out-process perchè la tecnologia dipende tutto da questo.

 

Esempio, se una stazione ha bisogno di sapere se un componente deve essere lavorato e per fare questo comunica con un server passandogli il datamatrix allora il server diventa in-process, devi stimare/calcolare/contenere il tempo transazione e devi curare la "disponibilità" dl sistema perchè se si ferma si ferma il processo.

Se invece il server trasferisce una tantum e on-demand le ricette e/o configurazioni varie o raccoglie dati (non veloci) diventa out-process cioè il sistema può continuare a lavorare magari in degrado per un periodo di tempo più o meno lungo.

 

Nel primo caso (o similari) devi mettere su una comunicazione multithread abbastanza veloce e parallela (ogni PLC un thread) che interroga i PLC e trasforma i pacchetti in query SQL (sto facendo delle ipotesi in base a quel poco che mi hai detto).

Nel secondo caso puoi comandare il server dagli scada (che sono l'interfaccia utente per l'impianto) per fargli mandare i dati ai PLC o possono gli scada stessi fare da gateway, loro si collegano direttamente al DB SQL e mandano/ricevono i dati dai PLC, in questo modo il server diventa un data-center puro e non devi scriverci software.

 

Se ti va di dare ancora qualche dettaglio possiamo scendere nei particolari.

 

Ciao

[Operational Amplifier]

Quote

Se sui PC della sala regia hai WinCC o un'altro scada commerciale, le architetture possibili si riducono a quelle permesse dalle modalità d'interscambio degli scada.

Oggi gli scada (non winCC flexible ovviamente) possono accedere direttamente ai server SQL via ODBC.

In questo caso avresti gli scada collegati al server via ODBC ed i PLC collegati al server con Snap7

 

Se possibile vorrei stare fuori dallo Scada WinCC, le applicazioni più impegnative vorrei svilupparle in C#.
 

Quote

Per capire che architettura utilizzare devi stabilire le parti in-process, quelle di supervisione e quelle out-process perchè la tecnologia dipende tutto da questo.

 

Sul Pc Server mi piacerebbe implementare una comunicazione multithread parallela con la libreria Snap7 Client che interroga i Plc (ogni Plc un thread) e che poi trasforma i pacchetti in query Sql.

A questo punto il massimo sarebbe poter leggere e scrivere questi dati dai Pc Client, cosa dovrei installare a questo punto sui Pc Client come Libreria Snap7....?

 

 

[dan64100]

Si, per ogni comunicazione con il PLC puoi usare Snap7 (a prescindere dal sistema operativo).

 

Potresti implementare un protocollo a "comandi" che è quello che utilizzo anche io ormai da molti anni.

 

Lato PC Client:

- Il PC Client della sala regia legge continuamente una variabile "comando" in una DB del PLC, basta un intero.

- Se il comando!=0 legge da un'altra area i dati associati a quel comando, li trasforma in query e li esegue sul server.

- Trasferisce al PLC l'esito e gli eventuali valori di ritorno.

- Azzera la variabile comando per evitare di rieseguire la query al ciclo successivo.

 

Ho diviso le letture comando e dati per mantenere piccolo il tempo di scansione ma se i dati sono meno di 480 byte (il PDU del 1500) puoi leggere tutto nella stessa passata, il tempo è praticamente lo stesso.

 

Lato PLC

- Quando c'è necessità prepara i dati  e poi valorizza la variabile trigger.

- Entra in attesa del fine comando o di un timeout (il PC client potrebbe essere spento).

 

Lato Server non devi fare praticamente nulla, al limite, se le query sono complesse, non ti conviene costruirle tutte lato PC Client.

E' più comodo chiamare delle stored procedures, ad esempio così : EXEC sp_xxxx <parametro1>,<parametro2>...

Così puoi modificare le stored procedures sul server "al volo" senza dover cambiare il tuo codice o fermare l'impianto.

 

Io ormai tutta la parte di protocollo con i PLC, trasformazione DB->Query, accesso a SQL Server/MySQL l'ho incapsulata in una DLL richiamabile da qualunque linguaggio.

E' sufficiente dargli in pasto dei files xml e crea automaticamente i thread, i client verso i PLC, quelli verso il database ecc..

PLC<->SQL non scrivo più una riga di codice.

 

[Operational Amplifier]

Non ci sono parole per descrivere la tua professionalità, veramente, spero un giorno di raggiungere anch'io il tuo livello tecnico.....  

[walterword]

usiamo anche noi xml per trasferire in streaming i dati tra i vari dispositivi e/o tecnologie.

Adesso stavo guardando anche json ... 

[walterword]

semplice video su Sharp 7

https://youtu.be/iMBRBOCF_-c?list=PLJmvUGejM2TMnTjn7t36wICKlkDoCLRE-

[Operational Amplifier]

Bello Walter....gli ho dato un occhiata ieri ma ci ritorno appena ho un attimo di tempo 

[walterword]

 

[dan64100]

Ottimo Walter