motore stepper con controlo posizione pid e encoder

ho fatto una versione veloce della scheda pcb

tempo di stamparla con il cnc e provarla

ho finito il prototipo assemblato e stampato il PCB

sistemato un po la stampante e ora la qualita' e' migliore

l'errore di retraction dovuto al gioco dell'ingranaggio dell'estrusore e del gioco del filo dentro la guida sembrano corretti

oltre a questo e' possibile intervenire sui alcuni parametri per migliorare la stampa e ottimizzare il deposito della plastica

[youtu.be]

Edited 1 time(s). Last edit at 11/15/2015 07:04AM by c128.

Forse mi è sfuggito: l'encoder da quanti passi è?
E dove l'hai trovato? A quanto?

l'encoder e' recuperato da una vecchia stampante, la risoluzione e' piu' di 100 righe steps

Ciao c128, sei sicuro che sia 100 righe per ogni step.? Mi sembra un po' troppo.

Quote
c128
l'encoder e' recuperato da una vecchia stampante, la risoluzione e' piu' di 100 righe steps

Nel senso che, con motori da 200 passi/giro o 1.8°, hai 100 righe ogni 1.8°?

il motore e' da 0.9' le righe misurate sono circa 100 per mm(mio errore di memoria non per steps) ma devi considerare che c'e' un gears di riduzione del motore di 3.15 circa quindi ogni steps coincide con un movimento molto minore

da quello che vedo dalle stampe che ho fatto il deposito sembra piu' omogeneo
nessun problema dal stm32 ne strani errori, ho aggiunto un controllo di errore nel caso l'encoder rimanga bloccato per evitare un loop continuo
altro per ora non serve aggiungere

questo driver si attiva soltanto nel momento in cui c'e un retraction e si chiude al ritorno in posizione di stampa riconsegnando il controllo dell'estruder all'arduino per la stampa

p.s. adesso che mi avete messo il dubbio devo andarmi a rivedere quante righe esatte vengono lette per step

Edited 4 time(s). Last edit at 11/15/2015 07:03AM by c128.

ho fatto le dovute verifiche anche perche' l'encoder era la prima cosa che ho inserito nel codice

per 500 steps ci sono 200 righe dell'encoder

questo vuol dire che c'e' un margine di errore ma credo accettabile '

per questo progetto devo migliorare la parte meccanica
per ora lo metto in standby

questa e' una stampa con encoder c'e un problema nell'asse Z che non rende bene l'idea

Buonasera,
sto realizzanco un progetto per poter bucare dei tubi (circa 100 buchi su una lunghezza di 5m) in automatico come foto allegata con due motori Nema 17 con motoriduttore in serie (per intenderci tutti e due i motori trascinano il tubo per aumentare la forza) usando l' uscita asse Z per il trascinamento del tubo e un Nema 17 collegato all' uscita Y per far scendere l' elettromandrino con la punta per bucare il tubo usando Arduino Mega + Rampe 1.5 + LCD 12864 con ingresso SD.
Al momento sto usando Firmware di marlinkimbra per stampanti 3D perche è gia completo di tutto, basta creare il GC con le propie esigenze e il tutto funziona, io ora vorrei inserire un Encoder per eliminare l'errore di posizionamento del tubo dovuto a piccoli slittamenti del tubo sulle puleggie.
Da come ho letto è possibile modificare il Firmware per inserire un encoder, potreste aiutarmi a realizzare il mio progetto?
Ringrazio chiunque possa aiutarmi.

Quote
alessandro347
Buonasera,
sto realizzanco un progetto per poter bucare dei tubi (circa 100 buchi su una lunghezza di 5m) in automatico come foto allegata con due motori Nema 17 con motoriduttore in serie (per intenderci tutti e due i motori trascinano il tubo per aumentare la forza) usando l' uscita asse Z per il trascinamento del tubo e un Nema 17 collegato all' uscita Y per far scendere l' elettromandrino con la punta per bucare il tubo usando Arduino Mega + Rampe 1.5 + LCD 12864 con ingresso SD.
Al momento sto usando Firmware di marlinkimbra per stampanti 3D perche è gia completo di tutto, basta creare il GC con le propie esigenze e il tutto funziona, io ora vorrei inserire un Encoder per eliminare l'errore di posizionamento del tubo dovuto a piccoli slittamenti del tubo sulle puleggie.
Da come ho letto è possibile modificare il Firmware per inserire un encoder, potreste aiutarmi a realizzare il mio progetto?
Ringrazio chiunque possa aiutarmi.

Il post è vecchio e magari qualcuno ha realizzato altre cose, in giro, magari usando come base GRBL che per usi CNC è più in "tema".

Per il progetto però dovresti assicurarti che anche le pulegge dell'encoder non slittino.

Altro punto critico, usare la Z per un compito da Y e la Y per un compito da Z è per lo meno confusionario.

La Z è sempre l'asse Z (su è giù) e per l'avanzamento orizzontale hai la scelta tra X e Y (a questo punto a tuo piacimento).

Se non sbaglio perché vado a memoria esistono varianti di GRBl che girano sul Mega e che hanno quindi a disposizione gli ingressi necessari per un "quadrature encoder" e ottenere un sistema "closed loop" (riporto i nomi in inglese perché la ricerca viene meglio).

Il problema è vecchio anche perché esistono già ad esempio stepper con integrato un controllo di movimento per cui se lo stepper perde passi viene "corretto" dall'elettronica di controllo. (Sul sito di Openbuilds italia trovi dei NEMA 23 a prezzi "ragionevoli").

Il tuo problema è che devi separare la trazione dalla "lettura del movimento del tubo".

Però anche nella lettura del movimento del tubo con un encoder, nel calcolo entra il diametro della "ruota di lettura" che analogamente al problema del filamento più o meno duro in cui la ruota di trascinamento affonda più o meno se dai ad esempio 500 passi con un filamento e ti avanza di 1 cm con un secondo tipo di filamento sempre con 500 passi avanzi di solo 0,99 cm e allora dovrai dare più passi per ottener un avanzamento di 1 cm.

Nel tuo caso devi comunque misurare dopo ogni ritocco della "pressione" sulla ruota di lettura per ottenere una aderenza senza slittamenti, quanti passi la ruota legge per ottenre la tua "misura standard" e questo prevede di mettere in piedi un sistema di misura del riferimento (automatico o manuale).

Diventa il classico problema in cui un controllo tipo CNC deve essere supportato da qualcosa di "esterno" o per lo meno di "dedicato"

In pratica dovrai serrare la ruota di lettura per ottenere l'assenza di slittamento e misurare a quanti passi "letti" corrisponde la misura di riferimento:diciamo che per ottenre 1cm hai 505 passi.

comandi il motore di trazione non di 505 passi, ma "fino a quando" la tua ruota di lettura ti ha restituito 505 passi. a questo punto il processore dovra dare un numero di step variabile al motore di trazione per ottenre i 505 passi sulla "ruota di lettura".

Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]

Buongiorno,
grazie per la risposta, la mia macchina è già realizzata con le componenti che ti ho descritto, il mio problema e che in fase di collaudo mi sono accorto che senza un encoder che rileva la misura di spostamento esatta non ho la ripetibilita dei pezzi bucati, in quanto alla fine dei 100 fori in 5m mi trovo degli errori di qualche centimetro, per non stravolgere completamente il mio progetto e risparmiare soldi e tempo vorrei inserire un encoder fra i due motori di trascinamento con un sistema di slitte con molle per tenerlo in compressione con il tubo ( in questa maniera non credo che possa slittare in quanto non ci sono forze in gioco solo l'attrito dell' encodr che è bassissimo).
Per quanto riguarda la scelta dell' asse Z per far scorrere il tubo e che sulla ranpe 1.5 è gia pronta da doppia uscita per l' asse Z senza troppi modifiche da fare per collegare i motori, basta ricordarsi in fase di programmazione del GC.
potresti aiutarmi a realizzare una cosa simile?

Il problema è la retroazione "separata" dalla trazione, io però non sono in grado di modificare un firmware per tenere conto dell'encoder, che deve essere letto e confrontato ad ogni movimento per verificare che il movimento del motore sposti correttamente il tubo di tot centimetri (fidandosi del non slittamento dell'encoder), il comando dell'ipotetico gcode dovrebbe comportarsi in questo modo:

aziona il motore fino a quando lo spostamento effettuato (legge i passi dell'encoder) corrisponde al valore impostato di step.

Però tu comandi uno stepper che conosce solo il comando di step e dir cioè gli "devi" dire di quanto spostarsi e se questo spostamento è scorretto devi calcolare di quanti step deve compensare (ammesso che ci sia trazione e non perda ancora step).

In alternativa il comando sarebbe:

1) muovi di uno step
2) controlla il valore dell'encoder
3) verifica che il target sia raggiunto (cioè il numero di step che arrivano dall'encoder sia quello previsto) ?
3a) se si sei a posto e passa alla prossima istruzione
3b) se no ripeti la procedura.


Tutto questo deve iinterporsi tra la ricezione del comando di spostamento e l'attuazione del movimento.

Saluti

Carlo D.

---

P3Steel - MKS GEN v1.2 e REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + Gen 7 MOSFET (HotBed) + alimentatore step-down 12V -> 5V
Firmware MK4duo 4.3.6 con ABL induttivo con LJ18A3 - Slic3R (Originale) ed ESP3D per controllare la stampante da remoto.
HotEnd Cinese V6 clone con ugello da 0.4mm.

[My Building Log]