Not enough power to send g-code fast enough to machine

I had a spare Atom based laptop laying around so I decided to put Windows 8.1 on it, disable everything possible to increase performance (disable unneeded services, programs, etc from running) and essentially make it a Carbide Motion dedicated system. Unfortunately I quickly found out that it simply can’t keep up with the g-code and stutters during the job. The job completes fine, but definitely stutters consistently.

My other machines are way overpowered for the Nomad (not a bad thing, it’s just that I don’t want to make them my dedicated CM system). Does anyone have a solid recommendation for a cheap laptop or small desktop (I would attach a small touchscreen to it if a desktop) that can actually run CM without stuttering?

I’m a bit surprised that the 1.5 Ghz Atom based system (2GB RAM) can’t handle the feed.

@dyelton : Not sure if its a problem of being under or over powered. It might be the type of job you are running. If your g-code program has a lot of very small line motions that have a high feed rate, Grbl can get buffer starved. This most often happens when G2/3 arcs are auto-converted to G1 line motions with very small and unrealistic lengths, like 0.1mm each.

Generally Grbl should be able to execute most anything. If you are still having problems, you can always try another gcode sender like bCNC, which will run very well on even a Raspberry Pi.

We list other comm / control options on the wiki:

Carbide Motion shouldn’t be that demanding an app though — I’d suggest contacting and mention your difficulties, and offer your file as a test case. To verify your hardware you could use one of the scripts, gctrl or

The official system requirements don’t mention CPU:

FWIW, the same code runs perfectly when sent from my MacBook Pro. CPU, RAM, etc aren’t maxed out when sending from the Atom based laptop.

So odd and totally unexpected… @ApolloCrowe

The HP stream 7 Tablet is around $100- $150 and works great as a dedicated CM station.
Something else is going on if you have stuttering, this usually only happens if you have the Log window open or are using a USB hub.

It may just be that the hard drive or the USB port are the issue. USB hubs can be glitchy. Hard drives that are old sometimes really run slow and most of the g-code senders I have read code in don’t have much of a read-ahead buffer from disk before sending to USB so if it is lots of tiny lines it may not read from a scattered disk well.

Have you tried other USB ports on the same computer by chance? Maybe one of the ports works better, sometimes they are separate USB hubs internally.

If it’s not any of these it’s probably because the lack of RAM is causing the computer to page in and out the memory to the hard drive during this operation which more then likely is not something you can fix unless you buy more memory for it. Check the hard drive light when it’s sending. If it’s blinking rapidly or solid on, more then likely that is the issue. It should just blink every so often as it reads a chunk of the file.

I’ve run pretty complex 3D milling from a raspberry pi 2 and had no problem?!

I’m not sure the price is worth it for me to really investigate heavily. I’m considering getting a Chromebook with a touchscreen and using this:

Look at USB drivers,ditch the Intel USB 3 root hub controller if you have it installed,it will revert the ports to USB2 but is much more stable
Open Task Manager,Click performance tab,leave open and run job (you can just air cut),look at what is being taxed and what is already running in the background.