Is there a trick or tool to easily break a .NC file into multiple parts?
The finish path on my current project is 91,102KB and will not load. I have manually broken files up before with mixed results.
Best practice is to break up jobs into manageable chunks: http://docs.carbide3d.com/tutorials/tool-change/
If you must do this:
- open up the G-Code file in a text editor
- identify the preamble and copy it — see [[G-Code]] and https://docs.carbide3d.com/software-faq/grbl-g-code-definitions/ for the details of the codes
- go to the line # noted above
- scroll up from there until you find a move down from safety height
- delete everything from the line above that line to the beginning of the file
- paste in the preamble at the beginning
- save under a new name
1 Like
That’s kinda what I did before. Just to be clear is G0 where the preamble ends?
%
G21
G90
G0X0Y0Z2.0000
(Created by STL2NC)
(FILENAME: undefined)
M6 T27
M3 S18000
G0 X0Y0
G0Z2.0000
G1X-0.4625Y0.5000Z-1.0550F510
G1X-0.4250Z-1.0500F1270
are there tool changes in the file?
if so https://fenrus75.github.io/FenrusCNCtools/javascript/gcodesplit.html will split the file per tool for you
(it’s not on online app, it fully runs within your browser)
2 Likes
I used your tool to create it. It is split by tool. The finish path is too long to run in one pass.
Sounds like I need to optimize for size more…
Also you might have picked a super small step over?
using a 1mm ballnose with a .1mm stepover. with the precision set to high.
Why is there even a file size restriction? Does it serve a purpose? If not, is there a way to bypass it?
it’s a legacy thing in CM (which is 32 bit but hopefully will go 64 bit soon)
1 Like
high precision makes 0.05mm steps in one direction… yeah it’ll get big.
I’ll poke at anything obvious I can do to shrink the result
1 Like
ok the current version should produce a lot smaller files
changes
- G0/G1 are modal and don’t need to be repeated on each line
- Output 2 digits instead of 4… in metric, 0.01 is plenty of small enough since the stepper motor steps are 0.025 anyway (this matches what carbide create does)
(for folks wondering what this is about, this is about STL gcode generation from https://fenrus75.github.io/FenrusCNCtools/stl2nc/stl2nc.html)
1 Like
That definitely makes it more compact. The same parameters reduces the size by a third. Still 3 times to large for CM.
I ran the first 817235 lines of the finish pass already though. Now I am trying to chop the next set and it is telling me the feedrate is undefined even though I am using the same preamble from the original, as seen above…
The current CM should be able to handle 62Mb files… I’ve done cuts (generated by my tool) that were 62Mb in size. Larger than that I’ve had it go BANG but 62Mb I know I’ve done
is the most suspect… although G0 shouldn’t need a feedrate, and the first G1 you have already sets a feedrate.
(if you don’t use the two G1s from your preamble, make sure the first G1 you have has an F on the line)
I updated my CM to the newest version and re-ran the file. Just my luck, the new finish pass on high precision comes in at 63.19.
Cest Le Vie. Thanks for your help. I am just gonna run the whole thing over again on normal precision and resolve myself to a little more sanding. With your updated tool, it’s only 39.1, so it will still be quicker than segmenting the rest of the original file.
“normal precision” isn’t horrible… it’s still <= 0.1mm resolution in both axis 
Fair enough. Honestly, I can’t even see a difference between normal and high. If the tool would let me, I would probably try doubling it again to .2mm or even .5mm just to see if the speed was worth it.
I am running it at 200% and it’s cutting through this mahogany like butter.
you can set the stepover size in the gui… it’s editable!
I think it is getting overridden by your calculate precision field, because the file size is the same at 0.1mm as it is at 0.5mm
that would be a bug… time to debug 
thanks for the report
(bug behavior confirmed, now to figure out what is going on)
1 Like