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?
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...
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.
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.
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???
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!
