Problemi con la funzione Home

[Toscano2019]

Salve, uso la mia lingua ma se è un problema posso ttradurre.. Situazione: bCNC con GRBL ver 1.1 su Arduino Uno r3 e CNC shield La CNC è una stampante 3D traformata, con piano di lavoro che si muove X e Y. Penso di aver settato correttamente il tutto, per avere l'origine in basso a sinistra, i fine corsa sono sullo zero. Tutto si muove correttamente e i fine corsa, azionati manualmente, sono rilevati nella barra di stato. Sembra tutto perfetto, ma quando provo ad effettuare un Home, l'asse Z si muove leggermente ma non raggiunge il fine corsa, di seguito il movimento X è corretto, quello Y si comporta come Z, con un leggero movimento avanti e indietro ma senza raggiungere il fine corsa. Se ripeto più volte l'operazione il movimento Z arriva a premere ill fine corsa senza fermarsi e bCNC va in allarme. I parametri modificati sono $3=4, $5=1 e $23=3 Spero di essere stato comprensibile. Grazie per ogni aiuto..

[MARIOBASZ]

Maybe electrical noise problem? Maybe try with the motors without, and activate with the hand the limit switches: 1- activate once the one corresponding to Z, give it a time supposedly go back and activate returned 2- Repeat for X. 3- Repeat for Y. The machine should report that it ended correctly homing (x = o; y = 0; z = n) (translated from Spanish by Google)

[MARIOBASZ]

Read again, Maybe only increase value $ 27

[Toscano2019]

Good morning, thanks for the quick response. I am attaching 2 screens, the first at the start of bCNC, the other after running Home. I also enclose a short clip of the movement of the Z axis. The final noise is the X axis that is positioning correctly, you see in the background that moves. 20190131_094334.mp4.zip

[Toscano2019]

I tried to increase $ 27 to 3. the movement is greater, but when it activates the limit switch it goes into alarm

[sfinexer]

@Toscano2019 What are the parameters of GRBL home? file config.h

// If homing is enabled, homing init lock sets Grbl into an alarm state upon power up. This forces // the user to perform the homing cycle (or override the locks) before doing anything else. This is // mainly a safety feature to remind the user to home, since position is unknown to Grbl.

define HOMING_INIT_LOCK // Comment to disable

// Define the homing cycle patterns with bitmasks. The homing cycle first performs a search mode // to quickly engage the limit switches, followed by a slower locate mode, and finished by a short // pull-off motion to disengage the limit switches. The following HOMING_CYCLE_x defines are executed // in order starting with suffix 0 and completes the homing routine for the specified-axes only. If // an axis is omitted from the defines, it will not home, nor will the system update its position. // Meaning that this allows for users with non-standard cartesian machines, such as a lathe (x then z, // with no y), to configure the homing cycle behavior to their needs. // NOTE: The homing cycle is designed to allow sharing of limit pins, if the axes are not in the same // cycle, but this requires some pin settings changes in cpu_map.h file. For example, the default homing // cycle can share the Z limit pin with either X or Y limit pins, since they are on different cycles. // By sharing a pin, this frees up a precious IO pin for other purposes. In theory, all axes limit pins // may be reduced to one pin, if all axes are homed with seperate cycles, or vice versa, all three axes // on separate pin, but homed in one cycle. Also, it should be noted that the function of hard limits // will not be affected by pin sharing. // NOTE: Defaults are set for a traditional 3-axis CNC machine. Z-axis first to clear, followed by X & Y.

define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace.

define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time.

// #define HOMING_CYCLE_2 // OPTIONAL: Uncomment and add axes mask to enable

// NOTE: The following are two examples to setup homing for 2-axis machines. // #define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) // NOT COMPATIBLE WITH COREXY: Homes both X-Y in one cycle.

// #define HOMING_CYCLE_0 (1<<X_AXIS) // COREXY COMPATIBLE: First home X // #define HOMING_CYCLE_1 (1<<Y_AXIS) // COREXY COMPATIBLE: Then home Y

// Number of homing cycles performed after when the machine initially jogs to limit switches. // This help in preventing overshoot and should improve repeatability. This value should be one or // greater.

define N_HOMING_LOCATE_CYCLE 1 // Integer (1-128)

[Toscano2019]

I do not understand what you mean. I have compiled with Arduino IDE v. 1.8.8 what I downloaded from GitHub gnea / grbl v. 1.1. I am using an Arduino UNO compatible. In any case, I enclose the file config.h

config.pdf

[sfinexer]

@Toscano2019 To use HOME, you must first configure GRBL by compiling it according to your machine configuration. This is not a B-cnc error, this is an incorrect GRBL setting.

[Toscano2019]

I agree. I was looking for help to understand what is not good in my configuration. did you read the previous posts where I describe the type of mechanics and the changes made to the $$ parameters?

[sfinexer]

@Toscano2019 are you sure the parameter is $5 = 1 The button must be closed in this case. I don `t know the device of your end sensors. In standard mode, the pull-up resistor is energized, when the button is triggered, the voltage drops.

Pleaz ALL parametr $$ especially important 132 and 20

[Toscano2019]

First of all, I thank you for the time you dedicate to me. I would like to summarize .. the hw is a Vellemann K8200, originally 3d printer. I replaced the controller with an Arduino Uno and a CNC sheld for GRBL compatibility. The movements via bCNC are correct, the limit switches, normally closed, manually operated are recognized in the status bar. The problem is that the Home function is correct only for the X axis, which moves until it reaches the limit switch and correctly positions 1 mm backwards. the Z and Y axis behave as if they were already on zero. In fact they make a couple of short movements back and forth, like the Y axis in the zero position. Waiting for other indications, I will try to reverse the axis connections, to understand if it can be a problem of the Arduino, shield or mechanics. Greetings

$0=10 $1=25 $2=0 $3=4 $4=0 $5=1 $6=0 $10=1 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=1 $23=3 $24=25.000 $25=500.000 $26=250 $27=1.000 $30=1000 $31=0 $32=0 $100=4.030 $101=4.030 $102=196.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=200.000 $131=200.000 $132=200.000

[onekk]

From the description GRBL is searching the limits, or better the home routine move toward the limit switch and wait for the trigger, then clear the limit by an amount specified by the $27=1.000 | Homing pull-off, mm

parameter and stop.

so the machine is searching the limit and probably it find it pressed due to a wrong configuration of the

$5=0 | Limit pins invert, boolean

or a wiring problem.

so it invert the direction to try to clear the limit and dind't find a trigger "off" and stops.

So you have to check the configuration and the wiring of the limit switch.

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration (See this page)

https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches (and this page)

The better schematics to use is those with NC and improved noise filtering.

Regards

Carlo D.

[Toscano2019]

Carlo, your analysis is absolutely correct: two of the three limit switches, Y and Z axis, even if apparently the same and equally responsive to manual pressure, do not work properly. By inverting the connections, I checked that with the Y-axis limit switch, the working one, the other axes also work correctly. What I do not understand is why bCNC reports on the status bar the pressure of all three limit switches .... However I am providing for the replacement of the limit switches. Thank you all for your cooperation.

[Toscano2019]

Carlo, la situazione non procede.. Ho cambiato il micro dell'asse Z ma è come prima.. Comunque cortocircuitando sullo shield CNC i contatti dell'asse Z, si muove. Controllerò il cablaggio.. Ho un uleriore dubbio. Qual'è la posizione di Home dell'asseZ? il mio HW è di derivazione 3D printer, quindi l'home era a 0, ma facendolo muovere come ti dicevo prima, il verso è verso l'alto, ovvero valore positivo. Se non ti arreco troppo disturbo, quando sei disponibile potremmo sentirci? Altrimenti continuiamo osi. Grazie in ogni caso

[Toscano2019]

aggiornamento: ho rifatto il cablaggio del micro asse Z facendolo passare da solo per un'altra strada e ora funziona. Rimane il dubbio della posizione Home dell'asse Z

[Harvie]

I am closing this, since it's not bCNC issue. But feel free to continue discussing the problem further in here.