Scambio segnali profinet tra cpu 1515 F safety e ET 200SP Open Controller CPU 1515SP PC2

[Dust]

Buongiorno,

anzitutto spero che stiate tutti bene in questo brutto periodo lavorativo e spero che qualcuno riesca ad aiutarmi..

 

Mi trovo attualmente da un cliente per delle modifiche software e hardware su un impianto di recente installazione, l'impianto in questione ha una Cpu 1515 safety, dove gira solo la logica safety, ed un ET 200SP Controller Cpu 1515SP PC2, dove gira la logica dell'intero impianto. (il cliente ha voluto il plc safety separato dal resto.)

 

Ho notato che quando si premono i funghi di emergenza, oppure qualcuno attraversa le barriere di sicurezza, la potenza dell'impianto cade perchè la cpu safety fa il suo lavoro ma non ho nessun contatto dalla cpu safety al controller che fermi il ciclo automatico e metta l'impianto in manuale, quindi appena si resetta la potenza il ciclo riparte senza nessuna autorizzazione da parte dell'operatore, mi chedevo se posso utilizzare un contatto dal safety, quindi tramite la comunicazione profinet, per arrestare il ciclo automatico quando si premono i funghi di emergenza oppure quando qualcuno attraversa le barriere di emergenza, utilizzando il blocchetto PUT e considerando che il controller non è safety e non ho ingressi digitali disponibili.

 

Grazie mille a quanti mi risponderanno

 

[pigroplc]

la soluzione è I-device e scambi tutto quello che vuoi 

[Dust]

Grazie mille Pigrollc, I-Device è la soluzione che ho pensato anch'io ma la normativa prevede uno scambio segnali tra un Plc safety e un Plc non safety ed utilizzarli nella logica di funzionamento?

[pigroplc]

Un conto è la parte di sicurezza che deve essere gestita dal PLC apposito e un conto è la condizione logica di stato dell'impianto che non è vincolata ad alcuna normativa: in altri termini se premi emergenza al legislatore / certificatore interessa che gli attuatori si fermino secondo quanto definito nell'analisi del rischio, non gli interessa se passando tra le barriere tu commuti da automatico a manuale o "manuale saltellante" o altre diavolerie, la macchina si deve fermare.

Già predisporre un doppio PLC (a mio avviso decisione che vorrei approfondire) significa che l'incidenza del costo dell'hardware / software nell'insieme della commessa è trascurabile quindi il lavoro di analisi dei rischi sia stato approfondito.

Io rilancio I-device.

 

[ken]

Segnali safety puoi scambiarli con i-device se le due cpu sono F e nello stesso progetto. la tua cpu è standard ma se non scambi dati safety puoi faro benissimo. potresti convertirli in non fail safe e poi trasferirli.

 

una cosa simile la facevo molto tempo fa con S7-300 dove per la parte F utilizzavamo un ET200S-F cpu e una 315 o 317 per il programma standard. scambiavamo i vari segnali (banalmente il ripristino) in un modo che è molto simile a i-device. 

 

[Dust]

Grazie mille, l'unico dato che devo passarmi dalla cpu safety è potenza non inserita per fare in modo che, nella logoca della cpu standard, si interrompa il ciclo automatico mettendo l'impianto in manuale, questo fa si che al ripristino delle emergenze, sia l'operatore a dover selezionare il modo automatico, fino a ieri, al ripristino di qualsiasi emergenza, l'impianto ripartiva subito in automatico, questo perchè il ciclo stesso non veniva mai interrotto se un operatore passava le barriere di sicurezza. 

 

Quello che mi interessava capire è se il segnale che passo alla cpu standard dalla cpu safety, potenza non inserita che arriva dal blocchetto safety di ripristino emergenza, che a sua volta attiva i teleruttori generali nel quadro, è considerato un segnale safety oppure no.

 

In un altro impianto, qualche anno fa, veniva portato un +24 volt, proveniente da un contatto NO dei teleruttori generali di potenza, ad un ingresso digitale della cpu standard, questo ingresso veniva poi utilizzato per poter mettere l'impianto in automatico e passare in modo manuale se i teleruttori non erano attivi (potenza non inserita) ma l'ingegnere che ha fatto l'analisi dei rischi ci aveva avvertito che non era a norma perchè l'ingresso si poteva bruciare e incollarsi o, peggio, qualcuno poteva portare 24 volt diretti.

 

Che casino ste normative di sicurezza!!!!

Modificato: 27 ottobre 2020 da Dust

[ken]

Se devi passare un solo bit lo farei a filo, ovvio però considerare possibili ampliamenti futuri.

per il tuo problema dipende dalla valutazione del rischio.

Penso che la cpu F vada a tagliare in modo hardware la potenza e a te serva solo un segnale per dire potenza non inserita. per me può essere non F per due motivi:

1. vai in una parte non F del software, una parte standard e nel software standard possono stare benissimo bit non sicuri
2. la cpu che hai non è F (quella che gestisce la parte standard) quindi non puoi valutare bit F e non puoi nemmeno utilizzarli

 

1 ora fa, Dust ha scritto:

In un altro impianto, qualche anno fa, veniva portato un +24 volt, proveniente da un contatto NO dei teleruttori generali di potenza, ad un ingresso digitale della cpu standard, questo ingresso veniva poi utilizzato per poter mettere l'impianto in automatico e passare in modo manuale se i teleruttori non erano attivi (potenza non inserita) ma l'ingegnere che ha fatto l'analisi dei rischi ci aveva avvertito che non era a norma perchè l'ingresso si poteva bruciare e incollarsi o, peggio, qualcuno poteva portare 24 volt diretti.

Scusa, gli hai detto che la potenza viene tagliata in modo sicuro come ha valutato i rischi e quello che ti serve è solo un consenso per dire lo stato delle sicurezze?

[batta]

1 ora fa, Dust ha scritto:

Quello che mi interessava capire è se il segnale che passo alla cpu standard dalla cpu safety, potenza non inserita che arriva dal blocchetto safety di ripristino emergenza, che a sua volta attiva i teleruttori generali nel quadro, è considerato un segnale safety oppure no.

Quando sei fuori dalla parte safety, non è più un segnale "safety". Come se, dall'uscita di un blcco safety, tu andassi a pilotare un'uscita normale.
Ma questo non conta ai fini di ciò che devi fare, che riguarda la logica e non la sicurezza.
È come se, con un ingresso normale del PLC che gestisce il ciclo, tu andassi a leggere lo stato di un modulo di sicurezza elettromeccanico.
Volendo, se ti è più comodo, piuttosto che mettere in piedi una comunicazione per scambiare un paio di segnali, potresti usare un'uscita del plc di sicurezza (anche una uscita non safety) ed un ingresso del plc di logica.
Per aggiungere sicurezza al sistema, potresti usare un'uscita del plc di logica (che cade se cade la marcia) da inserire nella serie dei feedback delle sicurezze per consentirne il ripristino (se la marcia non è caduta, il ripristino delle sicurezze non è possibile).
Anche questo segnale potrebbe essere scambiato in rete ma, come dicevo prima, se devi scambiare solo un paio di segnali, soprattutto se le due cpu sono nello stesso quadro, quasi quasi lo farei con segnali cablati.

 

Sarei anch'io curioso, come Pigroplc, di conoscere le motivazioni che hanno portato all'installazione di due cpu distinte.

[Dust]

Ok, grazie mille a tutti, alla fine ho usato I-Device perchè non avevo più ingressi digitali disponibili, il cliente ha la fissa per la sicurezza quindi, nel momento del capitolato, ha voluto dividere la parte safety dalla logica con 2 plc distinti.

 

Grazie mille ancora, sempre molto disponibili.

[batta]

22 minuti fa, Dust ha scritto:

il cliente ha la fissa per la sicurezza quindi, nel momento del capitolato, ha voluto dividere la parte safety dalla logica con 2 plc distinti.

Avere due PLC separati non aggiunge assolutamente nulla alla sicurezza.
Comunque, se ha scelto di spendere di più per avere un impianto più complesso e per niente migliore, contento lui, contenti tutti.
Secondo me, sono solo idee sbaglaite che nascono da scarsa conoscenza del sistema.
 

[Dust]

Il 30/10/2020 alle 09:35 , batta ha scritto:

Avere due PLC separati non aggiunge assolutamente nulla alla sicurezza.
Comunque, se ha scelto di spendere di più per avere un impianto più complesso e per niente migliore, contento lui, contenti tutti.
Secondo me, sono solo idee sbaglaite che nascono da scarsa conoscenza del sistema.
 

Hai perfettamente ragione ma è stata una scelta del cliente in fase di capitolato.

[pigroplc]

5 ore fa, Dust ha scritto:

Hai perfettamente ragione ma è stata una scelta del cliente in fase di capitolato.

Quando si definiscono dei capitolati in genere si analizza in modo approfondito il progetto, ecco perché io sono sempre convinto che ci sia un motivo che determina la scelta. A me viene in mente per esempio un processo lungo che una volta avviato non deve essere interrotto per alcun motivo, tantomeno per una modifica del codice del safety durante il collaudo. A tal proposito una doppia CPU potrebbe avere questo vantaggio. Sono tutte ipotesi.....

[batta]

Sì, certo, può essere che qualche motivazione, più o meno valida, ci sia, ma non credo sia questa.
Se devo modificare la parte safety, cadono tutte le sicurezze, quindi l'impianto si ferma anche se la CPU che gestisce il processo non viene messa in stop.
Se devo arrestare la CPU che gestisce il processo (es. modifica alla configurazione hardware), non mi serve tenere in run la cpu safety.

Comunque non escludo in modo categorico che una motivazione, a noi non nota, ci possa essere. Personalmente, non mi sono mai trovato a lavorare su impianti che richiedessero una CPU dedicata al safety. Mi sono imbattuto, invece, abbastanza spesso, in pessime scelte messe a capitolato.
Ma, come dicevo, se il cliente ha voluto questa soluzione e paga per questa soluzione, siamo tutti felici e contenti.