Hi.
Since there is no “Carbide Connect” yet, nor a version of “Carbide Motion”, for RaspBerry Pi; I am trying to use my RBP with UGS as a controller for my Nomad.
Has anyone been able to apply (successfully) Universal G-Code Sender, to use the Tool length Probe in the Nomad?
How do you do it?
I would appreciate explanatory comments (newbie guy) 
You should be able to get an idea of the commands used by opening up the Log, doing a tool length probe, then examining the contents of the log.
This long and somewhat meandering thread might help point you in the right direction:
I curled up with a nice cup of coffee and that thread, and my only take-home was that it quickly got away from discussing the Nomad tool probe specifically and never really came back. I really do feel like this is possible using the TLO support in grbl 1.1, but there weren’t many definitive answers to be had.
It’s been on my list to move to grbl 1.1 for a long while, so I suppose I’ll do that this weekend and then do some data collection to determine exactly what Carbide Motion is doing during a probing cycle. Maybe then I can parlay that into a CNCjs probing macro.
Hi Sean;
The other day, I was try to “parse” the information of the log (As Will recommended), I share you the file in case you find it useful. I have not advanced further on this at the moment, because I still do not fully understand the code G.
I was remove the Idles, to eliminate “noise”.
And I was could recognize that at some point it makes a change from absolute references to incremental references…
On the other hand also Install CNCjs in the raspberryPi; really is superior to UGS (As a web service, hosted on the RBP), but unfortunately it is very heavy for the RBP (3 B+) to support its GUI itself on an browser. As what I plan is to build a standalone controller, with screen, i return to UGS. On this I planned to apply a Macro (G-Code) for the Tool length probe cycle. Anyway, an G-Code will be useful to test.
I wish you success with the upgrade 
Nomad Measure Tool (log).zip (22.4 KB)
@patofoto and I took a lot of the Nomad specific conversation to a PM so as not to flood the thread with our back and forth. I do not have a Nomad, but, if I remember correctly, we had a macro that was working with the Nomad. Maybe he can chime in as the Nomad owner.
please chime, please please @patofoto
i’m looking forward to doing this soon, but it’s in my queue
Hello everyone and sorry for the late response. I have been involved in shooting a documentary and have been traveling for the past month. I have been away from my Nomad for quite some time because of work and miss milling projects for fun.
@neilferreri and I hit a wall with the Nomad and macros with CNCjs. There is code in Carbide Motion that accounts for the offset with the tool probe in the Nomad. I was able to send CNCjs to the probe location and measure but the measurement was not correct. I will try to find the macros that @neilferreri shared with me. It was a long time ago. I moved to probing with the Carbide3D Touch Probe.
This is the macro @neilferreri and I were testing.
TLO_Macro_Nomad.nc (2.7 KB)
Thanks, @patofoto! That’s a great starting point.
I upgraded my Nomad to grbl 1.1f over the weekend and had a play around with CNCjs. I ran some jobs that didn’t require tool changes, which worked out really well – I’m very impressed with the software and feel like it’s a step in the right direction for me.
Tonight, I gave your TLO macro some testing and you’re right – it almost works, and I think I have a plan for bringing it up to 100%.
After tweaking your macro for the 883 Pro’s tool probe location, I pulled out some gnarly old 1-2-3 blocks and zeroed Z on one of them. Then I just ran the tool change macro over and over (without actually changing the tool in the collet) to see what the numbers looked like. Then I repeated with actual tool changes.
The results were quite interesting. They ended up being quite close – my work zero would almost always be about 0.2mm - 0.05mm above the tip of the tool, regardless of whether I actually changed the tool during the course of running the macro. This tells me that the tool length calculation is correct and the offsets are being applied properly, but there’s some non-repeatability in the actual measurement.
Some digging in grbl’s github issues led me to this: Probing - Wiring Setup.and usage. · Issue #464 · grbl/grbl · GitHub
Specifically, this quote regarding grbl’s G34.2 behavior:
Whatever probe you design should be able to handle some over travel, the Z movement likely won’t stop immediately. Some sort of spring arrangement would do.
I think what’s happening here is that the macro is issuing G34.2, hitting the tool length probe, and then experiencing some small amount of over-travel before finally coming to a stop. The macro is then doing its length calculation based on where the machine stopped as opposed to where the probe switch was triggered, which results in it thinking the tool is shorter than it really is.
Probing twice at different feedrates the way Carbide Motion does, and doing some sort of math on the results may yield a more accurate tool length, or maybe just probing at a much slower feedrate. It’s also possible that just applying some sort of fudge factor proportional to the probing feedrate may eliminate the error. Either way, I think that this problem is solvable.
What great, positive news @koolatron!. Please let me know how I can help. I use mostly CM because I like the use of tool change probe and running everything on one job. Don’t absolutely need to do it this way but like the feeling of running things as efficient as possible for my own learning experience. CNCJS, as much as I like it, makes me be attending my machine all the time as I have not gotten used to it and its work flow. My goal, when I started asking @neilferreri for help, was to use it the same way I use CM.
Eager to help where I can. I do not know GCODE unfortunately but hope to assist as much as I can.
I don’t know that I’d bother with the TLO command in that macro. When I wrote it, I was trying to replicate what I saw from the the output from @patofoto’s Nomad and fill in the holes with stuff that’s going on within Carbide Motion.
I would think that using the same tool change probe macro I use for the SO3 would work (modifying the absolute positioning). To take care of that overshoot you could triple probe with a G38.2, a G38.4, and then another G38.2. I don’t have time to mess with that now, but the G38.4 is a “reverse probe”…the Z would move up until it’s NOT on the probe.
whoa, you guys are making solid strides on this !
hyped to see this solved as it would be great to utilize with cncjs
Hey ya’ll, just an update here. I dug a little deeper and found this (working) cncjs macro for tool change using the probe in the Nomad. It creates a very repeatable result.
The only thing that should be updated are the machine coordinates for the tool probe. Also as @neilferreri may appreciate, it updates the work zero with G10 L20 which will persist across soft reset/power cycling (as those offsets are stored in eeprom on the controller).
Hey @koolatron,
Did you try the one I linked to above? It’s the same thing essentially. The guy who posted the one you just shared contacted me about an issue, but I could not replicate it. I just want to make sure the one I’ve shared doesn’t have a bug.
Thanks
Just quickly tested the macro with my Nomad Classic and it seems to work well. I will play with it more this coming week. I would like to change a few things. The first probing for the current tool, can that be skipped?. I already have that position from the current work zero. Can we just move to the tool change position, change the tool and generate offset?. Why the first tool probe for current tool?. Super exciting that this is really looking promising for CNCjs.
At the moment, Carbide Motion does two things that I like a lot when used with my Nomad. One is the automatic tool length probe after a tool change. We are really close to getting this to work in CNCjs.
The other is the way pausing works in CM. When you pause a job in CM, the spindle stops spinning and it retracts. After unpausing the job, it returns to where it left off and continues milling. Is there a way to mimic this in CNCjs?. This is very useful to pause a job temporarily while we attend something else. CNCjs pauses the job by just stopping the X, Y and Z movements but the spindle stays on.
I was able to run it as well yesterday night.
After tweaking some of the locations and realizing I need to stay in G21 (metric programming) it worked well but I saw the same difference in height @koolatron mentioned. I think it would save current modal units (G20), change to G21 for the macro, then change back to previous modal units (G20), but I didn’t seem to have luck.
I reviewed the probe macro he just posted and it basically adds a second probe at a much slower feedrate. This will minimize over travel and should reduce the error in height. Although I do like the sound of the G38.2/G38.4 back and forth @neilferreri mentioned as well.
Tweaked the file @neilferreri originally provided and attached.
Keep in mind I’m a butcher of code and have yet to test it - hopefully tonight.
To increase the accuracy further you can just reduce ‘20’ to a lower number (it will take longer to finish)
%PROBE_SLOW_FEEDRATE = 20
If some soul is brave…
(I would try it without a tool first and depress the probe pin manually to get a sense of the macro)
Attached macro should do the following on the Nomad;
Go to probe pin
PAUSE (M1)
Probe current tool length at normal speed
Triggers pin and move up 1mm
Probe again at slow speed (increasing accuracy)
Retract and move to tool change position (I sent it opposite side of X axis)
PAUSE (M0) - change tool here
Go to probe pin
Probe new tool length at normal speed
Triggers pin and move up 1mm
Probe again at slow speed (increasing accuracy)
PAUSE (M0) - clean work area, tools, etc
Go to previous work position
TLO_Nomad_Metric G21_v2.zip (1.1 KB)
Did you try that one @PaulAlfaro? I went away from the macro shared by @patofoto and use one without the g43 and with a double probe. I’m away from a PC and a machine for a while, but the tool change macro I linked above has a couple of errors I need to fix. I’ll post back here when I get it updated.
I’m hoping to test it this evening when I get home.
It eliminated the last move to tool change position before the work position.
It left the g43, but it includes a second probe.
I believe it should work, but in any case I’m just eager to move this forward and get a functional macro.
Hey @PaulAlfaro, while you’re at it try the one here.
You’ll have to modify the machine locations.