Step7 + Sql

[dan64100]

Ciao,

Ultimamente ho visto svariati post ed ho anche avuto parecchie richieste, vista l’esperienza sulla parte di comunicazione lato PLC, di consigli/indicazioni sul modo più efficiente ma soprattutto economico di salvare e recuperare dati con un PLC da un database SQL.

Come molti qui, io sono nato, informaticamente parlando, quando i banchi avevano come output le lampade a 24 volt a baionetta : verde pezzo buono, rosso pezzo scarto Poi siamo transitati da pannelli HMI più o meno sofisticati, oggi sempre più spesso, anche per realizzazioni piccole, viene richiesto lo storage o il recupero ricette da un server remoto perché la tracciabilità è diventata fondamentale e quasi tutto viene gestito dai MES.

Ci sono tantissime soluzioni, più o meno sofisticate, dalle FB/FC all’interno dei PLC ai plugin per scada e OPC server, ma hanno tutte una cosa in comune : partono da 2000€.

Alla produzione di un impianto “importante” è sempre associato un budget di commessa altrettanto importante per cui tali soluzioni sono giustificate sia come complessità che come costo.

Se però come lavoro parliamo di una macchina piccola e/o retrofitting affrontato da un programmatore freelance o da una azienda piccolina, probabilmente il costo di una licenza di cui sopra rischia di pesare considerevolmente e chi commissiona il lavoro difficilmente accetta l’extra costo avendo già la risposta pronta : che ci vuole, i tecnici dell’IT con due righe di visual basic già salvano tutto quello che voglio sul server SQL.

Per questo motivo, ho avuto l’idea di scalare una mia applicazione che interfaccia i PLC con i DB SQL per renderla accessibile a tutti. Per scalare intendo ridurre il numero dei PLC ed il numero dei database gestibili contemporaneamente.

Premetto subito a scanso di equivoci : non ho intenzione di creare una demo che poi se volete acquistate il prodotto completo, io non vendo niente.

Il programma non avrà limiti di tempo o popup, per piccole applicazioni lo usate liberamente e spero vi possa tornare “utile a migliorare l’utile” per applicazioni grandi vi comprate uno dei moduli di cui sopra.

Mi piacerebbe il vostro parere, che non è scontato (se è gratis falla poi vediamo se serve ) ma anche per capire la fascia di utenza ed eventuali altre considerazioni sull' opportunità o meno di un’iniziativa del genere.
Stiamo parlando di un’applicazione completamente automatica che non richiede alcun prerequisito tecnico, non si programma nulla ne lato PLC ne lato PC, le DB che abbiamo nel PLC vanno già bene così. E’ sufficiente scrivere un file di testo per spiegare all’applicazione come sono strutturate le nostre aree di memoria.

Quindi didattica : zero.

Cosa ne pensate ?

[bigalex]

Ciao Davide.

La tematica che hai descritto è molto interessante e sempre più si richiedono salvataggi o storicizzazioni di dati di processo e di produzione (che provengono dal campo verso uno o più plc) su DBase e viceversa da DBase verso i plc (es. ricette, ordini di produzione etc.).

Come hai detto queste funzionalità solitamente richiedono software o tools con licenza il cui costo è comunque considerevole specialmente se riferito a piccole/medie appllicazioni.

A quali DBase pensavi di poterti interfacciare (MySQL , PostgreSQL , sqlite , MSSQL Server , Oracle , SAP .......) ?

Ti confermo sin da subito l'interesse ....

Quello che fai (Snap7 etc.) è qualcosa che difficilmente , almeno in ambito automazione , si vede messo in condivisione con la comunità.

Grazie per quello che fai e per l'ispirazione che trasmetti con il tuo lavoro.

bigalex

[dan64100]

Ciao,

I DB utilizzabili con drivers nativi e/o OLEDB sono:

MS SQL Server (da 2000 in poi) Express/Standard/Enterprise (Nativo/OLEDB)

MySQL (dalla 3.X in poi) Community/Enterprise (Nativo/OLEDB) (*)

Oracle (da 10g in poi) Express/Enterprise (OLEDB)

PostgeSQL (da 9.00 in poi) (OLEDB) (*)

MS ACCESS (97, 2010) (OLEDB)

SQLite3 (Nativo)

Poi con ODBC tutti quelli di cui sopra ed altri che forniscono un driver compliant ODBC.

I connectors sono tutti gratuiti tranne (*) cioè OLEDB per MySQL e PosrgreSQL che vengono venduti dai rispettivi produttori.

Al contrario, tutti i drivers nativi menzionati (MySQL compreso) sono già incorporati nell'applicazione e non bisogna installarli/configurarli.

Si potrà utilizzare un solo DB a scelta.

[bigalex]

M..chia !!!

[walterword]

credo che sia un'ottima iniziativa anche se a dire il vero la piccola macchina o il piccolo impiantino di solito non necessitano di DB locale o remoto , di solito funzionano con 4 ricette marce e 4 parametri

Poi ok il discorso economico ...ma gia pagano poco , quando pagano , i piccoli pasticcioni costruttori di ciofeche , poi regalargli pure accesso ai DB .

Personalmente a parte l'interesse tecnologico , non regalo piu niente a nessuno , se pagano hanno i db e quello che desiderano seno si fottono loro e le loro ciofeche , oppure chiudono che tanto per quello che servono ....

E' ora di finirala di regalare e lavorare gratis per quei 4 buiaccari che si fanno chiamare costruttori...opinioni personali ovviamente

Modificato: 19 giugno 2015 da walterword

[dan64100]

Se lavori con l'automotive anche la luce del capannone è connessa al DB e credo che in futuro anche gli altri settori seguiranno questa tendenza, quando e come chiaramente dipende da tanti fattori.

A maggior ragione, proporre la tracciabilità/storico o la gestione ricette da DB può essere un valore aggiunto anche per banchi/impiantini che non ne hanno stretta necessità.

Considera che SQL Express, MySQL Community e ORACLE Express sono gratuiti e hanno un impatto accettabile sul sistema e se proprio ci sono problemi di risorse si può utilizzare SQLite3 o ACCESS che sono single file.

Un sistema SQL completo può trovare posto anche su un Panel PC e condividere il sistema con WinCC Flexible senza alcun problema.

Noi programmatori abbiamo la (giusta) tendenza a badare al pratico : costi/benefici, funzioni utili si, porcherie no ecc.. e siamo abituati a snobbare l'informatica consumer.

E questo, secondo me, è un grossissimo errore, anche l'automazione è contaminata dalla generazione degli smartphone, il dirigente vuole leggere con l'iPhone un QR code sulle stazioni di un impianto ed avere la situazione aggiornata su pezzi prodotti, OEE e quant'altro, magari basta premere un softkey sul HMI Panel per avere le stesse informazioni e che si leggono anche meglio ma è da sfigati. Oppure da casa via internet vuole sapere la ricetta in uso su tal'altro impianto.

Non sono importanti le informazioni in se, che nella maggior parte dei casi non vengono nemmeno capite, ma avere la sensazione del controllo "smart", di vivere "l'internet delle cose".

Ci sono due approcci: ignorare tutto e continuare per la propria strada rischiando di fare la fine dei dinosauri da qui a pochi anni o imparare a fare business anche con queste vaccate. Io faccio piani quinquennali di innovation technology e la vedo sempre più complicata capire le direzioni giuste

Condivido pienamente quanto dici dei "buiaccari" e dei vari furbetti del quartierino, anche secondo me è meglio che chiudano tutti, almeno lasciano spazio ad aziendine/consorzi di gente "sana".

Mi sa che stiamo andando OT, ma ogni tanto qualche considerazione a latere sull'automazione può essere interessante. alla peggio arriva Livio e ci bacchetta

Ciao

[walterword]

sul fatto tecnologico la tendenza e' quella dello smartphone e/o controllare da un tablet ....

Ti ripeto , da un punto di vista tecnologico e' interessante e lo e' anche commercialmente entro certe fasce .

Quello che intendi tu e' integrare queste tecnologie nel "normale" con lo scopo di aiutare il programmatore progettista nello sviluppo di funzioni ad hoc con un costo low .

Pero' ormai siamo a livello che non vogliono piu nemmeno il pulsante di emergneza hw , nonostante sia obbligatorio .Ormai stanno diventando cari anche i plc

Andra' veramente a finire che richiederanno Arduino anche se non e' pensabile per ovvi motivi , magari con bleutooth o gps o wifi per fare i fighi ma soluzioni low cost

Aspetta ancora qualche anno e la fame vedrai ci porterà a soluzioni impensabili

La tecnologia e' sempre piu in ascesa , ma la povertà lo è ancor piu

comunque fai bene a portarti avanti ed avere nel cassetto le giuste soluzioni .Ormai a costi irrisori si possono acquistare o montare in casa delle piccle cnc , stampanti 3D , comprare elettronica di ogni genere , driver , motori , linuxCnc , GRBL , ect ect

Non sono soluzioni industriali , certo , ma fanno dei lavori eccezionali .Non sono a norme , certo , ma chi se ne frega , vedrai andando avanti ...le leggi andranno a finire nel cesso ....

[dan64100]

Se parli di macchine prodotte da cantinari per clienti cantinari allora tutto può succedere, è una realtà che non conosco direttamente per poterne parlare, ma tutto quello che affermi "mi torna".

Nelle realtà un po' più grandi, giusto quel tanto da essere considerate dignitose, fortunatamente c'è più attenzione alle normative ed alla bontà dell'automazione (ed è presente anche l'influenza dei grossi produttori di PLC che difficilmente si faranno sfanc....re da Arduino )

[walterword]

negli impianti presso i quali ho lavorato , T.....t, A....o ,D...g, T....i .... non ci sono certo gli arduini e nemmeno ci sono problemi di licenza di 10 stazioni HMI e 5-6 plc S4-400 o altro

Poi magari son cannati disegni , non c'e' una programmazione di lavori , manca la logistica , le macchine sono marce , ect ect ma il problema licenze non esiste

Daltronde una commessa da svariati milioni di euro non puo' permettersi di avere problemi di licenze , ce ne sono in esubero , forse troppe ed inutilmente

Per le macchine cnc , torni ect , anche li ho avuto modo di lavorarci , controlli numerici , brushless ect , non ci sono restrizioni di licenze o costi per i software

Ripeto , i problemi ci sono solo per quei buiaccari idioti che sono la piccola media azienda che vuole produrre tutto , bene , guadagnare e poi non vogliono nemmeno farti fare le pagine delle segnalazioni di allarme o di cicli automatici perche ti dicono che sei un costo e che non sono stati pagati per questo , cioe un impianto di 600-700 mila euro non prevede nel contratto che ci sia la gestione allarmi e cicli automatici senon previo pagamento

Questo per farti capire , un come se vai a mangiare la pizza e ti dicono che il pomodoro e/o la mozzarella sono da pagare a parte perche la loro pizza non lo prevede ....alche tu rispondi facendo notare che trattansi di focaccia e non pizza , ma loro negano l'evidenza ed insistono nel dire che e' pizza e non focaccia

Ovviamente , visto che sei un ragazzo intelligente , ti lascio immaginare la mia reazione ed il mio comportamento. Cioe' dopo aver invitato capo generale , vari schiagnozzi della corte ect , a raggiungere il luogo idoneo dove poter fare la cacca , ho fatto come dicevo io .

Questo e' piaciuto ai clienti che sono aumentati anche grazie ad un'automazione fatta in un certo modo , che non prevede il collegamento di tecnici (pasticcioni ) al plc , ma che tutto si risolve da hmi .....

comunque son cose che sai gia benissimo .... questi sono i buiaccari costruttori di macchine italiani

Modificato: 20 giugno 2015 da walterword

[bigalex]

Ciao Davide.

 

Ci sono novità in merito a quanto avevi descritto inizialmente ?

Il tema è sempre più di attualità ed al momento si vedono solo "prodotti" che richiedono licenza a pagamento.

 

[Livio Orsini]

E' ferma da 2 anni, Walter sono mesi che non si fa sentire (magari sta mettendo in marcia un impianto in Uzbekistan), difficilmente potrai avere risposte.

[dan64100]

Quote

Ci sono novità in merito a quanto avevi descritto inizialmente ?

 

Sinceramente no, visto l'interesse "oceanico" 

 

Quote

Il tema è sempre più di attualità ed al momento si vedono solo "prodotti" che richiedono licenza a pagamento.

 

E con Industry 4.0 (sarebbe interessante aprire qualche thread in merito) lo sarà sempre di più.

Certo, non essendo una normativa, nessuno obbliga a fare nulla, ma il mercato si sposta in quella direzione e la selezione "darwiniana" diventa automatica.

 

Ciao

 

[Marco Mondin]

Con altri prodotti è molto più semplice ed economico, nel mio caso mi sono sviluppato una serie di librerie C++ (Uso pesantemente il framework Qt) che comunicano con vari prodotti come OMRON, QEM, B&R e le uso in diversi progetti. Con SIEMENS ho comunque delle librerie C++ derivate da una reimplementazione delle API IBHNet, però richiedono comunque un dispositivo collegato o su PROFIBUS o su MPI, tale dispositivo è comunque molto economico rispetto alle soluzioni OPC tradizionali ed è trasparente al PLC.

Lo uso per tracciabilità, gestione remota ricette, telegetione, remotizzazione, HMI evoluti su PC, gestionali per automazione.