I’m trying to switch to CNCjs as I’m looking to be able to implement more advanced automatic probing than I can accomplish with Carbide Motion. I started with the @neilferreri macros (CNCjs-Macros) and adapted them slightly for my needs. I ran a job using them this morning and they mostly worked well with one fairly annoying problem.
Each time I was prompted for a tool change, it seems like the planner queue is not empty when M6 is executed. Immediately after being prompted for a tool change, I executed the “new tool” macro and it hung on the %wait. The first time, I ended up doing a jog and running it twice more before finding that a G0 X0 unfroze it (and executed all the other things I had clicked on).
Each of the following 5 tool changes required either 1 or 2 of my unfreezing G0 X0 commands to be typed into the gcode widget.
Aside from that, it worked perfectly. Is there something I’m doing wrong or some configuration that will make it empty out the planner queue when it pauses for the M6?
If anyone wants them, my macros are also on github. The big change in the macros is that you don’t need to remember to run “initial tool” when you change the Z zero. You can zero at any time without interfering with the “new tool”. If anyone wants to change their version, the change to do that is pretty small.
They work with the caveat that mine and @neilferreri’s versions both hang for me when I run them (the first thing it does is wait for the “planner queue” to be empty and it’s not). I don’t know why they hang for me when they clearly don’t for other people.
The %wait is just a G4P0.5… It’s mainly there to make sure things don’t hang and eeprom writes don’t get corrupted.
Try throwing some console outputs for sanity checks to see where you’re hanging. I’ve never seen this issue with CNCjs or gSender.
Yeah, it’s stuck on the wait (the gcode console shows G4P0.5 as the last line executed).
I’m running another job right now and it actually does the same thing even on the first tool change of the job. Aka, the only gcode that had been run in the job is
G90
G17
G21
G28 G91 Z0
G90
T9001 M6
and I still had to type G0 X0 to get it to continue. Very strange and I was hoping it was something that had come up before but I guess not.
9001 is not a valid tool number with Grbl unless you modified the source. Tool numbers only go to to 255.
Any errors popping up? That might be causing some issues.
Thanks! I think that may be it. I just did a quick test:
start the last job which failed to run the macro correctly
see it still failed
rename the tool number and start the job over
see it now works
Which is rather rough because I have been using a convention where the 1,000s digit identifies the vendor and now I have to go and rename all my tools in all my recipes. Sigh. Thanks for the help!
PS - You may want to check out the commit I linked. Makes the workflow a lot more idiot proof as you don’t need to remember to rerun Initial Tool when you change Z.