Velocità Slic3r g-code e riempimento pezzo

[Luca Zabeo]

Buongiorno,

pensavo che il portatile che uso per la prusa I3 fosse lento ad esportare in g-code (centrino dual core 1860mhz  e 2gb di ram con windows xp), allora ho preso la configurazione di Slic3r e l'ho riportata sul più prestazionante (pensavo) 8 core Amd con 8gb di ram win7 pro...

risultato: portatile batte fisso.

ho preso questo file, l'ho riparato (ha un paio di zone non coerenti) con Netfabb studio basic, e l'ho messo sul pc fisso, cambiando addirittura i tread da 2 a 6
Dopo mooolto tempo che stava ancora esportando, ho deciso di mettere lo stesso file in calcolo sul portatile: Pc fisso 25 minuti, Pc portatile 18 minuti. :-????

Possibile?


Inoltre ho provato a stampare questo pezzo
http://www.thingiverse.com/thing:61918

è venuto abbastanza bene, intendo le misure, solo che la parte superiore me l'ha lasciata aperta, in pratica non mi ha coperto il layer finale.
nella foto ho messo un rettangolo per evidenziare.
Mi manca qualche parametro da settare in Slic3r (ho cambiato da Honeycomb in Linear)?

grazie.

Luca

[Luca Zabeo]

Buonasera,

con un pò di tempo ho fatto una prova:
ho messo infill, Solid infill, top infill tutto a 100%

e il risultato è questo: (vedasi immagine),

ho messo alcuni cerchi perchè non capisco se ho sbagliato io il setting, la temperatura o altro, ho pensato ad un problema di retraction, ma non ne sono sicuro, e alcuni bordi non sono completi presentando scanalature... oppure è normale??? :-)

grazie

Luca

[Valter Bartolini]

Io apprezzo e condivido il lavoro dei ragazzi che sviluppano Slic3R, se posso

li aiuto anche (ho donato) ma su quel disegno con Cura a esportare il G code ci ho messo 6 secondi circa,

con Slic3R 4 minuti e 20 secondi circa, sono ancora lontanini i ragazzi, in piu Slic3R

alcuni disegni non me li fa propio :-( come questo: http://www.thingiverse.com/thing:13505

Per cortesia, non è una polemica, solo una osservazione :-)

[Luca Zabeo]

Ciao Valter,

devo dire la verità Cura non lo conoscevo, installato ieri sera.

Slic3r devo dire che mi stò trovando bene, a parte il tempo per la codifica del G-code, per il resto sto iniziando a vedere buoni risultati (non ottimi, a mio modesto parere), e stò provando diverse configurazioni.

Quindi presumo che una volta trovato una giusta configurazione in base ai pezzi, problemi non sussistono.

Domanda su Cura, i parametri alla fin fine sono uguali a quelli di Slic3r? Per provarlo basta che riporti i vari parametri o devo stare attento a qualcosa?

Grazie

Luca

[Alessandro Ranellucci]

L'immagine non è nitidissima, ma se il problema è la mancanza di alcuni tracciati è molto facile capire se il problema è software oppure no: si visualizza l'anteprima del G-code con un programma come Repetier-Host, Pronterface, gcode.ws. Se il tracciato è presente, il problema è hardware. Ad esempio un problema di trascinamento del filo (vite con dentatura intasata?) oppure di attrito nel condotto della hot-end (mancanza di ventola lungo il condotto?) oppure temperature troppo bassa, oppure velocità di stampa troppo alta eccetera.

Ricordate che la qualità non sta nel software, ma nel tempo che investite nel conoscere e calibrare la meccanica della vostra macchina… Non si spiegherebbero altrimenti, a parità di software, stampe perfette e stampe orrende :-)

- Alessandro

PS: saluti dallo stand RepRap al TCT Show di Birmingham :-)

[Luca Zabeo]

Ciao Alessandro,

sempre disponibile e sempre presente.... :-)

Avevo ridotto le immagini per non pesare sul forum, metto i link per le immagini ad alta qualità.
Ho controllato il file ed effettivamente non vedo grossi spazi, credo che il problema sia relativo alla velocità dell'estrusore, mi sà che devo rallentare un momento la e mettere un pò meno di retraction, in quanto i punti corrispondenti sono in concomitanza dei spostamenti e dell'inizio del riempimento.

https://www.dropbox.com/s/pbacafk87rne7hl/20130926%20-%20SS1.jpg
https://www.dropbox.com/s/j0hofbhaeqcd94n/SAM_1521.JPG
https://www.dropbox.com/s/3ipcw513c7zljqu/SAM_1522.JPG
https://www.dropbox.com/s/r9nz2zn1flpau7q/SAM_1523.JPG
https://www.dropbox.com/s/8143cmz43kn9sao/SAM_1525.JPG
https://www.dropbox.com/s/f86k4nmryjp0nmb/SAM_1527.JPG

p.s. Beato te che sei in giro per il mondo....sigh sigh...:-)))

grazie

Luca

[Luca Zabeo]

Pac-Man aggiornamento.

Ho deciso di fare una prova di stampa e ho preso il file di pacman, corretto e sistemato.

Stesso file, stessa stampa, ho solo moltiplicato il file in Slic3r, un pacman e venuto bene, l'altro beh suo fratello sfigato....

Presumo che non sia un problema di asse, presumo che non sia un problema di file, i casi sono due: estrusore o troppa poca aria....mah

https://plus.google.com/photos/109040431597022681315/albums/5928948450901318609?authkey=CLD0nKqAsqKpfQ

[Valter Bartolini]

I parametri anno qualche differenza, ma sono molto meno, da un lato è piu facile, dall'altra meno

configurabile, ad esempio non puoi scegliere una temperatura di partenza e diminuirla leggermente

successivamente, grosso modo se hai configurato sli3r Cura è piu facile, il comportamento dell'esecuzione

è però abbastanza diverso, per esempio slic3r riduce i tempi usando le ratrazzioni ed effettuando attraversamenti

dei perimetri, cura invece per gli spostamenti rapidi preferisce seguire i perimetri del pezzo a velocità di traslazione,

se fai dei dentini per una cinghia, ti accorgerai che con cura vengono perfetti perchè va e viene lungo i dentini e non

fa attraversamenti, mentre con slic3r ti rimsngono più bavette, penso che si possa ovviare ma non ho mai capito

come configurare Slic3r per fare in modo che non faccia attraversamenti ma segua i perimetri per spostarsi,

cosi uso piu spesso Cura per il Gcoda. ma come sender è scarso non mi piace, per inviare il codice uso

Repetier Host che è in Italiano :-).

Ciao!

[Luca Zabeo]

uhmmm in due parole, Cura per il Gcode e Repetier per la stamapante....

Ho fatto alcune prove oggi, con questo file: Bridge Torture Test http://www.thingiverse.com/thing:12925

corretti e visualizzati correttamente nel gcode.ws consigliatomi

Cura: veloce nella stampa, ottimo riempimento ma il bridge non è venuto un granchè (ne ho stampati diversi cambiando i parametri di velocita e di infill e retraction), ed e impreciso perchè non lasciava raffreddare il pla (ho messo due ventole e provato a rallentare la stampa), tralaltro nel file c'è un cerchio finale sul ponte, mai fatto, sul disegno a video c'è ma non lo stampa.

Slic3r: impiega qualche minuto a completarlo in più rispetto a cura (18 minuti contro i 11 di Cura), ottima stampa (layer migliore a mio vedere), bridge ottimo zero filamenti, il cerchio finale l'ha sempre stampato, inoltre ha creato due punti di supporto ai lati lasciando raffreddare correttamente il pla. Due cose non soddisfacenti: prima di iniziare il layer del ponte, benchè abbia messo un retraction forse un pelino elevato, l'estrusore non fà il reverse creando un filo che si attacca quando inizia il bridge, ad ogni prova sempre fatto (Cura non lo fà), inoltre il riempimento non è completo mi lascia un vuoto all'interno del ponte, come se si dimenticasse di creare il filo centrale (fatto diverse prove con riempimenti e infill differenti).

Purtroppo non ho fatto foto, mi son dimenticato, provvederò quanto prima.

Pensavo che costruire e assemblare la prusa fosse difficile...ma la calibrazione software non la immaginavo così...:-))))

[Alessandro Ranellucci]

Il giorno 25/set/2013, alle ore 22:18, Valter Bartolini <apo...@gmail.com> ha scritto:
> Io apprezzo e condivido il lavoro dei ragazzi che sviluppano Slic3R, se posso
> li aiuto anche (ho donato) ma su quel disegno con Cura a esportare il G code ci ho messo 6 secondi circa,
> con Slic3R 4 minuti e 20 secondi circa, sono ancora lontanini i ragazzi, in piu Slic3R
> alcuni disegni non me li fa propio :-( come questo: http://www.thingiverse.com/thing:13505
>
> Per cortesia, non è una polemica, solo una osservazione :-)

Osservazioni sempre ben accette :-)

Ti do qualche elemento per comprendere cosa c'è dietro ai tempi di elaborazione. Slic3r ha l'obiettivo di essere un CAM potente e flessibile e quindi ha tante funzionalità in più. Ogni opzione ed ogni algoritmo aggiuntivo comporta un'allungamento dei tempi di elaborazione. Alcune di queste funzionalità originali sono descritte qui: http://slic3r.org/blog/1.5-years-of-slic3r-development (ma l'elenco è molto più lungo, penso ad esempio alla gestione delle pareti a spessore singolo, che richiede un lento algoritmo chiamato medial axis, totalmente assente in Cura…) Se Slic3r facesse meno cose, sarebbe più veloce.
Inoltre in questi due anni ho imparato che il 90% dei problemi segnalati dagli utenti si risolve *aggiungendo* codice ed algoritmi. Di conseguenza un software più maturo, in grado di gestire più casi, è più lento.

Poi Slic3r è nato in un periodo ancora pionieristico della tecnologia, quando il buon vecchio Skeinforge impiegava anche un'ora… Nello sviluppare Slic3r mi sono dovuto inventare tante cose (che oggi sono state assorbite dai più recenti come Cura). Per essere più rapido nello sviluppo e poter sperimentare ho usato un linguaggio di programmazione ad alto livello, dunque più lento. Chi comincia adesso si fa forte delle cose introdotte da Slic3r e non dovendo sperimentarle può implementarle direttamente in un linguaggio veloce come il C++.

Sto lavorando da mesi per rilasciare la versione 1.0.0 di Slic3r, in cui molti algoritmi ormai maturi sono reimplementati in C++. Avrai sorprese sulla velocità :-)

- Alessandro

[Alessandro Ranellucci]

Luca,

ricordo bene la sofferenza dei primi tempi e quindi cerco di aiutarti dandoti un metodo di analisi dei problemi. Hai elencato buoni risultati e problemi delle tue stampe e li hai associati al software che hai usato, ma attenzione ad attribuire un nesso causale! È un po' come dire che le stampe del martedì hanno avuto dei problemi e quelle di mercoledì sono venute bene, e quindi è colpa del martedì :-) :-)

Dici che Cura "è impreciso perchè non lasciava raffreddare il PLA", ma non è certo colpa sua!
Sono sicuro che Cura sta facendo esattamente quello che gli hai configurato. Sei tu che col tempo prenderai la mano e lo configurerai al meglio, aggiusterai la posizione della tua ventola eccetera.
Poi dici che Cura non stampa un cerchio finale sul ponte che però si vede a video. Ma scusa… se si vede a video vuol dire che non è colpa del software. Il problema va cercato a valle.
Mi fa piacere che scrivi che Slic3r fa un "layer migliore", ma sono sicuro che Cura può fare la stessa cosa. Non è un pregio di Slic3r…

Ripeto, esistono stampe meravigliose e stampe terribili con tutti i software (persino con Skeinforge!), tutto dipende da come li configuri. Le differenze sono altre.

Ti consiglio di scegliere uno dei due programmi ed approfondirne la conoscenza, affrontando un problema alla volta, e variando un solo settaggio alla volta per capire come ogni opzione influisce. Puoi chiedere consiglio anche qui mostrando le foto e i file che aiutano ad aiutarti. Sono sicuro che così avrai anche tu stampe lisce e belle :-)

- Alessandro

[Valter Bartolini]

Purtroppo ho l'estrusore fuori uso non ho potuto satamparlo :-(

mi serve il tubetto in PTFE che dovrebbe arrivarmi martedi,

processato con Cura, tempo meno di 1 secondo, il tondo in mezzo è 0,5 di spessore,

se hai impostato come Shell tickness 0,5, non te lo fa, metti 0,45 oppure 0,90 vedrai che funge,

processato con Slic3R 5 secondi, ma che PC ai che ci metti 18 minuti :-(?

simulazione ottima, vorrei provare la stampa ma aime.... :-(

un sospeso da 50mm siamo al limite delle possibilita :-)

Ciao!

[Luca Zabeo]

Buonasera ad Alessandro e a Valter,

Vi ringrazio per le risposte, sempre precise e corrette.

Lungi da me da "dare la colpa al software", anzi grazie che esista. Altrimenti era meglio usare il pongo (come si faceva negli anni '80). :)))))

Ammetto la mia "niubba ignoranza", su molti aspetti tecnici che purtroppo non conosco (ma che mi piacerebbe approfondire).

Per Alessandro: di sicuro le mie impostazioni sono ancora acerbe, spero di effettuare alcuni test in settimana, così da essere più preciso su una cosa che ho notato con vari file processati. Cmq grazie ancora.

Per Valter: ti chiedo scusa, mi sono espresso/scritto male intendevo il tempo di stampa della Prusa tra i due file processati in in G.code. Uso un NB Centrino Duo T2060 (1800mhz), con 2 gb ram. Cosa intendi quando dici "un sospeso da 50mm siamo al limite delle possibilita"? Intendi il limite per un bridge? Prendo il consiglio per il ticketness e lo provo quanto prima. :-)

Luca

[Luca Zabeo]

Buonasera a Tutti,

purtroppo tra lavoro e malattie di stagione che si sono accanite (nel vero senso della parola) sul mio fisico, non ho avuto modo di fare delle foto agli ultimi lavori. Allego due gcode, che ho visionato con repetier host e mi presenta quei "problemi" che ho menzionato nei post precedenti

Nel long_bridge nell'ultimo layer, per esempio, ci sono 3 line di perimetro che nell'oggetto stampato sono molto marcate, e buchi nella corrispondenza del cambio direzione nel riempimento finale.

Nel bridge normale gcode, sempre visionando dal repetier si vede nel ponte che il riempimento non è completo.

Di sicuro c'è un parametro che mi sfugge... e continua a sfuggirmi... :-)))

Grazie per il supporto...

Luca

[Luca Zabeo]

Buongiorno a Tutti,

credo di essere arrivato "quasi" alla fine delle varie configurazioni software anche se manca qualcosa, soprattutto nei pezzi stampati superiori ai 5cm non riesco a trovare i settaggi per avere un riempimento al 100% nella parte finale della stampa.

Ho ricalibrato il piatto e l'asse Z, e ho fatto un esperimento, il famoso Bridge Torture Test di 50mm, l'ho scalato fino ai 90mm e stampato, oltre a provare una stampa di calibrazione, che ahime ho preso in misura americana (1 inch).

http://www.youtube.com/watch?v=EdW8cuqOwk4

https://www.dropbox.com/s/mnzqaqvmia6tjl7/DSC_0155.jpg
https://www.dropbox.com/s/778m3bv8fj09prv/DSC_0156.jpg
https://www.dropbox.com/s/e8bwu6hgnoipajm/DSC_0157.jpg
https://www.dropbox.com/s/tj483lzuwi1z01l/DSC_0162.jpg
https://www.dropbox.com/s/0oq7i4dtu8788l3/DSC_0163.jpg

Accetto volentieri suggeriment e, impressioni :-)

Luca