No one seen this before? @GrblGru any suggestions how to debug this?
Sorry for the late reaction, I am just back from vacation.
The error message is issued by GRBL when an illogical condition is detected at the measurement input.
There are 2 possible causes:
-
the parameter $6 does not match the switching behavior of the probe.
Check if your probe is a normally open contact or a normally closed contact and set the corresponding value of $6.
I recommend to connect the measuring input with a piece of copper wire.
As measuring object you just take a piece of metal and connect it to 0 Volt.
In this case $6 must be 0 -
due to e.g. long unshielded wires there are interfering signals at the measuring input.
As a remedy I recommend to connect a capacitor to the measuring input.
You will find many examples on the WWW how to do this. The problem occurs very often also with the limit switches.
Much success
Thanks @GrblGru for your input! I connected a small push button to the probe input on my board and tested both configurations ($6= 1 and 0) by either pushing or releasing the button when GRBL starts looking for the probe input. Cable was very short, 15 cm.
Both results are the same: “An error occured during measurement” after approx 30 sec.
My original probe is a 3D probe where I make a NC switch behaviour with a transistor and $6=1, so everything should be fine. As stated above, a simple push button does not work either.
I notice that GRBL during those 30 seconds before the error message appears, is sending the machine position repeatedly. My guess was that GrblGru expects world coordinates instead of machine coordinates or vice versa, but having tried both it did not help.
Any more suggestions?
Update: I added a capacitor but no change in behaviour. GRBL board is sending “WPOS” coordinates repeatedly after the probe input is detected correctly but after 30 seconds the error message appears again.
Funny side effect: I have to reset the board afterwards, otherwise jogging any axis will not stop (it just does not stop jogging even after releasing the jog button)
I am currently revising my program and therefore working on an ‘alpha’ version. Please download this version from my website at https://www.grblgru.com/Alpha
I have just tried probing with it again to be sure it works.
Attached are some screenshots of how it works for me.
Yes, I have tried the 6.0 before as well. Sadly, I have the same issue as in the released version.
Attached are two screenshots - this one shows the error message after 30 seconds (note that the probe input is detected correctly by GRBL v1.1f). It is important to note that there is no “ALARM 4” which would indicate a probe failure on GRBL level. This seems to be purely in GrblGru (the sender program):
This is the failure I get when I reset the controller. I have to do that as mentioned before, to prevent jogging going on endlessly. It seems GrblGru believes to be still “in motion” despite the machine has stopped when detecting the probe input:
Are you sure you have loaded the latest alpha v14 ?
I had made some changes yesterday. Please check the version number in the title bar.
Yes. Check my screenshot, its v14. I downloaded it again this morning before I tested again
Puuh, slowly I have no more ideas.
I have here once again a Uno with Grbl V1.1f on my desk.
There is only one normally open contact connected between GND and A5.
I start the measurement “Touch Left side” with the parameters from your screenshot and press the button after 2 seconds. Maybe you can try this once.
I made you a video of it. https://www.grblgru.com/VideoGallery
See the last video: Test scanning with Grbl
Please compare your settings with mine.
During the installation of GrblGru always 2 Hex Files are copied to the disk. Please flash your Uno with grbl_v1.1f.20170131.hex to make sure that it is not a problem with the Grbl version.
@GrblGru what are the corresponding lines of G code in your sequence?
I can punch them manually in the command line one after one and examine the result.
You can see it in the video at the bottom left of the window. It is actually just one simple command.
At the start it sends:
G91 G38.2 X10.0 F100
When GRBL detects a signal at the measurement input it sends "PRB: …
Thereupon I set this position to 0:
G10 L20 P1 X0
and move the axis back by the “Pull back” value.
G1 G90 F300 X-5.0
Please take a screenshot of the left controller window when the error occurs.
Thanks @GrblGru - This was my guess.
Now, screenshot 1 shows the result when I enter the G-code sequence manually in the command line. Everything works just fine:
The second screenshot shows the result from the probe dialogue, which supposedly should do the same thing. But, here it stops after the first line with the G38.2 command. Please note that I also found no difference in behavior if “Real 3D Touch Probe” is TRUE or FALSE. Same command (G38.2) and same fault. My settings are $6=1 and $10=0
Here is the corresponding feedback from GRBL1.1f at the top of the right window - you can see the PRB feedback is correct (Ignore that the position values differ from the screenshot because this is taken from another attempt):
<Run|WPos:-0.375,0.000,0.000,0.000|FS:100,0|Pn:A|WCO:1.431,0.000,0.000,0.000>
<Run|WPos:0.534,0.000,0.000,0.000|FS:100,0|Pn:A|Ov:100,100,100>
<Run|WPos:1.463,0.000,0.000,0.000|FS:100,0|Pn:A>
<Run|WPos:2.328,0.000,0.000,0.000|FS:100,0|Pn:A>
[PRB:4.297,0.000,0.000,0.000:1]
ok
<Idle|WPos:2.950,0.000,0.000,0.000|FS:0,0|Pn:PA>
<Idle|WPos:2.950,0.000,0.000,0.000|FS:0,0|Pn:PA>
<Idle|WPos:2.950,0.000,0.000,0.000|FS:0,0|Pn:PA>
I see that you used the V5.1 version for the tests. Please use the alpha V14 version. There are important changes in it.
To test correctly you must only send the command “G91 G38.2 X10.0 F100”.
Then you have to wait a while and connect input A5 with GND for a short time.
If you do it like this, will you get the error message or not ?
The input ‘Real 3D Touch Probe’ is only necessary for the evaluation of the measurement result (ball diameter etc.).
Here you go. 6.0 v14
Screenshot 1: Sendt manually until probe is triggered. No fault, even I waited for a long time.
Screenshot 2: Probe dialoge. Probe is triggered, after 30sec the error message pops up.
Both are using the exact same command, but the error only comes when using the probe dialogue. There is no error code coming from GRBL1.1f, it seems GrblGru is waiting for something and aborts the sequence after some time.
Thanks for the information. 
Each time the signal “PRB” is received, the measured value is written into the memory.
The memory is cleared beforehand when the Start button is pressed.
After that, the controller waits until it does not send any more data (right controller window).
During the waiting time, a beep sound is emitted after every second. After that the evaluation takes place.
First it is checked whether EXACTLY ONE measured value is in the memory. If this is not the case, the error message is displayed and the measurement is aborted.
I have just created a new version Alpha V15, in which the error message appears in the function “Touch Top”, but the measurement is not aborted if at least one measured value is present. Furthermore the number of received measured values are displayed.
I am very curious about the result.
Awesome! I am out travelling this week but will test on Saturday and post the result. Thanks so far!
No success here… “Too few measuring points = 0”. See below.
GRBL sends back the correct PRB values when the probe is triggered but for some reason GrblGru does not recognize them
I haven’t noticed it before, but with your GRBL version 4 axis values are returned.
Also when sending PRB result. Because I expect with only 3 values, I interpret the “Succes” message wrong.
Please try again with the new alpha V17.
I would be interested where you got this GRBL version from. Normally GRBL supports only 3 axes.
Alright - thanks for the v17 @GrblGru
The single point probing sequences work now, although it takes 30 seconds before the probe is retracted and zero point is set correctly.
“Align circle” does not seem to do what it should though. The probe returns to the original point where the probing started, but the correct center is not set.
The GRBL1.1f came with the chinese brand hardware, I assumed it is a standard version, but that might be wrong? Not sure I can post a link in this forum but here is a picture:
Thanks for your effort on that fantastic tool so far - hope for a speedy release of a stable v6.0 with 4 axis probing