My Nomad has suddenly stopped pocketing correctly. I have made no changes in workflow. From what I can tell, inside/outside contouring still works as it should. But the last 15-20 pocketing jobs I have tried have all failed. The end mill gets into positions but then BARELY moves in X or Z direction. I have rebooted, power cycled, and created new and different pocketing paths with different tools. The .nc file is below. I am using Carbide Create to design and create toolpaths. Any ideas?
Lines.nc (4.9 KB)
Hi @kalel76,
Something’s wrong in your G-code, it previews like this:
all the action happens in that upper right corner that is about 140mm to the right and 180mm to the front of the zero point, and then if one zooms in A LOT we can see the pocketing toolpaths, but the stepover between those passes is minusucule (0.1mm)
which matches with the micro-moves you are seeing.
Can you post the .c2d file for a look ?
2 Likes
Hi @Julien,
Sure thing, attached is the .c2d file. Thanks!
Imperial Credit 2.c2d (1.1 MB)
I should also mention that this happens on the most current build of Carbide Create (472) and when I reverted to a previous build (464) as well.
@kalel76 You only have a small section of your design selected. You also have a max depth of 0.3mm. Are you seeing something different than the preview?
1 Like
Hi @neilferreri,
Yep, you are correct. I’m using a 1/32nd end mill and doing some very fine milling. .3mm is the correct Max Depth for this project. The reason you only see the small section highlighted was because that was part of my most recent troubleshooting efforts after my problems began. Normally there would be more selections at one time.
So, what are you seeing that you aren’t expecting?
If you try a test square pocket of 50mm square, what happens?
1 Like
@neilferreri,
The end mill and bottom plate position themselves and begin to plunge. After the plunge the end mill just barely moves. Almost imperceptible. But if you watch it closely you can see it creeping along. And if you watch Carbide Motion’s Position counter, you can see that it is moving somewhat. I have the feed rate set to 250 but it’s certainly not moving close to that speed. Hope that makes sense.
Oh and I can’t do a test at the moment, it’s 1:27am my time and I’m in an apartment.
I think you should try a large pocket like @neilferreri said, with the same feeds and speeds, do an air cut of that, see if it behaves differently.
I can’t see anything wrong in the G-code, but it IS going to be very slow on X/Y, and movements on Z will be imperceptible (0.075mm depth per pass), and 250mm/min is slow enough that I wouldn’t be able to tell for sure know how fast it goes by looking at it.
If this test cut goes the “normal” speed you expected, then we can dig further?
1 Like
@Julien, sounds good. I’ll try this when I get home from work today. Thank you.
BTW, I have not tried generating gcode from any other .c2d file than this one since the problem started. I will create a new, simple pocketing file when I get home. In case this were to work, is there a way to save a design from one .c2d file to another? I do not want to have to recreate these measurements and alignments again if I don’t have to.
ok, let’s see how it goes and go from there.
Should you need to reuse the design elements from that c2d file in another one for any reason, what you can do is “File => Export SVG”, create a new c2d file, and then re-import that exported SVG. You would loose the toolpaths, but those can be re-created easily enough.
2 Likes
By the way, I ran your g-code file as an air cut, and captured a (bad) video:
- in the first seconds, it’s “just” plunging very,very slowly at the 5 mm/min plunge rate you specified in your file and then after a few seconds it reaches the depth of the first pass (-0.07mm) and you can see it moving along straight lines at 250mm/min, back and forth
So it all looks normal to me. I wonder if you maybe mistyped that plunge rate ? should it be 50mm/min not 5 ?
1 Like
@Julien, thank you for testing that. That looks correct, that is what I am accustomed to seeing (I’ve run about 5 of these previously with no issues). 5mm plunge is correct as I was trying to avoid snapping the 1/32nd end mill. Good to see that it works. I’m really hoping generating gcode from a new .c2d file will solve my issue.
Sorry, I guess I missed what the initial problem is then. Do you mean that what you see when running the file on your machine, does not match the behavior in that video I posted ?
Since I ran your G-code file as is, and “it works”, regenerating the file shouldn’t change anything?
If running that same exact “Lines.nc” file on your machine results in the movement not being what’s in the video, I guess there might be something else going on (mechanical ?) ?
This confirms that generating the square test cut we discussed earlier, to see if there is anything wrong happening for other jobs, should be your next move.
2 Likes
@Julien,
I got home and immediately tested a new .c2d file and it worked fine. Then I tested creating gcode from my original file and it worked. Then I tried another test from my original file and it failed. Nothing is different other than it was the 3rd consecutive test. Here is the file and the video. Please excuse the awful spelling, I was in a hurry.
test too patha again again.nc (4.7 KB)
Can you post the gcode that works?
I THINK I have found an issue but I cannot explain it. When I create gcode form my desired .c2d file, pocketing does not work correctly. When I create gcode from a new .c2d file, pocket works as it should.
OK, fine.
I will copy all design elements from desired .c2d file to a new one. When I do this they do not align themselves where they were in the original file so that the existing cuts on the stock on my machine do not match any future cuts I would make.
I’m making the EXACT same tool paths in two different .c2d files (and old one and a new one) and the old ones fail and the new ones work. How can i fix this so that the work I’ve already done is not wasted? And what’s to say this will not happen again in the future? If memory serves me correctly, my problems began when I downloaded the newest Carbide Create build.
Logic tells me that my desired .c2d file is not generating the proper gcode. But any new .c2d file I create is creating proper gcode.
From the above screenshot, code generated with desired .c2d file populates the feed of 250 on its own line. This gcode does not work. If I create gcode from a new .c2d file, the feeds line is never own its own line and the resulting gcode works properly.
1 Like
Please post the file in question here or send this file in to us at support@carbide3d.com and we’ll do our best to look into this with you.
@WillAdams,
Thanks! I’ll get some files together and send them your way.
Brand New C2D file gcode.nc (991 Bytes)
Desired C2D file gcode.nc (660 Bytes)
Update
I decided to simply create new code in a new file from scratch since that seemed to be working. I began my first cut and the first few minutes worked fine and then it began failing again. New file, new gcode, Carbide Motion, CNC working fine for the first few minutes, then failed. Here is that code:
New Outlines.nc (24.0 KB)
1 Like
It seems to me a lot of the Y moves are missing from the Desired and New files?
1 Like
Hi @kalel76,
Can you confirm that in the video you posted you did use the “test too patha again again.nc” you attached in the same post ?
What strikes me as odd is that the first few seconds of the video show that the machine is currently moving along X, but very small increments of about 0.1mm at a time and very slowly: what’s weird is that CM displays the current feedrate to be 6mm/min then (“Vel: 6”), when it should be 250mm.min at that point. 6mm/min is the plunge rate. The video also tells me the job was at line 18, and the file has this around that line:
line 14: G0X129.63Y69.79
line 15: Z0.75
line 16: G1Z-0.07F6.0
line 17: F250.0
line 18: X140.33
line 19: X129.63
So it was at X=129.63, then plunged Z to first pass depth at 6mm/min (G1Z-0.0F6.0), but then the “F250” line should have made the machine adjust the current feedrate to 250mm/min, this should apply to the subsequent moves, and in particular the X140.33 which we see being executed in the video…just still at 6mm/min, not the requested 250mm/min.
If this was indeed the G-code file you used in that video, it behaves as if it choked on that F250 command and ignored it.
In any case, the problem is not in the G-code itself.
The only thing I can think of is some intermittent USB communication issue, but it’s a bit unlikely that this would happen only for that line (or maybe it does happen on other lines but this is not as visible)
Can you double-check that the USB connection to your machine is nice and secure, and maybe retry running those jobs multiple times from another computer if you can ?
If this does not change anything, then I guess it time to get in touch with support@carbide3d.com for a live debugging session with support.
4 Likes