Archivio FIFO

[Ken75]

Salve a tutti,

avrei una domanda, mi è stato richieto un archivio FIFO per allarmi.

Ma esattamente, cosè un archivio FIFO?

Grazie

[Livio Orsini]

FIFO == First In FIrst out == il primo che entra è il primo a uscire.

Uno stack FIFO è un'area di memoria di "n" elementi in cui si memorizzano "n" dati, quando entra il dato n+1 automaticamente esce il dato 1, e così di seguito

 

Ad esempio se ho uno stack FIFO di 10 elementi posso memorizzare in sequenza 10 elementi, quando memorizzo l'undicesimo uscirà il primo, e così via.

[Max.bocca69]

La FIFO quando andavo a scuola ad un interrogazione ha spiegato cos'era la FIFA visto con lo sapeva. 

Su alcuni manuali la trovi descritta anche come memoria a scorrimento.

Con Siemens vedi anche il comando tabellla / table è comunque semplice l utilizzo.

Quando non c'era il commando in struttura  si copiavano i dati partendo dal penultimo alla locazione successiva ecc....

[Livio Orsini]

2 ore fa, Max.bocca69 ha scritto:

Su alcuni manuali la trovi descritta anche come memoria a scorrimento.

 

No questo è uno Shift.

 

FIFO, LIFO, FILO, LILO sono tutte memorie organizzate in "stack" o "pila".

Si riempe la catasta a partire da "sopra" o da "sotto"

La memoria a scorrimento o memoria shift è una coda circolare, dove i dati entrano, non escono, ed ad ogni colo di clock scorrono e quando il dato arriva all'ultima cella rientra nella prima.

[batta]

Io non capisco a cosa ti serva un registro FIFO per gli allarmi.

[Cialtrone]

un registro FIFO per gli allarmi in pratica è una tabella con gli ultimi allarmi in ordine cronologico.

supponiamo di fare un registro di 10 allarmi dove al posto 1 ho il più recente ed al 10 il più vecchio.

all'arrivo di un nuovo allarme copio il 9 nel 10, poi 8 in 9, 7 in 8... ed il nuovo allarme lo metto in 1.

Il metodo lo scegli come vuoi, anche in funzione di quanto dev'essere ampio il FIFO e di come sei più pratico.

 

p.s.: la maggior parte dei pannelli possono fare facilmente uno storico allarmi, col metodo FIFO, per migliaia di registrazioni.

Modificato: 15 luglio 2020 da Cialtrone

[batta]

Come si usa un FIFO lo so, ma non ne vedo l'utilità per la gestione allarmi. Questa era la mia domanda.

Poteva essere utile ai tempi in cui i pannelli operatore visualizzavano solo qualche riga di testo, e non avevano una gestione dei messaggi di allarme.

Ora che, anche il pannellino più stupido, gestisce gli allarmi, fare un FIFO nel PLC per gli allarmi non ha alcun senso.

A meno che non si tratti di un esercizio scolastico.

 

A mio avviso, l'unica cosa che, a volte, deve ancora essere gestita nel PLC, è la memorizzazione del primo allarme che ha causato l'arresto della macchina.

Ci sono macchine dove un evento ne causa altri in cascata in tempi molto rapidi, e da pannello operatore o da SCADA non è possibile discriminare quale sia stato l'evento scatenante.

Sulle rotative Cerutti, tanto per fare un esempio, veniva chiamato "primo fuori". All'entrata di un allarme che causa l'arresto della rotativa, la diagnostica veniva congelata, in modo da visualizzare solo l'evento responsabile dell'arreso. 

 

Modificato: 15 luglio 2020 da batta

[Livio Orsini]

3 ore fa, batta ha scritto:

Sulle rotative Cerutti, tanto per fare un esempio, veniva chiamato "primo fuori".

 

"primo fuori"  ===> First Out

 

Questo tipo di memorizzaziazione è detta anche "post mortem" perchè ti da la sequenza che ha causato l'arresto.

In alcune macchine l'allarme che causa l'arresto assume la condizione di "allarme pivot" e viene memorizzato lo stato significativo della macchine pre e post fermata; la profondità della memeorizzazioen di pende dal tipo di macchina e dalle risorse del sistema.

La doma nda di KEN75 è:

8 ore fa, Ken75 ha scritto:

Ma esattamente, cosè un archivio FIFO?

 

dal che si deduce che non sapendo cosa è un archivio di questo genere chiede lumi al forum.

Non dice dove dovrà implementarlo, se nel PLC, o nello HMI o altro.

La memorizzazione di allarmi in modo FIFO, ha una logica valid; si memorizzano in ordine cronologico di accadimento, ovviamente, e si visualizzona rispettando la cronologia di accadimento.

FIFO significa il primo memorizzato è anche il primo che sarà visualizzato, quando l'operatore ne chiede la visualizzazione.

 

Modificato: 15 luglio 2020 da Livio Orsini

[drugo66]

Ciao,

tempo fa mi era stata chiesta una cosa simile per gestire un visualizzatore enorme, posto sopra la macchina, visibile fino al gabbiotto del capo turno che era intorno ai 50 metri dalla macchina; era un array di Dint che giravo in seriale al visualizzatore; i testi degli messaggi erano memorizzati nel visualizzatore; se il numero era uguale 0, non esistava messaggio; se maggiore di 0, visualizzava il messaggio corrispondente; ovviamente con più messaggi presenti, venivano visualizzati più messaggi a scorrimento.

[marco1278]

8 ore fa, batta ha scritto:

All'entrata di un allarme che causa l'arresto della rotativa, la diagnostica veniva congelata, in modo da visualizzare solo l'evento responsabile dell'arreso. 

 

😂 È un mese che sto diventando matto per creare una cosa del genere

[Livio Orsini]

9 ore fa, marco1278 ha scritto:

È un mese che sto diventando matto per creare una cosa del genere

 

No dai, stai scherzando.

[pilota60]

21 ore fa, batta ha scritto:

A mio avviso, l'unica cosa che, a volte, deve ancora essere gestita nel PLC, è la memorizzazione del primo allarme che ha causato l'arresto della macchina.

In un Webinar, Siemens diceva che con il Prodiag in qualche modo si può avere la possibilità di sapere qual'è il "first alarm", approfittando del fatto che il time in cui avviene un allarme si può visualizzare sul pannello anche a livello di millisecondi.
L'unico limite, e questo mi lascia un pò perplesso, è che questo è possibile solo se gli allarmi successivi al primo vengano riconosciuti non prima del ciclo successivo del primo allarme.
E questo non so che aiuto possa essere.

[batta]

9 minuti fa, pilota60 ha scritto:

L'unico limite, e questo mi lascia un pò perplesso, è che questo è possibile solo se gli allarmi successivi al primo vengano riconosciuti non prima del ciclo successivo del primo allarme.

Anche in una gestione da PLC se entrano due allarmi nella stessa scansione non riesci a discriminare quale sia il primo, ma le probabilità che intervengano due allarmi bloccanti nel giro di pochi millisecondi, è molto remota.

[pilota60]

56 minuti fa, batta ha scritto:

Anche in una gestione da PLC se entrano due allarmi nella stessa scansione non riesci a discriminare quale sia il primo, ma le probabilità che intervengano due allarmi bloccanti nel giro di pochi millisecondi, è molto remota.

Si, io intendevo che se una serie di allarmi, scatenati dal primo, vengono riconosciuti in un tempo minore del ciclo PLC, non si riesce comunque a discriminare il primo allarme, malgrado il time in mS.
Percui la cosa va affrontata diversamente, magari con una logica apposita.
Poi magari sbaglio...

Modificato: 16 luglio 2020 da pilota60

[marco1278]

Il 16/7/2020 alle 07:00 , Livio Orsini ha scritto:

 

No dai, stai scherzando.

 

No no. Come dice pilota 60 se ho un evento che ne scatena altri e questi salgono prima... Allora il plc visualizza gli altri e non quello scatenante... o almeno esce in mezzo a quelli. 

[Livio Orsini]

2 ore fa, marco1278 ha scritto:

No no. Come dice pilota 60 se ho un evento che ne scatena altri e questi salgono prima... Allora il plc visualizza gli altri e non quello scatenante... o almeno esce in mezzo a quelli. 

 

Certo se gli eventi sono letti tutti tramite le tabelle immagini risulta impossibile fare una selezione temporale.

Però gli eventi che provogano una fermata immediata in genere sono una piccola percentuale degli eventi di allarme e vanno trattati in maniera differente.

[batta]

2 ore fa, marco1278 ha scritto:

Come dice pilota 60 se ho un evento che ne scatena altri e questi salgono prima...

Cosa significa: "e questi salgono prima"?

 

Se ti entra un allarme e, in seguito a questo allarme, il plc comanda un arresto (o qualsiasi altra azione), altri eventi che saranno conseguenza dell'arresto avranno inizio dopo che il plc stesso avrà comandato l'arresto. Ma, a questo, punto, tu hai già discriminato l'allarme che ha causato l'arresto.

 

Oppure, può capitare, per puro caso, che ci siano due eventi, praticamente contemporanei, che causano l'arresto.

Ma quanto dura la scansione del plc? 5 ms? 10 ms? 20 ms?
Quante probabilità ci sono che, in 20 ms, entrino due allarmi che causano l'arresto?
Ti potrà capitare una volta su un milione!
E, comunque, se ti capita, è perché, casualmente, si sono verificati due eventi simultanei (simultanei per quello che è il real time di un plc), e non c'è un evento come conseguenza dell'altro, ma sono due eventi distinti, capitati, per puro caso, nello stesso istante.
Ma, se sono simultanei, non devi discriminare tra i due chi sia intervenuto prima, perché sono, appunto, simultanei.

 

Sinceramente, non riesco a capire dove sia il problema.
 

[Livio Orsini]

9 minuti fa, batta ha scritto:

Ma quanto dura la scansione del plc? 5 ms? 10 ms? 20 ms?
Quante probabilità ci sono che, in 20 ms, entrino due allarmi che causano l'arresto?

 

Batta supponi di avere 5ms di ciclo. Fotografi lo stato degli ingressi ma non sai, di quelli che hanno variato il loro stato, quando lo hanno fatto.

Come ho scritto prima gli eventi che causano un arresto immediato, in genere, sono in numero limitato e si gestiscono in modo diferente.

Quando occorre uno di questi eventi,oltre ad arrestare la macchina, si fa una "fotografia" degli in gressi leggendoli direttamente.

Modificato: 18 luglio 2020 da Livio Orsini

[marco1278]

Ho alcune macchine che hanno il sistema di sicurezza costituito da pilz programmabili. Funghi, carter e sensori di sicurezza sono connessi ai pilz.

I pilz sono collegati tra loro da due cavi digitali che fanno capo ad un pilz elettromeccanico presente nel quadro. Se viene premuto un fungo il pilz programmabile apre la catena digitale che fa cadere il pilz generale che toglie potenza ai motori. 

 

Il plc legge il feedback del pilz elettromeccamico direttamente con un ingresso e anche i feedback dai vari inverter e azionamenti sono letti con ingressi digitali. 

Il plc comunica anche con i pilz programmabili in profibus da cui legge lo stato di funghi, carter e e sensori. 

 

Ogni volta che viene premuta un'emergenza il plc si accorge prima che è caduto il pilz elettromeccanico o che un inverter è in errore. L'allarme del fungo arriva sempre per ultimo. 🤯

 

Per arginare questo problema stiamo provando a interbloccare e ritardare certi allarmi... ma il lavoro è parecchio macchinoso. 

 

Avere 10 allarmi a video per un fungo di emergenza premuto non è molto utile. 

[Adelino Rossi]

Parlando di cose antiche, esempio in raffineria e utilizzando dei relè venivano fatti i gruppi di allarme per ogni macchina. Ogni gruppo macchina gestiva gli allarmi in modo interbloccato, Nel visore allarmi il primo fuori lampeggiava, gli altri visualizzavano solo lo stato. L'operatore tacitando ovviamente azzerava tutto.

Con i plc è estremamente facile creare i gruppi interbloccati. In quanto ai tempi di rilevamento concordo che i tempi di reazione di una macchina elettromeccanica o di un processo siano relativamente lenti rispetto al tempo di ciclo di un plc.  Nella mia ultima attività, centrale elettrica turbogas la situazione era un po più complessa. i segnali di processo sono gestiti da un dcs relativamente lento e i segnali relativi alle turbine piuttosto veloci gestiti da un sistema più veloce, poi essendo una centrale elettrica c'era anche il problema di essere sincronizzati con la rete elettrica nazionale. Gli allarmi importanti e bloccanti vengono gestiti da un plc specifico, (solo per questo scopo) estremamente veloce e con connesso un ricevitore gps sincronizzato a livello nazionale che creava il registro temporale degli eventi a cui associava appunto ad ogni evento l'orario gps. Poi con procedura standard un terminale di supervisione scaricava la memoria del plc acquisitore e mandava in stampa. In ogni caso è ovvio che è necessario effettuare l'analisi del tipo di eventi e della loro velocità presunta.  

[batta]

2 ore fa, Livio Orsini ha scritto:

Quando occorre uno di questi eventi,oltre ad arrestare la macchina, si fa una "fotografia" degli in gressi leggendoli direttamente.

È esattamente quello che intendo, con una sola differenza: quando arriva un evento che ferma la macchina, memorizzo lo stato della diagnostica, non l'immagine degli ingressi (che poi dovrebbe essere interpretata).
In diagnostica troverò quindi presente un solo allarme bloccante: quello stesso allarme che ha causato l'arresto.
Male che vada, per pura casualità, potrò avere in diagnostica due eventi anziché uno solo.
È il "Primo fuori" di cui parlavo qualche post indietro.

[batta]

1 ora fa, marco1278 ha scritto:

Ogni volta che viene premuta un'emergenza il plc si accorge prima che è caduto il pilz elettromeccanico o che un inverter è in errore. L'allarme del fungo arriva sempre per ultimo.

Con "allarme del fungo" intendi quello che leggi via Profibus dai Pilz programmabili?
Se è così, dovresti indagare sul perché di questo ritardo.
Ma quanto è questo ritardo? Posso anche capire che i segnali dal Profibus arrivino con un piccolissimo ritardo rispetto al segnale cablato dal modulo elettromeccanico, ma che arrivino addirittura dopo il fault degli inverter, no.
Riesci a quantificare il ritardo dei segnali dei Pilz da Profibus?
Puoi risolvere, come probabilmente stai facendo, ritardando, nel PLC, la diagnostica degli allarmi del segnale dal modulo elettromeccanico e degli inverter, ma la vera anomalia è il ritardo della comunicazione Profibus con i Pilz programmabili.
Se è fattibile (non ho alcuna idea della complessità dell'impianto e di come siano distribuiti i cablaggi), potresti portare lo stato dei funghi direttamente su ingressi del PLC, anziché leggerlo via Profibus. Ma si tratta sempre di un rattoppo. I moduli Pilz devono comunicare lo stato dei funghi istantaneamente, non "con calma, quando gli risulta comodo".

 

Proprio in questi giorni (quando si dice: "il caso"!) mi è stato richiesto di intervenire, per apportare alcune modifiche, su una macchina da stampa (rotooffset) con un PLC S7-300 che gestisce la macchina, e con un PILZ (CPU 3056 con, mi pare, 32 DI + 16 DO a bordo, e 15 moduli remoti da 8 DI) che gestisce le sicurezze.
Mi sono dovuto rispolverare un programma che ho usato solo quando facemmo il revamping di quella macchina (il Pilz era già presente).
Sulla parte S7-300 non metto le mani da 8 anni, e sul Pilz da 12. Tra l'altro, il programma è stato sviluppato utilizzando il vecchio PSS3000, e credo non si possa convertire al più nuovo PSS Win Pro (o, almeno, io non ci sono riuscito).
Non vi dico con quale entusiasmo stia affrontando la questione. Pur di soddisfare il cliente, mi toccherà sopportare parecchi mal di pancia.

[marco1278]

Si, con allarme del fungo intendo quello che leggo dal pilz. 

 

I pilz vengono letti da una FC che poi mette i dati in una DB.

Gli allarmi sono generati da altre FC che attingono da questa DB e da altre. 

 

Per avere il quadro totale della situazione il programma impiega minimo 3 scansioni. 

 

La parte allarmi è una di quelle cose che mi mette sempre il mal di pancia. Ogni fornitore la geatisce in modo differente. 

[Livio Orsini]

12 ore fa, marco1278 ha scritto:

il plc si accorge prima che è caduto il pilz elettromeccanico o che un inverter è in errore. L'allarme del fungo arriva sempre per ultimo

 

Semplicemente si fa lo OR dei funghi che attiva un interrupt, questo sicuramente arriva prima di tutti gli altri; poi si leggono gli ingressi  dei funghi e si riconosce quale è stato premuto e lo si associa a "Emergenza n° x" nella presentazione su HMI

 

10 ore fa, batta ha scritto:

quando arriva un evento che ferma la macchina, memorizzo lo stato della diagnostica, non l'immagine degli ingressi (che poi dovrebbe essere interpretata).

 

Appunto devi trattare in modo differente gli ingressi relativi algli allarmi ed alla diagnostica.

 

8 ore fa, marco1278 ha scritto:

Per avere il quadro totale della situazione il programma impiega minimo 3 scansioni. 

 

Perchè li leggi attraverso le immagini.

[marco1278]

2 ore fa, Livio Orsini ha scritto:

Semplicemente si fa lo OR dei funghi che attiva un interrupt, questo sicuramente arriva prima di tutti gli altri; poi si leggono gli ingressi  dei funghi e si riconosce quale è stato premuto e lo si associa a "Emergenza n° x" nella presentazione su HMI

 

Sai che non ci avevo mai pensato 😁