GRBL 1.1h fail to home X-axis for my Ortur LM2

Other Hardware Motors, Mechanics, Power and CNC
1

My Ortur LaserMaster 2 controller failed so I decided to replace it with an Arduino UNO and CNC Shield V3.0. I've got it working nearly perfect with the exception of the homing command $H. Here is what I've done to the code from https://github.com/gnea/grbl : In config.h;

  • Commented out line 105 and 106 for HOMING_CYCLE_0 and HOMING_CYCLE_1
  • uncommented line 112 to make HOMING_CYCLE_0 (1<<X_AXIS)
  • uncommented line 113 to make HOMING_CYCLE_0 (1<<Y_AXIS)
    I have also uncommented line 124 to define **HOMING_SINGLE_AXIS_COMMANDS** for testing purposes.

If I send CTRL-x and wait for controller to return to ready and then issue $X and it unlocks, then I issue $H and the rig makes what appears to be a -10mm X moves with a short pause (0.1s) and then another -10mm X and then it moves in the Y- direction until it hits limit switch - backs off and then SLOWLY touches the Y switch again and goes back to its "back off" location.. The behavior in Y direction is what I'd expect but the X isn't.

If I hold the Y-limit switch and issue the ? status command, the machine returns this: <Idle|MPos:-5.000,-395.000,0.000|Bf:15,128|FS:0,0|**Pn:Y**|Ov:100,100,100> and if I hold both X and Y: <Idle|MPos:-5.000,-395.000,0.000|Bf:15,128|FS:0,0|**Pn:XY**|Ov:100,100,100>

Here is a short video showing the rigs behavior:
https://youtube.com/shorts/WPR6LPeDtnI

Any and all help is greatly appreciated! :blush:

2

Check the wiring and setup for the home switch. Schematics showing it might be useful.

3

Ok - i'll see what I can do for those documents.. The thing - is that the machine works beautifully for all movement. If I manually move the tool head to a good spot and issue G92 X0 Y0 Z0 - I can then use programs such as Lightburn by pressing "Set Origin" and its machine settings to NOT auto-home and starting from "User Origin"..
So the machine works great - as long as I don't try to use the $H ?

If I measure from the ground of the power input block - to each of the limit switches with a volt meter, I get +5V until the switch closes and I get a solid 0 volt which I at that point can confirm is ground (about 2.5ohm).. So I think my hardware is solid?

See attached fritz diagram.

OrturLM2-ArduinoGRBL-CNCShieldV3_bb
OrturLM2-ArduinoGRBL-CNCShieldV3_bb1248×1755 156 KB

Oh! I've confirmed - all those black pins along the right edge are all wired to power ground.

4

Hmmm.. OK - so I wrote up a piece of code (mostly borrowed from another post) which keeps moving the X-axis in the negative direction until it hits the limit switch.. and it works..

Does anyone here have experience with GRBL 1.1h :interrobang:

There is the test code:

const byte directionPin = 5; // X=5, Y=6 and Z=7
const byte stepPin = 2;      // X=2, Y=3 and Z=4
const byte limitPin = 9;     // X=9, Y=10 and Z=11
const byte enPin = 8;        // Enable Stepper
const float delayTime = 0.001;

void setup() {
   Serial.begin(115200);
   pinMode(directionPin, OUTPUT);
   pinMode(stepPin, OUTPUT);
   pinMode(enPin, OUTPUT); 
   pinMode(limitPin,INPUT_PULLUP);
   digitalWrite(enPin, LOW);
   digitalWrite(directionPin, HIGH); // Negative direction=HIGH, Positive direction=LOW
}

void loop() {
   singleStep(delayTime);  // delay in milliseconds per step
}

void singleStep(unsigned long stepInterval) {
   static unsigned long stepTimer = 0;
      int pinValue = digitalRead(limitPin);
   Serial.print("limitPin is now ");Serial.println(pinValue);
   if (millis() - stepTimer >= stepInterval)
   {
      stepTimer = millis();
      if(pinValue== HIGH) { 
          digitalWrite(stepPin, LOW);
          digitalWrite(stepPin, HIGH);
      }
   }
}
5

Can it be the wrong pin being used for the Grbl 1.1? Is the setup, definition, correct, active high or active low?
As a paratesis below:
For safety aspects limit switches should be like the opposite. They allow movements when not triggered. A lost connection should give a stop condition. That means an active high enables running, a low disables running.

6

Yes - I've read that safety switches should be normally closed so that the machine would stop if there is a wiring break, rather than rumbling into an end point, i'll replace my switches once I can get this working properly.

I found that the cpu_map.h has the pin definitions around line 58 and it seems to be set the same as in my code (I used pin 9 for X and so does Grbl) -- besides, wouldn't the "status" command " ? " be giving the wrong information when I request it?

When I use PUTTY to communicate manually with GRBL and ask for status - i normally get this (after CTRL-X and $X):
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

If I hold the X limit switch: <Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:X|Ov:100,100,100>

If I hold the Y limit switch: <Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:Y>

With both X and Y held: <Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:XY>

I am currently trying to read through the code and understand the process used for homing, i want to see about adding some debugging information like "homing X", "x-limit found" etc.. i'll let you know how goes.. I greatly appreciate y'all insight into this :slight_smile:

7

You are ahead of me...

It's some time since I was looking at Grbl. (Code HPGL once...)

There are limit switches for x, y and z, but is maybe the home switch a fourth switch? If not, which axle switch to "home" to?

That's beyond my comfort zone. No theory pops up in my mind.

A vague memory tells about something there. Dors the user need to write it himself?
Was it a difference between Grbl 0.9 and 1.1? There's something special about homing, as You've already experienced.....

I do my very best, but not good enough yet....

8

It looks like homing is done in the motion_control.c by the mc_homing_cycle function on line 206 thru 251 which calls limits_go_home from limits.c line 157 thru 405

That's where I am going to be digging around and see about adding some debugging features :wink: (Just figured out that I can add this line "anywhere" useful to put a marker and be told whenever a piece of the code is executed: printPgmString(PSTR("^limit.c|272|^")); - that'd tell me it just executed line 272 in the limit.c code...

9

Fine. I remember compiling and downloading Grbl.h but never looked into it. I'll try in the evening.