Let’s start ex nihilo.
Would you please post your settings for Grbl and preferences in Carbide Motion?
Does the machine jog as you would expect it to?
The machine homes, jogs, and runs MDI perfectly.
The deeper I delve into the issue, the more it’s pointing to a zero issue. The program (both meshcam AND carbide motion) refuse to accept any zero other than the front left.
I am in the process of remaking my jigs, to see if I can make the default zero settings work. Fingers crossed.
1 Like
@JamesC, don’t give up yet! We’ll get through it. The Nomad is a great little machine.
First of all, I was wrong about the triads. The unlabeled triad is the geometry origin, and the labeled triad is indeed the Program Zero.
Build 27 has fixed the earlier MC6 problem about not being able to set the Program Zero on bitmap inputs, at least with its included fuzzydots sample image, with which I played this morning. I have not tested other images yet, maybe tonight. I was having trouble with my own images, so it might be image-dependent. But your screenshot showing the Program Zero is valid.
I ran your gcode on my Nomad this morning. I’m using grbl1.1/bCNC and the gcode ran properly. I only ran the first couple of minutes, where it was still roughing out the rear left corner. But with the machine zeroed on the center of the table, the gcode operated perfectly.
bcnc doesn’t handle rotary axis commands (EDIT: becuase 4th axis isn’t implemented in grbl yet), so I needed to edit the thirteenth line from
G1A0.000Z-1.257F127.0
to
G1Z-1.257F127.0
What MeshCAM postprocessor are you using?
Randy
1 Like
I’m not using a post processor. I use meshcam, and run the file directly with carbide motion.
not sure if I can talk my boss into laying out the cash for more software.
Good news: I have remade my jigs, and as long as I am careful, I can make the “front left” zero work.
I also found a nice free .bmp to .svg file converter, and that has made all the difference. I haven’t cut a new piece yet, I’m hoping to do that today. Wish me luck!
Rather than trust to any sort of auto-tracing, I’d suggest re-drawing any pixel image — you’ll get much better results and have absolute, total control over the results.
The postprocessor is what you choose in the MeshCAM puilldown box “Save as type” in the file save dialog. As I mentioned above, the postprocessor is a text file that tells MeshCAM how to format the gcode. It is part of the MeshCAM setup.
But it sounds like you’re past that stage at this point, so good news and the best of success.
Randy
Yeah, that is a confusing bit of terminology there — post-processor being a mandatory selection for G-code generation in many CAM apps, while there are additional utility programs for post-processing a Gcode file after generation.
We do have an entry for this on the Glossary: Shapeoko CNC Router, Rigid, Accurate, Reliable, and Affordable
Post-Processing/Post-Processor
An automated process that takes G-Code commands produced by another process as an input and produces a modified output. Post-processors can be found integrated into CAM software, as well as in the form of stand-alone applications or scripts. Post-processing is often used to translate generic G-Code into variants of G-Code that only support a subset of the full command set. e.g. Some controllers do not support the drilling commands, and a post-processor could convert these commands into an equivalent set of G01 Z-axis movements that are supported by the target controller. Another example of post-processing is the modification of feed speeds in the original G-Code commands to scale or limit speeds in the resulting G-Code.
Seem okay, or should it be edited / improved how?
Agreed, Will, but I don’t know what to do about the terminology either. Your explanation above is good.
The toolpaths that CAM programs generate are independent of the machine tool–they are pure geometry. The “internal” postprocessor will add the setup, toolchange, etc. lines and format the toolpath code for the machine controller language. So that is true post-processing. I don’t know of a way to get the “pure” toolpath gcode out of a CAM program without running it through the internal postprocessor so all generated gcode is actually post-processed already.
My post-post-processor has always been a text editor… 
I’ll do search-and-replace to edit feeds, safety/retract heights, etc. and hand-editing to remove superfluous moves (MeshCAM’s famous always-move-to-X0-Y0-first…)
So my tongue-in-cheek suggestion is to found the term post-post-processor for those external utility programs. 
Randy
1 Like
Ha ha, ok, I get it 
Right now, with my new fixture, and enacting revelations from talking with you guys… the machine seems to be working.
This is just a plastic test piece… the real pieces will be 6061 aluminum. If I remember, I’ll post more pictures.
1 Like
Ouch, but then we’d need an additional, specific term for “post-processor for G-code from CAM apps which do not have a post-processor configuration option” for full specificity (from the department of redundancy department).
James, 
Good work, and nice-looking fixture.
Are you using coolant, or just an air blast? I’m sorry if I have missed a description elsewhere on the forum…
Randy
1/8 2-flute endmill, air blast to keep chips away… and it has a nice cooling side effect as well. I tried using a 1/4" cutter, but it’s too much for the weak little motors. I may readdress the size issue now that I have more important problems seemingly solved.
1 Like
Good morning… I seem to be able to produce the parts I need… however, I still have one problem: Z zero.
When I set the zero to the top of the part, the NOMAD runs the program about 3/4 of an inch above the part.
When I set the zero to the bottom of the part, the NOMAD goes way beyond the .26 max depth, and digs into the fixture, which is crafted to allow for .062 extra clearance.
I hope you guys have some insight into this small issue. Meanwhile, I will keep fiddling with settings and see if I can accidentally fix the problem.