Terry,
I believe that you are mistaken when stating that a G31 that does not trigger the probe is an error condition. I have no such dependency listed in any fanuc gcode language reference I have; but I won't calaim to have all such relevant publications created since the start of time....
Since I understand that the M4 gcode interpreter has been reworked to be "more fanuc compatible", I would appreciate any pointer you have to a fanuc reference supporting your assertion re this "error condition".
Consider this common scenario: You want to know if the path from you current position to a known position crosses a part or not. This is common, for example, when finding the outline of a 2D part via probing. Common algorithms do a probe a known distance fro the current position in X or Y while looking for the part edge. It is not an error to complete a G31 and end up at the G31 commanded position. In fact, this is exactly what the move was meant to "learn" - that the G31 movement was "clear".
I suspect you are mixing two different concepts: 1) An error condition or not when a G31 movement is completed and 2) what to write into a file as a result of a G31 movement. Those are two independent topics.
#1 concerns the definition of the gcode sate machine at the end of a G31 movement. A skip command that did not skip any movement is not an error state - - it is one of two possible normal, non-error states that a G31 may end with. There are (at least) two common ways to determine at the end of a G31 movement if the probe was triggered: a) compare the current position with the commanded position and b) ask the control for the state of the probe input.
I'd note that support of b) is included in Mach 3. Brian's comment that he thinks he added such a register to indicate this in M4 also implies that M4 was intended to have the same support. When the G31 movement is complete, you inspect the state of the probe signal to learn whether the movement resulted in a trigger event or not (this is why M3 has to keep the probe positioned with a bit of overrun - so that the probe input state will be correct after the probe movement is done - i.e. at the time an application script checks the G31 ending state).
#2 (logging of G31 end coordinates) is an additional layer added on top of the basic G31 gcode movement. M3 has such a facility and apparently M4 has something similar. However, a desire to write (or not write) a value to a file upon normal (i.e. not error) completion of a G31 is an independent topic. You may or may not want the end point of a given G31 move in the file- it all depends on what you are using the data file for. Just as you gave an example of a situation where you would not want the ending coordinate written to the file, there are different applications where one would want various combinations of: trigger points, non-trigger points, or both written to a data file.
Please try to logically separate the behavior you may desire at an file write application level from the "error or not" ending state of a G31 movement.
FYI, yes, there are other (non-fanuc) gcode variants where the language is structured such that the gcode program uses different probe commands to handle the combinations of Triggered / not triggered and which is to be considered the "normal / desired" end state. One example I am aware of are the LinuxCNC extensions to RS274 - but I consider that not germaine to the discussion as those are not Fanuc compatible gcode interpreters.
Dave