My mistake on clone axis (but where is it ?) - Homing Y

[pferlini63]

Hi all, i've a strange problem but i don't know how to solve it (but for sure is a my mistake)

The environment is a self made cnc with 2 Y motors (with 2 end-stops, one for each axe), 1 on X (with 1 end-stop), 1 on Z (with 1 end-stop).

The problem appears on $HY (and $H).

Only one motor run for few mm (approx 10) in -Y direction and the other is stopped, then seem to reach end-stops (bat is far from them) change direction, move approx 5 mm (with the 2 motors) and then stop.

Seem to reach an imaginary end-stops.

I checked the end-stops and they works correctly (on both axis)

For to be sure i've reset the eeprom with $RST=* and restored the values exposed below.

Furthermore I've loaded a simple gcode and the cnc works like a charm.

Can you help me ?

Here-below my collected data.

[VER:1.1p.20201203:] [AXS:4:XYZY] [OPT:VNMGH,35,255,24]

$# [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F30 S12000]

$G [G54:-232.745,-286.180,-52.655,-286.180] [G55:0.000,0.000,0.000,0.000] [G56:0.000,0.000,0.000,0.000] [G57:0.000,0.000,0.000,0.000] [G58:0.000,0.000,0.000,0.000] [G59:0.000,0.000,0.000,0.000] [G28:0.000,0.000,0.000,0.000] [G30:0.000,0.000,0.000,0.000] [G92:0.000,0.000,0.000,0.000] [TLO:0.000] [PRB:-209.785,-253.645,-52.580,-253.645:1]

$$ $0=10 (Step pulse time, microseconds) $1=254 (Step idle delay, milliseconds) $2=0 (Step pulse invert, mask) $3=0 (Step direction invert, mask) $4=0 (Invert step enable pin, boolean) $5=0 (Invert limit pins, boolean) $6=0 (Invert probe pin, boolean) $10=1 (Status report options, mask) $11=0.020 (Junction deviation, millimeters) $12=0.002 (Arc tolerance, millimeters) $13=0 (Report in inches, boolean) $20=1 (Soft limits enable, boolean) $21=0 (Hard limits enable, boolean) $22=1 (Homing cycle enable, boolean) $23=11 (Homing direction invert, mask) $24=75.000 (Homing locate feed rate, mm/min) $25=500.000 (Homing search seek rate, mm/min) $26=250 (Homing switch debounce delay, milliseconds) $27=5.000 (Homing switch pull-off distance, millimeters) $30=12000 (Maximum spindle speed, RPM) $31=550 (Minimum spindle speed, RPM) $32=0 (Laser-mode enable, boolean) $100=200.000 (X-axis travel resolution, step/mm) $101=200.000 (Y-axis travel resolution, step/mm) $102=200.000 (Z-axis travel resolution, step/mm) $103=200.000 $110=500.000 (X-axis maximum rate, mm/min) $111=500.000 (Y-axis maximum rate, mm/min) $112=500.000 (Z-axis maximum rate, mm/min) $113=500.000 $120=50.000 (X-axis acceleration, mm/sec^2) $121=50.000 (Y-axis acceleration, mm/sec^2) $122=50.000 (Z-axis acceleration, mm/sec^2) $123=50.000 $130=380.000 (X-axis maximum travel, millimeters) $131=350.000 (Y-axis maximum travel, millimeters) $132=200.000 (Z-axis maximum travel, millimeters) $133=350.000

and few lines of config.h

ifdef DEFAULTS_RAMPS_BOARD

// 4, 5 & 6 axis support only for RAMPS 1.4 (for the moment :-)...)

define N_AXIS 4 // Number of axes

define N_AXIS_LINEAR 3 // Number of linears axis

else

define N_AXIS 3 // Number of axes = 3 if not DEFAULTS_RAMPS_BOARD

endif

define AXIS_1 0 // Axis indexing value. Must start with 0 and be continuous.

define AXIS_1_NAME 'X' // Axis names must be in X, Y, Z, A, B, C, U, V & W.

define AXIS_2 1

define AXIS_2_NAME 'Y'

define AXIS_3 2

define AXIS_3_NAME 'Z'

if N_AXIS <3

error "N_AXIS must be >= 3. N_AXIS < 3 is not implemented."

endif

if N_AXIS > 3

define AXIS_4 3

define AXIS_4_NAME 'Y' // Letter of axis number 4

endif

[fra589]

Hi @pferlini63,

In your $$ config output, I see $23=11 (Homing direction invert, mask).
This mean you have your limits switch on X min, Y min and Z max. Is it right?

I don't see in the configuration any other elements that you provided what can explain this behavior, but you don't provide your homing cycles definitions in config.h (line 178 to 224).

@++;
Gauthier.

[pferlini63]

Hi Gauthier, many thanks for your replay. This afternoon i'll be able to send you the missing info.

Paolo

[pferlini63]

Hi Gauthier, some more info:

"This mean you have your limits switch on X min, Y min and Z max. Is it right?"

Really i've connected X max,Y max, A max and Z max

I checked the end-stop for show that they works :

Triggered A <Idle|MPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:Y> No one triggered <Idle|MPos:0.000,0.000,0.000,0.000|FS:0,0> Triggered Y <Idle|MPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:Y>

Config.h missing lines :

#ifdef DEFAULTS_RAMPS_BOARD
  #if N_AXIS == 4 // 4 axis : homing
    #define HOMING_CYCLE_0 (1<<AXIS_3) // Home Z axis first to clear workspace.
    //#define HOMING_CYCLE_1 (1<<AXIS_4) // Home 4th axis (A)
    #define HOMING_CYCLE_1 (1<<AXIS_1) // Home X axis
    //#define HOMING_CYCLE_3 (1<<AXIS_2) // Home Y axis
      #define HOMING_CYCLE_2 ((1<<AXIS_2)|(1<<AXIS_4))  // OPTIONAL: Then move X,Y at the same time.
  #elif N_AXIS == 5 // 5 axis : homing
    #define HOMING_CYCLE_0 (1<<AXIS_3) // Home Z axis first to clear workspace.
    #define HOMING_CYCLE_1 (1<<AXIS_1) // Home X axis
    #define HOMING_CYCLE_2 (1<<AXIS_2) // Home Y axis
    //#define HOMING_CYCLE_3 (1<<AXIS_4) // Home 4th axis (A)
    //#define HOMING_CYCLE_4 (1<<AXIS_5) // Home 5th axis (B)
  #elif N_AXIS == 6 // 6 axis : homing
    #define HOMING_CYCLE_0 (1<<AXIS_3) // Home Z axis first to clear workspace.
    #define HOMING_CYCLE_1 (1<<AXIS_4) // Home 4th axis (A)
    #define HOMING_CYCLE_2 (1<<AXIS_5) // Home 5th axis (B)
    #define HOMING_CYCLE_3 (1<<AXIS_6) // Home 6th axis (C)
    #define HOMING_CYCLE_4 (1<<AXIS_1) // Home X axis
    #define HOMING_CYCLE_5 (1<<AXIS_2) // Home Y axis
  #else // Classic 3 axis
    #define HOMING_CYCLE_0 (1<<AXIS_3) // Home Z axis first to clear workspace.
    #define HOMING_CYCLE_1 (1<<AXIS_1) // Home X axis
    #define HOMING_CYCLE_2 (1<<AXIS_2) // Home Y axis
  #endif
#else
  #define HOMING_CYCLE_0 (1<<AXIS_3)                // REQUIRED: First move Z to clear workspace.
  #define HOMING_CYCLE_1 ((1<<AXIS_1)|(1<<AXIS_2))  // OPTIONAL: Then move X,Y at the same time.
  // #define HOMING_CYCLE_2                         // OPTIONAL: Uncomment and add axes mask to enable
#endif // DEFAULTS_RAMPS_BOARD

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

// #define HOMING_CYCLE_0 (1<<AXIS_1)  // COREXY COMPATIBLE: First home X
// #define HOMING_CYCLE_1 (1<<AXIS_2)  // 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)

// Enables single axis homing commands. $HX, $HY, and $HZ for X, Y, and Z-axis homing. The full homing
// cycle is still invoked by the $H command. This is disabled by default. It's here only to address
// users that need to switch between a two-axis and three-axis machine. This is actually very rare.
// If you have a two-axis machine, DON'T USE THIS. Instead, just alter the homing cycle for two-axes.
#define HOMING_SINGLE_AXIS_COMMANDS // Default disabled. Uncomment to enable.

I'll hope this can be useful

:-)

Paolo

[fra589]

Hi Paolo,

Really i've connected X max,Y max, A max and Z max

So, you should have $23=0 since it is the default of Grbl to have limits switch connected on the max side of each axis...

---

Grbl's philosophy regarding machine origin is, like most industrial machines, to have all limit switches on the maximum side. This implies that, after homing, all machine movement coordinates are in the negative domain. Subsequently, to use movements with positive and / or negative coordinates, new logical origins must be defined (new machine origin or part origins) with GCode commands:

• G92 - Global Offsets

• G10 P <0,1-6> L20 ... Coordinate system <Current, 1 to 6>

@++;
Gauthier.

[pferlini63]

Hi Gauthier, the position of end-stops is on left-bottom and the movement, i think, is in the correct orientation.

On the other hands, the homing on Z and X works correctly.

This is why i've set $23 to 11 (for inverting the homing movement of AX and Y )

i paint my cnc in the attached files. Where the red circles are the end-stop positions.

Paolo

[fra589]

Hi Paolo,

some more info:

"This mean you have your limits switch on X min, Y min and Z max. Is it right?"

Really i've connected X max,Y max, A max and Z max

So, it's what I said first: Your limit switchs are on Xmin, Ymin and Zmax and you should connect them on the corresponding connectors on the RAMPS board.

@++;
Gauthier.

[pferlini63]

Hi Gauthier, sorry if don't understand your suggestion.

I've changed the limit endstop (now all Y,A and X are at min).

I do some try but unfortunatly without results.

Tomorrow i'll try to recompile the firmware with Aurduino-ide (not with Platformio) and reload it, in the meantime i'll check the documentation for to be sure about pins.

After my tries i'll report to you.

Paolo

[pferlini63]

Hi Gauthier, i'm very sad ... all seem to works like a charms, except for Y homing.

I'm sure the both end-stops works as expected ( if i press both and snd the ? command the result is ...PnYY as i think).

The homing Y move aprox. 10 to 20 mm to Y- ( both axis Y and A ) , then stops ( is far from end-stops) move aprox. 10 mm to Y+ ( both axis Y and A ) , then stops move aprox. 5 mm to Y- ( both axis Y and A ) , then stops

Can you suggest me a way to debug more in depth ?

Paolo

P.S. after a manual homing Y (!) i've loaded a gcode for a PCB. it was milled correctly without any problem

[fra589]

Hi Paolo,

What you are describing is a little strange, I will have to do some investigations to try to understand where it can come from...
Please be patient, I don't have a lot of time for this.

@++;
Gauthier.

[pferlini63]

Hi Gauthier, thanks a lot for your attention and your time.

I'll still try different investigations.

If i'll have news i'll be back to you.

Paolo

[pferlini63]

Hi Gauthier, i'm back with good and bad news .

The first one, i've solved the problem and is possible to close this issue.

The bad, is that i think there is a bug(?) in the software (but can be in my board).

The problem was caused by an incorrect state of endstops "A".

when i displayed the status, it was "Pn:" without any "Y" (the "A" axe is renamed in "Y" in my configuration)

Also changing the position of endstops from max to min.

Now i'm using endstops NC .

So i've set $5=1, all endstop are in the min pos (but really doesn't care) and the max pins are short-circuited to 0v.

All homing like a charm.

Now i suggest, if you have time, to investigate in this direction: the "A" axes or doesn't have the pull-up or the routine for display and the routine for catching endstop are different.

at your disposition if you need other info or test.

Paolo

[fra589]

Hi Paolo,

What you say is pretty strange since axis names (or axis letters) are not used inside of the limit algorithm. Grbl use only the axis internal number as it know the ports bits where the limit switches are connected. The "X", "Y" or "A" axis names does not make sense for the internals limit functions.
The limit processing of all axis is the same, no matter of their names or their number.
For example, in the limits_get_state() function or in limits_go_home() function, we use a loop like this:
for (idx=0; idx<N_AXIS; idx++) {<processing of each axis>} to check all axis with the same code.
But you are right when you say "it really doesn't care" about the min or max pin connection of limit switch since there is no difference in the code, it process them the same.
Finally, I'm glad that now it work fine for you, I can close this issue.

@++;
Gauthier.

[pferlini63]

Hi Gauthier, Again many thanks for your work, your attention and your replay.

Paolo