Manually adding two post processors (mm and inch) to;
C:
ProgramData
Vectric
VCarve Pro
V8.0
PostP
After carrying two files, you have to start VCarve again. This time you can see post processors for X-Carve
Oups, I didn’t see Peter was already post the answer. Sorry.
Back to Chilipeppr. Noticed this error while cutting some air. Anyone know what it is/how to fix?
error: Invalid gcode ID:24
I have been having very good luck with it lately, looks like the JSON server problem finally worked itself out. Or something. It’s working now, in any case, with two annoying exceptions.
1: The jog functionality is only occasionally functional.
2: After running a program, I can’t do anything else until I soft-reset the GRBL. This doesn’t happen with UGS, and I’m not sure why.
Still not enough to keep me from using it, just annoying.
I also noticed that the DRO’s don’t work anymore.
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?
I don’t think that’s it, because code from VCarve and Fusion360 behaves exactly the same way…
I have the “soft-reset” issue even with UGS actually.
Very interesting… Huh, I wonder if it’s something with GRBL, then?
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.
The issues I’m finding are related to the post-processor of my CAM app. The first was to disable arcs. Next was G64 and G40. Still working through it with Jarret.
It probably helps not at all, but I’ve had no problems at all running ChiliPeppr with the X-Carve. But there again all the gcode is exported from Easel which is obviously geared for Grbl.
I do this so I can modify Z movements to laser on/offs to drive a laser for marking/cutting. Happily running jobs with over 3/4 million lines/hours of runtime.
I think ChiliPeppr is an excellent package for me, would love to see some its features in Easel.
Cheers
Ian
Ah, that did it! Thank you for the pointer!
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.
Hi John, For non-metallic probing can I hook this up and use it with chilippr?
http://wildhorse-innovations.com/index.php?_a=viewProd&productId=80
Yes, that probe should work fine. I’ve never seen one that cheap. Good find.
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
