I would have thought M40 is quite independent.  After a probe move the trip coords are just held in the specified parameter registers and it's up to the following code to read them and store in a file.  But I have never used it so can't confirm.  If you are having Autoleveller problems I suggest you raise them with the originator.

I can confirm it is not an Autoleveller issue, all that software does is write Gcode depending on some other file. The interpretation and execution of the codes are all inside Mach3.

It doesn't matter how slow I go or how many other complementary pieces of code I add, the Work Offsets still get saved in the file after the G31 command insted of the Work Coordinates, seems more like an issue on how the G31 command is coded, but that is something not visible to the user, all the user can see and modify are the M codes.

I began reading about Cypress code, which is the language Mach3 is based on when writting your own macros. I'll end up making my own G31 command, which is ridiculous, but I have no other choice. Rants about it might go later on.

I suggest that you try a very simple single Z probing move at one  XY point, after first opening a data file, then close it, then look to see what is written.  I know that probing itself works, though I haven't tried writing to a file.  Searching on Autoleveller there seem to be several threads on problems with it and solutions.

Writing a G31 command is not going to be easy - what you don't see is that behind the scenes there is a very tight loop to stop the axis moving very quickly when the probe trips.   You would have to use a G1 command to move the probe and find a way to stop the move in response to a hardware input before it completes, or move it in very tiny increments, testing the probe state after each one.  Anything you write in CB will be rather slow anyway.

Right, so I have done a couple of experiments on my mill using the tool height setter and a square-ended rod in the chuck as a probe.  The setter is basically a spring-loaded button at a known height of 38.84mm, which is grounded via the rod on contact.  I used my tool height setting macro initially, then also a straight G31 move.  Both of these verified that G31 operates and writes the XYZ PROGRAM coordinates to a specified file.  In the case of my macro two readings are written, for the fast and slow probe moves, they are very slightly different on Z but of course X and Y are the same.

So I suggest you try the following.

a)   Type M40 into the MDI text box and return - when a file dialogue appears type a suitable filename.txt into the appropriate box and save it somewhere you can find it quickly.
b)   Position the probe just above (say 1mm) the surface to be probed and take a note of the displayed X and Y coords (and Z if you like).  Suppose the Z value is Z0.
c)   Type G31 (Z0 - 2) F5 into the MDI box and press return.  The probe should start moving slowly down until it contacts the surface then stop.
d)   Type M41 into the text box to close the file you just created and wrote to.
e)   Now from Windows navigate to where you saved the file and open it - it should have one line with the X, Y, and Z coords in it corresponding to the values shown on the system DROs.

I had no problems whatever getting this to work and I conclude that probing is working as documented.  It is conceivable that whilst your Ethernet controller does support probing, for some reason it doesn't support the protocol to write the values into the file.  Probing motion is a function of the controller since very tight coupling is needed between the motion control and sensing the probe trigger, how the coord values get written to the file is a Mach3 function.  I have a Win10 Dell mini Inspiron PC with USB connection to a UC100 motion controller.

The other thing to try is to make sure that the G31 is correctly populating the #2********* variables, this might need you to write a simple macro.

Sorry to say, but, none of the suggestions above worked. 

I gave up on tweking the G31 command with other macros, I have spent too much time trying to figure out what's under the good to make it work.

Instead of reverse engineering or trying to patch the command, I just began writing my own probing macro from scratch, and so far, it has given me waaaaaaaay better results, with a few caveats that I wish could be solved as nicely as what I have done so far.

To summarize what I did with the G31 in the end, was just to use it as code to stop the machine from moving when the probe tripped. Unfortunately, after repeated tests, I found out that no matter how slow I did de probing, the machine would go about 0.3mm lower from the contact point. From what I tested, it seems that it has to do with how the G31 command is coded, it is either too slow or doesn't properly tell the machine to stop right when the Digitize LED is ON. It just keeps going lower after the probe has tripped.

Right now, I created a macro to issue a Stop command (1003) when the Digitize LED goes ON, and it works amazingly well. The problem now with this stop command is that, I have to manually press Start Cycle in order to get the file running again, and by pressing Start Cycle for some reason it goes one line before it stopped, which is causing a double reading on my file, which is surprisingly quite accurate, but not what it's intended.

So my question now is, is there a Gcode to stop movement without stopping file execution?

I tried, G1 F0, but it is not allowed, Pause Feed Hold (1001), and JogOff(Zaxis), but since it is not actually JOGGING it didn't do anything, I just did it to try it out.

Hi,

To summarize what I did with the G31 in the end, was just to use it as code to stop the machine from moving when the probe tripped. Unfortunately, after repeated tests, I found out that no matter how slow I did de probing, the machine would go about 0.3mm lower from the contact point. From what I tested, it seems that it has to do with how the G31 command is coded, it is either too slow or doesn't properly tell the machine to stop right when the Digitize LED is ON. It just keeps going lower after the probe has tripped.

When the probe is tripped the machine decelerates to a stop, so yes there is overtravel, but 0.3mm? No way, even my old stepper driven mill which had acceleration of 375mm/s^s stopped with 4um after probe trip when decelerating
from 100mm/min. My new mill has acceleration of 1500mm/s², ie 0.15g , and that's detuned from its rated 0.27g rated deceleration, so the over run is 1-2um. If you have overtravel of 0.3mm your machine has too
low acceleration to probe, fullstop.

Craig

"So my question now is, is there a Gcode to stop movement without stopping file execution?"

Probably not.  The only way to do what you want is to use a macro to move in very small steps, testing a hardware input at each point.  Veeeryyyy slow.  As Craig says, it seems amazing that you're the first person to have discovered this, like him I suspect the machine setup.

No way, even my old stepper driven mill which had acceleration of 375mm/s^s stopped with 4um after probe trip when decelerating
from 100mm/min. My new mill has acceleration of 1500mm/s², ie 0.15g , and that's detuned from its rated 0.27g rated deceleration, so the over run is 1-2um. If you have overtravel of 0.3mm your machine has too
low acceleration to probe, fullstop.

Thanks for the reply and the insight on that matter. Well, I actually overhauled my CNC mill a few months ago with closed loop stepper motors (Nema 23, 3.0Nm, 4.0A)  enough and their respective stepper drivers because the steppers it had before weren't bulky. I also added a WiXHC MK6 Ethernet controller, all because the cheap chinese CNC USB motion controller I had before had me replacing broken tips because of noise in the data lines.

I also just checked my acceleration settings for each motor, and they are all at 400mm/s2, which should in theory give me the same results. If not, what acceleration settings would be recommended for the sake of testing?

The only way to do what you want is to use a macro to move in very small steps, testing a hardware input at each point.  Veeeryyyy slow.  As Craig says, it seems amazing that you're the first person to have discovered this, like him I suspect the machine setup.

I already player with macros and going very slow, but I still get significant overtravel, not to mention once again that the G31 command within the G40 which opens a file just gives me some other data instead of the one being probed like I mentioned at the beginning of the thread. If I am the only one experiencing this, then I am just too unlucky.

 

I suspect that your motion controller doesn't properly support probing.