Comandi Manuali - Info&consigli

[Tec1]

Ciao a tutti,

devo realizzare un'interfaccia operatore su PC (un touch-screen con sistema operativo Windows Professional), collegato tramite una scheda di comunicazione Profibus ad un PLC (il cui programma viene realizzato da un'altra persona).

Mi è stato chiesto "verbalmente" di implementare in un'apposita pagina dei tasti a video che permettano di realizzare i comandi manuali in "jog" dei dispositivi di movimentazione presenti nell'impianto.

Pur non trattandosi, nello specifico, di un impianto "particolarmente pericoloso" mi chiedo:

- è ammesso dare dei comandi all'impianto passando per un sistema operativo diverso da quello del PLC e soprattutto "non deterministico" come Windows?

(intendo, cioè con dei tempi di latenza "variabili" introdotti dal s.o. e possibilità di eventuali blocchi del sistema stesso)

- il caso è contemplato in qualche norma? Se si, quale?

Ringrazio, anticipatamente tutti quanti saranno in grado di rispondere e/o di darmi qualche consiglio.

[Mbn]

Non mi risulta che ci siano norme al riguardo dando per scontato che il circuito di sicurezza (Emergenza) sia adeguatamente realizzato tramite le opportune catene e gli appositi circuiti.

Tutti gli altri comandi (ossia quelli non soggetti a prescrizioni di sicurezza) sono frutto delle modalità operative richieste.

Comandi via OP o pannelli operatore Touch o membrana sono molto diffusi.

Occorre però seguire criteri di progettazione che siano adeguati alle tipologie di comando e non generalizzare.

Ad esempio :

.comandare solo quello visibile dalla postazione (evitare comandi dal PC dell'ufficio)

. pensare che difetti dei terminali o delle membrane possano tuttal più attivare movimenti indesiderati e non fare danni

. comandi anche jog ma sequenziali (prima uno e poi l'altro). Diventa complicato gestire manovre manuali in contemporanea

. avvio arresto di cicli automatici mentre ad esempio inserzioni generali di impianti complessi sono più tranquillamente realizzate

da normali selettori

. per fare comandi a video devono esserci le pagine adeguate e considerare anche i tempi di accesso alle stesse.

. prevedere comunque che qualcosa non funzioni e pertanto procedure esterne almeno di arresto (es : se avvio un servizio

esterno da OP e poi questo si guasta : come lo fermo?).Pertanto appaiono selettori Blocco/loc/remoto anche a questo scopo

Su alcuni impianti ci sono terminali (anche doppi o tripli) specificatamente dedicati alle marce jog (es. 1 pagina con solo due pulsanti belli grossi).

Su altri i pannelli operatore sono 2 o più ma con le stesse funzioni distribuiti lungo l'impianto se grande (questo risolve problemi operativi ma ne apre altri tecnici realizzativi se si vuole un sistema professionale).

Etc,etc...

[JumpMan]

A mio avviso il miglior sistema è quello di aggiungere un pulsante a quadrifoglio o meglio un joystick (preferibilmente con pulsante "uomo morto") per effettuare i movimenti in 4 possibili direzioni lasciando al PC solo la possibilità di scegliere la parte da movimentare.

[Luca Bab]

è ammesso dare dei comandi all'impianto passando per un sistema operativo diverso da quello del PLC e soprattutto "non deterministico" come Windows

Non e' un problema , poiche' da PC alzi un bit , e' il PLC che fa' il jog controllando eventuali incroci e sicurezze , ovviamente anche nei movimenti manuali devono essere attive le sicurezze ( porte di protezione , emergenze e macchina in marcia ).

Se poi vuoi fare un bel lavoro , prima del jog del movimento , tenendo premuto il pulsante , attivi 2 secondi di allarme acustico.

Ma tutte queste considerazioni sono per il programma PLC , come seopra il PC alza solo un bit sul PLC

Ciao

Luca

[Tec1]

Grazie a tutti per i consigli.

In effetti ho già implementato "la scelta di alzare opportuni bit di comando" per i vari movimenti da eseguire, che è la stessa scelta che si fà quando i comandi vengono dati premendo dei pulsanti da pannello operatore. Il mio dubbio, però, non era sul "come fare", ma se è ammesso e/o contemplato da una norma dare dei comandi da un dispositivo che ha un sistema operativo non deterministico e diverso da quello che effettivamente mette in atto l'azione (il pannello operatore a un suo sistema operativo deterministico, e se ho dei sistemi integrati potrei avere un unica CPU e quindi lo stesso s.o).

In altre parole la mia preoccupazione è: "premo un pulsante sul PC touch screen e fin che il pulsante è premuto continuo a scrivere "1" nella relativa memoria/bit del PLC", se però si verifica un errore di comunicazione in questa fase anche se rilascio il pulsante a video, il bit rimane a "1" e quindi il movimento continua fino a raggiungere l'eventuale fine corsa (se presente) o, dato che ho a che fare con un nastro trasportatore, o continua sempre .

E' sufficiente, per garantire, la sicurezza la presenza di uno o più funghi di emergenza opportunamente posizionati?

A forza di ripensarci mi è venuta un'idea. Su PC ho già realizzato la funzione che gestisce gli errori di comunicazione, il problema è quindi dal lato PLC. Penso, però, che potrei usare un bit di "handshaking" per il controllo comunicazione. Con il PC lo metto a "1" e con il PLC ad intervallo fisso, ad es. di 500ms, tale bit viene verificato e rimesso a "0" e se al ciclo successivo il bit è a "0", significa che c'è stato un errore di comunicazione ed allora tutti i movimenti devono essere fermati. Cosa vi sembra, può andare?

[emanuele.croci]

Con il PC lo metto a "1" e con il PLC ad intervallo fisso, ad es. di 500ms, tale bit viene verificato e rimesso a "0" e se al ciclo successivo il bit è a "0", significa che c'è stato un errore di comunicazione ed allora tutti i movimenti devono essere fermati. Cosa vi sembra, può andare?

mi sembra di ricordare da qualche corso frequentato che alcuni pannelli abbiano già incorporata la possibilità di questo "life bit"... senza che tu debba scrivere sw particolari (non mi ricordo quali modelli...)

Comunque per me la tua soluzione è valida, tra l'altro non vedo particolari distinzioni tra PC e pannello visto che molti pannelli montano un S.O. Windows CE che non mi risulta particolarmente deterministico

Ciao, Emanuele

[Luca Bab]

Sicuramente fare un controllo di comunicazione e' una buona cosa , e mi sembra che lo hai approntato nella maniera corretta , in una applicazione l'avevo realizzato con 1 bit ognuno : sia il PC che il PLC fanno ciclare 0 - 1 ognuno nel suo bit , ambedue controllano il bit dell'altro con un timer e se il pc vede che non cicla il PLC da' una segnalazione d'allarme , se il PLC vede che non cicla il PC , azzera i bit relativi di attivazione provenienti dal PC e da' un'allarme.

La sicurezza non puo' essere fatta ne con il PC ne con il PLC , anche nel PLC puoi aver sbagliato il SW e mantenere un'uscita alta

ciao

Luca

[JumpMan]

I problemi legati alla comunicazione sono risolvibili con i bit di "handshake" come indicato negli ultimi post, quello che non mi piace invece è di muovere la macchina semplicemente sfiorando il touch-screen, magari uno toglie la briciola del panino che sta mangiando e combina un disastro .

Ora mi direte che non si mangia mentre si manovra la macchina, che ci sono apposite schermate da visualizzare per la pulizia del display, ecc. ecc.

Quello della briciola è solo un esempio, potrebbe anche succedere che il touch si guasti e attivi inaspettatamente un movimento...

Io su certi tipi di macchine continuo a preferire un selettore Joystick con pulsante si sicurezza ("uomo morto") sulla sua sommità, non nego di aver fatto comandi manuali direttamente sul touch ma erano macchine semplici dove non si possono fare grossi danni.