The new version of CM (636) immediately measures the tool on “Zero all” or Zero Z". The tool, in my case, has already been measured. The big downside is that I’m left unsure whether the zeroing has been successful.
I’m running a Nomad Pro from an Apple iBook.
I am running CM 639 and the changed work flow happened a couple versions back. So my machine initializes and comes to the front close to the BitSetter. Then I jog and set my X and Y Z. I typically use the center so I dont do all 3 at once. Then depending on whether I am using top or bottom of material I use my BitZero. So when I start the probe for the Z CM asks me if I want to measure the tool. If I say yes it moves over to the BitSetter and measures and returns to the previous position and probes Z. If you say no to the question then nothing happens.
So is that the behavior you are seeing?
Hmmm. I just yesterday downloaded what appeared to be the latest version labeled 363. Maybe 639 is a beta?
I’m unfamiliar with bitsetter, I guess it serves the same purpose as the built in homing on a Nomad. Anyway, on the Nomad, I use the jog menu to move the machine to an origin I want to set a 0, 0, 0. Once the machine is at this position there is a menu button to zero the machine. This opens a page where there are buttons to commit the current positions to zero. In all previous versions of CM the values all change to zero when these buttons are pressed. No surprises. But with v. 636 the machine measures the tool (Again, the tool length has previously been measured.)
I see there are newer, beta, versions but none seem to address this bug according to the build list.
639 was a beta, the new beta is 640:
I just tried using 640, the behavior is the same.
Yes, I had read the blog post but since I’m not using BitSetter, as mentioned in the blog, I didn’t think much of the text applied to the Nomad. Evidently it does? I thought BitSetter was an add-on for Shapokos. I guess the built-in tool measuring apparatus of the Nomad is also “BitSetter”? I had never heard this term applied as such.
So I can be confident, with my Nomad, that the z is confidently recorded in this process? I think I may like this if it ultimately reduces the number of times a redundant tool measuring takes place.
The tool length probe in the Nomad is a BItSetter.
https://carbide3d.com/blog/nomad-3-plus-something-else/
BitSetter is our absolute favorite accessory and it’s something we’re very proud of. We created it with the original Nomad and then eventually moved to the Shapeoko.
The Nomad’s and the Shapeoko’s use the same controller. Although slightly different in appearance they are functionally alike.
Thanks, I finally figured out that the tool measuring device on the Nomad was also termed a BitSetter as far as the blog on the newer versions of CM were concerned. I knew they served the same purpose, just hadn’t encountered the moniker applied to the Nomad. I’ll give the 640 build a new chance after this latest test. I like the idea of fewer tool measurings.
I understand what you are saying. I just picked up a second Nomad3 and installed CM into another laptop. I went from a previous version to 636 and immediately noticed this. I would always manually set my z zero using the job function and it would just change zero in my WCS. You can verify this with the work position screen and the tool didn’t move. Now, anytime zero is set, it will run back to the fixed tool sensor and check. I’ve found this to be worrisome at first but it seams to be working ok. Time will tell if it’s off in any way. A quick way for me to reverify is to move the tool back to my xy I used to set z0 and enter z0 in the MDI. I actually use a .020 feeler and use g20z.020 but same thing. Manually verify the correct Z and then continue. I do like the older way but I think this resoves the issue of someone changing tools mid jog and not remembering to measure the tool before zeroing Z.
I’m not sure if I have something setup wrong, or if I’m just misunderstanding the process. Let me attempt to describe what is happening and let me know if this is the expected behavior.
My previous project (in case this is important) was a job that had 3/4 inch stock that was zeroed to the bottom of the stock. After that job finished the router retreated to this position, and I turned the machine off…
… couple days later I turned the Shapeoko 3 XL back on, and before the initialization this is what Carbide Motion reported…
… the bit was WAY higher than the reported 0.749. The last step in the last job was cutting material (with tabs) out of 0.75 material, but it would have finished at a z height of 0.000, so I’m not sure where this 0.749 came from. That’s probably too much information, but this was the first sign that something was off. I let Shapeoko 3 XL perform the initialization process which then positioned the router to the front…
… and now Carbide Motion reported …
… if I attempted to start the job, Carbide Motion then warned me …
… I thought the new work flow was designed to allow us to skip the re-measuring the Z, but clearly something about this process is not working for me. I clicked “No” on that “Bounds Check” dialog, then found that if I click the “change tool” it will remeasure and correct for the odd Z height measurements.
So I can make this new workflow work, but it appears to me that the new workflow has become more tedious than the previous workflow, so I’m assuming I’m doing something wrong. Just need some guidance.
As long as you have a tool change (M6) command in your program, I believe it shouldn’t matter, at least it didn’t when I first beta tested this. But the other day, I noticed something similar.
The new workflow was supposed to not break the use case where you don’t need to set a zero before running a repeat program, and even ones where there’s no tool change or M6 command. But maybe something got lost in the updates. I’ll do some testing and report back to the code monkey if I can replicate this.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
