Azzeramento encoder assoluto S210

[Ghisla]

Buongiorno

 

Sto gestendo degli azionamenti S210 con encoder assoluto che eseguono delle preavvitature.

Dopo aver eseguito il reset dell'encoder con l'istruzione MC_Home (Mode 7) un paio di volte è successo che gli azionamenti spostassero il mio zero su un altro punto del modulo.

Che problema potrebbe esserci?

Sto usando TIA V16, L'azzeramento lo eseguo tramite telegramma.

Grazie

[pigroplc]

Io proverei con il buon vecchio sistema di marcare l'albero e il calettatore (qualora non ci sia una chiavetta). Più di una volta nella vita mi sono trovato a dover dimostrare a meccanici coriacei che il problema non era del software ma del segno del pennarello indelebile che magicamente si sfalsava.

Se invece il problema si verifica a livello software io inserirei un passo di controllo sulla posizione dell'homing, in modo da accertarmi che la funzione è andata a buon fine a seguito del fronte di salita del comando

[Ghisla]

Il controllo lo eseguo già.

Tra l'altro mi si sfasano 3 motori su 4 e esattamente nella stessa posizione, cosa molto strana

Quando eseguo l'azzeramento vedo la posizione attuale che si riporta a 0° ma magicamente ogni tanto lo 0° si trova a X gradi spostato da dove lo ho azzerato io

Modificato: 4 maggio 2020 da Ghisla

[Mattia Spoldi]

l'encoder dell'oggetto tecnologico come l'hai configurato?

assoluto o ciclico assoluto?

 

se riesci fai anche uno screenshot

Modificato: 4 maggio 2020 da il toby

[batta]

39 minuti fa, Ghisla ha scritto:

Quando eseguo l'azzeramento vedo la posizione attuale che si riporta a 0° ma magicamente ogni tanto lo 0° si trova a X gradi spostato da dove lo ho azzerato io

Dovresti spiegarti un po' meglio.

Come esegui l'homing?
Hai fatto un qualche ciclo automatizzato o è l'operatore che conferma la posizione di home?

Quali sono i controlli che "esegui già"?
Sei sicuro che, nella variabile in ingresso "Position" di MC_Home non ti ritrovi qualche valore strano?
Sei sicuro di non aver pasticciato con i DB di istanza delle varie MC_Home?
 

[batta]

56 minuti fa, pigroplc ha scritto:

Più di una volta nella vita mi sono trovato a dover dimostrare a meccanici coriacei che il problema non era del software ma del segno del pennarello indelebile che magicamente si sfalsava.

Quanto hai ragione! È un classico.
La situazione più eclatante, mi è capitata un paio di anni fa, in Russia, con la traslazione di circa 20 metri di un carrello del peso di una trentina di quintali.
Il carrello si deve spostare in posizioni ben precise per essere inserito o estratto dalla relativa postazione. Ogni tanto, il carrello veniva inserito in posizione errata.
La trasmissione del movimento viene fatta con cinghia dentata. L'encoder è sul motore. L'errore del posizionamento, guarda caso, era sempre esattamente del passo di un dente.
Io continuavo a sostenere che, se l'encoder mi dice che sono in posizione, e non sono in posizione, il problema è certamente di natura meccanica.
Ma niente, i meccanici continuavano a sostenere che era tutto a posto, ed era il software che sbagliava.
Siamo andati avanti mesi, impostando rampe sempre più morbide mano a mano che il problema peggiorava.
Poi, arrivati praticamente al collasso, si sono decisi a controllare la cosa più banale: la tensione della cinghia.
Inutile dire che, una volta ripristinata la corretta tensione della cinghia, il problema "software" è magicamente sparito.

[Ghisla]

44 minuti fa, batta ha scritto:

Dovresti spiegarti un po' meglio.

Come esegui l'homing?
Hai fatto un qualche ciclo automatizzato o è l'operatore che conferma la posizione di home?

Quali sono i controlli che "esegui già"?
Sei sicuro che, nella variabile in ingresso "Position" di MC_Home non ti ritrovi qualche valore strano?
Sei sicuro di non aver pasticciato con i DB di istanza delle varie MC_Home?
 

 

L'homing lo eseguo con un pulsante a pannello che mi setta il bit di execute dell'MC home, l'operatore porta l'asse manualmente in posizione e preme questo pulsante di azzeramento da pannello (ora lo sto facendo io, e dopo aver eseguito lo zero vedo che mi viene settato il done dall' MC Home)

Nell'MC_Home in position scrivo direttamente 0 senza appoggiare a variabili.

 

Grazie

[Marco Mondin]

1 ora fa, batta ha scritto:

Poi, arrivati praticamente al collasso, si sono decisi a controllare la cosa più banale: la tensione della cinghia.
Inutile dire che, una volta ripristinata la corretta tensione della cinghia, il problema "software" è magicamente sparito.

A me è capitato solo una volta con le cinghie, molte volte invece con alberi lisci calettati senza chiavetta per motivi di sicurezza nell'accoppiamento a freni di sicurezza.
Quasi mai usano chiavi dinamometriche per chiudere i serraggi e verificare che siano come da manuale (per fortuna sono rari come montaggi).

Una volta invece mi è capitato con un palettizzatore che si tranciasse di netto l'albero a causa (dissero) di una errata tempra e una probabile cricca nel metallo.
L'asse perdeva pochi decimi ad ogni ciclo sfalsandosi di svariati mm dopo qualche pallet. Lo teneva solo più la frizione dovuta all'irregolarità della frattura! Per fortuna!
Avrebbe potuto uccidere qualcuno! Ci rendemmo conto del problema in quando quando perdeva la quota il riduttore si spostava inclinando leggermente il motore.
Per sfilare quel povero alberino massacrato ci misero un pomeriggio intero 4 meccanici che si davano il cambio a squadre di 2!

[step-80]

1 ora fa, batta ha scritto:

Quanto hai ragione! È un classico.
La situazione più eclatante, mi è capitata un paio di anni fa, in Russia, con la traslazione di circa 20 metri di un carrello del peso di una trentina di quintali.
Il carrello si deve spostare in posizioni ben precise per essere inserito o estratto dalla relativa postazione. Ogni tanto, il carrello veniva inserito in posizione errata.
La trasmissione del movimento viene fatta con cinghia dentata. L'encoder è sul motore. L'errore del posizionamento, guarda caso, era sempre esattamente del passo di un dente.
Io continuavo a sostenere che, se l'encoder mi dice che sono in posizione, e non sono in posizione, il problema è certamente di natura meccanica.
Ma niente, i meccanici continuavano a sostenere che era tutto a posto, ed era il software che sbagliava.
Siamo andati avanti mesi, impostando rampe sempre più morbide mano a mano che il problema peggiorava.
Poi, arrivati praticamente al collasso, si sono decisi a controllare la cosa più banale: la tensione della cinghia.
Inutile dire che, una volta ripristinata la corretta tensione della cinghia, il problema "software" è magicamente sparito.

 

Ho un paio di macchine dove un robot antropomorfo preleva da un carrello dei pezzi molto piccoli per caricarli in macchina. Il carrello fa da magazzino pezzi portandoli avanti a mano a mano che il robot li preleva da davanti. 

Per un po è successo che TUTTI i lunedi mattina mi chiamasse il ragazzo addetto alla macchina dicendomi che 'il robot sbagliava la posizione' . Faccio presente che i robot sono stati aggiunti e programmati dal sottoscritto ad una macchina che di preciso aveva si e no l'indirizzo di dove era stata costruita. 

Sapevo benissimo che il robot non poteva sbagliare, e che se prendeva male i pezzi era dovuto senz'altro al carrello che si era spostato. Morale della favola, ho scoperto che il venerdi sera la ragazza delle pulizie , forse dalla foga di finire in fretta per andarsene a casa, dava delle mazzate col Mocio Vileda al carrello spostandolo mentre lavava il pavimento. 

Il ragazzo che lamentava il problema è sempre stato li con lei, l'avrà vista sicuramente almeno 20 volte spostare il carrello ma non c'è mai stato verso: il problema è sempre il robot che 'si è spostato'....'ha perso lo zero'....

 

Scusate OT

[batta]

56 minuti fa, Ghisla ha scritto:

Nell'MC_Home in position scrivo direttamente 0 senza appoggiare a variabili.

Quindi, subito dopo l'esecuzione di MC_Home, l'asse è a quota zero.
Se non ci sono errori nel software, non può essere diversamente.
E quand'è che sbaglia la posizione?
Sei sicuro che MC_Home venga richiesto quando l'asse è nella posizione corretta?

Continuo a non capire.

[Ghisla]

Praticamente è un pick and place che dopo aver depositato i pezzi esegue una preavvitatura.

Al termine della preavvitatura ritorno a presa posizionandomi a 0° con un movimento assoluto. Qui mi trovo le pinze orientate in modo errato, ma l'azionamento mi continua a dire che sono a 0°, sembra che sovrascriva lo zero 

Questo non succede sempre, casualmente.

 

[step-80]

@Ghisla lavori con l'asse in controllo di coppia? Una preavvitatura mi fa pensare a questo.

Ci sono riduzioni meccaniche fra motore e carico?

Modificato: 4 maggio 2020 da step-80

[Mattia Spoldi]

Ma questa perdita di 0, succede alla riaccensione o anche mentre la macchina lavora.

[ken]

io farei subito la prova che ti ha detto pigroplc.

poi potresti vedere se il nuovo zero ha sempre lo stesso offset

[Ghisla]

@step-80Per le preavvitatura imposto una coppia limite ma non tiro mai in coppia. Di mezzo c'è un riduttore con rapporto 1/5

@il toby stamattina mi è successo dopo una riaccensione mentre dopo qualche ora è successo a macchina già accesa.

[Mattia Spoldi]

Mi è già successa una cosa simile con gli assi in modulo, nel mio caso ho cambiato la configurazione da encoder assoluto ad encoder ciclico assoluto.

Se invece è già così farei dei segni con un pennarello sugli alberi e darei un occhio alla meccanica.

[step-80]

Dico una boiata: ma nelle impostazioni dell’asse è contemplato il riduttore? Perchè se è impostato come asse rotante in teoria quando comandi un posizionamento alla quota Zero ci va percorrendo meno strada possibile, se era a 181 gradi va avanti esempio. Ma se non è contemplato il riduttore hai uno sfalsamento dovuto a lui

[Mattia Spoldi]

@step-80per il discorso relativo alla strada più breve durante il posizionamento a 0, dipende da come configura il blocco MC_MoveAbsolute, il parametro direction indica la direzione del movimento sugli assi con il modulo, inserendo 1 andrà sempre in positivo, 2 sempre in negativo, 3 fa la strada più breve.

@Ghislastai usando la V16 con gli oggetti tecnologici 5.0 o ancora i 4.0?

[step-80]

@il toby grazie 1000 per la precisazione, non conosco TIA ed ho ipotizzato..

 

Il mio discorso era questo: l'asse pre-avvita un (tappo?) al quale serviranno sempre bene o male 'x' gradi per pre-avvitarsi. Quindi in condizioni normali l'asse a fine avvitamento si troverà sempre nei pressi di una certa posizione e, quando viene comandato lo spostamento verso lo zero, seguirà il comando tornando allo zero motore...il quale essendoci di mezzo un rapporto 1:5 può trovarsi sfalsato di 72° o multipli a seconda di dove si è fermato l'asse. Non so se mi sono spiegato. 

Solo che la mia ipotesi è scarsa perchè sicuramente @Ghisla ha inserito il rapporto nella configurazione asse e quindi il problema non si pone.

[Ghisla]

Buongiorno a tutti.

 

Sto usando l'encoder come assoluto e non ciclico

Il riduttore è inserito, giri motore 5 giri carico 1.

Gli oggetti tecnologici sono ancora della versione 4.0

@step-80 per quanto riguarda lo sfalsamento che dici te se fosse cosi succederebbe quasi sempre invece mi succede occasionalmente. Poi in ogni caso quello che succede è anomalo,

mi si sfalsa lo 0° encoder il che non dovrebbe succedere.

 

[batta]

57 minuti fa, Ghisla ha scritto:

Sto usando l'encoder come assoluto e non ciclico

Devi usare l'encoder come realmente è.
Se l'encoder è assoluto monogiro, devi impostare "encoder assoluto".
Se l'encoder è assoluto multigiro, devi impostare "encoder ciclico assoluto".

 

59 minuti fa, Ghisla ha scritto:

mi si sfalsa lo 0° encoder il che non dovrebbe succedere.

Certo che non dovrebbe succedere, anzi, è proprio impossibile che succeda.

Proprio per questo rimane il forte dubbio che il problema sia di natura meccanica.
Torniamo quindi al suggerimento che ti ha dato, ancora nel secondo post, Pigroplc.
A meno che non siano sbagliati i parametri dell'encoder.
Magari, se ci fornissi il codice completo del motore e uno screenshot di come hai impostato l'encoder nell'oggetto tecnologico, potremmo capire qualcosa di più.
Non mi spiego questa riluttanza a fornire tutti i dati.

 

[Ghisla]

Ho postato gli screen della targa motore e di come ho configurato l'encoder all'interno dell'oggetto tecnologico (Ciclico assoluto impostato successivamente al post di Toby)

@batta Scusami per la mancanza di informazioni, se hai bisogno di altro non esitare a chiedere. Posto tutto il necessario per risolvere il problema

 

 

 

 

 

[batta]

L'encoder è assoluto multigiro
Manca ancora cose c'è impostato in "Trasmissione dati encoder".

[Ghisla]

Ecco qua

 

[Mattia Spoldi]

 @Ghisla Io normalmente lascio flaggato anche la casella che tu non hai flaggato, ti evita di andare a configurare l'encoder a mano.

Comunque adesso l'encoder è configurato correttamente, io proverei a vedere se perde ancora lo 0