I have the same issue with not being able to do anything after running a program without doing the soft reset. It’s a bit of an annoyance, especially in the event that I want to maintain my workpiece home settings. I thought maybe the gcode I was generating from Makercam was leaving out something at the end of the code. Anybody have any thoughts on that?
The soft-reset is because of Grbl, not because of ChiliPeppr or UGS. Grbl loves to put itself into an alarm state. It frustrates most of its users. Just make sure your Gcode generator doesn’t put any end of file commands like M30.
@JohnLauer : Grbl’s alarm state is there to make sure the user knows when everything is operating as it should. It’s the standard practice on all machine controllers, including LinuxCNC and Mach3.
For reference, Grbl’s alarm state mainly occurs when Grbl doesn’t know its position. For example, a power cycle on the Arduino will do this, because stepper control is open-loop control. You have no position reference upon startup, as is the case on ALL stepper-based motion controllers. Or, if the user has stopped the machine while its moving or hits a hard limit, this causes an uncontrolled deceleration. This means that there is likely lost steps and there is no way to tell how many are lost. Hence it goes into alarm.
I just want to make this absolutely clear. The alarm state is a necessity. While it can be annoying, you have to have this to ensure that the user knows when the machine is running correctly. Otherwise, you can ruin your workpiece if you continue a job without it.
For example, you can be cutting an expensive piece of hardwood for 8 hours or machining a metal part that has multiple operations over days. I think this slight annoyance is worth its weight in gold.
An Grbl error ID 24 is an ‘axis command conflict’. This generally means that you have two g-code commands that both require the XYZ axis words. Since both require them, it’s undefined to which ones get the XYZ words. You’ll need to look at the problem g-code line and fix the problem by separating out the two commands.
You may have an M30 or M2 ‘program end’ at the end of your g-code program. To fix, just click the ‘~’ resume button, rather than soft resetting.
Grbl pauses the job when it receives a ‘program end’ command to prevent any other commands from moving the machine. This is keep the machine from doing something after the job completes, when you are often not around the machine.
This behavior is part of the g-code standard, but the problem is that GUIs have to do half of the work. Grbl can’t control what the stream of g-code so it has to pause the job. Unfortunately, Chilipeppr doesn’t adhere to the g-code standard very well and needs to show the user what is going on or automatically send the resume command to grbl while managing the streaming state itself. UGS, I believe, does manage the ‘program end’ well, so it’s no surprise that it works on UGS and not Chilipeppr.
I think the default behavior on an M30 or M2 should not be to pause the job, but rather do it the way TinyG does it. I think over the last year I’ve had more questions on why Grbl stops working after a job than possibly any other question. I don’t think pausing a job helps or adds any safety. I’ve never seen any Gcode actually have lines of Gcode after an M30 or M2.
I am successfully using ChiliPeppr to jog my machine, but when running pasted gcode it pauses after 10 lines. The code keeps buffering, but the machine will not move more unless I click Cycle Start “~”. Even then it will only execute one line before pausing again. Any thoughts on what might be the problem?
Otherwise I am pleased with the features ChiliPeppr offers and am working on customizing my workspace!
I had the same problem with Chilipeppr I like the way it looked but It would tell me to choose the processor in the pull down first and I would but it still wouldn’t work gave up and just use the grbl 8 works great