Tavola rotante con encoder assoluto - to_PositioningAxis

[ken]

Buon giorno a tutti, scusate sarò lungo.

Sto facendo delle prove per un lavoro che dovrei affrontare in futuro. Utilizzo la versione 5.0 dei blocchi tecnologici, Tia 16 e CU con firmawre 5.2

Ho una tavola rotante che deve fare passi di 90° o multipli di 90°.

la meccanica è così configurata.:motoriduttore, encoder assoluto multigio profinet (di terze parti) posto sull'albero lento; altro lato dell'albero lento un pignone che farà girare una ralla.

rapporto riduzione 1:40. diametro primitivo pignone 96 ralla 1184 quindi un giro tavola (360°) sono 12,33 giri encoder.

Posso permettermi rampe e tempi ciclo tranquilli, non è un'applicazione spinta. per esperienza 5-8 secondi per 90° sono accettabilissimi

 

Elettronica :

S120 configurato in vector e cpu 1511F pn; encoder profinet di terze parti configurato di default con telegramma 81 multiturn. Telegramma con motor mudule standard 1 con estensione per leggere altri parametri.

 

ho configurato l'oggetto tecnologico come rotatorio e ho due dubbi:

• Encoder, seleziono il mio encoder e come tipo ho scelto assoluto, attivo il modulo con avvio 0° e arrivo 360°. c'è anche l'opzione ciclico assolto e il manuale indica che sarebbe preferibile come scelta. in questo caso dovrei configuare l'encoder come singleturn?
• trasmissione dati encoder è la parte che mi da più dubbi, non ho capito benissimo cosa vuol dire:
  • acquisisci automaticamente valori encoder durante progettazione
  • acquisisci automaticamente valori encoder durante il runtime
  • 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)

• Meccanica. ho scelto sistema di misura esterno percorso per giro encoder 29.189; numero giri motore 49333 e numero giri carico 100. i parametri dovrebbero essere corretti.

 

Ultime cose.

• ho simulato l'asse e in simulazione funziona tutto. OB91 MC-Servo configurato ciclico a 4ms. In simulazione mi è andata in stop la cpu per overflow su quell'ob ho alzato da 4 a 8ms e tutto ha funzionato. Immagino che con la cpu vera i 4ms saranno ok. come si sistema questo parametro di solito? in rete ho trovato il manuale delle funzioni tecnologiche 4.0, non sembra molto diverso dalla 5.0 ma non ho trovato informazioni esaudenti se non configurare il tempo di ciclo non come ciclico ma come sincrono al bus, selezione non possibile nella mia configurazione per errore sulla "sorgente del clock di trasmissione.
• La posizione attuale, se l'encoder era come feedback motore lo avrei letto dal telegramma ciclico (telegramma 3 ad esempio); in questo caso? leggo dall'encder e scalo la lettura? non ho trovato negli fb usati (MC_HOME, MC_MoveRelative e MC_MoveAbsolute) la posizione attuale.

 

 

[batta]

Domanda: se hai un S120, immagino che il motore sarà un brushless. Perché complicarsi la vita con un encoder esterno?
E perché spendere di più per un S120, quando adesso ci sono gli S210? A meno che non ci siano già altri S120 sotto la stessa CU320.

Usare l'encoder esterno, se non hai un rapporto di riduzione con un numero finito tra pignone e ralla, ti crea un grave problema: potrai mettere tutte le cifre decimali che vuoi ma, per quanto piccolo, ad ogni rotazione, accumulerai un errore.
Al posto dei diametri primitivi, non hai il numero di denti?
Se usi l'econder sul motore, nella meccanica puoi inserire numero di giri del motore, e numero di giri del carico.
Nel tuo caso, per non avere approssimazioni, potresti scrivere, rispettivamente, 1480 e 3 (40 * 1184 / 96 = 1480/3).
Selezionando, invece, come nel tuo caso, "sistema di misura esterno", devi impostare il "percorso per giro encoder" e, questo percorso, dai valori da te forniti (ma fatti dare il numero di denti, non fare i calcoli sui diametri primitivi), risulta essere pari a: 360 * 96 / 1184 = 29,189189189189...... gradi.
Se la rotazione della tavola è sempre nello stesso verso, accumuli continuamente errori che, per quanto piccoli, a lungo andare possono diventare catastrofici.
Dovrai mettere in atto procedure per correggere questo errore.

 

1 ora fa, ken ha scritto:

S120 configurato in vector

Perché non servo? Che motore c'è collegato a questo S120?

 

23 minuti fa, ken ha scritto:

c'è anche l'opzione ciclico assolto e il manuale indica che sarebbe preferibile come scelta. in questo caso dovrei configuare l'encoder come singleturn?

Devi sapere se il tuo encoder è multigiro o giro singolo.

 

24 minuti fa, ken ha scritto:

trasmissione dati encoder è la parte che mi da più dubbi, non ho capito benissimo cosa vuol dire:

Con la spunta su "acquisisci automaticamente valori encoder durante il runtime", se l'encoder lo permette, il sistema dovrebbe leggere da solo i parametri dell'encoder.
In caso contrario, dovrai conoscere ed impostare manualmente i parametri che ci sono sotto: bit, risoluzione, ecc.

 

58 minuti fa, ken ha scritto:

ho simulato l'asse e in simulazione funziona tutto. OB91 MC-Servo configurato ciclico a 4ms. In simulazione mi è andata in stop la cpu per overflow su quell'ob ho alzato da 4 a 8ms e tutto ha funzionato.

Con la V16 ho avuto anch'io qualche problema di questo tipo con il simulatore. Per un solo asse, anche la cpu più scadente MC_Servo deve girare in 4 ms senza problemi.
Tieni comunque presente che, per un'applicazione lenta come nel tuo caso, potresti tranquillamente passare anche a 12 o 16 ms senza perdere qualità del movimento.
Se la cpu non ha già l'ultimo firmware, fai l'aggiornamento del firmware, che dovrebbe essere il 2.8.

 

1 ora fa, ken ha scritto:

La posizione attuale, se l'encoder era come feedback motore lo avrei letto dal telegramma ciclico (telegramma 3 ad esempio)

Ma non usi il telegramma 105? La posizione dell'asse la leggeresti sempre nell'oggetto tecnologico.

[ken]

Ho un motore asincrono tradizionale. utilizziamo s120 solo per motivi di spazio e per "continuità di prodotto" col cliente finale. solitamente sono cose che facciamo con un semplice G120C

Ho quindi un motore asincrono senza retroazione. la scelta vector è quindi obbligata.

 

per il problema dei decimali. l'ho pensato anche io. la tavola in questione avrà sopra un bobina che dovrà essere legata. ogni 90° c'è uno scasso dove scorre la reggetta. io devo posizionare quindi in base a quante legature vogliono fare. solitamente è una sola, quindi non posiziono nulla.

questo tipo di macchina veniva prodotta con dei semplici poximity. 2 facevano l'arresto in posizione (leggono tutti e due, macchina allineata e bloccaggio con pistone) 1 ulteriore proximity per iniziare un rallentamento prima dell'arrivo in posizione.. c'erano poi altri proximity per sapere quale vertice della croce è allineato.

il costruttore meccanico per eliminare questi proximity ha voluto montare un encoder assoluto col quale ricreare in modo software le mie camme.

Mi aspettavo l'encoder calettato sul giunto rotante, ho dei sensori a bordo e un motore per la rotazione dei rulli, mi serve quindi un giunto rotante. essendo per le cose semplici ho pensato ad un encoder con albero cavo montato sull'albero di rotazione del giunto quindi, 1 giro tavola, 1 giro encoder. ma sai, i progettisti a volte hanno altre idee.

 

a me piacerebbe però posizionare e quindi sto provando anche questa via, tenendo poi come calcio d'angolo la soluzione camme software che però non è esente dal problema dei decimali.

 

L'encoder è multi giro ma può essere configurato come giro singolo modificando i parametri

Non avendo motore retroazionato ed essendo in vector il 105 non è utilizzabile.

Penso di convincere il progettista a montare encoder e giunto rotante sullo stesso albero. sarebbe la soluzione più ovvia.

per il resto grazie Batta.

[batta]

Ok, ora è più chiaro il quadro generale.
Sinceramente, continuo a trovare un po' strano l'accoppiamento S120-Asincrono.
Avendo già CU320 e power module, aggiungere semplicemente un motor module è sicuramente la scelta più razionale, ma tanto valeva montare un brushless.
Buona parte del costo in più del brushless (se non tutto, dipende dalla taglia del motore) la recuperavi non installando l'encoder assoluto.
Inoltre: esecuzione più pulita, nessun problema per mantenere fermo in coppia il motore, migliori prestazioni, più facile gestione dell'asse a livello di software.

Purtroppo, molto spesso (non so se sia questo il tuo caso) si devono fare i conti con progettisti che non hanno una visione globale del problema, ma sanno solo sommare il costo dei singoli componenti e, a volte, nemmeno tutti. Per esempio, per quanto riguarda l'encoder non c'è da tener conto solo del costo puro dell'encoder stesso, ma anche del costo dell'installazione meccanica. E poi, ci sono le ore in più per lo sviluppo del software.
Poi (non conosco il ciclo quindi sto solo avanzando ipotesi), se la tavola deve rimanere ferma in posizione, o tieni il motore in coppia, oppure ti serve un motore con freno (o un freno esterno). Se tieni un asincrono fermo in coppia, probabilmente avrai bisogno della servoventilazione. Lo stesso se dovrà girare a basse velocità. Con il brushless, questi problemi non ci sarebbero.

Se hai bisogno di freno e di servoventilazione, con il brushless si spendeva meno.
Mettiamola così: con un S120 a disposizione, un domani potrai sempre sostituire l'asincrono con un brushless.

 

Per il problema dei decimali, temo dovrai usare un segnale di home per azzerare l'encoder ad ogni giro, oppure quando rilevi un errore di posizione sopra ad un certo valore.

Io sono in lotta quasi tutti i giorni con i progettisti meccanici che mi montano riduttori con rapporto 62,53.... (numero a caso). Ma sono 62,53, chiedo, o sono 62,53 e una fila infinita di altre cifre decimali?
No, mi dicono, è un valore approssimato. E come faccio io, con un valore approssimato, a non sommare errori? Niente, non lo vogliono capire.

 

Per quanto riguarda invece leggere la posizione attuale dell'asse, anche se usi il telegramma 3 per il drive, hai comunque tutti i dati dell'encoder che ti entrano nell'oggetto tecnologico con il telegramma 81 o 83. Quindi, la posizione attuale dell'asse la leggi comunque direttamente nelle variabili dell'oggetto tecnologico.
A proposito, visto che ti servono 12 e rotti giri encoder per un giro tavola, usa l'encoder come multigiro.

 

[ken]

Ho convinto il progettista a montare l'encoder sull'albero del giunto rotante. è un albero esattamente in centro alla tavola. 1 giro tavola 1 giro encoder. meglio di così si muore. basta solo una staffa...

il resettare l'encoder ad ogni giro non è fattibile. è un encoder profinet assoluto. i cicli di scrittura sono sicuramente limitati. dovrei capire dove viene scritta la nuova posizione. se viene scritta in memoria non volatile prima o poi esaurirò i cicli massimi ammessi

Per il motore e il fermo in posizione. il sistema è vecchio stile. c'è un pistone di blocco, quindi freno esterno.

devo eseguire un passo di 90°

1. retraggo il pistone. il movimento è libero
2. eseguo il posizionamento
3. motore fermo
4. blocco il pistone

 

avrò le mie rogne con la sorveglianza di fermo, lo so già.

Nel mio giro, macchine lamiera, da coil a fogli piani o sottobobine, ho due diversi tipi di progettisti. quelli ancorati alle scelte del passato, quelli troppo tecnologici.

[batta]

53 minuti fa, ken ha scritto:

Ho convinto il progettista a montare l'encoder sull'albero del giunto rotante. è un albero esattamente in centro alla tavola. 1 giro tavola 1 giro encoder.

Questo da una parte ti semplifica la vita, dall'altra rende peggiore il controllo, perché per un giro motore avrai solo 8192 / 40 * 96 / 1184 = 16.6 impulsi.
Personalmente, se non ci sono giochi meccanici significativi, preferisco l'encoder addirittura sul motore, quindi nemmeno sull'albero lento del riduttore.

 

Poi, tutto sommato, considerando che gli oggetti tecnologici lavorano con variabili LREAL, che con l'ecoder installato sull'albero del pignone un giro encoder corrisponderebbe a 29,189 (con il 189 periodico) e che tu potrai impostare, nell'oggetto tecnologico, 29.1891891891892 gradi, risulta che, ad ogni giro encoder, avresti un errore di circa 1.08e-14 gradi, che corrisponde ad un errore di circa 1.33e-13 gradi per ogni giro tavola. La tavola dovrebbe fare circa 750 miliardi di giri per accumulare un errore di 0.1 gradi.

Con una rotazione di 90° ogni 5 secondi, lavorando 24/7, l'errore di 0,1° si verificherebbe dopo circa 475320 anni.
Forse, quell'errore di un decimo di grado, potrebbe non essere un tuo problema 😉

In teoria, e se non ho sbagliato qualche calcolo.

Effettivamente, con la precisione permessa dal formato LREAL, se il rapporto reale è noto, anche se non è un numero finito il problema non sussiste.
Sussiste, invece, quando si hanno rapporti di riduzione nominali che si fermano a 3 o 4 cifre significative, e non sai cosa viene dopo.

Modificato: 8 aprile 2020 da batta

[ken]

non credo che sia 1:40 finito, approssimano sempre. non mi fido delle distinte movimenti. dovrei recuperare il codice e guardare il catalogo

 

domani ci ragiono meglio.

intanto grazie ancora Batta

[Roberto Gioachin]

14 ore fa, ken ha scritto:

il resettare l'encoder ad ogni giro non è fattibile. è un encoder profinet assoluto

Se devi resettarlo ad ogni giro tanto vale che metti un encoder incrementale.

Ma se devi resettare spesso un encoder assoluto e corri il rischio di rovinarlo, allora esegui il reset su una memoria ritentiva del plc, senza mai scrivere sulla memoria dell'encoder, in fin dei conti si tratta solamente di una sottrazione ed una somma rispetto il conteggio dell'encoder salvato sul plc nel momento in cui hai fatto il reset.

[batta]

Nel caso in questione, con encoder esterno, è da verificare se con la funzione di homing viene effettuata una scrittura sulla memoria dell'encoder.
Nel caso di encoder assoluti integrati nel motore brushless, e gestione con telegramma 105 o 102, quando si effettua l'homing non viene fatta nessuna operazione sull'encoder, ma viene impostato l'offset in una memoria ritentiva dell'oggetto tecnologico. Nessun problema, quindi, in caso di azzeramenti ciclici.
Ripeto, non so cosa accada con encoder esterno, ma io credo che venga gestito allo stesso modo, con offset nelle variabili dell'oggetto tecnologico.
Comunque, come detto nel precedente post, se ci vogliono 750 miliardi di giri della tavola per accumulare un errore di 0.1 gradi, non serve ripetere l'homing.

Modificato: 9 aprile 2020 da batta

[ken]

è una cosa che voglio verificare dal vivo. mi farò mandare il motoriduttore con l'encoder così proverò dal vivo in sede.

in teoria dovrebbe essere interno al tia come dice batta per l'encoder assoluto sul motore. l'encoder è multigiro e sicuramente per tornare a zero saranno necessari molti giri di tavola rotante.

la funzione "attiva modulo" dovrebbe servire a quello se ho capito bene quello che ho letto nel manuale.

in teoria non dovrei aver bisogno di homing perchè farei posizionamenti relativi. in ogni caso col blocco MC_HOME inizializzerò la posizione utilizzando il parametro mode a 7.

 

in fase di test mi basterà leggere dall'encoder direttamente la posizione e vedere la posizione attuale dell'asse. sono curioso.

[ken]

batta approfitto ancora, non mi tornano dei dati. sto provando in simulazione ma qualcosa ami sfugge.

imposto i vari dati calcolati da me tra cui

• percorso per giro encoder = 29.189 è questo mi sembra corretto
• Numero giri motore = 49333 (servono 493.33 giri motore per fare un giro completo tavola) e mi sembra corretto ((1184/96)*40)
• numero giri carico = 100

La velocità invece l'ho calcolata così:

ogni giro pignone sono 29.189°. Il motore è un 4 poli perciò senza avere la targhetta assegno 1400 rpm, riduttore 1:40 quindi il pignone gira a 0,583 giri/sec

29.189/0,583=17,02°/sec

 

Imposto 17°/sec in impostazioni della dinamica-velocità.

stessa cosa nei limiti.

 

abilito l'asse simulato imposto un posizionamento relativo di 90° ma la velocità attuale non supera 1,38°sec

 

Non capisco dove sbaglio

[batta]

1 ora fa, ken ha scritto:

la funzione "attiva modulo" dovrebbe servire a quello se ho capito bene quello che ho letto nel manuale.

La funzione "modulo" serve per far ripartire da zero il conteggio una volta raggiunto il valore del modulo. Nel tuo caso, serve per avere sempre quote comprese tra 0 e 360 gradi (359.999, ad essere pignoli).
Questa funzione non ha nulla a che vedere con i giri dell'encoder. Il sistema gestirebbe correttamente le quote dell'asse anche se tu avessi un encoder singleturn. Con un singleturn, probabilmente, potresti avere problemi nel caso di movimentazione manuale della tavola con sistema spento. In questo caso, se fai compiere più di un giro all'encoder, potresti poi trovarti con una quota errata. Per esserne certo, dovrei provare.
Con il multiturn non c'è questo pericolo, e viene gestito in automatico il numero di giri dell'encoder e la sua ripartenza da zero, in modo del tutto trasparente. Ovviamente, se sono stati impostati correttamente i parametri dell'encoder. Ma, anche questo, non ha nulla a che vedere con l'attivazione del modulo.

 

1 ora fa, ken ha scritto:

in teoria non dovrei aver bisogno di homing perchè farei posizionamenti relativi.

E se, per qualsiasi motivo, parti da una posizione sbagliata? Ti sei fermato a metà strada perché hai premuto un'emergenza o è mancata tensione?
Io farei l'homing una sola volta, e poi posizionamenti assoluti.
Per l'homing, in MC_Home, con encoder assoluto imposta mode = 7.
 

Tornando al discorso rapporti, di solito quando un riduttore ha un numero tondo, come nel tuo caso (40), il rapporto è esattamente quello.
Ma, anche se questo rapporto non fosse esatto, poco importa, dato che l'ecnoder sarà installato (tornando alla soluzione iniziale) sull'albero lento. Il rapporto di riduzione del riduttore, in questo caso, serve solo per pilotare il motore alla giusta velocità. Una piccola differenza dal valore nominale non avrebbe effetti negativi.
Quindi, hai bisogno di precisione solo nel rapporto tra pignone e ralla (sempre considerando encoder su albero pignone).
Considerando i diametri primitivi di pignone e ralla, si potrebbe ipotizzare che siano ruote dentate con modulo 4, da cui il pignone avrebbe 96/4=24 denti, e la ralla 1184/4=296 denti. Il doppio in caso di modulo 2, la metà in caso di modulo 8. Con quei diametri primitivi non mi pare si possano utilizzare moduli diversi da questi, dato che il pignone potrebbe anche avere modulo 3 o 6, ma la ralla no.

Se hai la certezza che i diametri primitivi siano esatti (o se conosci il numero dei denti), io lascerei l'encoder sull'albero del pignone, farei l'homing una sola volta (o con comando dall'operatore), e posizionamenti assoluti.

[ken]

2 ore fa, ken ha scritto:

Numero giri motore = 49333 (servono 493.33 giri motore per fare un giro completo tavola) e mi sembra corretto ((1184/96)*40)

ho modificato i due parametri senza considerare la riduzione della ralla.

quindi 4000 in numero giri motore e 100 in numero giri carico e così funziona come ho calcolato.

Penso di aver interpretato male il parametro.

sicuramente avrò indicazioni migliori con il motore vero e senza usare la simulazione

[batta]

48 minuti fa, ken ha scritto:

ho modificato i due parametri senza considerare la riduzione della ralla.

quindi 4000 in numero giri motore e 100 in numero giri carico e così funziona come ho calcolato.

Non mi quadra.

Il rapporto di riduzione ralla/pignone è 1184/96 = 37/3.

Il rapporto totale di riduzione tra motore e tavola è di 40*37/3 = 1480/3.
La configurazione dell'oggetto tecnologico, con encoder sull'albero del pignone, dovrebbe essere la seguente:

Parametri base                                                                                    Meccanica

   

 

Mentre con encoder sull'albero della tavola, la meccanica sarebbe così:

 

Ma, in ogni caso, il rapporto tra motore e tavola rimane sempre 1480/3.

 

A proposito, hai calcolato che, con questo rapporto di riduzione, con il motore a 1500 rpm la tavola si muove ad una velocità di poco più di mezzo giro al secondo?

Modificato: 9 aprile 2020 da batta

[ken]

è la stessa cosa 1480/3 = 493.33 quindi anche impostando 49333/100 non cambia nulla. ma così facendo non arrivo alla velocità calcolata di 17°/sec

imposto invece 40/1 e tutto va bene. potrebbe essere che considera poi il percorso per giro encoder. non capisco.

riguardo la velocità:

dovrebbe fare 2,83 giri al minuto

1400/40=35 giri minuto pignone

35/12.33=2.83 giri al minuto

 

non è una cosa veloce, è verissimo. la velocità per il tipo di lavorazione è corretta. conta che sopra ci sono bobine di acciaio fino a 2000 kg o forse più, quindi con un'inerzia non indifferente.

ho fatto un trace sul simulato con rampe tranquille e in 14 secondi faccio mezzo giro quindi molto accettabile per il ciclo macchina

[batta]

26 minuti fa, ken ha scritto:

è la stessa cosa 1480/3 = 493.33 quindi anche impostando 49333/100 non cambia nulla. ma così facendo non arrivo alla velocità calcolata di 17°/sec

Ti è rimasto uno zero nella tastiera ;-)

Che dire...

Ho provato col simulatore, e c'è decisamente qualcosa che non va. Se si imposta encoder sul lato di carico, tutto funziona regolarmente impostando il rapporto di riduzione 1480/3.
Impostando invece sistema di misura esterno, con il rapporto 1480/3 si muove pianissimo. Con rapporto di riduzione 40/1, l'asse si muove ma comunque si muove molto male: accelerazioni lentissime, che non rispecchiano assolutamente quelle impostate, ed errore di inseguimento elevatissimo.
Eppure, anche controllando sul manuale, l'impostazione corretta dovrebbe essere quella che avevo indicato.

Dovrò approfondire.
Di solito lavoro con brushless ed encoder sul motore, e non mi ero mai imbattuto in questo problema.

[ken]

io avevo sempre usato i posizionatori integrati nei drive sia G che S ma avevo sempre fatto posizionamenti lineari, sempre su macchine come questa. il passo dopo aver legato la bobina è quella di accatastarla sopra le altre. c'è un magnete o un mandrino che prendono la bobina, la si solleva e la si sposta sopra una stazione di deposito. li la traslazione è affidata ad un motoridutore con cremagliera.

 

Tornando al problema vero. direi di testarlo dal vivo. devo solo tornare al lavoro e avere il motoriduttore. il resto del materiale c'è

perchè mi è rimasto uno zero nella tastiera?

1480/3=493.33

49333/100=493.33

ora non posso postare il trend. per simulare non uso un pc collegato a internet, sono a casa senza switch... l'accelerazione mi quadra. imposto 6,8°/S^2 che corrisponde a 2.5 secondi. in più ho la S; dal trend è quello che vedo S compresa arrivo in velocità in 3,5 secondi quindi in linea con i parametri. l'errore di inseguimento si, è alto, circa 5° quando sono in velocità. se però non pompo col proporzionale è decisamente più alto

 

Batta ti ringrazio e metto da parte una bottiglia virus free (ho imbottigliato il giorno prima di aver la febbre.. quindi metto da parte il vino imbottigliato a gennaio). appena riesco provo dal vivo.

[batta]

1 ora fa, ken ha scritto:

perchè mi è rimasto uno zero nella tastiera?

Mi riferivo alla velocità massima: 1400 * 60 / 40 / 37 * 3 = 170 °/s, non 17.

 

1 ora fa, ken ha scritto:

ora non posso postare il trend. per simulare non uso un pc collegato a internet, sono a casa senza switch..

Guarda che puoi provare praticamente tutto anche con PlcSim. Ovviamente non vedi la tavola che gira, ma riesci a controllare tutte le variabili: velocità, posizione, errore inseguimento, velocità del motore, e molto altro. Puoi anche fare i trace.

[batta]

1 ora fa, batta ha scritto:

Mi riferivo alla velocità massima: 1400 * 60 / 40 / 37 * 3 = 170 °/s, non 17.

Mi autocorreggo, e mi cospargo il capo di cenere.
Il calcolo corretto è: 1400 * 6 / 40 / 37 * 3 = 17 °/s.

 

[ken]

Hai fatto il mio stesso calcolo in modo diverso. Capita Batta. solitamente sono io quello che cicca qualche formula e quindi non ho più verificato.Mi sembrava strano 170° al secondo, sono praticamente 1 giro di tavola in 2 secondi. 

Comunque grazie ancora, mi hai aiutato più di quanto potessi immaginare. 

appena provo dal vivo posterò cosa succede. c'è sempre quel fatto della riduzione che devo approfondire.

 

PS mi piacerebbe farti provare il vino che fa un nostro cliente portoghese. una bontà.

[batta]

2 ore fa, ken ha scritto:

mi piacerebbe farti provare il vino che fa un nostro cliente portoghese. una bontà.

Magari!

 

Pensa che ci sto ancora sbattendo la testa. Oramai è diventata una sfida.

Se imposto l'asse come lineare anziché rotante, impostando un passo vite (ovviamente assurdo, se fosse reale) di 360 mm, in modo da far corrispondere un giro vite a 360°, impostando 29.1891891891892 (mm ma che saranno gradi) per giro encoder, impostando 1480 giri motore per 3 giri del carico, tutto funziona regolarmente.
Se imposto l'asse come rotativo, si impalla.

Eventualmente, potrai seguire questa strada.

 

La cosa che mi pare strana, è che non si tratta di un errore introdotto recentemente, con gli ultimi aggiornamenti, ma ho provato anche con oggetti tecnologici di versioni precedenti, e con TIA V15.1, e si comporta allo stesso modo. Possibile che nessuno si sia mai accorto di questo grossolano errore?
Penso aprirò un case con il supporto Siemens.

[ken]

Voglio provare a sentire un amico che fa le mie stesse macchine e utilizza da tempo il motion nel tia. Penso abbia già provato qualcosa del genere.

Ti aggiorno poi. 

Non penso di poter utilizzare quell'encoder con la cu, altrimenti dal vivo proverei anche con il posizionatore integrato nei sinamics.

[batta]

17 ore fa, ken ha scritto:

Voglio provare a sentire un amico che fa le mie stesse macchine e utilizza da tempo il motion nel tia.

Anch'io uso da parecchio tempo gli oggetti tecnologici per il motion, solo che, quasi sempre, ho motori brushless, quindi non mi si presenta questo problema.

In un solo caso, che io mi ricordi, mi sono trovato con una configurazione simile, solo che il rapporto corona/pignone era solo di 3/2.
L'asse, in realtà, non mi ha mai entusiasmato come prestazioni (anche se per quell'applicazione erano comunque buone), ma ho sempre dato la colpa al fatto che stavo usando un asincrono e un G120C.
Ora, sono convinto che la colpa non fosse dell'asincrono e del G120C, ma dell'oggetto tecnologico.

 

Per risolvere il tuo problema, puoi comunque impostare l'asse come lineare (mm o gradi è solo per comodità). Se metto il passo vite pari a 360 mm, avrai che un giro dell'albero del carico corrisponde a 360 "unità" che, nel tuo caso, saranno gradi.

 

La configurazione dovrebbe essere questa:

 

 

 

Ho inviato richiesta al supporto tecnico Siemens. Vediamo cosa mi rispondono.

[ken]

Sto simulando per il software di "contorno". in questi giorni provo tanto sono a casa, solo, in isolamento, unica cosa che mi fa passare le giornate sono questi test.

[batta]

Chi dice che l'assistenza Siemens è lenta?
Sono già stato contattato dal tecnico. Pure lui è dell'idea che si tratti di un bug, anche se mi pare strano che non sia mai stato segnalato. Se trova errori nelle impostazioni (qualche parametro interpretato in maniera non corretta?), mi ricontatta. In caso contrario, passa la segnalazione ai tedeschi.

 

Comunque, Ken, configura come ti ho detto, come asse lineare. Puoi provare l'asse anche con il simulatore (dovrai impostarlo come asse virtuale, perché hai l'encoder esterno).
In simulazione, mi dà errori di inseguimento che non arrivano a 30 millesimi di grado. La realtà sarà diversa, ma non di molto, se il sistema è ben tarato.