Archivio FIFO

[batta]

5 ore fa, Livio Orsini ha scritto:

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

Probabilmente chiamiamo in modo diverso le stesse cose.

Come diagnostica intendo tutte le segnalazioni: messaggi, anomalie, allarmi di diversi livelli.

Se, all'entrata di un allarme bloccante, aggiorno la diagnostica solo per un ultimo ciclo, l'ultimo allarme segnalato (che sarà l'unico allarme bloccante) è l'allarme che ha causato l'arresto.
A questo punto è facile, con qualsiasi pannello operatore o scada, individuare l'evento che mi interessa con una suddivisione a gruppi o, semplicemente, visualizzando l'ultimo allarme entrato.

[batta]

2 ore fa, marco1278 ha scritto:

5 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

 

Se il problema è che le segnalazioni dei funghi, lette via Profibus dai moduli Pilz programmabili, ti arrivano in ritardo rispetto ad altri eventi, in questo modo non risolvi nulla.
Se, invece, hai la possibilità di sdoppiare i segnali dei funghi cablando un contatto aggiuntivo per avere un segnale diretto sul plc (in modo da leggere lo stato dei funghi senza quegli inspiegabili ritardi), allora non hai nemmeno bisogno dell'interrupt.

 

Ci sarebbe poi da capire perché siano necessari tre cicli del PLC per avere la diagnostica aggiornata.
E c'è da capire anche come sono gestiti gli arresti e la diagnostica.
Spiego cosa intendo.
Ci sono, fondamentalmente, due modi per gestire arresti e diagnostica.
Il primo modo gestisce gli arresti elaborando lo stato degli ingressi e del ciclo macchina, e poi si occupa della diagnostica elaborando nuovamente lo stato degli ingressi e del ciclo macchina.
In questo modo, il comando di arresto e la segnalazione dell'allarme potrebbero essere attivati in scansioni diverse.

Poi c'è il modo che preferisco: si parte a sviluppare il programma dagli allarmi (o, almeno, dalla loro dichiarazione), e saranno gli allarmi stessi a causare l'arresto.
 

Esempio banale: intervento di un magnetotermico.
Potrei usare l'ingresso dello stato del magnetotermico per arrestare la macchina, e poi usare di nuovo lo stesso ingresso per generare l'allarme.
Oppure, potrei usare l'ingresso dello stato del magnetotermico per generare l'allarme, ed utilizzare l'allarme per arrestare la macchina.

[marco1278]

Non posso collegare i feedback dei funghi perché dovrei tirare nuovi cavi e parecchio lunghi. 

 

Il fermo macchina è scatenato dagli allarmi. A software c'è un merker "cumulativo allarmi" che attiva la fermata della macchina.

 

[Livio Orsini]

3 ore fa, batta ha scritto:

Poi c'è il modo che preferisco: si parte a sviluppare il programma dagli allarmi (o, almeno, dalla loro dichiarazione), e saranno gli allarmi stessi a causare l'arresto

 

Questo è il modo che io intendo come modo corretto.

 

2 ore fa, marco1278 ha scritto:

A software c'è un merker "cumulativo allarmi" che attiva la fermata della macchina.

 

Se gestisci correttamente gli allarmi hai già l'informazione per avere lo stato macchina che ha causato l'arresto.

 

Batta io son più di vent'anni che non faccio uso di profibus, però credo di ricordare che c'era la possibilità di avere interrupt generati da profibus non ricordo se erano generati solo da allarmi del bus stesso (perdita di comunicazione, latenze eccessive, etc) o anche da eventi di macchina.

[batta]

43 minuti fa, Livio Orsini ha scritto:

Batta io son più di vent'anni che non faccio uso di profibus, però credo di ricordare che c'era la possibilità di avere interrupt generati da profibus

No, non mi pare si possano lanciare interrupt da Profibus (esclusi quelli di diagnostica), ma il problema non è una questione di interrupt, ma di ritardo ingiustificato dei segnali che arrivano, via Profibus, dal Pilz.
Addirittura, arrivano prima i segnali di fault dagli inverter per mancanza di alimentazione. Questo non ha senso.

[Livio Orsini]

Probabilmente c'è qualche cosa di errato nella configurazione della rete, però io non sono un conoscitore di profibus.

[batta]

Per poter dare indicazioni più precise, bisognerebbe essere sul posto.
Non credo però sia un problema del Profibus. O, almeno, in presenza di errori della rete, questi verrebbero segnalati con l'accensione del led rosso BF, e si troverebbero nel buffer di diagnostica della CPU.
Mi viene quasi da pensare che i moduli Pilz mandino un segnale ritardato anziché immediato.
Ma, per poterlo affermare, si deve accedere al programma Pilz.
 

[marco1278]

Non so, devo verificare che non ci sia qualche impostazione temporale sulla lettura dei pilz.

 

Comunque grazie per le dritte.