GCode G04 P0 hangs job

Home Forums TinyG TinyG Support GCode G04 P0 hangs job

Tagged: ,

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #9594
    kpanic
    Member

    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?

    #9596
    cmcgrath5035
    Moderator

    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.

    #9598
    kpanic
    Member

    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
    M1
    • This reply was modified 8 years, 6 months ago by kpanic.
    #9604
    cmcgrath5035
    Moderator

    I 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)?

    #9606
    kpanic
    Member

    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.

    • This reply was modified 8 years, 6 months ago by kpanic.
    • This reply was modified 8 years, 6 months ago by kpanic.
    #9613
    cmcgrath5035
    Moderator

    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

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.