Strange problem

[regpye]

This one has me puzzled, maybe someone can help?

I am setting up a new laser engraver, using GRBL, Arduino UNO and CNC shield. The shield has a double Y using cloned A driver.

I had all the setting done correctly I thought, I could move the machine in all the correct directions and then I came to doing the homing.
I pressed the homing button and all moved in the right directions, Z was OK, Y gave a problem (not worked that one out yet) and X didn't complete due to Y having the problem. I will check out all the wiring and connections tomorrow when I have more time as it is late here now.
The strange problem is that after trying to home, the X and Y axis will now only move in a positive direction, no matter which direction I try to move in. The Z will work OK in both directions.
I reset the program (LaserGRBL) and I even closed the program and restated it again, shut the computer and the machine down and restated them again, but still the problem persists.
I am at a loss to work out what has happened. I guess I wont get much sleep tonight thinking about it.

[AndyUK]

Is the direction that they now only move in the same direction as they move when homing?

It may just be that the settings are all screwed until it completes a homing cycle correctly. e.g the machine thinks its in some stupid position, and will only move towards it's expected correct range. Maybe X thinks its at -1000 and knows its only allowed to be -500 to +500, so will only move +ve until it thinks it reaches -500.

First thing to try is disabling soft limits. That should prevent the system babysitting your positioning.

[regpye]

Is the direction that they now only move in the same direction as they move when homing?

It may just be that the settings are all screwed until it completes a homing cycle correctly. e.g the machine thinks its in some stupid position, and will only move towards it's expected correct range. Maybe X thinks its at -1000 and knows its only allowed to be -500 to +500, so will only move +ve until it thinks it reaches -500.

First thing to try is disabling soft limits. That should prevent the system babysitting your positioning.

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 this morning and found that the Y axis limit was badly connected. This caused the homing fail. I fixed that and was able to home successfully after that, but the X and Y will still 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 and setting zero X and Y, I am able to move in both directions no problem. But 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 now.
The homing direction is correct for my machine, but maybe it isn't?? I am homing to the front lefthand corner.

[regpye]

Is the direction that they now only move in the same direction as they move when homing?

It may just be that the settings are all screwed until it completes a homing cycle correctly. e.g the machine thinks its in some stupid position, and will only move towards it's expected correct range. Maybe X thinks its at -1000 and knows its only allowed to be -500 to +500, so will only move +ve until it thinks it reaches -500.

First thing to try is disabling soft limits. That should prevent the system babysitting your positioning.

Do you think this could be a software problem or a firmware or hardware problem?
Can move in all correct directions right up until I do a homing. The homing completes in the correct way, but after that I can only move in positive directions.

[Clive S]

Do you think this could be a software problem or a firmware or hardware problem?
Can move in all correct directions right up until I do a homing. The homing completes in the correct way, but after that I can only move in positive directions.

Can you post the config file as that will help,otherwise we are just stabbing in the dark.

[regpye]

Can you post the config file as that will help,otherwise we are just stabbing in the dark.

Good point; Here it is:

$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)
$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)

[Clive S]

To me its strange that there seems to be no individual setting for X and Y inverts etc.

re
$3=5 (Step direction invert) ... Is 5 the correct number ? I would have thought 0 or 1 !!
$4=0 (Invert step enable pin)
$5=0 (Invert limit pins)

$20=0 (Soft limits enable) ... Is this enabled or disabled ?
$21=0 (Hard limits enable)

Sorry I don't know much about GRBL

[regpye]

To me its strange that there seems to be no individual setting for X and Y inverts etc.

re
$3=5 (Step direction invert) ... Is 5 the correct number ? I would have thought 0 or 1 !!
$4=0 (Invert step enable pin)
$5=0 (Invert limit pins)

$20=0 (Soft limits enable) ... Is this enabled or disabled ?
$21=0 (Hard limits enable)

Sorry I don't know much about GRBL

You need to view the table that comes with GRBL to work out that question about $3=5 It is actually settings for reversing the XYZ motor directions without having to physically doing it with the wiring.
29731

anything equal to =0 means disabled, =1 is enabled , other numbers are from the table above and are used in several of the settings.

[Clive S]

You need to view the table that comes with GRBL to work out that question about $3=5 It is actually settings for reversing the XYZ motor directions without having to physically doing it with the wiring.
29731

anything equal to =0 means disabled, =1 is enabled , other numbers are from the table above and are used in several of the settings.

Ah but the table did not show up in my crystal ball

[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 it works perfectly, so the new version has a jogging problem.

[Doddy]

I bet you swore at that point :)

[regpye]

Still swearing, still not fixed as it is a software problem!