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