My Nomad is frustrating

I produce a file with meshcam, then load it into carbide motion.

Carbide motion reads it, and totally ignores my ZERO settings, and tries to make the piece off to the side, and in some cases, tries to go beyond the limits of the machine table.

Why is Carbide Motion ignoring my zero setting? I need to work from the center, so that’s where I have my zero set. MeshCam is buggy when it comes to the “set machining center” feature, so I’m not sure which pice of software is screwing up,

Can anyone help me?

Can you post a picture of your MeshCAM setup?

Or can you upload the. Mcf file.

I think your program zero and your machine zero are not matching.

1 Like

I’m sorry, but where do I find the mcf file?
And what setup do you need? The toolpath window? Sorry if I’m dense lol

Note: If I don’t answer right away, it’s because I only have access to a computer at work. Thank you for your concern, I hope we can figure out what I’m doing wrong, or if there’s something wrong with the software.

@JamesC, in MeshCAM use the Set Program Zero command to put the 0,0,0 location where you want it relative to the stock. The actual stock and geometry positions are irrelevant–it is the Program Zero that is the one link between MeshCAM and the machine.

Then on the Nomad, place the tool tip where you want 0,0,0 to be, and be sure to zero all the coordinates at that point. I’ve read of people just placing the cutter tip but not actually zeroing the coordinates, and that produces results similar to yours.

If you do those two things, the machining will be correctly placed. MeshCAM is very reliable at generating the gcode relative to the Program Zero. is a related discussion over on the MeshCAM forum. If you search “program zero” over there you’ll find a bunch of related discussions too.

1 Like

It might be worth your time to take a look at this video. Lots of good info to get you started:

It looks like he also posted a tutorial on YouTube showing his process for zeroing the machine. This is an older version of Carbide Motion, but the general principles should all be the same.

1 Like

@JamesC wow you got the big guns weighing in on that thread. Zeroing is tricky aye and if you stuff it up your part ends up a gorged mess. That’s why I can’t wait for the carbide active probe to be ready :smile:

That’s what I’ve been doing, but it still tries to machine the part in random locations. I will go through the stuff everyone has posted, and see if I can find where my error is… thank you for your answer!

Ok, here we go with step by step procedure:

Set NOMAD to center of part, zero x and y, Z zero is actually the top of the part, so right now it’s up:

Define stock. I left the little boxes unchecked, because they seem to have no effect on my issue: please note that the problem happens no matter what I do with this screen.

program zero is set to the center, confirmed by the geometry screen:

Everything looks good… let’s save it and send it to Carbide Motion:

Carbide motion ignores the zero setting. This will cause the machine to slam the tool into the tool checking pin.

Any thoughts?

It appears meshcam is ignoring the zero setting… and generating bad gcode for the nomad.

1 Like

Where do I get that version of Carbide Motion? Mine has way less functionality

The latest versions are always at:

James, the toolpaths MeshCAM outputs are independent of machine. The postprocessor will format the gcode for things like mm-to-inch scaling, adding tool change commands, etc. but that is after the toolpaths are already generated.

Please zip and upload the gcode corresponding to your screenshots and I’ll take a look at it.

The CM toolpath extents screenshot (expressed in mm) is not out of line with your stock definition (expressed in inches).

I have moved away from CM and am using grbl 1.1 and bCNC to have an all-inches machining experience. I tried and tried, but could not deal with CM’s mm-only operation. EDIT: This is not a reflection on CM software, which is nice, but on my parochial inch-orientation. :slight_smile:


here’s my code. Sorry it’s not zipped, that’s way over my head… but file hosting… that’s right up my alley.

Hey, that works too! :slight_smile: Thank you.

(STOCK/BLOCK, 149.690, 39.374, 2.540, 74.845, 19.687, 2.540)

That tells CutViewer the stock X,Y,Z size in mm and the Program Zero location in mm relative to the front left bottom stock corner (as is CutViewer’s convention). Confirms the Program Zero is in the top center of the stock.


Tells the machine that mm are the units, absolute coordinates, and tells CutViewer a 1/8" diameter square-end mill.


For some reason MeshCAM always makes a first move to the Program Zero at Retract Height (which is 1/2" here)

(Roughing Level Depth: -0.050)

Rapids over to the back left corner ot the stock, then feeds down into the stock to -1.257mm, approximately the -.050" first roughing depth. MeshCAM’s roughing depths are always “rough”, and a little less than the theoretical depth.

Then it roughs the first level back and forth in X and Y and then

(Roughing Level Depth: -0.099)

Up to the Retract Height, rapids left and back and then feeds down to the second roughing depth in two steps. -2.515mm depth is approximately the theoretical -0.099".

Then moves back and forth etc. etc.

I’m away from my PC with CutViewer Mill until tonight, but I don’t see anything amiss in your gcode right now.



1 Like

Looking at the gcode, it appears that meshcam is correctly setting the top center of the material as 0,0,0 (X goes from approx -80 to 80mm; and Y similarly has the same positive range as negative range; and the first G1 with a Z goes negative)

I’m not sure what Carbide Motion is doing incorrectly with respect to the zeros.

Light bulb comes on. @JamesC, you are working from a bitmap, aren’t you? And what version of MeshCAM are you using? There is a Program Zero discrepancy between MeshCAM 5 and MeshCAM 6 when dealing with bitmaps. See for a possibly related discussion which links to an older discussion on the subject.

I think that the unlabeld X-Y-Z triad in the lower left corner of your geometry is the true origin.

But without knowing more of the process chain I don’t know how the labeled X-Y-Z triad got where it is…but the gcode is generated relative to that point, which I also don’t understand at this point…


1 Like

Using version 6

So, let me see if I have this straight:

no matter what setting I give it, it still uses the front left (or rear left?) as the zero.
I’m cutting these objects from irregular stock… seems silly if I have to machine the parts before I can machine the parts :stuck_out_tongue:

I will have to redo my entire setup. Currently I have a jig, because I will need to make a lot of these things. This is why I need the program to accept my zero in the center.

Image and video hosting by TinyPic

You have to begin the actual machining with stock at a regular thickness — otherwise the chip load is wrong and you’ll risk breaking a bit — one can surface the stock using the machine in suitably light passes, but note that that may result in some surfaces being cut with inadequate chip load, resulting in a poor finish — make a finishing pass after said surfacing for best results.

As a machinist Uncle once told me:

Precision has to start somewhere.

In the picture, which corner is the default zero? Ignore the red circles lol being lazy and using an old picture.

I adjusted my zero.
I just tried to run the program using the g-code posted here, and the machine slammed into the left side.

moved the machine zero to the other side (back right corner) and the program moves to the middle back and cuts air.

sigh the fight continues.