Big Files
 

Hi folks, I'm working on a big file.

I'm having problems with long GCode compile times, over an hour. I have tried ESTLCAM and CAMBAM. ESTLCAM just doesn't seem to finish, though I love it for little files. CAMBAM does some strange things with the cut order. I want a very specific cut order and CAMBAM changes it. I haven't tried Cut2D

First, what are your tips and tricks for working with big cut files?
Second, what are your tips and tricks for forcing cut order?

Thanks

Dale

Is this for 2D toolpaths?
What exactly are you trying to do, as 2D toolpath generation should only take a few seconds.

Dale, If you want to solve this with CamBam, have you tried their forums?
To help address this we need a bit more information from you related to the details of the files, and what you are desiring as an outcome.

Some programs limit length unless you unlock them. Also is it multiple tool paths? Roughing, Finishing, VCarve etc. You can do seperate files for each tool.

Hey Mike, yeah I'm chunking the job down into sub operations to reduce file sizes. That seems to be the best way to go about it. Also chunking down single operations to smaller groups of paths and using CAMBAMs styles function to simplify application of tool paths and parameters. I'd be really interested to know if anyone has experience that one CAM application handles large files better than another though.

We still do know whether this is 2D, 2.5D, full 3D. 2D should not be too long unless you have a lot of curves. 2.5D and 3D will be large no matter what you do.

Sorry Pete, its 2.5D. The dxf file is in the other thread i posted. Christmas Baubles

You didn't answer my questions, and AutoCAD wouldn't open the file you posted in the other thread.
My guess is that it's an issue with what's contained in your .dxf file.
A 14Mb .dxf file is massive, and would usually mean that there are things in the file that don't need to be there, or that the CAM programs won't like.
Also, your CAM program might be running out of memory due to the large file size.

I did a quick test, and made an array of about 50,000 lines in AutoCAD. The file size was about the same as yours.

Try saving as a version 12 .dxf and see if it helps. Version 12 format will strip out a lot of stuff that CAM programs won't like.

Great thanks Gerry

OK with a tip from Bruce and Gerry, thanks, I have improved the file by removing all HATCH from the dxf and changing the file format to R13, I can't save in R12. This has improved the file size to 7.9MB. It is still big but CAMBAM is processing paths faster.

Hi Gerry, specifically, I am trialling a number of different tools. CAMBAM, Cut2D, ESTLCAM and MakerCAM. The file is the Christmas baubles file and it's meant to be a big challenge. I want to push the software and also I want to learn some work arounds for complex files. I'm not looking for specific instruction on how to use any of the software. I am more interested in other peoples experiences. Particularly their experiences with chunking down complex files and hand assembling in text.

The HATCH thing is also a great example of where I can improve my vector file handling techniques. I was hatching my vector fills as a visual aid to help me see the profiles and pockets during the design process. Its really easy for me to strip the hatch out before I send to CAM but I didn't know to do that.

So for me the big lessons learned with all your help is:
Remove extraneous design queues. Hatching helps me design but CAM doesn't like it.
Chunk down logical processes. The whole job doesn't need to be on one GCODE file.

I have not looked at the file yet but I will give a simple example from previous simple 2D program. A Chinese checker board to draw in cad is simple, multiple lines and circles. CAM will process it fine but it is long and wastes time and movement. Redrawing the pattern with one line reduced the time and rapid to position dramatically.

Part of my day job for the last 17 years or so is programming cnc routers. I almost never hand write or edit g-code, unless there is a problem, or I want to do something the CAM won't let me do. Usually to save a few seconds here or there on production items.
For 99.5% of what I do, it's always straight from CAM to machine.
I am a firm believer that it's important to know and understand g-code. Nut if you know your CAD and CAM tools well, there's really know reason to ever hand code, as it's much, much faster to do it via CAD/CAM.

I downloaded your revised .dxf, and loaded it into Aspire. It took 40 seconds to create the toolpaths, on my 8 year old PC.

I just assembled a new PC last week. I think it might take less than 10 seconds on my new 6 core i7, which is much, much faster than my old PC.

Dale, I downloaded your file. You will have a lot of lines of code based on the amount of vectors I see. However, what is your limitation? Unless you are using an old Anilam controller that is limited to 12,000 lines or less, Mach and LinuxCNC should not have a problem. If it is the CAM software you are using that is causing the limitation, I would try something else.

Gerry, I agree with you. Funny part is were I work the programmer refuses to use CAM and writes everything by hand even though CAM is available. It takes forever to get even a simple program.

I really appreciate you guys taking the time to comment. I've learned a lot today. I think this has turned into a very valuable thread.

One other thing. You're .dxf contains a lot of blocks. Some inexpensive CAM programs may not deal with blocks well, so you may want to explode them before saving the .dxf.
The downside here is that it may increase your file size.

Thanks Gerry, I just found another fault with my DXF. Some of the paths are less than 1/8" internal pocket distance. I have assumed and applied a 1/8" downcut tool to rout the rebates. The result is that these vector paths get ignored because CAM can't get the tool in to the narrow space. Using a smaller diameter tool solves the problem. But, I'm going to take a look at fixing the DXF to give the patterns a wider rout.