Confusing BitZero Issues - revisited

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).

Thanks Peter.

Just to clarify (again :slight_smile: ) - were these measurements (6.19mm, 7.09mm) made by inspecting the cut, or jotted down from what was on the screen in CM (the current Z) ? I think there’s some confusion there as to what they were (probably in my mind only).

The first time I ran the project yesterday, resulting in the 9mm hole, I did exactly that.

I returned the spindle to X=0, Y=0 and manually jogged the Z down to the top of the stock, like this…

…so CM should show the X, Y and Z values as 0. However, these were the actual values:

I repeated this exercise with after the second attempt, but the first cut was ‘only’ 5.15mm. This time the Z reading was 4.295mm.

Also, I measured the stick-out when I ran the project earlier today, and it’s 43mm from the bottom of the collet nut to the bottom of the cutter. The top part of the cutter is just visible in the locking pin hole of the Makita spindle. This is how I ensure the cutter is held by the whole length of the collet (without there being a depth mark engraved on the shaft of the cutter).

No worries, Gerry.

No, these were measurements taken with a vernier gauge, after each pass.

I used Feed-hold to pause the process so I didn’t lose my fingers!

Stay safe, especially as the frustration rises :slight_smile:

I think @Julien has some reasonable suggestions. Measuring the tool protrusion is probably wise, otherwise it’s just going to be by eye.

Another interesting observation would be the active numbers for the Z value when a cut is too deep, but before you stop it (which will change the Z). This would let us know if CM is telling it to go to (say) -9mm, or CM is telling it to go to -1.016mm (your DOC).

I’m beginning to wonder if my other post is related to this?

Is 12.5mm the difference between a BitZero v1 and v2?

Could it be that you had selected a BitZero v1 in the interface, but probed w/ a v2?

Thanks, Will, but I’m very aware of this possibility, and make every effort not to choose the wrong option.

I confess to having done this once, but realised before probing, so just cancelled it and started again.

Good thought, though.

1 Like

Is 12.53mm the thickness of that material and “Z” 0 would be at the stock bottom/table surface?
I do not have a bitsetter, but could it be that in this instance you had the “Z” zero set as the bottom/table surface?

edit, n/m
I downloaded your file and see that the Z zero is set at the “Top” on 1.00" stock…as it should be

3 Likes

I appreciate all the help and guidance offered by everyone for this very frustrating, random event, that I can’t seem to get to the bottom of, but I’m also worried things may be going ‘off track’ a little, so I’m going to summarise everything as best I can, with what I know as fact, with a conclusion that may be considered controversial.

Things I know:

  1. The XXL is flat, square and level, and has a 25mm MDF waste board installed on top of the baseboard.
  2. The spindle (a Makita) is vertical.
  3. All the nuts, bolts pulleys and wheels are tight, the belts are reasonably tensioned and the machine moves in all directions without issue.
  4. A BitRunner, BitSetter and a BitZero v2 are installed, but everything else is ‘as provided’.
  5. I’m currently using Carbide Create Build 530, Built on: 2021-06-01 on my Mac and Carbide Motion Build 536 (I’ll upgrade to 537) on my Windows PC. Both devices use a shared folder on a NAS to share files.
  6. The routine from starting the machine to running the project is correct.
  7. Connecting to, initialising and homing the spindle works as designed with or without the BitSetter enabled, but under normal circumstances the BitSetter is enabled.
  8. The BitZero v2 works as expected when zeroing to the corner of the stock, parking itself at X=10, Y=10 and Z=19 when completed, and before starting a project. I would always use a probe to do this, not a cutter.
  9. After loading the .nc file and pressing Run, the spindle moves to front and centre, prompts for a new cutter, completes the BitSetter routine, and returns to front and centre to start the project.
  10. When it’s at front and centre, the BitRunner starts the spindle, (although CM prompts the user to start the spindle), prompts to set the speed, then goes off to start the project.
  11. It will start the cut at the correct X and Y axes, but this is when the Z starts at the correct height or cuts too deep. It does not ‘change’ the Z height mid-cut.
  12. The cutter (and the probe) are held securely and do not move.

Conclusions:
As all mechanical parts appear to be sound and the steps from starting the machine to running the project are considered to be correct, then either the BitSetter is mechanically changing the Z zero set by the BitZero, or there is a flaw in the software causing that effect, but it is not user error.

Therefore, would you (@robgrz, @Jorge, @Julien, @WillAdams, et al) please consider the user might not be at fault and the issue might be with the software at your end?

Thank you all!

1 Like

Hi Peter,

Believe it or not, I don’t think anyone has any vested interest in defending CM at all cost, there have been many instances in the past when someone came up with evidence of a CM bug, and it was acknowledged and fixed. The random aspect of the failure makes it both irritating for you and almost impossible for any developer to investigate (where would they start ?). What we have established is that something is different in your setup/workflow/project/hardware, producing this random problem when most other folks do not see it (you would argue that several people have reported similar issues, but most of those long threads ended up being user errors, which is not the case here)

I like treasure hunts, so I’ll actually be happy and relieved if in the end we do find a CM bug. But for that, we will need to dig deeper and, I’m afraid, you will need document those failure cases in excruciating details, including tool stickout at each step as I mentioned in my previous post. Or identify a repeatable way to make the BitSetter fail, but I don’t believe this will happen.

The BitSetter does alter the Z zero reference set by the BitZero, always, on purpose. We “just” need to understand why it does it with a wrong offset/compensation value, apparently randomly.

Does your BitSetter “stick” when you push it manually ? It could be interesting to probe the same tool repeatedly, and check (in the logs) what Z value it triggered at, to detect whether from time to time it comes up with an outlier value for any reason. By the way I lost track of whether you have interacted with support on this problem and where things ended up with them ?

4 Likes

Well, it now occurs to me that you should either change versions of CM or change to another sender.

That’s the only way you’ll eliminate the software possibility.

3 Likes

Yes, we’re perfectly willing to accept that their are bugs in our software — we’ve fixed a lot of them, and we usually do so based on bug reports which are repeatable at our end.

From: https://wiki.shapeoko.com/index.php/FAQ#Troubleshooting_Concepts

To eliminate the software, please check it in a 3rd party previewer — list at: https://wiki.shapeoko.com/index.php/Previewing_G-Code

Verify that you are using up-to-date software versions including the firmware (Grbl 0.9 originally, currently 1.1 and that the versions match, Carbide Motion 3 with Grbl 0.9, CM4 or later with Grbl 1.1).

Review that the machine is properly assembled according to the assembly instructions and that everything checks out per the Machine Operating Checklist: Machine operating checklist

The software works by:

  • Carbide Create (or some other CAD tool) creating geometry
  • assigning toolpaths to the geometry
  • exporting toolpaths to .nc (G-Code) files (using the appropriate post processor, Carbide 3D Shapeoko for Carbide Create)
  • Carbide Motion connecting to the machine (and if need be sending the correct settings for both the machine and Grbl)
  • initializing (homing) it
  • moving the machine to the correct origin relative to the stock and setting zero there
  • sending the G-Code file
  • appropriately changing tools as prompted

    ​The machine is able to move based on:
  • the controller interpreting the G-Code to make
  • impulses from the stepper driver — usually if they don’t work right there are horrible noises
  • sent through the wiring — check the connections and wiring — if you or a friend have a multimeter use it to check for continuity
  • received by the stepper motor — these almost never go bad
  • which rotates the motor shaft — check that this is true and not bent
  • which rotates the pulley — check that it has two set screws at least one of which is on flats and that they are secure: https://docs.carbide3d.com/shapeoko-faq/shapeoko-3-how-to-check-the-pulley-set-screws/
  • which pushes/pulls on the belt (or screw) — make sure that the belts track true through both the pulleys and the idlers and are in good condition, secure at appropriate points and well tensioned (see the assembly instructions)
  • which moves the machine along the V rails guided by V wheels (or linear rails for a Pro) — make sure that the latter are properly adjusted Tightening Eccentric Nuts - Carbide 3D and the former clean and in good shape, lubricate rails as necessary

The machine then cuts based on:

  • the trim router being securely in place
  • having an endmill properly installed in a clean and well-fitting collet properly tightened
  • being moved along by the toolpaths without running off the rails and running into a limit of motion along any axis or any workholding or physical obstruction such as a cord, dust collection, &c.
  • which matches the toolpaths in the G-Code (which brings us full circle)

For electronic accessories, check the connectors and the wiring along the entire length and that they are properly configured and enabled.

To extend on the above, we need to work up some technique for verifying the functionality of the BitZero and BitSetter.

For the former, it should be a straightforward matter of after probing, use the jog controls to move the machine around to verify that the origin was set as desired relative to the stock.

The latter can be a bit trickier, since if one is running tool changes in a G-Code file, the machine still has control — please try breaking up a test file such as:

and export each tool separately, then do a tool change in-between each file.

Let us know what you find out and we’ll do our best to sort things out.

To review, the expectations are:

  • the machine is powered up and initialized w/ a tool or probing pin loaded
  • the origin is set relative to the stock, either by hand or using a BitZero, probing once (at lower left corner) or multiple times
  • (optional) the tool change interface is used to change a tool and the tool length offset is measured
  • a file is loaded, if the correct tool for cutting the first part of the file is not loaded, it is loaded using the interface
  • the file is run, tool changes are managed using the BitSetter

I would suggest breaking things down and testing incrementally:

  • first cut the basic diamond-circle-square calibration file which uses a single tool setting the XY origin by eye at the center, and the Z origin using a bit of paper — if that file cuts well, the machine should be operating correctly mechanically
  • modify the file to put the origin at the lower left corner of a suitably larger piece of stock and set the origin there w/ a single probe operation using the BitZero — if that file cuts well, the BitZer would seem to be operating correctly
  • load a calibration file which requires tool changes but which is broken up into multiple files — use the BitSetter manually after each tool change to change the tool, and verify the Z-origin relative to the stock before each file

Not being picky, but please clarify this. Especially the “always” part… does this mean even (potentially) after the probe and during cutting?
@NewToThis
Have you tried running with all the peripherals disconnected?
(fwiw…you may have mentioned this earlier but I missed it)

I meant “systematically upon probing”. It does not interfere later (during the cut), that’s guaranteed by GRBL behavior (which ignores the probe signal input unless explicitly requested, and that happens only during probing through a G38.x command). Technically one could also imagine that CM would erroneously sends a command to change zeroes during a cut (very unlikely if you ask me, but let’s keep an open mind). A dump of the log window would settle the matter.

1 Like

Thanks, Will. I appreciate the sentiment and information provided, but seeing this has set my teeth on edge. Most (I haven’t read it all, but I will) revisits all the points raised over the previous replies, so may not be useful, specifically your reference to using a 3rd party viewer. If it works the first time, why didn’t it the second time, following the same procedures?

As I said, I’ll read what you’ve copied and pasted, but it will take a while.

I believe you, but it’s a struggle when I’m confident I’ve done everything I can to make sure I stick with the guidance - to the point of writing and pinning up a checklist - for it to go wrong at a random moment.

Maybe permanently enabling the log would help - at least temporarily? Maybe an option in Settings to keep it enabled (disabled by default) would be a good idea, then we can keep it that way until a problem occurs. Of course the log for a particular session doesn’t need to be saved after a successful session, but saved manually if the machine ‘misbehaves’ (Which would also obviate any performance issues, as identified by Will).

No it doesn’t, but the BitSetter button did come unscrewed from the mechanism and I had to screw it back in with a drop of thread glue.

Not yet, other than for flattening boards with a fly cutter, which went well. I’m convinced this is an issue between the software, and/or the BitZero, and/or the BitSetter, so when I next run a project, I’ll probably dispense with the BitZero and see how that goes.

My thinking too. I have looked at some other senders, but I want to retain the use of the BitSetter, BitRunner and BitZero (otherwise they would have been be a waste of money), and I haven’t really found something I’m confident to play with, yet.

Please provide a .c2d file, generated G-Code, step-by-step notes on how you are securing your stock and setting zero relative to it and managing all tool changes and notes and documentation on how a workflow which should work, results in an incorrect positioning relative to the stock which is repeatable — with that, we can look into this as a problem with the software.

If things aren’t repeatable, then it is likely some electro-mechanical aspect of the machine which is having a problem — we need for you to work with us on support to work with us so we can determine what is causing the problem and how to address it. Send an e-mail to support@carbide3d.com describing the difficulties you are having and we’ll do our best to sort this out with you.

I know you mean well, Will. But this is clearly copy-and-paste text from 100 other support responses you make, and to be honest it sounds a little patronising after two huge threads detailing pretty much all of this. Peter has done some of these things already. We have his c2d, the gocde fine, pictures of his stock, how its secured, what he is doing. (plus, how the stock secured is irrelevant for nearly all of the occasions when you ask for it.)

2 Likes

And when I’ve run his files, I don’t get the results which he notes, so it’s not repeatable, so we need for him to either increase the detail of the information which he is providing so that it is repeatable, or work with us via an e-mail to support@carbide3d.com so that we can determine what is wrong with the machine if it’s not the software and not user error.