Long gcode files

I’m a newbie trying some intricate carving using Vectric’s photoVcarve, but the gcode files are very long and I’m having trouble getting an entire file to send to the X-carve.

I’ve tried UGS, but it throws a “null” error and stops about an hour or two into a longer job. I haven’t had much luck with Chilipeppr either, and I read that it has a file limit and wasn’t designed with really large files in mind.

The gcode was generated using the vcarve post processor. I’ve been trawling the web to find out why the files aren’t working, and even went so far as to send sample files to Vectric for validation - they’re long but OK. But I’m still blocked.

Anyone have any experience and suggestions for the best way of getting long gcode files to run to an X-carve? UGS settings, other software, etc?

Haven’t done too much of this, but is it possible to break the code into chunks and run them sequentially?

bCNC has been tested by the lead Grbl developer and found to work well and reliably for longer jobs:


The other option is the gctrl sending command line program which is used to test Grbl w/ long files.

Our Windows PicSender streamer program has been tested to run up to 10,000,000 lines of raster gcode files reliably.

There are some X-Carve owners use it for engraving Lithophanes in this thread.

1 Like

If you’re running long Picture files, you definitely need PicSender. It is very reliable and low cost solution.

1 Like

I second using PicSender!

1 Like

I am absolutely getting PicSender and testing it out tonight. Thanks very much for the quick feedback and links, much appreciated! bCNC looks interesting also, and I may try that as well.

My test job from Easel worked great, so the machine is set up and working properly, now just need to get the software so I can do what I really want to do. :smile:

This probably isn’t the problem you are having, but it may help later down the road with those big g-code files… make sure that the computer sending the g-code won’t go to sleep and will keep the USB port active.

1 Like

I tried PicSender, and I’m still having problems. Maybe somebody here can help point me in the right direction.

  1. I generated a small (about 1.6MB) .gcode file from PhotoVcarve using the generic Gcode postprocessor. The job used a 1/8" ball nose to 1/3" cut depth, linespacing set to 50% as a rough cut.

  2. Checked the .gcode file with a file checker (can’t remember the name of the program at the moment), and it seemed to parse fine. It traced the tool paths onscreen, and nothing looked incorrect.

  3. Used PicSender to serve it up to my X-carve. I placed the bit, zeroed out my XYZ, and ran the file.

  4. At first, it all went fine, properly starting at the bottom right and moving up and left at a 45 degree angle. But then it went wonky, and started bringing the Y axis much too far down. I watched the thing go for a couple of minutes, then killed it. See image below.

  5. OK, so that didn’t work. Maybe if I use the X-carve for Vcarve Desktop postprocessor. Oh wait, PhotoVcarve won’t load, it throws an error on startup. So I found a tweaked version of the postprocessor (with arc parsing commented out, I believe), and generated another gcode file, this time saving as .tap format.

  6. Again using PicSender, served it to my X-carve. This time it went crazy earlier - see below.

  7. All righty then. Mechanical problem? Nothing felt too loose or tight. So without changing anything on the table, I created a quick circle and two stars design in Easel and carved that job. It took about an hour, but turned out perfectly. See below.

    Since Easel is properly cutting jobs, it seems that the machine is mechanically in OK shape, and the gShield and Arduino are working properly. The only variables are the program that generates gCode (Easel vs PhotoVcarve) and the gcode sender (Easel vs UGS, Chilipeppr, and PicSender). To make sure the Photovcarve files are OK, I sent a sample one to Vectric, and they validated the file was OK. So I don’t think it’s PhotoVcarve - although the postprocessor might be an issue.

The only thing left, in my mind, is the gcode sender. I’ve tried three, and none work on the type of file I’m trying. I did manage to get a very small (2"x2") Photovcarve job to cut, but anything bigger starts going wonky.

I checked my Windows 10 machine, and it’s set to never sleep while plugged in, so it’s not that. I’m at a loss at this point, since I really need to be able to generate and send large gcode files… using only Easel isn’t really an option for what I want to do.

Any thoughts or suggestions on what to look for are most gratefully accepted.

It sounds like a post processor issue…try the X-Carve Photo Carve post processor (has inches and mm) from this thread:

I’ve used these post processors with Photo Carve with success…although I must say that I’ve only used Photo carve 2-3 times thus ar.

Yep, those are the ones I tried (inches) - the second try was even more mangled than the first using the generic gcode postprocessor.

Ouch…I’m at a loss. I also re-read what you posted and saw that you’re using PicSender, and I have no experience with it. I’ve used UGS for larger files (500K lines or so), but I had to use the Nightly Build in order to do so. Version 1.0.8 gave me issues to where the job would freeze at about 60% completion.

My first tries were with UGS 1.0.8, and it also froze after about 1.5 hours, which is when I started looking elsewhere. Maybe I should try the nightly build.

It is definitely worth a shot! I had have zero major issues with the nightly build. The only issue I’ve run across is that when I have to cancel a job (because I goofed up), when I go to jog the machine around, it’s stuck in millimeters no matter what I do. So the fix for that is to close UGS, re-open, and all is well.

It has to be something with how the post processor generates the gcode, or it’s loosing steps during the cut. Charley in the Lithophane thread uses Aspire for his image engraving, so his PP may generate the gcode differently. The issue he had was with loosing steps and needed to adjust the pots for the steppers on his gshield to correct it.

Also open the PP in a text editor and check if these variables are set this way. With this setting, it will generate all axis moves on every line of gcode, even if an axis position has not changed from one incremental step to the next. Our image to gcode programs generate the gcode this way because we found it runs smoother with grbl. A stands for All and C stands for Change. Leave the feedrate to C since PVC does not have a variable feedrate feature like our PicEngrave Pro 5 has.


In PicSender use the GRBl Z Code and Position Sent options.

For setting to Inch units in the startup block, type in $N0=G20 into the Do. Cmd window and select the Do Cmd. button. Also to set a default jog feedrate, type in $N1=F50 the same way. Set $13=1 (report inches, bool) this way in the grbl settings for inch units


IME, short jobs running okay, while longer jobs fail w/ mis-positioned (usually too small) cuts, usually comes down to marginal current settings on the driver, or not quite tight enough belt tension.

Thank you for the detailed suggestions - I’m going to run this as soon as I get back to my workshop (on a business trip so it’ll be a couple of days).


So, I did the following actions, and now the machine is working as expected:

  • Adjusted the potentiometers as described in this helpful post (my current was low, especially on Z, so it bogged down easily)
  • Tightened the belts again and triple-checked all the V-wheels so there was no slop in movement
  • Adjusted the Vcarve post procesors as picengravertoo suggested
  • Ran PicSender with the suggested settings
  • Nearly perfect rough and final passes!

The only problem I had was using the wrong bit and it ran too fast, too deep per pass, so the bit broke, but that’s a separate problem I can deal with. All my hardware and software issues seem to have been solved.

I also bought the PicSender software, and am very happy with it. A very inexpensive addition to an expensive hobby.

Thanks very much for everyone’s advice! As soon as I get a finished piece together, I’ll post it in the gallery.


Good to hear you got it resolved.

We have a program called PicFRC that adds a variable feedrate to a gcode so it will slow the bit in deeper cutting areas and speed up the bit in shallower cutting areas. This reduces the chip load and minimizes the risk of bit breakage. We written it for our PicLaser Lite & PicLaser (released today) image to gcode programs and have not tested it with any others.

Download the Demo and run your PhotoVcarve gcode file through it and open in a text editor to see if it properly adds the variable feedrate on each line of gcode. In Demo mode it will only do half of the gcode file’s lines.


Or if you wish, zip the gcode file and send it to the PicSender Registration email and I can test it here and if it works properly, I can email it back to you with the variable feedrate added for you to test.


Pretty nifty - I will try that.