Arrow key movement of gantry

The minimum move tinyG can make in the X direction is the distance moved in a microstep.
That is 60mm_per_rev/(200 steps/rev *8 microsteps/step) = 0.0375mm

If your Jog increment is set to 0.1, it will take 3 pushes of the arrow key to yield a 0.1mm move, with some remainder.

If my quick math is correct, if your setting is 0.1, it will take three arrow pushes to get a move, 3 more to get a second move, but only two more to get a third move.
Welcome to the world of quantized movement

What jog increment setting are you using?

I would suggest you set $_pm=2 in-cycle for all 4 axes.
That will improve accuracy, but probably not affect what you call stuttering.

Did the Chilipeppr logo run OK?
There are other test files in the tinyG workspace – they stutter too?

Sort of difficult to tell, is the cut pattern relatively (or very) accurate?
Perhaps post your Gcode file for a look-see.

Nice looking machine, by the way

Table shaking, particularly with the relatively heavy spindle you have, is not unusual. It one reason I migrated to a 400W quiet cut DC spindle, my original dewalt was overkill for what I was doing.

You experiment by reducing the values of $xjm and $yjm from 5000 to , say 500, a dramatic reduction in ‘aggressiveness’. Run the job in air(or on waste material), see if you can discern a difference in shaking between 500 and 5000.
If you milling speeds (F speed) are relatively high, that would increase shaking as well,
Run a separate experiment, using the Gcode widget to slow speed down by factor of 0.5

• This reply was modified 8 years, 6 months ago by cmcgrath5035.

Just watching the video, I might guess that CP is not keeping the buffer full, tinyG is stopping, waiting for more instructions.

Describe your CP setup (OS, SPJS host version and OS, etc)

As your Gcode is running (just run in Air), do you see strange variations in the fubber status from the CP display, particularly during an area where Gcode stutters

Can you post your Gcode, or a piece of it long enough to produce stutter, so we can try it?
Copy to a CLoud Drive and post URL.

Sorry, buffer status (actually, the number of buffers left available for use).
It is a maximum of 32, if SPJS is doing it’s job keeping tinyG filled the number of available buffers will be low.
If SPJS stops streaming commands, the available buffers may spike up, a pause (stutter) occurs then streaming of data continues.

Wow, it has been a long time since I ran the file.

Turns out it has no real setup code, such as a G21 to say it is mm code.

So if you were in G22, inch mode at the time, it took off for 6″ when it was authored for 6mm. Good thing it hit a limit – It would have headed for 1 inch deep next.
Sorry about that.
The code was actually developed to run on the original, rather small, ShapeoOko1.

It did not have an M03 to turn on the spindle either, sorry about that too.

I edited the file to add a G21 and Mo3 at front end, M05 at end.

Try your Gcode file first with SPJS 1.88

Redownload the ShapeOko file, run in air.

By the way, things always run better with tinyG in mm mode at the moment.
Consider regenerating you Guitar file in mm.