Grbl 1.1f come configurare ?

[MauPre75]

Salve a tutti
Ho appena caricato grbl 1.1f , ho difficoltà a configurare la macchina e con i comandi G90 , ho provato con homing che esegue correttamente a modo suo ma lo fa però non si sblocca dai pulsanti , l'ho provato in tutte le direzioni ma non si sgancia .
Con il G90 va solo in direzione negativa e non rispetta le quote andando all'infinito , mentre è corretto con il G91 .
Prima di ritornare al grbl 0.8 che è perfettamente funzionante vorrei chiedere se qualcuno può aiutarmi a capire cosa fare , forse c'è da mettere mano al conf h ?
Aggiungo anche che dopo fatto homing con i soft limit se mi sposto in direzione positiva mi da alarm 2 errore di origine.
Grazie a chiunque possa aiutarmi .
Saluti Maurizio

[tittopower]

Io utilizzo la 1.1f come te e non ho avuto nessuno di questi problemi, nel grbl credo di aver cambiato solo il fatto che non faccia assieme la home di X e Y come da default. All'inizio avevo la home in basso a sinistra poichè nella fresa mach3 la avevo così ma poi mi risulta più pratico per caricare il pezzo da fresare avere la home in alto a destra così il piano è accessibile, anche se poi sono visualizzati valori assoluti di macchina negativi. Ho attivato anche #define HOMING_FORCE_SET_ORIGIN e #define LIMITS_TWO_SWITCHES_ON_AXES poichè ho switch sui massimi e minimi ma ho fissato i soft limits un pò piu bassi della corsa massima in modo che non arrivi ad attivarli poichè se attivati i motori vengono disalimentati.
Cosa intendi esattamente con "a modo suo ma lo fa però non si sblocca dai pulsanti , l'ho provato in tutte le direzioni ma non si sgancia"

[MauPre75]

Con la 0.8 con SH l'homing partiva e non si fermava fino al raggiungimento dei pulsanti , tutti gli assi contemporaneamente , la 1.1 premendo SH mi si muove Z di un mm e poi si ferma , devo premere nuovamente sh tutte le volte fino al pulsante , una volte trovato il limit si aziona X Y sempre di un mm per volta , insomma devo stare li fino alla fine a premere sh , trovati tutti gli home si muove in direzione dei pulsanti di un mm schiacciandoli ulteriormente , ma questo ultimo dettaglio era uguale in 0.8 .
Una volta terminato homing posso solo muoverla nella direzione home , per allontanarmi in senso opposto mi da errore 2 , come se fossi fuori dagli offset , ma non ho impostato nessun offset , forse dovrei farlo ?
Disattivato i limit posso muoverla ma in nessun caso non vedo ne posizione macchina ne di lavoro che stanno sempre a 0 .

[tittopower]

Io ho $20, $21, $22 =1 specificando una corsa degli assi minore di 2mm rispetto ai fine corsa MAX
$23 a seconda di dove vuoi la home (0=in alto a dx, 3 in basso a sx)
Cavi schermati e accoppiamento ottico alimentazione separata per i fine corsa, $5=1 (uso contatti NC) con cavi normali avevo un problema similare.
Altro non saprei che muovere, tanto avrai sicuramente replicato i valori con cui la 0.8 andava bene.

[MauPre75]

Stasera ho risolto per l'homing , era $5=0 con =1 ha fatto tutto perfetto , adesso mi rimane da risolvere il perché le coordinate mi stanno a 0 e alarm2 con i comandi G90 , forse perché non ho nessun G54 memorizzato chissà ?
Grazie per l'aiuto tittopower.

[tittopower]

Non tutti i programmi grbl utilizzano allo stesso modo la comunicazione per quanto riguarda la visualizzazione del DRO. Devi provare a variare $10.

[MauPre75]

Provato anche quello ma non funziona , ma non è un problema posso sempre visualizzare con il verbose , più importante che sto rimettendo in marcia la macchina , pian piano forse riuscirò ad attivare anche il dro , penso che dovrei controllare il conf h .

Voglio aggiornare anche ugs , chissà forse andrà meglio.
Ancora grazie Tittopower

[MauPre75]

Sera a tutti
In questi due giorni ho avuto un problema i G2 G3 , dopo aver fatto lo zero pezzo avviato il gcode grbl segnala errore 20 con G64 e errore 33 per G2 G3 , andando a spasso per i fatti suoi , nello sbattimento ho notato che se faccio un fasullo zero pezzo un po più lontano e poi ritorno un po' indietro alla giusta coordinata non dà più errori .
Sapete dirmi se è un problema di offset ?
Come evito questo problema ?

[hellfire39]

Non so se aiuta, ma non ho trovato il G64 tra i comandi gestiti da gbrl

[MauPre75]

Non aiuta ma grazie lo stesso , il vero problema è errore 33 che delocalizza la lavorazione mettendo a rischio collisione .

[hellfire39]

Servirebbero le linee di codice incriminate.
Sembra che a gbrl il comando non piaccia, potrebbe essere un errore di arrotondamento dovuto a valori a virgola mobile troppo piccoli.

[MauPre75]

No Hellfire non centra il gcode , è questione di posizionamento , oggi ho fatto un po di analisi di procedura , quando con il grbl 0.8 semplicemente mi spostavo dall'home con G91 G0 X.....Y.....Z.... seguito con reset zero e lanciavo il gcode tutto era ok , con 1.1 in presenza di G2 G3 questo non funziona e da errori , ho eseguito la stessa operazione home, G91 xyz , seguita con un movimento di z con la tastiera che al primo spostamento lo fa in g21 g91 g0 z-...., reset zero , e tutto funziona a dovere .
Se qualcuno sa come posso approfondire con link il linguaggio di grbl 1.1 ne sarei grado , ho letto quasi tutto velocemente i link github di configurazione e interfaccia ma non ne parla .
Ancora non uso il probe e credo che dovrei per il giusto posizionamento.

[hellfire39]

Ho letto un thread, su gbrl, che lamentava un problema simile e lo imputava ad un problema di calcoli in virgola mobile (che non sono proprio il forte di arduino, essendo un processore a 8 bit).
L'errore 33 indica che, per gbrl, i valori non sono corretti, ovvero non descrivono un arco di cerchio.


Servirebbe uno spezzone di codice, contenente il punto di partenza (quello prima all'errore 33) e quello incriminato.

[MauPre75]

L'errore 33 oltre ai g2 g3 lo da anche anche per il g38.2 probe che non uso ancora , l'ho solo provato in maniera sommaria giorni fa , non saprei dire se avviando dopo un azzeramento da probe sarebbe più fluido , però ritorno a dire che con uno spostamento fatto da macro di ugs ed un solo spostamento da tastiera seguito da reset zero funziona , se invece effettuo solo la macro e reset zero fa l'errore all'avvio del gcode.
Non appena posso faccio un video .
Grazie per l'aiuto anche se non risolutivo ma presente.
A presto con il video

[hellfire39]

A basso livello, l'errore indicato (STATUS_GCODE_INVALID_TARGET) appare nella parte di codice relativo ai movimenti ad arco.
Come detto, per qualche ragione, a grbl non piacciono i valori indicati.
E' molto probabile che la cosa sia dovuta a errori di arrotondamento e che non sia risolvibile, se non con modifiche al codice.
Ho visto che qualcuno ha bypassato il problema evitando di utilizzare G2/G3, soprattutto se il cam che lo genera, crea una moltitudine di piccoli archi.

E, come già detto, questo potrebbe essere un limite intrinseco di Arduino (e dei processori 8 bit, in generale) che non hanno coprocessori dedicati al calcolo floating-point.

E' probabile che i valori generati dal cam siano corretti, ma la precisione di calcolo di Arduino, no. Quindi non gli portano i valori.
In pratica, dato il punto di partenza, il punto di arrivo e il centro (I,J). Arduino pensa che la distanza del punto di partenza dal centro e del punto di arrivo dal centro siano differenti.

Alcuni spunti trovati in giro:

it seems to only occur on very small arcs. The theory is that is it is some kind of math or rounding error occurring when GRBL checks to see if the ARC is a valid geometry?...
But so few of my projects even use "arc curves", almost all of them use "smooth curves" which do not generate ARC commands, so this is a low priority bug for me. (and I suspect for the GRBL team for the same reasons)
At least I found a easy work around.

Questo è quello che accade. A mio parere non troverai soluzione, su grbl. Ma eventualmente sul cam/post che usi.