Rampe velocità nastri trasportatori

[Slayer90]

Buonasera, 

Vorrei chiedere un vostro parere su una applicazione che sto sviluppando con PLC s7-1500. Sono presenti una ventina di nastri trasportatori che trasportano uno strato finissimo di pasta dolciaria. Tutti i nastri sono comandati da inverter g120c, il sistema con discreta precisione deve essere avviato e arresto con le stesse rampe di velocità di tutti gli inverter per evitare che si strappi la pasta. Il problema nasce dal fatto che i nastri non viaggiano tutti alla stessa velocità ma tramite ricetta é possibile modificare un offset che agisce sulla velocità passata all'inverter. Quindi per sé imposto rampe di 3 secondi su tutti gli inverter ma uno a vmax 800rpm e uno 1000 ho paura che si creino problemi. Come risolvereste questo problema senza usare oggetti tecnologici tipo assi di sincronismo in velocità? 

Grazie l'aiuto

[batta]

Risolvi con dei semplici calcoli, impostando poi, su ogni inverter, tempi di accelerazione/decelerazione diversi, in modo che la reale accelerazione/decelerazione sia uguale per tutti i trasportatori.

Immagino poi avrai anche un sistema per la gestione delle velocità in cascata, quasi indispensabile per questo tipo di lavorazione.

[Livio Orsini]

Per una lavorazione simile, non nel campo alimentare, avevo risolto mettendo tutti i motori in albero elettrico, con master virtuale. In questo modo si garantisce il medeismo rapporto di spazio percorso dai nastri, in tutte le condizioni di velocità

[batta]

47 minuti fa, Livio Orsini ha scritto:

avevo risolto mettendo tutti i motori in albero elettrico, con master virtuale.

Questa è sicuramente la soluzione più sofisticata e performante, ma Slayer90 chiedeva di non usare oggetti tecnologici.
E non dimentichiamo che stiamo parlando di semplici asisncroni, controllati in velocità e senza encoder.
Inoltre, nel settore alimentare, per linee di laminazione, trasportatori, ed altro, è prassi comune gestire semplicemente i motori in velocità, con un sistema che permette di modificare in automatico le velocità dei motori (comunemente chiamato, almeno dalle mie parti, "cascata"), ma senza ricorrere alla sofisticazione di un asse elettrico.

Generalmente poi, trattandosi di un prodotto elastico, se non ci sono differenze abissali nelle velocità dei motori, il fatto che ci siano delle rampe leggermente diverse tra un trasportatore e l'altro è ben digerito dal sistema.

 

Comunque, rendere uguali le rampe è molto semplice.
Un esempio di calcolo:
- Trasportatore 1 - Velocità tappeto 10 m/min (con motore a 1500 rpm)

- Trasportatore 2 - Velocità tappeto 8 m/min (con motore a 1500 rpm)

 

Il tempo di accelerazione da impostare sul trasportatore 2 sarà:
TempoAcc_2 = TempoAcc_1 * 8 / 10.

 

 

[Livio Orsini]

2 ore fa, batta ha scritto:

un sistema che permette di modificare in automatico le velocità dei motori (comunemente chiamato, almeno dalle mie parti, "cascata"),

 

Il metodo a "cascata dei riferumenti" è vecchio quanto me, anzi di più

 

Avendo letto:

 

12 ore fa, Slayer90 ha scritto:

...per evitare che si strappi la pasta.

 

ritengo che la garanzia che questo non accada, oltre ad evitare variazioni di grammatura della pasta, la dia solo un sistema reazionato con controllo dello spazio.

Anche perchè, in genere, le rampe di accelerazione degli asincroni senza reazione di velocità sono tutt'altro che lineari.

 

Io non ho esperienze di automazione nei settori paste, dolci ed alimentari in genere, quindi non so se le variazioni di gramamtura, che sicuramente ci saranno, perchè se un materieale si allunga o si accorcia cambia lo spessore, siano tollerabili o meno.

[84paolo]

io tempo fa avevo fatto una cosa del genere ed avevo impostato rampa accelerazione e decelerazione a zero su tutti gli inverter. poi ti dai tu un parametro di tempo di accelerazione e decelerazione. in una ob a tempo per esempio a 50ms calcoli 1 secondo di tempo di accelerazione /50 ms di ob per arrivare al tempo richiesto quindi 20 scansioni. quindi alla partenza prendi la velocità set del nastro e la dividi per le scansioni. per esempio 40 hz diviso 20 scansioni=2 hz. con l'uscita di marcia incrementi la velocità del nastro di 2 hz fino ad arrivare al set. se la velocità é 60hz allora lo incrementi di 3. e così anche per l'arresto. devi mantenere l'uscita attiva fino a velocità 0.

devi solo valutare bene le fermate in emergenza

[batta]

2 ore fa, Livio Orsini ha scritto:

ritengo che la garanzia che questo non accada, oltre ad evitare variazioni di grammatura della pasta, la dia solo un sistema reazionato con controllo dello spazio.

Per la pasta, sarebbe solo una inutile complicazione ed un altrettanto inutile aggravio di costi.

Tutte le linee, salvo qualche punto particolare, sono con motori controllati in velocità. Anzi, le differenze di velocità tra un trasportatore e l'altro sono volute.

Generalmente, la velocità master è data dal forno (o dalla rotostampa, se presente), e poi si fa una cascata delle velocità, a seconda dei casi, verso valle o verso monte. Si può modificare la velocità di un singolo motore (nel qual caso viene ricalcolata la costante del rapporto di velocità rispetto al suo master), oppure di un motore e di tutti quelli a valle (o a monte, a seconda della direzione della cascata).

 

46 minuti fa, 84paolo ha scritto:

io tempo fa avevo fatto una cosa del genere ed avevo impostato rampa accelerazione e decelerazione a zero su tutti gli inverter....

Anche questa è una complicazione che non serve per questo tipo di lavorazione. Tieni presente che le velocità si modificano solo in fase di messa a punto, e quando si cambia produzione. Poi, per ore ed ore, la linea viaggia a velocità costante. Si fanno solo piccoli aggiustamenti per adattarsi alle condizioni dell'impasto. Inoltre, si parla sempre di rampe brevi.
Mai visto problemi dovuti alle rampe, a meno che non siano impostate, per dirla alla Livio, "a membro di molosso".

[PlcPro]

Slayer,

supponendo di pilotare in contemporanea tutti gli inverter (quindi p.es. via bus), non avrai mai la garanzia che le velocità relative rimangano sempre "costanti", o per dirla in altri termini, non avrai MAI le stesse performances del menzionato albero elettrico che Livio giustamente cita.

Anche Batta dice giustamente di agire sui tempi di accelerazione, ma questo comporta software aggiuntivo in quanto dovresi mandare (supponendo il pilotaggio sempre via bus) ad ogni inverter la sua "nuova" rampa che tiene conto della velocità attuale. Soluzione (quella di Batta) molto fine e matematica.

 

Ti propongo una "mia" soluzione che è questa: dato che il sistema sicuramente tollera dei piccolissimi errori (temporanei) sulla nuova applicazione della velocità, perchè da pannello non applichi le nuove velocità "per gradi" ? Cioè le fai variare (quando le cambiano) di pochissimo per volta ed attendi sempre il tempo di "applicazione" da parte dei G120C della nuova velocità. Così avresti suddiviso il problema in "tanti" sottostep che, presi singolarmente, non dovrebbero dare problemi.

 

E' una soluzione che usiamo nel tessile quando hai un fuso che viaggia dagli 8000 ai 10000 rpm, un filo da 0.12 mm di diametro e la necessità di cambiare velocità su tutti i motori che trainano quel povero filo.

[batta]

9 ore fa, PlcPro ha scritto:

ma questo comporta software aggiuntivo in quanto dovresi mandare (supponendo il pilotaggio sempre via bus) ad ogni inverter la sua "nuova" rampa

Se non c'è bisogno di modificare le rampe (e, di solito, non c'è), non serve altro software. Basta impostare, in ogni inverter, la rampa corretta.

In ogni caso, si tratta di un calcolo banalissimo.

Poi, come già detto, la pasta, relativamente a questo problema, è un prodotto facile da trattare, e una lieve discontinuità durante i transitori di accelerazione/decelerazione non causa problemi. Il mio lavoro, da 10 anni a questa parte, è per l'80 % nel settore alimentare. Quanto affermo, lo affermo per esperienza. Tieni presente che le velocità sono dell'ordine di pochi metri al minuto, e che le rampe, da fermo a velocità massima, sono di un paio di secondi. Durante la lavorazione, le regolazioni sono minime. Quando arresti e riparti, la pasta non si rompe, e qualche scarto lo faresti comunque, anche con motori in asse elettrico.

[Slayer90]

Grazie mille ragazzi per le tante risposte e suggerimenti! Credo che il metodo matematico descritto da batta sia sicuramente il più indicato, anche perché da pannello si imposta la velocità di linea che viene mandata su tutti i nastri (che sono tutti uguali) e le rampe di accelerazione e decelerazione. La velocità massima é di 2.5m/min quindi é qualcosa di veramente lento. Quindi anche le differenze di velocità tra i nastri variano di poco. Attualmente prima dell'avvio del ciclo automatico calcolo le rampe da scrivere sui parametri degli inverter partendo dai m/min impostati e calcolando la rampa in secondi. È la prima applicazione che facciamo di questo tipo quindi certe tipologie di problemi non le abbiamo mai affrontate. 

[leleviola]

Nel campo tessile dove spesso le velocità di assi in cascata sono fondamentali per la buona resa dei macchinari l'uso di rampe differenziate per i vari azionamenti spesso non porta a buoni risultati perchè ogni asse può essere slegato dall'altro e un eventuale impuntamento di un asse sulla catena non fa autoregolare gli assi successivi, sempre usate rampe pari a zero su ogni asse, ti crei una rampa master che comanda l'asse master gli altri assi sono comandati in cascata ma il come si comandano in cascata può fare la differenza, c'è chi prende la velocità in uscita dalla FB di controllo dell'asse e c'è chi invece per comandare l'asse successivo preleva il segnale da BUS dall'ingresso dell'FB dell'asse precedente, sono finezze che con asincroni possono fare la differenza. Il prelevare dall'uscita dell'asse il segnale per comandare l'asse successivo può causare l'aggiunta di un errore relatico al comando dell'asincrono, sempre meglio prelevare il segnale in ingresso dall'asse precedente. La soluzione consigliata da Livio è la più precisa ma oggigiorno soluzioni con motori a magneti permanenti possono essere comunque una buona soluzione con assi comandati con normali inverter. Il fatto di usare normali inverter può essere giustificato da quanto è necessario variare la velocità di funzionamento dell'asse, con un brushless hai precisione con un asincrono se le escursioni di velocità sono troppo ampie non puoi avere precisione alle basse velocità

[Slayer90]

Comunque il sistema é identico a quello descritto da batta, un forno di cottura fa da master per le utenze a monte: cella lievitazione + laminatoio. 

Alla fine questo è un revamping, il sistema prima funzionava già correttamente con dei potenziometri manuali che gestivano le velocità dei nastri e le partenze e arresti venivano fatte su rampe fisse per quello in azienda abbiamo optato per un sistema senza assi virtuali e con solo ricalcolo delle rampe per rendere magari più precisa la regolazione. 

Ringrazio tutti per i preziosi suggerimenti 

[Livio Orsini]

18 ore fa, PlcPro ha scritto:

E' una soluzione che usiamo nel tessile quando hai un fuso che viaggia dagli 8000 ai 10000 rpm, un filo da 0.12 mm di diametro e la necessità di cambiare velocità su tutti i motori che trainano quel povero filo.

 

Nel campo tessile ho fatto parecchie applicazioni e li, effettivamente, una piccola differenza di velocità causa modifiche alle caratteristiche del filo che alla fine si notano sulla pezza di tessuto, cosa che deprime di molto laredditività del prodotto. E giocoforza, quindi, fare anche l'impossibile affinchep questi stress siano evitati.

 

Come ho già scritto, non avendo alcuna esperienza nel campo alimentare, accetto di buon grado il parere di chi ha una lunga esperienza nel campo, anche se, come impressione mia, non sembra una soluzione corretta.

 

2 ore fa, leleviola ha scritto:

Il fatto di usare normali inverter può essere giustificato da quanto è necessario variare la velocità di funzionamento dell'asse, con un brushless hai precisione con un asincrono se le escursioni di velocità sono troppo ampie non puoi avere precisione alle basse velocità

 

Da qualche anno non mi occupo più di questio problemi, però usavo degli asincroni-sincronizzati alimentati da un'unico inverter per avere identica velocità anche ad anello aperto. Era la soluzione tipica dei "godet" per la produzione di filato acrilico.

[batta]

48 minuti fa, Livio Orsini ha scritto:

non sembra una soluzione corretta.

È la soluzione universalmente adottata nel settore.
Tieni presente che gli inverter di oggi, con controllo vettoriale ad anello aperto, raggiungono una precisione ottima.
Più volte ho paragonato il set di velocità, la velocità letta dal drive, e la velocità letta con un contagiri. La differenza non è mai andata oltre pochi rpm su 1500.
E vai a sapere se a sbagliare di più era l'inverter o il mio contagiri.
Ovvio che un asse elettrico è più preciso, ma la precisione in più non serve, per questo prodotto.
Il sincronismo si fa solo dove serve, per esempio, sui rulli di una rotostampa. Lì, chiaramente, non se ne potrebbe fare a meno.

[Livio Orsini]

Batta mi ricito:

15 ore fa, Livio Orsini ha scritto:

....non avendo alcuna esperienza nel campo alimentare, accetto di buon grado il parere di chi ha una lunga esperienza nel campo, anche se, come impressione mia, non sembra una soluzione corretta.

 

[ETR]

Ciao a tutti la diatriba è sempre quella : a domanda, si risponde per sommi termini.

 

Non avendo informazioni, rispondo fornendo la soluzione che tecnicamente mi garantisce al 100% la soluzione la problema (qualsiasi esso sia come costo, si fa per dire ma ci siamo capiti). Se poi, ho eperienza nel settore, ho le informazioni tecniche dell'applicazione, posso affinare la soluzione sfondandola di tutti quei particolari che la rendono più onerosa.

 

Poi tecnicamente, per come la vedo io, in un mondo teorico, fatta la soluzione di Livio, l'applicherei ovuquqe, per il semplice motivo che non dovrei preoccuparmene in nessuna maniera.

 

Ma nascono le eccezzioni nel mondo reale, come questa della pasta, come nelle rulliere della logistica (a basso costo con tutti asincroni senza bus e con/senza inverter tutti mischiati) ed in molti altri casi dove, con pazienza, calcoli ed esperienza le soluzioni poi vengono affinate, in base a diverse scelte tecniche.

 

Come nota (derivante più da sistemi di controllo/assenza rotazione delle coclee), ma con dei prox sull'albero lento o veloce del motore, date anche le prestazioni dei nuovi PLC e dei loro tempi di scansione, determinare la velocità del nastro ? Lo utilizzo per evitare l'uso di encoder o tachimetriche, su processi molto più veloci, ma che per via delle condizioni estreme di uso, sarebbero probelmatiche da implementare. Nel caso di slayer, avrebbero dalla loro parte un costo decisamente basso di implementazione.

 

Buona giornata, Ennio

[Roberto Gioachin]

Il 9/10/2020 alle 23:21 , Slayer90 ha scritto:

Come risolvereste questo problema senza usare oggetti tecnologici tipo assi di sincronismo in velocità? 

In applicazioni simili io ho preferito generare sul PLC il riferimento di velocità (con rampe di accelerazione e decelerazione) da usare su analogiche o bus di campo, sull'inverter ho portato le rampe a zero.

Sul plc ho create una funzione che permettono di inserire il dato di velocità in m/min e di accelerazione in m/sec2, la funzione in base ai dati di cinematica di ogni motore determina il valore da inviare all'analogica.

[batta]

9 ore fa, ETR ha scritto:

Poi tecnicamente, per come la vedo io, in un mondo teorico, fatta la soluzione di Livio, l'applicherei ovuquqe, per il semplice motivo che non dovrei preoccuparmene in nessuna maniera.

In un mondo teorico non esistono i costi, e non esistono i tempi di sviluppo.
In un mondo pratico, una soluzione costa il doppio dell'altra, è più complicata e, con un materiale come la pasta, non ti accorgeresti della differenza. Questo è il punto cruciale: la maggior precisione che otterresti con un controllo più sofisticato, non ti servirebbe assolutamente a nulla.
Sarebbe come mettere in asse elettrico dei nastri trasportatori di bottiglie.
La soluzione corretta non è quella tecnologicamente più avanzata, ma quella che ti permette di raggiungere lo scopo nel modo meno oneroso.
Non dimentichiamo che non si tratta solo di costo dell'hardware, ma anche di sviluppo software, e di maggiori complicazioni in caso di interventi di manutenzione.
Sostituire un asincrono controllato in velocità ad anello aperto e sostituire un brushless, non è certo la stessa cosa.
Perché mi dovrei complicare la vita per non avere nulla in più?

Tra l'altro, anche se con l'asse elettrico hai garanzia che tutti i motori seguano la stessa rampa, questo non ti risolverebbe il problema di qualche scarto in caso di arresto e ripartenza, perché già il semplice fatto di esserti fermato altera il prodotto.
Ti posso garantire che, anche con il sistema attualmente usato, si fanno delle regolazioni molto fini.

 

Voglio fare un esempio, in un caso completamente diverso.
Trituratore con due motori asincroni da 132 kW che lavorano accoppiati sullo stesso albero.
La logica direbbe che si deve avere un master, ed uno slave controllato in coppia.
E questa era la mia intenzione.
Per pura curiosità, ho voluto provare a pilotare semplicemente i due motori, con controllo vettoriale, in velocità, ad anello aperto, passando lo stesso riferimento.
Ebbene, con mia sorpresa, i due motori lavoravano con lo stesso identico assorbimento, e con la stessa identica coppia.
A questo punto, perché dovrei complicare di più il software (anche se non si tratta certo di una grossa complicazione), se non mi serve?
In base a quale principio si potrebbe definire migliore la gestione master/slave se quella più semplice lavora altrettanto bene?
Completamente diverso, invece, il caso di macchine da stampa dove, sullo stesso albero di trasmissione, ci sono più motori. Importantissimo evitare giochi meccanici dovuti a tiro/rilascio, quindi, in questo caso, il controllo con un master e gli slave regolati in modo da avere sempre l'albero in torsione, diventa di importanza assoluta.

 

Insomma, non esiste la soluzione universalmente migliore.

Modificato: 12 ottobre 2020 da batta

[Livio Orsini]

10 ore fa, batta ha scritto:

Insomma, non esiste la soluzione universalmente migliore.

 

[leleviola]

Batta tanto per tornare al tema della discussione tu parli di una soluzione che imposta le rampe di accelerazione e decelerazione dei singoli assi a seconda dei giri o che fa l'asse, giusto? Tu hai un sincronismo generale che passi a tutti gli assi e poi in caso di fermata o partenza ogni singolo asse fa la sua rampa secondo quanto ha impostato internamente, giusto? La mia era una domanda tanto per capire meglio cosa intendevi e al limite cambi tramite bus di campo l'entità della singola rampa del singolo asse, giusto?

[batta]

Facciamo un passo indietro. Io lavoro per diverse ditte di automazione, che lavorano per diversi costruttori. Ogni ditta, ed ogni costruttore, ha i propri standard, ed io, di volta in volta, mi adeguo.
Le rampe, per questa lavorazione, c'è chi nemmeno le rende impostabili, anche perché hanno come unico scopo quello di partire e di fermarsi in modo non brusco. In questo caso, basta impostare in ogni singolo drive delle rampe coerenti per avere tutti i trasportatori che accelerano e decelerano in modo uguale.
C'è chi le rende impostabili, ma senza preoccuparsi più di tanto di fare calcoli. Verranno impostate in fase di collaudo e, molto probabilmente, mai più toccate. Tanto, come detto, l'influenza sul prodotto è minima.
Impostare un'accelerazione generale della linea e poi fare calcoli per trasferire i tempi di rampa ad ogni singlo drive, è già una sofisticazione non necessaria.
Le velocità, nella maggior parte dei casi, vanno da frazioni di m/min ad una decina di m/min, con rampa al massimo di un paio di secondi.
Ovviamente, ci sono sempre i casi particolari.
 

[leleviola]

Beh se si tratta di lavorazioni con rampe di 2 secondi sono avviamenti abbastanza "grossolani" che non hanno bisogno di grande precisione ma quando si tratta di avviamenti con rampe di 10 sec. e oltre è forse necessaria maggiore precisione e magari un sistema con rampe a zero e asservimento a un sistema Master sincrono che comanda tutto il resto con la propria rampa è forse più preciso, vero è che comunque con gli inverter attuali si raggiungono comunque buone prestazioni

[batta]

44 minuti fa, leleviola ha scritto:

un sistema con rampe a zero e asservimento a un sistema Master sincrono che comanda tutto il resto con la propria rampa è forse più preciso

Con un sistema simile, all'avviamento (e all'arresto) gestisi la rampa del master, e tutti gli slave lo seguono.
Ma cosa accadrebbe quando vai a modificare la velocità di un motore?
In questo caso, non ti basta più gestire la rampa del master (che non cambia velocità), ma dovresti gestire le rampe di ogni singolo drive.

[beppeconti]

Il 10/10/2020 alle 09:01 , batta ha scritto:

Questa è sicuramente la soluzione più sofisticata e performante, ma Slayer90 chiedeva di non usare oggetti tecnologici.
E non dimentichiamo che stiamo parlando di semplici asisncroni, controllati in velocità e senza encoder.
Inoltre, nel settore alimentare, per linee di laminazione, trasportatori, ed altro, è prassi comune gestire semplicemente i motori in velocità, con un sistema che permette di modificare in automatico le velocità dei motori (comunemente chiamato, almeno dalle mie parti, "cascata"), ma senza ricorrere alla sofisticazione di un asse elettrico.

Generalmente poi, trattandosi di un prodotto elastico, se non ci sono differenze abissali nelle velocità dei motori, il fatto che ci siano delle rampe leggermente diverse tra un trasportatore e l'altro è ben digerito dal sistema.

 

Comunque, rendere uguali le rampe è molto semplice.
Un esempio di calcolo:
- Trasportatore 1 - Velocità tappeto 10 m/min (con motore a 1500 rpm)

- Trasportatore 2 - Velocità tappeto 8 m/min (con motore a 1500 rpm)

 

Il tempo di accelerazione da impostare sul trasportatore 2 sarà:
TempoAcc_2 = TempoAcc_1 * 8 / 10.

 

 

Si potrebbe ottenere lo stesso risultato anche tenendo le rampe uguali (P1120, P1121 e P1135) e cambiando la velocità massima P1082 in proporzione delle cinematiche diverse

 

[batta]

51 minuti fa, beppeconti ha scritto:

Si potrebbe ottenere lo stesso risultato anche tenendo le rampe uguali (P1120, P1121 e P1135) e cambiando la velocità massima P1082 in proporzione delle cinematiche diverse

Questa potrebbe essere un'altra soluzione.