Strange homing problem.

[regpye]

I have a puzzling problem that I have not been able to work out, maybe someone here can advise me on what is going on and how to fix it? I have built another laser engraver/cutter, it is my fifth one, so I am not a noobie and have some experience. The machine uses Arduino UNO (genuine) and a Chinese clone CNC Shield v3. The firmware is the latest GRBL 1.1h. The shield has been setup with two Y drivers, cloning the A drive to be the other Y. The Z axis is also used The software used is the latest LaserGRBL and I am using that on several other machines without any issues. The machine has been tested and can move in all directions and the intended homing position is the front left hand corner and Z at max positive position. I am able to travel positive and negative until I do a homing. The homing is travelling in the negative direction. After homing I can travel only in positive directions, regardless of which direction I choose. I checked the wiring and was able to home successfully, but the X and Y will only travel in the positive direction, even if I select negative travel. I disabled homing and soft limits, and tried again after resetting the computer and the machine. After manually positioning the tool in the home position by hand and setting zero X and Y, I am able to move in both directions no problem. By setting the travel lengths to the numbers shown on the screen, I am able to travel and stop in the correct positions and using the home button, return to the zero X Y that I set. Once I turn on homing the problem starts again, so it must be something to do with the homing setup I think. I checked the limit switches and they are all OK . The homing direction is correct for my machine, but maybe it isn't?? I am homing to the front left-hand corner. Very thing appears to be as it should, until homing has completed and then I can no longer move in any negative direction, except for the Z axis.

My config settings:

$0=10 (Step pulse time) $1=25 (Step idle delay) $2=0 (Step pulse invert) $3=5 (Step direction invert) $4=0 (Invert step enable pin) $5=0 (Invert limit pins) $6=0 (Invert probe pin) $10=19 (Status report options) $11=60.000 (Junction deviation) $12=0.002 (Arc tolerance) $13=0 (Report in inches) $20=0 (Soft limits enable) Can only enable if $21 =1 $21=0 (Hard limits enable) $22=0 (Homing cycle enable) I turned this off to do further tests. $23=3 (Homing direction invert) $24=1200.000 (Homing locate feed rate) $25=1000.000 (Homing search seek rate) $26=144 (Homing switch debounce delay) $27=3.000 (Homing switch pull-off distance) $30=1000 (Maximum spindle speed) $31=0 (Minimum spindle speed) $32=0 (Laser-mode enable) I turned this off so I could test the laser without motion $100=40.000 (X-axis travel resolution) $101=40.000 (Y-axis travel resolution) $102=80.000 (Z-axis travel resolution) $110=10000.000 (X-axis maximum rate) $111=10000.000 (Y-axis maximum rate) $112=1000.000 (Z-axis maximum rate) $120=1000.000 (X-axis acceleration) $121=1000.000 (Y-axis acceleration) $122=100.000 (Z-axis acceleration) $130=840.000 (X-axis maximum travel) $131=420.000 (Y-axis maximum travel) $132=75.000 (Z-axis maximum travel)

Setting Value Mask Invert X Invert Y Invert Z 0 00000000 N N N 1 00000001 Y N N 2 00000010 N Y N 3 00000011 Y Y N 4 00000100 N N Y 5 00000101 Y N Y 6 00000110 N Y Y 7 00000111 Y Y Y

$3 – Direction port invert mask: binary This setting inverts the direction signal for each axis. By default, Grbl assumes that the axes move in a positive direction when the direction pin signal is low, and a negative direction when the pin is high. Often, axes don't move this way with some machines. This setting will invert the direction pin signal for those axes that move the opposite way. This invert mask setting works exactly like the step port invert mask and stores which axes to invert as bit flags. To configure this setting, you simply need to send the value for the axes you want to invert. Use the table above. For example, if want to invert the Y axis direction only, you'd send $3=2 to Grbl and the setting should now read $3=2 (dir port invert mask:00000010)

[SimonJohnCastle]

Are you sure your switches are wired correctly Normally Open/Closed ? if feels like the limit is permanently triggered.

[regpye]

The switches are all NO and they checked out when I did some testing. I have stripped down all the wiring and am doing it again to see if I can find a fault.

[regpye]

I am not getting many replies, so I stripped down all the wiring and started again. This time I only wired the stepper motors and the limit switches. I turned off homing in the configuration to do the first test. The X and Y motors needed reversing, so instead of changing the configuration file, I physically changed the wiring so that the motors moved in the right directions. I made sure that $3=0 The test showed that the machine can move in all correct directions if I move the laser head to the "wanted" home position first by hand. All working well so far. Next I turned on the homing and set it as default of $23=0. The test showed that the machine was trying to home in the top right-hand corner, which is not where the limit switches are, so I stopped everything and changed $23=3 which should be the bottom left-hand corner. I rebooted everything and did another test. The homing went correctly, Z lifted up, double bounced and then the X an Y proceeded to the lower left-hand corner, The Y stopped first and waited until the X reached the limit, stopped and both did a double bounce. All seems normal, no warnings from LaserGRBL. I then tried making a movement, and I could move both X and Y in the positive directions, but when I tried to go negative again, that is returning to home, the movements were both in the positive directions again. This has got me really beat, I feel I have checked everything and just can't work out what is going on.

[regpye]

I may have nailed the problem down? Because I was getting the repeated bad results from the hardware I was using, I decided to change all the electronics again. I used a new Arduino UNO, programmed it with the original GRBL 1.1h and then I tried again using the same CNC shield. Same problem. So next I also changed the CNC shield for a new one, checked all my wiring very carefully and tried again. Same problem. I was starting to think maybe the is something wrong in the software, so I opened up Universal G-code Sender and tried that. Straight away everything worked, I could home and travel in all directions without any problems. So next I closed UGS and opened up LaserGRBL again, and tried again. Back to the same problem, so to me it is something that LaserGRBL is doing.

[regpye]

Problem confirmed. I loaded an old version of LaserGRBL and tried that out. Works perfectly, so the new version has a jogging problem.

[dzamuga]

Similar here. Manually jogging X, Y no problem, but Z is running up/down randomly...