Crash prevention for PBL conversational lathe cycles?

When trying out / developing / testing the conversational cycles in Probe Basic Lathe, it's been pretty clear that it would be quite easy to accidentally type in an inappropriate diameter (X coordinate) or axial position (Z coordinate). Humans are good at doing this sort of thing. But worst of all, there's currently nothing by way of a sanity check in the macros to prevent a bad crash. They are pretty robust and straightforward but they expect a degree of responsibility on the part of the user to get the coordinate inputs right.

By experimenting with different starting positions when trying out the macros with air cuts, the result of wrongly specifying X and/or Z coordinates is easy to see on the backplot. In simple terms, the positioning (clearance and positioning) moves are simply based on the starting position and the dimensions of the stock and the feature to be machined, as specified in the setup table. The macro doesn't check the tool position against the outline of the stock you have defined, yet it executes rapid positioning and clearance moves based on that info. What could possibly go wrong?

As you can see, positioning the tool as shown below results in the tool attempting retract and positioning moves within the stock - not ideal: 

Here's a tool start position at 7mm (diameter), with "10mm diameter at corner" ie stock diameter.

Looks almost sensible:

Same operation but with tool, start position at 7mm (diameter), with "10mm diameter at corner" ie stock diameter.

Oooof. Lots of retract and positioninbg moves within the stock:

We can surely do better than this, based on the information at hand.

Quite simply, the plan is for the tool to approach the toolpath from outside the stock in both X and Z. However, if the starting X and Z coords are within the stock outline, an error should be notified and the operation aborted.

Doesn't sound very tricky to implement, so I asked Claude to propose a simple sanity check. 

Good progress. Here's my
suggestion for the sanity checks:
After starting_X and starting_Z are captured (before any motion), add a block that checks:
checks:
Z-side check (wrong side of the face):

• Front outside / Front inside: starting_Z must be > radius_z (approach from the open/tailstock side)

• Rear outside: starting_Z must be < radius_z (approach from the chuck side)

X-clearance check (inside the stock):

• Front outside / Rear outside: starting_X must be > radius_x (outside the OD)

• Front inside: starting_X must be < radius_x (inside the bore)

In NGC it would look like
this immediately after the starting_X/starting_Z assignments:

o120 if [#<radius_exterior_front> GT 0]
     o121 if [#<starting_Z> LE #<radius_z>]
          (MSG,ERROR: Front outside radius - start tool to the +Z side of the face)
          o121 return [-2]
     o121 endif
     o122 if [#<starting_X> LE #<radius_x>]
          (MSG,ERROR: Front outside radius - start tool outside the diameter)
          o122 return [-2]
     o122 endif
o120 elseif [#<radius_interior> GT 0]
     o123 if [#<starting_Z> LE #<radius_z>]
          (MSG,ERROR: Front inside radius - start tool to the +Z side of the face)
          o123 return [-2]
     o123 endif
o120 elseif [#<radius_exterior_rear> GT 0]
     o124 if [#<starting_Z> GE #<radius_z>]
          (MSG,ERROR: Rear outside radius - start tool to the -Z side of the face)
          o124 return [-2]
     o124 endif
     o125 if [#<starting_X> LE #<radius_x>]
          (MSG,ERROR: Rear outside radius - start tool outside the diameter)
          o125 return [-2]
     o125 endif
o120 endif

One subtlety: the radius_x comparison for front inside is less clear-cut (the boring bar could be anywhere inside the bore), so I'd leave that one out unless you want to add it. The Z-side check catches the most dangerous crash scenario.

Want me to add this to the file?

Let's test this out and see if there are any situations where this might be a problem limiting the desired operation - and if it is actually a useful safety feature in the first place. If it looks helpful, we can then implement similar sanity checks on the other operations.

Here's the equivalent operation in the Radius macro, with this error checking implemented:

There's no machine movement and the error box pops up.

Once the tool position on the X axis exceeds the specified "Diameter at Corner" value, operation is allowed. Sounds like a good result.

Checking with the tool position on the Z axiswithin the stock bounds also works:

That is a win. 

A couple of observations / issues to fix next:

• The macros will run with T0 ("no tool") loaded, at which point, there's no tool shape shown in the backplot. Is that a problem?
• It would be handy to have some gridlines shown in the backplot to give an idea of scale. Perhaps autoscaled to suit the operation in hand.

So, let's get the other sanity checks implemented, then get these 2 points resolved.