Linea Pallets

[photomass]

Buongiorno a tutti...

Sto progettando una linea a pallets per l'assemblaggio di un componente per elettrodomestici.

E' una linea che presenta una dozzina di stazioni tra handling e lavorazioni varie più una piccola tavola rotante su cui viene eseguita una lavorazione di pressatura.

La domanda che vorrei porVi riguarda il controllo di tutta la macchina.

Alcuni costruttori di sistemi di trasporto a pallets ,anche prestigiosi e rinomati, mi hanno detto che la filosofia più comune è quella di usare un controllore separato per la linea. Io mi trovo nelle condizioni di dover gestire la macchina, probabilmente, con due PLC. Questo significherebbe dotare la macchina di tre PLC innalzando ulteriormente i costi e il numero di componenti.

Vorrei un consiglio da Voi e magari delle indicazioni su come sarebbe meglio gestire questa situazione e perché.

Grazie infinite a chi vorrà rispondermi.

Saluti

[Livio Orsini]

Io mi trovo nelle condizioni di dover gestire la macchina, probabilmente, con due PLC.

Perchè mai? I PLC odierni hanno capacità di elaborazione e di gestione di numero di I/O tali che si riesce a gestire non una linea, ma una media fabbrica con un solo PLC.

La filosofia del PLC dedicato alla linea è corretta. Permette di tenere rigorosamente separate lina di pallettizzazione dalla lavorazione a monte. In questo modo si possono accoppiare macchine e linee differenti; Puoi cambiare alvorazione e mantenere la medesima linea di pallettizzazione.

[lelos]

ciao

teoricamente (parlando di plc e di capacità di elaborazione) un plc basta e avanza.

Un plc di media potenza gestisce tranquillante oltre 4000 i/o.

Secondo me si tratta sopratutto di come utilizzare al meglio i moduli remotati del plc , ingressi,uscite,analogiche,ecc.....

Per quanto rigurdas l'utilizzo degli hmi io dei pc non ci sono limitazioni (non penso ne utilizzi un oltre il centinaio ) .

Se utilizzi tanti inverter ti conviene metterli in rete coni l plc , ti costa sicuramente di più ma hai una gestione completa .

Per quanto rigurda il plc dedicato alla linea,secondo me, è una tecnica obsoleta. Ci sono bus di campo che permettono di poter collegare o scollare parti di macchina senza problemi , in quanto il bus è configurabile anche con il plc.

Io (e altra ditte) li ho provati e mettere tanti plc non è più servito , ma dipende sempre da come è fatto l'impianto e quello che vuoi ottenere.

[Livio Orsini]

Per quanto rigurda il plc dedicato alla linea,secondo me, è una tecnica obsoleta

Lelos non è questione di remotaggio, bus di campo et similia.

E' questione di flessibilità della linea. Con 2 PLC ti trovi ad avere la linea di pallettizzazione completamente autonoma. Chi produce abitualmente queste macchine risparmia moltissimo in progettazione, usando questa tecnica.

La buona progettazione significa anche avere una vista presbite.

[lelos]

ciao

se le linee non devono essere spostate e l'impianto è fisso (anche se devi modificarlo per cambi lavoro) per me basta 1 solo plc,

è quello che ho fatto fino ad ora se linee a pallet lo permettono.

che modello e marca di plc intendi usare ?

[Livio Orsini]

se le linee non devono essere spostate e l'impianto è fisso (anche se devi modificarlo per cambi lavoro) per me basta 1 solo plc,

E se l'esemplare è unico; se pensa di replicare macchina e linee con varianti la soluzione di 2 PLC è ancora quella ottimale. Questa è la ragione per la quale chi produce queste linee tende a dotarle di un PLC dedicato.

Poi molto dipende dal tipo di PLC che si vuole usare.

Attenzione. Ottimizzando le configurazioni e facendo bene i conti, 3 piccoli PLC (non siemens ovviamente ) potrebbero costare molto meno di un unico grande PLC.

[luigi69]

per quanto riguarda il post di Livio , il 4 ed il 6, vorrei esprimere anche la mia opinione , dettata soprattutto dall'esperienza in campo

è logico che chi progetta la linea debba tenere conto dei costi , ma se poi sono io che devo andare ad eseguire la manutenzione debbo trovare la galassia.....allora cerco di proporre anche una alternativa

personalmente NON sono favorevole ad una unica CPU che gestisca parecchi in out nonché periferia.... innanzitutto sarà una CPU di un certo tipo , quindi un domani risulterà difficile da reperire ( i soliti 20 gg )

nonostante la linea sia "unica" e non preveda singole stazioni da rifare altrove , io mi immagino fra qualche anno..... grossa modifica oppure rottura di un bus di campo, oppure... non lo so...

allora mentre siamo fermi con la produzione facciamo manutenzione ? sostituiamo quel particolare li ? proviamo questa altra modifica ?

se l'impianto è suddiviso in tre CPU..tanto per fare un esempio , stazioni di carico , lavorazioni, stazioni di scarico e pallettizzazione....

allora singolarmente posso

con una unica CPU ferma per qualche motivo..purtroppo no....

leggevo il post 3 di lelos.... noooooooooo un numero cosi elevato secondo me è un suicidio per il programmatore.....come si farà a mettere le mani sul software anni dopo ? materialmente non si saprà da che parte iniziare

credo che in questi discorsi ci sia una lotta senza quartiere fra chi costruisce e deve rientrare entro determinati costi , e chi si prende in carico il lavoro dopo e si scontrerà con scelte non fatte secondo la propria filosofia di lavoro...

[pigroplc]

La scelta del numero di PLC è funzione di molteplici considerazioni:

1) Standardizzazione della progettazione quindi riduzione dei tempi di sviluppo

2) più CPU significa possibilità di start-up e debug contemporanei di più sviluppatori (riduzione del tempo di messa in servizio)

3) possibilità di test e debug iniziale presso il costruttore di spezzoni di impianto quindi riduzione dei tempi di start-up

Quanto al numero di input / output non è vero che c'è da impazzire CON 4000 I/O. Bisogna essere in grado di programmare BENE E COMMENTARE! (dote rara purtroppo)

Tieni conto che il vero costo degli impianti è la mano d'opera e non l'hardware. Io ho a suo tempo risparmiato parecchi quattrini aggiungendo hardware ma riducendo considerevolmente I tempi di cablaggio.

pigroplc

[photomass]

Ringrazio per l'interessamento e per le risposte, tutte utili. Non sono un semplice progettista... mi piace progettare macchine che funzionino, che costino il giusto e che possano essere manutenute da chiunque, non solo da chi le ha costruite, cioè io. E' la mia filosofia che abbraccia a pieno quella di Luigi69.

Livio ha secondo me centrato il problema. Lavoro con PLC Panasonic e negli ultimi tempi l'utilizzo degli FP0R ha notevolmente ridotto i costi sul controllo di tutte le piccole macchine costruite. Mi piacerebbe continuare ad usare quel PLC che ha però il limite dei 64 I/O. La macchina sarà costituita da un ramo che assemblerà un sottogruppo e da un altro ramo in cui si assemblerà un altro sottogruppo all'interno del quale verrà poi inserito il primo sottogruppo. Per questo parlavo di due PLC separati. Innanzitutto perché avrò in campo più di 64 I/O, secondo perché potrò gestire separatamente i due rami con la produzione dei due sottogruppi separati, che ha la sua utilità in caso di guasto di un componente, oltre a tutti i plus elencati da pigroplc. Ora poiché la gestione del trasporto è relativamente semplice, pensavo di integrarla all'interno di uno dei due PLC, risparmiando così il costo di un PLC e delle sue espansioni. Probabilmente non varrà la pena impazzire per cercare di risparmiare I/O per stare su due soli PLC e sarà ancora conveniente investire sull'hardware per risparmiare tempo ( e denaro) su programmazione, gestione, e manutenzione della macchina.

[Livio Orsini]

Luigi69 e Pigroplc avete completato le mie argomentazioni con idee che condivido appieno e che, con alcuni decenni (tanti, troppi oramai, purtroppo) di esperienza in ufficio tecnico e sul campo non posso che condividere e confermare.

Quanto al numero di input / output non è vero che c'è da impazzire CON 4000 I/O. Bisogna essere in grado di programmare BENE E COMMENTARE! (dote rara purtroppo)

Purtroppo il concetto di programamre bene è sempre più ignorato.

Si assiste sempre più, gia a partire dalla scuola, al programma realizzato "a mazzate". Si parte a codificare secondo metodo "pene di molosso", senza un'analisi preventiva, senza una stesura di uno straccio di specifica di funzionamento.

Si crede di risparmiare tempo, invece si ha solo un programam che è un castello di carte che crolla al primo spiffero d'aria. Addiritura si fa il programma in fase di messa in servizio.

Tieni conto che il vero costo degli impianti è la mano d'opera e non l'hardware. Io ho a suo tempo risparmiato parecchi quattrini aggiungendo hardware ma riducendo considerevolmente I tempi di cablaggio.

Sai cosa mi ha risposto, un tempo, un cliente a cui avevo proposto la periferia decentrata per risparmiare sul cablaggio bordo macchina?

"A me non importa alcunchè di questi costi, tanto li affronta il cliente finale!"

photomass, forse il limite di 64 I/O è un po' basso, anche perchè un minimo di reserva per future modifiche va tenuto. Io non conosco panasonic, però magari spulciando un poco nella loro gamma riesci trovare qualche modello che ti possa concilieare flessibilità e costi.

Probabilmente non varrà la pena impazzire per cercare di risparmiare I/O per stare su due soli PLC e sarà ancora conveniente investire sull'hardware per risparmiare tempo ( e denaro) su programmazione, gestione, e manutenzione della macchina.

Io cambierei "probabilmente" con "sicuramente".

Per risparmiare un paio di centinaia di euro sull'hardware si rischia poi di spenderne 5 volte tanto in progettazione e messa in servizio.

Modificato: 3 giugno 2014 da Livio Orsini

[photomass]

Grazie Livio e grazie anche agli altri intervenuti... Livio se ho capito bene mi stai consigliando di usare un PLC per il trasporto e gli altri due per la gestione dei due rami della linea, senza la necessità che i tre PLC "si parlino" tra loro?

La gamma Panasonic è sufficientemente vasta per tutte le esigenze. Diciamo che il fratello maggiore dell'FP0R è l'FP Sigma che ha possibilità di gestire il doppio degli I/O ma essendo nato prima del FP0R presenta limiti sulla velocità che infatti è molto più bassa.

L'ultimo arrivato è l'FP7 che è fantastico da ciò che dicono in Panasonic ma ha costi paragonabili a Siemens, credo, e probabilmente è ampiamente "iperqualificato" per questo tipo di macchine.

Sulla stessa linea avrò in campo una sessantina di valvole pneumatiche, forse anche più, dislocate su una lunghezza di 6/7 metri. Ci saranno 4 o 5 assi elettrici da controllare, oltre tutti i motori, sotto inverter, della linea di trasporto, che dovrebbero essere 6. Fino ad oggi la compattezza delle macchine, non mi ha mai portato ad avere problemi di cablaggi kilometrici e le isole di valvole sono state, quasi sempre, collegate con connettori multipolari a 25 pin, ma credo che questa macchina sarà diversa. E' quasi certo che ricorrerò all'utilizzo di un bus di campo non solo per gli assi ma anche per tutte le isole di valvole.

Sapete darmi dei consigli su quale sia il protocollo più indicato da utilizzare, anche in funzione dei PLC che intendo usare?

Ho sentito anche parlare di gateway per la gestione in campo degli I/O attraverso protocolli proprietari dei costruttori di valvole pneumatiche. Che ne pensate? Avete consigli?

Grazie.

Livio scusa, se questa parte è off-topic rispetto alla discussione precedente spostala pure dove ritieni sia più opportuno. Grazie.

Massimo

[Livio Orsini]

senza la necessità che i tre PLC "si parlino" tra loro?

Questo lo puoi sapere solo tu; da quello che hai scritto sino ad ora sembrerebbe di si. Se al limite devono scambiarsi solo pochi consensi/allarmi diciamo meno di una decina di I/O si può fare.

Però se pensi di usare un bus di campo per gestire gli assi puoi ipotizzare un eventuale futuro collegamento tra i 3 PLC tramite lo stesso bus.

Bus di campo.

Ci sono valvole che si comandano con CAN Bus, però questo bus non è il massimo per gli assi. Ti ripeto io non conosco Panasonic, però presumo che disporrà di un bus standard tipo TC/IP - Ethernet, quindi io sceglierei assi Panasonic che sono validi e, dicono, non molto dispendiosi e che sicuramente avranno il medesimo bus ed i drivers pronti all'uso. Poi per le valvole, al limite si cerca un convertiore per il CAN (ci sono molte schede abbastanza economiche che fanno da interfaccia tra CAN e altri bus standard).

Non non è OT ne con la discussione ne con la sezione.

[Werner]

E' vero che un PLC attuale medio ha capacita' di elaborazione enormi e teoricamente puo' gestire isole di lavorazioni grandi, ma secondo me l'utilizzo di piu' CPU da enormi vantaggi, le differenze di prezzo le prendi su immediatamente nella progettazione (anche sulla linea), collaudo e manutenzione.

.

[photomass]

Dunque, il dubbio sul protocollo rimane... non ho ancora capito perfettamente cosa sia meglio usare con Panasonic. Se c'è qualche esperto di Panasonic che può aiutarmi sarei grato, poi contatterò il mio rivenditore, sperando che abbia le idee chiare su cosa sia meglio per l'applicazione in questione.

Da quello che ho capito si potrebbe utilizzare il bus proprietario RTEX che usa rete Ethernet per gli azionamenti e poi utilizzare un altro protocollo per il controllo di inverter, sensori e valvole e magari collegare tra loro più CPU. Ma non è più semplice utilizzare un unico protocollo? Gli inverter della linea pallets sono collegati, ad esempio, tramite profibus. Non sarebbe più conveniente a questo punto usare profibus per tutto, compreso i servo di Panasonic? O gli azionamenti si possono collegare in bus di campo solo con protocollo RTEX o EtherCat.

O addirittura non si potrebbe utilizzare solo EtherCat e convertire il segnale degli inverter da profibus a EtherCat?

Grazie anticipatamente a chi mi risponderà.

Saluti