Downloaded MillMage Pro 0.8.00-RC-14 @ e747243 Qt6.5.7 yesterday and had problems with Zero Probe not seen on previous versions.
W11 connected to Fox Alien Masuter 3S
First couple of tries drove the v bit into the probe breaking the tip so I did a manual zero.
Ran it again today to test with MillMage and UGS. Probe worked flawlessly on UGS but failed short on MM.
Here are the console logs from both
**ON UGS**
[PRB:-397.005,-397.012,-61.413:1]
ok
ok
>>> G90 G21 G0 Z0.0
>>> G91 G21
ok
ok
>>> G10 L20 P1 Z19.364
>>> G91 G21
ok
ok
*** Connection closed
**On Millmage**
Stream completed in 0:00
<Idle|MPos:-397.005,-397.012,-53.000|Bf:15,127|FS:0,0>
ok
<Idle|MPos:-397.005,-397.012,-53.000|Bf:15,127|FS:0,0>
ok
Starting stream
[PRB:-397.005,-397.012,-61.443:1]
ALARM:5
Probe fail. Probe did not contact the workpiece within the programmed travel for G38.2 and G38.4.
On or near line 6:
Stream completed in 0:08
<Alarm|MPos:-397.005,-397.012,-59.399|Bf:15,127|FS:0,0>
ok
If it drove the tool into the metal surface of the probe block, then there is a fault in the detection of the contact closure.
-61.443 + (-59.338) = 2.105mm
This looks like you are trying to detect the probe block within 2mm of travel. Is that what it looks like when you run it? I do not use the Probe method, so I am not familiar with how MillMage does it.
I use an old-school method (machinist showed me) of setting the surface zero.
Thanks for trying
I am suggesting that this is a software issue introduced in RC14, as it worked fine in previous releases and the probe woks fine still with UGS.
I thought I could report it here but I see there is an email.
Hi @MikeyH
I can now demonstrate that this issue has been introduced since RC11.
I have sent videos to support of it failing in RC14 but working as expected in RC11 as it is with UGS.
Happy to share link to videos if you are interested
Thank you for this. We appreciate you taking the time to report issues you encounter. Really helps us to reproduce here, which is the first step in fixing.
Not necessary, I fully believed what you were saying. If Lightburn can reproduce it, they can fix it. If not, then everyone will try to figure out why yours is different.
Your console log is missing some information. When you are looking at the console make sure to click the “show all” button at the bottom.
that ALARM 5 is a Grbl error and it comes up when the probe does not close at the expected time. Either never closes because the probe does not connect, or sometimes it can happen because the probe contacts before the start of the actual probe cycle.
GRBL will only register the probe if it connects during the G38.2 command. If it connects in the move prior to calling the G38.2 probe sequence it will cause an error and potentially a crash.
Did it connect during the slower probe search move or during the initial move to the probe start position?
Thank you @JoeSpanier
I have just re-run the tests on RC-11 (working) and RC-14 (failing) with fast probe at only 100 and precise probe at 10. They were both 600 and 60 the default values and now the same as my UGS set up.
Same result, but I notice that on RC-14 the probe does first touch and then withdraws but then holds without attempting the precise probe. About 30 seconds later it times out.
Whilst I appreciate that this is a firmware feature of the CNC, the MM must send the parameters of the probe function to the CNC. It appears to me now that there is some change in the sending of the precision parameters in RC-14.
I hope that is evident from the screenshots sent to support
Thank you all for your help!
We now have the solution on RC-14 the following probe settings:
Backoff Distance > Precise Probe Distance
Hence it would back off and then never get to touch again so hitting the timeout.
Software support are going to see if there is a use case for such a setting and either prevent or put up a warning.
The odd thing is that I loaded and reloaded RC-11 and RC-14 several times in the testing and those settings persisted for RC-14 but for RC-11 they were
