MK 4.3.6 ultima versione non va, ok versioni più vecchie

So che è una versione vecchia ad oggi e magari non c'è più supporto ma segnalo un problema presente nelle ultime versioni.

Sulla mia stampante 3DRag con ArduinoMega + Ramps + TMC2130 (in SoftSPI) l'ultima versione si blocca nello schermo di logo e da lì non va avanti.
A livello di log seriale l'ultima cosa che vedo è un errore (normale) di eeprom versione cambiata e poi null'altro.

Però se uso i sorgenti di Agosto (Revision 10082018), stessa config funziona perfettamente.

Questo problema l'ho notato già a partire da Settembre o Ottobre, ma prima non ero iscritto al forum e non potevo segnalarlo.

Edited 1 time(s). Last edit at 03/17/2019 02:10PM by FabryR.

Allora prima cosa fai un bel erase della eeprom, cerca su google uno sketch per arduino mega lo scarichi e cancelli tutto. Secondo sono cambiate le librerie tmc2130 che non faccio io quindi non so se vanno ancora e come vanno con il software SPI..

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ma le librerie una volta cambiate non rimangono le stesse per tutte le compilazioni ?

La 4.3.6 versione di agosto (e sempre in softSPI) funziona
La 4.3.6 versione definitiva non va
La 4.3.7 funziona (pochi test, comunque parte)
La 4.3.8 funziona (a parte il problema segnalato nell'altro thread)

La versione 4.3.6 sua la libreria TMC2130, mentre la 4.3.8 la TMCstepper che ha tutti i driver, non sono le stesse..

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ok la libreria TMC2130 si è aggiornata mesi fa (ora è v2.5) però conta anche come il codice 4.3.6 chiama le funzioni.

Perché se compilo la 4.3.6 di Agosto oggi (e quindi usando la nuova libreria) ottengo un firmware che parte, se compilo l'ultima revision ottengo un fw che si blocca all'avvio (probabilmente sul codice TMC, o magari su altro)

Comunque appena ricompilato 20 min fa le due versioni (a pari IDE ed a pari TMC2130 v2.5), una parte regolarmente (la versione di Agosto) con questo log:

Quote

start
Info:Echo:MK4duo_4.3.6
Echo:Last Updated: Aug 19 2018 23:19:48 | Author: (none, default config)
Echo:Compiled: Aug 19 2018
Echo:Free Memory: 2771 PlannerBufferBytes: 1456
SD card ok
MKV50 stored settings retrieved (330 bytes; crc 26228)
Config:
G21 ; Units in (mm)
Configteps per unit:
Config: M92 X80.000 Y80.000 Z2560.000 T0 E600.000
Config:Maximum feedrates (units/s):
Config: M203 X300.000 Y300.000 Z2.000 T0 E100.000
Config:Maximum Acceleration (units/s2):
Config: M201 X1500 Y1500 Z50 T0 E3000
Config:Acceleration (units/s2): P V T* R:
Config: M204 P3000.000 V3000.000 T0 R10000.000
Config:Advanced variables: B S V:
Config: M205 B20000 S0.000 V0.000
Config:Junction Deviation: J:
Config: M205 J0.050
Config:Heater Sensor parameters: H P A B C R L O:
Config: M305 H0 P13 A100000.0 B4725.0 C0.0000000000 R4700.0 L0 O0
Config:Heater parameters: H P A B C L O U I:
Config: M306 H0 P10 A40 B230 C255 L5 O275 U1 I0
Config:Heater PID parameters: H P I D:
Config: M301 H0 P22.20 I1.08 D114.00
Config:Heater Sensor parameters: H P A B C R L O:
Config: M305 H-1 P14 A100000.0 B4725.0 C0.0000000000 R4700.0 L0 O0
Config:Heater parameters: H P A B C L O U I:
Config: M306 H-1 P8 A80 B255 C255 L5 O150 U0 I0
Config:Fans: P U L F I H :
Config: M106 P0 U9 L0 F250 I0
Config: M149 C ; Units in Celsius
Config:Material heatup parameters:
Config: M145 S0 H190 B60 F255
Config: M145 S1 H240 B100 F255
Config: M145 S2 H230 B60 F255
Configtepper Direction:
Config: M569 X1 Y1 Z1 T0 E0
Configtepper driver control:
Config: M569 D0 P0 R500000
Configtepper driver current:
Config: M906 X750 Y750 Z750 T0 E750
Config:Hysteresis Correction:
Config: M99 X0.00 Y0.00 Z0.00 F1.00
Stats: Total: 0, Finished: 0, Failed: 0
Stats: Total print time: 0s, Power on time: 0s
Stats: Filament used: 0Km 0m 0cm 0mm
wait
SD card ok

e l'altra si blocca sullo boot screen con questo log:

Quote

start
Info:Echo:MK4duo_4.3.6
Echo:Last Updated: Mar 17 2019 22:49:19 | Author: (none, default config)
Echo:Compiled: Mar 17 2019
Echo:Free Memory: 2780 PlannerBufferBytes: 1456
SD card ok
Echo:EEPROM version mismatch (EEPROM=MKV50 MK4duo=MKV51)

L'eprom era stata inizializzata dalla versione 4.3.6 di Agosto

Comunque non è un grosso problema, mi terrò i sorgenti vecchi quando voglio usare la 4.3.6 (cosa che sarà necessaria solo le versioni 4.3.7 e 4.3.8 non funzionassero correttamente, cosa per ora già vera sulla 4.3.8)

Edited 2 time(s). Last edit at 03/17/2019 06:00PM by FabryR.

Ti giuro che non ci ho capito nulla... Tu mi devi far capire se l'ultima versione la 4.3.8 va o non va, le altre ormai non le tocco più...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

E' semplice sarà cambiata pure la libreria ma il problema è nel codice che hai cambiato tu da Agosto in poi dato che il vecchio codice con la libreria cambiata funziona (alias la versione vecchia non è che va perché ho una build fatta ad agosto, va anche se compilo oggi cosa che non si può dire dell'ultima revision).

Comunque va bene era solo per segnalare.

La 4.3.8 non la tocco più la considero buggata ed inutilizzabile in sicurezza

Ora sto provando la 4.3.7 che sembrava funzionare (non testata in fase di stampa), finché non ho voluto provare nuove feature.
Ho attivato il Bed Levelling TMC SensorLess e collegato il pin Diag1 dell'asse Z (su ZMax quindi il microswitch ZMin è sempre presente)
Bene non fa più Homing Z, quando lo chiedi va un po' verso l'alto e poi si ferma (chiedi altro Homing e va ancora verso l'alto), ma potrebbe esserci qualcosa di sbagliato nelle config (sono esperimenti).
In più in una fase di homing non ha sentito gli endstop x o y (o entrambi) è andata a sbattare ed ha continuato a spingere (fino al mio reset)
Però l'ha fatto una volta sola e lo considero un caso

EDIT: Provato per scrupolo a dare la stessa config (convertita dal Fw Configurator più ritocchi manuali per le parti che non fa) al 4.3.8 e fa lo stesso comportamento (niente Homing Z), vedremo nei prossimi gg di capire se problema di config o meno.

Edited 4 time(s). Last edit at 03/17/2019 08:03PM by FabryR.

Scusa ma baggata cosa?? Questo è che non riesco a capire è quella che usano tutti anche con i tmc quindi davvero non capisco che problemi hai??
Se fa quel comportamento quando fa la home vuol dire che trova l'endstop triggered. Controlla con M119 e vedrai che Z è in triggered.

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Veramente se leggessi meglio per bug (o problemi magari legati in combinazione all'elettronica, voglio provare a cambiare il Mega per sicurezza) della 4.3.8 vedresti che mi riferivo ad altro (e c'è il thread).

Che se va verso l'alto con questa config potrebbe esserci un problema nella config (o nel cablaggio) l'ho anche scritto

Quote

potrebbe esserci qualcosa di sbagliato nelle config (sono esperimenti).

però non è normale che se dai un comando di movimento asse X (per esempio) si muova pure (e senza motivo) asse Y fino a Y200 (cosa che non succede sulla 4.3.7 e quindi non è il fatto che ZPROBE sia sempre triggered e su quello hai ragione)

Non è normale che aggiungendo delle opzioni (slegate tra loro) smettano di funzionare delle parti con comportamenti difficili da spiegare.

Non è normale che sulla Geeetech G2S del mio amico ogni tanto non senta gli endstop quando fa homing e vada a sbattere.
E guardacaso controllando ora su GitHub c'è uno che segnala lo stesso problema e dice anche come riprodurlo (noi non l'avevamo capito ci sembrava casuale ed ogni tanto, proveremo appena possibile se la tecnica di riproduzione è corretta).

Da noi non funziona pure il bed levelling (ah quello che lo segnala su GitHub ha ragione che fa solo Z100 ma non si è accorto che c'è un'altro bed levelling nel menù configurazione e quello fa partire la procedura corretta), ma ci riserviamo di confermare o meno il problema dopo aver verificato la sonda che faccia il suo lavoro in modo corretto (magari è la sonda che non scatta e ...)

Insomma qualche problemino la 4.3.8 pare averlo in certe config almeno.

Edited 3 time(s). Last edit at 03/18/2019 06:21AM by FabryR.

Allora il movimento su X e anche di Y capita solo sulla coreXY dopo aver fatto G29, ma visto che g29 si fa solo una volta e poi si salva in eeprom e a inizio stampa si da il G28 il tutto non accade, questo lo so e sto investigando ma non avendo una core sto vedendo anche se su marlin risolvono.
Il resto è assurdo, la lettura degli endstop avviene solo in home e si legge un pin se è allo stato 0 o allo stato 1, non si fa altro.
Di quale commento su github parli? Per caso quello della delta?
In MK4duo a differenza di Repetier a Marlin i pin sono modificabili via gcode e quindi salvati in eeprom, puoi cambiare un pin di un endstop con un comando. Purtroppo le schede AVR soffrono di una rimappatura di pin successiva all'inizializzazione, specialmente se si rimappa lo stesso pin.
Quando si effettua M502 vengono caricati tutti i valori messi nei vari #define e anche i pin e poi rimappati. Quindi se si fa un reset della eeprom, M502 e poi M500, bisogna per forza di cose spegnere e riaccendere in modo che poi vengono mappati bene tutti i pin una sola volta...
Ci sarebbe una soluzione, ma costa in termini di ram già poca nell'avr, memorizzare per ogni pin se è stato già mappato o no, ma visto che praticamente viene usato questo valore solo se si fa M502 (reset ai valori di default) e m500 poi mai più non l'ho mai fatto.
In finale basta poco si vogliono resettare M502 M500 e poi spegni e riaccendi..
Il problema è come si usa sta benedetta Eeprom, ma perché dovrei resettarli al valore di default??? A che diamine serve?? Basta usare il plugin xml per repetier host, che salva tutti i dati della eeprom in un file su pc, quando si carica un nuovo firmware per essere sicuri di avere tutti i dati giusti basta caricare i valori nel PC e scaricarli in eeprom.. Tutto molto semplice e facile da fare... E se si deve cambiare solo un parametro basta cambiare solo quello... C'è la tabellina con tutti i valori si cambia e si salva... Senza neanche usare i gcode...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
Allora il movimento su X e anche di Y capita solo sulla coreXY dopo aver fatto G29, ma visto che g29 si fa solo una volta e poi si salva in eeprom e a inizio stampa si da il G28 il tutto non accade, questo lo so e sto investigando ma non avendo una core sto vedendo anche se su marlin risolvono.

Ok ma io non ho una coreXY ma una normale cartesiana con assi X e Y separati

Eppure con il FW (però sarebbe meglio parlarne nell'altro thread) 4.3.8 che ho messo stanotte ottengo che se faccio
G28 XY
G1 X50 F3000

Si sposta a X50 Y200 (e se non ero in homing con Y va a sbattere)
Qualunque asse sposti ci associa sempre un Y200 allo spostamento.
Anche
G28 Y
G1 Y75 F3000
diventa un Y200 finale

Ok ho il problema del ZPROBE (non ZMIN) sempre triggered (per quello ho evitato di perdere tempo nell'Homing Z) ma non dovrebbe centrare nulla.

Ah prima del test ho fatto
Spegni e riaccendi
Inizializza Eprom (menu LCD)
Ripristina impostazioni (menu LCD)
Salva Config (menu LCD)
Spegni e riaccendi
e poi non contento da seriale ho aggiunto
M502
M500
Spegni e riaccendi

Però il difetto lo fa UGUALE!

Quote

Il resto è assurdo, la lettura degli endstop avviene solo in home e si legge un pin se è allo stato 0 o allo stato 1, non si fa altro.
Di quale commento su github parli? Per caso quello della delta?

Si quello della Delta (la Geeetech G2S è una delta).

Sulla ns (o meglio su quella del mio amico) abbiamo notato che ogni tanto (casuale a prima vista) nell'Homing va a sbattere (almeno su uno degli assi) ignorando l'endstop.
Poi ci riprova ed al secondo tentativo lo fa (e dopo altri homing tutto ok).
Ma non sapevamo come riprodurlo ed abbiamo pensato a falso funzionamento del microswitch ed abbiamo ignorato la cosa

Inoltre quando chiediamo l'auto bed level (con sensore Allen Key dovrebbe essere mi pare) fai dei movimenti scoordinati e va a sbattere sul piano.
Però abbiamo la molla del sensore zprobe che va tirata di più ed a volte non richiude il contatto ed anche lì abbiamo dato la colpa a meccanica (però se il sensore collisione piano rimane triggered non ha molto senso che continui verso il basso impiantandosi).

Leggendo su GitHub poi abbiamo (ho) trovato due che segnalano problemi proprio sulla GeeeTech.
Uno segnala il problema end stop ogni tanto saltato e lui dice anche come riprodurlo per farglielo fare sempre (non abbiamo ancora provato e non posso confermare che è così anche per noi, però in effetti alcuni volte che ha sbattuto avevo fatto un M502 prima).

L'altro segnala che la funzione auto livellamento nel menù principale non fa NULLA tranne portare Z a 100.
E questo confermo che è così davvero, ma io l'avevo inizialmente preso come cosa voluta (ti porta a Z100 per farti attivare AllenKey) e poi c'è la stessa funzione come menu dentro il menu configurazione e qui c'è più roba e c'è la vera funzione di auto livellamento (che poi a noi va a sbattere, ma dobbiamo prima verificare la meccanica e/o magari provare un altro fw su cui funzioni prima di dire che è colpa del 4.3.8)
Ecco non so se è voluta la cosa è c'è un errore nel codice dei menù e magari il menù completo di livellamente dovrebbe esserci pure senza entrare in configurazione (nella 3DRag infatti è così, il menù livellamento è esterno a configurazione)

Quote

Il problema è come si usa sta benedetta Eeprom, ma perché dovrei resettarli al valore di default??? A che diamine serve??

Serve solo ad evitare le contestazioni del tipo "hai ripristinato le config a default ? quando si cambia un fw bisogna sempre resettare a impost. di fabbrica e poi riconfigurare" che spesso si usa in informatica.
Nonché serve (credo) anche a fare sparire l'errore Eprom cambiata ogni volta che salto da 4.3.x a 4.3.y

In ogni caso i default di fabbrica (PID a parte forse) sono già quelli che sono giusti (almeno per partire, poi le ottimizzazioni sono una cosa a parte).
Non ci sono Pin che nel default fanno x, ma nella realtà fanno y e vanno riconfigurati dopo per avere il funzionamento corretto.

Edited 1 time(s). Last edit at 03/18/2019 10:45AM by FabryR.

Ok ora è più chiaro..

Allora io ho una cartesiana e tutto va.
Vediamo quale potrebbe essere il problema. Disabilita l'hysteresys e vediamo se è quello il problema... Altro nel tuo overall non lo vedo...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ho paura che sia qualcosa collegato alle nuove librerie TMCStepper (e magari all'uso con SoftSPI), nei test che sto facendo mi sono appena ricordato perché ero rimasto alla versione 4.3.6 di Agosto.
L'ultima 4.3.6 abbiamo già appurato che si blocca, però anche la 4.3.7 non va alla fine (e mi sono ricordato che avevo problemi anche mesi fa appena era uscita).

Tolto lo zprobe (e messo bad levelling manuale) e da LCD funziona tutto ma i comandi G1 non vanno
Qualunque comando impartisco ottengo che parte solo l'asse Z e senza più fermarsi (se non resetto va in collisione in alto)

Adesso compilo la stessa config su 4.3.8, ma già il fatto che scazzi la 4.3.7 non è buon segno

PS
Rimane la possibilità di problemi alla scheda Arduino ma non si spiegherebbe perché il 4.3.6 (agosto version) invece funziona.

Edited 1 time(s). Last edit at 03/18/2019 10:45AM by FabryR.

La cosa strana è che i comandi di movimento funzionano con il pin step, la porta SPI serve solo per settare i driver, quindi il movimento dovrebbe farlo bene.
Però la comunicazione in software SPI non mi è mai piaciuta anche perché usa i timer e magari sono gli stessi che si usano per fare altro e non vorrei che andassero in conflitto, ma sinceramente non ho mai indagato...
Non riesci proprio a usare l'hardware spi?

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

E' già occupato dalla SD e volevo evitare di shararlo, inoltre i pin sono coperti dall'adattatore LCD e dovrei saldarci sopra dei fili per usarli.

Comunque ho compilato il 4.3.8 con la stessa config e sembra andare tutto o quasi (G1 va).
Poi ho tolto una opzione (che non serve a nulla alias PINS_DEBUGGING) e ricompilato.

Anche questa versione sembra funzionare ma meno bene, se faccio partire la funzione di Bed Levelling (manuale) su 5 tentativi ha funzionato correttamente 2 o 3 volte solo.
Una volta invece di fare la posizione 10,10 (primo punto) ha sparato Y al max (e senza softEndStop, alias ha crashato a fondo scala ed ha continuato a spingere fino al reset), un'altra volta non ha mosso gli assi per nulla e si è congelato sul primo punto (lo schermo lcd non rispondeva più), ...ecc

Però se metti o togli le opzioni e cambiano le funzioni base di movimento o altro, c'è qualcosa che non va (magari nella scheda arduino anche se la 4.3.6 pare stabile).

PS
Ho notato un bug (non tuo) nella funzione di Bed levelling.
Prima di partire fa un Home degli assi ma la fa ignorando l'opzione MIN_Z_HEIGHT_FOR_HOMING che invece G28 usa.
Insomma dove è Z rimane e se è a 0 sulla mia meccanica spostare prima gli assi XY spesso significa schiantarsi su cose che sporgono ai bordi

Ma fai una prova per volta, davvero cosi si capisce poco di quello che succede...
Inizia da una semplice home e movimentazione..
Poi fai l'abl. Per l'abl usi una probe o fai un manual mesh level?
Quando fai G29 se non hai fatto prima la home ti da errore, non fa la home, come è possibile che lo faccia??

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Manual Mesh Level (niente sonde, volevo usare TMC SensorLess Probe ma per ora non so come farlo funzionare già a livello di pin, e poi esce/usciva il problema che impazziva G1)

Dal menu LCD fa lui sempre un Homing prima di iniziare.

Comunque rettifico non è un problema del bed levelling ma è proprio la funzione di Homing (che sarà del Marlin) che ha un limite nell'attuale implementazione.

Spiego meglio:

Stampante appena accesa (o resettata) e con estrusore posizionato a contatto del piano (o comunque ad altezza inferiore a MIN_Z_HEIGHT_FOR_HOMING) in una certa posizione ma la stampante non le sa (ancora) le posizioni degli assi e le dichiara "?"
Se lancio G28 non fa spostamenti di Z e parte subito con gli assi XY (insomma ignora MIN_Z_HEIGHT_FOR_HOMING), con il risultato che se ero rimasto fermo su bordi (dove ci sono parti sporgenti di qualche mm) si schianta.

Se invece faccio G28 Z e poi seguito da G28 allora correttamente rispetta MIN_Z_HEIGHT_FOR_HOMING ed alza Z prima di spostare XY.
Ok che non sai la posizione di Z finché non fa l'homing di Z ma è concettualmente sbagliato spostare gli assi XY senza variare Z.
MIN_Z_HEIGHT_FOR_HOMING dovrebbe essere una altezza minima da rispettare sempre in homing quindi se non sai la posizione di Z in quel momento hai due strade:

• Ti sposti in modalità relativa (invece che assoluta) e ti alzi sempre di minimo MIN_Z_HEIGHT_FOR_HOMING rispetto alla posizione attuale (al peggio l'unico rischio è che se eri già a max Z va a sbattare, ma una stampante che viene spenta/resettata a max Z è poco probabile, il contrario alias Z < MIN_Z_HEIGHT_FOR_HOMING invece no)
• Fai prima implicitamente un G28 Z per stabilire l'altezza di Z e poi fai il G28 correttamente considerando MIN_Z_HEIGHT_FOR_HOMING
  Questa ha lo svantaggio che se sotto c'è un oggetto stampato ti schianti su di lui, quindi forse è meglio la prima.

Edited 4 time(s). Last edit at 03/18/2019 11:39AM by FabryR.

Ma che centra Marlin??
Si in effetti se non conosce la posizione di Z non si alza di MIN_Z_HEIGHT_FOR_HOMING...
Prima era che si alzava sempre, poi mi hanno detto in molti che lasciavano il piatto in MAX a fine stampa che tentando di alzarsi andava a sbattere e allora l'ho tolto.. Purtroppo come vedi non c'è mai una soluzione, ma l'unica è come sempre l'utente che conosce la stampante e sa cosa deve fare, basta fare una home di z, prima di tutto, li dove sei e hai risolto...

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Ho detto marlin perché pensavo che il frammento di codice non fosse tuo ma fosse preso da Marlin e quindi il comportamento non dipendesse da codice scritto da te, ma da codice importato dal Marlin.

In ogni caso la soluzione perfetta non c'è, ognuna ha sempre un difetto e va scelto il male minore.

Se scendi in G28 Z per azzerare prima Z e sotto c'è qualcosa collidi (e se era una stampa non è bello).

Se lasci la stampante a Max Z (davvero qualcuno lo fa ? Però spesso il max Z impostato non è il Max Z fisico, esempio la mia arriva a 218mm in Z ma quasi tutti la usano a max 200 e quindi anche a Max Z può alzarsi ancora senza problemi, ma ovviamente è stampante dipendente e non si può generalizzare) ed alzi sempre collidi a fine corsa

Se non alzi quando non sai la posizione di Z e ti sposti rischi di collidere con gli oggetti che proprio MIN_Z_HEIGHT_FOR_HOMING voleva evitare

C'è un flag di compilazione per scegliere ?
Ossia se io volessi la vecchia modalità "alza sempre (ma solo se non conosco posizione Z)" ho un flag per accendere o spegnere o devo modificare il codice ?

Edited 4 time(s). Last edit at 03/18/2019 12:11PM by FabryR.

No non c'è, posso metterlo, ma nella 4.3.9, non nella 4.3.8...
per ora se vuoi cerca in cartesian_mechanics.cpp la riga

const float z_homing_height = home_flag.ZHomed ? MIN_Z_HEIGHT_FOR_HOMING : 0;

la cambi con

const float z_homing_height = MIN_Z_HEIGHT_FOR_HOMING;

Edited 1 time(s). Last edit at 03/18/2019 12:15PM by MagoKimbra.

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

Quote
MagoKimbra
No non c'è, posso metterlo, ma nella 4.3.9, non nella 4.3.8...
per ora se vuoi cerca in cartesian_mechanics.cpp la riga

const float z_homing_height = home_flag.ZHomed ? MIN_Z_HEIGHT_FOR_HOMING : 0;

la cambi con

const float z_homing_height = MIN_Z_HEIGHT_FOR_HOMING;

Visto che il 4.3.9 è stato rilasciato, questa parte è poi diventata una opzione o c'è ancora da modificare cartesian_mechanics.cpp ?

Edit: Guardando il codice credo che l'opzione non sia mai stata messa.

Edited 1 time(s). Last edit at 08/18/2019 07:28PM by FabryR.