MECCANICA e DINTORNI

Si chiama "ricerca e sviluppo" al paese mio che non è manco troppo lontano dal tuo

Mimoletti, anche a me ci sono parecchie cose che sfuggono; ma una su tutte, sarò ripetitivo, è il tuo codice..... codice privo di errori, funzionale, che filetta viti da due metri senza errori e che non perde un colpo nemmeno con encoder da un trilione di passi ma che, al solito, hai visto solo tu.

I vantaggi della mia soluzione li ho già spiegati... non mi diverto a reinventare l'acqua calda ma semplicemente reputo che la tua soluzine (così come quella del russo da cui l'hai copiata) abbia delle criticità. Ho già ampiamente spiegato quali sono ma come si dice non c'è peggior sordo di chi non vuol sentire quindi, come già fatto in passato, ti invito a leggere il mio codice e capire come funziona. Fatto questo sarò felice di commentarlo con te.

Vedere il mio codice non ti serve a nulla, dal russo ho copiato 3 righe di codice, nient'altro, sviluppando il programma in modo del tutto indifferente. Come ti è stato spiegato il mio progetto è stato realizzato da diversi utenti di questo forum e funziona perfettamente e non capisco come tu possa ancora metterlo in dubbio.

Quando lo realizzato mi sono posto alcuni obbiettivi:

1) Evitare il tipico movimento a scatti del motore passo passo quando gira a basse velocità, sopratutto durante gli avanzamenti, da qui nasce l'esigenza di utilizzare il micropasso e una riduzione meccanica.
Ovviamente il rapporto di divisione non potendo essere inferiore ad 1 la risoluzione dell'encoder deve essere adeguata alla risoluzione del motore.
Nel mio caso ho adottato una risoluzione di 6400 passi per ogni giro della madre vite.
Ma volendosi accontentare di un funzionamento a scatti e meno fluido si possono scegliere anche valori più bassi. Ai fini del funzionamento non cambia nulla.

2) Renderlo estremamente affidabile. Pertanto anziché leggere ogni singolo fronte di salita in tempo reale (come faceva il russo) ho utilizzato il timer del PIC. Pertanto l'interrupt si genera su l'overflow del timer e non continuamente, quindi in generale il compito di leggere il numero di impulsi non è affidato alla CPU del micro.

Ho deciso di non pubblicare il codice sorgente, ma ho programmato e spedito gratuitamente a quanti me l'hanno richiesto il pic.

Avere la vite madre in pollici o metrica non fa differenza ai fini della precisione, in ogni caso non potrai avere mai tutti i valori di divisione interi. Ma questo comporta una imprecisione se il codice è strutturato correttamente trascurabile.

Se non si fosse capito, mi sembrava di averlo scritto, faccio in questo modo:

Immaginiamo che il valore di divisione sia di 2,5 carico nel timer valore 253, 256 - Div1, dopo tre impulsi si genera in interrupt su l'overflow, quindi verifico il senso di rotazione del mandrino e lo aggiorno, genero un impulso di step, carico in una variabile (esempio pippo) il valore frazionario di 500, se il valore della variabile pippo ( a cui sommo continuamente il valore frazionario) è uguale o superiore a a 10000 decremento il valore che carico nel timer di 1. TMR0 = 256 - Div1 - 1
Facendo in questo modo ottengo essenzialmente due cose, l'interruzione avviene con una frequenza che è direttamente proporzionale al valore di divisione, e ciclicamente quando il valore di divisione è come nell'esempio di 2,5 divido per 2 e poi per 3 e cosi via.

Spero di essere stato chiaro.

sei stato chiarissimo, e lo eri già stato anche la scorsa volta. Solo non capisco come gestisci un'inversione improvvisa del mandrino: se mentre il timer vale, ad esempio, 254, il mandrino cambia verso di rotazione, come ritorni indietro sui tuoi passi senza perdere il sincronismo ?
I canali del tuo encoder passano in una XOR, quindi la direzione non è immediatamente rilevabile dal timer che, a prescindere dal verso, incrementerà il contatore.


Uguale o superiore a 1000.... spero....
E la parte eccedente 1000 la sommi al valore frazionario successivo, immagino.....

Solo non capisco come gestisci un'inversione improvvisa del mandrino: se mentre il timer vale, ad esempio, 254, il mandrino cambia verso di rotazione, come ritorni indietro sui tuoi passi senza perdere il sincronismo ?

E' come il gioco di inversione di una chiocciola, lo riprendi all'inversione successiva. Non mi serve decrementare il timer, gli impulsi perduti, vengono recuperati all'inversione successiva.

I canali del tuo encoder passano in una XOR, quindi la direzione non è immediatamente rilevabile dal timer che, a prescindere dal verso, incrementerà il contatore.

L'uscita del Flip Flop cambia immediatamente, ad ogni inversione. Come ti ho spiegato sopra, non è necessario decrementare il timer, l'importante è aggiornare il valore del Dir all'interno della routine di interruzione e prima di generare l'impulso di Step.

Uguale o superiore a 1000.... spero....

Avevo scritto bene uguale o superiore a 10000, avrei dovuto scrivere 5000 e non 500, nel mio programma la parte frazionaria è di 4 cifre.

no che non è come il gioco d'inversione di una chiocciola. Il gioco di una chiocciola ha un valore fisso che dipende dall'usura; qui il valore è casuale e dipende da quando inverti.

Poniamo il caso che il valore caricato nel timer sia 200. Arrivato a 210 il mandrino si inverte ma tu continuerai a contare i restanti 45 impulsi prima di dare l'impulso di step nella direzione opposta. All'inversione successiva poniamo che il mandrino si inverte quanto il timer è a 220; qui conterai solo 35 impulsi prima di dare lo step nella direzione opposta: il sincronismo è perso.

Il tuo sistema funziona se filetti senza invertire il mandrino. Se continui ad invertire perdi passi e pure parecchi.

Altra limitazione è quella della precisione della parte decimale. Tu utilizzi 4 cifre per stare in un intero da due byte. Io eseguo il calcolo fuori dal ciclo e grazie a questo posso usare variabili float che ti garantiscono 7 decimali di precisone.

Non credevo di aver realizzato nulla di cosi difficile comprensione!

Poniamo il caso che il valore caricato nel timer sia 200. Arrivato a 210 il mandrino si inverte ma tu continuerai a contare i restanti 45 impulsi prima di dare l'impulso di step nella direzione opposta. All'inversione successiva poniamo che il mandrino si inverte quanto il timer è a 220; qui conterai solo 35 impulsi prima di dare lo step nella direzione opposta: il sincronismo è perso.

Ma il fatto che sia stato collaudato in diversi esemplari, non instilla in te nessun dubbio???

Appena ho tempo vedo di realizzare con solidworks (se ci riesco, essendo alle prime armi) una simulazione.

Il tuo sistema funziona se filetti senza invertire il mandrino. Se continui ad invertire perdi passi e pure parecchi.

E' l'esatto contrario, infatti nella prima versione di SW che ho rilasciato c'è una perdita di sincronismo quando va in pausa e viene invertito il senso di direzione del mandrino, problema risolto con la versione di SW successivo.

Altra limitazione è quella della precisione della parte decimale. Tu utilizzi 4 cifre per stare in un intero da due byte. Io eseguo il calcolo fuori dal ciclo e grazie a questo posso usare variabili float che ti garantiscono 7 decimali di precisone.

Aumentare la precisione del calcolo è inutile, avrai alla fine del tuo ciclo di divisione un'errore uguale alla risoluzione da te scelta.
Immaginiamo di inviare 65000 impulsi in ingresso al tuo o al mio sistema, con un valore di divisione di 2,67 in uscita potrai avere o 24344 o 24345 impulsi e mai in ogni caso esattamente 24344,569 step.
In ogni caso anche con risoluzioni più basse cambia poco, ad esempio con una risoluzione motore di 1000 avresti un errore di 4 millesimi, con una vite madre di 4mm.
Quindi del tutto trascurabile. Io ho utilizzato una risoluzione elevato, solo perchè mi infastidiva il rumore del passo, soprattutto alle basse velocità, ma questo è soggettivo. Ma ai fini del funzionamento scegliere una risoluzione di 1000 o 5000 cambia poco.
L'errore in ogni caso è trascurabile.

Collaudato come ? Certo se filetti senza mai invertire il mandrino funziona (anche se non hai spiegato come riprendi il sincronismo angolare.....).
Se inverti il mandrino, a meno che tu non lo inverta con cognizione di causa (cosa direi impossibile), perdi i passi.
Questo è a prescindere perché è MATEMATICA. Se poi vogliamo metterci a discutere di quella va bene.... ma resta pur sempre MATEMATICA, non un'opinione.
Con questo non sto dicendo che non funziona o non è utilizzabile. Le filettatura avendo un ELS le fai senza invertire il mandrino quindi ha perfettamente senso che questa opzione non venga contemplata e tu, nel modo in cui esegui il ciclo, non l'hai contemplata.

Sopra ti ho fatto un esempio e tu semplicemente dici che è stato testato e funziona... perché invece non mi spieghi come hai risolto il problema, visto che esiste?

Mi stai facendo rivalutare il mio progetto, non credevo di aver realizzato l'impossibile!!

Nella prima versione di SW avevo la possibilità di filettare solo nel modo tradizionale, invertendo il senso di rotazione del mandrino. Come se il tornio fosse dotato di cambio norton.

Ma forse mi stai prendendo in giro?

il fatto che sul filetto si avvita un dado non significa aver eseguito una filettatura perfetta, per cui si puo' dire che il progetto funziona in maniera pratica e sufficiente all'uso che ne faremo

perdendo (virtualmente) qualche step dell'encoder ad inversione e quindi perdendo in minima parte il sincronismo angolare si ha che l'utensile ricalchera' la filettaura un pelo + avanti o un pelo + indietro, probabilmente di valori assolutamente trascurabili, ma non in maniera perfetta

non entro nel merito dei calcoli perchè gia' vi state applicando voi abbastanza

detto questo, la cosa funziona?
certo che si, come ho detto prima se il parametro per determinare il funzionamento del sistema è quello di poter avvitare sulla filettatura un dado di pari passo, il sistema è perfettamente funzionante


se invece con "funziona" si intende avere una filettatura che passerebbe un collaudo in stazione metrologica... beh, credo che la cosa cambierebbe alquanto

detto questo non riesco a capire l'appporto pratico alla discussione

in pratica si sta "criticando" il lavoro senza fornire di fatto alternative e senza realmente confrontarsi perchè fino ad ora solo uno di voi ha pubblicato integralmente il lavoro svolto

se il tutto sta "degenerando" in una sfida fra programmi, nemmeno questa avrebbe soddisfazione per il semplice fatto che allo stato dei fatti non si possono valutare i due algoritmi


quindi, ribadendo il concetto che per il nostro uso "basta che si avvita", il risultato è stato raggiunto da tutti e due

ricordando che l'essenza stessa del forum è la condivisione...

un saluto
Luca

Sempre grazie, fratello . . . .

Ciao Luca,

mi dispiace dirlo ma spari solo caxxate.
Se rileggi i mie post precedenti non mi sono limitato a criticare il suo lavoro, ma gli ho proposto delle valide alternative.
Ma ogni volta, mi rispondeva che erano alternative impossibili da applicare, nonostante gli facevo notare che il mio progetto era stato ampiamente collaudato.

E bada bene che quando dico collaudato intendo, aver verificato la filettatura eseguita, con gli appositi tamponi.
Ti posso assicurare che ti basta la perdita di pochi passi per notare due solchi sovrapposti, che indicano inesorabilmente, la perdita del sincronismo.

Nel l'immagine e rappresentato quello che succede, immaginando che l'encoder generi 3 impulsi a destra e 2 a sinistra e che il valore di divisione sia di 5, nonostante l'interruzione si verifica sempre a sinistra il dir sara alto poi basso e cosi via, e quindi il motore farà un passo a destra e un passo a sinistra senza mai perdere il sincronismo.

per prima cosa ti invito a moderare i termini: nonostante la pazienza l'abbia persa tante volte non mi sono mai permesso (e Luca tanto meno) di insultarti. Di "caxxate" ne ho viste scritte tante e ancora ne continuo a vedere ma c'è modo e modo di rispondere.

Ciò detto, torno a bomba sull'argomento per dirti che il tuo schema non è chiaro. I diagrammi che hai postato non sono etichettati e non si capisce come mai il segnale "DIR" risulti perfettamente simmetrico quando invece non dovrebbe esserlo visto che gli impulsi non lo sono: l'hai scritto tu, 3 a destra e 2 a sinistra.... e lo hai detto tu, il cambio di polarità sul flip-flop agisce sul "DIR" quindi, per logica, il "DIR" dovrebbe alternarsi tra 3 impulsi e 2... invece ne ha sempre 2.
E il segnale rosso cos'è ?

Se ti prendo in giro?
Direi proprio di no.... ma non posso fare a meno di notare una strana coincidenza: stavo pensando la stessa cosa!

Essere accusati di aver criticato senza aver proposto delle alternative, cos'altro può essere se non insulto?
Un conto è essere o non essere d'accordo sul modo con cui si è risolto un problema, altra cosa è inventarsi le cose!

Ritornando all'immagine allegata, i primi due segnali sono il canale A e B, il secondo segnale è la somma (forse non è esatto definirlo come tale) dei due all'uscita della porta logica.
Il dir è simmetrico perché io lo aggiorno solo durante l'interruzione, in questo caso l'interruzione si ha sempre quando il mandrino sta ruotando in senso antiorario.