G38.2+

[tmpvar]

This is mostly a copy of #490's description which I've included at the bottom

It seems like @chamnit is having some reservations about landing this, so I guess it's worth explaining my use case.

I would really like to have a switch on my machine somewhere near 0,0,-z that I can use in combination with G43 (G43 Tool Length Offset) to automatically setup tools (depth for now) after manual tool changes.

My main concern is with G38.2 and that once the switch is pressed it continues moving into the switch during the EXEC_FEED_HOLD/deceleration phase and eventually reports it's resting position. This makes sense, you certainly don't want to blow away the state of the machine doing a hard stop and losing steps. This is probably not as big a concern for machines with fast acceleration settings.

However, to be robust against various machine configurations, backing off of the switch seems like a reasonable next operation to ensure the tool is exactly at the height of the button. This is roughly analogous to how homing is performed currently (i.e. back off, re-engage, etc.)

Given access to either the probe pin state or G38.{4,5} a cycle much like the homing cycle could be created in user land tools (i.e. python/node/java) to help eliminate any variation between tool changes. I've chosen the standard way here as to avoid adding more reporting noise to the output, and with the hope that it is useful for people using other types of probes as well

copied from #490

This is accomplished by adding a sys.probe_away flag that is used to flip the direction of the switch depending on which direction we are probing in.

truth table

            towards (G38.2, G38.3)    away (G38.4, G38.5)
before       sys.probe_away  = 0       sys.probe_away  = 1
             sys.probe_state = 0       sys.probe_state = 1 

after        sys.probe_away  = 0       sys.probe_away  = 1
             sys.probe_state = 1       sys.probe_state = 0 

This assumes that the switch is engaged when "probing away" begins, which appears to be sound given the wording in linuxcnc's description

G38.2 - probe toward workpiece, stop on contact, signal error if failure
G38.3 - probe toward workpiece, stop on contact
G38.4 - probe away from workpiece, stop on loss of contact, signal error if failure
G38.5 - probe away from workpiece, stop on loss of contact

grbl with this patch builds at 27758 bytes vs master at 27654 bytes

[chamnit]

@tmpvar : Thanks for the explanation. I just wanted some clarification why we needed to add more probing tools. The code looks good and small, so there shouldn't be any issue with eating up too much flash storage. There might be a couple of things I may add or change after integrating and reviewing the code later though, like a separate message (or no message for G38.3/.5).

A few things:

• You'll never be able to get away from the deceleration in the probing cycle. So, I'm still having trouble seeing what the usefulness is for the G38.4/.5 g-codes. You have to get the probe engaged first for these g-codes to work and this involves a motion into them and decelerating. I suppose I just want to know a typical use case for these g-codes. For example, do these behave differently, as in not forcing a feed hold when it detects a probe trigger and just moving on to the destination point?
• The G38.2 probe cycle that is currently installed records the position that it first detects the switch trigger and then issues a feed hold to decelerate. It is then followed by a pull-back move that brings it back to the probe trigger position (which isn't quite right, but it made sense to me to do this at the time). This pull-back will probably break the G38.4/.5 commands, since it'll may have reset the switch.
• Lastly, most switches don't have the same trigger and reset points. So, when you do a G38.2 followed by a G38.4, you will likely see that these positions do not correlate.

I'm not totally against adding these. I generally don't want to make things more confusing for new users getting started with CNCing. These probing g-codes are very similar between all of them and are not immediately clear what the differences are and their use cases.

[ashelly]

Shouldn't the sys changes be done down around line 985, after the rest of the error checking on the line is complete?

[tmpvar]

The correct state will be setup prior to running probes in the current location, but I defer to @chamnit w.r.t. where the state change lives in the file

[tmpvar]

I am in no way the authority on how this should work! The only experience I have is with my handful of hobbyist grade homebuilt cncs.

• You'll never be able to get away from the deceleration in the probing cycle. So, I'm still having trouble seeing what the usefulness is for the G38.4/.5 g-codes. You have to get the probe engaged first for these g-codes to work and this involves a motion into them and decelerating.

I agree, and that is fine. My main concern is that tool lengths vary which affects the speed at which the probing cycle can occur. If we can trigger the switch while traveling at a reasonable rate, then we have a basis for performing the probe_away cycle which can be done much slower to eliminate overshoots due to deceleration.

I suppose I just want to know a typical use case for these g-codes. For example, do these behave differently, as in not forcing a feed hold when it detects a probe trigger and just moving on to the destination point?

That is a good question. My naive response is that the behavior should be the same

• The G38.2 probe cycle that is currently installed records the position that it first detects the switch trigger and then issues a feed hold to decelerate. It is then followed by a pull-back move that brings it back to the probe trigger position (which isn't quite right, but it made sense to me to do this at the time). This pull-back will probably break the G38.4/.5 commands, since it'll may have reset the switch.

From my experiences, even after the pull-back the switch is still depressed and the 1/8" bar that's holding it in place is still deflected. The amount of deflection is more at higher probe rates.

I my case (and I'd venture to guess others) if you back off to exactly the switch trigger point, the switch should still be triggered (even if the switch has the exact same on and off location).

I do see your point though, and am curious why the bar is still deflected after the pull-back stage.

• Lastly, most switches don't have the same trigger and reset points. So, when you do a G38.2 followed by a G38.4, you will likely see that these positions do not correlate.

Yeah, this is what I'm banking on. Use 38.{2,3} to find the switch with tools of arbitrary length, and 38.{4,5} to back off and find the switch off point at a slow feed

[chamnit]

@tmpvar : Ok. Now I see what you're getting to. You want to use G38.2/.3 as a seek and G38.4/.5 as a locate cycle. Makes sense. I think though, I'll need to remove the pull-back motion for this to work correctly. Perhaps we can do something along the lines of a compile-time option for the rest of the probing cycles, so that we can keep things simple for new users. Would that be an acceptable solution?

@ashelly : Yep. I think I'll re-write portions of this code to fix little errors like these. I don't think it'll be right to ask @tmpvar to fix the nuances of the Grbl code.

[tmpvar]

@chamnit a compile time option is fine by me. Also, if you are referring to the pull-back motion on G38.{4,5}, I think you are correct. The pull-back motion on G38.{2,3} seems alright as is, but removing it shouldn't affect my use case.

I'm also willing to fix up this patch-set so that it adheres to the grbl style, which so far only seems like the issue @ashelly mentioned. Are there any other nits?

[chamnit]

@tmpvar : Hard to say exactly without studying the code, but two things pop out. One, I'd try to find a way to remove the sys.probe_away variable and move it to the probe cycle function. There's got to be a way to do it without adding a permanent variable. Second, I'd probably re-instate the probe_get_state() function. I've been trying to keep any pin specific calls as function calls that can be easily changed or updated for portability reasons.

[chamnit]

@tmpvar : I wasn't sure if you were still working on this pull request. Should I wait?

[tmpvar]

@chamnit yeah, I'm taking another stab at it after thinking on it for a bit.

I have removed the sys variable successfully by packing probe modes into gc_block.modal.motion, but it seems like that is fairly error prone/not future proof change.

To fix that, I think adding a uint8_t on the stack inside gc_execute_line will make it a bit more clear

[tmpvar]

since probe_get_state is called from the ISR, we have to put the mode somewhere so we can pass it along. This seems like as good of a place as any, since we're only using 1 bit of 8.

[tmpvar]

Just realized that this still needs the "no error" mode installed on G38.3 and G38.5

[chamnit]

@tmpvar : Yeah. I started working on it last weekend, before I remembered to ask you first. So we weren't doing the same task. (I then got sidetracked by Windows updating hell trying to restore an old PC laptop.) I don't think the "no error" will be a problem. Everything up to to the probe call should be the same. The exit handling will only need to avoid setting the alarm and update the stored probe position to the failed location.

There also needs to be an additional boolean parameter, according to linuxcnc, that tracks if a probe is successful or not. And, this would likely need to be printed with $# view parameters. Not sure how to do this cleanly and not break any GUIs (but not many support it). Perhaps we can just append the boolean to the probe printout in $# like [PRB:0.000,0.000,0.000,1]... not sure.

[gerritv]

My vote: Adding it to PRB response makes it available in the correct context. $# presently returns axis values, not status values. If/when a GUI implements G38 support it will be interested in the status in its context, ie immediately after a probe command. Making the GUI then do a $# to get the status is not very tidy.

[chamnit]

@gerritv : Agreed. I didn't like the prospect of adding the boolean probe parameter either to the $# print out. It's not really needed or critical in practice. I suppose if it's only really useful if you don't have immediate feedback on the probe status, but in this case, we can provide it as a Grbl [] message, much like the current feedback. Perhaps as something like [PRB:Fail].

[ashelly]

@chamnit, that's exactly what I did for my automation interface. I either get "[PRB: ]" when it's good, or "[PRB:Not Found]" on bad. It works well for my use case.

[gerritv]

According to what I have read, an unsuccessful probe returns 0 for the status and location of the point (I suppose the location at point of failure). G38.3 and G38.5 only add an Error indication as well, otherwise they perform the same function as G38.2 and G38.4 respectively. (Not that I have used any of the probe commands, yet. Due for addition to my GUI soon though) Since a fail might also signal error, then we should send an error: sub code. to allow a more versatile and robust error handler.

[tmpvar]

Current behavior for G38.3/G38.5 moves back to the origin when the switch is not triggered.

grbl> G38.3 Z10 F100
?
RUN Machine(0.000, 0.000, 5.704) Work(0.000, 0.000, 5.704)
?
RUN Machine(0.000, 0.000, 7.032) Work(0.000, 0.000, 7.032)
?
RUN Machine(0.000, 0.000, 9.068) Work(0.000, 0.000, 9.068)
?
RUN Machine(0.000, 0.000, 7.272) Work(0.000, 0.000, 7.272)
?
RUN Machine(0.000, 0.000, 5.300) Work(0.000, 0.000, 5.300)
?
RUN Machine(0.000, 0.000, 2.048) Work(0.000, 0.000, 2.048)
?
RUN Machine(0.000, 0.000, 0.760) Work(0.000, 0.000, 0.760)
[PRB:0.000,0.000,0.000]

this should be fixed in the next commit by hopping over the pull-off section

[tmpvar]

Functional, minus the flag on the PRB report.

grbl> G38.5 X10 F1000
[PRB:10.000,0.000,0.000]
grbl> ?
IDLE Machine(10.000, 0.000, 0.000) Work(10.000, 0.000, 0.000)

I think adding a bool to track success is a good idea, that way the format is generally the same which makes for less surprise when writing a parser. I do think that the status should be returned immediately, but incase you cleared your terminal or something you should also be able to see it in the $# query

[chamnit]

@gerritv : I debated on using the error: protocol when I first installed G38.2, but it doesn't quite fit. The oks and error: indicate whether or not Grbl has received a command and processed it correctly for execution. A probe fail is something different.

With G38.2 it was easy, all I needed to do was to enable the alarm and all execution stops per g-code definition. Clean and easy.

G38.3/.5 kind of messes this up a bit, because it's a little different. If a probe fails, sending an error: will cause the GUI to stop streaming g-code (if the correct protocol outlines have been followed). There isn't a way for the GUI to tell if it was the probe command that failed or the probing cycle itself that failed, except by tracking what the error says. Not that great either.

If a G38.3/.5 probe command is valid (responds `ok') and the cycle fails, the GUI should receive separate feedback and keep streaming g-code. I suppose a problem would be if there are several probe commands sent and the GUI would then need to determine which one failed..... Dang. I hate it when there isn't a clean obvious solution.

[gerritv]

If you always send the probe fail/success status as part of the [PRB: response then 1 part is solved. For G38.2 and G38.4, you could additionally set Alarm? .3 and .5 should not send an error at all, just the Probe Status bit set to 0.

The protocol issue with the send/response is a general one, adding message numbers to the Gcode packet and to the ok/error (Ack, NAK) would allow keeping it all in line. But that requires a rather different implementation of Grbl and all the GUI's. Maybe when the Arduino Zero is released into the wild we can think of adding that additional 'real' protocol. (I used to design and implement protocols in the sync comms days, SDLC, X.25, Uniscope and some proprietary ones, the problem we are having is a common one)

[gerritv]

http://www.linuxcnc.org/docs/2.4/html/gcode_main.html#sub:G38.2:-Straight-Probe

[gerritv]

Doing some testing, trying out G38.2 If it fails, then the response as expected is "ALARM: Probe fail", but after doing the Reset, you go directly into <Alarm, state? I don't have Soft Limits enabled and no limits switches are tripped.

[tmpvar]

@gerritv you need to unlock / home to get out of the alarm mode

grbl> ?
IDLE Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)
grbl> G38.2 X-1 F100
ALARM: Probe fail
grbl> [Reset to continue]
grbl> reset
grbl> Grbl 0.9g ['$' for help]
['$H'|'$X' to unlock]
grbl> ?
ALARM Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)
grbl> $x
[Caution: Unlocked]
grbl> ?
IDLE Machine(0.000, 0.000, 0.000) Work(0.000, 0.000, 0.000)

[gerritv]

I know I need to do that, which is why I think it is a fault in implementation. It is an Error, not a catastrophic failure. It makes G38.2 useless or at least very risky to use: if it fails. I lose all my positions, feed rates etc just because the probe fails? I'm not totally certain this is what @chamnit intended.

When the probe fails, the machine still knows it is at the same X and Y location, it even knows where the controlled point is on the Z axis. No need to force a Homing cycle etc.?

[chamnit]

@gerritv : The intent was to place a failed G38.2 probe was to put into an alarm state. This is grbl's error mechanism to stop everything. The gcode standard doesn't explicitly layout the exact details of what should happen, but it does say that program execution must stop, which is in effect an alarm. From my exposure to professional CNCs, an alarm is used for just baout everything from limits to simple g-code errors. This forces users to ensure that their g-code programs are good.

However, machine position shouldn't be lost. The probe should have come to a stop before issuing the alarm. In these cases, like soft limits, machine position is retained. But you do bring up a good point, if you have G92 offsets and other g-code modes set, you do lose these upon a G38.2 probe fail. It does make this less useful, but can be useful in other scenarios. This is also another reason why @tmpvar is pushing installing G38.3/.5 as well, since these don't force program execution to stop. We just need to figure out the error mechanism for these two g-codes that doesn't stop the program.

[gerritv]

I understand the need to stop, having crashed a few times as well as broken cutters :-)
I implemented Pause on Error on my GUI for just that reason, a failed code block should not be ignored unless you are very sure of the code in the file. E.g. an M06 results in an error, not an Alarm.

IMO the really good news with implementing .3 and .5 is that no error or Alarm is required, just a status bit set to 0 instead of 1. For .2 and .4 the Alarm can then stay. This allows a probing program to continue even if it probed in thin air and is exactly what I would need it to do if I were mapping a model car body for replication.

[gerritv]

@chamnit re: the modes being lost, if you have the preset loaded in Gbl it will apply those after the Unlock? And a Gcode program should have its required settings at the top anyway. So that doesn't worry me either now. Thank you for clarifying the intent.

[chamnit]

@gerritv : Hmm. I just re-read the NIST and linuxcnc definitions. I must have hallucinated the program execution stop, because I don't see it. It just says "error is signaled", whatever that means. I suppose I interpreted it as a program stop. Has anyone use Mach3 or linuxcnc's probing feature? What's it behavoir?

If we need to change the "error is signaled behavior, we may need to think about a new feedback mechanism to indicate these types of messages. Not sure how though at this point.

[gerritv]

I'll read through the Mach3 stuff later tonight. For now I wouldn't lose sleep over the interpretation, the flow should stop on some events and maybe this is one.
Adding the extra ,0 or ,1 to the PRB response solves the issue for 38.3 and .5 which perhaps is what users should be making use of anyway?

[chamnit]

http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G38-probe

Ah. I'm not crazy. It does say halt program execution in the most updated linuxcnc website. So, alarm stays.

Conversely, we don't have to report anything for 38.3/.5. Just the position and record the fail parameter.

[gerritv]

Ahhh, I should stop reading their old wiki, very confusing.
@tmpvar Thank you for adding the non-interruptive G38 sub codes, will be very useful.

[tmpvar]

Conversely, we don't have to report anything for 38.3/.5. Just the position and record the fail parameter.

@chamnit have you come to a conclusion on whether or not to include bool_status in [PRB, x, y, z, bool_status]?

@gerritv of course :)

[chamnit]

@tmpvar : I think so. We should include the probe_status boolean for completeness and add it to the probe message. It should look like [PRB:0.000,0.000,0.000:0]. Note the : separating the boolean value. This should cover your additional g-codes, where G38.3/.5 should always report the probe message after completion but not enact the alarm if it fails.

I'm open to other suggestions, but this seems like a good compromise.

[gerritv]

@chamnit , a very parseable status string.

[tmpvar]

@chamnit sounds good to me, where is a good place to store the status long term (for $#)?

[chamnit]

@tmpvar : I would just add it to the report print probe position function in report.c. It's called by both the probing cycle and $#.

[tmpvar]

@chamnit right, but that would require the addition of another property on sys - something like sys.probe_succeeded or similar

[chamnit]

You're right, but I don't see a way around it for now. I think there will
need to be a system 'parameters' struct in the next version to store these
variables. Thanks for working on this. Long lengths of time to work on code
is in short supply these days.

On Mon, Sep 22, 2014 at 9:07 PM, Elijah Insua notifications@github.com
wrote:

@chamnit https://github.com/chamnit right, but that would require the
addition of another property on sys - something like sys.probe_succeeded
or similar

—
Reply to this email directly or view it on GitHub
#491 (comment).

[tmpvar]

@chamnit ready for review when you get a minute, I'm sure there are further nits which I'm happy to fix! :)

[chamnit]

@tmpvar : Awesome! Looks great. I'll merge it later today!

[chamnit]

@tmpvar : I reviewed the code in depth over the weekend. There are some issues that need to be resolved. The g-code modal report $G is broken with probing (and was missing G38.2 anyhow) with this update. I'll need to change around some of the g-code parser things. I also will be altering some of the probe state handling. There doesn't seem to be a way to get around the fact that you need system variables to indicate state and probing mode. Anyhow, thanks for doing the leg work on this. It's a lot easier to see what's needed and some potential bugs and pitfalls when there is a set of working code there to read.

[chamnit]

@tmpvar : Ok. Had some time to make the changes and pushed them. I did a once over of the code and a little bit of testing on it. If you have some time, please review the code and try to break it. Thanks!

[tmpvar]

@chamnit will do, been busy trying to kill some sporadic EMI in my setup which is causing homing to go a bit crazy. I've been meaning to build a rig to test out this code anyhow - will likely have time tomorrow to do so