Why Additional BitSetter Cycle in v635?

Software Carbide Motion
1

Pre- v635, I would set zero, start the job, and after confirming the tool change, a bitsetter cycle would run.

In v635, when I set zero, a bitsetter cycle is automatically ran. I can then start the job, confirm the tool, and another bitsetter cycle starts.

In understand the need to have the cycle after the tool change, but what’s the point of having it after setting zero? This appears to be just an extra activity which takes longer for my job to start, since I have to wait for 2 cycles.

If there a benefit to me that I’m not aware of and should be taking advantage of? Or is the new extra cycle just a necessary evil to insure all measurements are correct?

Thanks for indulging my curiosity.

2

Previously, it would run the first bitsetter cycle when you initialized the machine. This is to establish a baseline using the first tool or probe (dowel) from which to measure all the other tools.

They eliminated the tool measurement on initialize, and moved it to the set zero function.

Now that I think about it. If I run 6 jobs during a ‘session’ (without reinitializing), and set zero for each job, then I have 6 tool measurements (5 of them redundant). Whereas previously I would only have 1 during initialize. (In addition to the measurements for each tool change)
The downside being if I don’t have a tool in the spindle on initialize it would either fail, or measure the collet nut.

The logical/ideal solution would be to measure the tool on toolchanges only. Of course you need a button to measure the tool when the toolchange occurs outside of a “Run” cycle.

3 Likes
3

Yup, i posted in another thread about the same issue, i don’t get it. I like how much faster things are, but that additional cycle and then the return to zero makes no sense, especially since you are most likely going to run a job next, so then you have to move over and run it all again.

4

I believe they did that for use with the bit-zero probe. It isn’t a redundant cycle of you are using the probe rods. I do get frustrated with the obsolete cycle when manually setting zero’s.

5

It does seem a bit redundant if you are just setting a new Z zero using the paper method and not changing bits between jobs.

6

What has been bothering me about this new behavior is specifically that it returns to the same X/Y when it’s done measuring after setting Z.

My workflow is pretty much the same every time:

  1. Jog to X/Y zero, zero them out
  2. Jog to Z zero with paper method, zero it out
  3. Start job

With how much faster tool measures are now, the redundant measure after steps 2 + 3 doesn’t bother me SO much. But it’s annoying watching it jog from the bitsetter all the way back to the X/Y from step 2 knowing I’m about to start the job immediately and watch it jog all the way back to the bitsetter again.

Would love for a popup or even a hidden “advanced user” setting that lets you decide whether it should return to the X/Y after setting Z.

7

Yup, several thread on it, we will see if they update it.

100%

8

I am pretty certain the probe right before job run is to make sure the bit had not changed, without a tool length offset having been applied, since zeroing. Looking at it from C3D’s point of view I could see where they would want to lean into reducing user errors and therefore support calls, but I could see an ‘advanced user’ mode where some of the guardrails are removed for the user in trade for the user opting in to accepting responsibility for things going wrong.

9

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