albemasci

Ciao a tutti! Dopo aver smanettato un po' coi settaggi della stampante che ho finito di programmare qualche giorno fa, risolvendo per ora i più comuni difetti di stampa, sono arrivato a un punto morto. In sostanza, sulle pareti dell'abitacolo della benchy, mi appare una sorta di motivo a righe diagonali; inoltre, gli angoli dell'abitacolo, non sono regolari accanto all'oblò. Per adesso sto lavorando a layer alti 0.2. Allego foto: Sapete indicarmi cosa potrebbe causare questi problemi?

Grazie del suggerimento! Se mi addentrerò in questa avventura, poi vi posto i risultati! 😁

Ottimo! sai dirmi il modello dello stepper? Almeno do un'occhiata alle caratteristiche e mi faccio un'idea! Ad ogni modo, con il passo delle viti dovrei impostare molti steps/mm per ottenere buone velocità; magari i motori ci riescono comunque, ma non sono certo sia un modo efficiente di usare gli stepper: a quanto leggevo su internet, sembrerebbe che gli stepper per loro natura siano più efficaci a gestire alte forze di torsione piuttosto che alte velocità. Nella mia piccolissima esperienza, un po' tutti gli stepper perdono passi con l'aumentare della velocità, cosa che sembrerebbe confermare quello che ho letto. Per questo volevo un "riduttore" (che poi non credo sia propriamente un riduttore, in quanto fa il contrario, ma non saprei proprio come chiamarlo, non sono esperto.. 😁) che faccia corrispondere più rotazioni a una singola rotazione dello stepper motor. Non so se mi sono spiegato..

Certo, sicuramente una sls o sla sarebbe un modo più efficiente di spendere soldi se l'unico obiettivo fosse il risultato.. Ma hai detto bene, per me è un hobby, e il divertimento nella progettazione e costruzione sono sul piatto della bilancia! 😁 Se sai indicarmi siti tipo RS con prezzi non hobbistici, anche solo per curiosità, sono tutto orecchie!

Interessante, me lo immaginavo ma non lo sapevo! Avevo solo visto le CNC... mi diresti qualche modello, così magari guardo meglio come sono fatte e mi faccio un'idea? Concordo, molto probabilmente non ne vale la pena.. ma ero curioso di vedere dove andavo a cadere con i costi: penso sia un meccanismo più preciso rispetto alle classiche cinghie/pulegge, non avendo il problema della, seppur piccola, flessibilità delle cinghie. Visti, ma anche in questo caso li ho trovati solo con rapporti che diminuiscono la velocità in favore della coppia! Ma forse non so io dove cercare, ho guardato solo su aliexpress, ebay e banggood! Qualche dritta su dove guardare?

Un esperimento! Vorrei progettare una stampante 3d con tutti gli assi che si spostano tramite viti a ricircolo di sfere! Il "riduttore" mi serve perché gli step/mm necessari sarebbero troppo alti, e sicuramente i motori perderebbero passi..

Qualcuno sa se esistono dei "riduttori" (gearbox) per motori passo passo che diminuiscano la coppia in favore della velocità? Se si, dove posso trovarli? Ne ho trovate solo che fanno l'inverso..

Credo che N/m stia a significare il momento angolare a distanza di un metro, quindi la conversione dovrebbe essere 12.7N/cm=0.127N/m Non voglio sbilanciarmi sul motore adatto o meno per l'estrusore, credo che sia sufficiente ma lascio ai più esperti la sentenza! 😀

Grazie mille, Alep, non solo per aver risolto il problema, ma anche per la spiegazione interessante e utilissima sull'EEPROM! 🙂

Ciao a tutti! Ho voluto fare un test cambiando una puleggia alla stampante. Fatta l'operazione, ho modificato gli steps/mm nel firmware (Marlin 2.0): era impostato su 200 (puleggia da 16, cinghia gt2, 1/32 di passo), quindi avendo messo una puleggia da 20 ho portato a 160. Questa è l'unica stringa su cui ho messo le mani: #define DEFAULT_AXIS_STEPS_PER_UNIT { 200, 160, 800, 838 } In sostanza, dopo averlo flashato, non cambia niente! Gli steps/mm mi restano a 200. Ho provato altri valori per sicurezza, e stesso risultato. Preciso che sto usando una MKS Sbase 1.3 e uno stepper esterno per l'asse Y. P.S. ho provato a lanciare un M502 (factory reset) da pronterface prima di effettuare l'ultimo flash, con lo stesso risultato!

manualmente si muove correttamente, e non rileva l'endstop attivato (verificato da pronterface con comando M119). In realtà, ho risolto il problema... cambiando scheda madre! 😀 Sarò io che non sono esperto, ma la mia esperienza con la minitronics 2.0 è stata pessima! Fortunatamente avevo una vecchia MKS Sbase 1.3, che ho programmato con relativa facilità con Marlin 2.0. Peraltro, i motori si muovono molto più silenziosamente senza che abbia fatto niente.. meglio così 😀 Grazie mille, in ogni caso, a tutti! 🙂

... Nessuno ha idee? Io ho riletto tutto, ma non riesco proprio a capire dove possa aver sbagliato, e non so più cosa provare.. 😔

Grazie mille per la risposta Alep, persino la notte! 😁 Purtroppo mi risultano tutti "not triggered".. E purtroppo non posso fare un homing solamente dell'asse Z perché ho attivato l'opzione Safe Homing: il mio piano di stampa non si estende fino al sensore quando gli assi x e y sono sul finecorsa, e con safe homing dovrebbe spostare la sonda in un punto predefinito (nel mio caso il centro del piano).. Questi sono i parametri che ho impostato (in realtà erano già pronti così, ho solo decommentato): #define Z_SAFE_HOMING #define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2) #define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2) Di fatto, chiedendo un homing di tutti gli assi, la stampante fa questo: Homing dell'asse x (corretto) Homing dell'asse y (corretto) Spostamento del sensore al centro del piano di stampa (corretto) FINE. Semplicemente la stampante, a quel punto, non esegue l'homing dell'asse Z come dovrebbe! Nessun movimento né verso l'alto né verso il basso. Ho provato a spostare manualmente l'asse Z affinché dopo, con spostamenti verso l'alto, risultasse alla stampante che l'asse è sopra lo zero. Stesso risultato.. 😖

Ciao a tutti, Sto installando una minitronics 2.0 (come alcuni di voi sanno bene, avendoli già torturati con i miei post di troubleshooting. E a proposito, grazie ancora a tutti per l'aiuto!) Il problema è questo: quando eseguo un homing, Gli assi X e Y eseguono l'homing correttamente, ma dopo l'asse z resta fermo. L'asse Z funziona correttamente, e lo stesso vale per la sonda a induzione che utilizzo (lanciando il comando M119 per vedere lo stato degli endstop, risulta "Not Triggered", e avvicinandola al piano di stampa diventa "Triggered". Ho provato ad abassare il feedrate dello Z homing fino a 2mm/s: niente, asse immobile. Con pronterface o da monitor, invece, risponde perfettamente ai comandi di movimento.. Ho la sensazione che sia una sciocchezza, ma non riesco a trovare il problema.. Qualcuno sa aiutarmi?

Di rientro dalle vacanze, ho avuto modo finalmente di rimettere le mani sulla scheda! Leggendo quello che mi hai inviato, e sbirciando al volo su internet, mi sembra di aver capito che non sia niente di problematico, salvo il rumore! Quindi ho pensato di ignorare la cosa, almeno per ora ma forse anche per sempre: il rumore non è un problema per me. Piuttosto, è sorto un problema ben maggiore! 😖 A qualsiasi VREF (da 0,5V a 1,2V), e con gli stepstick ben raffreddati, sembra che i motori vogliano ignorare gli spostamenti di oltre 10mm per volta. Semplicemente si fermano come se stessero perdendo passi! Però, almeno nella mia esperienza, in caso di perdita di passi, il movimento viene interrotto e poi riprende. Qui proprio cessa! Questo accade, ad esempio, se richiedo un homing dell'asse X: Il motore si sposta di poco verso il finecorsa, poi si ferma. La cosa assurda è che a 0,5V e a 1,2V non noto assolutamente nessuna differenza! Ho controllato i finecorsa da repetier, e risultano correttamente "not triggered" normalmente e "triggered" se premuti... EDIT: Ho risolto! Ho disabilitato la disabilitazione degli assi in disuso (scusate il gioco di parole) agendo su queste stringhe: #define DISABLE_X false #define DISABLE_Y true #define DISABLE_Z false #define DISABLE_E false Ho mantenuto Y, dato che funzionava bene (uso uno stepstick diverso per quello)! Ho poi risolto il problema del ronzio prolungato, agendo su questo parametro: #define DEFAULT_STEPPER_DEACTIVE_TIME 1 che prima era settato a 120 (secondi). In questo modo, dopo un secondo il ronzio cessa. Spero possa essere d'aiuto a qualcuno, grazie ancora per l'aiuto @FoNzY! Albe.

Di rientro dalle vacanze, ho avuto modo finalmente di rimettere le mani sulla scheda! Leggendo quello che mi hai inviato, e sbirciando al volo su internet, mi sembra di aver capito che non sia niente di problematico, salvo il rumore! Quindi ho pensato di ignorare la cosa, almeno per ora ma forse anche per sempre: il rumore non è un problema per me. Piuttosto, è sorto un problema ben maggiore! 😖 A qualsiasi VREF (da 0,5V a 1,2V), e con gli stepstick ben raffreddati, sembra che i motori vogliano ignorare gli spostamenti di oltre 10mm per volta. Semplicemente si fermano come se stessero perdendo passi! Però, almeno nella mia esperienza, in caso di perdita di passi, il movimento viene interrotto e poi riprende. Qui proprio cessa! Questo accade, ad esempio, se richiedo un homing dell'asse X: Il motore si sposta di poco verso il finecorsa, poi si ferma. La cosa assurda è che a 0,5V e a 1,2V non noto assolutamente nessuna differenza! Ho controllato i finecorsa da repetier, e risultano correttamente "not triggered" normalmente e "triggered" se premuti...

Purtroppo non posso provare subito.. appena riesco ti dico. Grazie in anticipo! 😁

Non sono riuscito a recuperare quella versione.. Fai così: Scaricati Pronterface, avvialo e connetti la tua stampante. Poi clicca su "Connect". Quindi, in fondo a destra, accanto a "Send", dovresti avere uno spazio per scrivere. Scrivi M119 e poi clicca Send. Sopra dovrebbe restituirti una cosa di questo genere: x_min: NOT TRIGGERED y_min: TRIGGERED Questo è come si lancia il comando M116. Anche cura dovrebbe avere un programma di comunicazione con la stampante, ma non trovando quella versione non sapevo come aiutarti a trovarla.. Se dopo aver fatto quel test leggi appunto che Y è TRIGGERED, prova a premere manualmente il finecorsa e rilancia M119, vedi se stavolta ti dice che Y è NOT TRIGGERED. in quel caso devi invertire la logica di quel finecorsa agendo sul firmware. Avendo però tu trovato la scheda già pronta, dovrai trovare su internet il firmware precompilato per la tua stampante. La Anet A8 è molto diffusa, dovresti trovarlo con facilità! Una volta ottenuto, scaricati il programma Arduino IDE (e installalo). Quindi apri il file marlin.ino che troverai all'interno delle cartelle del firmware, ti aprirà il file con Arduino IDE. Dovresti vedere una cosa del genere: Clicca su "configuration.h", quindi avvia la funzione di ricerca premendo Ctrl+F e ricerca "MIN_ENDSTOP_INVERTING". Basta che scambi le scritte "true" con "false" e viceversa, per cambiare la logica degli endstop. Tu sei interessato all'Y_MIN. Una volta fatto questo, dovrai semplicemente il bottone con la spunta "v" per verificare il software. Se non hai commesso errori, sul nero non dovrebbero comparirti messaggi di errore. A quel punto verifica da "strumenti" che la "porta" sia quella dove hai connesso la stampante, e se è quella premi sulla freccia accanto alla spunta per effettuare l'upload del firmware. FATTO! A quel punto verifica che a M119 ti risulti tutto not triggered, in quel caso hai risolto il problema!

Tranquillo, nessun problema! 😀 Che versione di cura hai?

Ciao a tutti, ho cambiato scheda madre da poco a una mia stampante, e dopo aver risolto buona parte dei problemi di compilazione, finalmente sono riuscito a superare il sanitycheck. Il firmware è MK4Duo, la scheda una minitronics 2.0. La scheda monta i DRV8825, ma per l'asse y uso uno stepper esterno, un TB6600, per avere più potenza (il piano di stampa è un po' peso). In sostanza, quando i motori X, Z ed E sono abilitati, emettono un ronzio forte. Gli steps/mm sono a posto, i motori si muovono esattamente quanto dovrebbero, ma c'è questo ronzio che cessa solo quando i motori si disabilitano. Se richiedo un movimento più ampio di 10mm (es. 40mm), avviene che i motori restano abilitati per un paio di minuti, rendendo gli assi non spostabili manualmente per quel tempo. Quando i motori sono abilitati, il ronzio non cessa mai! Passati questi minuti, quando i motori si sbloccano cessa anche il ronzio. Anche con il ronzio, i movimenti richiesti continuano ad avvenire correttamente. Ho impostato una stringa per disabilitare immediatamente i motori dopo un movimento, risolvendo così il problema temporaneamente. Ma questo ronzio lo posso ignorare? L'asse Y funziona alla perfezione (stepper driver esterno). Non so se è rilevante, ma lo stepper esterno utilizza un pin di ENABLE personale, mentre x, z ed e hanno lo stesso pin di enable in comune. Ho settato la VREF a 1.2 (i motori sono da 2,5A), quindi dovrebbe essere corretta. In ogni caso, ho provato ad abbassare sull'asse Z la Vref, anche drammaticamente (0.6, considerando che è divisa su due motori) e il ronzio è identico. Ecco come ho impostato i parametri dal firmware (ve li prendo in ordine sparso e da vari config): #define X_DRIVER_TYPE DRV8825 #define Y_DRIVER_TYPE TB6600 #define Z_DRIVER_TYPE DRV8825 #define E0_DRIVER_TYPE DRV8825 #define MINIMUM_STEPPER_PULSE 3UL #define MAXIMUM_STEPPER_RATE 150000 #define DIRECTION_STEPPER_DELAY 0 // (ho provato anche 650 e 1500, senza risultati) //#define ADAPTIVE_STEP_SMOOTHING //(ho provato ad attivarlo, senza risultati) #define INVERT_X_STEP_PIN false // (ho provato con true, senza risultati) #define INVERT_Y_STEP_PIN false #define INVERT_Z_STEP_PIN false #define INVERT_E_STEP_PIN false Aiutino? 🙏

Tranquillo, ti aiuto volentieri se riesco! 😀 Dunque, tu hai usato Arduino IDE per caricare il firmware nella stampante? Oppure la scheda aveva il firmware già caricato e ci hai solo connesso i fili? Intanto ti direi di fare una prova: Lancia il M119 premendo l'endstop, e verifica se te lo considera triggered o open. Se te lo considera OPEN devi davvero modificare il firmware (tranquillo, è molto più semplice di quanto sembri). Se invece continua a considerarlo TRIGGERED, probabilmente lo hai cablato male!

Domenico, prova da pc a lanciare il comando M119: dovrebbe darti come risultato lo stato degli endstop. Se sono "open", è tutto regolare e il problema è da cercare altrove. Se sono "Triggered", allora come ha detto Fonzy il problema è quello (la stampante crede che gli assi siano al finecorsa, vedendoli attivati, quindi non permette ai motori di muoversi verso i finecorsa). In quel caso, risolvi invertendo la logica dei finecorsa modificando il firmware: in config.h modifichi "X_MIN_ENDSTOP_INVERTING = false" con true, e fai lo stesso per Y_MIN. Se fosse già su true metti false.

Aggiornamento: FORSE ho risolto. Ho sostituito il BLTouch con un sensore induttivo e relative modifiche al codice (sparito l'errore #error "Unsupported Platform!"). Forse la scheda non lo supporta! Ho inserito di nuovo manualmente il pin dello Z_Probe, e stavolta ha funzionato (Sparito l'errore #error "DEPENDENCY ERROR: A probe needs a pin! Use Z_MIN_PIN or Z_PROBE_PIN."). Ho sostituito un file incluso nel firmware fornito da reprapworld relativo alla mia scheda con quello originale di MK4Duo, ottenuto direttamente dal sito di marlinkimbra (sparito l'errore error: #endif without #if #endif /* _VECTOR_3_H_ */). A occhio, mi sembra che quest'ultimo non avesse semplicemente un #endif alla fine. Avevo anche provato ad aggiungere all'originale un #ifndef VECTOR_3_H_ ottenendo però altri errori. Fatto l'upload sulla scheda, devo risolvere dei problemi agli stepper motor (si muovono correttamente ma emettono un forte ronzio), a quel punto avvierò una stampa e vedrò se tutto va bene: il file che ho sostituito con l'originale era relativo al livellamento automatico, quindi posso sapere se è tutto corretto solamente con una stampa (con livellamento) ben riuscita! Segnalo anche ai possessori di Minitronics 2.0 che i pin sono totalmente sbagliati. Anche se scaricate la libreria, alle voci "Original_pincopallino_pin" non corrispondono i pin effettivi. Ho dovuto riscrivere singolarmente ogni pin per far funzionare tutto!

Ho fatto un test: ho provato a definire la stampante come una corexy, senza toccare il file config delle corexy. Teoricamente, se il problema fosse stato il processore, avrebbe dovuto darmi comunque errori e problemi; invece, nessun errore di compilazione! Ho anche provato a flashare, e funziona pure lo schermo! Quindi posso definitivamente ignorare il primo messaggio della libreria U8Glib. La mia sensazione è che il nucleo del problema sia questo: Il punto è che io credo di averlo definito, perché su Configuration_Pins ho questo: // ENDSTOP pins #define X_MIN_PIN ORIG_X_MIN_PIN #define X_MAX_PIN ORIG_X_MAX_PIN #define Y_MIN_PIN ORIG_Y_MIN_PIN #define Y_MAX_PIN ORIG_Y_MAX_PIN #define Z_MIN_PIN ORIG_Z_MIN_PIN #define Z_MAX_PIN ORIG_Z_MAX_PIN #define X2_MIN_PIN NoPin #define Y2_MIN_PIN NoPin #define Z2_MIN_PIN NoPin #define Z3_MIN_PIN NoPin #define X2_MAX_PIN NoPin #define Y2_MAX_PIN NoPin #define Z2_MAX_PIN NoPin #define Z3_MAX_PIN NoPin #define Z_PROBE_PIN ORIG_Z_MIN_PIN #define SERVO0_PIN 25 Ho provato anche con ORIG_Z_PROBE_PIN, con il numero del pin... niente. ho provato a usare il configuratore online di marlin/kimbra con una scheda fittizia (il configuratore online non supporta la mia), specificando che ho un bltouch, poi ho studiato il Configuration_Pins per capire se sbagliavo qualcosa nel codice, ma sembra tutto ok... Forse non è così che comunico al codice il pin della sonda! Idee..?

Grazie per la risposta, Alep! Se ti riferisci a questo: In realtà credo sia ignorabile. Dovrebbe essere solo riferito alla libreria del monitor (U8glib), che però garantiscono funzionare con questa libreria e con questa scheda. Sono gli altri 3 i problemi che non riesco bene a comprendere o a correggere.. Se invece ho capito male io cosa intendevi, correggimi pure 😀