From the original Synthetos forum (2011–2025)
I'm a newbie, using OX/tinyg/chilipeppr to cut circuit boards.
I've been using pcb2gcode to convert some old gerbers. There are a number of places it issues "G04 P0 ( dwell for no time -- G64 should not smooth over this point )", and this hangs my job. I've solved this by removing the lines, but I'm trying to figure out what effect this has. I'm assuming that tinyg is interpreting this as an infinite pause rather than a zero-length pause.
Can someone shed some light on this?
First I have seen a G04 question.
Can you try an experiment and change some G04 P0 to, say, G04 P1?
If those work, then we can raise the bug flag that P0 is not being property handled.
Thank you for addressing this. I forgot to mention that I love the tinyG, its a really great piece of hardware :)
I just ran a number of tests. G04 P[1-5] all work as expected. P0 hangs the job indefinitely. Only a reset pulls it out, and if the planner was buffered up, I couldn't get a ctrl-x into the pipeline, so a button-press reset was necessary. I also tried using the pause/start buttons in the gcode widget without any luck.
I'm happy to do more testing, but the only environment I have set up right now is the chilipeppr.
Here's my full environment:
tinyg v.97, 444.20
SPJS v.1.86, detected COM4 FTDI Driver
Chilipeppr/tinyg, in chrome
Windows Vista crappy laptop
And here's the gcode I used for testing. I changed the Px values in different places for each test:
G94 ( Millimeters per minute feed rate. )
G21 ( Units == Millimeters. )
G90 ( Absolute coordinates. )
;S10000 ( RPM spindle speed. )
F600.00000 ( Feedrate. )
G64 P0.05000 ( set maximum deviation from commanded toolpath )
M3 ( Spindle on clockwise. )
G04 P10 ( dwell for no time -- G64 should not smooth over this point )
G00 Z5.00000 ( retract )
G00 X10.30120 Y26.30320 ( rapid move to begin. )
G01 Z-0.05000
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
G00 X10.30120 Y26.30320
G00 X10.27580 Y17.61640
G00 X10.14880 Y17.54020
G00 X10.17420 Y15.83840
G00 X10.78380 Y15.83840
G00 X10.80920 Y17.59100
G00 X10.70760 Y17.59100
G00 X10.75840 Y25.97300
G00 X28.64000 Y25.97300
G00 X32.37380 Y23.61080
G00 X32.70400 Y23.63620
G00 X34.65980 Y25.33800
G00 X37.27600 Y23.94100
G00 X37.45380 Y23.96640
G00 X37.65700 Y25.59200
G00 X39.15560 Y25.46500
G00 X39.10480 Y24.09340
G00 X39.43500 Y24.01720
G00 X39.53660 Y24.11880
G00 X39.58740 Y25.84600
G00 X37.35220 Y26.04920
G00 X37.22520 Y25.76980
G00 X37.12360 Y24.65220
G00 X37.04740 Y24.57600
G00 X34.68520 Y25.87140
G00 X34.38040 Y25.76980
G00 X32.47540 Y24.11880
G00 X29.04640 Y26.37940
G04 P5 ( dwell for no time -- G64 should not smooth over this point )
G00 Z5.00000 ( retract )
G00 X42.63540 Y25.38880 ( rapid move to begin. )
g04 P5
G00 X0 Y0
G04 P5
M5
M1I entered an Issue here:
https://www.synthetos.com/topics/gcode-g04-p0-hangs-job/#post-9594
Not at all clear to me why a G04 P0 is being issued - what is it supposed to do besides waste space in the command buffer (and cycle time)?
That was actually the bigger part of my question. I'm guessing that it insures that the point won't get "rounded" ( G64 mode )or something like that. I've pulled down the pcb2gcode project and am implementing a "tinyg" option, so I need to know how to handle that line. Is it better to not write it out, or is it better to substitute P1. etc. etc. pcb2code attempts to be as generic as possible. My ONLY experience is with tinyg, so I'm assuming that this really does something for other CNC software/firmware. Judging from this: https://github.com/synthetos/TinyG/wiki/Gcode-Support#g61-g611-g64-path-control-modes, G64 is handled differently in other implementations.
Also, that is a small snippet of a 7000 line job. The "G04 P0" appears in between different code blocks. Also, all the G00's I added in from an early attempt to get the job running. So the generated code has "normal" blocks of movement.
Many legacy interfaces are really slow (8 bit slow uC) so perhaps this was a chance for them to catch up.
I would try first
Eliminate them, let interface flow control (RTS/CTS recommended) do it's job.
If no work, tun back on with P1 or perhaps P0.5 (?)
My guess is that P0 won't get fixed soon, assuming it really is a bug
This topic is from the original forum (April 2016). Your reply starts a new discussion linked to it.
Back to TinyG Support or latest activity.