[BUG] Strange behavior with a 4th axis in the new LINEAR_AXES features

[pyromanci]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

When I saw the LINEAR_AXES feature added in on June 5th. I wanted to give it a try as I do have some large printers and board with enough drive slots to possible start experimenting with 4/5/6 axis movements. For testing I used BTT GTR 1.0 board, with the M5 expansion board and BTT Octopus. I've even thrown a MKS GEN_L into testing just to make sure this wasn't a problem solely related to the BTT line of boards.

Everything was working normally. I could move the the extra Axis's I had connected. Which I have labeled as A. That Axis is on the back rail of my X Axis. While testing I didn't see any weird moments. Until I was printing a file that didn't have anything to do with A axis. I then noticed what appeared to be random, the printer stop and the Axis move to the end of it's extents and then back to it's home. Then the print would continue. I've checked the G code file and there is no G1 or G0 commands set to move the Axis.

At this time i'm not sure what in the file triggered this movement and i've seen it happen in more then just this file.

Bug Timeline

7/15/21

Expected behavior

That the additional Axes from the new 6 axis feature do not move when not suppose to.

Actual behavior

When processing GCODE Files they do some times go to the extent and come back.

Steps to Reproduce

1. Run the attached GCODE File

Version of Marlin Firmware

2.0.9.1

Printer model

CUSTOM Cartisan

Electronics

BTT GTR 1.0, M5, BTT Octopus, MKS GEN L

Add-ons

No response

Your Slicer

Cura 4.8

Host Software

OctoPrint

Additional information & file uploads

Config and one of the Gcode Files

[thinkyhead]

Whenever I have seen this kind of behavior it has been due to communication errors pushing weird G-code into the queue. Are you printing over USB and do you see the same issue when printing from SD?

[pyromanci]

I have been printing VIA octoprint. I will try the SD card. I will need to set up a camera for it to catch it. As I know it does it in the include G code file, but it's a 800g 17hr print and I've only caught by pure chance each time i've seen in.

[pyromanci]

It does do it when printing from SD card as well. Here is a another slice that is doing it.
CFFFP_Control Box v10.zip

In this slice I don't see the problem until LAYER:3 down in the lower right hand corner.

[thinkyhead]

I'm stumped. More data will be needed. This is a very complex problem.

[DerAndere1]

If anyone ever experienced this bug with ARC_SUPPORT disabled, please report here.

[pyromanci]

I currently have another long run print running (i've turned off the extra axes for now). Once it's done I will try and reproduce without out ARC support. Though it will be a few days before I can.

After reviewing the the first few layers of the print on the second gcode file. I can see several places the nozzle stopped and moved the 4th axis. As there are spots you can see that it was ozzing. So it did it several times before i saw it on that print.

[pyromanci]

Ok. I've gotten the addition testing done. I can confirm it only has happened during what should be a G2/G3 command just not every time.

For the additional tests I used the Model Second File exact same printer slice parameters. I did allow for cold extrusion and printed with out a heater or filament. So could focus on just the axis movements. Also All movement of the 4th Axis were the same. Full length stroke back and forth once at a speed slower then current print speed.

Printed the box with ARC_SUPPORT enabled and with the model arc weld in cura - The 4th axis moved
Printed the box with ARC_SUPPORT enabled and with the model arc weld in octoprint - The 4th axis moved
Printed the box with ARC_SUPPORT enabled and no arc welding. - No 4th axis movement
Printed the box with ARC_SUPPORT disabled and no arc welding. - No 4th axis movement
Printed the box with ARC_SUPPORT disabled and with the model arc weld in cura (just being thorough) - No 4th axis movement
Printed the box with ARC_SUPPORT disabled and with the model arc weld in octoprint (just being thorough). - No 4th axis movement

[DerAndere1]

I prepared PR 22602 to add a SanityCheck that will prevent compilation with [LINEAR_AXES 4 or more axes] AND [ARC_SUPPORT]

For anyone who is interested to extend ARC_SUPPORT to be compatible with LINEAR_AXES >= 4, the relevant code is in file https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/gcode/motion/G2_G3.cpp .

My thoughts on this (could be wrong): The code in the file G2_G3.cpp defines an l_axis (L axis) that is perpendicular to the working plane. By default (when CNC_WORKSPACE_PLANES is disabled), this L axis is identical with the z axis.
Without any special kinematics enabled, G2 / G3 is supposed to do linear interpolation for the 4th, 5th, 6th axes (i, j and k axes) and the L axis. That means that the logic for axes i, j and k should closely follow the logic for the L axis (l_axis).

[thinkyhead]

The PR #22599 adds support for extra linear axes, plus makes some other adjustments to arc processing. Please give it a test to see if it behaves any better. It's a rough work in progress at this point, so proceed with caution.

[DerAndere1]

Changes to ARC_SUPPORT (G2/G3) were made in Marlin bugfix-2.0.x. You can test it

[thinkyhead]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.