Gestione asse S120 a passi

[Slayer90]

Buongiorno a tutti, 

Ho qualche dubbio su come sviluppare un applicazione in ambiente siemens tia portal: tramite azionamento s120 con suo motore brushless (sempre siemens), devo comandare un piano di scorrimento (è praticamente un nastro che deve portare delle confezioni nella giusta posizione per poter essere riempite!). Fondamentalmente il sistema deve funzionare a passo in base alla ricetta della confezione inserita. Volevo sapere se qualcuno ha esperienza con questo tipo di gestione asse. Più nel dettaglio, la macchina ha una camma di azzeramento (l'asse è di tipo rotativo, è praticamente un nastro) che corrisponde alla prima posizione utile di deposito di tutte le scatole. Io avevo pensato di usare un asse modulo che si azzera in automatico quando si ha fatto un avanzamento fisso che viene definito in base alla meccanica della macchina e da lì iniziare a contare i passi delle posizioni da fare. Ad esempio 0 posizione 1, avanzo di 150mm posizione 2, poi vado a 300 posizione 3 e così via sempre in movimento assoluto. Il problema quando magari arrivo a 600 l'asse modulo si azzera, come faccio a fargli ripetere la sequenza all'infinito? Ho quasi sempre lavorato con assi lineari che si muovono da punti a-b, anche in camma con altri assi, ma qui mi trovo un po' in difficoltà sinceramemte, c'è qualcuno che riuscirebbe a darmi qualche dritta ☺️? 

[batta]

Perché non fai posizionamenti relativi anziché assoluti?

[Slayer90]

Ciao batta, in verità c'avevo pensato, però metti caso che per qualche motivo abbia un errore di posizionamento, posizionandomi in relativo accumulerei l'errore nelle posizioni prossime e quindi avevo pensato di riferire sempre al punto zero. Però effettivamente avendo un modulo di 600 se mi trovo a 500 e mi muovo di 300mm in relativo mi dovrei ritrovare a 200mm quindi? Così potrei ripetere il posizionamento di continuo! 

[batta]

1 ora fa, Slayer90 ha scritto:

Però effettivamente avendo un modulo di 600 se mi trovo a 500 e mi muovo di 300mm in relativo mi dovrei ritrovare a 200mm quindi?

Sì, esatto.
Per non accumulare errori, è importante che i rapporti meccanici siano dei numeri finiti. Per esempio, se hai un riduttore a vite senza fine, il rapporto di riduzione quasi di sicuro sarà un numero approssimato. In questo caso, accumuleresti continualemnte errori.
L'errore ppotrebbe essere così piccolo da risultare insignificante dopo anni di lavoro, oppure potrebbe essere già intollerabile dopo poche ore.
Potresti risolvere con correzioni della posizione, che puoi fare anche al volo, con asse in movimento.
Il problema di accumulare errori dovuti ad un rapporto di riduzione impreciso, comunque lo avresti anche con i posizionamenti assoluti.

[Slayer90]

Il nastro è collegato direttamente sul secondario del riduttore del motore brushless siemens: addirittura nella configurazione dell's120 inserisco solo il codice del motore completo di riduttore e si calcola tutto lui, la riduzione  a valle del riduttore è nulla. ma cosa intendi con correzioni al volo con asse in movimento? 

 

[EmilioR]

Seguo la discussione perché anche io in azienda ho una macchina con un s120 che gestisce un motore e riduttore siemens configurato come asse rotativo. La macchina esegue dei passi costanti di 108000 impulsi encoder. A distanza di qualche anno abbiamo dei problemi sulla precisione del passo nonostante gli impulsi encoder siano precisi. 

Leggendo la risposta di batta(che ringrazio per avermi aiutato indirettamente 😄) ho collegato il mio problema ai giochi meccanici. Purtroppo non posso esserti di aiuto dato che il problema è ancora presente da noi però spero che questo post possa esserti di aiuto quantomeno ad evitare problemi futuri sul progetto

[Livio Orsini]

13 ore fa, Slayer90 ha scritto:

ma cosa intendi con correzioni al volo con asse in movimento? 

 

 

Se l'errore è costante si può sapere in anticipo dopo quanto la differenza tra quota reale e quota virtuale, quella che misura l'asse, avràraggiunto un determinato valore che può essere corretto, p.e. 2 impulsi di encoder. A questa condizione si può aggiungere al volo la correzzione in più o in meno all'asse, in modo da azzerare l'errore.

[Slayer90]

12 ore fa, EmilioR ha scritto:

La macchina esegue dei passi costanti di 108000 impulsi encoder. A distanza di qualche anno abbiamo dei problemi sulla precisione del passo nonostante gli impulsi encoder siano precisi. 

È proprio questa la mia più grande preoccupazione per questa macchina 😱!! 

Ok si potrebbe gestire l'errore come dice il buon Livio, ma se questo non fosse costante o addirittura nullo in certe condizioni? 

Comunque questo è un problema che si vedrà in fase di messa in servizio, per ora mi servirebbero degli spunti su come gestire l'asse in modo che i passi siano definiti da ricetta (ci sono circa 30 confezioni diverse con posizioni di deposito completamente diverse e asimmetriche) ad esempio una confezione può avere in deposito 6 file altre 2, altre addirittura 1.. È un confezionamento uova. Come hai gestito i passi? Con posizionamenti relativi? Usando il posizionamento relativo, come valuti l'arrivo in posizione target se l'asse modulo si azzera prima del raggiungimento della quota? 

[EmilioR]

Non è un progetto che ho sviluppato io, ci sto mettendo le mani da qualche anno come manutentore. Posso dirti che l's120 è configurato in MDI e dal plc gli inviamo le rampe, lo start del passo e gli impulsi da fare. Non ho il progetto sotto mano al momento ma in settimana posso darti informazioni più precise. Da quello che ricordo adesso il numero degli impulsi da fare viene scritto in un Db PZD, nel mio caso è un valore fisso ma può essere anche un valore da variabile. L'azionamento quando riceve lo start esegue il passo da 108000 impulsi e sempre in una variabile contenuta nei PZD restituisce un bit del passo eseguito. Perdonate se non riesco ad essere preciso ma sono autodidatta e sono solo un paio di anni che smanetto sui plc

[Livio Orsini]

1 ora fa, Slayer90 ha scritto:

ma se questo non fosse costante o addirittura nullo in certe condizioni?

 

Questo lo sai a priori, perchè sai il rapporto di riduzione del riduttore, quindi conosci per ogni giro di di motore, quindi di encoder, quale frazione di giro effettuerà l'albero lento.

Oltre a questo dato devi disporre della costante che rapporta una rivoluzione dell'albero lento con la lunghezza della traslazione corrispondente.

 

Con un po' di pazienza trovi la corrispondanza tra un impulso di encoder e la lunghezza dello spostamento corrispondente dell'asse.

Se questa costante corrisponde ad un numero irrazionale o razionale con un numero notevole di decimali, sicuramente avrai un errore di troncamento perchè puoi contare solo un numero intero di impulsi.

Potrai calcolarti, alla scrivania, ogni quanti impulsi ne avrai perso uno o ne avrai contato uno in più (in funzione se arrotondi per eccesso o per difetto).

 

Gli altri errori dipendono dai giochi meccanici,ma quelli puoi cercare di minimizzarli ma non riesci a commpensarli.

Modificato: 15 agosto 2021 da Livio Orsini

[Slayer90]

37 minuti fa, EmilioR ha scritto:

Perdonate se non riesco ad essere preciso ma sono autodidatta e sono solo un paio di anni che smanetto sui plc

Vai tranquillo, anche io sono praticamente autodidatta e con poca esperienza ☺️! 

 

23 minuti fa, Livio Orsini ha scritto:

Con un po' di pazienza trovi la corrispondanza tra un impulso di encoder e la lunghezza dello spostamento corrispondente dell'asse.

Se questa costante corrisponde ad un numero irrazionale o razionale con un numero notevole di decimali, sicuramente avrai un errore di troncamento perchè puoi contare solo un numero intero di impulsi.

Potrai calcolarti, alla scrivania, ogni quanti impulsi ne avrai perso uno o ne avrai contato uno in più (in funzione se arrotondi per eccesso o per difetto).

 

Gli altri errori dipendono dai giochi meccanici,ma quelli puoi cercare di minimizzarli ma non riesci a commpensarli.

Sì di solito faccio muovere l'asse da un punto noto e vedo quanti impulsi encoder equivale e dividendo questi 2 valori trova la costante mm per impulso.. Ma come dicevi è sempre un numero con tantissimi decimali...ma questo problema si avrebbe anche gestendo il tutto tramite oggetto tecnologico? 

[batta]

23 ore fa, Slayer90 ha scritto:

ma cosa intendi con correzioni al volo con asse in movimento? 

Se hai un sensore di home, c'è una modalità di MC_Home che ti permette di effettuare l'homing anche con un posizionamento in corso.
Questo, di fatto, andrà a correggere la posizione attuale dell'asse.
Ovviamente, la variazione di posizione dell'asse dovrà essere piccola, per non generare errori di inseguimento e/o variazioni di velocità dell'asse.
Potresti anche decidere di fare un nuovo homing solo se rilevi una differenza tra la posizione letta dall'encoder e quella del sensore di Home superiore ad un certo valore.

 

Il problema comunque lo avrai solo nel caso di rapporto di riduzione approssimato. Se dalla targa del riduttore leggi i = 12.3 (numeri a caso) quasi sempre quel valore sarà approssimato. Nel caso di riduttori epicicloidali con rapporto di riduzione reale con un numero infinito di cifre decimali, se si conosce il vero rapporto in forma di frazione, dato che gli oggetti tecnologici del TIA lavorano con variabili a 64 bit, potrai inserire un numero così vicino a quello reale che solo dopo anni di funzionamento senza aver mai fatto un riposizionamento riscontreresti differenze significative.
Quando invece hai a che fare con riduttori a vite senza fine, il rapporto indicato sulla targhetta sarà sempre approssimato, perché soggetto a tolleranze costruttive.
Purtroppo i progettisti meccanici (che dovrebbero essere loro a mettere in guardia noi programmatori su queste problematiche) non ne tengono mai conto e, dato che il riduttore a vite senza fine è il più economico, ecco che te lo ritrovi anche dove non si dovrebbe usare.

 

Modificato: 15 agosto 2021 da batta

[Slayer90]

Grazie mille Batta, molto interessante questa cosa! 

Quindi potrei partire facendo una cosa del genere: presenza sensore e quota asse modulo a 0, muovo l'asse con posizionamenti relativi (le. Posizioni e il numero dei passi vengono calcolate da una funzione in base alla ricetta inserita). Se alla fine non ho un fronte di salita su sensore di zero e l'asse modulo risulta azzerato sposto l'asse sul sensore di 0 e lo resetto con mc home.. Potrebbe funzionare almeno come punto di partenza. Che dite? 

[batta]

Prima di tutto, si deve definire se disponi di encoder assoluti o incrementali. Se dispono di encoder assoluti, sta a te decidere se fare, in ogni caso, un homing (intendo un homing "completo", con ricerca del sensore di Home, non un homing "al volo") quando avvii la macchina, o se non farlo. Generalmente, con encoder assoluti l'homing si fa solo su richiesta dell'operatore, a seguito di manutenzioni o di anomalie della posizione.
Se hai un encoder incrementale, all'accensione della macchina dovrai sempre fare un ciclo di homing.

Successivamente, in entrambi i casi, con macchina in lavoro, potrai fare una correzione "al volo" della posizione dell'asse qualora venisse rilevato uno scostamento superiore ad un certo valore.

Tieni presente che questa eventuale "correzione al volo" ti serve solo ed esclusivamente se hai un rapporto di riduzione approssimato. Se il rapporto di riduzione è noto con precisione, non avrai mai nessun errore.
Poi si tratta di capire come è fatto il tuo trasportatore. Se è un semplice tappeto sul quale vengono depositate le scatole, non ti interessa assolutamente se ad ogni posizionamento commetti un piccolo errore. E, anche se questo errore si dovesse sommare ad ogni ciclo, da dove viene depositata la scatola a dove viene prelevata avrai sempre un errore insignificante.
Diverso invece se hai un trasporto a facchini, nel qual caso un accumulo di errori ti porterebbe, nel tempo, ad andare fuori passo.
In questo caso, meglio pensare a posizionamenti assoluti.

 

Sulla sequenza di homing, con encoder incrementale puoi configurare nell'oggetto tecnologico come vuoi che avvenga l'homing: direxzione di ricerca del sensore di home, azzeramento sulla tacca di zero dell'encoder, e molto altro. Nel caso di encoder assoluto, invece, non è possibile sfruttare questo automatismo, e dovrai muovere l'asse in jog per ricercare il sensore di Home. Chissà se i tedeschi un giorno capiranno che, pur essendo vero che in caso di encoder assoluto l'homing si fa molto raramente, è vero anche che un homing completo, come nel caso di encoder incrementale, sarebbe assai gradito. 

Modificato: 15 agosto 2021 da batta

[Slayer90]

Ok, grazie Batta. Proverò a buttar giù qualcosa del genere e vedere come funziona, magari non si manifestano nemmeno i problemi sopra citati.