Confusing BitZero Issues - revisited

So, you close feeds when they don’t suit you? Sounds like a dictatorship, to me.

My response to that thread was going to be…

They’re all very valid points, @Gerry, and I appreciate the feedback.

Being a) trained to follow orders in the military, b) an engineer by trade, c) follow instructions to the letter by profession, and d) old and set in my ways, I’m confident I’m doing what I’m supposed to do, but here is my process, with the computer on, CM not running, everything connected, and the machine switched ‘off’ and in the NE position (which is where I normally park it):

  1. Secure the stock in place.
  2. Turn the machine on using the rocker switch.
  3. Start CM.
  4. Click ‘Connect to the router’ - then wait for the Initialise button to appear.
  5. Click Initialise - The machine homes, moves to SC prompting for a bit/probe.
  6. Click Resume - It does its thing with the BitSetter, then returns to SC.
  7. Move the spindle to the start point and, using the ‘automatic’ CM workflow with the BitZero v2, set the X, Y and Z zeroes and remove the BitZero to a safe place.
  8. Move the spindle to an approximate SC.
  9. Load the *.nc file.
  10. Click Run - CM prompts for a new tool.
  11. Change the tool (unless it’s already in the spindle).
  12. Click Resume - It does its thing with the BitSetter, then returns to SC.
  13. Click Resume - cross my fingers and hope for the best. It’s at this point it going to go right or wrong.

This is the process I follow every time I start the machine to run a project but, if I run another project during the same session, I start the the process at Step 6, even if I’m running the same project a second time and cutting from the same stock.

I’ve tried this today, following these steps, and the project seems to be going well. I’ll let you know when t’s finished, but if these aren’t the ‘approved’ steps to follow, I need to know.

3 Likes

Hmmm… that looks ok to my eyes.

I have to admit that I start from scratch every time. The reasons are many and varied but essentially, I rely on the persistence of the Z axis zero point and do not try to reset it at all, if the stock is the same height as my last stock measurement.

I don’t know the CM software well enough to rely on the processes I use other than when I use them from scratch. The whole BitSetter routine can get out of shape and funky for no apparent reason. When an event is apparently random, it is tough to try and document it.

When my BitSetter reads correctly at the initial pass then sends the bit to the highest possible location on the Z axis and then descends really slowly (as if it is measuring the bit length) then I am at a loss. It is a random event and I cannot tell you what presaged it. I follow my normal routine which works for 98% of the time.

When it does not, I have not changed my routine but something is not working as it should. If it ain’t me, it can only be the hardware and the way it communicates with the software or the software and the way it communicates with the hardware. Because it is not a consistent happenstance, it is very hard to pin down the causative mechanism.

4 Likes

Hey Peter,

Thanks for the response. Your operations do look okay.

I don’t think 8 is something you need to do, and could accidentally trigger a “oh it needs a new tool” feeling, which would be bad :slight_smile:

Step 12 is where you turn on your router? I don’t have this step since I have a spindle.

In the same session, your probably can’t get to step 6 again. You’d need to go to step 7 I think.

It does look like you are doing the right things.

Really, the only rules for this flow of operations are:

  1. Never put anything at all in the collet from the time you turn the machine on to the time you turn it off - unless the spindle has moved to SC and there’s a CM prompt telling you to do so. As in, really really never, regardless of jobs loaded, zeroing, BitZero, or anything else.
  2. See 1.

It’s easy to make mistakes with zeroing by putting the BitZero in the wrong place, but I would image BitZero errors should only either be a 3mm too shallow a cut, or a 3mm too deep a cut.

5 Likes

I thought about that, but I did have concerns about the spindle being a bit close to the top of the stock when at Step 10, but maybe I’m just being paranoid :thinking: :+1:

Ah, my bad. I’ve got a BitRunner, so the starting the spindle is automatic.

Of course :face_with_raised_eyebrow:. I removed a line when drafting this and forgot to update text. Thanks for pointing that out :+1:

I totally agree.

Thanks, Gerry :+1:

So, the cut went perfectly well, following the steps above.

Today I’m going to cut the lids, using the same steps. Let’s see how that works.

6 Likes

Oh my! I did not know that you were running a box factory. My observation is that the grain may look better running longitudinally.
:rofl:

My last inspection did not reveal your mass production capability. Does HMRC know about this production line you are running?
:wink:

1 Like

So, running the project for the lids didn’t go as expected, despite following the steps above. The very first cut put a 9.03mm hole into the surface of the stock - and only stopped because I used the feed-hold switch.

I abandoned the project and moved the spindle back to the X, Y and Z zero points on the stock, like this:

…but this is the Position settings at that time:

…so my guess is it would have cut a hole deeper than 9mm if I hadn’t stopped it.

According to some, this is always user error, so I turned the machine off and closed CM, and started again.

After starting CM, reconnecting and reinitialising, the machine did it’s BitSetter thing, I used the BitZero v2 to set the stock zeros, and after it did it’s thing, the Position was showing thus:

I then ran the project and the spindle moved to prompt for a cutter, here:

When it returned from the BitSetter process is landed here:

I’m not sure why Y is different, but there it is, and I assume the Z position is different because of the difference in length between the Probe used for zeroing and the #251 cutter I was going to use for the project.

Except that didn’t work out, either.

This time, the first cut went 5.15mm deep before cutting the Contour path for the lip, with subsequent cuts being at 6.19mm (+1.04mm), 7.09mm (+0.9mm), 8.33mm (+1.24mm) and then 9.04mm (+0.71mm), which is a bit weird when the overall cut for the lip should have been 0.2", i.e. 5.08mm!

Also, why are the subsequent cuts to different depths?

Finally, I let the project run as the stock was now firewood, and this is what happened during the fast travel.

Tell me this is user error again, @WillAdams

EDIT: Sorry, I forgot to add the files.
Rectangular Lid x5 v2.c2d (250.0 KB)
Rectangular Lid x5 v2.nc (187.7 KB)

2 Likes

Oh damn! That is extremely irritating. This must be especially distressing after succesfully running the first half of the project. I would hope that support@carbide3d.com takes another look at this issue, Peter. Random happenings are hard to pin down but having them ruin the stock and all of your careful previous work is an issue that should be addressed as a matter of urgency. The perfect bases demonstrate to me that you must be using the machine and the software correctly.

I think it may be helpful for you to know that the displayed Position is a relative position. I am not sure if that is relative to the last zeroed position before the machine begins working. It is, in my opinion, far more useful to click on the Position legend so that it changes to show the Machine Position legend. As far as I can tell the ‘Machine Position’ function displays the actual location of the spindle and Z axis carriage, regardless of the latest zeroed value. Hopefully, a more knowledgeable person will clarify this point and correct my statements.

I have no answers for the lack of retract height… indeed it is a positive value as it has cut deep into the stock. I wont insult you by asking whether the bit was tight in the collet, for I know that will have been properly done. It reminds me to ask if the collet has become worn and failing to hold onto the bit.

I think it would be reasonable to create a series of tests that cannot be interpreted. I may have a think about that proposition and see what failures cause questions to support and what tests could eliminate the possible causes. Unfortunately, it wont help with yet another ruined piece of expensive stock. Phone me, Peter, if you have the time. Jeff

1 Like

Are you 100% confident your endmill isn’t slipping and moving down in the collet? That would probably explain all of this. It does look rather protruded in the top shot.

I’m on my fourth read of all the details you provided and still can’t come up with anything relevant, so I’ll drop a few ideas instead, should you want to continue the investigation:

  • it would be interesting to make a note of tool stickout at each tool change. I know I usually ask for the CM Logs too, but in fact the logs are useless if one does not also know how far each tool was actually sticking out in reality. It’s going to be tedious, but there would be a chance that we can compare the actual, as-measured tool length difference, with what the BitSetter applied to the Z zero, and go from there.

EDIT: and this would also address @Gerry’s hunch of a slipping endmill, if you were to make a note of the stickout both before and after the cut with a given tool

  • until we figure out what happens, one thing you could do as a (somewhat silly) way to double-check where the Z zero has been adjusted by the BitSetter upon starting the job is: start the job, let it go to BitSetter, but then before it actually starts cutting, pause and stop the job, and manually jog to X0/Y0/Z0 like you did in one of the pics above. If it still matches, then re-starting the job as is should work 100% of the time (the job start will make the machine go to the BitSetter again, but with the same tool, so that is pretty much guaranted to not mess up the Z0)
  • as a last resort you could try and use another G-code sender with bitzero and bitsetter macros (e.g. CNCjs and Neil’s macros). That won’t help figuring out why in the CM+BitZero+BitSetter setup you have those issues, and I am not saying there is anything wrong in CM (trust me, I have tried and tried and tried to pinpoint something suspicious whenever someone reports a Z depth problem, but so far I have never been able to pinpoint a bug). It may provide you with a setup that happens to work for you always, sometimes at the end of the day this is what matters.
1 Like

I’m absolutely sure. The top of the cutter is just visible in the hole in the spindle of the Makita and the collet is clean.

I’ll check, though…

UPDATE: I’ve checked the cutter and it’s in exactly the same position it was when I started the project. And there’s more…

There are some questions about this that need answering, and I’m going to try and ask them here. Specifically:

  1. Running this same project twice and following the same set of steps that worked before, why was the first cut over 9.03mm and 5.15mm deep on the first and second attempt, respectively, on the first pass of the project?

  2. Why were the subsequent cuts on the second project different, when the Depth per Pass was set to 0.040"? They were at +1.04mm, +0.9mm, +1.24mm and then +0.71mm, when they should have been +1.016mm each.

  3. When I popped back into the shed to check the spindle, during a conversation with @jepho about Position vs Machine Position co-ordinates, I looked once again at the zero settings of the machine to prove a point. I switched it on, started CM, connected to the router, disabled the BitSetter and initialised the machine, and it carried out the Home process. I then used Rapid to moved the spindle to X and Y zero (which it obviously remembers from the last project) and then manually moved the Z down to it’s zero position on top of the stock (which is still in place, even though it is essentially firewood) and noticed the Z Position was reading 4.295mm, when it should have been 0mm. Why is that?

What I can tell you is this:
After zeroing the stock with the BitZero v2, the spindle retracts to X=10, Y=10 and Z=19mm, relative to the top of the stock. OK so far.

Somewhere between that point of ‘stability’ and when it leaves the BitSetter, something randomly goes wrong. It can’t be beforehand, because the BitZero has set whatever zero points the user has allowed it to do, so it must be something to do with the BitSetter (Assuming the cutter didn’t move in the spindle. If it did, this would be the problem - or part of it - but mine didn’t move).

After leaving the BitSetter, there is nothing to change the software settings (i.e. the X, Y and Z zero values) other than the cutter slipping but, again, mine didn’t move.

This leaves the BitSetter randomly changing the Z height value of the stock - so it seems to me this must be a software issue.

When you have eliminated the impossible, whatever remains, however improbable, must be the truth. – Sir Arthur Conan Doyle, stated by Sherlock Holmes

3 Likes

Is it possible your Z-Axis itself is slipping? Can you move it up or down by hand with the machine switched on?

1 Like

Good question Gerry. I would like to throw a point or two into the mix. The pathway in establishing truth is frequently beset with many pitfalls. I may be wrong and you may be right, and by an effort, we may get nearer to the truth. [Karl Popper]

I want to start by assuming that Peter has done everything correctly. My basis for that assumption is simple… The bases to the boxes, which Peter produced yesterday, are clearly as he designed them and they are produced to a high standard. Notwithstanding some major random realignment of the universe and the physical laws which govern the universe we all inhabit, I don’t believe that the dice could randomly fall just so; and go on to produce correct work of that calibre.

Knowing how machinery in use needs servicing and can slip out of adjustment (Peter has had this random happening previously) it is not feasible or reasonable to imagine that it all goes belly up and then randomly puts itself right again… so right that it can turn out good work. I am arguing here for the proposition that once the machine is out of adjustment and off the rails, it will need a physical effort to track the failures and put them right.

The fact that Peter can get his box bases right… by using methods which he has exposed and which we can see to be accurate and correct; is akin to the black swan. All swans are white no matter where they are and no matter how many swans exist and we have seen them in their millions… until we see a black swan. Now we cannot say all swans are white for that proposition has been falsified.

Peter is that black swan and he works according to what he has learned and tries to implement his learning so that he does not waste his time or his resources. Where something is not amenable to normal analysis… for the best brains on the forum have tried to understand what might be the issues that Peter is having, without solutions.

If it is genuinely beyond the hive mind… and there are some seriously well informed people on the forum, then the solution does not lie with continually looking for the faults at Peter’s end. Is it not within the bounds of possibility that some bug may exist in the software and it only makes itself known randomly? If we admit that such a possibility exists, how about looking at the issues from the other end? What could cause the software to misbehave might be a question I would ask myself if I were a developer. As I am not a developer, I am talking out of my arse but the point I am making is blaming the customer may not be the most productive pathway when alternatives are available.

I spent some time talking with Peter on the phone. We discussed how the machine is producing wrong numbers and where that is happening. Peter did not sound like a wild-eyed lunatic nor did he sound as if he had no clue. He was well aware of the processes involved. I hope that Carbide 3D give him an opportunity to fix the issue, because from where I am sitting, it appears to be something happening in the software. My position for that statement is bolstered by incorrect values being randomly applied to the Z axis. They cannot be waved away by setting the stock to the top or the bottom wrongly. The values assigned are random and not consistent with the input settings for cut depth or passes… ergo the conclusion, that it very much looks like it is a software issue. No software should be inventing its own input values.

4 Likes

The truth lies dormant in our future history. [Tex Lawrence]

Could it be that you have a weak Z motor that works but not well?

No, definitely not.

I spent half a day checking the machine over and making sure the machine bed was level and the spindle perpendicular, and part of that was to check movement with the power on and off.

Valid question though, thank you :+1:

That’s a good question too, but how on earth could I check for that?

To eliminate a bitzero or bitsetter issue have you tried the job old school paper method? Then just using the bitsetter and then just the bitzero? We are working on process of elimination.
The one thing I noticed in the workflow was adding the code. What if you add the code before setting the zeros?

2 Likes

Can you capture the log when you probe XYZ?

Likely irrelevant, but,Was the machine still cutting Tab’s at this point?