wildsharkg

Inversione fatta ma non c'è alcun cambiamento né nel sibilo, né nell'eccessivo surriscaldamento di X rispetto agli altri assi. Inviato dal mio iPhone utilizzando Tapatalk

Non ci ho ancora provato! Testo! Inviato dal mio SM-G930F utilizzando Tapatalk

Al momento non ho altri driver. Prima avevo quelli integrati nella scheda Anet 1.0 Inviato dal mio SM-G930F utilizzando Tapatalk

No, non li ho presi. Guardando le caratteristiche, questi mi sembravano essere i migliori. Inviato dal mio SM-G930F utilizzando Tapatalk

Ho comunque provato ad invertire i fili ma il motore non si è mosso. Sono ritornato al cablaggio precedente ma resta il "fischio" ed il motore dell'asse X bollente. Ora sono con la corrente a 500 impostata su Marlin (se scendo sotto l'asse non si muove). Cosa posso provare per migliorare questo inconveniente?

Rivedendo gli schemi ho ricostruito l'ordine corretto (come sono montati attualmente): Polarità A+ B+ A- B- PIN Motore 1 3 4 6 Colore Cavo Blu Verde Rosso Nero PIN SKR1.4 A2 B2 A1 B1 PIN Driver 1B 1A 2B 2A La mia opinione è che non vada invertito nulla. Chiedo un vostro qualificato parere.

Grazie per l'ottimo spunto! Ti confermo che, non trovando nulla, ho testato i pin del motore con il multimetro: il grafico che hai postato è esattamente quello dei miei motori (originali venduti con la Anet A8 Plus), ovvero: il cavo Blu è abbinato con il Rosso il cavo Verde è abbinato con il Nero Quindi devo effettivamente invertire tutti i cavi verdi con i rossi! Penso di farlo sui connettori della scheda madre. Non mi resta che fare qualche prova.

Sto approfondendo anche il tema "rumore bianco" dei motori. Ho trovato una serie di risorse che parlano di variare le impostazioni in 2 parti di Marlin, per fare il tuning di SpreadCycle: https://3dwork.io/en/complete-guide-skr-v1-4-and-tmc2209 https://marlinfw.org/docs/hardware/tmc_drivers.htm /** * Optimize spreadCycle chopper parameters by using predefined parameter sets * or with the help of an example included in the library. * Provided parameter sets are * CHOPPER_DEFAULT_12V * CHOPPER_DEFAULT_19V * CHOPPER_DEFAULT_24V * CHOPPER_DEFAULT_36V * CHOPPER_PRUSAMK3_24V // Imported parameters from the official Prusa firmware for MK3 (24V) * CHOPPER_MARLIN_119 // Old defaults from Marlin v1.1.9 * * Define you own with * { <off_time[1..15]>, <hysteresis_end[-3..12]>, hysteresis_start[1..8] } */ #define CHOPPER_TIMING CHOPPER_DEFAULT_24V comincio a sperimentare e vi dico.

Stavo giusto cercando il foglio dati motore ma sembra non esistere. bella sfida!

Cerco di essere più preciso, grazie ai tuoi consigli: La piedinatura del BTT TMC2130 v3 è la seguente (diversa da quella inserita nel mio precedente post che era di un'altra versione/produttore evidentemente) Quindi, confermando l'ordine in cui sono collegati i fili, allo stato il mio cablaggio è il seguente: 2B -> Nero -> D 1B -> Verde -> C 1A -> Blu -> A 2A -> Rosso -> B Ovvero, nell'ordine che mi hai proposto: 1A Blu A 1B Verde C 2A Rosso B 2B Nero D Mi sembra di capire che dovrei invertire tutti i cavi verdi con i rossi, right? Ma come è possibile che funzioni tutto ugualmente?

Ammetto di essere alle prime armi, sto approfittando di questa discussione per imparare. Ho riverificato tutti i cablaggi, tutti i motori hanno un pin a 6 uscite, di cui non vengono usati solo il 2 ed il 5 come desumibile da questa immagine: Ho quindi controllato i cavi, tutti sono connessi ai motori nell'ordine Blu, Verde, Rosso, Nero. Tutti sono connessi alla scheda madre nell'ordine Nero, Verde, Blu, Rosso. Inoltre mi sembra, confrontando i pinout dei driver 2209 e 2130, che abbiano gli stessi pin per le connessioni ai motori: Mi confermate che non sto sbagliando nulla?

Avevo seguito questa procedura: VREF = (RMSCurrent x 2,5 ) / 1,77 Il modello degli stepper motor è 42SHDC3025-24B che hanno i seguenti parametri: Rated current 0.9A <---Il dato che ci interessa per la formula Per ottenere la RMSCurrent dalla Massima, basta dividerla per 1,41 quindi: RMSCurrent = 0,9 / 1,41 = 0,638 La mia formula, quindi è: VREF = 0.638 x 2,5 / 1,77 = 0,90 Di cui ho impostato solo il 90%, pari a 0,811 come spiegato qui: https://www.youtube.com/watch?v=OUadiW5QLBE

il sito di caggius era stato uno dei miei riferimenti per il ricablaggio, infatti a questa pagina https://caggius.wordpress.com/anet-a8-rewiring-for-skr1-3/ viene specificato che non c'è bisogno di fare modifiche (solo che lui usa i TMC2209 e non i TMC2130): Adesso provo ad abbassare la VREF a 256mA (invece di 700) per i motori x e Y, mi confermate che le voci da interessare sono X_CURRENT e Y_CURRENT ? #if HAS_TRINAMIC_CONFIG #define HOLD_MULTIPLIER 0.5 // Scales down the holding current from run current #define INTERPOLATE true // Interpolate X/Y/Z_MICROSTEPS to 256 #if AXIS_IS_TMC(X) #define X_CURRENT 700 // (mA) RMS current. Multiply by 1.414 for peak current. #define X_CURRENT_HOME X_CURRENT // (mA) RMS current for sensorless homing #define X_MICROSTEPS 16 // 0..256 #define X_RSENSE 0.11 #define X_CHAIN_POS -1 // <=0 : Not chained. 1 : MCU MOSI connected. 2 : Next in chain, ... #endif #if AXIS_IS_TMC(Y) #define Y_CURRENT 700 #define Y_CURRENT_HOME Y_CURRENT #define Y_MICROSTEPS 16 #define Y_RSENSE 0.11 #define Y_CHAIN_POS -1 #endif

il codice dei motori è 42SHDC3025-24B che hanno i seguenti parametri: Holding Torque 40 N·cm Rated voltage 3.96 V Shaft Ø 5 mm Single Step angle 1.8° Motor length 40 mm Rated current 0.9A Per quanto riguarda i cavi non ho fatto alcuna variazione rispetto a quelli già previsti sulla scheda madre Anet originale:

Mi sembrava di aver risposto a tutte, quali mi sono perso? Inviato dal mio SM-G930F utilizzando Tapatalk

i motori hanno tutti lo stesso codice, M569 mi restituisce: X driver mode: spreadCycle Y driver mode: spreadCycle Z driver mode: spreadCycle E driver mode: spreadCycle Dici che estrude troppo? Intanto permane questo fischio/sibilo/rumore bianco sul solo motore dell'asse X, avete idee?

Intanto vi rinnovo i miei ringraziamenti per i consigli. Nelle mie continue ricerche mi sono imbattuto in questo post che mi sembra essere analizzare il mio problema (parlano anche qui di asse Y): https://github.com/MarlinFirmware/Marlin/issues/9487 e suggerivano di abbassare sotto i 1000 anche la DEFAULT_MAX_ACCELERATION Ad ogni modo ho prima cominciato con le prove richieste da Whitedavil usando pronterface ed ho notato durante la stampa numerosi errori di surriscaldamento dei driver già nei primi layer, e la corrente dei driver veniva progressivamente abbassata da 811, valore iniziale, ai valori che credevo invece di aver impostato. Ve li riporto: 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) 00:11: X driver overtemperature warning! (811mA) X current decreased to 761 X current decreased to 711 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) 00:15: Y driver overtemperature warning! (811mA) Y current decreased to 761 Y current decreased to 711 A seguire, inoltre, il report del M122 dopo la stampa (qui non ci sono più gli errori di temperatura perchè intanto avevo abbassato la corrente con il comando "M906 X700 Y700": SENDING:M122 X Y Z E Enabled false false false false Set current 650 650 811 811 RMS current 642 642 795 795 MAX current 905 905 1121 1121 Run current 20/31 20/31 25/31 25/31 Hold current 10/31 10/31 12/31 12/31 CS actual 10/31 10/31 12/31 12/31 PWM scale 60 103 21 35 vsense 1=.18 1=.18 1=.18 1=.18 stealthChop true true true true msteps 16 16 16 16 tstep max max max max PWM thresh. [mm/s] OT prewarn false false false false triggered OTP false true false false off time 3 3 3 3 blank time 24 24 24 24 hysteresis -end -1 -1 -1 -1 -start 1 1 1 1 Stallguard thrs 0 0 0 0 DRVSTATUS X Y Z E sg_result 0 0 0 0 stallguard fsactive stst olb ola s2gb s2ga otpw ot Driver registers: X 0x80:0A:00:00 Y 0x80:0A:00:00 Z 0x80:0C:00:00 E 0x80:0C:00:00 Testing X connection... OK Testing Y connection... OK Testing Z connection... OK Testing E connection... OK La lettura dei risultati del M122 mi ha messo una pulce nell'orecchio ed ho cercato di approfondire come mai, in tutti questi giorni di tuning, le stampe mi sembravano tutto sommato sempre le stesse. Ho rilevato che lo stealthchop era ancora su "True". Si tratta di dati che ovviamente non mi aspettavo in quanto avevo ricompilato correttamente il firmware. Poi ho fatto mente locale ed ho approfondito il tema EEPROM. In una delle mie prime prove avevo infatti memorizzato tutte le impostazioni con M500. Ho capito solo ora che andava fatto un bel reset con M502 per fare in modo che le modifiche apportate al firmware compilato venissero lette come quelle di default. Google mi rincuora: Ho quindi ricompilato, ripartendo dalle prime modifiche suggerite: disattivazione dello StealthChop e riduzione della velocità di stampa. Ho riportato i valori iniziali di X_CURRENT a 811 (calcolato con la formula per i TMC2130) e di DEFAULT_MAX_ACCELERATION a 2000. La stampa è venuta quasi perfetta (per i miei parametri), ho quindi solo abbassato la corrente di X e Y a 700 perchè gli errori di overtemperature erano ancora presenti. Ecco a voi l'ultimo M122: SENDING:M122 X Y Z E Enabled false false false false Set current 700 700 811 811 RMS current 673 673 795 795 MAX current 949 949 1121 1121 Run current 21/31 21/31 25/31 25/31 Hold current 10/31 10/31 12/31 12/31 CS actual 10/31 10/31 12/31 12/31 PWM scale 0 0 0 0 vsense 1=.18 1=.18 1=.18 1=.18 stealthChop false false false false msteps 16 16 16 16 tstep max max max max PWM thresh. [mm/s] OT prewarn false false false false triggered OTP false false false false off time 3 3 3 3 blank time 24 24 24 24 hysteresis -end -1 -1 -1 -1 -start 1 1 1 1 Stallguard thrs 0 0 0 0 DRVSTATUS X Y Z E sg_result 359 0 176 292 stallguard * * * * fsactive stst olb ola s2gb s2ga otpw ot Driver registers: X 0x81:0A:01:67 Y 0x81:0A:00:00 Z 0x81:0C:00:B0 E 0x81:0C:01:24 Testing X connection... OK Testing Y connection... OK Testing Z connection... OK Testing E connection... OK Grandissimi passi avanti oggi! (scusate se mi sono dilungato ma spero che la mia esperienza possa essere utile a qualcun'altro) Vi chiedo a questo punto cosa posso fare per eliminare le imperfezioni che si vedono nelle foto qui sotto ma soprattutto come mai, pur non ricevendo alcun errore di temperatura del driver, il motore dell'asse X resta davvero MOLTO caldo e sembra che "fischi" o - meglio - "sibili".

Si, anche togliendo lo StealthChop sono roventi (così come i dissipatori dei driver 2130).

Il primo Gcode che avevo provato era un coperchio se non vado errato ma aveva sempre lo stesso problema: Eccovi i miei configuration. Non mi sembra ci siano problemi meccanici di scorrimento dell'asse Y. Configuration.h Configuration_adv.h

Rieccomi, ho provato entrambe le soluzioni proposte: 1. Ridotto le velocità di stampa (come da schermata), ottenendo i cubi 2 e 3; 2. Disabilitato lo StealthChop, ottenendo il "cubo" 4. il n.1 era quello del primo post. Cos'altro posso provare? Non posso non notare una certa sistematicità nella posizione dei livelli, ma non capisco a cosa possa essere dovuta. 😪

Il mio prossimo acquisto è la ventola, soprattutto con questo caldo (di solito stampo sul balcone, ma il cubo l'ho stampato in casa con l'aria condizionata accesa). Ad ogni modo nel frattempo proverò con i vostri consigli (riduzione velocità di stampa, disattivazione Stealthchop) di cui vi ringrazio. Quindi pensate anche voi che che non si tratta di un problema hardware o firmware?

Prima avevo la 8bit nativa, tutti i driver hanno i dissipatori, non sono ancora riuscito a mettere una bella ventola per un raffreddamento attivo. La spreadcycle sarebbe troppo rumorosa, preferirei evitarla, ma se mi dici che risolvo ci provo volentieri!

Dici che può essere anche quella? con la vecchia scheda, anche con velocità più alte, non ho mai avuto questi problemi. Pensi che passando alla modalità mista "HYBRID THRESHOLD" potrei risolvere? Ora sono solo in STEALTHCHOP

"Macello Totale" non mi fa ben sperare 😟 il modello degli stepper motor è 42SHDC3025-24B (quelli standard della Anet A8 plus), Le velocità di stampa che avevo impostato sono in allegato Se spingo gli assi con le mani sento una restistenza piuttosto marcata, ma anche con la vecchia scheda era così e non ho mai avuto questo tipo di problemi (a tal proposito ho sostituito i cuscinetti standard con gli Igus LM8UU).

Ho effettuato alcune ricerche infruttifere sul sito, quindi vi chiedo un supporto (se il problema è già stato affrontato, vi prego di segnalarmelo). Ho di recente eseguito un upgrade della scheda madre della mia Anet A8 Plus sostituendola con una SKR 1.4 turbo con abbinati 4 driver TMC2130. Dopo aver superato le molteplici rimappature dei cavi, ed aver rinunciato per ora al sensorless homing per problemi che al momento non sono ancora riuscito ad approfondire, ho cominciato con le solite stampe di prova ma ho rilevato - mio malgrado - un pesante layer shifting di cui riporto le foto in allegato. Mi sembra, ma potrei sbagliarmi, che il problema riguardi solo l'asse Y. Ho cercato molto, anche su github dove vengono segnalati problemi legati ai driver, ma sinora nulla che mi abbia chiarito cosa fare per risolvere. Premetto che ho anche abbassato a 600 i milliAmpere dei driver prima di stampare il cubo di calibrazione alla voce: #define X_CURRENT 600 // (mA) RMS current. in quanto il motore X era diventato "rovente". Sto ipotizzando anche un problema meccanico sui binari Y (che ingrasso costantemente) ma la parte centrale del cubo perfettamente allineata porta a scartare questa ipotesi. Grazie in anticipo.