I’m running a series of art cuts. They’re organic shapes/patterns. The series is motivated by refining my workflow/stress testing my CAM software, exploring some new (to me) bits, and trying to get rid of some spare material I’ve had sitting around.
I have laid out 8 such ‘tiles’ in a 2 x 4 grid. I processed the job in FabexCNC (formerly BlenderCAM) as a chain comprised of an art operation that cuts the detail line work of each tile, and a frame operation that goes around and cuts out each tile afterwards.
I began running the 15.4MB chain last week. The file loaded in the webui, although it didn’t display most of the job. I ran it anyway. It stopped most of the way through the first tile.
Today, I broke the art op up, so I could run a single tile at a time. The 3.4MB job appeared to load in the webui, but after a while, I got this line across the workpiece.
It seems that Maslow truncated my job on line 129665. This is problematic as the job is in reality 190978 lines long.
Upon identifying this relationship, I reopened the larger job from last week. It appears to be truncated at line 140975 out of 874920.
From what I can find in the documentation, it seems that FluidNC’s max file size is 4GB. Does that limit hold true for Maslow as well? FabEx has an option to split the file. While not ideal, is there a recommended number of lines that jobs should stay below?
Is there any information I can gather to help identify where/why this is failing?
For files such as yours, this should yield a smaller file, but maybe not enough to get the whole file in under the limits.
GCodeClean does its thing over 3 steps:
Clean - does most of the heavy lifting, including analysing the GCode to identify where commands can be optimised within tolerances. This can significantly reduce file sizes. But it also marks up the file with specific comments that identify the ends of each individual cutting path, which may increase the file’s size. I don’t yet have an option to not output these comments.
Split - finds those specific comments and splits the file (output by ‘clean’) into individual GCode files that can be used independently of each other. This could be a precursor to effectively splitting your GCodes file into smaller files.
Merge - takes the output from ‘split’ (which is a folder with all of the individual cutting path files within it) and tries to optimise the travelling distance between cuts. This can significantly reduce the overall cutting time of the GCode file.
You can take the output from ‘merge’ and repeat the same process, which will refresh the numbering of all of the cutting paths. Although ultimately you usually don’t get much more travelling distance saved with the second ‘merge’.
To reliably divide your GCode files into smaller chunks, where each chunk is a discrete optimised GCode file, you could:
Run ‘clean’ to clean things up
Run ‘split’ to generate individual cutting path files
Run ‘merge’ to optimise the cutting path order and pull everything back to a single file
Rename the 'merge’ed file into something more convenient for you, and then …
Run ‘clean’ again on this new file, mainly just to renumber each cutting path.
Run ‘split’ again on the 'clean’ed new file
Manually create several folders, copying some of the files from the ‘split’ output folder into each one. Divide each set of files up according to a convenient total file size for each grouping of individual files
Run ‘merge’ for each of these folders to get your new GCode files, ‘cleaned’, with the cutting paths reasonably optimised, and 'merge’d back into convenient individual files
Thanks md8n. I’ve been using BlenderCAM/FabexCNC which also has options for combining points and shrinking job sizes.
I’m curious if this is a regression from FluidNC, if the issue exists or has been resolved upstream, or if the documentation is just unverified. Also, are others experiencing this issue?
Ran into a problem today. Have an .nc file from the Fusion Maslow post-processor that is 3mb, and my Maslow wouldn’t let me upload it. So I ran it through GCC clean and got a 1.3mb file which could upload.
When I tried to run it, however, the Maslow complained…something about expecting the first line to be gcode. If I’d thought of it, I would have captured the verbiage, but…
Here’s the first few lines (up to the preamble marked by GCC):
post-processor code:
> (STAIR LIFT TROLLEY) (T31 D=0.25 CR=0 - ZMIN=-0.75 - FLAT END MILL) G0 G40 G90 G17 G20 (-ATTENTION- PROPERTY SAFE RETRACTS IS SET TO CLEARANCE HEIGHT.) (ENSURE THE CLEARANCE HEIGHT WILL CLEAR THE PART AND OR FIXTURES.) (RAISE THE Z-AXIS TO A SAFE HEIGHT BEFORE STARTING THE PROGRAM.)
**> ** > (2D POCKET1) T31 M6 M3 S18000
GCC code: > (STAIR LIFT TROLLEY) (T31 D=0.25 CR=0 - ZMIN=-0.75 - FLAT END MILL) G20 (-ATTENTION- PROPERTY SAFE RETRACTS IS SET TO CLEARANCE HEIGHT.) (ENSURE THE CLEARANCE HEIGHT WILL CLEAR THE PART AND OR FIXTURES.) (RAISE THE Z-AXIS TO A SAFE HEIGHT BEFORE STARTING THE PROGRAM.) (2D POCKET1) T31 M6 S18000
The GCC code omits
> G0 G40 G90 G17
and the M3 before S18000
Just wondering if you have any insight. I love GCC, and really need to resolve this issue.
G40 G90 G17 are all perfectly valid instructions for the start of a GCode file.
But the opening G0 is telling your machine to get going, but without saying where.
If there’s some way somewhere that you can remove this, then I’d definitely recommend doing that. This is a bad practice.
A G0, without any other value to indicate where to go to, will be stripped out by GCC. But appearing here so early in the file means that GCC might not be properly ‘set up’ in terms of its state to respond correctly.
I removed that initial G0 and added the --annotate cli option and got this
(STAIR LIFT TROLLEY)
(T31 D=0.25 CR=0 - ZMIN=-0.75 - FLAT END MILL)
G20 (Length units: Inches)
(-ATTENTION- PROPERTY SAFE RETRACTS IS SET TO CLEARANCE HEIGHT.)
(ENSURE THE CLEARANCE HEIGHT WILL CLEAR THE PART AND OR FIXTURES.)
(RAISE THE Z-AXIS TO A SAFE HEIGHT BEFORE STARTING THE PROGRAM.)
(2D POCKET1)
T31 (Select Tool)
M6 (Tool Change)
S18000 (Set Spindle Speed 18000 rpm)
(Preamble completion by GCodeClean)
G90 (Set Distance Mode: Absolute)
G94 (Set Feed Rate Mode: " or degrees, per minute)
G17 (Plane selection: XY)
G40 (Cutter Radius Compensation: Off)
G49 (Tool Length Offset: None)
G54 (Select Coordinate System: 1 (Default))
M3 (Turn Spindle: Clockwise)
(Preamble completed by GCodeClean)
G0 Z0.1 (Linear motion: Rapid, Z0.1")
(Postamble completed by GCodeClean)
M30 (Program End, Pallet Shuttle, and Reset)
So, the M3 was moved to the preamble, and so was the G90, G40 and G17 which should have been left in place, but each on their own line. There is some idealised sequencing to the preamble, but that shouldn’t be relevant here - so I’ll have a poke around.
So I have been doing some tinkering. I ran GCC on my post-processor file, then moved G20 above the comments before uploading it to the Maslow 4. The Maslow did not give the complaints it had previously thrown. So yay that…
My apologies also, I’ve got everything set up to run my tests, but haven’t gotten back to it over the last few days.
What I’ve noticed with a lot of GCode generation from ‘respectable’ software is that they’re mostly doing black-magic and finger-waving. Or in some cases outright en-ification. For example, ‘empty’ G0 commands too early
But I haven’t yet explored manipulating the preamble sequence to clean up this first wave (of the fingers) and put those values in a reasonable order.
At some time in the future, I also want to work my way through the 3D printer syntaxes
RepRap->Marlin->Klipper
:rofl"
ification. For example, ‘empty’