Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Miglioramento "Thermal Runaway Protection" #35

Closed
Zikoel opened this issue Apr 2, 2015 · 7 comments
Closed

Miglioramento "Thermal Runaway Protection" #35

Zikoel opened this issue Apr 2, 2015 · 7 comments

Comments

@Zikoel
Copy link

Zikoel commented Apr 2, 2015

Salve,

Mi chiedevo se fosse possibile migliorare ulteriormente questa funzionalità coprendo anche il caso in cui il termistore sia rotto prima della stampa. Se non sbaglio al momento la funzione di protezione entra in funzione dopo che la temperatura di stampa è stata raggiunta. Credo sia un'ottima modifica introdurre un timer che parte all'accensione e si disattiva nel momento in cui entra in funzione quello già esistente.
In questo modo si può mettere anche un limite entro il quale la temperatura di stampa deve essere raggiunta.

@MagoKimbra
Copy link
Member

Ok vedo che posso fare, lo metto in lista....

@simonepri
Copy link
Member

Non si può mettere un limite entro il quale il nozzole deve raggiungere la temperatura dato che il tempo dipende appunto dalla temperatura.
L'unica cosa logica, a mio avviso, da fare per implemetare quello che hai proposto, è fare questo ragionamento sulle variazioni di temperatura, mi spiego:
se il nozzole sta a X° si stabilisce un TMAX_PER_GRAD entro il quale il nozzole deve arrivare a (X+1)°.

Ho già il codice pronto ma se avete idee migliori dite pure

@Zikoel
Copy link
Author

Zikoel commented Apr 2, 2015

L'idea di guardare la rampa è valida, ma non capisco quale sia il problema di inserire un tempo massimo per arrivare al target. Si potrebbe fare un timer che parte all'arrivo del GCode e stacca tutto se dopo un certo tempo non è arrivato al target. A me è capitato durante delle prove di mettere un target non raggiungibile dal mio estrusore oppure di avere il termistore staccato alla partenza.

@simonepri
Copy link
Member

E' capitato anche a me e sono arrivatoa 300°, fortuna che ho un full metal.
Comunque sia il problema sta che fissando un tempo fisso la gente dovrebbe calcolarsi il tempo che il proprio estrusore impiega ad arrivare alla massima temperatura e poi inserirlo nel firmware, e dato che il tempo dipende molto non solo dall'hotend ma anche dai fattori ambientali esterni sarebbe un valore poco preciso e comunque sia non avresti un valore generale da mettere come default accettabile per tutti gli hotend.
Invece se si lavora sulle variazioni allora si può facilmente trovare un valore di tempo per eccesso che vada bene per tutti gli hotend.
Ti faccio anche un esempio:
immagina che la mia stampante arrivi a 300° in 5 minuti
e quindi il tempo massimo secondo il tuo ragionamento dovrebbe essere 5 minuti.
Se io decidessi di stampare a 100° levando di proposito il termistore la mia stampante impiegherebbe la bellezza di 5 minuti ad accorgersi che il termistore non cè.

Bene allora ciò che si può fare è rendere il tempo di attesa proporzionale alla temperatura.
Supposto che io riesca a legare tempo e temperatura, dovrai comunque attendere qualche minuto prima che la stampante vada il protezione.

Ragionando su le variazioni di temperatura si ottiene che la stampante va in protezione subito se cè qualcosa che non va invece che attendere dei minuti.

@Zikoel
Copy link
Author

Zikoel commented Apr 2, 2015

Adesso mi è chiaro... cambio talmente tante volte il firmware che mi sembrava immediato il cambio di temperatura in base alle proprie esigenze, però capisco che messo a codice non si possa fare. La tua idea come ho detto prima mi sembra valida, esistono anche alternative come prendere il valore dalla EEPROM oppure impostarlo con un nuovo GCode.
Però non sono in grado di valutare quale delle soluzioni attuabili sia la più conveniente in termini di sviluppo. Che cosa ne pensi?

@simonepri
Copy link
Member

E' tutto relativamente semplice da realizzare, in ogni caso sono poche righe di codice.
Comunque non capisco perchè ritieni che comunque dovrebbe essere più comodo avere un timeout fisso.

@Zikoel
Copy link
Author

Zikoel commented Apr 3, 2015

No, credo che la soluzione migliore in termini di sicurezza è quella che hai proposto tu. Insistevo con il valore fisso solo perché mi sembrava meno costosa da implementare.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants