progetto open source per avanzamenti automatici su arduino

[mimoletti]

No in filettatura è più che sufficiente, in modalità avanzamento potresti avere dei problemi, quando ho provato il progetto del russo, oltre i mille giri smetteva di funzionare correttamente.

[McMax]

La mia modalità avanzamento è libera, nel senso che imposti l'avanzamento in mm/min e il movimento del carro è svincolato dal mandrino.
C'è un'altra funzione dove ho provato a impostare l'avanzamento in cent/giro ed in quel caso uso un solo interrupt sul fronte di salita quindi leggo 250 passi/giro al posto di 1000 che per un avanzamento sono più che sufficienti; ma ha senso solo se riesco a visualizzare la posizione progressivamente altrimenti tanto vale.... solo che se faccio aggiornare il display non ci sto dietro quindi ho deciso di mantenere quella in mm/min "libera".

Comunque se organizzi bene il codice con gli interrupt ce la fai; certo, se avessi avuto la QEI sarebbe stato tutto più semplice!
Il problema di usare un PIC è che non ci sono board pronte e ti devi fare il PCB, io ho pensato ad un progetto semplice da assemblare anche per chi ha poca dimestichezza con l'elettronica

[mimoletti]

Le mie non sono delle critiche ma solo delle osservazioni. Hai fatto un'ottimo lavoro.

[McMax]

non ho mai pensato che lo fossero, figurati. E comunque sono pronto ad accettare anche quelle, quando sono costruttive aiutano a migliorarsi

[mimoletti]

Io volevo la sincronizzazione anche in modalità avanzamento, avere l'avanzamento in mm/min non mi piaceva, nella prima versione ho fatto in questo modo:

Ho utilizzato un flip-flop per stabilire il senso di rotazione del mandrino, una porta xor per raddoppiare la risoluzione dell'encoder, ed il timer0 per contare gli impulsi. In questo modo anche ad elevati reggimi di rotazione non perdo mai il sincronismo.

Nella seconda versione ho utilizzato un Pic con QUEI, semplificando ulteriormente il circuito.

In entrambi i casi l'interruzione viene generata solo quando deve essere generato l'impulso di step.

Inoltre ho previsto la possibilità nella modalità "filettatura a misura" di arretrare il carro anche a mandrino fermo e alla massima velocità possibile, cosa che mi risulta utile per le filettature o torniture interne.

[McMax]

La strada del flip-flop e della porta xor l'avevo percorsa anch'io, ma ci sono dei momenti durante l'inversione in cui si incasina. Il segnale DIR dovrebbe arrivare un tot di microsecondi prima rispetto agli step ma usando la logica esterna questo cambia praticamente insieme al passo. Poi é vero anche che inversioni così veloci é difficile che avvengano ma spesso mi perdeva 1 o 2 passi alla volta.....

[mimoletti]

Infatti nel mio progetto il segnale il cambiamento del dir avviene sempre prima del passo.

[McMax]

Aspetta, forse mi sono spiegato male. Intendevo dire che con la logica esterna di lettura dell'encoder, capita, soprattutto durante l'inversione, che ci sia un passo "incerto" visto che il segnale di direzione (generato dal flip-flop), viene commutato esattamente nello stesso istante del passo. Questo fenomeno é indipendente dal micro che usi per leggerlo visto che é un problema della logica....

[mimoletti]

Ti sei spiegato bene, nel mio progetto l'uscita del flip-flop è collegata ad uno degli ingressi del micro, e il segnale di dir viene comutato prima dello step in ogni caso. Non è possibile che avenga il contrario.

[McMax]

certo, è ovvio che l'uscita del flip-flop è collegata al micro.... altrimenti la direzione come la vedi?
Controlla bene perché la commutazione del flip-flop avviene solo mentre viene commutato un passo: non sarebbe possibile altrimenti far commutare il flip-flop.

[mimoletti]

Assolutamente la commutazione del dir avviene a passo già commutato, non potrebbe essere altrimenti, perché i due segnali sono sfasati di 90°. Comunque in ogni caso se perdevi passi era per altri motivi. La prima versione funzionava perfettamente. Mai perso un passo.

[McMax]

non sono d'accordo.
La commutazione del DIR sull'uscita del flip-flop avviene nel momento in cui viene effettuato un passo dell'encoder nel verso opposto rispetto al precedente. Lo sfasamento di 90° riguarda i passi in quadratura. Il flip-flop commuta SOLO quando il segnale di un canale cambia di ordine rispetto all'altro, ma usando la porta XOR per moltiplicare la risoluzione perdi la fase quindi non sai dove sei.
In pratica, se vuoi usare il flop-flop per avere il segnale direzionale devi rinunciare al moltiplicatore.

[mimoletti]

Nel mio progetto ho utilizzato un Flip-flop D (data), l'ingresso data è collegato al canale A dell'encoder, l'ingresso di clock al canale B dell'encoder, l'uscita Q ad uno degli ingressi del Pic. Ad ogni fronte di salita del clock (canale B), il livello logico sul ingresso data (canale A), viene memorizzato sull'uscita Q. Essendo i due segnali sfasati di 90°, la commutazione del dir avviene a passo già commutato. Il Flip-flop si trova a monte della porta xor. Raddoppiare la risoluzione dell'encoder, non mi priva della possibilità di usare il Flip-flop. Non vedo come possa essere il contrario.

[McMax]

La configurazione che usi è quella classica che si trova ovunque: il flip-flop cambia di stato in funzione dell'ordine di commutazione del segnale "D" rispetto al clock.
Se fai la tabella di verità di quella logica ti accorgerai che il problema c'è. Non è di facile comprensione ed io ho dovuto osservarlo facendo delle prove. Il segnale che tu prelevi dalla porta XOR è preso in parallelo a quello che vede il flip-flop e genera un impulso indipendente dalla fase di quadratura dell'encoder. Anche tralasciando sul fatto che gli stati del flip-flop sono più lenti e quindi addirittura il DIR potrebbe essere in ritardo di qualche decina di nanosecondi, il meglio che puoi ottenere è un fronte del segnale DIR che commuta nello stesso istante del passo che l'ha fatto commutare quindi, nel migliore dei casi, perdi un passo.

Quello che avviene nel codice è semplice: dal momento che userai un IF per capire lo stato del pin DIR e decidere se incrementare o decrementare il passo, quel DIR potrebbe essere ancora nello stato precedente e farti commutare in una direzione sbagliata.

Comunque sia si tratta di un problema secondario; parliamo di frazioni di grado che difficilmente condizionano la buona riuscita della filettatura.

[mimoletti]

In realtà la verità e nel mezzo, questo succede solo in uno dei due sensi di rotazione.

Primo punto: Perché dovrei perdere passi? Il timer continua a contare indipendentemente dal segnale presente sull'uscita del Flip-flop.

Secondo punto: Ammesso e concesso che in uno dei due sensi di rotazione il fronte di salita del segnale presente all'ingresso del timer sia coincidente con il fronte di salita del segnale all'uscita del Flip-flop, l'impulso di step che genero con una delle uscite del Pic può essere solo successivo al cambio di stato del Dir. Questo dipende da come ho strutturato il codice.

In realtà il mio codice e più semplice di quanto tu possa pensare, e non utilizzo nessun IF (intendi Input Capture?).

La perdita di un passo può avvenire in un solo caso, quando il periodo tra un fronte e quello successivo del segnale in ingresso al timer e di una durata inferiore a quella che mi occorre per caricare nel timer il valore di divisione.
Con una risoluzione Encoder di 3600 impulsi a giro questo si verifica quando vengono superati i 2000 giri/min, ma essendo il valore di divisione per gli avanzamenti un valore a tre cifre e come se si passasse per esempio da un avanzamento di 8 cent a giro ad un avanzamento di 0,078 cent a giro.

Ho visto il tuo PDF, da quello che ho potuto capire dandogli un'occhiata veloce, che la vite madre ed lo stepper sono collegati con un rapporto 1:1, esatto?

Anche questo non mi piace, perché aggiunto all'impossibilita di utilizzare il micro step, si traduce in un movimento a scatti del motore soprattutto con avanzamenti ridotti.

Io ho un rapporto 1:4 tra motore e vite, ed il driver settato a 1600 step a giro.