One thing that may help is to break up your job into two seperate processes:
The first process will cut the “top” layer of your pattern using a DOWN cut bit. The DC bit effects its cut by pushing down into the workpiece material. This will leave you with very crisp edges on the top with little to no tear out. You don’t have to go too deep, only .125 inches or 3mm. The problem with DC bits is that while pushing against the material, they also push against the router and sled. This has the affect of lifting the router up off the workpiece. They also pack chips down into the kurf of the cut, when pocketing this isnt such a bad thing but if cutting a deep narrow line it has a tendency of generating a lot of heat.
The second processes is to cut the remainder of the pocket with an UP cut bit. The UC bit is really good at evacuating chips from the material. It also has a side effect of pulling the Router down into the workpiece.
You are using a compression bit. They are a combination of the two. The first (lower) part is an UP cut bit. The second (upper) part is a DOWN Cut bit. What might be happening with you is when your bit starts the cut, its an UC bit and it’s tearing up the fibers on the upper surface, giving you the tear out.
Truthfully, You could probaly get away with cutting the whole thing with only a DC bit and avoid the tool change because your pockets are sufficiently large enough to allow for adequate clearing of chips.
In my opinion, COMP bits are great in large CNC machines with tradition carriages that can make deeper cuts than we can with the Maslow. I will use them sometimes when I have completly cut out a part and want to perform a final full depth finishing cut. Otherwise, I stick to UC and DC bits.
IF you are having difficulty visualizing what I’m talking about I can do a video capture of a simulation of a recent job I did that shows the two processes I spoke about above.
I think we need to clearly differentiate between two issues
the cuts change over time (deeper or shallower)
the difference between the reported position and the gcode position changing
over time.
the first can involve mechanical issues, the second cannot. I think that mixing
these two things up is causing a lot of confusion.
If we have a test case where moving up and back (not hitting any mechanical
limit) generates an error, and the more times you do this cycle, the larter the
error, then we have a real issue.
Remember, the maslow was only designed for an accuracy of 1/64", which is 0.4mm,
so errors of 0.01mm are way smaller than the machine is designed to deal with.
But if the errors grow over time, we have a major issue
an error of 1/1000" = 0.025mm
0.01mm = 4/10,000"
errors of a few thousanths of an inch are to be exptected.
But if the errors grow over repeated cycles, we have a major issue
This is how I interpreted the current state of things. I believe Tim discovered a bug in how WC was reporting feedback when units were set to metric. I was able to replicate the error but it would be good if others can duplicate the test I did. I agree that the amount of error is pretty small.
I don’t think this issue is causing the problem with inconsistent depth of his pocket operations though. It could be some sort of mechanical issue in his Z axis that is not allowing repeatability in his depth setting. I suspect though that the tear out he is getting when he makes his initial cuts is causing excess material to build up under the sled and causing it to ride up and give him shallower pocket depths than he expected.
What I would like to see is a test pocket cut that is much simpler than what he’s trying to cut. A simple 2in / 5cm square or circle, .125 in / 4mm deep. single pass with a DOWN cut bit. If the this is successfull than the problem may be just bit selesction. To be thorough, maybe do this for settings in both mm and inches just to see im the problem is related to the feedback issue.
I don’t think this is the case. My pockets where done first with a 1/4 compression. Then I contour the edges and around the stars with an 1/8. Both were set to the same depth. I the 1/8 took more passes to get to the depth than the 1/4 and was slightly deeper at the end. If saw dust was collecting as you say then it should of been shallower. As there is the drag mars when traversing because the travel hight wasn’t being reached. I used gcodeclean so the travel hight was small to begin with, but it proves that the z axis isn’t traveling the correct distance all the time. I think the WC sled measurements differing from the gcode and my pocketing issue is one in the same.
I do have a brand new 14 gallon shop vac and cyclone system that is attached to the sled when cutting. (Was removed when I took the pic)
Just did a aircut with multiple passes and traverses in inches. My z axis looked good for the first few z movements. Then I got a .01" of a difference between my gcode and sled. This is about a 1/4 of a mm which was the average when I was cutting in mm, so it seems the same problem exists between the two.
Sometimes I would regain that different while cutting. Then it would come back.
In inches the hundreds place isn’t as small as it is in mm so you see it right away with mm and takes awhile with inches.
Edit:
So during my cut I got back on track at -.45" for both gcode and sled. I paused it and WC allowed me to switch over to mm. Once I did that the finer measurement with mm showed that I was off still, only .03mm
Any ideas of settings or something I can do fine tune the z?
I’ve never used gcode clean so I don’t really know what it is supposed to be doing.
I ran multiple test cuts in both mm and inches this morning and didnt see the differnece crop up. However, they were small test cuts with small step changes in depth. No retracts or anything. It may be that it never got the chance to develop during my test.
I then ran your job several times this morning (air cuts). I paused at each Z axis move to capture the gcode command and the resultant feedback value. It usualy took a second or two for the feedback value in WC to catch up but after a second or two it did. I ran the file multiple of times to see if I could get a compounded error. After 5 complete runs I hadn’t received any error either during the active job execution or at any of the job pauses along the way. I also didn’t finish any of the complete jobs with an error either.
I am running the last version of WC prior to @Orob starting his modifications, v0.94. Which version are you running?
I’m pretty sure it’s the newest version. I’ll CK when I get home. Any ideas on the next steps to resolve this problem (assuming I’m running the same WC as you)?
It’s a used machine. When I got it, I didn’t wipe anything when I went into holey cal. What will happen if I wipe the epromm? I don’t know what that is and don’t want to screw up the machine.
Basically need to be told what to try out so I can try to fix the problem, I have surpassed my level system knowledge.
again, to figure out if we are talking a software issue (it’s not going where
it’s told and drifting over time) or a hardware issue (it thinks it’s doing the
right thing, but isn’t) let’s make a small gcode file that just moves the Z axis
back and forth several times and have different people run it and show the
results.
let’s also clear the log file for a fresh start before the test and have people
upload the log file after (assuming that it shows the gcode-vs-current error)
Jonathan, do you think you can create a test file, something simple that just
sets the units, sets the feed rate, then bounces back and forth a few times,
pauses, then does some more? I don’t have a machine setup near me right now to
test the result on, and I hate sending out test code that I haven’t tested for
stupid typos
if it is a mechanical thing, one thing it could be is that the 1/8" bit isn’t
quite as tight as it needs to be in the chuck, with a compression/upcut but (and
a compression bit is effectively an upcut bit when doing any pocketing) the
cutting forces will tend to pull it out of the router. try marking it with a
piece of tape something like that, do your cutting and see if the bit has
moved (not a bad idea to do the same for the router)
It’s been doing it with 1/8, 1/4 upcuts and straights as well. I really crank on the collet but to make sure the bit doesn’t move, but I’ll mark it the next cut I do just to make sure. I do have the router marked and it hasn’t slipped in the router clamp.
I’m pretty positive it is something to do with my settings/software. Thanks for all the help guys, I’m determined to try anything to solve this thing! Keep feeding me ideas/solutions.
right idea, but I was thinking of doing more Z moves, say 5 up/down cycles, then
doing the tool change, then 10 cycles, then a tool change… give it a workout
(and look in the log file to see if it logs the position, if so, consider not
doing the tool changes and looking at the logs)
trying to maximize the error while minimizing the labor involved.
but that gcode will work, it’s just that since it pauses after every Z move it’s
more work for you to do.
It is a series of hole drilling operations. It drills a series of holes in a single location, at increasing depths from .125 inches to .750 inches in .125 inch increments for a total of six operations or steps. A group of six steps is one cycle. In between each step the Z will fully retract to it’s retract height and begin the next step from there. There are a total of six cycles, for a total of 36 steps. Each cycle will alternate between two tools (T4 and T2) so there is a tool change in between each cycle. This will trigger a pause in between the cycles that will require a resume from the operator.
I assumed that this will be run as a test without a bit in the router but to be safe I programmed in a very slow feed rate in case someone acutauly tries ot cut this. I ran the full program on my machine to verify that it will function without breaking anything. FYI, no errors were evident in my test.
You mentioned collecting a log file. Which one should I grab?
Let me know if this file will suffice. If not, I can modify as needed.
EDIT:
Here’s a version WITHOUT the tool changes: Z_CYCLE_REV01.nc (3.4 KB)
EDIT2:
I’m wondering if adding a one second dwell after each operation reaching its depth would be helpful. Give WC a chance to catch up with reporting the feedback. Does Maslow support G04?
