Sistema economico di livellamento del piano di stampa

Anche se un po' scettico, segnalo questo sistema:
[diy3dprinting.blogspot.it]
è più economico degli altri proposti fin ora, ma come ho detto rimango sempre un po' scettico, perché comunque è un adattamento al disallineamento del piano di stampa da parte del gruppo estrusore e non il contrario cioè un livellamento dinamico del piano.

---

Prusa I3 R2 di Nicola P. Hotend IeC 1.75
Delta Kossel V250 in costruzione

Parole sante... Come piu volte spiegato l'ABL ,sviluppata in questo senso, è una funzione concettualmente sbagliata.

---

R2 Evo-Prometeo-Poseidon-Titan0
Multiextruder NPr3-WR4
[www.3dmakerlab.it]

Giusto per ricordare il post
Disegno di MagoKimbra

Tra l'altro è proposto da Mr. Prusa

---

Prusa I3 R2 di Nicola P. Hotend IeC 1.75
Delta Kossel V250 in costruzione

solo per curiosità, perchè non è stato implementato un sistema di calcolo dei delta per compensare la x e la y per mantenere la perpendicolarità sul piano?

E' una bella idea, probabilmente implementabile recuperando pure parte dal codice usato per le Delta.
Per funzionare dovresti ipotizzare un piano di stampa dato da un unico piano geometrico non normale all'asse Z.
Dovresti far il probe in 3 punti del piano e partire da lì per i calcoli.
Non funzionerebbe per quei piani di stampa con collinette o cunette rilevabili con almeno 4 punti di probe (ad esempio i miei specchi Ikea più alti al centro).
In questi ultimi casi non c'è modo di avere una superficie di adesione di partenza veramente piana, ma potresti ricorrere ad una funzionalità di raft automatico nel firmware (da scegliere se lasciare abilitata o decidere alla fine del probing).
Un po' complesso ma potrebbe funzionare...

Magari non l'hanno ancora implementato perchè l'Arduino Mega non ci starebbe dietro con i calcoli (non credo) oppure perchè non l'aveva proposto ancora nessuno....

Edited 1 time(s). Last edit at 09/26/2014 03:57PM by lion_heart78.

Guarda, io ho fatto un paio di conti, ci sta alla grande che abbia toppato, ma dati due assi, x e y a me il delta viene sinA x cosA x BC dove A è l'angolo compreso tra uno degli assi e la retta passante per l'origine e uno dei punti del probe (o meglio,della proiezione del punto nello spazio,sui due assi)chiamiamolo B e C è la sua proiezione sull'asse adiacente all'angolo.

Spero di essermi spiegato,e ripeto,non se se ho fatto i conti giusti, però potrebbe valere la pena rivederli...

Secondo me non si devono nemmeno scomodare gli angoli. Ma è sabato mattina e non garantisco.
Mi viene solo il dubbio che non lavorando in un piano normale al nozzle, potrebbe esserci una valore di non-normalitá limite oltre la quale il bordo esterno del nozzle gratta il filamento già depositato.

Beh sta cosa servirebbe per piccoli delta ..se poi uno prova a stampare con uno squadro del piano evidente ad occhio nudo,se la stampa fallisce saranno anche cavoli suoi...no?

ovvio, se il delta è ridotto il nozzle su può spostare su un gradiente di Z senza grattare...

Quote
ZIOLele
Beh sta cosa servirebbe per piccoli delta ..se poi uno prova a stampare con uno squadro del piano evidente ad occhio nudo,se la stampa fallisce saranno anche cavoli suoi...no?

Eheh... guardati questo video e ne riparliamo!

Quindi in sostanza l'hanno già fatto... E funziona...

Direi proprio di sì. Peccato che sia una prerogativa del Merlin... con Repetier siamo ancora lontani.

Si infatti hanno aggiustato parecchio in marlin per compensare l'inclinazione del piatto, ora c'è una matrice X Y Z con tutti i calcoli... Vi dico solo che con un arduino mega il calcolo impegna molto la CPU rallentando molto la stampa a secondo dei gradi di inclinazione, nel video si ha una situazione oltre tutti i limiti e si vede come stampa piano il tipo...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ma trasferire questa trasformazione di coordinate nello slicer? Eventualmente con un plugin post-slicing con le coordinate campionate dal probe?

Quote
MagoKimbra
Si infatti hanno aggiustato parecchio in marlin per compensare l'inclinazione del piatto, ora c'è una matrice X Y Z con tutti i calcoli... Vi dico solo che con un arduino mega il calcolo impegna molto la CPU rallentando molto la stampa a secondo dei gradi di inclinazione, nel video si ha una situazione oltre tutti i limiti e si vede come stampa piano il tipo...

Effettivamente, pensandoci un attimo, il calcolo non è cosi banale. Non sarebbe correetto infatti agire solo sull'asse z, compensando il disallineamento verticale rispetto al piano orizzontale. Otterresti una "proiezione" dell'oggetto sul piano inclinato. Mentre la via corretta è una rototraslazione del sistema di coordinate, che poi è quella del video, in cui l'oggetto si mantiene normale al piano inclinato.

In robotica questo tipo di operazioni si effettuano attraverso le matrici ma sono davvero molto laboriose.

Quote
lion_heart78
Ma trasferire questa trasformazione di coordinate nello slicer? Eventualmente con un plugin post-slicing con le coordinate campionate dal probe?

Ma lo slicing non si fa prima?bisognerebbe fare prima un probe, POI lo slicing dell'oggetto. però a questo punto ogni stampa diventa mondo a sè e non ti salvi più il g-code ( tra una stampa e l'altra, il piatto potrebbe muoversi)

Beh, chi stampa da PC via usb potrebbe lanciare il probing, recuperare da comando i valori di probing salvati in eeprom, quindi fare lo slicing e con una post-elaborazione fare il ricalcolo le coordinate. Oppure potrebbe essere il plugin di post-elaborazione a lanciare lui stesso il probing (a stampante connessa) e mandare i comandi per recuperarsi i riferimenti.
Similmente chi stampa da SD potrebbe avere una funzione di probing da LCD che salva su SD ed eeprom i campioni da usare in post-slicing.

Se devi ri-tarare il piano manualmente (o usare l'auto bed level con campioni diversi) dopo ogni stampa hai un serio problema di fissaggio.
Io se stacco il pezzo o addirittura tolgo e rimetto il vetro non devo ri-tarare ogni volta.
Però la verifica automatica dei cambiamenti della taratura, un attimo prima di stampare a piatto e ugelli caldi, può essere utile.
Eviti di ritarare a mano se non serve, blocchi le stampe dall'inizio se qualcosa è cambiato troppo, ed eventualmente sa se utilizzare o meno il ricalcolo delle coordinate al volo (che rallenta la stampa).

Una sequenza potrebbe essere questa:
Faccio lo slicing nel modo attuale.
Faccio il probing con un comando dedicato e ottengo i 3 campioni (salvati in eeprom e su SD o mandati via USB al pc).
Li uso per la rototraslazione in post-slicing, che mi riscrive il gcode e mi aggiunge dei comandi custom all'inizio.
Ottengo un nuovo gcode che:
- prima di iniziare la stampa rifà il probing
- se i campioni sono uguali a quelli in eeprom o nell'iniziativa del gcode, usati per la rototraslazione fa partire la stampa (che risulta quindi veloce)
- se i campioni son troppo diversi abortisce subito la stampa o propone di ricalcolare tutto al volo in fase di stampa (che risulta più lenta)

Al momento della preparazione della stampa successiva avrai già i 3 campioni sul PC per fare la post-elaborazione e quindi farai tutto subito, velocemente con la potenza di calcolo del pc e senza necessità di accedere alla stampante.
Quindi ad inizio stampa sulla stampante potrai avere il riscontro se la tua preparazione del gcode è già adatta al non allineamento attuale del piano e decidere di conseguenza.
La scelta e i riscontri richiedono LCD ed encoder ma si potrebbero usare dei timeout per sapere se il piano si è mosso e si abilita in automatico il ricalcolo al volo.
La funzione non cambia ma credo la usability migliorerebbe.

Edited 1 time(s). Last edit at 10/03/2014 07:46AM by lion_heart78.