Mine Nomad loses zero between job loads even if power is not cycled. Even if I zero the machine, leave CM open while I’m working the Meshcam file then load the Meshcam file, it will lose zero. I don’t trust it to keep it more than a minute or so. I don’t know why but its a real pain.
Really? I know you have a Nomad 883 Pro like I do. I don’t see this.
With CM and the Nomad both on the zero is known… it doesn’t have to be forgotten. That said, that forces old school never depend methods.
Mine (an earlier version) remembers zero about 95% of the time.
That’s good to know. My quick test mentioned above worked - one shot. Thinking back, I’m pretty sure I’ve seen the zero preserved more than a handful of times. As I said above, I never assume the zero is preserved. If it looks like it is, I check it before starting.
@warba has gone through the same machinist’s school of hard knocks I did.
I’m sorry this happened to you! I’m sure @mbellon is right about the best practices for machining, but for what it’s worth, Carbide Motion has reliably recalled zero every single time I’ve ever used it in the year or so I’ve had it. This includes turning off and unplugging the machine, unplugging the usb, and rebooting the computer. It’s recalled the zero for weeks.
This is because, as @robgrz has stated in some thread somewhere on here, CM stores the zero (or offsets) in a text document on your computer somewhere.
If this behavior has been changed in the latest version of CM, that is a major change and they REALLY need to let us know about it. But I rather expect it has not been changed. If people are losing zero often, then I think maybe there is a bug somewhere. It’s supposed to remember it!
As a side note, here is how to record your zeros (offsets, really), if you are doing a job that will be repeated and have the same zeros every time: move your cutter to the correct zero for your job, then go into the “set zero” screen in CM, and click “clear offsets,” which will show you the absolute machine coordinates for that spot. Note these somewhere safe – another Nomad user just wrote them directly on his custom spoilboard. Make sure to hit “set zero” before you leave the zeroing screen.
… Carbide Motion has reliably recalled zero every single time I’ve ever used it in the year or so I’ve had it. This includes turning off and unplugging the machine, unplugging the usb, and rebooting the computer. It’s recalled the zero for weeks.
This is because, as @robgrz has stated in some thread somewhere on here, CM stores the zero (or offsets) in a text document on your computer somewhere.
If this behavior has been changed in the latest version of CM, that is a major change and they REALLY need to let us know about it. But I rather expect it has not been changed. If people are losing zero often, then I think maybe there is a bug somewhere. It’s supposed to remember it!
Excellent point. Could this be a problem with the latest CM? Are we all on 357?
FWIW, I used the exact same computer. I didn’t even unplug it from the port when I fired it back up. Where is the location and name of the file you are saving to on a Mac?
Shame on me for assuming the machine kept zero. Given that the above quote states that zero is stored on a file on the computer initially used and that I used the same computer on the re-run, yes I do place blame on Carbide Motion for failing to keep its side of the bargain. I’ve learned my lesson and I will not trust it in the future however. That was my bad, but in this instance I really don’t believe it was my fault for relying on the machine or the program sending the code to remember zero if that is one of its features.
Just to make sure we are talking about the same thing. … the"center of the table" zero has always been right. When I rezero for the current job the Nomad (or my computer) has lost that zero many times. I set it like always, go set up a job in MeshCam, then watch it go to some other zero when I run the job. I then rezero on the workpiece exactly the same way as I previously did and it works.
I don’t think user error is to blame for what I see happening.
Digging up this ghost of a thread from 5 years back, but I’m seeing the same thing in CM #535 on my new Nomad3. I just ran a job that used a small portion of the stock at the front edge. I carefully zeroed the Z to just kiss the wasteboard. First piece came out flawlessly. Then I simply jogged my Y by 40 mm and rezeroed just Y) to make a duplicate at a new location in the same stock. But when I did, Z shifted by about 0.7mm, causing me to cut into the wasteboard (no biggie) and end up with a part that’s 0.7mm too thin (big problem).
I didn’t cycle power, shut down CM, or even re-load the file. Not quite sure how Z changed. X managed to stay the same, through.
At first I thought I was seeing things, but it just happened to me again, this time when swapping out stock. I ran a job (in foam) to be sure my Z was correct. Half way through, I was satisfied, so I aborted and loaded up my UHMW stock. I was about to hit RUN when I decided to double check my Z, and it was off (high) by about 0.7mm again.
Seems like this is a bug, and fairly consistent, so maybe the CM folks can retrace my steps and find it. For making more than 1 of something, this is a crucial need to get to even moderate production levels.
If you did not reset zeroes in CM, and did not power cycle, then chances are CM has nothing to do with it since Z zero is (mostly) managed in GRBL at the controller level.
I can imagine three possible causes:
Z axis skipping steps during the previous cut (unlikely in your case if you were using a 1/16th endmill, and with standard plunge rates)
The tool length probe sticking slightly, throwing off the probing by 0.7mm.
the bed OR stock not being level to the machine axis and perfectly flat. Did you get that 0.7mm offset working off a freshly surfaced stock ?
and then again it could be a bug, what would help is if you could come up with a detailed list of steps that produce the problem in a repeatable manner.
It feels like a bug, but it’s happens so consistently that I’d be really surprised that others aren’t reporting it. That makes me think it’s something consistentaly wrong with my process. Here’s what I do…
Set up job with fresh 6x6x0.5" stock, referenced to front left corner at wasteboard. X&Y get referenced by eye, since I have lots of extra stock, and I don’t need ot be on the money there. Z gets referenced to the wasteboard, by tramming to within the thickness of a sheet of paper, then down an extra 0.025"
Start job with roughing and cleanup paths - CM does its dance to calibrate Z based on the bit placement, etc.
After roughing, change cutters, and proceed. CM again calibrates the new cutter length, and goes on to clean up and finish the job perfectly.
Tram the Y carriage back 40 mm to a fresh spot in the stock, and re-set Y zero to this new position.
Insert the roughing cutter, and prepare to re-run the same job.
At this point, my Z will have changed, because I moved cutters in the spindle. If I do a reality check vs. the wasteboard, it’s obviously different, since CM doesn’t know how deep I installed it. When I run the job, the startup check vs. the plunger probe doesn’t seem to re-cal my cutter-to-spindle position, but possibly just uses the position gathered from the original plunger probe scan from the previous job. The result is that the spindle will either cut air, or crash, depending on whther I installed the cutter higher or lower than in Job #1.
Am I missing a step here? It seems like CM should re-cal my Z when it does its startup “dance” at the beginning of a job, but I don’t think that’s happening. Do I have to run with the touch probe?
Workaround for me: If there’s an easy way to cut & paste duplicates of a part in MeshCAM, that would work for me. I can fit 4 pieces in my stock, so if I could combine them into a single job, then my zero would hold for that entire run, until I switch stock.
Thanks for the help here - this forum and support from Carbide have been top notch.
" * Insert the roughing cutter, and prepare to re-run the same job."
It does seem like you might be doing something wrong here. Are you ever changing the cutter without a prompt on Carbide Motion asking you to insert a endmill?
You should never replace a cutter unless there is a prompt in CM telling you to put a cutter in and resume.
Yes, but only after the first job completes (successfully) and before the second one starts. Maybe I shouldn’t change the tool immediately after #1, but only when prompted between scan #1 and scan #2 of the second job?
I’m not really clear why the Nomad3 does its bit length check 2x at the start of a job. Maybe this is the source of my trouble. Should I leave the old bit installed when it does the first Z plunger scan, and then only change back to the roughing cutter after that, and before it does its second plunger scan?
Yes, please leave the old tool installed, and only do tool changes when prompted by the program, or when you initiate one using the button in Carbide Motion.
OK - I’ll trust you there, and try shortly, since I’m about to finish a job and start a duplicate.
But can you explain what the Nomad3 is doing on these two probe routines when a job starts? Seems like the second one verifies the depth of the tool in the spindle. And I assume that probing between tool changes does the same. But what does the very first one do?
When you start the job, it measures the length of the tool you left in after you did the zeroing, then prompts for the tool for the job. Then it measures that tool to see the difference in the length between the zeroing tool and the job’s first tool. If those tools are the same, it does appear like it is measuring the same tool twice.
