Mimoletti il tuo progetto usa una scheda fuori standard basata su MCU PIC che ormai è obsoleta quanto mia nonna (pace all'anima sua).
Oggigiorno sviluppare un PCB con microcontrollore ha senso se hai volumi dal migliaio di pezzi in su.
Per un progetto casalingo non c'è ragione di mettersi a fare un PCB con tutte le incognite del caso. Meglio partire da una scheda già fatta che oltre che garantire il perfetto montaggio costa meno dei soli componenti che un normale hobbista deve acquistare per costruirsene una.
Poi per carità, se uno deve farsi una cosa particolare che non trova va benissimo, io spesso faccio PCB custom ma sono cose difficili da replicare acquistando schede pronte. In questo caso serve un microcontrollore e, a parte, un driver stepper. Nulla più.
Detto ciò
tarzan: "1-quanta risoluzione dell'encoder serve realmente per un risultato ottimale non distinguibile dal cambio ad ingranaggi?
Vedo gente con encoder da 1000 passi da processare con schede ultra performanti ed altri che con 300/400 passi e arduino nano fanno lo stesso lavoro!
"
300 passi di encoder, nel mio progetto, voglio dire 1200 passi di risoluzione su una rotazione completa, il che vuol dire (360/1200=0,3 gradi). Ovvero il sistema sarà in grado di eseguire come minimo 1 passo sul motore della vite madre ogni 0,3° di rotazione angolare del mandrino.
Spesso si confonde la risoluzione con l'errore. L'errore dipende dagli accoppiamenti meccanici, non dalla risoluzione dell'encoder. Potremmo anche montare un encoder da 360passi ad ogni rotazione (encoder da 90 passi, ad esempio): nel qual caso avremmo una risoluzione di 1° che sarebbe comunque più che accettabile e sfido chiunque ad apprezzare una differenza sul filetto.
tarzan:"Avrebbe senso motorizzare con un sistema di stepper "closed loop" ? Il kit non costa tanto di più della versione Open... sarebbe più affidabile e meno rumoroso. "
Nulla in contrario a patto che sia il driver a controllare l'encoder montato sul motore stepper. A mio avviso questa cosa ha senso se si monta un motore di bassa potenza che potrebbe perdere passi. in questo modo il driver si incaricherebbe di controllare che il motore abbia effettivamente eseguito i passi dati. Io personalmente mi preoccuperei di più di dimensionare i motore correttamente: in questo modo i passi non si perdono ed evitiamo di inserire nel loop di controllo una variabile in più. Ricordandosi sempre che ciò che non c'è non può generare errori e non può rompersi..... come dicono gli americani: "less is more",,,,
tarzan:"3-Di quale hw dovrei dotarmi per non precludere l'upgrade ai 2 assi? É sufficiente Uno, Nano o a sto punto direttamente Mega? "
Se vuoi replicare il mio progetto devi prendere una UNO. La nuova versione, se mai avrò tempo di farla, sarà fatta su ARM cortex a 32 bit e per comodità userò na Nucleo di ST: costa meno di Arduino ed offre una potenza di calcolo assolutamente non paragonabile.
In linea generale i microcontrollori a 8 bit sono obsoleti: trovano ormai applicazione solo in sistemi ultra semplici dove la minima differenza di costo fa la differenza (milioni di pezzi). Per sistemi come questo è inutile incaponirsi sugli 8 bit: non offrono alcun vantaggio visto che la differenza economica è di una manciata di centesimi. Per darvi un'idea, una MCU ARM Cortex M0 a 32 bit oggigiorno può costare anche 0,4€ per volumi...... un PIC a 8 bit 0,2. Se avete un milione di pezzi da comprare fa la differenza ma se dovete comprare una scheda da hobbista nemmeno ve ne accorgete.
|
