Acceleration violation with very short XYZ motion and large ABC motion

[robEllenberg]

Following errors are likely to occur due to acceleration violations when running this G-code snippet:

G0 X0 Y0 A0
G91 G20

G1 X0.1 Y0.1 A1.0 F100
G1 X0.000000005 Y0.000000005 A100.0 F10000
G90
G1 X0 Y0 A0 F10000
M2

Here are the steps I follow to reproduce the issue:

1. Run LinuxCNC in simulation or real hardware on a machine with at least one linear and at least one rotary axis. It's easier to see with Sam's HAL setup to compute accelerations for each axis.
2. Run attached program
3. Acceleration violation (or following error) at line 5

It worked properly before this:

Not sure, but likely for most 2.7 releases

Information about my hardware and software:

Running simulation config in a user-space build (on Ubuntu 18.04) in tests/trajectory_planner/circular_arcs/configs/XYZ.ini (bit of a misnomer since it has an A axis). The particular platform should not matter for this issue, though it would be interesting if it was affected by compiler / choice of kernel.

[jallwine]

Are you sure CART_FUZZ is the same tiny value as the one used in TP? There are a number of different EPSILON values used. Where are the corresponding calculations done in TP?

#define CART_FUZZ (1.0e-8)

These are various values found in tp_types.h:
#define TP_PURE_ROTATION_EPSILON 1e-6
#define TP_ACCEL_EPSILON 1e-4
#define TP_VEL_EPSILON 1e-8
#define TP_POS_EPSILON 1e-12
#define TP_TIME_EPSILON 1e-12
#define TP_ANGLE_EPSILON 1e-6

[robEllenberg]

It wasn't before, canon had its own "tiny" value which was 1e-7. The zero-length check is done in pmCartLineInit(_posemath.c:1652). It used to look at the overall magnitude of the vector, but now is looks at the largest component (which is what canon does). Each of those other epsilon values has a specific purpose that's unrelated to the zero-length move check. I'd like to consolidate them eventually, or else add documentation as to what they're for.

…

On Fri, Jan 25, 2019 at 4:51 PM John Allwine ***@***.***> wrote: Are you sure CART_FUZZ is the same tiny value as the one used in TP? There are a number of different EPSILON values used. Where is the corresponding calculations done in TP? #define CART_FUZZ (1.0e-8) #define TP_ACCEL_EPSILON 1e-4 #define TP_VEL_EPSILON 1e-8 #define TP_POS_EPSILON 1e-12 #define TP_TIME_EPSILON 1e-12 #define TP_ANGLE_EPSILON 1e-6 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#550 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJ6PDBzcFU_kHVLkZpCLIunC2irxL5Gks5vG3xFgaJpZM4aTRzB> .

[jallwine]

Is the pmLineInit function ever called? It has similar checks to the pmCartLineInit function, but you didn't make your comparison changes there.

https://github.com/robEllenberg/linuxcnc-mirror/blob/10c3678ab069f856532e5512a93bfaffcf930491/src/libnml/posemath/_posemath.c#L1569

[robEllenberg]

I replaced all usages I could find of PmLine with PmCartLine, so not used currently. I'd like to either deprecate the old PmLine and related functions, or I can migrate the change there too.

…

On Sun, Jan 27, 2019 at 10:28 AM John Allwine ***@***.***> wrote: Is the pmLineInit function ever called? It has similar checks to the pmCartLineInit function, but you didn't make your comparison changes there. https://github.com/robEllenberg/linuxcnc-mirror/blob/10c3678ab069f856532e5512a93bfaffcf930491/src/libnml/posemath/_posemath.c#L1569 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#550 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJ6PPElDs6cf3HEJZ_MflYIUPD20yCrks5vHcWRgaJpZM4aTRzB> .

[jallwine]

When I make your changes to MachineKit, I get B follow errors on programs that previously worked. I’ll take a closer look tomorrow, maybe I made a mistake somewhere.

[robEllenberg]

I'm also still seeing some violations (though not as bad) in a particular pathological case (arc / tangent blends between a linear+angular and pure angular move). I'll continue to investigate on my end, there's clearly something still missing. Thanks for trying it out!

[gfalavigna]

I'm facing the same issue of your G-code snippet, but with X axis moving a little longer (e. g. G1 X1 instead of G1 X0.000000005) that is above the EPSILON previously mentioned.

I have just tried to test what was done in https://github.com/robEllenberg/linuxcnc-mirror/tree/bug-550-tp-canon-displacement-checks but with no benefits.

Does someone know if there is a way to work around this situation?

Thanks in advance

[robEllenberg]

@gfalavigna try this branch:
https://github.com/robEllenberg/linuxcnc-mirror/tree/rellenberg/develop-combined-2.7

That one should have all the corner-case fixes for TP acceleration violations.

[jallwine]

It's been a while since I checked in on this. Do you believe this is fixed? Do you have any plans to port these changes over to MachineKit?

[robEllenberg]

This issue and a few related ones are fixed in this pull request: #589 I haven't tried to port it to MachineKit yet, but it would be worth rebasing that whole branch to keep them consistent (and to include unit testing for the TP).

…

On Fri, May 17, 2019 at 10:48 AM John Allwine ***@***.***> wrote: It's been a while since I checked in on this. Do you believe this is fixed? Do you have any plans to port these changes over to MachineKit? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#550?email_source=notifications&email_token=AAJHUPAORUX2NWXKESXDLDTPV3ATZA5CNFSM4GSNDTA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVU623Q#issuecomment-493481326>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJHUPEEV732CNMNRCYRHPLPV3ATZANCNFSM4GSNDTAQ> .

[jallwine]

@robEllenberg, is there any chance you could help with rebasing this fix into MachineKit? I could probably handle finding changes that require prefixing rtapi_ (fmin, cos, etc.), but with things like the tp_shared changes in MachineKit and tpCheckTangentPerformance in MachineKit vs tpChooseBestBlend in LinuxCNC, I'm in a little over my head. For a lot of the rebase conflicts, I'd be making very uninformed decisions about how to fix them. Any help you can provide in rebasing or pointers you could give me would be appreciated!

[robEllenberg]

If I can get half a day free one of these weekends I'll give it a shot. It would help a great deal if we can bring the 2.8 and machinekit trajectory planners more in line with each other. Over the years, features have been merged inconsistently, and it's become a big headache to port anything from one to the other.

[jallwine]

Thanks @robEllenberg! I really appreciate all the work you've put in so far. Let me know if I can help in any way. I'm happy to test things out or do anything else that would be helpful.