MECCANICA e DINTORNI

Scusa McMax non ho capito se io imposto avanzamento per esempio 1.25 mm a giro , la vite si muovera sempre a quella velocita io il sincronismo lo prendo con le tacchette di sincronismo agganciate alla chiocciola .

mimoletti per il microcontrollore (quindi dal suo punto di vista) un interrupt è un evento randomico ed è corretto quello che dice Max, ti faccio un esempio così capisci. Hai in input un sensore che registra la luce emessa dai fulmini durante i temporali...sono eventi non prevedibili e il micro non sa quando accadrà e nessuno in realtà può saperlo...
Solo quando hai una funzione continua nel tempo, per esempio generata dall'encoder del motore (ed in questo caso il primo fronte di salita per il micro è random, dipende da quando tu lo azioni) o da un oscillatore, può prevederla, ma è un caso, non una regola...

Le estrazioni del lotto invece non lo sono assolutamente, infatti si sa perfettamente quando le fanno, il numero che uscirà invece è randomico e non prevedibile
(scherzo ho capito quello che intendevi ;-))

Grazie Umbez... a volte mi sento un po' come Don Chisciotte

mimoletti:"anche nel tuo, retrocedi in modo asincrono, quando filetti a misura?"
certo... come potrei retrocedere in modo sincrono se il mandrino sta sempre girando ma nel frattempo lo stepper si é fermato ?

Mario la ruota di sincronismo sulla chiocciola continuerà a funzionare normalmente....

Comunque, per rispondere alla tua prima domanda: no, non puoi usare l'avanzamento per filettare.

Ok, adesso mi e' molto piu' chiaro e condivido quello che dici.
Son testone e se una cosa non la capisco, non mi convince.

Se il programma funziona cosi' com'e' non credo di modificarlo. Ma stai certo che nei prossimi programmi cerchero' di seguire le buone norme di programmazione.

Adesso resta solo il responso del tornio, vediamo se dopo mille discussioni teoriche il programma fa cilecca

Umbez e Max:

Assolutamente errato, la la fonte di un interrupt non è un evento Random a prescindere. Dipende dalla fonte.
In un temporale non potremo mai in nessun caso, prevedere il tempo che intercorrerà tra un fulmine e quello successivo.
Ma nel caso dell'encoder lo puoi sapere con precisione assoluta, dipende dalla velocità di rotazione e dal numero di impulsi a giro.

Con poche righe di codice, potremmo calcolare, prima di avviare la filettatura, tranquillamente l'intervallo tra un interruzione quella successiva, in quel preciso instante. Misurando semplicemente la velocità di rotazione del mandrino.
Se l’evento che genera l’interruzione fosse random come asserite, non sarebbe possibile prevederlo in nessun modo, come nelle esempio dei fulmini.

Ora spiegami argomentando in modo serio, ovviamente con esempi pertinenti, perché consideri il segnale prodotto dall’encoder e di tipo random.

Il micro non è un essere pensante, ma un hardware che esegue una serie di istruzioni. Non ha un suo punto di vista.

È la fonte che eventualmente sarà di tipo random oppure ricorrente.
Ora se la vostra tesi fosse corretta evidentemente, sono stato fortunato perché il mio Pic ha un punto di vista, diverso da quello montato su Arduino.

mimoletti scusa ma tu che lavoro fai ?
Parli come un professore di informatica e sistemi...
"assolutamente errato". Ma per piacere!

Qualsiasi evento che arriva dall'esterno è random. Un clock in ingresso al micro è random perchè non è il micro a controllarlo.
Tutto quello che il micro genera non lo è. E infatti la generazione di numeri random è una delle cose più complesse per un processore al punto che, sui sistemi di crittografia dove la generazione di numeri random è importante, c'è un hardware dedicato , esterno al micro, che li genera. Pensa te....
Si chiama RNG (Random Number Generator), se ti interessa imparare qualcosa.....

concordo con Max, non solo: l impulso encoder deve essere reputato random perché per motivi diversi la velocitá del mandrino puó cambiare: sbalzi della tensione di rete, materiale da filettare non omogeneo che induce oscillazioni nella velocitá del mandrino, scheggiatura utensile, etc...

La stessa attivitá di filettatura non é a carico costante sull' utensile tra una passata e l'altra e sui tornietti hobby dubito abbiate controllo velocitá mandrino retroattivo.

Personalmente concordo a trattarlo come evento random. Tratterei in modo diveroso un input di un quarzo o un oscillatore di altro genere che ha precisione maggiore del clock interno dell arduino stesso.

mimoletti, leggi bene quello che ho scritto, e scoprirai che ho detto quello che dici tu, magari hai letto di fretta.
il progetto ELS è un "caso specifico" ma chi ha progettato l'atmega o il pic non lo ha fatto basandosi su casi specifici, ma su un problema generico, ovvero scatenare un interrupt ad un evento esterno (qualsiasi esso sia, random o ridondante), quindi <<in generale>> dal punto di vista di qualsiasi processore che implementa questa tecnica, un interrupt avviene in un momento "RANDOM".
Nel <<caso specifico>> puoi ovviamente prevederlo, perchè il mandrino del tornio gira sempre alla stessa velocità, questa rotazione viene convertita da un encoder, che genera un'onda quadra a frequenza fissa <<continua nel tempo>>.
Quindi hai ragione? SI nel caso specifico.
Max ha ragione? SI nel caso generale, e non c'è bisogno che aggiunga altro.
Io sono in linea con Max, perchè professionalmente programmo dal punto di vista GENERALE, poi all'occorrenza specifico se non posso fare di meglio.
Tu sbagli nel considerare il caso specifico? Probabilmente in questo caso no, ma solo l'esperienza potrà dirti perchè un progettista parte dal punto di vista Generale e cerca in tutti i modi di rimanerci (leggi scalabilità del software).
Fine e non aggiungo altro, perchè è una discussione "sterile".
miei 2 cent ovviamente ;-)

McMax, non te la prendere ma ti faccio una critica.
A Mimoletti ti rivolgi sempre con toni caustici (almeno cosi' traspare da quello che leggo). Mimoletti potra' anche dire castronerie e non retrocedere di una virgola ma tu non sei tanto distante.
Ti cito: " In questi casi la routine è asimmetrica e potrà durare di più o di meno. Questo è un altro problema: per sapere se riesco a eseguire una routine senza andare in nesting devo sapere esattamente quanto dura, non posso fare una media; posso eventualmente utilizzare il caso peggiore e usare quello come limite, ma capite bene che non è per nulla efficiente e, in ogni caso, più soggetto a problemi di instabilità.".
Io ti ho fatto notare (dimostrandolo) che la tua routine di interrupt dura quasi 4 volte quello che pensavi tu e mi rispondi:
"certo sono stato un po' ottimista su alcune operazioni ma con 3.5usec direi che ho comunque un buon margine rispetto ai limiti che ho imposto. Parliamo pur sempre di una routine in grado di intercettare passi a 285Khz, non mi pare faccia poi così schifo."
Le due cose che scrivi sono una il contrario dell'altra.
Non sei stato ottimista nel calcolo della velocita', hai sbagliato proprio concetto (e se ci sono arrivato io ad intuito ci poteva arrivare chiunque).
Entrambi (tu e mimoletti) vi scornate ma nessuno dei due torna sui propri passi.
E su questo capitolo io me ne tiro fuori, sta diventando una gara a chi ce l'ha piu' lungo. Non e' una competizione a cui mi interessa partecipare.

La gara a chi ce l'ha più lungo la vedete solo voi, io vedo solo uno scambio di informazioni

Matteo:"A Mimoletti ti rivolgi sempre con toni caustici"
Si hai perfettamente ragione. Come sai (e come visibile in questo stesso threrad) con mimoletti ho già parlato a lungo di questo progetto in passato e quindi ho dei preconcetti che non posso esimermi dal considerare quando leggo una sua risposta. Purtroppo son fatto così, mi rendo conto che a volte lo faccio in modo gratuito, come l'altra sera dove l'ho attaccato perchè avevo sbagliato a leggere una sua risposta e per la quale mi sono scusato, ma non posso farci nulla.
Del resto i suoi toni non sono molto diversi.
Cito, e in questo caso rivolto non solo a me che anche a Umbez che giustamente ha puntualizzato:
"Umbez e Max: Assolutamente errato, la la fonte di un interrupt non è un evento Random a prescindere. Dipende dalla fonte."

Questa, perdonami, è una BESTIALITA'!
La "randomicità" dell'evento E' A PRESCINDERE!
La conferma di questa affermazioone sta intrinsecamente nel modo in cui stiamo trattando l'evento (che sia un clock ultra stabile, un encoder, un tasto, la variazione di un valore analogico, ecc). Mi spiego. Perchè ho bisogno di un interrrupt per leggerlo ? Se fosse un evento prevedibile che bisogno ci sarebbe di usare un interrupt ?
mimoletti sta dicendo che, nel momento in cui si intercetta il primo fronte dall'encoder (e questo mi auguri sia random anche per lui ), è possibile ricavare gli altri perchè conosciamo la velocità di rotazione del mandrino. Altra bestialità sulla quale non voglio tornare perchè ha già detto tutto in due parole Eugenio che, oltre che aver studiato più di me, ha anche il dono della sintesi che io non ho.

Circa la durata della routine di interrupt, se leggi bene, a parte la durata, io ti ho menzionato il fatto che la tua è asimmetrica (per via delle condizioni e dei calcoli condizionali). Di questo stavo parlando nella parte che tu hai citato.
Sulla durata certo, ho sbagliato a calcolare, ma a questo punto fossi in te mi domanderei: ma se quella di Max che ha 4 istruzioni in croce e nessuna condizione dura 3.5us, la mia quanto dura ? E soprattutto, la mia dura sempre 3.5us.... e la tua?

Come ho sempre detto, e' difficile capire le persone con uno schermo nel mezzo.
Ma quando si alzano i toni (anche per via di fraintendimenti che faccia a faccia non ci sarebbero), la discussione va sul personale e diventa sterile.

Io mi son chiesto quanto dura la mia routine di interrupt (conscio del fatto che e' concettualmente sbagliata) e ho fatto delle misure (sbagliate perche' pensavo che millis fosse preciso).
Ho corretto il tiro, probabilmente sbagliando ancora. Forse, usando un timer per contare i cicli di clock dovrei riuscire ad avere una misura piu' accurata (potrei dissassemblare la mia routine di interrupt ma e' troppo lunga e sicuramente mi perdo).
Io non ho convinzioni, sono conscio che il mio codice e' scritto male (per mie deficienze) e son pronto a cambiarlo piu' volte finche' non funziona, questo l'ho sempre detto. Per fortuna non lo faccio per lavoro, quindi ho tutto il tempo per sperimentare
Questa cosa concedimela e apprezzala (dammi una soddisfazione ogni tanto ).

Infine, come gia' detto, io sono praticone. Il fine ultimo e' far funzionare il tutto meglio possibile.
Se il tuo riesce a filettare a 1000 giri un passo 3 e il mio (a parita' di condizioni) riesce a filettare solo fino a 300, vuol dire che il tuo lavora meglio del mio (mio e tuo e' inteso in generale. In senso stretto il mio programma ha girato solo sul banco, magari messo sul tornio esplode tutto).
Una volta stabilito questo, andro' a ritroso per vedere perche' il mio programma non riesce a fare quello che fa il tuo. Lo so, ragiono al contrario ma son fatto cosi'.

Una cosa non mi e' chiara: perche' non posso prendere il caso peggiore come tempo di esecuzione dell'interrupt? Se e' un discorso generale mi e' chiaro. Nel caso specifico non la vedo una bestialita' cosi' estrema.

Per quanto riguarda la randomicita' non mi esprimo, e' stato gia' detto tutto e non posso che essere d'accordo. Spero che Mimoletti si sia espresso male e intedesse qualcos'altro.
Quello che dici (intercettare il primo impulso e ricostruire gli altri) e' stato applicato in un programma che avevo trovato, sempre per l'els.
Se ricordo/ho capito giusto, lo stepper era pilotato senza leggere l'encoder costantemente come facciamo noi. L'encoder veniva letto solo sotto una certa velocita' (50rpm o li' in giro), oltre presumeva che direzione e velocita' restassero invariate.
Appena capito questo, non ho perso tempo a studiare il resto del programma perche' mi sembrava inutile.

matteou nello studio asintotico degli algoritmi si prende sempre O(n) = caso peggiore, non omega(n)=caso migliore, ne tetha(n) =caso medio. Quindi si è corretto considerare il caso peggiore, sempre. Detto questo per me (e sottolineo per me), nelle routine di interrupt, va sempre utilizzato lo stretto necessario, su qualsiasi tipo di processore, che sia il PC (dove lavoro abitualmente) sia su altri tipi di processori.
Ora per chiudere l'argomento ti invito a leggerlo su : https://www.arduino.cc/reference/en/lan ... interrupt/
Sito del produttore della scheda :
《Generally, an ISR should be as short and fast as possible. If your sketch uses multiple ISRs, only one can run at a time, other interrupts will be executed after the current one finishes in an order that depends on the priority they have. millis() relies on interrupts to count, so it will never increment inside an ISR.》

Matteo: "perche' non posso prendere il caso peggiore come tempo di esecuzione dell'interrupt? Se e' un discorso generale mi e' chiaro. Nel caso specifico non la vedo una bestialita' cosi' estrema."

McMax: "...per sapere se riesco a eseguire una routine senza andare in nesting devo sapere esattamente quanto dura, non posso fare una media; posso eventualmente utilizzare il caso peggiore e usare quello come limite, ma capite bene che non è per nulla efficiente e, in ogni caso, più soggetto a problemi di instabilità."
Mi sono citato da solo

Non ti ho mai detto che non puoi usare il caso peggiore. Quello che ho detto è che, essendo che le routine di interrupt devono essere ridotte al minimo indispensabile, ritengo inefficiente limitare il sistema considerando il caso peggiore. I problemi di instabilità a cui mi riferisco sono eventuali chiamate in nesting che possono verificarsi solo in determinate condizioni ma non in altre visto che, avendo la routine una durata diversa da momento a momento, si può verificare un nesting random di molto difficile individuazione.... e chiaramente tutta roba runtime che al momento della compilazione non ti da nessun errore...

Mi vorrei anche ripetere però sul concetto chiave di tutta questa discussione:
il micro mentre filetta esegue 2 task.
1 - legge l'encoder
2 - genera il passo stepper (a seguito di un calcolo basato sui passi encoder)
La parte più problematica del task n.2 è sicuramente il calcolo, perchè in realtà se usi il mio metodo con il timer il passo stepper non è bloccante quindi si tratta di un'istruzione che carica nel timer un valore a 16 bit... saranno da 2 a 4 cicli di clock, così ad occhio....

Che senso ha far eseguire entrambi questi task alla routine di interrupt ?
Cosa farai fare al codice principale mentre aspetti che l'interrupt venga generato? In pratica resterai in un loop sterile che non fa nulla tra una chiamata all'ISR e l'altra... a parte forse il controllo sulla misura del filetto per fermare tutto quando arrivi a fine passata, sempre che tu voglia implementare questa funzione.

Matteo"Questa cosa concedimela e apprezzala (dammi una soddisfazione ogni tanto )."
Ma che scherzi! Io apprezzo la passione che ci metti e ben venga chi come te si prende la briga di discernere il mio codice per capire come funziona. Di certo molto meglio rispetto ad altri che si limitano a criticarlo senza mai nemmeno averlo guardato.