Sistema di test per elettronica: come procedere?

[TND-storm]

Ciao, rieccomi dopo qualche mese di assenza (alcuni problemi al lavoro e personali mi hanno fatto mettere in standby il discorso CNC).

L'idea in questo momento è sempre quella di tentare un sistema a 2 motori per l'asse principale in modo da non avere la vite centrale e così non avere limiti di altezza dei pezzi da lavorare. Sarebbe una funzionalità  particolarmente utile quindi l'alternativa ai 2 motori sincronizzati sarebbe in pratica solo quella di mettere 1 motore che muove 2 viti, il che però rischierebbe di minare la precisione in maniera eccessiva, oltre ad introdurre più componenti meccanici che potrebbero creare problemi rispetto ai collegamenti diretti.

L'importante quindi è verificare che sia possibile mantenere la sincronizzazione anche in qualunque circostanza standard di funzionamento e trovando una soluzione per quelle non standard (mancanza di corrente, errori, interruzione esecuzione, ...).

Prima di terminare il progetto della meccanica voglio quindi effettuare questa verifica. Il dubbio è: posso effettuare questa verifica con un sistema "dummy" molto semplificato (ad esempio collegando due viti filettate invece che viti a ricircolo che ancora non ho) o magari addirittura senza meccanica, o l'unica è far test con il sistema più realistico possibile?
La mia idea sarebbe quella di costruire un semplice accrocchio con 2 viti filettate o trapezie a cui collegare i motori e che simuli l'asse principale della macchina, e su quello testare cosa accade nei vari casi. Il vantaggio rispetto a usare i motori a vuoto sarebbe la presenza di un asse reale (che si può danneggiare in caso di errori) che avrà  i finecorsa come nel sistema finale. Ma se doveste ritenerlo comunque insufficiente a verificare la sincronia tanto vale evitarsi questa spesa e fare dei test a vuoto. Cosa mi consigliereste?

Acquisterò a breve la scheda Kflop, i motori e gli azionamenti li ho già  (Omron Accurax G5 da 400W).
Stavo pensando intanto di provare a mettere in funzione un azionamento/motore e magari iniziare a smanettare sui settaggi e le funzioni di autotuning, si può fare o meglio evitare di far andare il tutto a vuoto?

Ho preso il materiale per 2 assi, per ciascuno dei quali ho: azionamento, motore, filtro di linea, cavo encoder, cavo segnale, cavo controller (avranno circa 50 fili e solo un lato ha la spina già  preparata -_- ). Se seguo gli schemi di collegamento non dovrebbero esserci problemi a fare un test rapido del tutto, sbaglio? Avete qualche raccomandazione da fare?

[walgri]

Ciao TND-storm,

il loop sarà  chiuso sui driver o sulla Kflop ?
Se il loop si chiudesse sui driver, come dovrebbe avvenire nel mio caso, sarei (sono) abbastanza preoccupato dall'assicurarmi che i segnali di step e dir arrivino sicuramente ai due driver. E in ogni caso mi lascia pensieroso il fatto che se si sconnettesse uno dei due segnali da un driver, o si guastasse un fotoaccoppiatore o simili, la macchina procederebbe verso l'autodistruzione.

Mentre se il loop si chiudesse nella kflop, l'algoritmo prima o poi andrebbe in fault per superamento del limite dell'errore I, sempre che sia impostato abbastanza basso.

Che ne pensi ?

[TND-storm]

Ciao!
Hmm io chiuderei il loop sui driver ma poi visto che la kflop è programmabile manderei il segnale encoder anche alla kflop e imposterei una verifica fatta in modo che se gli encoder sono sfasati di più di tot impulsi si blocca tutto. Non sono certo al 100% che si possa fare ma sarà  da provare.
Ci sono delle controindicazioni a questa idea secondo te?

[Zebrauno]

A quanto ammonta l'errore meccanico che puo' tollerare la tua meccanica senza distruggersi? Forse non lo puoi quantificare, ma visto che quello che giustamente tu vuoi evitare e' un intraversamento allora perche' non controllare proprio quella condizione, senza fare giri tra encoder, doppie verifiche e programmazioni su Kflop?

Perche' avrei in mente una soluzione per verificare l'allineamento direttamente per via ottica, forse un po' ostico da regolare la prima volta, ma di certo piu' sicuro di qualsiasi routine o programma in C custom per Kflop (devi anche prendere in considerazione che potrebbe perdere parti di programma, o thread con le parti, o tu potresti dimenticarti di aggiornare delle modifiche etc...).

Oppure sfruttando una strain-gauge con un amplificatore di segnale, posizionata in un punto a deformabilita' controllata con dei gradi di liberta' tali da far flettere la strain-gauge, o comprimerla, in modo che sia un segnale inequivocabile di una deformazione strutturale.

Entrambe i metodi possono essere inseriti in una catena a sicurezza instrinseca: se non sono attivi la macchina non parte, lavorando in modalita' NC se rilevano un errore entro la soglia da te impostata si blocca tutto.

Devi anche considerare l'ipotesi che gli impulsi generati da un encoder, o entrambi, possano ricevere interferenze (per ragioni a noi ignote) e dunque sballare i conteggi a valle che ne controllano l'allineamento, quindi vale la pena considerare una soluzione indipendente da qualsiasi cpu, software, programma o routine eseguita su un sistema logico di per se fallace.

ps: potresti sfruttare persino un meccanismo banale, una sorta di interruttore NC costruito ad hoc, molto sensibile, che possa rilevare movimenti di pochi centesimi. Per assurdo persino una sonda 3D potrebbe svolgere quel compito, se fissata nel punto giusto.
ciao

[Pedro]

e chi dice che il meccanismo "banale" sia scevro di erore? e chi dice che poi la verifica finale con mezzi anche accurati di misura finale del pezzo "lavorato" non siano ancorchè essi stessi errati. Così non si finisce più

vero che tutto nella catena, aperta o chiusa che essa sia, qualsiasi parte può introdurre errori, si cerca per questo anche in sistemi chiusi di evitare che ci siano "imperfezioni" e si cerca sempre di prendere sia i componenti migliori che adottare gli opportuni cablaggi (ma poi ci sono facili dimostrazioni sia teoriche che pratiche che "introducendo" degli errori invece i sistemi si stabilizzano, le fuzzy sono solo un esempio ma anche nei sistemi elettronici si sa che l'iniezione "di rumore" esterno proprio per la sua natura randomica stabilizza). Insomma, qualcosa di buono si dovrà  pur fare con quello che si ha a disposizione

PS: e la tolleranza degli utensili di lavorazione credi che siano proprio proprio quantificabili, la loro usura, la densità  del refrigerante, il pelo del gatto siamese che dorme sul divano

Ragazzi, abbiate pazienza con me, comincio ad essere vecchio e faccio discorsi strambi e difficilmente misurabili

PPSS: chiudi, se ne hai la possibilità , un anello del loop sui motori, con i loro encoder, e il sistema con le righe ottiche, se ne hai, sul controller. Un anello che contiene l'altro e non uno che si interseca con l'altro, cosa possibile ma molto difficile da mettere a punto. Ah, dimenticavo..la risposta dell'anello interno, la sua costante di tempo insomma, deve essere sempre più veloce di quello esterno e con smorzamenti più netti anche se imprecisi se non vuoi che il sistema oscilli

[TND-storm]

@Pedro: forse ho capito male il discorso che fai, però si parlava di sicurezza più che di precisione! Cioè visto che voglio mettere 2 motori sincronizzati per l'asse che muove il gantry mi serve che questi motori siano SEMPRE sincronizzati, altrimenti se uno dei due parte e l'altro sta fermo si intraversa il ponte e si danneggia la meccanica!

Per la chiusura del loop ho visto che posso utilizzare il dual loop direttamente sugli azionamenti (nel manuale c'è questa opzione), ma in caso facendo come dici si ha un riscontro sul controller e si può fare in modo che sia quello a verificare che la posizione di ciascun lato del gantry non sballi mai.


@Zebrauno: mi era venuto in mente di usare una sonda 3d mentre leggevo l'inizio del tuo messaggio!
Comunque a questo punto in effetti forse è più semplice verificare che non si intraversi mai il ponte con qualche sistema ottico/meccanico di controllo che impostando elettronica e controller a prova di qualunque errore (sempre sia possibile).
Non saprei però che errore meccanico può reggere la meccanica prima di danneggiarsi, ma almeno qualche decimo penso di sì...

Per il sistema di verifica dell'allineamento ho l'impressione che per via meccanica non sia semplicissimo: ad esempio se usassi una sonda 3d con un braccetto che collega le due spalle non vorrei che anche solo le accelerazioni possano far flettere il braccetto abbastanza da far scattare il blocco. O magari anche le vibrazioni.
Per il sistema ottico che avevi in mente?

[Pedro]

si, hai ragione, mi sono spiegato male io: diciamo essere sicuri della precisione ecco ma poi ho sbandato un po' col discorso di zebra.

Per i due motori, se mandi alla kflop i due segnali dei due encoder e 4 linee di programma in c che controlla la differnza di posizione e se supera un tot o stoppa, o suona le trombe, o fa un reset è piuttosto facile da farsi ma anche un brain su mach3, sempre se usi la kflop, ma qui devo pensarci un po' di più

[Zebrauno]

Con un sistema ottico basato su emettitore laser puntiforme, 3 riflessioni in modo da amplificare l'errore in modo esponenziale e far ritornare il fascio dal lato dell'emettitore potresti apprezzare errori di centesimi e far scattare l'allarme con il minimo disallineamento tra le spalle.

Ciascuno vede in modo chiaro la via che piu' gli e' congeniale e che ha gia' battuto con successo...anche la soluzione che Pedro ha riassunto, basandosi su due diversi feedback di posizione, potrebbe essere molto efficace.

[Pedro]

mi piace il sistema ottico, semplice e ingegnoso

però vedo un problema con i trucioli che volano durante le lavorazioni e con le....mosche

a tutti gli effetti se i motori sono servo e il drive accetta, tutti praticamente lo fanno, il max error allora siccome le viti saranno solidali agli assi dei motori e le chiocciole ovviamente forzatamente legate ai giri del motore allora se uno dei due motori non segue (più o meno un po' di gioco dovuto alle viti non a ricircolo) gli step uno dei motori andrebbe in max error che a sua volta manderebbe in allarme il controller quale esso sia

[walgri]

Da quel punto di vista spostiamo gli encoder sulle viti e così gestiamo in un colpo solo (si fa per dire) anche tutto quello che si può rompere dai finali del driver alla vite.

A valle potrebbe da un lato non funzionare l'encoder e in tal caso continua forse a salvarci il limite sull'errore massimo, dico forse perchè occorre che sia tarato abbastanza basso. Altrimenti si rischia una bella fuga in solitaria di uno dei due motori.

[Zebrauno]

Certo che per funzionare, poiche' trattandosi di un laser, dovrebbe lavorare in modo totalmente inscatolato. Io credo che con un profilo a U di 60x20mm (oppure due L da 30x30) si potrebbe coprire in modo ermetico tutto il circuito ottico visto che le 3 riflessioni, anche incluse delle regolazioni micrometriche sugli specchi, hanno spazio sufficiente. Se il sistema fosse montato dietro il gantry, o subito al di sotto della traversa, non causerebbe alcun fastidio.

A voler fare le cose in grande (piu' che altro complicando l'elettronica di trattamento) si potrebbe allestire un rudimentale interferometro, a questo punto le riflessioni sarebbero superflue e la taratura andrebbe regolata sulla base di un contatore che distingua il numero e il verso della deviazione. E qui la precisione salirebbe virtualmente ai micron, supponendo di avere un gantry privo di vibrazioni in lavorazione.

[Pedro]

il sistema ottico mi piace ma lo vedo poco pratico. Io opterei per un controllo sugli encoder dei motori e loro "sfasamento", se ne può discutere il come ma di modi ne vedo parecchi. Per quanto mettere gli encoder sulle viti: i motori, di solito, hanno encoder di gran qualità , 2048 ppr o più, perchè non usarli e spendere un capitale per prenderne degli altri. Tra l'alto quelli sui motori, ripeto di solito, sono in vetro che è molto più preciso ed accurato di encoder magari di poco costo. Se invece si vogliono mettere encoder di qualità ...beh costano parecchio ecco.

Fare un prototipo? non so che dire, non ne vedrei la necessità . Se la struttura è pesante, e quindi molto robusta immagino, non credo che un motore anche se da 400w possa deformarla o comunque fare danno, i driver hanno tutti un max torque limit, si spengono se sforzano prima di fare "il botto" insomma. Se la struttura è leggera, ma per essere deformata da un servo è molto leggera, allora mi chiedo, vale la pena e il costo di fare un prototipo? a questo io non posso rispondere certo

[Zebrauno]

Ma si possono montare gli stessi encoder dei motori, spostandoli sulle terminazioni delle viti. Io l'ho fatto usando dei semplicissimi adattatori di diametro torniti ma su una macchina costruita da zero questo e' gia' prevedibile terminando le viti con un ulteriore lunghezza di 15-20mm in diametro 8.
Dopo tutto ricordiamoci che ad intraversare il ponte e' una posizione errata delle chiocciole, l'organo che le muove e' la vite....se ci basiamo sull'albero dei motori abbiamo di mezzo ancora i giunti di riduzione (che potrebbero allentarsi) o eventuali pulegge+cinghie, sempre prone a possibile scivolamento.

[walgri]

Motore_vite.jpg

[Zebrauno]

Ecco, Walgri e' gia' pronto alla battaglia