Marlin-9axis_pull hardware test report Axes 8 and 9

[HendrikJan-5D]

To support rebasing 9axis_pull branch onto current upstream MarlinFirmware/Marlin/bugfix-2.0.x

Have I configured Marlin-9axis_pull for 8 axes
And tested with a Dummy hardware shaft.
All functions work.

I configured Marlin-9axis_pull for 9 axes.
I am getting compiler errors

Marlin > src > feature > tmc_util.cpp

445 #if AXIS_IS_TMC(P)
446 if (monitor_tmc_driver(stepperP, need_update_error_counters, need_debug_reporting))
447 step_current_down(stepperPM); <-------------> must be (stepperP )
448 #endif

Marlin > src > core > macros.h

LIST_INC_INC_16 was not declared in this scope [332,25]

Marlin > src > core > serial.cpp

identifier q is undefined C/C++ (20) [117,3]
q was not declared in this scoop [118, 160]

Marlin > src > gcode > config > M92.ccp

Q_AXIS was not declared in this scope

It seems if you choose 9 axes , ( P ) the 10th axis is also chosen ( Q )
Would you take a look at this, I can't figure it out.

Send the complete configuration to you.

Marlin-9axis_pull 9 Axis test.zip

[DerAndere1]

Thanks for testing and reporting. I will have a look.

[DerAndere1]

compilation for 8 and 9 axes is fixed now in https://github.com/DerAndere1/Marlin/tree/Marlin/9axis_pull . Thanks for providing the preconfigured firmware, it helped with development . Your pin files and configs can be copied over without changes.

[HendrikJan-5D]

I have tested the latest version Marlin/9axis_pull.
Compiling is no longer a problem.
The W ( P ) endstop function is okay ( M119 )
The 9th axis can only turn in one direction.
The dir function of the TMC2209 does not work.
This also prevents the homeing from working.
With G1 W20 the shaft goes in the plus direction 20 mm
Then at G1 W5 the shaft goes to 35 mm instead of to 5 mm
All commenucation with the TMC2209 via ( M122 S0 ) is okay.
Another TMC2209 gives the same problem
The TMC2209 in a different position of the motherboard does not improve.
This excludes a hardware error.

[DerAndere1]

It seems the P axis is always in relative mode. This seems to be related to issue #54 . I had no problem with absolute/relative mode in upstream Marlin bugfix-2.0.x so it seems like a good idea to rebase the 9axis code onto current MarlinFirmware/Marlin bugfix-2.0.x now as that should fix the issue

EDIT: you issue seems to be more than just relative mode I have read 25mm where you wrote 35mm. What happens if you send
G1 W20
G1 W-1 ; Warning. This may crash the W axis into physical limits so be ready to push the emergency kill button

[DerAndere1]

Luckily I just found and fixed a typo in 9axis_pull that led to a bug in the p axis that would have been very hard to debug otherwise. Maybe that fixes it already

[HendrikJan-5D]

Your latest update did not resolve the issue.

G1 W20 + ------> 20 mm
G1 W-20 +------> 40 mm totaal +----> 60 mm

The dir function of the TMC2209 P axis is not controlled

When compiling I regularly see a problem message.
Which has to do with the P axis.

[DerAndere1]

Memo to myself: I have to change uint8_t to linear_axis_bits_t in the following lines:

Marlin/Marlin/src/module/stepper.h

Line 291 in 2b18e92

static uint8_t last_direction_bits, // The next stepping-bits to be output

Marlin/Marlin/src/module/stepper.h

Line 545 in 2b18e92

static void set_directions(const uint8_t bits) {

Marlin/Marlin/src/gcode/gcode.h

Line 329 in 2b18e92

static uint8_t axis_relative;

Marlin/Marlin/src/module/planner.cpp

Line 2333 in 2b18e92

static uint8_t old_direction_bits; // = 0

Marlin/Marlin/src/module/planner.cpp

Line 2337 in 2b18e92

const uint8_t direction_change = block->direction_bits ^ old_direction_bits;

Marlin/Marlin/src/module/stepper.cpp

Line 152 in 2b18e92

uint8_t Stepper::last_direction_bits, // = 0

Marlin/Marlin/src/module/stepper.cpp

Line 1662 in 2b18e92

uint8_t dm = last_direction_bits;

Marlin/Marlin/src/module/stepper.h

Line 291 in 2b18e92

static uint8_t last_direction_bits, // The next stepping-bits to be output

Marlin/Marlin/src/module/stepper.h

Line 545 in 2b18e92

static void set_directions(const uint8_t bits) {

and make sure the following macro from motion.h L425 is moved to types.h or elsewhere so that it is available in all files listed above:

typedef IF<(LINEAR_AXES > 8), uint16_t, uint8_t>::type linear_axis_bits_t;

[DerAndere1]

above changes are now in 9axis_pull branch. Testing is much appreciated

[HendrikJan-5D]

I downloaded your latest version.
And think you made a version mistake somewhere.
I run into compiler errors that have already been fixed in an earlier version. ( 3 days ago )
And now reappear.

[DerAndere1]

yes my git repository was in a strange state. should be fixed now including an additional correction regarding relative/absolute mode

[DerAndere1]

If the current solution is problematic with 8 or 9 axes, we will have to use axis_bits_t instead of linear_axis_bits_tin the above places.

[HendrikJan-5D]

In the first configured version 3 days ago, the 8th axis worked without any problems.
Only the 9th axis had problems.

[HendrikJan-5D]

Latest version downloaded

My pin files and configs copied over without changes.

The dir problem with the 9th axis is not solved yet.

The other 8 Axis work well

G1 X100 Y100 Z100 A90 B45 C45 U90 V90

I send you the current configuration

Marlin-9axis_pull 9 Axis test 5.zip

[HendrikJan-5D]

When looking for a solution to the ( dir ) problem of the P Axis
I came across the following things.

Marlin > src > core > types.h

376 template
377 struct XYZval {
378 union {
379 struct { T LINEAR_AXIS_LIST(x, y, z, i, j, k, m, o, p, q); };
380 struct { T LINEAR_AXIS_LIST(a, b, c, u, v, w, ax7, ax8, a9, ax10); };
381 T pos[LINEAR_AXES];
382 };

Line 380 ----> a9 this must be ax9

Unfortunately this doesn't solve the ( dir ) problem of the P Axis.

I also came across a few things while searching that I don't know if it's wrong.

Marlin > src > inc > Conditionals_post.h

186 #if LINEAR_AXES >= 9
187 #define _P_HALF_PMAX ((P_BED_SIZE) / 2)
188 #endif

I'm missing the code for the 10th Axis .
While he is present at line 213

Marlin > src > feature > stepper_driver_safety.cpp

In this file I see everything from the X Y and Z Axis plus extruders E
I expect there should also be a code for I J K M O P Q Axes

[DerAndere1]

I now changed the type of one occurance of uint8_t dm and did the changes proposed by you. To understand why it is so much more difficult to get 9 axes working compared to 8: to safe space. Marlin uses variables of type uint8_t whenever possible, which is a variable with 8 bits, so up to 8 axes are possible with the old code. For more axes, I had to change to a variable type with more than 8 bits. Changing all occurances of u8int_t would increase code size too much, so I have to find the right spots. I now use axis_bits_t in all places I listed so far, which hopefully it resolves the issue. Thanks for being patient with me.
Things that have to be tested for 8 axes and seperately for 9 axes:

• change of direction
• change between absolute mode and relative mode (G90, G91)

[HendrikJan-5D]

Just a quick feedback.
The 9th Axis works.
Come back to it later, test more first
We've fixed it.

[DerAndere1]

This is great. If you like, you can prepare a list of Gcodes you need for printing and one list for G--codes you tested succssfullly.

Alternatively, you could attach an example gcode file (preferrrably one with many different commands) that you tested, and report the Start-Gcode and End-Gcode (if any) you are using. That would be equally helpful - Would be nice to see where we stand.

[HendrikJan-5D]

For the X Y and Z Axis all standard codes work
And can I print normally
This is not yet possible for the other Axes.
Because there is no universal Slicer software yet.
This is my next challenge .
I am already in contact with TU Delft.
But could only continue with this when all 7 axes can be controlled with G coders.
I still want to see if we can get the 10th Axis working together.

I did the tests you asked about before
See test report.
Can I do other tests ?
Otherwise I'm going to configure the 10th axis and test it out.

DerAnder1
I would like to get in touch with you as a member of Hcc!3d outside of github.
Is this possible

Marlin-9axis_pull 9 Axis test report.txt

[HendrikJan-5D]

I configured the 10th Axis. (The 10th Axis works after corrections )
See attached test report.
And configured files

Question

For the cooling of drivers on the extension board M5.
I also want to control a second fan at the same time ---> FAN3_PIN

Configuration_adv.h

466 --> #define CONTROLLER_FAN_PIN FAN2_PIN // Set a custom pin for the controller fan

Is that possible with the current configuration ?

Test report Axis 10.txt
Marlin-9axis_pull 10 Axis test 1.zip

[DerAndere1]

Thanks for the corrections. One of the more challenging things to get working correctly with a 5+ DoF machine is probably bed leveling. For your setup, we could change the AUTO_BED_LEVELING_3POINT code so that it automatically adjusts the rotational axes of the table. Then the bed can be assumed to be level after a G29. Otherwise (or for mesh-based bed leveling procedures) you would probably have to implement inverse kinematics for your machine within Marlin

[DerAndere1]

I will contact Hcc!3d via their website and see if we can get in contact as soon as I have time.

[HendrikJan-5D]

((The AUTO_BED_LEVELING_3POINT code so that it automatically adjusts the rotational axes of the table.))

That would be nice .
Because I now have to make sure that all axis are in the 0 position before I apply G29

1193--> #define NOZZLE_TO_PROBE_OFFSET { 10,-20, -2.0, 0, 0, 0, 0, 0, 0, 0 }

In this line you must be able to indicate how all axes are in the G29 function.
That doesn't work yet.

Before I bring my printer back to 7 Axes I send you a video of the test setup for 10 Axes

https://youtu.be/7TWvoukShwI

[DerAndere1]

1193--> #define NOZZLE_TO_PROBE_OFFSET { 10,-20, -2.0, 0, 0, 0, 0, 0, 0, 0 }
In this line you must be able to indicate how all axes are in the G29 function.

Not so sure about that. I think you allways should home all axes before sending G29 and in that case, only offsets in X, Y and Z are meaningful. NOZZLE_TO_PROBE_OFFSET should become distances in the cartesian 3D space, so only X, Y and Z element is meaningful. The additional elements of value 0 in that array are only a workaround that is needed until Marlin has a dedicated variable type for 3D coordinates.
To make the firmware respect those 3D offsets with more than 3 axes, you need inverse kinematics. The task of inverse kinematics is exactly that: translating those 3D coordinates into the required joint positions according the kinematic parameters (dimensions of your specific machine) and that is outside of the scope of my work.

Quote from the wiki:

If you have a different machine where additional axes contribute to tool positioning, you currently have to implement your own kinematic model or develop a post-processor that translates desired tool positions to compatible G-code.

What I meant with my proposal was to eliminate the need for bed leveling compensation in software during the print by doing it in hardware once during the G29 procedure. Here is some pseudo-code for that implementation of G29:

• probe 3 points
• Get probing data
• Get bed plane (the plane normal is enough):

  vector_3 planeNormal = vector_3::cross(points[0] - points[1], points[2] - points[1]).get_normal(); 

(inspired from

Marlin/Marlin/src/gcode/bedlevel/abl/G29.cpp

Line 702 in de061ba

vector_3 planeNormal = vector_3::cross(points[0] - points[1], points[2] - points[1]).get_normal();

)

• Calculate the bed tilt angle using linear algebra: angle between planeNormal and vector3 y = (0,1,0) (for A axis) and angle between planeNormal and `vector3 x = (1,0,0) (for B axis)
• turn A axis stepper and B axis stepper to compensate for the bed tilt in hardware
• set A and B axis position to 0 (in software, don't turn the sepper). (get inspiration from G92 command)
• throw away bed level data and turn of software bed level correction because the bed can be assumed to be really level (get inspiration from G29 J command)
  --> G29 finished

[HendrikJan-5D]

I think I misunderstood you.
What I had in mind, that when starting the G29 code from arbitrary axes position
All axes move first to their 0 position .
And only then start the bed leveling function

First homen G28 and then bed leveling G29 will not always go well .
If an axis has a negative offset . ( I_MIN_POS -90 ) (I_MAX_POS 90 )
Then after homen the I axis is at -90
And must first be brought to 0 before I can bed level G29
Since I have a round bed, the 0 point of the X and Y axis is also in the middle of the bed,

[HendrikJan-5D]

Have you already implemented my changes to, the 10 Axis test report, in the official version?
Then I can mechanically test it again with 10 Axis.
Before I build my printer back to 7 Axes.

[HendrikJan-5D]

G29 AUTO BED LEVELING > LINEAR < also works

[DerAndere1]

I have added your corrections plus one change in motion.h to 9axis_pull. But so far I have not found a solution to the "?" reported with M122 S0 for the slave_adress and the stallguard threshold of the Q axis. Maybe the TMCStepper library is limited to 9 axes + E axis = 10 TMC steppers?

Regarding

First homen G28 and then bed leveling G29 will not always go well .
If an axis has a negative offset . ( I_MIN_POS -90 ) (I_MAX_POS 90 )
Then after homen the I axis is at -90
And must first be brought to 0 before I can bed level G29

Does it help to set the following in Configuration.h ?

#define MANUAL_I_HOME_POS -90

[HendrikJan-5D]

When I download Marlin-9axis_pull as zip file.
I get Marlin-Marlin2ForPipetBot.zip

[HendrikJan-5D]

Also when I download zip file
10 axis_PR1
9axis-pull_b
bugfix-2.0.x

I get Marlin-Marlin2ForPipetBot.zip

[DerAndere1]

Edit: github fixed their bug that caused the issue with downloading different branches as zip from github.com.

[HendrikJan-5D]

I have done several tests.
Also on a new computer with Windows 11.
Here I see other error messages at the same place.
It also does not display the TOOL number when connecting.
If I offer the complete test file via a usb stick directly through the printer display
TFT70 everything goes well.
I think it has to do with the usb driver in Windows.
And it happened after one of the last updates of Windows 10 and now also in Windows 11.
How can I solve this driver problem.
And which one should I choose for BTT GTR V1.0 with a STM32F407IG

[HendrikJan-5D]

To see if I could control the Rotary Axes via the LCD display.
I configured the following marlin fork from your github platform.
Marlin-move_rotary_axes_from_LCD.
I get a compeiler error, which I think is caused in the SanityCheck.
And send you the completely configured Marlin files

Marlin-move_rotary_axes_from_LCD.zip

[DerAndere1]

Please test if you can fix the first error (cannot call non-constexpr function "strstr") by updating your libraries and the ST STM32 platform under "PlatformIO home"

---

I used your latest configs to identify and fix a compile error related to the U axis in my move_rotary_axes_from_LCD branch. here is a link to the single line change:

85a9fbd

---

To compile the fixed move_rotary_axes_from_LCD branch, I did the following changes in your Configuration_adv.h as advised by the sanity check:

//#define SAFE_BED_LEVELING_START_X 0.0
//#define SAFE_BED_LEVELING_START_Y 0.0
//#define SAFE_BED_LEVELING_START_Z 0.0

change those lines to something like this:

#define SAFE_BED_LEVELING_START_X 0.0
#define SAFE_BED_LEVELING_START_Y 0.0
#define SAFE_BED_LEVELING_START_Z 50.0

Instead, if you know what you are doing and/or are willing to accept the risks associated with experimentation, you can remove sanity checks by deleting (comment out) the related lines in file SanityCheck.h

[HendrikJan-5D]

Compeiler problem solved.
Bed leveling works.
And the rotary axes can be controlled via the LCD display.
Thanks for the support.

[HendrikJan-5D]

If I am in the last sent configuration , Marlin-move_rotary_axes_from_LCD
for my BTT TFT 70 Display .
enable.
#define M115_GEOMETRY_REPORT
I get a compiler error.
If I do this for example in Marlin-9axis_PR2 then it works fine.

[DerAndere1]

I have updated the Marlin2ForPipetBot branch. It is currently the most up-to-date branch. The updated example configs for your printer can be found at https://github.com/DerAndere1/Marlin/tree/Marlin2ForPipetBot/config/examples/multi_axis_3D_printer.

• I fixed a bug in the inverse kinematics (See LinuxCNC issue 2435). Direction of rotational axes must follow the convention of RS274NGC / LinuxCNC docs: move of rotational axes in positive direction means that the tool orientation rotates counter-clockwise relative to workpiece when viewed from positive axis end. You might now have to invert the axis direction for some rotational axes in your configs if you want to use tool center point control (TCPC, G43.4).
• XYZBC_HEAD_TABLE kinematics is now renamed to PENTA_AXIS_HT
• I did preliminary hardware tests with the new PENTA_AXIS_TRT kinematics (for 5 axis machines in table/table configuration aka tilting rotary table).
• updated documentation of all features in the README file of the Marlin2ForPipetBot branch

[printercnc]

I detected a very slow g2 g3 movement error on your tcpc branch

[printercnc]

I wonder if anyone has responded to you yet? i just uploaded your latest revision on tcpc branch, i will reconfigure and test g2 g3 movement

[HendrikJan-5D]

No one has yet responded to my TCPC test report.
What I adjusted on advice DerAndere1 is the value of PAX_SEGMENTS_PER_SECOND
In my test I came out at 60.
If you want more information , contact DerAndere1.
He wrote the software.

[printercnc]

I'M FEEDBACK TO DerAndere1, I DON'T KNOW IF THE FEEDBACK HERE IS CORRECT? IT IS NOT RELATED TO THE PROBLEMS YOU MENTIONED, WITH THE SYNTAX G1 X Y Z F , THE AXIS MOVE VERY SMOOTH. WITH THE SYNTAX G2/G3 X Y Z I J F THE AXIS DO MOVE BUT VERY SLOWLY.

[HendrikJan-5D]

Open a new Issue to contact DerAndere1
https://github.com/DerAndere1/Marlin/issues

[DerAndere1]

Hi, I opend a new issue to track the reported bug concerning the feedrate with G2/G3. I hope everyone is doing fine. By the way, open source CAD models of a tilting rotary table or documetation how to build one is difficult to find. If you can share your design under some license like the Creative Commons Attribution License 4.0 or CC-BY-SA 4.0, I would be interested.
Best regards, DerAndere

[printercnc]

I am an engineer specializing in CNC machining. I have many 3D CAD files about 4 and 5 axis rotation mechanisms. I don't know how to send the files to share. It took me months to create a github account, oh so happy, first thing I have to report the problem to you, DerAndere

[CleisonManriqueAguirre]

Hi , this work is more than amazing . I have a question . Is it possible to enable 5axis TRT and a corexy kinematics in your configuration or do I need to write kinematics from zero?

[DerAndere1]

Not possible without programming. You have to add new kinematics that combine the equations for PENTA_AXIS_TRT and CORE

[CleisonManriqueAguirre]

And what about penta_axis_trt and 4 extruders for different colors . Is it possible ? .
Just a random question . Why kinematics is here ?. Actually I was thinking to make a config file but without kinematics . I was planning to add the kinematics in the slicer . Am i wrong ?

[printercnc]

In my opinion, it is not wrong if there is a slicer software that can declare these deviations. CNC multi-axis gcode generator software all do this, the important thing is how good your software construction ability is. i am also trying to communicate with DerAndere1 here #72 to assist him in understanding that it would be better to create a multi-axis simultaneous actuator controller .

[CleisonManriqueAguirre]

Thanks . What about units for the 4th and 5th axis . Are they mm or degrees ? Due to inverse kinematics I guess they must be degrees

[printercnc]

Linear axes are in mm (inches), rotational axes are in degrees. Please learn the dynamics on the branch of DerAndere1
https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics/config

[CleisonManriqueAguirre]

Thanks for the recommendation. I'll follow that

[DerAndere1]

when the previous move involved linear axes and the next move only involves rotational axes (or vice versa), it is recommended to specify feedrate for the next move using G1 F. Take care to properly set DEFAULT_STEPS_PER_UNIT and enable AXIS4_ROTATES as well as AXIS5_ROTATES. Then rotational axes are in deg. More info can be found in the README file

[DerAndere1]

And what about penta_axis_trt and 4 extruders for different colors . Is it possible ? .

PENTA_AXIS_TRT and PENTA_AXIS_HT as well as a config without special kinematics enabled are all compatible with up to 8 Extruders. Branch https://github.com/DerAndere1/Marlin/tree/penta_axis_kinematics is not well tested but should support up to 255 tools (of which the first 8 can be extruders, followed by up to 1 laser, followed by tools for a spindle). You should define HOTEND_OFFSETS_Z for all tools. In My fork, for 4 Extruders you will need #define TOOLS 4 and #define EXTRUDERS 4. There are different config options for tool change mechanisms. In my fork, I improved SWITCHING_TOOLHEAD to be compatible with floor-mounted tool magazins.

Just a random question . Why kinematics is here ?. Actually I was thinking to make a config file but without kinematics . I was planning to add the kinematics in the slicer . Am i wrong ?

for compatibility with commercially available CNC controllers and LinuxCNC. Also, with kinematics in the firmware you reduce the traffic over serial communication, thus you can have smaller segments, i.e. higher resolution and smoother motion.

If you want to let the slicer handle the kinematics, you can disable all kinematics options in the firmware (//#define PENTA_AXIS_TRT, //#define PENTA_AXIS_HT). In that case it is recommended to use https://github.com/MarlinFirmware/Marlin .

If you have your slicer working with kinematics, please share a link. That would be of great value for the community

[CleisonManriqueAguirre]

If I joint both Corexy and 5axis . Do you think ill face a memory allocation problem because of many variables? Just to know in what ill struggle before starting the journey. I am quite new with cpp but ill try

[DerAndere1]

Depends in your Motherboard, but I never Had Problems with memory allocation as far as i am aware of. First Thing I would try ist indeed removing the Offending sanity Check and try to enable both, CORE_XY and PENTA_AXIS_TRT and See what You get. It might work with just minor Code Changes: CORE kinematics are embedded deeply in the Planner, so the Firmware might first do the core kinematics in the Planner and then do the TRT kinematics on top of that

[HendrikJan-5D]

At the end of this YouTube video, multiple axes are controlled using cura.
Is this also applicable to our printer.
https://www.youtube.com/watch?v=gBKsBhFbQNk

[CleisonManriqueAguirre]

While enabling mechanical toolchanger option and sending gcode to extruder 1 or 2 (T1 or T2) it doesn't receive the order to extrude T1 // G0 E1 10 for example . Should I modify some cpp file?

[DerAndere1]

It is great to see that an additional person is working on this. I added Mr. Carpentier's code to my current list of open source projects concerned with CAM software for multi-axis 3D printing:

• https://github.com/marianocarpentier/gcode-modifier
• https://doi.org/10.1145/3550454.3555516, https://github.com/zhangty019/S3_DeformFDM
• https://xyzdims.com/2021/02/08/3d-printing-penta-axis-pax-5-axis-printing-option/
• https://github.com/epit3d/goosli
• https://doi.org/10.1145/3658212, https://github.com/RyanTaoLiu/NeuralSlicer

[printercnc]

I have a new link, I don't know if his code helps, I can't test it because I can't install them.

• https://github-com.translate.goog/epit3d/spycer?_x_tr_sl=en&_x_tr_tl=vi&_x_tr_hl=vi&_x_tr_pto=sc

[DerAndere1]

Yet another multi-axis Gcode generator: https://github.com/jyjblrd/Radial_Non_Planar_Slicer