My first real problem (not caused by my inexperience). My project runs to about 75% and then seems to stick on one tool path which it runs over and over and over and over. The machine is still responsive…I can quit the project and then still control the SO3. I re-ran the project and the results were the same. I’m going to delete and re-create the “bad” tool path and see if it helps. Any advice if it doesn’t?
You can alway post your GCode here and let us look at it (please tell us what lines are being repeated). But try re-creating the tool path first.
Please post:
- source file
- description of how source file was made / derived
- tool used for CAM
- settings used for each aspect
- final G-code file
It’s important to have files as simple and concise as possible — always check them in outline view if using a drawing program rather than CAD.
1 Like
Roger that. I’ve deleted and recreated the problem tool path. I’ll run the project again tonight. If it is still not working I’ll grab the g-code and line number out of CM.
I used CC to import a DXF file and then create the tool paths based on a drawing I created in a CAD program.
@Qwkpony
A screenshot of your Tool path settings would be helpful, I suspect you may have .000" as a DOC somewhere?
1 Like
I tried it again last night. It ran the tool path I re-created and then moved to the next tool path and ran it over and over and over. The SO3 was not frozen, I was able to pause and then quit the project.
The source file started as a DXF I created in DeltaCAD, then imported into CC to create the tool paths. If you’d like the source .DXF or CC .c2d used to create the e g-code just let me know.
CC version 286
CM version 3.0.361
I paused it on line 1489.
badgcode.zip (5.7 KB)
I ran it, it completed in 11 minutes.
The first 1/2 or more of the program is the one pattern but it is going down in depth each pass until it gets to -10MM
At that point it switches to the other tool paths and finishes the project.
How long does your get stuck in the same pattern for? It clearly runs that pattern first and that takes the longest time.
The part on the right (One left from the right most part) is deeper then all the rest and takes up most of the g-code in the file. It runs that part for most of the job.
1 Like
That is what I’m seeing. I don’t let it run the repeating tool path run more than about 6 times because if I did it would be through the foam I’m using to test and into the spoil board.
Depth per pass is set to .062 and depth of cut is set to .131 so it should only take 3 passes to complete each tool path. Why is it trying to cut so deep?
I’m going to upgrade to the latest version of CC and recreate all the tool paths and see if that helps.
ok that being the case it must be an issue with overlapping toolpaths or something in carbide create. Can you post the CC file so I can load and review the toolpaths? c2d I think is the one.
This would be a great time to share your knowledge about how you emulated the cut file to get the image above that clearly shows the extra cutting in the file. it is not getting stuck, it is in there.
Don’t laugh, but this is the first time I’ve looked at the raw g-code. I can see that it runs the same exact group of code 7 times. I assume that is the tool path it is repeating too many times. Very strange when it should have only been run basically 3 times.
I’ve recreated all the tool paths. Unfortunately I have to have the SO3 connected to my laptop to run CM and convert the CM .egc files to plain g-code. When I get home tonight I’ll pull the raw g-code and see if the tool paths are still being run too many times.
If there is some other way to convert the egc files to raw g-code, please let me know,
So far it seems to be a bug in the CC created .egc files running one tool path too many repetitions for the depth specified.
The simulator I hacked together from several sources actually. I spent many hours trying to make it get MOST gcode commands to actually get interpreted to the screen properly. I include it with my software when I start selling it. It works on most files I have run with it so far. Even really large ones seem to work, although you could potentially run out of memory but I have tested it on a few million + lines of code files and it takes a few seconds to load but it shows them well I think.
FWIW, there’s a list of G-code simulator / previewers here:
1 Like