I am trying to optimize the GRBL in my Shapeoko Pro. I am running CarbideMotinon Build 622 and recently upgraded my machine from the 65mm mount with the Z-Plus to an 80mm mount with the HDZ to carry a PwnCNC Air-Cooled Spindle. After working through a few calibration differences with the machine’s physical movements, I have moved on to working out the GRBL bugs.
More specifically, when I was running the 65mm trim router, whenever I loaded a file into CM and clicked Begin Job then Start, the machine paused for about a second and then moved to the front of the table and asked for a tool change before measuring the tool with the bit setter. The delay between clicking the Start button and when the machine moves forward to request a tool change has drastically changed since the upgrade, and it is incredibly annoying.
Therefore, I have set out on a mission to better understand the calibrations and settings within the Shapeoko. This has led me to watch dozens of videos and read as many articles, none of which address this particular action. The closest I have gotten was a video explaining what the G4P setting is, but that appears to be used while the machine is actively cutting. I have tried researching the GRBL command that reads N0G4P0.5, thinking this could be the culprit, but nothing in any of the videos mentions the N0 portion of the command, so I am not sure if that is where my issue lies. I want to reduce the latency between when I first send the command to begin the program and when the machine actually moves.
I have already checked with PwnCNC, and they told me it is a GRBL setting, but I cannot find anything in the GRBL commands that would improve this time. I would greatly appreciate the input if anyone has a suggestion on where to look or how I can achieve this. For good measure, I have posted my most current GRBL setup below:
$$
$0=10
$1=255
$2=0
$3=5
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=1
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=24000
$31=0
$32=0
$100=40.000
$101=40.000
$102=320.000
$110=10000.000
$111=1300.000
$112=1300.000
$120=500.000
$121=500.000
$122=100.000
$130=845.000
$131=850.000
$132=150.000
ok
N0G4P0.5
ok
$xG92.1G49G10L2P1X0Y0Z0G54G21G90
ok
ok
ok
ok
ok
Again, any help in understanding GRBL and how it works is much appreciated. Thank you.
As I am extremely new to learning what GRBL is and even newer to understanding what I am looking at. The line $xG92.1G49G10L2P1X0Y0Z0G54G21G90 populated when I entered $$ into the MDI line to see the current GRBL settings. Excuse my ignorance; I am not exactly sure how to check the lines of command directly after I push start. I am afraid to enter anything into MDI after the program starts, mostly because of my limited understanding of the GRBL function.
I believe the pauses are hard coded into the firmware build as part of the Run/Bitsetter cycles & none of the GRBL parameters have any influence on that. I would suggest trying the latest version of CarbideMotion(v6.40) as some significant changes were made to the machine behavior from v6.22(the version notes are quite extensive): Carbide Motion Downloads
Ok, new problem. I updated CM to Build 640, and when I run a homing path to initialize, everything is fine until the carriage moves all the way to the front. Where it would normally ask for a tool to be inserted, nothing happens until I click on Load New Tool then the carriage moves right and plunges to measure the bit on the bit setter but instantly rebounds all the way to the top of the HDZ and receive the following error message:
BS003: The BitSetter probe did not activate while probing.
This can be caused by several things:
The Z axis is jammed, and was not able to reach the BitSetter.
The BitSetter button is jammed.
The BitSetter is unplugged.
The BitSetter is damaged.
Please ensure the BitSetter LED turns red when pressed.
First, the Z-axis is not jammed and did initially reach the bit setter before rebounding and sending the message. Second, the bitsetter button is not jammed, nor is it unplugged. Finally, the light does turn red when it is depressed. I went to the settings to ensure the bit setter was enabled:
As you can see, it is. Next, I closed everything and restarted the computer. Once I was back online, I ran another initialization, and the same thing happened. I looked at the log and saw the following:
{
“bitRunnerEnabled”: false,
“bitSetterEnabled”: true,
“bitSetterX”: -3.5,
“bitSetterY”: -841.0,
“bitZeroType”: 2,
“connection”: 1,
“lastConfigSent”: 6,
“lastProbeIndex”: 0,
“lastSizeOption”: 0,
I am not sure what to do now except try to contact Carbide Tech Support. If anyone has another suggestion, I would love to hear it. Thank you for taking the time to read over this post.
After that last post, I realized that I might need to set up a new machine and download the configuration again. After doing that, it seems to be working fine now. I haven’t run a new toolpath yet, so I will see if the annoying delay (Dwell Delay) between clicking start and when the carriage moves is still there. If so, I will keep researching to see if there is a way to change the dwell time settings. If not, I guess I will have to live with it, but it is really, really annoying, kind of like fingernails on a chalkboard.
If there is no dwell (G04) in your G-code, and you’re seeing one when you hit “Start”, then it’s CM that’s sending it, and there will be no way to change it. (That I know of). It may be their way to ensure the command buffer on the machine is full before proceeding (???)
I haven’t looked at the log in quite a while while running. If I get a minute I’ll run out & see what it’s doing. I don’t remember seeing a dwell after a $$ MDI command. And the G10 I think would only happen when setting a zero. ??
OK, I’m seeing at least 4 (G04P4) commands. One at start, one after each M3 or M5 command (Spindle On/Off). So it’s CM sending them, and that means no way to turn it off or adjust the dwell.
Yeh, there are 2 unneeded Dwells at the start. One at the beginning of program, and another with the initial M5 (Spindle Off). Then another after the M3 (Spindle On).
