I just wired up a new machine and when commissioning it I found a strange problem.
I can home no problem. When I move the X axis in a positive direction it works fine but when I try to move back again in the negative direction it goes positive instead.
Same with the Y axis.
The Z axis works fine both up and down.
I loaded a file after homing and then moved in the positive direction to about the centre of the table.
I then tried framing the loaded file and it frames correctly moving in a positive direction and a negative direction.
After doing a machine home, I can move X and Y in a positive direction and then set the work home at zero. If I move X and Y in a positive direction some more (can’t go negative) and press the work home button, the laser head will return to the set work home position (which is a negative direction)
I have tried many times to locate the source of the problem.
After many tests I have found that if I don’t do a mpos home, everything works fine, I can go back and forth in any direction and by pressing the wpos home button can return to the home position.
One I do a mpos homing the problem starts, I can only move in a positive direction for X and Y, the Z works okay up and down.
I have checked and rechecked the wiring and found no errors of loose connections. The limit switches work okay.
Have I done something wrong, any other way to test my setup?
I’ve had strange problems like you. Y will be backwards for no apparent reason, then I home it and it works right again. Also, it seems that I have to click on the get position because it doesn’t want or is slow to update its position.
Mine is also a homemade machine running grbl 1.1h and Arduino uno.
Does it happen all the time? Mine does, so it isn’t some random problem. Yours maybe a loose connection on a plug or socket, unless it always happens, then that is cause what we have to work out.
This may be due to the acceleration being too high, causing the motors to lose sync with the drive pulses when they start up. Stepper motors will happily run backwards, particularly if the final speed is relatively low.
Reduce the axis acceleration settings in $120 - $121 by a factor of 100 and see if the situation improves. If so, then double the accelerations until the axes misbehave and drop back by a factor of two.
If it’s a gantry machine with the usual layout, the final Y axis acceleration will probably be lower than the X axis, because the motor must accelerate the entire gantry.
Thanks for that tip, I will give that a try.
I also found in config.h the following that might have something to do with it all.
// After homing, Grbl will set by default the entire machine space into negative space, as is typical
// for professional CNC machines, regardless of where the limit switches are located. Uncomment this
// define to force Grbl to always set the machine origin at the homed location despite switch orientation.
// #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable.
Depends on your configuration. In general, you should enable this. I recommend it for every diode laser machine using the homing to bottom-left. You can also use software settings to compensate this, but using the mentioned option makes life much easier. I wrote some documentation about this here: Limit Switches - Diode Laser Wiki
This morning I used UGS wizard to configure the settings in GRBL.
In UGS the machine works properly and does a homing and then the arrow direction keys all work as they should.
I exported the settings and carefully copied the content into a text file.
I renamed the text file to be a .NC file and loaded that into LaserGRBL and ran it.
LaserGRBL inserted all the 34 commands into it’s setting with no errors.
I then rebooted the computer and open LaserGRBL again and connected to my machine.
I didn’t home to start with. I just tested the movements with the arrow buttons and they all worked fine.
I then did a homing cycle and the homing worked as expected going to the front left.
I then tried using the arrow buttons and again the movements are only positive even if I use in the negative direction.
If I keep moving in a positive direction until I reach positive space the arrow buttons will work in the negative direction.
The settings exported from LaserGRBL that are giving the problem, but only in LaserGRBL:
There is a misunderstanding here. The settings you are referring to are actually stored in the machine. They are neither stored in UGS nor in LaserGRBL. LaserGRBL reads the configuration from the machine (and also can write it), but there is absolutely no configuration stored in each of the tools.
So the step you did does not make any sense, since you took the settings you stored on the device and stored it on the device again.
You still have the wrong coordinate space configured in your laser. After homing, the position is not set to 0,0. You only need to change this.
I pointed you to the guide that explains all this. Do a homing cycle and then send G10 L20 P1 X0 Y0 without doing anything else in between. (Edit for completeness:) afterward, send $10=0.
Thanks for that info, I must get this sorted.
I really don’t understand a lot of this, I used UGS to set the machine up and it worked fine. Those setting you say are stored in the machine, correct?
That means that using any GRBL program should work the same in my thinking.
Why does it work fine in UGS and Gsender, but not in LaserRGBL?
What you are telling me is to set a G54 position, is that correct?
Because UGS and Gsender are designed for CNC machines and not lasers. Those machines use an origin at top-right corner and are configured to use negative coordinate spaces. LaserGRBL expects the origin at bottom-left and a positive coordinate space.
That commands sets the G54 coordinate offset. You also need to set $10=0 to enable the positive coordinates to be reported at all times.
Okay I have tried that as you said and it is still in negative space.
I even rebooted to make sure.
I did a homing and then entered the G10 L20 P1 X0 Y0
$10=0 was set as well before I tried the second time.
Still in negative space.