GRBL probe question

Discussion about the arduino based g-code interpreter, grbl
matthew798
Posts: 1
Joined: Sun Jun 08, 2014 4:47 am

GRBL probe question

Post by matthew798 » Sun Jun 08, 2014 2:43 pm

Hey fellas,

Very simple.

Does GRBL support probing say, a PCB, to map out it's surface? I can't find any definitive answers anywhere. Nothing in the changelogs of 0.9 seem to indicate that it does but some websites say that it was supposed to be supported as of 0.9.

If it does:

Does it automatically adjust a job on the fly? Or do you need to plug it into your cam software and generate the g-code with the surface results?

Thanks!

Xaracen
Posts: 125
Joined: Sat Apr 20, 2013 7:41 am

Re: GRBL probe question

Post by Xaracen » Fri Jul 04, 2014 7:30 pm

Hello, Matthew,
to answer your question, I can offer a qualified Yes, or a qualified No. Let me explain.

If you have LinuxCNC or Mach3 running your Shapeoko then a utility called AutoLeveller will indeed map your PCB surface for you.

You basically point AL to the gcode file you intend to run to mill/engrave your PCB, tell it which controller you are using (because the gcodes and variables system differ), and it will then add a block of gcode at the beginning of the file scaled to the area of the PCB and also modifies the body of the gcode file. You then run the file on your CNC mill. The initial block of added code probes the surface at a number of points across the PCB, storing the Z values of each point at which the probe triggers into a set of user variables, one for each point. At this stage the gcode pauses to let you detach your probe and start up the spindle, then runs the rest of the gcode.

The second block of code is your gcode which is modified to read the variables created and filled by the first block, and performs bilinear interpolations based on the stored info to adjust the Z parameters of all of the milling moves. AutoLeveller is thus dependent on your milling controller having the capability of user accessible variables before it can do its job, because it is mapping and calculating the amendments in real time as your PCB is being milled.

Unfortunately, no version of GRBL has this capability. But that does not mean a probe function has no value here.

Last week I downloaded GRBL 0.9e into a spare Arduino to trial its probe functionality for myself. Be aware this is a Dev version so is likely full of bugs, and is not recommended for any production use.

I was curious to see if I could use it to improve my slate engraving by using the probe to test for the surface on slate with uneven surfaces. I have been playing with this all week, and it does indeed have some potential to be useful.

I use F-Engrave for engraving, and I can edit the gcode it generates by adding codes to move the probe to the centre of a character then issuing the gcode G38.2 Z-0.25 F2.5 to probe down to the surface, setting the Work Co-ordinate Z value to zero then letting F-Engrave carry on with the engraving as normal, and repeating this process for the next character. Thus each character gets its own calibrated Z0 just before it gets engraved.
Essentially I am modelling a non-level, non-flat slate surface as a set of adjacent small flat and level rectangles all at potentially different heights from each other, one for each character or other shape. Not as good or sophisticated as AutoLeveller, but it still an improvement over no probe at all.

In theory!

My first attempt to run an actual engraving operation with such modified code worked fine for the first character, but the second one went astray, and engraved itself about half an inch above the slate. It later turned out that the second instance of the probe gcode (G38.2 Z-0.25 F2.5) was deemed invalid, even though it was identical to that used for the first character, so it didn't drop the probe down at all but the following line still zeroed the Z value of the WCS. Dev software, pfffuh! :-D I'll be having another go at it tomorrow!

So, it is not automatic, you have to modify the gcode to use it, and I think that its usefulness is almost certainly limited by GRBL's lack of any user-accessible variables, though that might be a little unfair, as I am comparing it with AutoLeveller, and I am no expert. There may well be other strategies available, we just have to think of them.
Shapeoko v1 #????
500mm Y-slides with dual Y-steppers
375mm dual X-axis gantry
150W DC ER11 Sable2015 spindle
conductive probe via spindle shaft/toolbit (can probe while spinning!)
Arduino Uno running grbl v0.9i with grblShield v4.

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: GRBL probe question

Post by cvoinescu » Fri Jul 04, 2014 7:48 pm

A moderately competent programmer could write a script to probe a given area, interacting with GRBL directly to collect the probing results on the host computer (rather than in G-code user variables). GRBL requires a peculiar type of flow control, but a sample Python program that implements it is included in the Git repository. Once the probe data has been collected, it is easy to modify the Z coordinates in the G-code and do the interpolation, again on the host side. Finally, the program could send the modified code to GRBL, or simply write it to a file, to be sent with your favorite G-code sender.

As far as I know, this program does not exist today, but several people reading this could make it so that it existed tomorrow.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

WillAdams
Posts: 8628
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: GRBL probe question

Post by WillAdams » Fri Jul 04, 2014 8:53 pm

I believe that that is what the program Autoleveller does: http://www.autoleveller.co.uk

Two other options might be opt-qt or PCB probing software, all linked from the PCB section of the CAM page: http://www.shapeoko.com/wiki/index.php/CAM#PCB
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: GRBL probe question

Post by cvoinescu » Fri Jul 04, 2014 9:26 pm

WillAdams wrote:I believe that that is what the program Autoleveller does: http://www.autoleveller.co.uk
If you read Xaracen's post, he explains that Autoleveller does not do that. It works by storing probing results in user variables, and by replacing Z coodrinates in the original G-code with expressions involving these variables. GRBL does not support variables and expressions (by firmly stated policy, not because they haven't got around to doing it yet). Autoleveller works with LinuxCNC and Mach3, because those have the required G-code support.

My point is that essentially the same thing can be done, without terrible difficulty, by a program running on the computer connected to GRBL.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

Xaracen
Posts: 125
Joined: Sat Apr 20, 2013 7:41 am

Re: GRBL probe question

Post by Xaracen » Fri Jul 04, 2014 9:53 pm

Cvoinescu, I agree a utility can do this on the host computer, as it can read the data reported by the probe in the mapping phase once someone writes it, or perhaps incorporate the feature in a suitable sender program. Do we know anyone who could do this? Someone with experience with writing a sender program in Java, say, and knows GRBL? :-)

Meantime I'll have to have a look at CNCProbe.jar, too.
Shapeoko v1 #????
500mm Y-slides with dual Y-steppers
375mm dual X-axis gantry
150W DC ER11 Sable2015 spindle
conductive probe via spindle shaft/toolbit (can probe while spinning!)
Arduino Uno running grbl v0.9i with grblShield v4.

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: GRBL probe question

Post by cvoinescu » Fri Jul 04, 2014 11:30 pm

I'm not going to learn Java for this. :P I could do it in Python -- it doesn't need to be fancy: I'm comfortable running the Z probing from the command line -- but I really, really don't have the time. But as I said, there are several people here who could do it.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

Xaracen
Posts: 125
Joined: Sat Apr 20, 2013 7:41 am

Re: GRBL probe question

Post by Xaracen » Tue Jul 08, 2014 10:14 am

I have been carrying on with my original cunning plan but the engraving is bedevilled with apparently spurious problems and errors, except that they tend to be repeatable, so they aren't spurious.

I am engraving the text "Katie" (daughter wants a slate place card, stat!). I have turned my spindle into a touch probe by connecting the spindle shaft to the probe pin on the Arduino via a double ball bearing mechanism that allows the shaft to spin while maintaining a good electrical connection. The ground connection on the slate is by a spring clip and the slate surface is brushed with a solution of handwash soap and water, ensuring the clip is well drenched. Again I am getting good connections in tests with the probe as the v-bit drops slowly onto the wet surface. Certainly good enough to start actual engraving tests.

First attempt at the weekend with F-Engrave gcode output edited by hand to add a probe preamble to the beginning of every character, which moves the v-bit over the character's bounding box centre at safe height 0.100 (inches mode), and issue the probe command G38.2 Z-0.125 F2.5, followed by G92 Z0 if probe triggers, or error stop if not triggered. If triggered OK, Z is set to zero and the F-Engrave gcode starts engraving the character, before lifting to safe height and G0s to next character. The preamble is the same for each character except for the co-ordinates of the bounding box centre.

The K engraving goes well, the probe triggers on touching the wet surface of the slate, Z is set to zero and the character is nicely engraved. The v-bit lifts to safe height and moves to the centre of the next character, and the probe preamble runs, but this time it drops only a fraction of the distance it needs to touch water, and it triggers without actually making contact! Z is again set to zero and the character is engraved about 2mm above the slate. I stopped the run, and re-ran the file with the K code removed as it was already cleanly engraved.

Starting the run with "a", but otherwise the same file. This time "a" engraves well, as the "K" did on the previous run. The gcode moves onto character "t" and this time the probe command is rejected by grbl with an error: Invalid gcode ID:36 which doesn't itself halt the program, so it carries on with G92 Z0 with the v-bit still at safe height, and "t" is duly engraved at that height.

I gave up at this point, and rechecked all my code, finding nothing to explain what was happening, so I started fresh with another part of the slate this morning and got almost exactly the same results. I can engrave one, or at best two characters before something goes wrong, with no damage to the slate, so I can always resume with a modified file, but I don't seem to be getting reliable, consistent behaviour from grbl, or possibly the probe. The false positive trigger can only be due to noise in the signal cable, so I will replace the existing twisted pair from the spindle with a screened version and see if that helps. I already re-routed my USB cable away from the stepper cables, although I have never had any issues with it before, and for the second series I rerouted the probe cabling as well, to no real effect. The nature of the probe connection to the top of my spindle shaft may be iffy, but is far more likely to result in false negatives, ie no connection even if the tip is drowning in water/soap solution.

I am wondering if this Dev version of grbl (0.9e) is too unfinished to even test properly, at least as far as the probe function is concerned. I'll re-run the gcode from F-Engrave without any G38.2 stuff in it and see how it goes.

Anyone have any thoughts on this?
Shapeoko v1 #????
500mm Y-slides with dual Y-steppers
375mm dual X-axis gantry
150W DC ER11 Sable2015 spindle
conductive probe via spindle shaft/toolbit (can probe while spinning!)
Arduino Uno running grbl v0.9i with grblShield v4.

Xaracen
Posts: 125
Joined: Sat Apr 20, 2013 7:41 am

Re: GRBL probe question

Post by Xaracen » Tue Jul 08, 2014 5:57 pm

Re-ran the engraving of "Katie" without any probe codes this time, still using the 0.9e grbl, and just a single visual touch of the v-bit onto the surface at the centre of the card. That ran perfectly well, no hiccups, no error: invalid gcode ID:36. The engraving was pretty good, but the depth of cuts were varying across the card due to a slight slope. I had also disconnected the probe, so I will reconnect it without using it, and run the next card "Robbie" the same way, without any probe code in it, and see how that turns out.

I did discover that the probe input was indeed getting a lot of electrical noise, especially when the spindle was turned on, but a small tantalum bead capacitor 6.8µF 16v between ground and the A5 pin seems to have eliminated the noise completely, certainly couldn't see it on the scope any more, and it was extremely obvious before. However, a test run still behaved no better, so I'm thinking the issue must be in grbl itself. Actually, while I've got the scope out, I think I'll scope out the voltage levels on the Arduino, too.
Shapeoko v1 #????
500mm Y-slides with dual Y-steppers
375mm dual X-axis gantry
150W DC ER11 Sable2015 spindle
conductive probe via spindle shaft/toolbit (can probe while spinning!)
Arduino Uno running grbl v0.9i with grblShield v4.

veng1
Posts: 250
Joined: Fri Nov 30, 2012 12:09 pm

Re: GRBL probe question

Post by veng1 » Wed Jul 09, 2014 8:25 pm

I wouldn't put to much stock in this answer but I thought that Autoleveler merged the probe file and the original g-code file into a new one with modified z height.

If I did it myself, that's what I'd do, but I'm way too lazy.

Post Reply