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 more 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)
Have I done something wrong, any other way to test my setup?
Windows version 10
Engraver brand and model DIY
Grbl version 1.1h
LaserGRBL version latest
That’s weird. What controller and drivers are you using?
The drivers have a DIR pin. If that isn’t getting inverted. Then it won’t go reverse. But that doesn’t explain why it works sometimes and not others. The homing is a particularly sensitive process that needs to be to move in both directions at sopecific times.
Is the grbl firmware you have on it something you flashed from the main grbl repo?
I am using standard GRBL 1.1h and CNC shield and a Uno V3 board.
I rewired all the steppers again with a heavier cable and tried again.
It worked properly until I did a machine home, which worked as it should, but after the homing I was unable to go in negative directions again.
Maybe I have a bad stepper that has a faulty lead or something, or it could be a faulty board.
I have a few spare steppers and a few spare boards so I will do some swapping out to see if I can eliminate the problem.
But first I will check all plugs and sockets to make sure that all connections are good.
Okay, I checked all connections and before taking off any stepper motors I thought I would try again.
It appears to be a homing problem because I tested several times and the same thing happens each time.
If I start the computer and open LaserGRBL and connect and do not make a machine home everything works fine. I have tested this a number of times without any fails.
If I do a machine home which seems to work as it should, going in the right direction, touching off and then retouching again, that is when the problem starts. I can from there on only travel in positive directions.
If I shut down the computer, disconnect everything and reconnect, fire up LaserGRBL and try everything again, a repeat of the above each time. Everything works until I do a machine home.
I guess I have to read up on homing some more, but I don’t understand what and why it is happening.
I haven’t done an accurate test yet, but from rough measuring it is all correct. I will fine tune the settings once I have worked out this first problem.
I’m not familiar with LaserGRBL (I use LightBurn), but it sounds like LaserGRBL may not be commanding the equipment to do what you want (after homing). Is there a console/machine output you can view?
Guessing… it could be that the machine area is not configured correctly. It would make sense that it would “do whatever” you told it before homing, but once homed, start enforcing what it thinks are the machine’s limits. Essentially, soft limits implemented in LaserGRBL. Again, I’m not familiar with LaserGRBL so just guessing.
I would (a) check the machine size definitions in your LaserGRBL config to see if they match your config in $130 and $131 (of 840 and 420, respectively). I would also (b) try just moving 1mm at a time to see if it moves.
…also your 2nd last post has me unclear on whether you can only command travel in positive directions, or if it still moves in positive directions when commanding negative direction moves.
I am trying to move in negative directions, but it goes forward.
I can ask it to go positive or negative and it always goes positive.
Only happens after a machine home.
I don’t use GRBL nor LaserGRBL, but one possibility is that your homing code is not setting the coordinates correctly. That, combined with absolute movements could cause the behavior you describe. Or is it possible that you don’t have the home location set correctly? That possibility combined with inverted steppers could cause the behavior you describe.
Home the machine, then have the machine report it current position. If either of the above two is an issue, you won’t get (0,0) for the X and Y position.
I would try sending G01 commands directly to eliminate lasergrbl. It sounds a lot like when repetier host gets confused by our G92 and moves to where it thinks 0,0 is, but is really far away.
Thanks Jeff,
I have tried that several times. If I don’t do a machine home it works 100%. I just send a manual command and it works, and if I hold the wpos Home button, it will return to the wpos home each time, until I have done a mpos home, then all movements from there on are only positive direction. I have to close down the system and restart to get back to working again.
Very strange and I am not able to find anyone that knows what is going on.
In desperation I just tried something.
I downloaded and installed UGS and using the same wiring, same GRBL settings it all works fine as it should.
I can’t understand what is going on here.
Setting mpos (or homing) should be changing the wpos. I think of wpos as a transform from mpos to wpos.
I think in your first post you described setting mpos (with home) then wpos (manually) then jogging and it was borked. But if you are doing it in the opposite order. Then I would have a hard time determining where it would go.
A couple of things:
Can you tell from the command line what lasergrbl is sending and ugs is sending and how they are different?
When it moves in the wrong direction, do you let it finish? Does it move the correct distance or something weird?
I think you are narrowing it down. Make sure you post the solution when you figure it out.
I will definitely post the final results.
I have a few more things to try, but will take a few days more to do it all as I have other things that need to be done outside of this.
All movements are “about” the right distances as I have not fine tuned the steps yet, but they are close and although after doing a mpos home and all going in the same positive direction, the distances are consistent with travel lengths.
Using LaserGRBL (latest version) and after doing a mpos homing the arrow direction buttons only work in a positive direction.
Before homing the machine will work flawlessly.
I tested my machine using both LaserGRBL (latest version) and UGS
I just tried both softwares and found out that LaserGRBL seems to be the problem.
It all works fine in UGS but the problem happens in LaserGRBL so I zoomed out on the work area shown on the computer screen so I could see the cursor that represents the tool.
When I have homed and use the direction arrow buttons the cursor moves only in positive directions. So this shows me that it is NOT a hardware error, but a software error, because if it were the reverse the cursor would move in the pos and neg directions when asked.
I am using LaserGRBL. $H can be sent as a texted command of by using the homing button. I do not include it in any gcode,
Before homing I can use the arrow direction buttons to move the laserhead. I can also insert text commands.
All of these work perfectly until I do a homing cycle with LaserGRBL.
After that all direction arrows are in the positive direction, whether I use positive or negative direction arrows.
The strange thing is that if I load a file and send it out it will work okay, I just can’t jog anywhere using the software.
If I disconnect and reconnect again and don’t do a homing I can set a wpos home and it all works fine.
The only other thing I can think of is what do you have set in the GRBL config.h around the homing? As this is a laser machine do you have any (unwanted) reference to Z homing in the config.h file? (the default setting is to clear Z before moving x or y - perhaps that is messing with the homing?)