I use NX at my day job for CAD and CAM. I would like to output my program directly from NX, and I was wondering if anyone else has done this and with what post-processor?
The closest I have is the generic mill 3 axis. With some manual edits I think I can change the program to work on my machine but I would like to have a polished output so I don’t fat finger any mistakes.
Any help is appreciated.
Thank you
There should be one at:
The firmware we use, Grbl, uses LinuxCNC as a reference for G-Code, which in turn uses Mach3 as a reference, so try them if need be.
1 Like
It looks promising, but I cant seem to download them since its from an archived page.
Hey, great to see another NX user.
I work for Siemens PLM, and the principle part of my job is making posts & simulations.
I have a post that I’ve started for the HDM. I don’t have my machine yet, but when it arrives
I will test & finish that post.
I don’t know what, if any differences between the SH3 & HDM desired output.
I can send you a copy of the unfinished post I have, and if you can let me know what changes are
necessary we can get a post set up for the SH3 that doesn’t need any edits.
Which version of NX are you using?
2 Likes
The big post-processor difference would be if tool changes (using a BitSetter and handled by Carbide Motion) would be allowed. The BitSetter is an option on the SO3 and 4, but standard on the Pro and HDM and Nomad.
1 Like
Thanks, Will
That is easily handled with a UDE (User Defined Event) on the NX operation or tool for the SO3 & 4.
And I could just make it automatic for the other machines. Unless there is a reason you might not want
to use it sometimes on the newer machines??
I suppose I could create a simple test part in both NX & CC, change the machines/post in CC & compare the output. I’ll work on that & see if I can get 2 posts set up.
Stand by… 
OK, changing the machine didn’t change the output.
I’m guessing the bitsetter is controlled by the toolchange line in the code, so no impact on what the output should look like?
2 Likes
Hey Tod
That’s awesome you work for Siemens PLM! I saw your post from the other month and was actually hoping you would be able to help, so this is great!
I’m using NX12 mainly and have access to NX8.5 if needed.
I do not have a bit setter so this could be a good test of an output without it. I just had a goto UDE at the end of a tools last tool path to bring it front and center for tool change.
If you are willing to share the post for sure I can try it out on the SO3 to see how it behaves!
Yes, the big thing is that if there is no BitSetter, each tool should be written out as a separate file — that requirement/limitation can be foisted off on the user though.
1 Like
That’s no problem. Its easy enough for me to separate programs by tool and output them separately.
Thanks, Will
So with the bitsetter the output should be
G90
G20
G0 G53 Z-0.197 (Move to toolchange height)
M05 (Make sure spindle is off)
M06 T102 (Move to toolchange position & pause)
Without bitsetter…
G90
G20
G0 G53 X0.0 Y0.0 Z-0.197 (Move all axes to toolchange position)
(LOAD TOOL: MILL_0.125)
M1 (pause for toolchange & Z zero set)
Or does the tool need to be loaded and zeroed before each file is run?
1 Like
W/o a BitSetter the tool is expected to be loaded and zeroed for a given file before it is run.
2 Likes
Got it! 
Is G53 non-modal in GRBL? And did I make the right assumption about G53 X0 Y0 Z0? (toolchange position)
1 Like
It is non-modal as noted at:
but, it’s not necessary to make the move — Carbide Motion will handle that, just put in the tool change command.
The only G53 move I can think of in G-Code from Carbide Create is a move to safe height before running a file.
2 Likes
Excellent! (bookmarked the GRBL wiki)
So I think the only last question… (I’m optimistic! 
) is…
Justin mentioned, “I just had a goto UDE at the end of a tools last tool path to bring it front and center for tool change.”
I’ve created a GOHOME UDE in NX, But I need to tell the post what to output when it sees it.
Where is G53 X0 Y0 Z0? Or, what G53 position should I output to get the head to a reasonable toolchange position (front/center - front/right). I assume this is hard-coded in the machine controller, so can be hard-coded in the post as well.
1 Like
G53 X0 Y0 Z0 would be top back right where the homing switches are.
Usually it’s just a G53 Z-5mm which is used in a file.
Tool change position is relative to the machine size, so better to leave it to Carbide Motion.
M30 is the usual end of file code — current implementation in Carbide Motion is to lift and move straight back and stop.
1 Like
I personally think front center is best, room to the right and left to change the tool. I don’t like being stuck against the wall trying to handle the collet and turn the collet wrench. Plus with your bit setter at the front right, you don’t want any chance of damaging that when changing a tool.
I like how CM has the ability to choose hot spots, including front center, and its understandable that your machine settings have to be correct. Front center on a standard size machine is a lot smaller of a value than on a xxl machine.
What code is CM front center button telling the machine to do?
For no bit setter, the default finish position CM gives (back center) would be default end of program I think. With the option to force the final position to change from that to front center for a tool change.
With a bit setter, when the program has more than (1) tool, have to ask it to go front center between tools but M00 so you can change the tool and continue running the program.
Thats just my $.02 , I am by no means the post processor expert here haha.
@WillAdams We’ve been working behind the scenes to sort out a post for NX. I have come up with some general g-code questions and how CM interprets them.
1: When running a CC program in CM, I’m pretty sure I get 2 splash screens near the beginning. One to load the right tool, and one to turn on the spindle/set the rpm. What codes exactly are triggering those messages?
2: In the grbl wiki it says that we can use a M01 optional stop. How do I enable optional stop in CM?
Thanks for your continued support Will, its really appreciated!
-
that should be the M6 T### command — please note that Grbl is limited to 1 byte for that tool #, so Carbide Motion translates any tool numbers which are out of range on the fly — which means that one is limited to 255 different tools in a given file sent to the machine by Carbide Motion
-
I don’t believe CM would need any configuration for that — either it works (since it’s a command Grbl understands and which CM will react to because it recognizes the state which Grbl is in) or it won’t (because we didn’t anticipate its use).
It is listed at:
https://my.carbide3d.com/faq/grbl-g-code-definitions/
- M1 — Sleep (optional stop)
so it should work.
Most controllers have a switch (whether physical or digital) to turn OPTIONAL stop on or off.
The machine only stops at an M1 when the switch is on. If the switch is off it ignores them & continues.
I’m guessing what you mean is, if it’s ON, it’s just always ON.
I’m still a bit unsure of the differences in the G-code for Justin’s SO3 -vs- my HDM. But we can figure those out once I have my machine. As I mentioned, the G-code posted for either machine looks identical.
So M06 T1 on Justin’s machine won’t do anything? Because he would need to load & zero the tool before executing the program? Or it would trigger the splash screens he mentioned?
Or would the spindle splash screen be triggered by a M3 S10000 block?
The M06 T1 command on my HDM will move to the toolchange position & prompt me to load the tool, then hit start to probe the tool length? Then start again to continue with the program?
What I really need to determine from a post development perspective, is if there are any differences in the posted G-code for either/any of the machines.?
I don’t believe Grbl supports Optional Stop — check w/ the Grbl folks on Github.
The tool change command M06 T### will be interpreted by Carbide Motion and will work as expected on machines which have BitSetters — if Justin has a BitSetter it would be the same as for an HDM.
The BitSetter functionality is the only change, and we don’t bother to take it into consideration in Carbide Create — we just expect folks w/o BitSetters to write out one file for each tool: