Motore brushless in fuga.

[Pappardella]

Buongiorno a tutti. Ho un motore NUM come in foto, che va in fuga appena lo collego al drive. E' retroazionato con un resolver SICK del tipo hiperface, codice SKM36-HFA0-S05. Vorrei controllare se l'encoder è guasto oppure no. Con un tester è possibile fare una verifica sui pin di collegamento del resolver?

Lato potenza sembra OK, nessuna interruzione sulle fasi, e resistenza ohmica uguale su tutte e tre le fasi.

Grazie come sempre...

[Ctec]

Per il lato resolver, va alimentato l'encoder, e poi misuri le uscite SIN e COS, che ti danno una coppia di valori analogici che definiscono la posizione assoluta dell'albero. Girando a mano, devi vedere i valori cambiare. Ciascun segnale fa una sinusoide completa ad ogni giro, e sono sfasate tra loro di 90°.

Per il lato Hiperface, invece, questo è un protocollo di comunicazione, per cui diventa complicato.

A volte vanno in fuga semplicemente perché c'è da girare le fasi del motore (in pratica l'encoder "gira" in un senso e il motore nell'altro).

[mc1988]

Non credo che il resolver si possa controllare con un normale multimetro.

Probabilmente occorre un oscilloscopio almeno doppia traccia di buon livello e resta comunque un'operazione che richiede una certa perizia tecnica.

[Livio Orsini]

33 minuti fa, mc1988 ha scritto:

Non credo che il resolver si possa controllare con un normale multimetro.

 

Se fai ruotare lentamente, a mano, l'albero motore lo puoi verificare tranquillamente anche con un tester digitale; con uno anlogico è più facvile.

È un'operazione che ho eseguito parecchie volte.

Devi pensare che ad ogni giro di albero dal resolver esce un segnale di una sinusoide ed un altro segnale di una cosinusoide.

Addirittura usando due voltmetri analogici vedi chiaramente l'andamento sfasato dei due segnali.

 

L'oscilloscopio ti serve se hai il motore che ruota alimentato, ma inquesto caso non puoi farlo perchè va immediatamente in fuga.

[Pappardella]

Grazie a tutti per le risposte!

In pratica si tratta di un resolver multigiro se ho capito bene. I segnali sono analogici, la porta seriale serve all'accensione per comunicare al drive di controllo il numero di giri dato che si tratta di una retroazione assoluta?

 

Avrei un'altra perplessità che vorrei condividere. E' possibile che il costruttore del drive memorizzi nella EEPROM del resolver alcuni dati tramite la comunicazione seriale, in maniera tale da renderlo compatbile solo con quel drive?

Mi è venuto questo dubbio perchè lo stesso motore portato in un laboratorio Schneider alcuni anni addietro, girava perfettamente, installato sul drive NUM andava in allarme...

Grazie ancora a tutti!

[Livio Orsini]

13 ore fa, Pappardella ha scritto:

n pratica si tratta di un resolver multigiro

 

I resolver sono monogiro, danno la posizione assoluta nell'ambito di un giro.

 

13 ore fa, Pappardella ha scritto:

la porta seriale serve

 

Quale porta seriale?

 

13 ore fa, Pappardella ha scritto:

E' possibile che il costruttore del drive memorizzi nella EEPROM del resolver alcuni dati tramite la comunicazione seriale, in maniera tale da renderlo compatbile solo con quel drive?

 

tutto è possibile, anche che un resolver abbia una memorria eeprom, anche se mi sembra poco probabile. Bisognerebbe disporre delle specifiche tecniche del resolver.

[19simo89]

non devi fare qualche fasatura sul resolver-motore tramite drive? che modello di drive hai?

[Pappardella]

Il 04/02/2025 alle 12:08 , 19simo89 ha scritto:

non devi fare qualche fasatura sul resolver-motore tramite drive? che modello di drive hai?

Ciao, è un NUM MDLU30144B000N01, serie Axium...

[Pappardella]

Il 04/02/2025 alle 07:12 , Livio Orsini ha scritto:

 

I resolver sono monogiro, danno la posizione assoluta nell'ambito di un giro.

 

 

Quale porta seriale?

 

 

tutto è possibile, anche che un resolver abbia una memorria eeprom, anche se mi sembra poco probabile. Bisognerebbe disporre delle specifiche tecniche del resolver.

 

In questo momento, Pappardella ha scritto:

 

 

Il 04/02/2025 alle 07:12 , Livio Orsini ha scritto:

 

I resolver sono monogiro, danno la posizione assoluta nell'ambito di un giro.

 

 

Quale porta seriale?

 

 

tutto è possibile, anche che un resolver abbia una memorria eeprom, anche se mi sembra poco probabile. Bisognerebbe disporre delle specifiche tecniche del resolver.

Buonasera Livio, allego estratto del datasheet del resolver Hiperface Sick SKM36-HFA0-S05. C'è una EEPROM a bordo ed il connettore ha due pin in più per il collegamento tramite RS 485...

 

 

[Livio Orsini]

Non hai il manuale di questo resolver?

Però ho un dubbio: quel connettore è montato fisicamente sull'involucro del resolver o è su una scheda di interfaccia?

[lucios]

Guarda che quel Sick è un encoder, non un resolver. Ha una interfaccia di comunicazione Hiperface che trasmette i dati all'azionamento, quindi, secondo me non è semplicissimo controllarne il funzionamento senza appositi strumenti.

Avevo letto qualcosa in passato quindi prendi quello che ti dico con il beneficio del dubbio ma, se non ricordo male, l'interfaccia Hiperface dovrebbe fornire anche tutta una serie di errori che, se correttamente gestita, dal controllore, dovrebbe farti uscire dei messaggi e impedire il movimento del motore.

Tu dici che è connesso ad un azionamento tipo MDLU, quindi Num; presumo quindi che il tutto sia comandato da un CNC sempre Num. Se così fosse, il tutto, a meno di parametrizzazioni errate sul CNC dovrebbe farti uscire a video dei messaggi di allarme e non permetterti la fuga del motore.

 

 

[Livio Orsini]

22 minuti fa, lucios ha scritto:

Guarda che quel Sick è un encoder,

 

Lucios è forse un encoder che genera 2 segnali sinusoidali sfasati di 90° invece di 2 onde quadre? Anzi sono 4 onde quadre perchè ci sono anche quelle in controfase.

 

[lucios]

Quote

Lucios è forse un encoder che genera 2 segnali sinusoidali sfasati di 90°

Ciao Livio, mi hai incuriosito e ho trovato questo

https://www.sick.com/it/it/catalog/prodotti/sensori-motion-control/sistemi-motor-feedback/sksskm36/sks36-hfa0-s05/p/p656717

 

Comunque, come dicevo a Pappardella, dalla tabella di stato nel link si vede che ci sono tutta una serie di errori che dovrebbero essere gestiti dal controllore.

Quote

Avrei un'altra perplessità che vorrei condividere. E' possibile che il costruttore del drive memorizzi nella EEPROM del resolver alcuni dati tramite la comunicazione seriale, in maniera tale da renderlo compatbile solo con quel drive?

Mi è venuto questo dubbio perchè lo stesso motore portato in un laboratorio Schneider alcuni anni addietro, girava perfettamente, installato sul drive NUM andava in allarme...

Non credo, è invece sicuro che il drive debba venire parametrizzato con le caratteristiche del motore e del rispettivo encoder.

 

Ma chiedo: normalmente i motori Num sono forniti con un encoder integrato standard che quindi rientra nelle tabelle di parametrizzazione del CNC Num. In questo caso perchè si utilizza un Sick con quelle caratteristiche?

 

 

[Livio Orsini]

Grazie Lucios, la mia era pura curiosità.

Non ho mai lavorato molto con i controlli numerici, però so che l'uso di questi encoder era molto apprezzato da dolor che volevano elevate risoluzioni ma frequenze non elevate.

Con questi encodere, per avere un elevata risoluzione, bisogna poi avere dei convertitori A/D veloci e precisi, poi bisogna anche avereun buon algoritmo di discriminazione del senso di rotazione.

Io ho sempre preferito interfacciare l'encoder ad onda quadra, aumentando il numero di i.p.g.; la frequnza sale, quindi devi curare bene i cablaggi degli encoders però, a mio avviso è tutto più semplice e preciso.

 

Da quello che scrivi deduco che pensi che forse hanno fatto un "matrimonio sbagliato" tr trasduttore e controllo.

 

Purtroppo si ad ora a nessuno è venuto in mente di chiedere se prima il tutto funzionava regolarmente. Non vorrei che...

[lucios]

Ariciao Livio,

Quote

Io ho sempre preferito interfacciare l'encoder ad onda quadra

Beh sì, prima dell'avvento degli encoder assoluti con interfacce digitali si faceva come dici tu anche con i CNC, si fa ancora in diversi casi, oppure si usavano dei sinusoidali con segnale di zero anch'esso sinusoidale. I segnali  vengono poi squadrati alla bisogna per effettuare ad es. i conteggi di misura per i CNC.

Ora è tutto digitale... si sta abbastanza imponendo l'interfaccia ENDAT inventata da Heidenhain che è uno dei maggiori costruttori di trasduttori.

Stiamo un po andando fuori tema ma ti giro ugualmente un link visto che, anche se sei dipendente dell'INPS come me, sei ancora curioso verso le nuove tecnologie.

https://news.heidenhain.com/it/automazione/integrazione-di-sistema-con-endat

 

 

[Livio Orsini]

Grazie Lucios

Si, ci sono stipendiati INPS che vanno a vedere i cantieri, ma ci sono anche quelli come noi che continuano con il lavoro di spempre, ma con il previlegio di scegliersi di cosa uccuparsi, di quando e per quanto farlo.😄