Home › Forums › TinyG › TinyG Support › GCode G04 P0 hangs job
- This topic has 5 replies, 2 voices, and was last updated 8 years, 6 months ago by cmcgrath5035.
-
AuthorPosts
-
April 25, 2016 at 10:36 am #9594kpanicMember
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?
April 25, 2016 at 4:53 pm #9596cmcgrath5035ModeratorFirst 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.
April 26, 2016 at 10:25 am #9598kpanicMemberThank 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 laptopAnd 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 M1
- This reply was modified 8 years, 6 months ago by kpanic.
April 26, 2016 at 7:50 pm #9604cmcgrath5035ModeratorI entered an Issue here:
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)?
April 27, 2016 at 8:36 am #9606kpanicMemberThat 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.
April 27, 2016 at 9:22 pm #9613cmcgrath5035ModeratorMany 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
-
AuthorPosts
- You must be logged in to reply to this topic.