Does grbl support probing and auto bed leveling? I have done a couple Google searches and all I find are scripts that send g code to the controller. This makes me think it is not built into the firmware.
Just looking for someone to confirm,
-Atom
It is not built in, AFAIK. Estlcam and bcnc both support that through closed loop gcode. Basically they move and probe and then adjust the gcode before sending it to grbl.
You can really do complex meshes that way.
1 Like
I assume that means that estlcam is looking for a switch activation from machine? Do you think it could be made to use an analog input rather then a binary?
The ChiliPeppr GRBL (and TinyG) workspaces have an autolevel widget.
There is also an autolevel extension available for CNCjs.
I have not tried either myself (yet).
1 Like
No, not really. I am failing to guess why you would do that unless you were doing THC for a plasma cutter. The functions I’ve seen are not closed loop real time. They are for measuring the surface and then no new measurements during cutting.
Because I would like to, at some point use a laser triangulation sensor for surface probing. It reports actual distance with an analog output and could create a point cloud of a surface significantly faster then a touch probe. And with much more detail. So I’m not looking for measurements while cutting, just the input of an actual distance (0-5v represents 0-5cm for example) so that the machine does not need to touch every point to measure it. And receive points several times a second rather then one or two a minute.
Just as an example they are used in pick and place machines to ensure components where properly placed on the leads.
Well. Maybe. The gcode sent from the software says, move to XY, then probe and grbl returns the distance back. So in theory you could rewrite the probe firmware to just immediately return the distance when asked to probe, instead of moving the Z down to measure the distance.
1 Like
That would work then just pass the analog value and integrate it for the z axis depth. 
I don’t know what sensor you are planning on. But something like the sonic range sensors (which are not accurate enough for this) would require the firmware to do something like this:
- wait until the movement queue was empty. Maybe pause for a fraction of a second to stop any extra ringing.
- enable the sensor/start a ping.
- read the analog value from the pin. Maybe repeat a few times to reduce the noise. This would all happen in a fraction of a second.
- turn off the sensor (may be a no-op).
- subtract an offset and multiply the result by a constant to convert from analog read values to a distance in mm.
- print the distance to the console in a string.
There isn’t any integration that I am aware of. This would be for determining the distance from the probe to the surface at one exact X,Y location. The advantage of this over a Z touch probe is just that this would take 200ms and a probe could take 10s, which would add up if you are probing a few thousand places. You could either get a much faster total probe sequence, or the same total time (a minute or two) and a much finer mesh.
This same type of probing is probably possible in Marlin too. It would be a heavy change of code deep down in the probing code. But the result would be a mesh that it would use like any other probe output. The gcode sender in that case would just command G29 and then regular G1 commands without any Z adjustments.
It is certainly an interesting integration.
hmm, i cant find the exact one i was looking at before, but it is somthing like this: https://www.walkerindustrial.com/LE550I-Laser-Displacement-Sensor-p/le550i.htm?gsn&gclid=CjwKCAiAxp-ABhALEiwAXm6IyaLD26H-Qh14b2fJ9ZHxXFchGsm2HBke6zLRE2Y3ivqufswnXvw1dRoC04YQAvD_BwE
the one i was looking at before (apparently i should have bookmarked it) was capable of reading with a .1mm accuracy and had a sample rate of like 60hz. it was designed specifically for measuring the tolerances of products on a moving assembly line (specifically pcb manufacturing). because of that i was thinking of only stopping the read when changing direction.
and your right about the application, the idea is to create a vary detailed mesh of a 2.5D object. my thought is to scan in 2.5D surfaces to be laser engraved on. letting the diode move up and down across with the surface so that high detailed engravings would be possible.
i came up with the idea for a marlin machine, but now i’m thinking of using a GRBL machine instead and wanted to see if the idea would still work. thus the question 
Any progress on this? This sounds intriguing to me.
Thinking a laser gimbal or array may be pricey, perhaps one vertical laser could speed up probing as well for less cost. I am thinking like those Bosch lasers I use to estimate jobs at work. They get 1/32" accuracy at long range, but I figure that is just tuned to the application and they could send more precise data. I am sure there is a cheap chinese kit for that somewhere that could be used. Not having to move Z would be huge for an MPCNC; you could do a lot more points in less time just cruising on a zigzag XY path.
The hard part for me would be getting the sender (in my case bCNC) to take a value from the laser, vs from a probe report by GRBL. bCNC is python, which I’m not familiar with. The whole deal could (and probably should) be done in the sender OS vs the controller. This would be more flexible and inline with how GRBL is setup at the moment. I envision using a rpi hardware uart/spi/whatever to talk to the laser, and a python script that writes to a surface leveling data file which bCNC can use. Of course, being vertical the script may also need to have XY offset data just like a typical Marlin z probe does.
No progress still just conceptual. The only lasers I could find with the accuracy and speed required are over $75 and it’s not a huge priority for me. As far as a single laser, I haven’t seen any single lasers with fast reputable accuracy at the proper distance. Most use laser triangulation (two lasers in a single box that shoot at slightly different angles to get accurate repeatable results). My original hope was to I tigrate it directly into the marlin bed leveling system. That said I think an com interface to read x,y,probe and send it back to a computer would work just as well. For my mpcnc it runs grbl on an esp32, so there is no rpi or anything else connected (no need as the board is already wifi/Bluetooth compatible and has a built in web server) but it could still easily report the x,y,&probe back to a computer.