MECCANICA e DINTORNI

McMax, intanto complimenti per il lavoro. Sto leggendo il programma ed e' un gran bel lavoro.
Ci sono alcune cose che non ho capito, posso romperti le scatole?
Intanto, ho modificato il programma per poter usare il display con un multiplexer i2c, mi faceva fatica collegare tutti i fili del display
Poi ho fatto un pcb per non usare direttamente la scheda arduino.
Se qualcuno e' interessato, posso caricare i files.

E adesso le domande:
1. la variabile actual_integer_steps (che usi nella funzione CreaSequenza) e' un byte. Ho provato a simulare (carta e penna) i conti che fai (1000 passi di encoder, vitemadre passo 3, 800 step/giro e passo filettatura 1mm) e quella variabile va in overflow. Sicuramente la cosa e' voluta (visto che funziona), ma perche' sfruttare l'overflow e non usare una variabile int? Questione di spazio?
2. l'array per stabilire la posizione dell'encoder l'hai dichiarata cosi: char encoder[] = {0, 1, -1, 0, -1, 0, 0, 1, 1, 0, 0, -1, 0, -1, 1, 0};.
L'hai dichiarata char per questione di memoria? I valori che popolano l'array come li hai trovati? Premetto che non ci ho ragionato sopra (mi sto concentrando sulle routine filettatura, quella piu' interessante).
3. per ora sono fermo nella serie di while all'interno della funzione FilettaturaToPosition... in un primo momento mi sembrava non facesse nulla, mi ero scordato che avevi attivato la routine di interrupt dell'encoder che va a modificare diverse variabili (e quindi entri nell'IF appropriato)

E infine alcune "critiche" (piu' che altro gusti personali, leggi: "cose che io avrei fatto diversamente"):
1. non avrei usato il joystick, tutti quelli che ho provato (cinesi o recuperati da controller ps3, sia cinesi che originali) hanno una corsa utile che arriva a poco meno di 3/4 della corsa reale (mi spiego: col joystick a riposo leggo 5kohm circa, lo sposto da una parte e arrivo a 10k molto prima che il joystick sia a fine corsa). Sara' che sono un animale ma devo bisticciare ogni volta per arrivare ad inserire il valore corretto. Se mi riesce, modificherei il programma per mettere 4 pulsanti.
2. il lavoro che hai fatto nei menu' e' una chicca, me lo devo studiare bene per sfruttarlo nei miei (molto) futuri progetti. Io avrei tolto tutto il menu impostazioni, scrivendo direttamente i parametri in una costante del programma. Vero che, come hai fatto tu, il programma e' piu' professionale e pronto da usare (quindi usabile da chiunque... per questo tanto di cappello per il lavoro fatto), pero' togliendo tutta quella parte risparmieresti tutte le routine per scrivere/leggere dall'eeprom e, ovviamente, tutta la parte del menu impostazioni.

Comunque e' e resta un lavoro mastodontico

Ciao Matteou,

scusa il ritardo ma ero via e non riuscivo a risponderti dal telefono.

Matteou:
1. la variabile actual_integer_steps (che usi nella funzione CreaSequenza) e' un byte. Ho provato a simulare (carta e penna) i conti che fai (1000 passi di encoder, vitemadre passo 3, 800 step/giro e passo filettatura 1mm) e quella variabile va in overflow. Sicuramente la cosa e' voluta (visto che funziona), ma perche' sfruttare l'overflow e non usare una variabile int? Questione di spazio?
------

Questa variabile viene usata durante il calcolo di creazione dell'array e al suo interno memorizzo la SOLA PARTE INTERA del rapporto tra passi encoder e passi vite. I passi interi sono quelli che andranno memorizzati nella cella dell'array corrispondente in funzione del rapporto tra passi encoder e passi vite. Mi spiego meglio... o almeno ci provo. Se dal calcolo uscisse ad esempio che il rapporto tra passi vite e passi stepper è 7,5, nella variabile andrebbe il 7 e lo 0,5 che resta andrebbe sommato al 7,5 a creare il passo successivo che, ovviamente, sarà uguale a 8.
Un byte basta e avanza visto che quel numero indica quanti passi encoder bisogna attendere prima di eseguire un passo della vite. Il caso in cui il rapporto sia 255 equivale ad una filettatura con passo di una manciata di centesimi quindi inapplicabile.

Matteou:
2. l'array per stabilire la posizione dell'encoder l'hai dichiarata cosi: char encoder[] = {0, 1, -1, 0, -1, 0, 0, 1, 1, 0, 0, -1, 0, -1, 1, 0};.
L'hai dichiarata char per questione di memoria? I valori che popolano l'array come li hai trovati? Premetto che non ci ho ragionato sopra (mi sto concentrando sulle routine filettatura, quella piu' interessante).
-----------
Questa è la parte di codice che legge l'encoder. L'ho dichiarata char per poter sfruttare i numeri negativi (-1); se l'avessi dichiarata byte avrei avuto solo i numeri postivi visto che la codifica del byte in C (che spesso si chiama unsigned char) prevede solo numeri positivi.
Per velocizzare al massimo la lettura visto che genero un interrupt ad ogni fronte sia del canale A che del canale B, utilizzo semplici operazione di bitshift direttamente sulla lettura delle 2 porte di ingresso dei canali encoder. In pratica leggo simultaneamente le due porte, le metto nel terzo e quarto bit di un byte, le "shifto" di 2 posizioni a destra e leggo lo stato successivo inserendo la lettura sempre nel terzo e quarto bit dello stesso byte che sono rimasti vuoti, in questo modo ottengo un nibble (4 bit) che può assumere 16 diversi valori, ciascuno dei quali corrisponde ad un movimento specifico dell'encoder che può essere +1 passo, -1 passo o 0. La condizione 0 in realtà non dovrebbe mai verificarsi in quanto vorrebbe dire che l'encoder ha eseguito due passi oppure nessuno ma in questo caso non dovrebbe essersi generato alcun interrupt. In pratica i 4 bit vanno a comporre il puntatore sulla cella dell'array da 16 posizioni e sono formati dalle due posizioni dell'encoder adiacenti (2 bit per posizione, A e B..): la precedente e l'attuale. Spero di essermi spiegato... lo so, non è semplice!

Matteou:
3. per ora sono fermo nella serie di while all'interno della funzione FilettaturaToPosition... in un primo momento mi sembrava non facesse nulla, mi ero scordato che avevi attivato la routine di interrupt dell'encoder che va a modificare diverse variabili (e quindi entri nell'IF appropriato)
---------
Esatto, l'interrupt è attivo quindi i passi encoder si muovono da soli...

Sulle critiche sono d'accordo. Il joystick è una gran rottura ma pensavo di sfruttare meglio l'ingresso analogico dei joystick per muovere liberamente il motore stepper anche se alla fine mi sono complicato la vita.
Sulle impostazioni ci ho perso parecchi tempo ma alla fine sono funzionali anche se la memorizzazione dei parametri lascia il tempo che trova.... forse sarebbe bastato salvare le impostazioni correnti per ritrovarle all'accensione successiva....

Grazie per i complimenti. Il lavoro è stato lungo e mi fa piacere che ci sia qualcuno che stia "perdendo" del tempo per analizzarlo così anche da comprendere le difficoltà della stesura di un algoritmo del genere...

Ora sto lavorando al software della saldatrice e non nego che anche qui ci siano parecchie insidie; in ogni caso a livello matematico questo dell'ELS è sicuramente più complesso.

In questi giorni sono stato incasinato anch'io e non ho avuto tempo di continuare lo studio... pero' nei prossimi giorni preparati a essere tartassato di domande

Intanto rispondo alle tue risposte:
1. la variabile actual_integer_step ho capito a cosa serve, ma mi chiedevo se l'overflow fosse voluto o meno.
Ti metto i conti che ho fatto (validi per il primo ciclo for e coi parametri che ti avevo detto):
progressive_pitch = (passo/one_turn_mandrel_steps)*progressive_mandrel_steps=1
long_progressive_ratio = (progressive_pitch/single_step_pitch)*1000000=266666666
integer_remainder = long_progressive_ratio % 1000000=666666
actual_integer_steps = long_progressive_ratio/1000000=266
Quindi actual_integer_steps va in overflow... Sono piu' che principiante nel programmare, mi ero bloccato su questo punto perche', solitamente, se vedo un overflow penso ad un errore.

2. ti sei spiegato benissimo, ma la logica di quell'array l'avevo gia' capita La mia curiosita' era su come avevi trovato i valori dell'array, se c'e' una logica dietro o sei andato a nasometro. Mi spiego: c'e' un calcolo da fare per trovare i valori dell'array oppure hai buttato giu' una tabella con le varie combinazioni dei bit del canale A e B al susseguirsi dei passi e hai trovato i valori "empiricamente"?

Quando trovo un programma che mi interessa, cerco di capirlo per imparare a programmare meglio (se poi l'autore e' disponibile a chiarimenti, e' una manna dal cielo!).
In effetti, col joystick ti sei incasinato non poco la vita, se non altro per la gestione dei valori nei menu (piu' muovi il joystick e piu' il valore cresce velocemente e' una chicca).

Si hai ragione in effetti in quella parte di codice va in overflow ma non serve a nulla... Quel ciclo for l'ho aggiunto nella versione rivista del codice e serve per determinare qual'è la miglior combinazione tra passi mandrino e passi stepper al fine di ridurre al minimo o eliminare completamente errori di arrotondamento. In pratica li viene calcolato il valore di "matched_mandrel_steps" che altro non è che il numero di passi mandrino a cui corrisponde il rapporto con i passi vite con il minor resto possibile. matched_mandrel_steps viene poi usata come riferimento per creare il rapporto che verrà realmente utilizzato nel popolamento dell'array dei passi. Non ricordo come mai ho inserito anche la parte che estrae i passi interi visto che qui non serve a niente. Quella riga si può eliminare.
Se prosegui nella funzione CreaSequenza vedrai che actual_integer_steps viene usata poi nel ciclo for che carica i valori dell'array per estrarre la parte intera del rapporto progressivo ed in quel caso non può andare in overflow.

Per l'array di lettura encoder ho fatto una tabella su carta con le 16 combinazioni possibili ed empiricamente ho assegnato gli step corretti.

Ah, adesso ho capito a cosa ti riferivi nella prima risposta.
Tu facevi riferimento a questa riga: actual_integer_steps = int(real_progressive_ratio); e li' si che non puo' andare in overflow.
Todo claro

Anche la funzione CreaSequenza e' una chicca... insomma, secondo me e' un programma da leggere e capire, si puo' imparare molto.
Curiosita': ma sei programmatore di mestiere oppure sei autodidatta?

A dire il vero, tutto e' partito da Mecha, che si lamentava del ritorno del carro troppo lento (in filettatura). Anche li', ci ho messo un bel po' a capire il senso della routine SetOneShot e FireStep (specialmente la prima... leggendola da sola mi sembrava non facesse nulla... ed in realta' e' cosi'. Poi "risvegli" il timer chiamando FireStep quando ti serve). Io avrei fatto un approccio piu' tradizionalista, usando ocr1 e ocr2, uno come match e l'altro come top. Legando il match al top con una funzione matematica, avrei potuto variare la frequenza (modificando top) lasciando inalterato il duty cycle (match si modifica seguendo top).
Pero' poi non so come mantieni il sincronismo durante la filettatura (vedendo velocemente, richiami FireStep ma devi far qualcos'altro per aggiustare la frequenza). Questa parte di codice (la piu' interessante) devo ancora studiarmela con calma (non anticiparmi nulla... e' un po' come se mi svelassi il finale di un film giallo ), quindi non saprei se il mio approccio potrebbe funzionare o se porterebbe a inutili complicazioni (ragionando mentre scrivo, mi pare che il codice si complicherebbe non poco. Il timer conterebbe sempre e sarebbe da variare il top per stare dietro all'encoder... troppo complicato e forse non riesce a stargli dietro).

No Matteou non sono programmatore ma nemmeno autodidatta. Sono diplomato in automatica/elettronica quindi l'informatica l'ho studiata a scuola ai tempi in cui internet non esisteva e dove la base era l'assembler... i microcontrollori più evoluti erano lo Z80 e il Motorola 68000, rigorosamente ad 8 bit ed i personal computer 8088 e 8086 erano merce rara. A quei tempi la RAM era molto limitata e l'utilizzo dei tipi di variabili richiedeva particolare attenzione.

Ok, non ti svelerò nulla... se non ci arrivi chiedi!

...mia madre ,mi diceva di studiare......

anche mio padre... il bello è che ho studiato ma cose poco utili nella realtà manuale

Bello il Valerio in versione "amarcord".... ma poi, hai studiato ??

no.....purtroppo a9 anni mi hanno messo in collegio,ero una peste,a 13 ho cominciato a lavorare,devo solo dire che provo un po' di chiamiamola invidia,quando vedo sti lavori di elettronica ,e la capacita di farli funzionare,ma non si puo' avere tutto magari tu max provi la stessa cosa quando vedi un muratore rabboccare un muro

senza andare tropo lontano Valerio.... anche quando vedo certi lavori di meccanica su questo forum

k

che bel lavoro ragazzi... mi son appena recuperato un tornio BV20 vorrei cnceggarci la vite madre, domanda perchè avete scelto di usare un NEMA 24 invece che un motore DC e 2 encoder? uno per la vite e uno per il mandrino?

l'utilizzo di un motore stepper ti semplifica notevolmente la vita. Il motore DC con encoder sarebbe comunque troppo difficile da controllare ed andrebbe demoltiplicato, cosa invece non necessaria con un motore stepper. Non ultimo, la gestione di due encoder da parte del micro sarebbe complicata visto e considerato che girerebbero insieme e non potresti permetterti di perdere nessun passo.
Lo stepper non ha retroazione quindi il controllo è diretto ed il micro non si deve preoccupare di controllare cosa fa il motore; certo lo stepper potrebbe perdere il passo ma se dimensionato correttamente questo non avviene.

Hai perfettamente ragione ma lo stepper ha intrinsecamente un funzionamento a scatti, mentre studiando bene il controllo un DC in lavorazione potrebbe lavorare in maniera più 'fluida'.
Alla fine per la gestione dei 2 encoder basta non esagerare con le precisioni, per il mandrino direi che 400 passi giro bastano e avanzano a 1000 rpm son interrupt a 7khz.
Lato vite sempre tenendo una precisione di 400 passi al giro la freq è nettamente più bassa diciamo un decimo...
Alla fine se gli si fan fare tutti i conti al mega e il display + interfaccia la faccio fare ad un nano connesso spi la cosa può stare in piedi secondo me.

Boh poi banalmente di DC motor ed encoder ne ho la casa piena recuperati da varie stampanti, mentre un NEMA lo devo comprare...

Faccio due conti e due disegni.... solo una cosa: sapete quanta coppia ci vuole su una madrevite? così calcolo quanto grosso stamparmi l'ingranaggio per il motore.

Grazie
Ciao