Fasce Orarie - su PC o PLC?

[pixel]

Salve,

sto sviluppando un sw. che simuli il funzionamento di grossi motori in un impianto di refrigerazione ad ammoniaca. Dato che sto sviluppando (sempre a livello di studio... ) un piccolo SCADA in VB.Net vorrei qualche consiglio per azionare e spegnere i motori seguendo uno schema a fasce orarie del distributore di Energia Elettrica.

Ad una prima valutazione mi è venuta in mente una soluzione : caricare il db delle fasce su PC che effettua la supervisione e attraverso questo comandare il PLC per Accendere o spegnere i motori. La soluzione abbastanza semplice mi sembra poco professionale ! posso sbagliarmi ma spostare delle logiche di gestione Automatiche su SCADA non è una decisione da prendere alla leggera (problemi di instabilità dei PC).

Considerando che il processo di automazione è sviluppato con S7-314:

1) come posso implementare un Database delle Fasce aggiornabile dallo SCADA che permetta al PLC di gestire il tutto?

2) quale SFC è più adatta allo scopo?

grazie

[Ecup]

Premesso che IMHO è molto meglio che queste cose siano memorizzate nel PLC, quanto spesso cambiano queste fascie orarie?

Caricare una DB (o dei dati in genere) dallo SCADA al PLC non dovrebbe essere un grosso problema, ma forse mi sfugge cos'è che vuoi fare realmente

[pixel]

Ciao,

le fasce dovrebbero cambiare ogni anno. Il problema è il seguente:

devo spegnere i motori quando si è in fascia F1 e F2 dove il costo dell'energia e più elevato. Energia e credo anche Enel forniscono il calendario delle fasce alle industrie. Ad esempio da Gennaio a Marzo dalle 8.00 alle 13.00 --> F1 (quindi l'impianto per quei mesi a quelle ore deve fermarsi), da Aprile ad Agosto dalle 8.00 - 15.00 --> F3 (quindi l'impianto può funzionare), una cosa di questo genere.

spero di essere stato più chiaro

[Matteo Montanari]

in questo caso ti serve fare solo dei confronti, lasciando stare SFC.

inoltre per sapere l'ora ti conviene elaborare il dato presente in OB1, senza scomodare SFC per leggere ora attuale...(controlla nei dati temporanei presente nell'OB1 )

[pixel]

...controllato... in OB1 ho una variabile Date_and_time devo utilizzare questa vero?

ora devo capire che formato ha la variabile e come operare il confronto solo su mese e ora.

grazie

[Ecup]

> devo spegnere i motori quando si è in fascia F1 e F2 dove il costo

> dell'energia e più elevato.

Per fare questo non è necessario usare SFC... basta fare dei confronti con la Data&Ora memorizzate dal PLC. Eventualmente puoi stabilire un sistema per verificarne la sincronizzazione con il PC dove girerà lo SCADA (in questo caso dovrai essere sicuro che sul PC la data&ora sia corretta)

Su come importare il database dell'Enel nello SCADA, non so... non ho mai visto il database dell'Enel... se è una cosa semplice, visto che cambia una volta all'anno, puoi anche pensare ad un banale inserimento manuale (anche se non è bello). Altrimenti puoi fare delle query che tirano fuori i dati utili e preparano una DB da trasferire sul PLC.

ciao

[Luca Bab]

Date & time

primo byte = Year ( 80-99 / 00-29 )

2 byte = Month ( 1-12 )

3 byte = Day ( 1-31 )

4 byte = Hours ( 0-23 )

5 byte = Minutes ( 0-59 )

6 byte = Seconds ( 0-59 )

7 byte = bo ????

8 byte = Day of the week with bit from 0 to 3 ( 1 = Sunday )

ciao

Luca

[pixel]

Grande Luca bab...

...per l'inserimento prevederò una maschera con una griglia dove verranno inseriti solo gli stati on del motore tutto il resto per Default sarà off.

Ecco un problema a cui non avevo pensato... la sincronizzazione col PC

... certo mi serve, non solo per settare la data / ora al momento dell'avvio, ma anche per i cambi ora estate / inverno. Quella Variabile temp Date_and_Time può essere scritta vero?

[Luca Bab]

Si , puo' essere scritta con SFC0

siccome e' un po' brigosa , solitamente rendo disponibili da Pannello ( da PC dovresti riuscire a fare la stessa cosa )

6 campi introduzione ( ATTENZIONE in BCD ) equivalenti ai primi 6 byte che ti ho indicato

poi con SFC0 aggiorno la CPU

La soluzione che utilizzo di piu' e quella che e' il PLC a tenere la data e ora , e la passa al pannello ( o PC )

quindi se hai la data o l'ora da mettere a posto , lo fai sulla CPU ( come ti ho descritto sopra )

Ciao

Luca

[Ecup]

>Ecco un problema a cui non avevo pensato... la sincronizzazione col PC

Io solitamente faccio una sincronizzazione scadenziata, oppure invio un segnale di sincronizzazione (con relativi Data&Time) ogni volta che accendo il PC di supervisione, ma io ho esigenze particolari di sincronizzazione con gli storici e visualizzazione dei trend in tempo reale.

Quando non ho queste esigenze, o utilizzo semplici pannelli operatori, una bella pagina con 6 campi per impostare anno-mese-giorno, ore-minuti-secondi

[MarcoEli]

Fasce Orarie.... hihihi....(rido perchè ci ho pestato io stesso le corna)

Per poter gestire la fasce orarie (fino al 31 dicembre sono 4 poi diventano 3) devi crearti una tabella con 8670 campi (8670 sono le ore ri una anno) in ognuno di questi campi devi inserire in che fascia sei.

Poi per avere un margine di tempo per aggiornare le fasce ogni anno dovresti riuscire a gestire 13 mesi in modo tale che hai un mese di tempo per caricare le fasce dell'anno nuovo (altrimenti dovresti farlo con la notte di Capodanno).

Comunque il sistema che vuoi tu esiste già. ed anche io ho rinunciato a farlo con il PLC anche perchè se non hai una tabella di inserimento "Comoda" ogni anno dei perderci ore a compilare la fasce (l'ho fato ieri).

Quindi questa gestione ti conviene farla con un modulo esterno.

Attenzione, non devi sincronizzarti con il PC, l'ora che conta è quella del Contatore Enel quindi attraverso la scheda ad impulsi devi sincronizzarti con "lui".

Modificato: 4 ottobre 2006 da MarcoEli

[pixel]

Ciao MarcoEli,

io pensavo di craere una griglia di dati (anche in excel) che comprendesse solo gli ON dell'impianto. L'utente deve solo inserire gli ON in corrispondenza delle Fasce a lui più convenienti. Insomma siccome lo scada lo faccio in VB.Net con l'interfaccia potrò sbizzarrirmi forse sono troppo ottimista...

Ma per il contatore va bene qualsiasi modello? esattamente come posso sincronizzare il PLC con il contatore?

[MarcoEli]

Allora, prima di tutto devi assicurarti che il contatore abbia la scheda ES (uscita ad impulsi) dopodichè devi "leggere" gli impulsi ai canali 3 e 4 rapportarli alle fasce orarie in vigore fino al 2004. Una volta che sai quando cambiano le fasce sai che ore sono.

Questo purtroppo, oltre alla tabellina devi caricarlo tutto nel PLC!! Ovvero il tuo programma in VB deve leggere e scrivere almento 8670 variabili (se sono On/Off puoi anche compattarle).

E' vero che in vb.net ti puoi sbizzarrire ma gestire tutta la tabella in un PLC diventa una cosa enorme.

Devi eseguire (e scrivere) 8670 confronti (se lavori con degli array potresti ridurli a 24).

Purtroppo per te l'unico SFC che puoi usare è quello per l'aggiornamento dell'ora.

Attenzione poi che il PLC non gestisce l'ora legale, devi gestirla tu.

Una volta era molto più semplice, ENEL dava fuori dal contatore le fasce orarie...........

Comunque, capisco il tuo spirito, anche io ho tentato di fare una cosa simile ed alla fine ho optato per una soluzione "già fatta" anche perchè la manutenzione di tale sistema è assai onerosa.

[Ecup]

Scusa, ma il database dell'Enel come viene fornito?

Se fai tu la supervisione, e quindi puoi fare quello che vuoi, basta che fai delle query sulle info che ti servono, e preparare al meglio i dati da trasferire in una (o più) DB per il PLC. L'importazione dei dati dell'Enel nel sistema di supervisione verrebbe fatto una sola volta all'anno, in automatico, senza richiedere compilazioni di fogli Excel o altre griglie (ammesso che Enel non cambi il formato di questo Daatbase).

Come strutturare i dati per le DB, dipende da come vuoi operare sul PLC.

Se tieni sincronizzato PC e PLC (oltre a sincronizzare il PLC con il contatore), e il PC è sempre acceso, potresti anche pensare di trasferire le fasce giorno per giorno, per semplificare il lavoro del PLC... ma personalmente non è una soluzione che mi piace...

Oppure (soluzione che prediligo perché mette al sicuro il funzionamento del PLC per un anno intero) puoi fare 12 DB, una per mese, ognuna con 31 UDT corrispondenti alla struttura giornaliera della fascia oraria; a quel punto il software del PLC avrà istruzioni indicizzate per leggere solo la DB giusta e solo nel punto relativo al giorno corrente. I confronti sarebbero ridotti alla sola UDT del giorno in questione. Non è elementare ma non è neanche troppo complesso (IMHO da fare rigorosamente in AWL...)

ciao

[Luca Bab]

Scusami , ma queste fascie orarie cambiano giorno per giorno ???

Se la risposta e' NO , da PC le scrivi sul PLC , le leggi ( quelle che hai scritto ) e se sono cambiate le riscrivi.

mi sembra la via piu' semplice e banale ( tenere tanti dati nel PLC non ha senso )

Ciao

Luca

[Ecup]

>Scusami , ma queste fascie orarie cambiano giorno per giorno ???

Boh... qualcuno ha parlato di 8760 variabili (che poi immagino siano 24h*365gg)

>Se la risposta e' NO , da PC le scrivi sul PLC , le leggi ( quelle che hai scritto ) e se sono cambiate le >riscrivi.

Ah beh, se fossero sempre fisse per tutti i giorni dell'anno, non credo che sussisterebbe il problema

Se però cambiano di giorno in giorno non si può pretendere che qualcuno li aggiorni manualmente di continuo...

>mi sembra la via piu' semplice e banale ( tenere tanti dati nel PLC non ha senso )

I dati, una volta che ci sono, non danno alcun fastidio, ed essendo ritentivi mettono al riparo da qualsiasi problema possa avere il PC. Se non ci sono problemi computazionali e se si scrive un programma che possa accedervi in maniera "intelligente" non vedo perché no...

ciao

[Luca Bab]

Forse mi sono spiegato male

Ah beh, se fossero sempre fisse per tutti i giorni dell'anno, non credo che sussisterebbe il problema

Se però cambiano di giorno in giorno non si può pretendere che qualcuno li aggiorni manualmente di continuo...

La tabella te la fai su PC , ( o mi sembra di aver capito che e' possibile ricavarla in automatico )

poi da pc scrivi nelle variabili del PLC ( solo quelle del giorno odierno ) e quando il PC vede che il giorno cambia ( ce la dovrebbe fare ) e le variabili del giorno sono diverse da quelle memorizzate nel plc , le va ad aggiornare

I dati, una volta che ci sono, non danno alcun fastidio, ed essendo ritentivi mettono al riparo da qualsiasi problema possa avere il PC. Se non ci sono problemi computazionali e se si scrive un programma che possa accedervi in maniera "intelligente" non vedo perché no...

Ritentivo e' un termine di cui si abusa , se la cpu parte , non sono piu' ritentivi ( le db prendono il valore iniziale )

Poi mi chiedo percke' memorizzare 8k di DB ( che magari ti obbligano ad usare una CPU con taglia superiore ) quando non serve.

Io credo che ci sono compiti che spettano al PLC ed altri che spettano al PC ( ovviamente se ce lo hai , se no va bene tutto )

tenersi delle tabelle da 8000 variabile e' un tipico compito da PC

Ciao

Luca

[pixel]

La soluzione dei 12 DB con UDT potrebbe essere buona...

Su questa scia avrei pensato... (ma mi rimetto al vostro giudizio non essendo molto pratico) :

1) definisco per ogni DB 31 variabili a 32 bit in cui posiziono dei bit 1 in corrispondenza degli ON dell' impianto. Considero quindi che per la variabile il bit meno significativo equivale allo stato ON/OFF alle ore 1.00 e il 24-esimo bit lo stato ON/OFF alle ore 24.

2)Una variabile a 32 bit viene shiftata di una posizione alla scansione di ogni ora

Esempio ore 1.00:

00000000000000000000000000000001 ----------> valore decimale 1

Quindi alle ore 8.00 del mattino la variabile assumerà il seguente aspetto :

00000000000000000000000010000000 -----------> valore decimale 128

la mia varibile della facia (quella specificata al punto 1), se deve determinare l'accensione dell'impianto dalle ore 8 alle ore 11 avrà il seguente formato:

00000000000000000000011110000000

3) Ogni ora faccio un AND tra la var shiftata e quella della Fascia

00000000000000000000011110000000 X

00000000000000000000000010000000

---------------------------------------------

00000000000000000000000010000000 ------------> valore decimale >0

4) se valore > 0 parte l'impianto

5) In funzione del giorno del mese mi vado a fare l'operazione sulla n-esima var del mio DB (es. oggi 5 ottobre ---> leggo la 5° Dword del 10° DB) :horny: :horny:

Che ne dite si può fare....?

P.S: X il momento programmo in KOP.

[Ecup]

>La tabella te la fai su PC,

Si, ma se ogni giorno cambia è impensabile che qualcuno debba aggiornarla in continuazione...

>(o mi sembra di aver capito che e' possibile ricavarla in automatico)

Spero proprio di si... ma in questo caso perché non ricavare in automatico tutto il necessario per l'intero anno, visto che la tabella Enel vale per l'anno intero?

>poi da pc scrivi nelle variabili del PLC ( solo quelle del giorno odierno ) e

>quando il PC vede che il giorno cambia ( ce la dovrebbe fare ) e le variabili del

>giorno sono diverse da quelle memorizzate nel plc , le va ad aggiornare

E se il PC è spento/guasto?

Io ragiono sempre nell'ottica di poter far funzionare l'impianto anche nell'eventualità in cui il supervisore sia guasto; il supervisore serve "solo" per visualizzare stati e allarmi, e memorizzare dati storici o grossi database.

>Ritentivo e' un termine di cui si abusa , se la cpu parte , non sono piu'

>ritentivi ( le db prendono il valore iniziale )

Se la CPU parte si ferma l'impianto, e il problema di avere dati coerenti non esiste; quando fai il ripristino della CPU schiacci un pulsantino sul supervisore che ti ricarica tutte le tabelle.

>Poi mi chiedo percke' memorizzare 8k di DB ( che magari ti obbligano ad usare una

>CPU con taglia superiore ) quando non serve.

Perché 8k di DB? Non servono mica INT o WORD...

Supponendo di avere 4 fascie e di volerle identificare ognuna con un bit (ne basterebbero due di bit se usiamo le combinazioni, ma è meglio stare larghi) avremmo 6 word per ogni giorno, che per 365gg dovrebbe fare poco più di 2k.

Se poi è il PC a decidere direttamente quando i motori devono essere ON o OFF in base alle fascie, basta trasferire nelle DB un solo bit, e quindi basterebbero 3 byte al giorno, che fa poco più di mezzo kb...

>Io credo che ci sono compiti che spettano al PLC ed altri che spettano al PC

>(ovviamente se ce lo hai , se no va bene tutto )

esatto... secondo me al PLC dovrebbe spettare il compito di assicurare il funzionamento corretto dell'impianto anche senza la presenza del PC (con i dovuti limiti che dipendono da caso a caso); buona l'idea di far decidere al PC direttamente l'ON-OFF, per limitare la dimensione delle DB... questo può essere un compito del PC, anche se toglie un po' di flessibilità: se il PLC ha gli identificativi di fascia, si potrebbero impostare dei parametri per decidere automaticamente quali fasce usare per fare ON o OFF.

>tenersi delle tabelle da 8000 variabile e' un tipico compito da PC

Non sono tabelle da 8000 variabili... sono 12 tabelle da 744 variabili, che nella migliore delle ipotesi sono 744 bit cioé 93 Byte, per un totale di poco più di mezzo kb (che non mi pare per niente eccessivo).

Nell'ipotesi di usare invece 4 bit, avremmo 12 DB da 186 Word, per un totale di circa 2k. Tra l'altro, con 4 bit ci si potrebbe anche pararsi il "didietro" nel caso in cui Enel aumenti il numero di fasce: 4 bit possono fare 16 combinazioni di fasce.

Se poi ci sono limiti sulla scelta della CPU è un altro discorso (deve fare solo questo o farà altro?), ma credo che il mezzo kb dell'ipotesi ON-OFF non sia un grosso problema...

Tutto questo, ovviamente, IMHO...

ciao

[pixel]

Sono d'accordo con Ecup sulla questione del PC (vedi mio Post iniziale). Anche perchè se devo proprio affidarmi al PC, tanto vale non caricare dati nel DB, Sincronizzare data e ora, etc... sviluppo una lociga sullo SCADA e abilito direttamente la variabile ON/OFF dell'impianto controllando data e ora del PC.

Il problema è che il PC deve solo supervisionare... emettere allarmi, dialogare con l'operatore, fare lo storico di variabili, etc. Se il PLC si ferma e poi riparte lo SCADA comunica all'operatore la necessità di ripristinare i valori.

Nell'esempio che ho fatto, considerando come diceva ecup che possono bastare 24 bit al giorno... (in realtà ho optato per 32 solo per una comodità, si lavora tutto con DWord) ...credo si impegnino circa 1,5 Kbyte (spero di non aver fatto mali i conti... )

[Ecup]

>La soluzione dei 12 DB con UDT potrebbe essere buona...

>Su questa scia avrei pensato... (ma mi rimetto al vostro giudizio non essendo molto pratico) :

>[...]

Non è esattamente come l'avrei fatto io (e ci mancherebbe... mica tutti ragioniamo allo stesso modo), comunque dovrebbe funzionare

[pixel]

bhè spiagami come l'avresti fatto tu.... magari è più conveniente...

[Ecup]

>bhè spiagami come l'avresti fatto tu.... magari è più conveniente...

Io avrei letto l'ora attuale del PLC e utilizzando i puntatori sarei andato a vedere direttamente se il bit interessato è a "1" o a "0".

Non so ancora bene come: dovrei mettermi a scrivere un po' per vedere il metodo migliore, per poi magari abbandonare questa idea e fare qualcosa di simile alla tua idea

Non chiedermi come utilizzare i puntatori in KOP però... io uso sempre l'AWL... non sono neanche sicuro che si possa fare in KOP quello che ho detto io.

[B_N_]

l'impostazione di ipotizare le fasce orarie e' sbagliata

puo' sbaglire l'orologio

puo' sbagliare l'ora legale

puo' cambiare il contratto

non funziona mai

e' molto piu' semplice

compri da enel la scheda, una volta costava sui trecento euro di acquisto niente canone

ignori l'ora che non serve a nulla

con quattro (o tre, non mi ricordo) ingressi logici decodifichi la fascia

sei sincronizzato sempre e comunque ad errore zero, anche se cambiiasse il contratto tutti i giorni

[pixel]

Purtoppo il contatore è troppo distante dall'impianto ed e' più complesso passare il cavo.