MECCANICA e DINTORNI

Il costo dell'encoder la differenza invece la può fare eccome. Se proprio si vuole spendere qualcosa in più meglio farlo li, quello si che è il componente critico del sistema. La sua precisione ed affidabilità condiziona la precisione e l'affidabilità dell'intero sistema. Un encoder da 2000 passi deve essere fatto MOLTO bene, altrimenti è come averne uno da 200 passi ma che necessita la potenza di calcolo (e le limitazioni) di uno da 2000. Un po' come i 100megapixel della fotocamera degli smartphone, per intenderci....

Cosa vuoi che ti dica, sul mio ho utilizzato un encoder prodotto da una nota ditta italiana, tutti gli altri che lo hanno realizzato (almeno una 50) invece hanno usato un encoder della Omron e nonostante si possa comprare in Cina a meno di 30 euro, funziona egregiamente.
Non sono un'esperto in encoder come te quindi di più non ti posso dire.
In ogni caso sarebbe interessante con un micro a 32 bit, realizzare un progetto con integrato un interprete di G-Code.
Pensi che sia fattibile?
Che linguaggio di programmazione utilizzeresti, per un'applicazione del genere?

Beh questo é esattamente quello che stavo pensando di fare, ne parlavo qualche mese fa proprio in questo topic.
Il linguaggio é pressoché obbligato: C++. Si può pensare anche al python ma è molto meno supportato su queste piattaforme e mi ci dovrei impratichire.

"Nel mio progetto è possibile impostare fino a 3200 stepper per giro, con uno encoder da 2000 P/R.
Cosa non da poco.
In ogni caso quello che fa la differenza è l'algoritmo contenuto nel micro."

se riesci a leggere un encoder da 2000p/r con 20mhz di clock e una routine di interrupt che, se non ricordo male, conterà una 20ina di istruzioni complesse (o forse più), pensa cosa puoi fare con 70mhz a 32 bit....ci puoi anche pilotare il display, sotto interrupt
Riguardo al cannone per ammazzare la zanzara, é vero fino ad un certo punto: con 2 assi da controllare, l'interprete G-Code e l'encoder da leggere, con 8 bit stai stretto. Oddio, volendo si fa ma perché complicarsi la vita quando un 32bit oggi ti costa forse meno di un 8?

"se riesci a leggere un encoder da 2000p/r con 20mhz di clock e una routine di interrupt che, se non ricordo male, conterà una 20ina di istruzioni complesse (o forse più), pensa cosa puoi fare con 70mhz a 32 bit....ci puoi anche pilotare il display, sotto interrupt"

Non solo li leggevo ma nella prima versione addirittura li avevo raddoppiati con una porta Exor. Poi sono sceso di risoluzione per semplificare il circuito.
In entrambe le versioni ho sempre mantenuto la sincronizzazione sia in filettatura che avanzamento.
L'unica cosa che non sono riuscito ad aggiungere nel mio programma è la rampa di accelerazione nella fase di Play, cioè quando si sposta dalla contropunta verso il mandrino.
Attualmente possiede una rampa di accelerazione solo durante la fase di Reverse, cioè quando si sposta dal mandrino verso la contropunta.
Ti sei posto mai il problema di aggiungere delle rampe di accelerazione? Come avevi pensato di risolvere il problema?

Se dovessi fare una nuova versione ovviamente sceglierei un micro a 32 bit.

la rampa di accelerazione la puoi fare ma mentre accelera non sei sincronizzato, ovviamente.... se mantieni il sincronismo il motore stepper si muove in funzione del mandrino quindi velocità e accelerazione dipendono da quello; se vuoi inserire un'accelerazione il motore stepper deve potersi muovere liberamente per tutta la fase di accelerazione.

Ho fatto delle prove ma sono arrivato alla conclusione che in modalità filettatura l'accelerazione non serve a niente visto che la velocità di rotazione del mandrino è comunque bassa. In modalità avanzamento, non essendo invece strettamente necessario mantenere il sincronismo, puoi svincolare mandrino e motore e inserire sia rampa di accelerazione che di decelerazione.
Nelle prove che avevo fatto, in modalità filettatura, per accelerare mentre il mandrino già stava girando facevo fare un giro al motore stepper in accelerazione calcolando i tempi (sia di start che di accelerazione) a ritroso: in pratica il motore faceva una giro esatto con un rampa di accelerazione ed arrivava alla fine del giro con velocità e sincronismo angolare corretti rispetto al mandrino. Chiaramente era fondamentale che la velocità di rotazione del mandrino non variasse durante questo giro di start altrimenti il sincronismo veniva perso. Facendo alcune prove mi sono poi reso conto che, vista la bassa velocità di rotazione del mandrino, questa pratica era totalmente inutile ed anzi inseriva una complessità in più che avrebbe potuto portare ad errori.

In effetti non è ne facile da implementare ne indispensabile, anch’io avevo fatto qualcosa di simile a come hai fatto tu, invece durante la fase di Reverse si apprezza parecchio, soprattutto perché il Reverse è ad una velocità superiore a quella del Play consentendo di abbreviare i tempi di filettatura.

Ciao Max ho visto la scheda della St, se hai avuto modo di provarla puoi dirmi che ide hai usato e se da la possibilità dell' debugging in circuit?
PS vero il prezzo è concorrenziale e la scelta del Pin-header molto furba, ma se vogliono battagliare con Arduino devono scrivere un sacco di librerie, non ho visto in dettaglio il loro framework.

Umbez, la serie Nucleo di ST non vuole in alcun modo andare in concorrenza con Arduino. Quelle di ST sono schede di sviluppo che ST propone ai clienti per "accelerare" lo sviluppo con i loro micro. Il fatto che abbiano una piedinatura compatibile con Arduino è solo per comodità e per permettere ai clienti di poterci attaccare anche schede di concorrenti: ormai tutti i produttori si stanno standardizzando e propongono schede con piedinatura Arduino.
Il costo delle schede ST è simbolico: ST non ha alcun interesse a guadagnare dalle schede cosiddette "fast prototype" ma piuttosto facilitare la vendita dei micro come componenti a se.... Considera che ST è il partner numero uno al mondo di ARM ed è l'azienda con il portafoglio di microcontrollori ARM più ampio al mondo.

Per quanto riguarda l'ambiente di sviluppo ci sono varie strade. Le 2 più facili sono:
STM32Cube: questo il sistema di sviluppo "offline" di ST supportato da una marea di expansion pack. Come disponibilità di librerie ed esempi ST non è seconda a nessuno.
MBED : Questo è un ambiente di sviluppo online di ARM. Registrandosi (gratuitamente) è possibile accedere ad un compilatore online e praticamente quasi tutte le Nucleo di ST sono supportate e coadiuvate da librerie ed esempi. I progetti vengono salvati online in una propria cartella e volendo possono essere condivisi con la community. La comodità del sistema MBED sta nel fatto che non servono driver particolari per caricare il firmware sulle schede: se la scheda è supportata il costruttore ha previsto una sorta di file system tale che, quando attacchi la scheda alla USB del PC/Mac, questa viene vista come un drive USB. Il firmware compilato su MBED viene scaricato in locale e lo si carica sulla scheda semplicemente copiando il file nel drive USB virtuale. Comodissimo e soprattutto standard: qualsiasi scheda supportata da MBED utilizza questo sistema quindi non vi è alcuna differenza tra una scheda ST, NXP, RENESAS, MICROCHIP, ecc....

Per quanto riguarda il debug, con ST32Cube hai tutti i tool necessari (con breakpoints, monitor ecc.), con MBED il debug si fa come su Arduino IDE, quindi Serial print e via andare.....

EDIT: so che alcune Nucleo di ST sono ora supportate anche da Arduino IDE.... ma non ho mai provato...

Belle informazioni Max grazie.

Buon giorno atutti...Finalmento tutto montato sul tornio allego qualche foto prima di scocciarvi chiedendovi dei chiarimenti.




Avendo impostato i dati come da specifica ho dovuto effettuare delle variazioni in particolare se imposto encoder 1440 ( essendoo il mio 360 ppr) mi ritrovo sfasato sulla posizione angolare del mandrino, se invece imposto il valore reale di ppr la posizione risulta giusta.
Di seguito la configurazione
Passi encoder 360
Passi motore stepper 400 ( driver configuarato sempre a 400)
Passi vite madre 3.000
avanzamento carro 300
velocità massima 100

configurando questi dati riesco a filettare ma non ho il giusto valore di spostamento , se imposto il vincolato su 10 mm lo spostamento reale è di 9 . se inve imposta i dati per avere il dato di spostamento giusto i filetti non corrispondono.
Anche la scala presente sul display mi sembra sia impostata a cm e non a mm .

"Avendo impostato i dati come da specifica ho dovuto effettuare delle variazioni in particolare se imposto encoder 1440 ( essendoo il mio 360 ppr) mi ritrovo sfasato sulla posizione angolare del mandrino, se invece imposto il valore reale di ppr la posizione risulta giusta."

Cioè fammi capire, l'encoder è 360passi e tu imposti 360 nel FW e le misure angolari tornano corrette ???

Questo è un problema...
Secondo me hai un problema di connessione o di segnali tra encoder e arduino. Controlla banalmente con un tester se entrambe le uscite in quadratura dell'encoder (A e B) cambiano di stato durante la rotazione. Se hai un oscilloscopio meglio ma non è strettamente indispensabile. Se non sai come fare chiedi che ti spiego in dettaglio.

si max sono corrette , presumo perchè un giro dell'albero dove è collegato l'encoder corrisponde a 4 giri di mandrino, c'è un rapporto 1 a 4 lato encoder

Con le seguenti impostazioni non ho problema con la filettatura
enc 360
passo 3.000
avanzamento carro 300
ma riscontro problemi di avanzamento perde 1mm , provando impostazioni che risolvono la discrepanza nell'avanzamento ho problemi di filettatura

https://youtu.be/kIJFsWmN178[/youtube]


https://youtu.be/kIJFsWmN178

Ciao e scusate se vi rompo con un'altra domanda che forse potevo fare in un'altro thread ma non so dove ;)

In attesa che mi arrivino gli altri pezzi sono indeciso tra questi kit di stepper\driver
https://www.omc-stepperonline.com/it/ki ... ma%2024%5D
E questi :
https://www.omc-stepperonline.com/it/ki ... ma%2024%5D

Spero di poter linkare siti commerciali ed in caso contrario picchiatemi pure ..
Qualcuno di voi saprebbe dirmi le differenze tra questi motori?
So che uno è da 3nm e l'altro da 4nm ma stando alle FAQ del sito e consultando i pdf sembra che abbiano differenze qualitative e curve di erogazione differenti..

Quale sarebbe più adatto per la ELS ?
Il primo è la serie "professionale" il secondo "normale" e poi ci sarebbe anche il terzo tipo con il driver color rosso più economica..

Per la differenza pecuniaria esigua prenderei quello più "figo" ma vorrei un vostro parere anche perchè sulla carta ha meno Nm del secondo ma li eroga diversamente..

Lascia da parte per un attimo la funzione avanzamento, concentriamoci sull'encoder e sulla posizione angolare... il video che hai fatto non considera i passi encoder ma solo i passi viste, ma andiamo per ordine...
Dunque tu hai una riduzione tra il mandrino e l'encoder ? Spiega bene come hai collegato.
Considera che l'encoder, a meno di impossibilità estreme, andrebbe collegato in presa diretta al mandrino per evitare errori e calcoli complessi, non tanto del sw quanto tuoi perché i passi che devi impostare sul parametro encoder sono per UN GIRO DEL MANDRINO, non dell'encoder..
Comunque 360 passi per il mandrino sono troppo pochi in ogni caso; per come è fatto il software il mandrino non può avere meno di 800 passi. In realtà è possibile costruire alcuni passi di filetto anche usando un numero inferiore di passi mandrino ma per eliminare tutte le limitazioni bisogna andare con 800 passi che coprono tutte le configurazioni possibili. Ma ripeto, PASSI MANDRINO, non passi encoder. Puoi ad esempio usare un encoder da 400passi (che diventano 1600) ridotto 2:1. In questo caso essendo l'encoder ridotto rispetto al mandino effettuerà 1/2 giro ogni giro del mandrino e quindi 800 passi. Il motivo per cui consiglio di andare in presa diretta (1:1) è proprio per evitare di scervellarsi con calcoli tra vite, motore stepper, mandrino ed encoder....

Passiamo ora alla vite: tu sei sicuro che sia passo 3mm ? Non è che, per caso, è in pollici ed è passo 1/8" (3.175mm)? Verifica che la configurazione del driver sia corretta a 400passi come li hai impostati nel sw.

tarzan, io andrei con quello meno costoso da 4Nm... Attenzione che il closed loop non faccia casino: è una funzione non richiesta pertanto io non la prenderei......