Hello, I use my X-carve daily at work. I grew tired of probing the tools through a terminal, so I wrote a Z axis probing program to send to GRBL:
$H
G20
G38.2Z-3.3F3.
G4P1
G10L20P1Z.588
G4P1
G91
G0Z2.8
$H
The tool gets set just fine, but anything coded after the G10 command comes back “ok” but no motion is produced.
If I restart the terminal or run another program, the machine works fine.
Is there some code I need to clear something or re-enable the motors?
I know there is a way!!
-EP
Why do you have multiple “$H” commands in the file?
I’m not sure why you have G4 commands in there either, they seem unnecessary.
You should be able to get by with just:
G20
G38.2Z-3.3F3.
G10L20P1Z.588
G91
G0Z2.8
Try that and see what happens.
Also, be careful with the G10. You have to wait for the “ok” from the G10 comes back before you send additional commands…it’s a GRBL and EEPROM thing.
Justin,
I home the machine before probing (since I have limit switches) and it is a good place to probe at in X,Y. The second home is just to get the Z up out of the way. The machine still doesn’t move after the G10 command in the example you provided. I am using simple_stream.py to send the code, I belive that it waits for the “ok” before sending, so that shouldn’t be the problem.
I’ve tried G28 and G30 since I have those locations set, still nothing seems to make the machine move except a restarted terminal session.
Strange…!
Do you have soft limits active?
I don’t have soft limits activated.
If your homing switch is less precise than your Z probe, which is likely the case, then you are throwing away probe precision by rehoming after probing.
Just use G53 G0 Z0 or similar to move the Z axis back up at the end.
Then I would find a way to make sure that your sending program does actually wait for the response to a command before you send the next one.
If I enter your commands by hand, they work on my machine.
Larry, I find the same success issuing commands manually. That is why I was confused about streaming the command in programs. There is a note in the GRBL wiki -known bugs- about G10 taking a bit of time to store things. I wouldn’t have called it a bug if it was just a limitation, but it does appear to be a bug since it gives an “ok” in the executed gcodes following it… I am 99% sure that the probe height was updated, and 100% sure that the rest of the program stopped executing physically while falsely showed “ok” after each command afterwards while nothing happened.
I will have to chock it up to G10 taking a few ms to store in EEPROM.
I will gladly compromise my wishes with reality, it will be really nice to hit a button on my raspberry pi and probe, another button to set XY zeros. Tired of typing, and I’m not an Easel user!!!
Thanks to everyone for their input!
-Eric
KPI Machining Inc.
Here is my solution to the probing problem. https://discuss.inventables.com/t/eeprom-write-problem/49782/3?u=ericpine
My bad, here is a re post:
I didn’t have time to tinker around, I forced the Gcode streaming script “simple_stream.py” to pause for a second between lines. It did however turn out that I had a soft limit alarm, so I disabled limits in my gcode program, probed, stored, re-enabled limits, got safely away, and sent the tool down to check function. Works like a charm!
It runs with a push of a button on a Raspberry Pi.
