are you using it with Carbide Motion, or another GCode Sender?
Carbide Motion, for now (I have a Sienci Longmill at home and am using cncjs, so either that or gSender). I’m sending custom grbl via the MDI interface, which is how I’m probing now. I need to update to a more recent version of Carbide Motion to try the custom macros; hopefully that will make life a lot easier than copy and paste. Otherwise, the normal probing command works well for xy location setting in holes, which is what I’ll be primarily using this for.
1 Like
@ChrisPro Thanks for sharing your experiences! I’m buying this probe, then. In my case, I need it mostly for edge probing, so we’ll see how well it will work for that.
I just hope we’ll be able to use it with Carbide Motion eventually — a large part of the value proposition of the Nomad is that many things “just work”. I wouldn’t want to switch to different software and lose nice things like tool length probing in the process.
1 Like
I also picked up this probe. Should be here tomorrow.
I hope to help develop a nice suite of macros for gSender on the nomad 3.
That said, I’m super interested in helping out with carbide motion macros as well. Should we start a thread for development of carbide motion macros with this edge finder? Keep all of the conversation in one place and all that?
3 Likes
Over on the F360 section I asked if anyone knew how to get in-process probing working. This probe looks ideal for it but the F360 post processor barfs. The Nomad is such an accurate machine that this would really make its capabilities shine. Bitzero2 is good but can’t help with probing a small registration hole after a flip etc.
Any takers?
That’s one of my ultimate goals.
I’d love to do in-process probing and it would also be really cool to get qc/reporting working as well.
No idea if it’s even possible with grbl 1.1 but if i end up figuring it out, I’ll be sure to share.
(And if anyone gets to it before me, ping me 
)
Just to say it out loud, that’s quite a large chunk of work. I expect even if someone started on it today, it would take a good while to get it sorted out.
I don’t know who authored the Carbide post in F360, Carbide themselves, Autodesk or a contracted 3rd party but the handler for in process wcs measurement is missing. I am not confident enough in JavaScript to fix it up myself.
Right right, pretty sure it’s not supported at the moment. I don’t think I’ve ever read about it being supported.
My guess is someone from the community would have to extend the current implementation. (Which I’m interested in doing myself, eventually)
I certainly can’t speak for carbide but I’d guess there are a very small number of stakeholders interested in putting time into that feature.
And if I remember correctly, much of the in-process probing stuff is behind a fusion paywall which further reduces interest. Though don’t quote me on that 
TLDR: if it does happen, it’ll probably be awhile and it’ll probably be a community driven effort.
Getting in process probing working would also most likely require changes to the gcode sender (cncjs or gSender). I don’t believe that it is currently possible to generate gcode to handle most (all?) Of the probing options.
If you can generate gcode that you could add to the file (and not just in a macro) to do the probing that you want, let me know. I am familiar with the post processor and have a forked version that adds some functionality.
1 Like
With grbl, we’re limited to the G38.x commands for probing. I think anything you want to do would be easier to run from a macro than as a “toolpath”. Can you give me an example of where that wouldn’t be the case, knowing the limitations of grbl? I am not coming from a machinist/cnc programmer background, so my experience with this is limited. I can see the value when your machine/controller has an array of probing tools and routines, but we pretty much just have the straight probe…everything else has to be done with gcode, possibly with some javascript.
If one of you wants to mod a post processor…check out chapter 8:
3 Likes
My slightly noob understanding is that for an in-process probe of a single face the post processor would generate a g0 move to a standoff position then issue a g38 slightly past the expected touch point. Then g92 with the probe radius (for X and Y). I’m assuming Fusion will generate the tool change prior to that.
I can’t see any reason that this basic minimum this addition to the post processor wouldn’t work with CM or grbl. I can see that some of the more advanced in-process probing (such as dynamic tool diameter compensation) would be problematic.
Probing inside a hole might also be tricky too because I guess it needs to use M114 and a different sender which can calculate some averages. I guess it would be nice if there were a gcode which could be sent to trigger CM’s built-in X and Y probe routines which would make things a whole heap easier.
From my relatively small understanding of how the macros in CM work, I would think this probe should be to do everything except Z probing, because it cant use the tool length setter.
Anyone feel free to correct me if I’m wrong.
Well now, sounds like something we can test!
I’ll spin up the thread for the unofficial 3D Touch probe carbide motion macros
Unfortunately, there are definitely things that you can’t do with Carbide Motion. Probing the middle of a large hole is one as the only way to probe a hole in CM is to pretend it is a bitzero. Trying to probe a hole without the bit zero requires that the macro be able to remember the positions of the two sides and have a formula that computes the mid point (for each axis). That’s not something that you can write in gcode.
Similarly, you can’t find the middle of an object / axis because it requires the same thing.
In terms of Z probing, you can handle that in cncjs / gSender. What I do is probe a fixed point (to the left of my bitsetter on my SOPro 4) and use that point to match the tool lenght probing. Since it is probed to a common height, I can then use the touch probe to set Z accurately.
My thought was more along the lines of having 4 different macros (X+, X-, Y+, Y-) for moving in a each of those directions, until it hits stock, then setting the zero. And then one could re-use the existing Bitzero v2 XY probing routine/macro to set the zero on a desired hole center.
I was aware the Carbide Motion macros cant do any sort of math, like moving from either side of a piece of stock and then calculating the midpoint.
The ability to retain the tool length probe & the offset with this probe is cool, it just sucks that you’d have to move away from CM to do it. I guess ill have to spend some time learning CNCjs
FWIW, I really don’t want to stop using CM. One of the main reasons for buying a Nomad is to get a more streamlined workflow, where things are done for me, and I can spend more time on designing and less on tweaking the machine.
I really hope that Carbide3D will make a small gesture and modify CM to accommodate other probes — even very basic support would be fine.
In my case, I really want automated length probing, as my jobs usually have several tool changes. And what I’d need is basic edge probing and inner/outer corner probing. I can do this myself manually using the LED on the probe and a calculator, but it would be nice if I could enter the probe diameter into CM and have CM auto-calculate and store the zero for me.
Hole probing would be nice, but even without it the ability to use this probe would help me quite a bit.
1 Like
from what ive seen of gSender, its really not too bad of a leap in terms of learning curve.
Well, for me it’s not really about the learning curve, but about “just works” — will it “just work” with F360 CAM? Will everything work like with CM, specifically auto tool length probing on tool changes?
Anyway, I do not want to derail the conversation, which is really about supporting the probe.
This is all gcode. Could be a quick action on motion or just entered through the MDI.
Is the idea to automatically correct for errors in the previous operation of the same job?