Truck64

Anche in Ideamaker nello start gcode vanno messe le istruzioni di predisposizione, come per tutte le stampanti e macchine utensili. A te manca + o - tutto. Questa è presa dalla pagina 246 del manuale di IdeaMaker. Da quanto ne so ci sono errori anche in questa immagine ma almeno ti può dare un idea di cosa dovrebbe contenere lo start gcode Di sicuro a te mancano come prime istruzioni G21 ; set units to millimeters G90 ; Set all axes to absolute Poi ci dovrebbe essere l'autohome G28, da eseguire con la sequenza fissata da firmware o in una sequenza diversa. Poi eventuali attivazioni di calibrazione del piatto, ecc. Visto come è impostato ora il tuo slicer l'home degli assi glielo fai da pannello ad ogni accensione? Ti ricordi sempre di farlo? Gia che ci sei comincia subito a correggere l'end gcode: G91 ; usa coordinate relative G1 E-1 F300 ; retract the filament a bit G1 Z+2 E-5; move Z uo and retract more the filament G90 ; Set all axes to absolute G28 X0 ; Home X Axis G1 Y285 F3000 ; Present Build Plate M106 S0 ; Turn off Cooling Fan M104 S0 ; Turn Off Extruder Heat M140 S0 ; Turn of Bed Heat M84 ; Disable Steppers

Quello che sconcerta me è che lo faccia "a volte". L'end gcode lo fa sempre o mai, se comincia a farlo quando gli pare è un problema grosso. Non mi risultano casi possibili di comandi " in sospeso", tranne le pause/riprese che sono comunque gestite con richieste esplicite, quindi in condizioni di avvio ciclo normale non può restarti una coda di di istruzioni dalla stampa precedente. Se proprio vogliamo fare i precisi al tuo gcode iniziale manca l'impostazione di movimento in quote assolute (G90 come prima istruzione), però mancano anche le istruzioni per riscaldare hotend e piatto, l'home assi ecc. Faresti meglio a postare le schermate dello slicer relative a start/end gcode, almeno si capisce come sei messo.

Non ho capito se hai risolto o no. Per curiosità ho fatto la prova con la versione attuale del firmware e (con la solita correzione) compila correttamente.

La riga che ho evidenziato probabilmente era G1Y285 F3000. Così com'è scritta da te manda il piatto avanti di 285mm dalla posizione attuale (immagino che i finecorsa sw della stampante siano stati regolati bene altrimenti andrebbe a sbattere ogni volta) e Z su di 3m (!!!) che a 5mm/s ci metterebbe una vita. Anch'io stampo prevalentemente Petg Sunlu. Il bianco e il nero sempre tra 230 e 235°. Ma può esserci anche una differenza di letura dei termistori tra la mia stampante e la tua quindi vale il risultato della temptower.

Il primo strato di stampa più che scenza è arte 🤪. Al di la delle facezie i fattori che fanno scattare l'estrusore possono essere tanti, per come la vedo io primo è l'impazienza che ti fa partire con la stampa appena vedi la temperatura anche se magari il nozle ci mette qualche secondo in più del termistore a scaldarsi, il secondo è il contrasto con il piano di stampa centinaia di gradi più freddo del filamento che ne blocca il flusso molto più del resto del modello qualche layer più su. E' per quello che in tutti gli slicer ci sono impostazioni di velocità temperatura e flusso indipendenti per il primo layer. Per quanto riguarda l'ingrossamento del il filamento può essere una causa ma non te lo saprei dire per certo: io uso solo gole all-metal e quei problemi non mi si sono mai presentati. Se sei sicuro che la temperatura sia corretta ti suggerirei di provare 5..10° in più per il primo layer e 25% di velocità in meno.

Scusa la domanda ma l'Hemera è un estrusore diretto come ce ne sono tanti altri. Si differenzia dal bowden originale della Ender per step/mm e forse per senso di rotazione, entrambe modifiche che volendo non richiedono il cambio di firmware. C'è qualche altra ragione che ti ha spinto all'impresa? Comunque specifica quale sono i problemi che vediamo come risolvere.

si Se accendi la stampante con il filamento già caricato fino al nozle, o riparti dopo una stampa con autohome non vedi differenze. Cambia solo se hai mosso l'estrusore prima dello start. Sicome di base il firmware interpreta le quote di G1 come assolute (c'è anche modi di impostare E come sempre incrementale ma secondo me da più problemi che altro) l'estrusore andrà avanti solo se è in posizione <15mm, altrimenti ritrae. Il linguaggio Gcode non è molto complesso ma ha le sue regole di sintassi e di ordine dei comandi. Se non ci lavori o non l'hai fatto a scuola ci vuole un po a impararlo.

Il primo comando E0 non ha senso. Il reset della posizione dell'estrusione è G92 E0. Cos' come è scritto se prima di partire hai fato andare avanti l'estrusore di 30mm o più è normale che al secondo e/o quarto movimento muova dalla parte sbagliata. Rivedi lo start-gcode.

Allora io la prova la farei proprio. Con quella puleggia hai 0,16mm di spostamento per passo motote ma ho data un occhiata ad alcuni tutorial e forse è una risoluzione un tantino bassa, dipende dal punto del laser. Al limite credo si possa contare sul mezzo passo, quindi 0,08mm tra le righe può andare comunque.

Quell'effetto chiaro/scuro ciclico potrebbe essere causato da minime differenze nella distanza tra le linee in Y. La cosa potrebbe essre imputata ad un difeto meccanico, tipo puleggia eccentrica del motore, o anche dal fatto che la posizione del motore intermedia tra un passo e l'altro non è sempre ripetibile. Una prova veloce sarebbe fare le line ad una distanza Y pari ad una numero intero di passi del motore. Quindi ipotizzando di usare la classica puleggia da 20 denti al netto dello stiro della cinghia fare una distanza tra le righe di 0,2 o multipli. Ora però mi sovviene che la tua laser è CoreXY, quindi probabilmente sto scrivendo ca...ate.

vorrei sbagliarmi ma quel'effetto li potrebbe anche essere un problema di posizione in Y del laser. Hai provato a dagli una risoluzione che sia un multiplo esatto di quella meccanica?

Purtroppo si può procedere solo per esclusione, ma come ti ripeto l'elettronica per scarsa che sia è l'ultima della lista per probabilità. Gli sforzi mecanici che puoi percepire muovendo a mano la cinemantica dell'estrusore montata sono di un ordine di grandeza superiore a quelli che possono causare problemi, in più muovere i motori collegati all'elettronica può danneggiarla. Se la stampante l'avessi sotto mano prima cosa smonterei i motori di X e Y, farei le pulizie, lubrificazioni e verifiche di tutti i componenti, poi procederei alla calibrazione di tutto, ma comprendo che può essere un approccio impegnativo. D'altro canto l'elettronica che monti non ha drive separabili, è una 8bit con ATmega1284P e quindi ha poco senso cercare di farci aggiornamenti. Puoi provare a verificare la Vref (non so come su quella scheda) che magari i potenziometri si sono ossidati ma l'unico altro intervento sensato e la sostituzione di tutto. Prima di procedere penso sia doveroso essere certi che non ci sia un problema meccanico.

Lascia stare il firmware, la perdita di passi è un problema prima meccanico, poi elettronico. Comincia a revisionare i carrelli, le ruote, le cinghie e soprattutto le pulegge delle cinghie. Poi si vede se e come verificare il funzionamento di motori stepper e scheda di controllo. Intendi che è un po che è ferma? Quanto?

Marlin incorpora la lettura del sensore come "impulsi di movimento" da qualche anno. Oltre ai normali settaggi va abiltata la definizione #ifdef FILAMENT_RUNOUT_DISTANCE_MM // Enable this option to use an encoder disc that toggles the runout pin // as the filament moves. (Be sure to set FILAMENT_RUNOUT_DISTANCE_MM // large enough to avoid false positives.) #define FILAMENT_MOTION_SENSOR #endif Non l'ho ancora provato ma un buon esempio di implementazione la puoi trovare in questa discussione:

Purtroppo no.. @john meglio che rivedi il montaggio delle cinghie. Sui rami dove scorre Y devono essere parallele e sicuramente NON devono torcersi.

A me questa cosa quì lo faceva il PLA Geetech con riempimenti fitti causa temperatura di estrusione troppo alta. Abbassato temperatura e velocità dell'infiill e si è sistemato. PLA/PETG Sunlu mai successo. Penso dipenda da quanto tira il materiale raffreddandosi. Alcuni sono peggio di altri

Guarda cosa hai scritto: LPC1768 e LCP1768 non è la stessa cosa

Non sempre. Va messo il nome nella sezione [env:... dei file ini indicati sotto extra_configs = che corrisponde alla scheda, e spesso la denominazione corrisponde al processore.

Veramennte con i file di configurazione di esempio della SBASE compila regolare: Difficile darti una risposta se non ci dai più informazioni.

Hai scelto un opzione sconosciuta al compilatore, per il resto sei troppo vago. Comincia a scrivere per quale stampante/scheda e cosa hai messo in default_envs = e #define MOTHERBOARD

Dopo aver cambiato la tensione alle cinghie andrebbero anche allentate e poi tirate le viti che fissano la traversa di X ai carrelli di Y, giusto per far assestare le ruote che altrimenti si possono rovinare. Magari lo sai ma meglio puntualizzare anche l'ovvio.

Dalla tensione delle cingie. Tiri più quella di un motore o dell'altro per raddrizzare il portale. Poi ovviamente la struttura non deve deformarsi e le vie di scorrimento di Y devono essere parallele, ma la perpendicolarità degli assi di una CoreXY dipende da come sono tirate le cinghie dentate.

Non parlo di giochi. Intendo che se muovi X (1) i carrelli che scorrono lungo Y (2) non devono andare ne aventi ne indietro. Il fenomeno si evidenzia soprattutto all'inversione del moto ed è causato dalla resistenza alla rotazione di una o più pulegge. Proprio quelle sui carrelli sono le più critiche.

Salvo un malfunzionemento interno dei drive, visto che i parametri dei TMC sono passati da Marlin il cambio drive vuol dire poco. Magari sei semplicemente troppo vicino al limite meccanico della tua macchina e ogni tanto il motore semplicemente non ce la fa a partire. Giusto per fare una prova abbassa jerk e accellerazione di Z (o i limiti della Junction Deviation) e vedi se il problema permane.

Vero ma forse non basta. Dall'ultima volta che ho compilato Marlin deve essere cambiata la gestione dei precorsi curvilinei. Se inaftti prima la sezione corrispondente era questa: ora è richiesta anche la variabile #define MM_PER_ARC_SEGMENT 1.0 senza la quale la compilazione non va a buon fine. Ho dato un occiata veloce ad alcuni dei file di configurazione negli esempi, tipo quelli della Ender 3, e la sezione indicata manca di questo valore, che è invecie presente nei file che scarichi con il firmware. Visto che gli errori di compilazione sono in genere indicati e ben documentati forse sarebbe il caso che @l0v3byte ci mostri anche il report di compilazione con i vari errori.