NEW Servo Drive Dc 100W e 800W

[Pedro]

non mi sono spiegato bene, i sistemi di protezione sui driver per servo sono molteplici, uno è quello che a tot step devono corrispondere tot letture sull'encoder più un errore massimo che deve essere corretto dal closed loop, un altro sistema di protezione, se l'encoder è solidale col motore in un modo o nell'atro (quindi anche se fosse una riga ottica lineare che a sua volta è mossa da un asse della macchina che è mosso da una vite e che è mossa da un motore). Questo sistema si basa sulla taratura che si fa sul driver per cui a tot giri di motore devono corrispondere tot impulsi sull'encoder a prescindere dagli step che gi si danno in input. Siccome la rotazione del motore è data dal servodriver se questo sa che sta ruotando le tre fasi, se brushless, o dando tensione se Dc o comunque sta provando a far girare il motore e quello sta in "folle" rispetto all'encoder anche li il driver si mette in errore

[walgri]

Ok Pedro, grazie !

Per un brushless il driver può sapere, se glielo si può impostare, quanti impulsi di encoder deve aspettarsi ad ogni giro, e visto che è lui medesimo che ruota le fasi può verificare l'errore, ma su un DC ? A me non viene in mente altro che un timer (però non quello di cui parlavo prima), il quale non dovrebbe consentire che a una tensione in uscita diversa da zero non corrisponda un impulso di encoder entro un tempo ragionevole (e magari anche di segno concorde).

Ora sto ovviamente estendendo il discorso oltre il mio problema specifico, che magari si risolverà  una volta sistemati i cablaggi e le schermature rispetto al guazzabuglio che è già  ora con un solo motore.

Grazie

[Pedro]

in effetti su un driver DC la cosa non è semplice ma si potrebbe fare, come dici tu, con un timeot. In effetti una taratura tensione/velocità  dovrebbe essere fatta, se no il PID successivo come fa a sapere come e quanto correggere. Quindi se il sistema ha errore di posizione (per qualsiasi motivo) comincia a correggere ma se vede che non corregge un accidenti deve tagliare il loop se no va in saturazione. Ovvio che il timeout può essere proporzionato all'uscita, si può studiare

[Zebrauno]

Il fenomeno della fuga e' descritto anche in alcuni manuali tecnici che ho letto in passato (Heidenhain e Renishaw) ed esula totalmente dagli aspetti teorici del closed loop poiche' a causarlo e' un misto di interferenze o differenze di potenziale, spesso dovute a schermature errate o loop di massa, che di fatto ingannano il driver illudendolo di contrastare con successo una forza applicata al motore (che non fa muovere l'encoder oltre il limite di errore impostato).


Per Toshiro, dalle mie prove togliere l'alimentazione (o la massa) all'encoder non causava effetti dannosi, il motore rimaneva privo di tensione.
L'unica condizione capace di creare la fuga e' il distacco del segnale A o B, staccandoli entrambi non accadeva nulla.


Con gli altri motori BLDC che avevo il controllo aggiuntivo era dato dal monitoraggio dei 3 sensori Hall presenti nel rotore.

[Pedro]

un resolver su un motore a rotazione libera fa solo che bene

[walgri]

Zebrauno, questi documenti sono reperibili in qualche modo ?

Ho fatto una ricerca su "runaway axis" e salta fuori una bella pletora di documenti e riferimenti, dei quali ho letto alcuni. E son tornato a far prove. Scusate ma credo dovrò essere più prolisso del solito.

Ho attivato la finestra di dialogo con i segnali dell'encoder ed ho visto che erano "puliti", per quanto possano esserlo a una visione mediata attraverso una connessione seriale, l'interfaccia grafica e tutto il resto. (Non ridete per favore )

Motore fermo, inchiodato (talvolta "freme", anche se l'errore visualizzato è 0, magari perchè non riesco a vederne la variazione ?)

Provo a muovere l'asse del motore, e questo freme ma rimane inchiodato, vedo chiaramente l'errore che varia e con esso l'uscita.

Fin qui tutto ok, credo.

Stacco la "presa" dei segnali dell'encoder: a volte il motore viene messo in fuga, a volte no, e in questo caso il motore è ovviamente inerte. Quando non va in fuga, il motore resta inerte, per lo meno finché ho la pazienza di aspettare (pochi minuti, in realtà ). Mi vien quindi da pensare che non ci siano interferenze nocive sui segnali dell'encoder, non so se su altro, però.

Un modo certo che ho di innescare la fuga è forzare l'albero del motore e staccare la presa dei segnali.

Fuga che viene innescata anche facendo fare uno step al volantino e che sempre con il volantino riesco a fermare e a invertire (se son abbastanza veloce).

Faccio un'altra prova: imposto una banda morta a circa 5. Niente fughe se non dopo decine di inserimenti ed estrazioni a caldo della presa e dopo che ho visto l'errore oltrepassare la banda morta.

Ovviamente in fuga l'integrale cresce (in valore assoluto) e con esso l'uscita.

Fin qui le prove.

E' forse da notare che lo stacco della presa può facilmente generare un pattern valido ai fini della interpretazione dei segnali da parte del driver. Basta che almeno uno dei due segnali A e B sia basso. Quando entrambi sono bassi facilmente il segnale non varierà  contemporaneamente in entrambi i canali, generando, correggetemi se sbaglio per favore, due impulsi validi. Validi anche a generare l'errore che innesca la fuga, secondo me.

Ora:
La calza del cavo segnali è collegata al GND del segnali nel morsetto del driver, libera dal lato encoder. La calza del cavo di potenza del motore è collegata allo chassis del quadro, libera dal lato motore, che attualmente non è collegato a terra (ouch credo di dover rimediare al più presto). Attualmente l'Arduino che gestisce i segnali del volantino è alimentato dallo stesso portatile a cui è collegata la seriale del driver. Questo mi ha fatto pensare a un loop di massa, ma ho provato ad alimentare l'Arduino con un secondo portatile a batteria, senza modificare il collegamento seriale, e nulla è cambiato rispetto a quanto sopra.

Da mountain biker, non credo di aver mai visto tante fughe in vita mia ! Qualunque altra informazione o suggerimento su cosa provare è calorosamente accolta.

In questo momento, sembra che l'unica cosa che possa fare, con quello che ho e senza ulteriori circuiti elettronici, per cautelarmi da queste fughe sembra essere impostare un basso limite all'integrale, anche se attualmente non ho la più pallida idea dei valori che può raggiungere durante una lavorazione, mentre la banda morta la lascerei a zero, vedere un motore elettrico che ha un lasco simile alla trasmissione di un Defender degli anni 90 fa una certa impressione.

Che ne pensate ?

Grazie !

[Pedro]

posso dirti che sulla mia macchina, ho servi brushless, se non collego la massa ai motori fa un gran casotto. Non so se il problema possa essere questo ma io comunque la collegherei

[walgri]

Fatto, nessun cambiamento.Per un attimo ho sperato .

[Zebrauno]

Per me c'è un problema di loop nelle masse e/o una carenza di schermatura.....la banda morta devi tenerla a zero.

Magari allega una foto per farci vedere in che condizioni esegui la prova, lasciando tutto cosi' come si trova.

ciao

[Pedro]

lo fa su di un asse o su più di uno?

[walgri]

Ho cablato solo un motore, la macchina non esiste ancora. Faccio delle foto di come son messo ora e poi monto anche il secondo.

[scj]

ma, fammi capire. E' un problema che capita solo a te o può interessare tutti?
io non ho avuto questi fastidi anche se ho fatto solo qualche provetta

[marcosin]

Ho riletto i messaggi ma non ho capito se hai problemi durante il normale funzionamento oppure le prove che stai conducendo sono solo mirate a capire che succede in caso di anomalia all'encoder.
Sul drive non vi sono accorgimenti particolari, se si scollega tutto l'encoder o un canale, fino a quando l'errore è 0 il motore rimane senza alimentazione, ma se l'errore aumenta anche di un solo punto inizia a girare.
Ovviamente se aumenta di un punto ha poca accelerazione perchè va dietro al caricamento dell'integrale, se l'errore è più ampio (magari perchè arrivano gli impulsi di step) l'accelerazione è maggiore.
Non è semplice fare un buon controllo di encoder failure su un servo dc, anche se è possibile, ma serve implementare anche un pò di hardware, non si riesce a farlo solo con il firmware o per lo meno io.

[walgri]

@scj: per come ho capito il funzionamento del sistema e da questo chiarimento di Marco, potrebbe capitare a tutti. Che si chiami fuga o meno. Di fatto se stacco l'encoder quando il driver segnala un errore di posizione, aumenta progressivamente l'uscita fino a saturazione. E a volte l'accelerazione inizia anche quando l'errore è zero, anche se non ho avuto modo di verificare se avevo l'A o il B bassi al momento di staccare la spina. E' possibile che l'errore sia generato proprio dallo stacco la spina, in base al ragionamento che ho esposto qualche post fa.

Anzi, se potessi fare delle prove e riportare i risultati a questo punto sarebbe utile.

@Marcosin: se possiamo considerare normale il "controller" che ho fatto con un Arduino, durante il normale funzionamento è tutto letteralmente perfetto. Ora sto provando cosa succede nel caso di anomalie nell'encoder o nei cavi. Il fatto è che da quello che scrivi, è tutto letteralmente perfetto anche in questi comportamenti con cui sto appestando il tuo thread.

@tutti:
Ne sto parlando qui perché finora non avevo mai letto niente nei vari thread che parlano di sistemi servo e in tutto il forum non ci son che due pagine di messaggi contenenti fuga ass*, e a parte i messaggi che ci stiamo scambiando ora ci saranno una mezza dozzina di rilevanti messaggi tuoi, di turbina e di ciro.postiglione.
A me capiterà  di sicuro di inciampare sul cavo dell'encoder mentre la macchina è in funzione

Possiamo abbozzare qui una serie di indicazioni e raccomandazioni per evitare questo comportamento ?
Oltre a un limite al valore dell'integrale ?

Senza voler entrare nel dettaglio di come è implementato il firmware (neanche capirei), perché non sembra così adeguata una routine che, in presenza di errore di posizionamento, misura l'intervallo di tempo che passa tra un impulso dell'encoder e il successivo e mandi il driver in fault se l'intervallo è superiore a, immagino, 1/60 s ?

E un circuito che si interponga tra l'encoder e il driver che all'occorrenza tagli l'enable ? Considerato che l'uscita é in PWM ?
Quanto può essere affidabile un tale sistema ?

Grazie a tutti.
Che scuola !

[Zebrauno]

Se puoi inciampare sul cavo dell'encoder allora puoi anche inciampare su quello di potenza o di consenso del mandrino e farlo smettere di girare mentre esegue una tasca nell'alluminio....a quel punto ti saverebbe solo il limitatore di corrente impostato sugli assi.

Forse e' piu' facile allestire delle protezioni o boxare la cnc in modo che i cavi non siano accessibili e viaggino dentro catene, o dentro canaline per pavimenti se li fai passare a terra.