problema sulle dimensioni (slic3r/marlin)
Salvatore Balestrino
ad esempio un diametro 8mm mi diventa un 7.4mm
la stampante e' calibrata a dovere e quindi penso che il problema sia in qualche impostazione che sbaglio su slic3r o sul firmware
sapete darmi un indicazione?
thanks :)
Alessandro Ranellucci
>le dimensione delle stampe non sono corrette, ad es. i
diametri dei
>fori mi vengono piu piccoli di quello che dovrebbero ad
esempio un
>diametro 8mm mi diventa un 7.4mm
Ciao Salvatore,
un errore di 0.6mm su un foro di 8mm mi sembra più che
accettabile. A livello teorico ci sono alcuni fattori (oltre
alla calibrazione) che influiscono sull'accuratezza dimensionale
dei buchi: principalmente sono il ritiro della plastica con il
raffreddamento e la forma poligonale -e non circolare- che
qualsiasi superficie ha quando rappresentata in un file STL
(l'area di un poligono inscritto in una circonferenza è sempre
inferiore a quella della circonferenza stessa).
Per il primo problema si può rallentare la stampa dei perimetri;
per entrambi i problemi molto spesso la soluzione è nella
compensazione del fenomeno a livello di modellazione. Su alcuni
blog -mi viene in mente quello di nophead- ci sono delle formule
e delle tabelle che molte persone usano per ingrandire i buchi
tenendo conto di come usciranno stampati.
Per quanto riguarda la calibrazione, puoi giocare con Nozzle
Diameter (facendo lievi variazioni), Filament Diameter ed
Extrusion Multiplier. Per quanto la stampante ti risulti
calibrata, probabilmente esistono altre combinazioni di questi
parametri che mantengono l'accuratezza di altre caratteristiche
(ad esempio i ponti o le superfici solide) ma migliorano la
dimensione dei buchi. È una questione di equilibrio e di
tentativi, non so darti indicazioni più guidate :-)
- Alessandro
Salvatore Balestrino
il problema alla fine non e' tanto per i fori che di solito si possono ripassare con una punta ma il problema grave e' ad esempio la testa dell'M8 che non mi entra nell'ingranaggio grande del Wade
ho fatto un file di test e l'ho messo su thingiverse, se avete tempo/voglia fatemi sapere i vostri risultati
- Alessandro
--
Hai ricevuto questo messaggio in quanto sei iscritto al gruppo RepRap Italia.
Maggiori informazioni:
http://groups.google.com/group/reprap-italia?hl=it
Previdi Roberto
ho fatto un file di test e l'ho messo su thingiverse, se avete tempo/voglia fatemi sapere i vostri risultati
Salvatore Balestrino
--
Davide Dalfiume
Non è quindi un fattore determinante dal software.... o perlomeno sono convinto che ogni macchina avrebbe la possibilità di migliorare sensibilmente le tolleranze ma più che dal software penso che siano correzioni da fare a livello firmware e la difficoltà consiste nel fatto che difficilmente ogni macchina autocostruita possiede le stesse tolleranze e caratteristiche meccaniche mentre i software ed i firmware che si utilizzano sono sempre quelli per tutte. D'altronde se avessimo davvero la possibilità di eliminare le tolleranze a quel punto arriveremmo a caratteristiche da prototipazione professionale... ed anche in quel ambito se si va sulle fasce più economiche si hanno problemi similari....
Previdi Roberto
Non è quindi un fattore determinante dal software.... o perlomeno sono convinto che ogni macchina avrebbe la possibilità di migliorare sensibilmente le tolleranze ma più che dal software penso che siano correzioni da fare a livello firmware e la difficoltà consiste nel fatto che
Salvatore Balestrino
--
Davide Dalfiume
io per il momento, come detto, calcolo le tolleranze sui test stampati in base alle quote, le forme e lo spessore del layer...... purtroppo questo metodo induce errori di stampa nel momento in cui si condivide pubblicamente un files (thingiverse), d'altronde, avete mai stampato qualcosa da thingiverse che sia assemblabile con misure perfette? io no
forse con le stratasys.....
comunque continuiamo a porcelo il problema.... e chissamai riusciamo a rivederlo in maniera un pochino più "standardizzata"
Alessandro Ranellucci
>D'altro canto lo slicer ha la possibilità di analizzare il
modello 3d
>intero, e capire dove sono i buchi. Penso che sarebbe
fattibile un
>procedimento di questo tipo:
>[...]
Il punto è l'accuratezza dei modelli fisici. Io non ho mai
guardato i processi di estrusione al microscopio, né ho mai
misurato le pressioni nei condotti, né conosco i ritiri termici
delle plastiche che usiamo.
Ho implementato in Slic3r dei modelli fisici ipotetici,
sicuramente semplificati, ai quali sono arrivato col
ragionamento e l'osservazione a occhio nudo. Ho studiato i
fondamenti della reologia e ho una bibliografia in materia, ma
ci faccio poco senza riscontri sperimentali e soprattutto con
una varietà di hardware notevole.
Lo slicer genera i percorsi e decide quanto materiale occorre
per ogni segmento. Ciò si basa su un equilibrio di volume e su
modelli di tipo geometrico, ossia relativi alla forma che assume
il materiale estruso.
Il firmware controlla il flusso. Nel G-code c'è scritto quanto
materiale occorre per ogni segmento, ma il firmware decide
*come* controllare l'estrusore per far sì che il flusso sia
costante: il firmware considera la variable *tempo* che nello
slicer non è presente.
Un firmware evoluto come Marlin include tra le altre cose:
- il controllo dell'accelerazione;
- l'algoritmo di Matt Roberts, noto come "advance", che usa un modello
fisico per controllare il flusso tenendo conto delle
pressioni e della
viscosità.
Potrei dilungarmi, ma una immagine vale mille parole:
http://forums.reprap.org/read.php?263,110934,112726#msg-112726
In quella foto, Ahmet ha cambiato l'accelerazione del firmware
durante una stampa. Guardate come cambiano le dimensioni dei
denti. Eppure il G-code è sempre lo stesso...
Per quello che vale, molta gente (anche molto esperta come lo
stesso Ahmet e altri) mi conferma che con Slic3r riesce ad
ottenere buchi di dimensioni perfette. Il merito non è tutto di
Slic3r... configurate bene il vostro firmware!
- Alessandro
Davide Dalfiume
https://github.com/prusajr/PrusaMendel/issues/39
se può essere utile per l'ingranaggio
Salvatore Balestrino
continuero' a studiare il problema che ho sulle dimensioni e vi faro' sapere
FabioP
delle schede replike? Questo perchè EMC ha una gestione dei motori
molto performante e dispone del realtime integrato. E' molto stabile e
totalmente gratuito, perchè perdere tempo con quegli accrocchi? ciao
Fabio
On 7 Feb, 21:06, Salvatore Balestrino <salvatore.balestr...@gmail.com>
wrote:
> grazie Davide, ho provato questo <http://www.thingiverse.com/thing:6713> ed
>
> continuero' a studiare il problema che ho sulle dimensioni e vi faro' sapere
>
> Il giorno 07 febbraio 2012 15:18, Davide Dalfiume
Salvatore Balestrino
io mi trovo benissimo con Arduino, la RAMPS e una SD.
Alessandro Ranellucci
>scusate se mi intrommetto, ma qualcuno utilizza EMC di linux
al posto
>delle schede replike? Questo perchè EMC ha una gestione dei motori
>molto performante e dispone del realtime integrato. E' molto
stabile e
>totalmente gratuito, perchè perdere tempo con quegli accrocchi?
Quali accrocchi?
Diverse persone lo fanno, ma onestamente non ne vedo i vantaggi.
Hai comunque bisogno di un'elettronica aggiuntiva per il
controllo delle temperature (e dei finecorsa?). Come diceva
Salvatore, ti perdi anche la possibilità di stampare da scheda SD.
Inoltre EMC non contiene alcun algoritmo speciale per il
controllo del flusso (vedi il mio messaggio di ieri). Una
stampante FDM non è del tutto equiparabile ad un utensile CNC,
perché c'è di mezzo il flusso che va gestito con la variabile tempo...
- Alessandro
FabioP
informo. Per i costi, i driver Pololu possano funzionare con una
semplice interfaccia parallela, mentre per la gestione del flusso ho
fatto un setup
solo soft al momento e sembra funzionare bene il controllo dell'asse A
per l'estrusore sia con Sfact che Slic3r.
Salvatore Balestrino
se siamo nell'ambito delle prove e della sperimentazione va bene tutto, ma io starei attento ad uscire fuori dai toolchain che si sono e si stanno sviluppando intorno alla RepRap.
Previdi Roberto
Drakelive
EMC2 non è generatore di GCODE e neppure invia GCODE alla stampante. Strano adirsi ma EMC2 è l'equivalente di Marlin ma lato PC. Quindi noi gli forniamo il GCODE e lui, tramite parallela\e invia i comando direttamente hai driver di potenza per gli stepper.
Si EMC2 fa parte del progetto linuxcnc ed è il controllo numerico più avanzato presente nel panorama OpenSpurce.
E' utilizzato moltissimo in ambiti industriali per pantografi, CNC, Frese, Torni e Robot antropomorfi.
Oltre tutto possiede un ambiente integrato chiamato Hall che permette il controllo di periferiche esterne grazie ad un'interfaccia a Blocchi logici.
Nei vari Forum sul controllo numerico di tipo professionale dicono che EMC2 è molto più preciso di molto altri software anche professionali.... in effetti parlano proprio di precisione e qualità finale.
Saluti
Drake
FabioP
quanto lo uso tutti i giorni per lavoro.
In breve,avevo diversi controlli cnc basati su Win, ma il loro
funzionamento era variabile, incostante,
a volte a secondo del PC utilizzato. Solo quelli più sofisticati e
costosi con molta elettronica dedicata,
funzionavano veramente bene. Con alcuni vecchi P4 riesumati, al
contrario, ottengo eccellenti risultati di precisione
e ripetibilità da circa due anni, a costo zero. Ricordo che le
elettroniche più semplici spesso avevano latenze e faticavano
molto a mantenere la traiettoria programmata, anche la gestione dei
motori era decisamente inferiore ed ho impiegato
parecchio per capire e risolvere il problema. Sicuramente ci saranno
problemi di settaggio e meccanica, ma ricorda molto
quanto mi è già capitato.E' possibile usarlo come applicazione dentro,
Win se non piace, si disinstalla come un normale
programma Win oppure lo si può utilizzare per fare prove comparative
tra le varie piattaforme.
Se si vuole gestirlo via USB c'è questa http://www.mesanet.com/.
Drakelive
Concordo sul fatto che in campo professionale e quindi in quei settori dove le tolleranze e quindi la
repitibilità dei movimenti sia un'elemento critico l'utilizzo di EMC2 è una scelta validissima e sopratutto
economica.
EMC2 prende in input i file GCODE e li interpreta producendo il percorso utensile che di fatto sono i "segnali"
da inviare hai driver dei motori tramite porta parallela. E' questa la ragione per la quale EMC2 è fornito
come ISO con un Kernel Realtime e con una accurata scelta dei servizi attivi. Ecco perchè quando si fresa un
foro le superfici ne risultano precisissime e non scalate..... infatti i movimenti sono continui e fluidi
cadenzati da tempistiche ben precise.
Poi ci sarebbe da considerare che il set dei comandi GCOD è davvero completa e ben sviluppata!
L'uso delle porte parallele alla fine è identico all'uso delle porte ad 8 bit di Arduino .... il firmware
non fa altro che prendere un comando GCODE trasformarlo in "movimenti utensile" ed inviarlo alla porta
ad 8 bit sotto forma di Byte......
L'unica criticità nell'utilizzo delle vecchie parallele è l'uso di cavi lunghi tra PC e Driver Motori e
le interfrenze di ogni tipo che stanno in contesti industriali ma in queste realtà in genere il controllo
numerico ( EMC2 ) è incluso dentro Armadi Metallici schermati che includono gli alimentatori e Driver di
potenza. Quindi di fatto il controllo numerico è a breve distanza dalla macchina mentre gli unici cavi
che escono dall'armadio sono quelli che vanno hai motori e hai sensori ecc.
Il GCODE in genere si inserisce in una cartella condivisa in rete presente nel pc dentro l'armadio e lo fa
in genere il disegnatore .... mentre l'operaio addetto alle macchine richiama il GCODE tramite una sorta
di Joystik con un piccolino modulo LCD.
Non conosco purtroppo i convertitori USB ma per sentito dire in forum specializzato non ne parlano benissimo
ma è anche probabile che negli anni qualcuno abbia prodotto qualcosa di valido.
Saluti
Drake
Drakelive
Mi sono reso conto di avere lo stesso problema sulle dimensioni.
Ho una Orca v0.3 con Gen6 e Marlin configurato per questa stampante. I test sugli spostamenti ha dimostrato che il Firmware è perfettamente configurato preservando la precisione anche su spostamenti molto veloci quindi mi fa pensare che almeno in questi termini la stampante si comporta molto bene.
Quindi quello che mi viene da pensare è se davvero Slic3r non abbia niente a che fare con questo problema.
Ho condotto un po di test anche a velocità bassissime..... tipo lumaca ma niente..... pare che la elocità non influisca..... l'errore di dimensionamento c'è e rimane costante.
Non dico che per forza ci debba essere un bug in Slic3r magari l'ho configurato male io.
Per esempio il parametro del diametro dell'ugello potrebbe influire sulle dimensioni ?
Io ho un estrusore V9 di Mendel-Parts.com per fili da 1,75mm e un'estrusore da 0,35 mm. Se per un motivo o un'altro ( diciamo una botta sul piatto di alluminio ) l'ugello presenta un diamerto minore che cosa comporta in fase di stampa?
Invece le variazioni del diametro del filo PLA cosa comportano ?
Saluti
Drake