Welcome to Our Community

Some features disabled for guests. Register Today.

G-Code with line numbers

Discussion in 'CAM' started by Metalguru, Mar 26, 2016.

  1. Metalguru

    Metalguru Veteran
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    752
    Likes Received:
    548
    Has anyone come across G-code with line numbers? I purchased some G-code files from Ebay, designed for a Mach3 machine. The G-code has line numbers on every line beginning with N100. GRBL does not like something in the g-code, it seems to choke on just about every line with an error. I have no idea how to strip out the line numbers, the files are 2-8MB in size, manually editing them is not an option.

    Anyone?
     
  2. Metalguru

    Metalguru Veteran
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    752
    Likes Received:
    548
    Seems line numbers were not the problem. Removed the line numbers using NC Corrector, still the same sh*t. Runs through NC Corrector no problem, also runs through Camotics NP.

    I have attached the first few lines of the g-code. Pretty much every line gets a Error ID 24 from GRBL. I noticed that most of the g-code generated by SketchUCam has spaces between the G, x, y, and z commands, but some of my g-code files that work have no spaces. Don't know whether this is the problem.


    ( File created: Tuesday, October 09, 2012 - 05:15 PM)
    ( for Mach2/3 )
    ( Material Size)
    ( X= 152.400, Y= 203.200 ,Z= 7.620)
    ()
    (Toolpaths used in this file:)
    (3D Finish 1 )
    (Tools used in this file: )
    (1 = Ball Nose {3 mm})
    N100G00G21G17G90G40G49G80
    N110G71G91.1
    N120T1M06
    N130 (Ball Nose {3 mm})
    N140G00G43Z5.081H1
    N150S16000M03
    N160(Toolpath:- 3D Finish 1 )
    N170()
    N180G94
    N190X0.000Y0.000F3810.0
    N200G00X75.900Y-127.300Z5.080
    N210G1X75.900Y-127.300Z-5.064F558.6
    N220G1X75.900Y-126.772Z-4.689F3810.0
    N230G1X75.900Y-126.244Z-4.366
    N240G1X75.900Y-125.540Z-4.010
    N250G1X75.900Y-125.012Z-3.801
    N260G1X75.900Y-124.132Z-3.524
    N270G1X75.900Y-123.075Z-3.293
    N280G1X75.900Y-122.019Z-3.146
    N290G1X75.900Y-120.787Z-3.064
    N300G1X75.900Y-119.203Z-3.036
    N310G1X75.900Y-118.147Z-3.075
    N320G1X75.900Y-116.914Z-3.209
    N330G1X75.900Y-115.330Z-3.464

    and it goes on like this for 10,000 lines...
     
  3. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,478
    Likes Received:
    1,920
    from
    Interfacing with Grbl · grbl/grbl Wiki · GitHub
    "24 Two G-code commands that both require the use of the XYZ axis words were detected in the block."
    so my guess is that the files have improper line ends, maybe Mac style, leading GRBL to think that
    there are more than one G1/G0 on one line.
    use 'flip' or 'unix2dos' or similar to change them all to regular DOS format line endings and test.
     
  4. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,478
    Likes Received:
    1,920
    line numbers and spaces between words do not matter at all, even to grbl.
    line numbers are used for looping and subroutine calls (in fancier controllers like LinuxCNC).
    in the old days of paper tapes and very limited memory, no spaces were used. sucks to read it though.
     
  5. Metalguru

    Metalguru Veteran
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    752
    Likes Received:
    548
    Hey David:

    This is confusing the hell out of me. I tried your suggestion, using Flip, since Unix2Dos is a linux only program.

    I first ran the -t option on Flip, which told me that it was a Unix file. Eureka! I thought, there is the problem. However, having loaded the original file with Wordpad, it shows up all nice and neat with separate lines for the whole thing. This doesn't make sense, but WTH.

    Ok, I'll run Flip anyway, with the -d option, which should convert it to dos/windows CRLF format. I do this, and verify with Flip -t that it did as it was supposed to. It now shows up as windows format.

    However, when I opened the converted file in Wordpad, it shows up as a single line. No CRLF's at all. Confirmed this when loading with G-Code sender, same thing. File will not run on GRBL.

    I'm lost here. What am I missing???
     
  6. Metalguru

    Metalguru Veteran
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    752
    Likes Received:
    548
    Well, I found some answers anyway.

    I found that Flip is pretty useless, and doesn't really do what it is supposed to. I finally found an MSDOS version of Unix2Dos.exe, and it did do what it was supposed to.

    Unfortunately, this was not the problem. So, I started looking at the G-Code sender I was using. It was one I found on YouTube, called 109JB's GRBL Interface, and I really liked it for some of the features it had, including a single step mode. However, it seems that it was the culprit, not sure what it did but it seemed to mess with the CRLF line separators and cause GRBL to generate the error ID 24. Switching back to GRBL Panel fixed the problem and I was able to run the g-code no problem.

    God I hate buggy tools. I spent hours trying to get this to work, only to find out that it was the software's fault. I should have realized that it might be the software after NC Corrector and Camotics both ran the g-code no problem...

    Anyway, thanks David and Justin for your assistance!
     
    David the swarfer likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice