MECCANICA e DINTORNI

Riprendo la discussione avviata da Robyt qua:
viewtopic.php?f=16&t=29866&start=105

La questione puo' meritare di essere approfondita perche' spesso capita (almeno a me, spero di non essere l'unico) di avere comportamenti strani del programma a causa di overflow di variabili.
Questo il programma di robyt:


dove si vede come una stessa operazione da' due risultati diversi.
Quello che manca nel ragionamento e' che tra il programma scritto in C e il codice macchina c'e' il compilatore che ha un suo modo di ragionare (capire questo, per me autodidatta, e' stata una rivelazione).
Per capire cosa fa realmente il programma scritto (visto che passa per l'interpretazione del compilatore) sarebbe da vedere il codice assembly che pero' e' abbastanza ostico.
Se si attiva gli avvisi del compilatore (dall'ide di arduino, file-impostazioni, attivare la spunta su compilatore e caricamento alla voce "mostra un output dettagliato durante:" e scegliere tutti alla voce "warning del compilatore".
In questo modo si avranno anche gli avvisi dati dal compilatore.
Nel caso specifico, il compilatore ci avvisera' con due warning:


Visto che si sta lavorando con costanti, il compilatore ha gioco facile e si rende conto che c'e' qualcosa che non va.
Nel primo warning avvisa che un long verra' troncato in un int.
Nel secondo caso avvisa che c'e' un overflow nella conversione implicita di una costante.
E' interessante vedere cosa fa il compilatore guardando il codice assembly (in questo caso molto semplice):


Il resto nel pomeriggio

Interessante, non avevo mai provato a ottenere l'output dettagliato durante la compilazione e credo che potrà rivelarsi utile.
Ma come si ottiene il codice Assembly ?
Ho provato a esportare lo sketch compilato ma l'unico file leggibile che ho trovato è un listato esadecimale.

Per ottenere il file assembly puoi usare questo programma:
https://sourceforge.net/projects/arduin ... converter/
Compili il tuo programma dall'ide di arduino, vai a recuperare il file .elf (se hai attivato la visualizzazione dei messaggi del compilatore, ti mostra anche dove ha salvato il programma compilato, se usi windows >7 solitamente e' in users\nomeutente\appdata\local\temp\arduinoqualcosa), lo carichi nel programma di conversione e lui esce con un file di testo contenente le istruzioni in c e subito sotto il codice assembly.

Poi da questo link: http://ww1.microchip.com/downloads/en/d ... manual.pdf scarichi il set di istruzioni assembly per gli avr (tra i quali c'e' l'atmega328 che usa arduino uno).
Nel codice assembly vedrai un sacco di roba strana oltre al tuo programma. Se provi a compilare uno sketch vuoto vedi tutto quello che carica a tua insaputa (se vai a leggere il thread viewtopic.php?f=16&t=29864 dove parlo del mio programma per l'els, vedrai che mi trovavo dei problemi legati a questo discorso).

Tornando al tuo sketch di prova, vedi dal codice assembly, cosa succede.
Il compilatore (o il preprocessore) vede che stai usando delle costanti quindi non fa fare i conti al processore ma se le calcola gia' lui.
E ottimizza anche l'uso dei registri. Infatti, per il primo calcolo (A=65534+2) che dara' come risultato sempre 0, usa il registro R1 che contiene gia' il valore 0. Semplicemente scrive all'indirizzo di memoria 0x0161 e 0x0160 (essendo un int da 16bit ha bisogno di due blocchi da 8bit) il valore che c'e' nel registro R1.

Per il secondo calcolo, quello col casting, non so che ragionamento faccia ma carica in due registri il valore 0xFF e poi li salva nei due indirizzi di memoria assegnati alla variabile A.

Ho provato a convertire il codice e dare un'occhiata all'assembly ma è fuori dalla mia portata. Mi sono reso conto che dovrei rimettermi a studiare e sinceramente, alla mia età, preferisco usare il tempo per fare altro. Grazie comunque per le spiegazioni, qualcosa in più ho capito.
Ho letto anche la discussione che avevi aperto sul tuo programma per l'ELS e anche da li ho appreso qualcosa.
Continuerò a seguire le discussioni e in caso di bisogno farò qualche domanda. Grazie ancora.
(a proposito, hai completato il tuo programma ?)

Leggere il codice assembly e' abbastanza facile. Capire quello che fa molto meno, scriverlo e' abbastanza complicato. Io mi limito a cercare di intuire cosa sta facendo senza scendere troppo nei dettagli.

Il mio programma e' fatto e funzionante. Dovrei sistemare anch'io il debounce dei pulsanti ma per ora mi va bene cosi'.
Il limite adesso e' il motore passo passo, riesce a fare 1mt/min (tenendo un po' di margine e comunque con coppia sufficiente).
Quindi, riesco a filettare a 1000 rpm passo 1, a 300 passo 3 e a 100 passo 6.
Se me ricordo giusto avevo messo anche un video.

Continuo qua il discorso cominciato nell'altro thread.
Ho apportato un po' di modifiche al codice di McMax per poter fare passi filetto > del passo vite madre.
Ho fatto le modifiche basandomi sui parametri di Amarillis (per il massimo passo da filettare).
Dovrebbe funzionare ma non l'ho provato dal vero. Ho riunito tutto in un unico file perche' altrimenti mi incasinavo a saltare da un file all'altro.

Ora la serie di domande, McMax alla fine ti faro' una statua per la pazienza
Pur avendo capito cosa fa la funzione CreaSequenza, non ho ancora capito la logica del tutto.
Primo dubbio: perche' calcoli matched_pitch? Mi sembrava fosse per cadere con l'ultimo passo dello stepper al giro completo di mandrino ma, riguardando il codice, non mi pare sia cosi'.
Se puoi chiarirmi la logica che c'e' dietro mi faresti contento.

La funzione CreaSequenza che vedi oggi è il risultato di svariate modifiche fatte nel corso degli anni.
Lo scopo è quello ovviamente di riempire l'array di valori che indicano quanti passi mandrino attendere prima di fare un passo vite. Chiaramente il calcolo matematico prevede che esista un rapporto ben preciso tra passi mandrino e passi vite.
Nella prima versione mi ero imposto (sbagliando) di fissare una valore ed in particolare il numero di passi encoder per 1 giro del mandrino. Ovvero, mi imponevo di riempire l'array con un pattern che arrivava a fare un giro completo del mandrino (nel mio caso 1000 passi). Alla fine del calcolo addirittura contavo i passi mandrino ed aggiustavo l'ultima cella facendo in modo che il conto totale fosse appunto 1000, ovvero il mio giro completo. Questo oltre che essere inutile era sbagliato in quanto andavo ad inserire un errore che, per quanto infinitesimale e ininfluente ai fini del filetto, era per sempre un errore evitabile.
Dalle versioni successive ho cambiato approccio e ho reso variabili non solo i passi vite ma anche i passi mandrino, in questo modo è più facile trovare il rapporto ottimale e realizzare praticamente qualsiasi passo, partendo da qualsiasi vite, sia essa in pollici o in millimetri.
Nel realizzare questa modifica avevo pensato di scandire a RITROSO i passi mandrino alla ricerca del miglior rapporto ma, così facendo, andavo a creare un pattern che si, era più preciso che nelle versioni precedenti ma veniva ripetuto più e più volte all'interno dell'array inutilmente.
In quest'ultima versione la scansione del "mandrino" viene fatta partendo dall'inizio quindi il pattern si fermerà allo stretto indispensabile. Ad esempio, se imposto il passo massimo tornibile dovrò sempre attendere 1 passo mandrino per fare il passo vite, in questa nuova versione l'array verrà riempito con una sola cella contenente 1, nella vecchia versione al di la che non sarebbe stato possibile per via del limite di 800, l'array sarebbe stato riempito interamente di celle con valore 1. All'atto pratico non cambia nulla, il passo del filetto risultava comunque corretto ma la cosa a livello logico non aveva alcun senso.


Ho dato un'occhiata al tuo codice. Tu hai eliminato completamente la parte di ricerca del pattern migliore quindi di fatto vai a riempire l'array di 800 valori verificando con una condizione se si verifica la ripetizione del pattern. Purtroppo però la cosa non è così semplice perché il pattern non è necessariamente composto da un elenco regolare di valori.
Ti faccio un esempio (con la configurazione di amarillis che è l'ultima che ho simulato):
passi mandrino: 1440
passo vite: 1,5mm
passi stepper vite: 800
avanzamento vite per singolo passo: 0,001875mm (1,5/800)

Per eseguire un passo da 1mm con questa configurazione il rapporto tra passi vite e passi mandrino è di 1:2,7. La miglior combinazione che troviamo con la nuova CreaSeqeunza è di 10 passi vite ogni 27 passi mandrino, così distribuiti:
2 - 3 - 3 - 2 -3- 3 - 2 - 3 - 3 - 3
con la tua condizione tu ti fermeresti alla quarta cella ed il pattern risultante sarebbe 2 - 3 - 3, che equivale a 3 passi vite ogni 8 passi mandrino, per un rapporto di 2,66 che si, non è molto diverso da 2,7 ma inserirà un errore nel filetto di circa 1 centesimo al giro. Per carità non è nulla di incredibile ma se vogliamo fare le cose per bene l'utilizzo della condizione non è la soluzione ottimale.

Matched_pitch è il passo della vite che dobbiamo tornire ridotto sulla base del giro parziale di mandrino che andremo a fare (matched_mandrel_steps).
Per farti un esempio non realizzabile nell'algoritmo ma che dovrebbe aiutarti a capire. Se devo eseguire un passo da 1mm e per i calcoli mi rendo conto che il miglior rapporto ce l'ho con esattamente 1/2 giro del mandrino, matched_pitch sarà 0,5mm.... cioè 1mm per ogni giro vuol dire 0,5mm per 1/2 giro.... oppure 0,25mm per 1/4 di giro e così via.

McMax, ti ringrazio per la spiegazione, finalmente ho capito a cosa serve matched_pitch.
Avevo completamente travisato la sua funzione, avevo capito che andavi a cercare il passo piu' "comodo" per fare i conti e che andavi a tornire quel passo (e li' mi ero bloccato perche' ottenevo valori assurdi di matched_pitch). Ora tutto chiaro e ha una logica.

La modifica l'avevo fatta per Amarillis, conscio di aver introdotto un errore ma era l'unica soluzione che avevo trovato senza dover riscrivere tutto (se avessi saputo che ci mettevi poco a rilasciare una nuova release non mi ci sarei messo ).