Work Flow / Software Problem?

I’m not sure if this is the correct place to post this issue or not, but here goes my description…

To start, I have an XXL with a Bit Setter and a Probe, and I am using CC and CM.

My son and I have been carving flags. The flags are roughly 19x38 so we can only carve 1/2 of the flag at a time. Typically we will do the Union first and then flip the board around and do a logo. Here is the issue. Today we carved a very nice logo of a local County Sheriff following our typical work flow - secure the board, set XY, use the PROBE to set Z, run the gcode, change bits using the BIT SETTER. Everything is great. Once that gcond is complete, we rotated the board 180 degrees, load a gcode for the stars (note that this is the same gcode that we have used over and over), reset XY, reset Z using the PROBE, run the program. The program asks for a new bit, checks Bitsetter, start the router, and then we wait for the v-carve stars to begin. We know from experience that the carve starts our very shallow and by the time all of the v-carve passes are complete, we should have 50 perfect stars.

Here’s the issue - somewhere and the v-carving depth changed. In today’s case the v-carving started out about 1/4-inch too deep and another board ruined. This is not the first time we have seen something like this. We follow the same work flow each time - 98% of the time everything works fine. Actually I should say that 75% of the time everything works fine, 23% of the time it’s definitely User Error, and the remaining 2% is this unknown issue that is driving me up a wall.

If both gcodes use the same design references (i.e. both designs set the zero depth at the top of the stock, and both designs use the same stock thickness), where or why would there be a change in the Z starting point? Has anyone else had a similar issue?

Hi @Scott219,

Can you go through you workflow in even more detail, and specifically at which precise steps you proceed to change the cutter and what you do then?

We have had a number of cutting depth issues that ended up being due to folks changing the tool and not telling CM they did, and there are sequences of actions than can lead to the BitSetter adjusting your Z0 reference whereas it was not your intent.

One wrong way to do it for example is to have that initial BitSetter probing during machine initialization, then physically change the tool and re-zero with it, then proceed to start the cut, where a new BitSetter probing will happen: what happens then is that CM will compensate the Z0 you set by the difference between that latest probing and whatever was the previous bitsetter probing before that: in this scenario it happens to be the one at machine initilization, done with a different tool. Therefore this tool length compensation ends up being wrong, and you have a cut at the wrong depth.

To avoid this, always, always use the “Change Tool” button in CM whenever you go and change the tool in the router, and this should never happen again.

You could argue that you always do the exact same steps, but if you are like me or any other average human being, our “error rate” in repetitive actions is typically one percent or two, so it is not unlikely that in 2% of the cases, you forgot a step or did things in a slightly different order :slight_smile:

1 Like

Yesterday, this was the first carve of the day, so the sequence was, to be best of my memory was:

Turn on XXL; Connect to XXL; XXL initializes and moves to bit change position.
CM asks for a bit; Insert bit; XXL goes to BitSetter and returns to position
load gcode; set XY at 0,0; manually move gantry to center of carve area on the stock; use probe to set Z; run gcode
CM asks for the first bit (1/8-inch, which at this point is the same bit that is in the router); XXL moves to BitSetter and returns to position; Turn on router; run gcode.
CM prompt for tool change; insert 60-degree v-bit; XXL BitSetter check and return;
Turn on router; run gcode; finished with no issues

Flip board 180-degrees

Change tool to 90-degree v
load new gcode; set XY at 0,0; manually move gantry to center of carve area on the stock; use probe to set Z; run gcode
CM prompt for tool change; (90-degree v-bit is already in router); XXL BitSetter check and return; start router; begin carve

At this point the new carve starts out too low and the run is killed.

I should also point out that this is not the same problem that I was having in my May posts. I think my problem back in May was that my work surface was not as flat as possible. In that case a very small difference in stock surface can become very obvious when carving patterns like stars (every one should look exactly like the one next to it). In this case the starting depth is 1/4 inch off and it is definitely not the stock or the waster board.

Note that there are two ways to position the BitZero:

  • registered against a corner so as to Probe XYZ
  • placed on a surface and possibly aligned against an edge to probe a single axis

If you use the wrong placement the Probing will be off by the height of the lip, ~1/8" (3mm)

If you’ll post a .c2d file, and step-by-step notes on how you are securing your stock and setting zero relative to it we’ll do our best to work through this with you.

In this application I only use the BitZero for Z only. XY is set manually.

I suspect the first change was not done with the Run Tool Change Button.

2 Likes

Would that matter if the Z depth is reset after the tool change?

Will,
Attached is a photo of my messy setup. If you zoom in you should be able to see the stock clamps.
I have attached the .nc and the .c2d files.

Flag Stars Area 19x38.c2d (343.6 KB)
Stars 19x38 Flag.nc (73.3 KB)

With Bitsetter involved, NEVER change a bit without going through the C3D Bitsetter “dance.”

1 Like

As @CrookedWoodTex notes you have to use the BitSetter for all tool changes if it’s enabled.

So, in the work flow, are you saying that once the machine is initialized, NEVER EVER change a tool without using BitSetter EVEN if you run a new gcode on a new stock with a new Z set? I assumed that loading a new gcode and using BitZero would take care of any tool change that might have occurred prior.

2 Likes

Correct. The machine tracks by length offset and changing that confuses things.

Well, this increases my USER ERROR to 25%.

Thank for the help!

This topic was automatically closed after 30 days. New replies are no longer allowed.