Plc 1200 database sql

[Mister_X_]

Buongiorno a tutti, avrei bisogno di qualche consiglio riguardo la comunicazione per industria 4.0.
Finora ho utilizzato un gtaeway Weintek (cMT-G01) dove mettevo a disposizione le variabili da scambiare e il cliente con protocollo OPC-UA andava a leggere/scrivere i dati che gli interessavano.

Ho un nuovo cliente che mi chiede invece di usare "tabella di frontiera SQL". Premetto che non ho la minima idea di come utilizzare o creare la comunicazione in questo modo.

L'hardware che sto usando è un PLC Siemens 1214.

La prima domanda è: cosa intende per "tabella di frontiera SQL" e lato PLC cosa dovrei fare? Ci sono documenti o FB già pronte da usare?

Ho notato anche che sul Weintek cMT-G01 che uso spesso, c'è la possibilità di creare databse e viene nominato l'SQL, per caso può fare al caso mio? 
L'ideale sarebbe che io come faccio di solito, avessi la possibilità di mettere le variabili a disposizione sul dispositivo..

Qualsiasi consiglio è ben accetto.

Grazie.

[batta]

Io non lavoro con i database, e non so cosa sia una "tabella di frontiera", ma scrivere i dati in un database non è compito del PLC. Il PLC mette a disposizione i dati. Poi sarà un qualche applicativo su PC o HMI che si occuperà, eventualmente, di scrivere in un database. Ma dovrebbe essere chi gestisce il database che si legge i dati direttamente da PLC.

[Livio Orsini]

3 ore fa, Mister_X_ ha scritto:

La prima domanda è: cosa intende per "tabella di frontiera SQL" e lato PLC cosa dovrei fare?

 

La tabella di frontiera costituisce l'interfaccia per scambio dati tra 2 sistemi.

Queste tabelle servono a sincronizzare i dati tra i 2 sistemi. Ad esempio (tratto dalla documentazionen Office).

•  

  Quote

   

  • Quando si crea un collegamento ai dati, Access crea una connessione bidirezionale che sincronizza le modifiche ai dati in Access e nel database SQL.

  • Quando si importano dati, Access crea una copia unica dei dati, quindi le modifiche apportate ai dati in Access o nel database di SQL non vengono sincronizzate.

   

Per prima cosa dovresti capire se lao scambio dati è solo da PLC verso SQL o anche viceversa.

Normalmente dovrebbe essre che i dati vengono trasferi da PLC a data base.

Come suiggerito da Batta il PLC riserverà un'area di memoria contenente i dati da trasferire e sarà commpito del seistema in cui è ospitato il data base prelevare questi dati con modalità da stabilirsi.

Ad esempio nel PLC si alza un flag che indica che i dati sono stati aggiornati; il sistema di acquisizione capisce che deve prelevare i nuovi dati, esegue l'aggiornamento, quindi abbassa il flag per comunicare l'avvenuta ricezione.

 

[Mister_X_]

Quindi teoricamente mi basterebbe prevedere un db con i dati da scambiare e sarei apposto?

Aggiungendo il bit di “dati sincronizzati” come consigliato da Livio

 

Comunque il problema più grosso è che gli indirizzi ip del plc non sono conformi a quelli della rete aziendale 

[pigroplc]

 

3 ore fa, Mister_X_ ha scritto:

Ho un nuovo cliente che mi chiede invece di usare "tabella di frontiera SQL".

 questa soluzione comporta la composizione di un file che dev'essere creato su un pannello o su un PC della macchina, quindi il sistema superiore preleva i dati. Se la fornitura prevista nel contratto è il pannello Weintek, devi vedere se è fattibile scrivere un file SQL.
in questo link https://forum.weintek.com/sql-query-2/ viene mostrato come leggere e aggiornare ricette, mi prefiguro che sia quindi possibile fare il contrario.

 

[Mister_X_]

15 minutes ago, pigroplc said:

 

 questa soluzione comporta la composizione di un file che dev'essere creato su un pannello o su un PC della macchina, quindi il sistema superiore preleva i dati. Se la fornitura prevista nel contratto è il pannello Weintek, devi vedere se è fattibile scrivere un file SQL.
in questo link https://forum.weintek.com/sql-query-2/ viene mostrato come leggere e aggiornare ricette, mi prefiguro che sia quindi possibile fare il contrario.

 

Ottimo, il gateway che volevo utilizzare io non supporta quelle funzioni

 

L’HMI è sempre Weintek ma non è della serie cmt quindi non si può fare

 

Diciamo che la storia della tabella sql è stata chiesta dal cliente perché è in ritardo per la certificazione perché noi di base forniamo la predisposizione 4.0 tramite opc

Volevo capire se era fattibile col materiale che avevo a disposizione 

[batta]

53 minuti fa, Mister_X_ ha scritto:

Comunque il problema più grosso è che gli indirizzi ip del plc non sono conformi a quelli della rete aziendale 

Per risolvere questo problema ti basta aggiungere una scheda Ethernet sul PLC.

 

[Mister_X_]

41 minutes ago, batta said:

Per risolvere questo problema ti basta aggiungere una scheda Ethernet sul PLC.

 

6GK7 243-1BX30-0XE0
 

Tipo questa?

[drn5]

Il 1200 può scrivere dentro i database SQL. Se ti mettono a disposizione un server aziendale puoi popolarne una tabella come ti pare. Poi sarà loro cura prelevare i dati e farci quello che vogliono. In rete trovi tanto da cui prendere spunto. Lasciamo perdere il discorso di policy di sicurezza che sennò si apre un discorso infinito...meglio chiarire insieme al IT manager fin da subito.

Modificato: 28 dicembre 2022 da drn5

[Mister_X_]

7 minutes ago, drn5 said:

Il 1200 può scrivere dentro i database SQL. Se ti mettono a disposizione un server aziendale puoi popolarne una tabella come ti pare. Poi sarà loro cura prelevare i dati e farci quello che vogliono. In rete trovi tanto da cui prendere spunto. Lasciamo perdere il discorso di policy di sicurezza che sennò si apre un discorso infinito...meglio chiarire insieme al IT manager fin da subito.

Riusciresti a postare qualche esempio o qualche link?

 

Grazie

[drn5]

https://support.industry.siemens.com/cs/document/109779336/connecting-a-s7-1200-plc-s7-1500-plc-to-a-sql-database-?dti=0&lc=en-IT

 

Googla:  s7 1200 sql database

 

 

[drugo66]

Ciao,

effettuando una semplice ricerca sul web ho trovato questo:

https://www.google.com/search?client=firefox-b-d&q=Siemens+1200+SQL

 

Comunque, te lo sconsiglio: scrivere da un PLC direttamente su un database SQL comporta una serie di problematiche che non sono facilmente risolvibili (la rete, vedere i dati risulterebbe difficoltoso, etc.); in ditta dopo un inizio altalenante, alla fine abbiamo optato per una applicazione installata su un computer con la versione gratuita di Msc SQL Server; è l'App che comunica con il PLC e popola il database di frontiera; il server aziendale è collegato all'altra porta ethernet del PC (2 reti diverse). L'App l'abbiamo scritta in Lab View, ma si può fare con il linguaggio che preferisci, basta che sia in grado di comunicare con il PLC e leggere e scrivere da un database SQL.

In questo modo il PLC salva i dati in locale e, qualsiasi cosa accada al server, la macchina continua a funzionare mentre le 2 reti sono ben separate; avresti in più il costo di un computer e dovresti scriverti l'applicazione; il software Msc per il server e l'utilità per gestire il database (SQL Server Studio) sono gratuiti.

 

Alcuni mesi fa, sia per insistenza del cliente che per problemi di tempo, ne abbiamo fatta una con la connessione diretta PLC<->OPC-UA e ci stiamo mettendo le mani ancora adesso. Invece, come ti sto consigliando, all'inizio c'è dello sbattimento per scrivere/modificare l'applicazione e creare il database di frontiera, ma poi, una volta che hai verificato che i dati nel database ci sono e sono corretti, te ne dimentichi.

 

Ciao

[valvolina]

ciao,

Io con quel prodotto (cmt-g01) non ho mai fatto scritture e letture da un data base SQL,

invece con un CMT-SVR-100 ho già provato con Sql di Microsoft.

Ho dato una guardata per rinfrescarmi la memoria, con CMT-SVR magari meglio i nuovi CMT-SVRX.... piu potenti,

hai anche uno strumento in più rispetto ai CMT-G01 per la gestione data base,

vengono comunque gestiti data base MYSql oppure MS SQL.

Tutti i CMT-Srv.... hanno comunque due porte di rete con due indirizzi diversi,

da una parte prelevi dati dal plc dall'altra vai sul data base

 

un saluto

Valvolina

[batta]

3 ore fa, Mister_X_ ha scritto:

6GK7 243-1BX30-0XE0
 

Tipo questa?

Sì.

 

2 ore fa, drn5 ha scritto:

Il 1200 può scrivere dentro i database SQL. Se ti mettono a disposizione un server aziendale puoi popolarne una tabella come ti pare.

Sì, hai perfettamente ragione, si può fare.
Io però, come Drugo66, sono dell'idea che scrivere su un database direttamente da PLC comporti problematiche che sarebbe meglio evitare.
Io continuerei a spingere sulla linea che il PLC mette a disposizione i dati, e chi si occupa del database se li viene a leggere.

[Livio Orsini]

1 ora fa, drugo66 ha scritto:

Comunque, te lo sconsiglio: scrivere da un PLC direttamente su un database SQL

 

Concordo appieno con Drugo!

Accordati su come vogliano che sia fatta la tabella situata nella memoria del PLC, poi sarà compito del sitema superiore prelevare ed eventualmente scrivere i dati in quella tabella.

 

Se io fossi lo IT Manager aziendiale non acconsentirei mai, per problemi di sicurezza, che un dispositivo esterno acceda al data base aziendale.

Modificato: 28 dicembre 2022 da Livio Orsini

[drn5]

L'indicazione che ho dato è perché è quello che intetessa a @Mister_X_.

Anche secondo me il plc è giusto che non faccia questo lavoro su database. In molte occasioni lo faccio fare al pannello, in altre a datalogger esterni, in altre ad applicazioni scritte in nodred su ipc zimenz. Per me il plc deve fare il controllo di processo, tutto il resto è giusto che lo facciano altri.

[Mister_X_]

Grazie davvero a tutti.

Nei prossimi giorni ho l’incontro, proverò a spingere per mettere solo a disposizione i dati, vediamo cosa dicono.

 

 

[ifachsoftware]

Concordo col fatto che per scrivere su un SQL server , il compito dovrebbe essere demandato ad uno SCADA ossia il PLC mette solo a disposizione una DB con i dati oppure li pubblica tramite Opc UA.

Il problema del 1200 è che ha una sola scheda di rete che dovrebbe andare sulla rete aziendale con tutti i problemi connessi.

 

Per quanto riguarda la sicurezza , condivido una soluzione che ho realizzato in questi giorni proprio per l'industria 4.0 e che mi ha dato delle soddisfazioni.

Nel mio caso avevo un S71500 con 1 sola scheda di rete e bisognava interfacciarsi con la rete del cliente.

 

Il primo problema era che la rete del cliente era su IP differenti e si voleva tenere una separazione tra le due reti.

 

La cosa è stata risolta con un PN/PN Coupler che da un lato parla con L'S71500 e sull'altro lato parla con un S71200 a cui si aggancia uno scada che legge/scrive e logga su file SQL.

 

La lettura/scrittura nel mio caso avveniva su DB dell'S71200 , ma si sarebbe potuto tranquillamente farlo fare tramite OPC UA.

 

Il tutto a costi molto inferiori ad una CP di comunicazione che oltretutto in questi periodi hanno tempi di consegna non trascurabili.

 

Il vantaggio è che si scambia solo un sub set di dati e si ha la separazione fisica tra le due reti

 

[Livio Orsini]

5 ore fa, ifachsoftware ha scritto:

Il vantaggio è che si scambia solo un sub set di dati e si ha la separazione fisica tra le due reti

 

Claudio è veramente un'ottima soluzione

[Mister_X_]

6 hours ago, ifachsoftware said:

Concordo col fatto che per scrivere su un SQL server , il compito dovrebbe essere demandato ad uno SCADA ossia il PLC mette solo a disposizione una DB con i dati oppure li pubblica tramite Opc UA.

Il problema del 1200 è che ha una sola scheda di rete che dovrebbe andare sulla rete aziendale con tutti i problemi connessi.

 

Per quanto riguarda la sicurezza , condivido una soluzione che ho realizzato in questi giorni proprio per l'industria 4.0 e che mi ha dato delle soddisfazioni.

Nel mio caso avevo un S71500 con 1 sola scheda di rete e bisognava interfacciarsi con la rete del cliente.

 

Il primo problema era che la rete del cliente era su IP differenti e si voleva tenere una separazione tra le due reti.

 

La cosa è stata risolta con un PN/PN Coupler che da un lato parla con L'S71500 e sull'altro lato parla con un S71200 a cui si aggancia uno scada che legge/scrive e logga su file SQL.

 

La lettura/scrittura nel mio caso avveniva su DB dell'S71200 , ma si sarebbe potuto tranquillamente farlo fare tramite OPC UA.

 

Il tutto a costi molto inferiori ad una CP di comunicazione che oltretutto in questi periodi hanno tempi di consegna non trascurabili.

 

Il vantaggio è che si scambia solo un sub set di dati e si ha la separazione fisica tra le due reti

 

È praticamente la mia situazione.

Io volevo usare un gateway per mantenere gli indirizzi diversi ed usare opc. Il cliente però non vuole.

 

Una domanda, sul 1200 avete solo messo a disposizione la db oppure avete costruito la connessione  allo scada?

[Mister_X_]

50 minutes ago, Yiogo said:

leggo in questa discussione interventi da XX secolo, male

ai tempi ero quello che eliminava i vari protocolli per usare solo modbus, ma ora anche questo dimostra la sua età

pensare che il plc debba solo "controllare" il processo e non faccia scambio dati è un'idea che bisogna toglersi dalla testa

curioso anche il termine "tabella di frontiera" che probabilmente è una "traduzione curiosa" di front end, in itagliano si chiama dati condivisi e il modo principe per condividere i dati è OPUua

 

da questa premessa si può andare avanti i vili dettagli, ma ormai tutti i plc supportano OPCua per cui si tratta di organizzare in relazione alle esigenze i dati condivisi

stiamo mettendo in servizio (con un altro pllc, ma non cambia nulla) un sistema complesso dove il plc controlla il processo e carica i dati come sopra descritto

gli HMI (di un'altro vendor) fanno da interfaccia operatore, scambiano i dati con il gestionale e comunicano in modbusTCP con il plc centrale in HTML

i sistema è coordinato da dati condivisi tra i tre strati in OPCua

il vantaggio è che non si deve richiedere a livello di software applicativo lo scambio dei dati che è di fatto già IMPLICITO nella configurazione dei sistemi interessati

a livello di plc le unoiche comunicazioni gestite a livello software sono quelli con i sottostemi delle utilities, tipicamente con call modbus tcp perchè queti sistemi hanno plc molto "leggeri" che non supportano OPCua

Il mio problema è che opc-ha non è contemplato dal mio cliente e lui vorrebbe che fossi io a trovare una soluzione per adattarmi al loro operato…

[batta]

6 ore fa, ifachsoftware ha scritto:

Il tutto a costi molto inferiori ad una CP di comunicazione che oltretutto in questi periodi hanno tempi di consegna non trascurabili.

Non sono tanto sicuro che un accoppiatore PN/PN e una CPU 1200 costino meno di una CP. La CP per il 1200 credo costi circa come l'accoppiatore PN/PN.

[Livio Orsini]

2 ore fa, batta ha scritto:

Non sono tanto sicuro che un accoppiatore PN/PN e una CPU 1200 costino meno di una CP. La CP per il 1200 credo costi circa come l'accoppiatore PN/PN.

 

Batta visto il momento particolare bisogna considerare anche i tempi di consegna: sembra che per le CP abbiano tempi di consegna improponibili.

Se la differenza di costo delle due soluzioni è anche leggermente svavorevole alla versione con 1200, am la disponibilità è molto più rapida, vale sempre la pena.

[batta]

Il 30/12/2022 alle 08:10 , Yiogo ha scritto:

da questa premessa si può andare avanti i vili dettagli, ma ormai tutti i plc supportano OPCua per cui si tratta di organizzare in relazione alle esigenze i dati condivisi

Ma è esattamente ciò che, più o meno tutti, abbiamo suggerito.

[batta]

Il 30/12/2022 alle 11:38 , Livio Orsini ha scritto:

Batta visto il momento particolare bisogna considerare anche i tempi di consegna: sembra che per le CP abbiano tempi di consegna improponibili.

Sì, ma in questo caso si tratta di adottare una soluzione per aggirare il problema di consegna, non perché sia tecnicamente migliore o più economica.
Un vantaggio c'é: esponi sulla rete solo il secondo PLC. Ma, visto le sicurezze offerte dalle nuove CPU, personalmente non considero la cosa di importanza vitale.

 

Proprio per i tempi di consegna mi ritrovo ad aggiungere una CPU 1200 come I/Device solo perché la CPU il cliente ce l'ha a magazzino, mentre non trova un modulo di espansione Profinet in tempi accettabili.