G2 doesn't do proper limit checks

[hdiethelm]

At least I think that's not supposed to happen:

LinuxCNC 2.9.8 or master branch / axis_mm:

• Start and home
• Go to MDI and enter "G2 I1000 F2000"
• The machine just runs into the soft stops with full speed and overshoot the limits
  • In my real setup, it would probably crash due to the distance between soft limits and hard crash not enough to stop with full speed
• "G0 X1000" for example is checked and not executed if it will go off limits

If I find time, I might look into the code.

[andypugh]

Well the good(?) news is that it's always been like this. I have tested back to LinuxCNC v2.5 from 2012 and it's just the same.

The same code inside a G-code program does bring up a warning, but if you override then it runs out of bounds too.

[hdiethelm]

I did some future testing by writing a tiny ngc file and and pressing continue anyway when I'm asked.

• G0 out of bounds
  • GUI doesn't complain
  • Interpreter doesn't execute it
• G1 out of bounds
  • GUI does complain
  • Interpreter doesn't execute
• G2/G3 out of bounds
  • GUI does complain
  • Interpreter executes it and then it goes out of bounds
• G5 out of bounds
  • GUI does complain
  • Interpreter doesn't execute it

It's not that big of an issue, because in most cases, you probably use G2/G3 only in .ngc files but you can crash you machine if you use it in MDI mode. Luckily I tried that first in simulation because I'm still learning and I don't want to crash my machine... ;-)

Also if you write a macro containing G2/G3 and execute it in MDI, you have the same issue. Probably also when you execute it using HALUI->MDI_COMMAND (I did not test that)

[hdiethelm]

Some debugging later I found that inRange does only check the position of the circle, not the diameter:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/command.c#L1076

Copying over some code from motion-logger.c results in:

SET_CIRCLE:
    pos: x=45.04, y=8.7672, z=-68.49, a=0, b=0, c=0, u=0, v=0, w=0
    center: x=1045.04, y=8.7672, z=-68.49
    normal: x=0, y=0, z=1
    id=0, motion_type=3, vel=33.3333, ini_maxvel=80, acc=200, turn=-1

a few seconds later:
Exceeded POSITIVE soft limit (405.00000) on joint 1

I somehow did not manage to run motion-logger. As soon as I run this module, the normal program flow breaks, so I just copyed the printf's over to command.c

[hdiethelm]

Implementing an inRange check for circles is probably rather involving.

G5, G5.1, G5.2 (and might be more) use also multiple circles in the background. I think with some backwards calculation or random tries, you can also find examples for these which will run out of bounds. My test didn't do that because pos was also out of bounds of at least one circle.

For the moment, I would just add a warning to the doc except someone want's to implement bounds checking for circles.

[hdiethelm]

I had an idea I wanted to test: Just use a mirror tp to check if your proposed trajectory runs out of bounds before you really execute it. It might be to computationally expensive but it seams to work and it probably also works with nonlinear kinematics.

A really hacky POC: hdiethelm/linuxcnc-fork@xhc-whb04b-6-fix-v2...hdiethelm:linuxcnc-fork:g23_limit_hacking

An other option would be to continuously check during moves if you can stop with max. acceleration before hitting the bounds. In edge cases, I think that will not work with strongly non linear kinematics, but it will be less computationally expensive.

[andypugh]

I had an idea I wanted to test: Just use a mirror tp to check if your proposed trajectory runs out of bounds before you really execute it.

This is how the G-code previewer does it, and is why the GUI / G-code gives warnings, using the SAI (stand-alone interpreter) I think.

I don't think that it is particularly hard, in principle, to work out if an arc lies entirely within bounds. You need the start and end angles of the circle, and then check the points on the circle at 0, 90, 180, 270 degrees if those angles lie inside the arc limits.

But the InRange function doesn't get the arc centre or radius, so can't work it out.

(This assumes a rectilinear bounding box (in joint space) which is all that LinuxCNC currently supports) and the angles above are in world space, so there is some complexity for non-trivial kins.)

[hdiethelm]

I had an idea I wanted to test: Just use a mirror tp to check if your proposed trajectory runs out of bounds before you really execute it.

This is how the G-code previewer does it, and is why the GUI / G-code gives warnings, using the SAI (stand-alone interpreter) I think.

I don't think that it is particularly hard, in principle, to work out if an arc lies entirely within bounds. You need the start and end angles of the circle, and then check the points on the circle at 0, 90, 180, 270 degrees if those angles lie inside the arc limits.

I think it's not that simple. The circle is defined by a start point, end point, center and normal. And it can also do spirals. It looks like the G codes only do circles in XY, XZ or YZ planes and spirals perpendicular to this plane. However, the underlying math can do it for every normal. In that case, a circle can touch the boundary at any angle.

Also, when you go a bit deeper, some blending, fitting and corrections are done.

But the InRange function doesn't get the arc centre or radius, so can't work it out.

(This assumes a rectilinear bounding box (in joint space) which is all that LinuxCNC currently supports) and the angles above are in world space, so there is some complexity for non-trivial kins.)

Creating an inRangeCircle would do the trick. But that might be more difficult than it seams. This function could use inRange to check single points of the circle. That way, also the joints are verified.

Options are:

1. Figuring out the extreme points of a the circle and check them (0,90,180... in a simple case but not always)
2. Sampling a circle, let's say 90 times in 4° steps and check the points
   An elegant solution would be to use the same code that is used for later interpolation, just for way less samples
3. Use a second tp to project what is going to happen and use these samples (My hacky example) The time steps could be increased for this to avoid unnecessary calculations.
4. Check if the maximum acceleration is enough to stop before a boundary is hit and if not, stop. This could be done in a general path and will always help against boundary overruns.
5. Write a warning in the doc and forget about it.

Option 4 sounds interesting to me. It is not that complicated and you can do it in a general way. That could be even a separate hal module and it works in all cases, even if someone in the future creates a new move type and doesn't do the bounds check properly. What do you think?

Joints can be be checked using joint.0.pos-cmd / joint.0.pos-fb / joint.0.vel-cmd
Machine coordinates using axis.x.pos-cmd
Is there any signal corresponding to the axis velocity? I did not find anything, but it could be estimated based on differentiating the position.

[andypugh]

That could be even a separate hal module and it works in all cases, even if someone in the future creates a new move type and doesn't do the bounds check properly. What do you think?

I don't think anyone is going to invent a new move type. Most machining is done with CAM now, and that typically needs to be asked nicely to even do arcs. The vast majority of generated G-code is millions of short linear moves. LinuxCNC has Splines / NURBS, but I am unclear if anyone had ever used them. I don't think any CAM software supports them.

[hdiethelm]

I just used splines to convert text to G-Code for creating name plates:
oe7set/Text2Gcode#1
It works great!

GCode from FreeCAD uses circles if you draw a round form. There are a lot of macros especially for lathe's and I also just created a few macros. It's way faster then using CAM for single piece production. Especially if you prefer writing code than clicking around in UI's.

Looking at the code, I also don't think anybody will do new G-Codes, it is just to complex... ;-) But you never know.

Just found a link in the code in: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/control.c#L1546

#80

So this issue is nothing new at all. I did not went that far back in the issues list.

[hdiethelm]

A simple version of the acceleration based variant:
hdiethelm/linuxcnc-fork@master...hdiethelm:linuxcnc-fork:acc_based_soft_limit
It works mostly but somehow, when I hit the limit, it doesn't stop with the full acceleration but only about halve or even less when I don't hit it straight. It seams that the coordinated move just continues instead of hitting full breaks.

Also G-Code does only 1/2 of MAX_ACCELERATION. Any idea why this is the case?

[hdiethelm]

After some future investigation, I discovered that G-Code moves are stopped respecting the actual configured acceleration and for circles, this is a vector which lies on the circle. So ^^ is also complex to implement properly. By configuring high speeds and low accelerations, you can exceed the soft limits pretty far as long as you don't have limit switches.

Due to my machine has no limit switches, high speeds and just 10 mm between the soft limit and the crash structure, that got me now a bit afraid of crashing due to bugs or me entering a gcode command wrong in MDI. I think the best solution would be to create a soft_limits hal module, so the limits are verified near the outputs and not somewhere deep in the code where somebody can forget to do proper checks.

This module would check the following signals to verify if an excursion is unavoidable:
joint.0.pos-cmd
joint.0.pos-fb
joint.0.acc-cmd
...

and then modifies:
joint.0.motor-pos-cmd -> soft_limits -> stepgen.00.position-cmd
to use the stepgen (or hm2, other output modules) to break with max acceleration and then stop. If an excursion happens anyway, joint.0.pos-lim-sw-in or joint.0.neg-lim-sw-in can be set.

Thoughts about this?

[hdiethelm]

I found a way to stop reliably in control.c, updated branch:
hdiethelm/linuxcnc-fork@master...hdiethelm:linuxcnc-fork:acc_based_soft_limit
It's probably not how it's nicely done in linuxcnc and just a POC. But it works and I can even resume normal operation afterwards without quirks. I would need some guidance to do that the correct way, I am not so deep in this code yet.

So I leave that for now and wait for comments. I see two good options:

• Enforce soft limits in control.c as done in ^^ just in a nicer way
  • +It can handle proper tp abort and resume normal operation
  • -Change in existing code, could result in new bugs
• Enforce soft limits in a separate hal module
  • +Independent of existing code, if someone has issues with it, just don't use the module
  • -Might need re-homing / restart afterwards
  • -Would need new examples and documentation

[andypugh]

I think this is actually a duplicate of the oldest bug, #80