Tavola rotante con encoder assoluto - to_PositioningAxis

[ken]

Domani provo di certo.

Nella mia applicazione errori di inseguimento anche più alti non dovrebbero darmi problemi. Posso poi permettermi rampe belle lunghe.

Modificato: 10 aprile 2020 da ken

[ken]

Nettamente migliore senza modificare guadagni e altri parametri dell'anello di posizione.

Batta, non me ne sarei mai accorto. lo avrei giudicato un comportamento normale dovuto anche alla mia inesperienza.

Non mi resta che vederlo funzionare a banco ora.

Naturalmente aggiornerò la discussione. se ne parlerà minimo tra un mese comunque.

non finirò mai di ringraziarti

[batta]

7 ore fa, ken ha scritto:

non finirò mai di ringraziarti

Non c'è bisogno, figurati.
Anzi, questa cosa è servita anche a me: ora so come evitare il problema, se mi capita di lavorare su una configurazione simile, e come sistemare quell'asse che non mi soddisfava, se mi capiterà di rimetterci le mani.

Per il resto, io mi trovo molto bene con questi oggetti. Basta prenderci un po' la mano, e sono semplici da gestire (eventuali bugs a parte 😉 ).
Poi, dagli oggetti tecnologici è facile anche estrarre molte informazioni.
Per esempio, oltre alle più classiche come "ActualPosition", "ActualVelocity", "ActualAcceleration", che sono riferite al movimento reale dell'asse, c'è un altro valore che, spesso, può tornare utile, ed è "ActualSpeed", che ti dà la velocità del motore in rpm.
Ovviamente, oltre a questi dati, sempre dall'oggetto tecnologico leggi statusword, errorword, warningword.
Tutto normale, dirà qualcuno. Sì, certo, ma per chi non conosce questi oggetti, se non sa che dall'oggetto tecnologico si ricevono moltissime informazioni, forse, nemmeno prova a cercarle.
Per farti un'idea,  apri l'oggetto tecnologico (che poi non è altro che un DB) con tasto destro del mouse --> Apri editor DB. Ecco, lì dentro trovi tutte le variabili dell'oggetto tecnologico.

 

Una cosa poi che mi ha positivamente sorpreso, è che il comportamento reale dell'asse è molto vicino al comportamento in simulazione. Questo, almeno, con motori brushless, e rimanendo nei limiti di un corretto dimensionamento.

 

Con le cpu "T" poi, si aprono molte altre strade.
Per esempio, ora sto lavorando su un oggetto "Kinematics", con un movimento "Delta 2D" e un "Portale 2D".
L'oggetto tecnologico si configura in maniera molto intuitiva, aiutati da figure molto chiare. E poi, bastano veramente poche righe di codice per compiere movimenti anche complessi, con possibilità di decidere se e come raccordare i movimenti tra di loro.
Tra l'altro, nel mio caso, il Delta ed il Portale, completamente diversi da un punto di vista della meccanica, devono eseguire dei movimenti simili. La parte di codice è la stessa per entrambi gli oggetti, cambia solo la configurazione dell'oggetto tecnologico usato.
Il trace della cinematica ti permette di visualizzare graficamente i movimenti dei vari organi. Il tutto funziona sempre anche in simulazione, così puoi muovere veramente gli organi meccanici solo quando sei già quasi sicuro che faranno il movimento corretto, riducendo enormemente il rischio di danni.

 

Esempio trace di un semplice movimento Delta 2D

 

 

Esempio trace movimento portale 3D

 

[ken]

Il db di instanza dell'oggetto tecnologico me lo sto studiando. in tempi normali non avrei fatto più di tanto. ora ho tempo e sto guardando le variabili. Mi sono anche creato una rogna. le variabili di stato sono dword ma a me interessano i bit. ho provato la sovrapposizione AT. ha una rognetta. se usi nome_variabile.%x0-X31 hai i bit in ordine come da manuale. se usi la sovrapposizione li gira come era normale in s7 classico.

 

La cpu T non è cosa che serve nel tipo di lavoro che abbiamo. per questa macchina abbiamo una macchina a 3 assi che deve depositare i legnetti sopra le bobine. sono 4 legnetti che servono a creare spazio tra bobina e bobina. Non avendo tempo di fare questa parte che resterebbe unica collaboriamo con un'azienda che invece conosce bene questo tipo di lavori. sono curioso di vedere come sarà.

 

avendo tempo sto studiando un po il motion nel tia. solitamente uso sinapos e il posizionatore integrato nel drive. è tempo però di cambiare.

[batta]

15 ore fa, ken ha scritto:

ho provato la sovrapposizione AT. ha una rognetta. se usi nome_variabile.%x0-X31 hai i bit in ordine come da manuale. se usi la sovrapposizione li gira come era normale in s7 classico.

Per risolvere, è sufficiente riordinare, a gruppi di 8, i bit nella struttura.

Io ricorro raramente alla sovrapposizione con AT (ma si tratta solo di una scelta personale), preferisco usare le istruzioni scatter e gather per i trasferimenti da word a strutture di bit e viceversa.
Con scatter a gather, il primo bit della struttura è il bit meno significativo della word (ordinamento Little Endian), mentre con la sovrapposizione con AT, il primo bit della struttura è il bit meno significativo del byte più significativo (ordinamento Big Endian).

 

Buona Pasqua.

 

 

[ken]

Esatto. non avendola mai usata volevo provare

[ken]

Ho iniziato oggi a fare qualche prova con il moto-riduttore (solo motore, riduttore ed encoder), niente carico vero.

la difficoltà ,maggiore è stata la parametrizzazione encoder.

Il 8/4/2020 alle 11:27 , ken ha scritto:

risoluzione di precisione, bit in Gx_XIST1 e 2; il manuale dice 25-bit absolute multiturn encoder, 13-bit singleturn resolution (8192 counts per

 

revolution), 12-bit multiturn resolution (4096 revolutions). Quindi dovrei impostare 13 e 13, è corretto? (measuring units /Revolution 8192)

i paramenti di risoluzione vanno impostati entrambi a zero. Non capisco il perchè ma ho provato semplicemente girando l'encoder a mano. 1 giro (8192 impulsi) dovevano corrispondere ai famosi 29.189°

non avevo mai quel valore. impostavo i 12 o 13 bit come è la vera risoluzione. Ho iniziato a sparare a caso e ho notato che abbassando il valore migliorava. arrivato a 1 ho visto che il risultato era la metà esatta. 

ho messo zero e il tutto funziona.

ora devo vedere come gira in anello di spazio. funziona ma a volte, con accelerazioni e velocità discrete ho errore di inseguimento. pensa sia solo questione di taratura. domani vedo con l'oscilloscopio cos succede.

 

dopo farò la prova girando il sistema come asse rotante, quello che in simulazione dava errori di inseguimento alti. 

[batta]

1 ora fa, ken ha scritto:

la difficoltà ,maggiore è stata la parametrizzazione encoder.

Se usi un brushless Siemens con encoder in "drive-cliq", fa tutto da solo (devi solo spuntare "Acquisisci automaticamente valori encoder..." nell'oggetto tecnologico).
Se non c'è collegamento drive-cliq, devi inserire i parametri forniti dal costruttore dell'encoder. Non c'è nulla da impostare per tentativi.

 

1 ora fa, ken ha scritto:

funziona ma a volte, con accelerazioni e velocità discrete ho errore di inseguimento

Verifica, con la funzione "Trace", se superi i limiti di coppia del motore. Se non superi i limiti, gli errori di inseguimento devono rimanere molto contenuti.
Nel trace puoi inserire velocità, coppia, accelerazioni, e molto altro.

 

Per quanto riguarda la configurazione come asse rotante, oltre ad avere aperto un case all'assistenza Siemens, ho inviato un progetto di prova anche ad un tecnico col quale sono spesso in contatto. Pare proprio che, nella configurazione come asse rotante con "sistema di misura esterno", ci sia un baco. Per ora, si risolve impostando l'asse come lineare, come descritto in un precedente post.

 

 

[ken]

si, lo sto usando come dicevi.

certo, oggi trace prima lato s120 per vedere riferimento e feedback di velocità, una volta che il motore risponderà bene passerò all'anello di spazio.

Non credo che ci siano problemi di coppia. è solo motore e riduttore, non dovrebbe.

 

per l'encoder è come dici ma non ho trovato da nessuna parte come impostare i parametri dei bit di risoluzione di precisione o meglio non ho capito come interpretare la cosa. li avevo interpretati come bit di risoluzione encoder invece sono tutt'altro

[batta]

9 minuti fa, ken ha scritto:

una volta che il motore risponderà bene passerò all'anello di spazio.

Salvo applicazioni particolarmente spinte, dovrebbe andare bene già al primo colpo, con i parametri di default.

 

10 minuti fa, ken ha scritto:

non ho trovato da nessuna parte come impostare i parametri dei bit di risoluzione di precisione

Con un S120, lascia fare il riconoscimento dell'encoder al sistema.

[ken]

è un encoder di terze parti, un encoder assoluto profinet della lika, il sistema non lo riconosce da solo; è poi posto sull'albero lento del riduttore. la penso come te, con motore 1fk o simili partivo già meglio. sto cercando di spiegare la cosa ai progettisti ma come sempre (e anche per me alla fine) è difficile far cambiare abitudini e convinzioni.

 

comunque ho subito visto dove stava il problema. il generatore di rampa interno. Pensavo che attraverso la word di comando il sistema lo escludesse (P1122 a 1). non è così. c'erano ancora le rampe di default a 10 sec quindi l'errore di inseguimento giustamente esplodeva. ho sistemato il regolatore di rampa e il gioco è stato fatto. quasi come in simulazione. adesso comunque qualche trace lo faccio lo stesso

[batta]

26 minuti fa, ken ha scritto:

è un encoder di terze parti, un encoder assoluto profinet della lika, il sistema non lo riconosce da solo; è poi posto sull'albero lento del riduttore

Salvo casi particolari, dove eventuali giochi della trasmissione diventano importanti, con un brushless che dispone già del suo encoder (anche assoluto multigiro), installare un ecoder esterno ha senso solo come eventuale controllo (generazione di allarme in caso di discordanza tra i due encoder).
Non capisco perché molti progettisti siano ancora affezionati a questa soluzione che, quasi sempre, è solo un inutile costo aggiuntivo.

Comunque, tu ti ritrovi con due encoder: quello sul motore, e quello sull'albero lento. Potresti quindi, come detto sopra, usare l'encoder sul motore per la gestione dell'asse, e l'encoder sull'albero lento per controllo.

Tra l'altro, i moderni controlli per funzionare bene hanno bisogno di frequenze di impulsi piuttosto elevate. Se l'albero lento sul quale è posto l'encoder è molto lento, la regolazione peggiora.
 

 

[ken]

31 minuti fa, batta ha scritto:

Comunque, tu ti ritrovi con due encoder: quello sul motore, e quello sull'albero lento

no, solo encoder su albero lento. il motore è un normalissimo asincrono senza encoder. il drive è configurato come P1300 (tipo di regolazione) a 20 regolazione vector del numero di giri senza encoder.

è per questo che lo sto provando bene prima di inviare in montaggio.

ti riassumo la questione. questo tipo di lavoro veniva fatto con tre semplici proximity per determinare il rallentamento e l'arresto per la rotazione oraria e antioraria. in più servivano altri due proximity per determinare la posizione della tavola (come è orientata).

senza chiedermi nulla hanno pensato di mettere un encoder assoluto per eliminare tutti i proximity mantenendo la stessa meccanica. a questo punto mi ero detto "usiamo il motion allora"

 

Insomma sono sempre cose progettate con l'idea "abbiamo sempre fatto così"

giustamente la versione con i proimity è stata eliminata. tararli ti portava via un sacco di tempo e in più da vedere era veramente brutto.

 

Il discorso è che vengono decise le cose senza discuterne bene prima. ci sono parecchi punti in cui si può migliorare su questo tipo di macchine

[batta]

2 ore fa, ken ha scritto:

no, solo encoder su albero lento. il motore è un normalissimo asincrono senza encoder.

Ma allora stai usando un G120, non un S120.

[ken]

S120. Si possono utilizzare anche loro senza feedback di velocità. Il g120 andava bene. Anche il g120c. Ma per motivi di spazio si è preferito usare gli s120

Modificato: 4 agosto 2020 da ken

[batta]

7 ore fa, ken ha scritto:

S120. Si possono utilizzare anche loro senza feedback di velocità.

Sì, ma è uno spreco enorme!

[ken]

Vero ma con i G nello spazio a disposizione non ci si stava.