This has occurred, but very early on, when I first started to use the machine and hadn’t developed the “looking in 10 directions at the same time” skill!
1 Like
Hey Peter,
If “adding the code” means loading the gcode file, that doesn’t do anything with respect to the machine state, zeros, tools, etc. You can load it at any time.
The picture of chaos above is a single operation, yes? Cutting out five lids in one go, with no tool change involved, all in the on go, according to the .c2d file you posted.
If the depth is changing during this operation, after the BitSetter operation, then the BitSetter can’t really be relevant here, can it? At least here, you have a “depth is changing whilst cutting” issue, not a “tool offset was not calculated correctly” issue. And, these will look like identical issues if it happens at the start of the run and you stop it quickly.
It does, but I’m beginning to run out of ideas and will try anything!
Exactly, yes. But I’ve tried to do it twice. Once where the first cut was just over 9mm deep and the second with the first cut over 5mm deep. I’m going to try again today!
I’m not sure that’s the case. Assuming(!) the BitZero is setting zero for the X, Y and Z axes correctly (which could be tested by using Rapid Move to X=0mm/Y=0mm and then Z=6mm after loading the file but before the BitSetter process) it must be the BitSetter, surely?
It would alter the Z position for the difference in the length of the current tool vs the last tool. But only once, and then it is out of the picture.
For the cut to change depth whilst cutting, I would imagine something else is happening. In my own mind, this is because something is slipping physically somewhere. The machine doesn’t measure where the spindle actually is, just where it’s told it to go. So it can think it’s cutting a line at 6mm and slip, and actually cut it at 25mm, but still think it’s at 6mm.
It’d be great to get to the bottom of this. My steps are exactly like yours and I never have these issues. As such, finding out what’s the cause, and what is different, would be really satisfying (so long as you don’t lose heart and give in 
)
2 Likes
I’m trying not to lose heart, but it’s a struggle,
Good job people like you are here to help!
2 Likes
Ah, but it doesn’t. This will always happen immediately, on the first cut, so there is nothing physical to affect the tool length, for example.
1 Like
Then I misunderstood.
I thought you said that the cuts in the “failure” picture ended up all being different depths.
So the slots there are all ended up with the same depth?
I was hoping that it would be the “slotting has excessive tool engagement” sort of issue pulling the Z-axis downwards (Will’s “add more geometry” sort of thing).
My mistake, not yours 
The cuts you see are all the same depth. I let it finish that part of the project
The variation in depth of cut is for each pass of the same geometry.
Oh… well, that’s interesting since they are wrong. Did you pause and measure between each pass?
I’m sure we’ve covered this, but what Z-Axis have you, and what configuration did you select and send to the machine for the Z-axis ?
I did yes, because I was trying to find out what was going wrong, I then discovered that issue.
The Z-Plus and that’s the configuration I sent when setting it up 
Have you changed your computer since then at all? I think it has to be set again if you install CM onto a machine that’s never had it on before.
No, it’s the same one. I recently changed the CM control board, and carried out the settings routine.
I did wonder if using CC on my Mac and then CM on Windows to run the project could have been an issue, though.
UPDATE: I tested the process again twice today (well, three times including where the BitZero process failed) and on both occasions the first cut was as it should have been. I’ve attached the log file, but I suppose it’s irrelevant as it worked properly!
20210704 - Test Run.pdf (52.0 KB)
Stupid machine 
1 Like
The cutter is engaged. So far as I know, nothing appears to have been moved at any time without a cut being made. If that is not the case, then the following is not relevant.
Imagine instead of a cutter it was a screw, and it pulled the axis forcefully into the wood. Lets say it pulled it further than the axis pushed. There would be a discrepancy.
If this happened, you could not tell post-mortem whether the very instance it hit the wood it was going to too deep (bitsetter issue), or that it hit it perfectly at the right spot, and then was instantly pulled out of position.
1 Like
I’m really not interested in agreeing with you, Jepho. I am trying to postulate possible reasons why Peter is experiencing his issues.
Your conclusion is not what I concluded. The cutter is engaged if it pulls either the cutter or the spindle downwards. Afterwards, you can’t tell if it hit at the wrong depth or hit at the right depth and got pulled down.
I can’t seen any reference to that sort of issue. Can you point me to it?
I don’t interpret that post as having input height values differing from programmed heights.
My interpretation is that Peter ran the job and it plunged 9mm into the wood instead of 0.04" (around 1mm) which is his DOC.
He then jogged back to the zero position and it showed that the tip of his endmill was 12.53mm too long compared to the previous time. (it read 12.53mm when it should have read 0mm).
Maybe Peter can clarify what was happening here, but I don’t see anything there that shows a value has been changed.
I thought these were all physical measurements after the fact, and not logged values on the screen recorded whilst the machine was cutting.
If the machine was saying the wrong thing, that’s not been explicitly made clear, I think.
As much as I don’t want to interfere with the flow of your common investigation, I still think what would be really helpful is if we had a documented case of one cut gone wrong with the following associated info
- measured stickout value of whatever is used during machine initialization
- measured stickout value of whatever is used for setting Z zero (the gage pin, probably)
- initial measured stickout value of the endmill before hitting “Start”
- final measured stickout of the endmill after the failed job
- final Z zero value offset (compared to where it should have been, e.g. xxx mm too deep)
- a CM log corresponding to that run (with status messages filtered out using the checkbox)
I believe if we had that, we would be able to tell whether CM or GRBL makes a mistake in the Z zero compensation algorithm somehow.
6 Likes
Hope I am not jumping into water that’s too hot…
Each time the machine changes depth, look at the actual x,y and z position in the CM screen. Are they what are expected? If the values are as expected the program is working normal. If the values are as expected and the cut is going wrong this leaves either the motion control board, or a mechanical issue at the machine.
If the values shown are not as expected…well I can not suggest on that as I have no experience with building computers or writing algorithms.
This has to be frustrating for the OP.
All I can say, is don’t get too flustered and don’t give up.
5 Likes
That is exactly what happened on the first cut - which I aborted almost immediately, when I realised the cut had gone too deep. This left a hole over 9mm deep in the stock.
Leaving the stock where it was, I tried to run the project a second time. Although the first cut was again too deep at just over 5mm I let it continue, until the bit dragged diagonally across the stock, because I was hoping to salvage something. It was then I realised the actual DoC was different at every pass - but consistent for each lead, i.e.the first Contour tool path cut was 5.15mm deep, with subsequent cuts being at 6.19mm (+1.04mm), 7.09mm (+0.9mm), 8.33mm (+1.24mm) and then 9.04mm (+0.71mm).