Marlin-9axis_pull hardware test report Axes 8 and 9 about marlin

[HendrikJan-5D]

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

[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)

[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]

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

I don't think you can solve it with this.
Even then, after homing, the I axis is at -90
And it must be set to 0 before you want to perform bed leveling

---

I configured Marlin-10axis_PR1 with
9axis_PR1_configs.zip (from Support for up to LINEAR_AXES 9 )

Tested
Compilation ok
Problems 2
Hardware printer test ok

See test report
And completely configured zip file

Test report Marlin-10axis_PR1.txt
Marlin-10axis_PR1_9axis test.zip

[DerAndere1]

it would make sense to create a new parameter #define SAFE_POSITIONS { 0, 0, 0, 0, 0, 0 } for the i,j,k, m,o,q axes and move to those positions as part of G28 (with SAFE_HOMING) and as part of G29. I will see what i can do.

[HendrikJan-5D]

That would be nice.

---

I have reduced the existing test configuration to 7 axes.
For my 5D printer
But keep getting the same 2 problem messages.
Does this have anything to do with limit switch names?

[DerAndere1]

Thanks for the test report. The download of different branches as zip from github.com now works again. There was an issue on github and i was wrong thinking that you can only download the default branch. One problem is a deprecation warning. If you obey what the warning message says and change the pin names, that problem should be solved. I do not know what the other problem means:

expression must have a constant value -- cannot call non-constexpr function "strstr" (declared at line 48 of "C:\USERS\JAN.PLATFORMIO\PACKAGES\TOOLCHAIN-GCCARMNONEEABI\ARM-NONE-EABI\INCLUDE\string.h")

Possibly it is due to the fact that I quickly hacked the config and pins file together, by copying your old config file, changing the version number and working around compile errors. Once you configure from scratch, the problem may be gone.

[HendrikJan-5D]

Marlin-10axis_PR1 completely reconfigured

Marlin-10axis_PR1_7axisconfig 2

Compiler errors

configuration.h

1149 #define SOLENOID_PROBE SOL1_PIN
missing this-----------------------+++++++

See problem Screen Shot

See config zip file

Marlin-10axis_PR1_7axisconfig 2.zip

[DerAndere1]

I fixed a bug in the 10axisPR1_branch. You will need current https://github.com/DerAndere1/Marlin/tree/10axis_PR1 from today to compile successfully with LINEAR_AXES 7.

I updated and fixed your configs. Here is the result: https://github.com/MarlinFirmware/Marlin/files/7407013/7axis_configs.zip

[DerAndere1]

Lets try to go to position 0 at the beginning of G29, as requested. Try this (untested):
For 7 axes plus one extruder, In Configuration.h, add

#define SAFE_PROBING_POSITION { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 }

---

In

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

Line 251 in cbc07e4

add the following:

#if defined(SAFE_PROBING_POSITION)
  const xyz_pos_t safe_probing_position = SAFE_PROBING_POSITION;
  do_blocking_move_to(safe_probing_position);
#endif

---

---

Alternatively, try the following: In Configuration.h, add this:

#define SAFE_PROBING_POSITION_X 0.0
#define SAFE_PROBING_POSITION_Y 0.0
#define SAFE_PROBING_POSITION_Z 0.0
#define SAFE_PROBING_POSITION_I 0.0
#define SAFE_PROBING_POSITION_J 0.0
#define SAFE_PROBING_POSITION_K 0.0
#define SAFE_PROBING_POSITION_U 0.0
#define SAFE_PROBING_POSITION_V 0.0
#define SAFE_PROBING_POSITION_W 0.0

---

In

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

Line 251 in cbc07e4

add the following:

#if defined(SAFE_PROBING_POSITION_X)
  current_position.set(
    LINEAR_AXIS_LIST(
      SAFE_PROBING_POSITION_X, SAFE_PROBING_POSITION_Y, SAFE_PROBING_POSITION_Z,
      SAFE_PROBING_POSITION_I, SAFE_PROBING_POSITION_J, SAFE_PROBING_POSITION_K,
      SAFE_PROBING_POSITION_U, SAFE_PROBING_POSITION_V, SAFE_PROBING_POSITION_W
    )
  );
  sync_plan_position();
#endif

[HendrikJan-5D]

Thanks for the support.
In the meantime I had to adjust the hardware configuration.
At the Y axis the 2 stepper motors were connected in series.
This did not work optimally
Now the Y axis has 2 drivers of its own and it works fine.
I did my first 5 d print test.
I'll make a video of this to show you.

And I will test out your suggested changes

[DerAndere1]

Great, I'm looking forward to seeing the video, I updated my solution to the G29 SAFE_PROBING_POSITION in my last comment.

[HendrikJan-5D]

I have tested both change proposals.
SAFE_PROBING_POSITION
See test report:

Test report G29 change.txt

[DerAndere1]

the output of M503 (M906 I1 Y1500) is correct.
In case of M506 and M569, parameter I means: "Index for dual steppers. Use I1 for X2, Y2, and/or Z2".

Lets try to fix the solution for SAFE_PROBING_POSITION: Revert the changes and try the following:
In Configuraton.h, add

#define SAFE_POSITION_HIGH { 20.0, 20.0, 100.0, 0.0, 0.0, 0.0, 0.0 }
#define SAFE_PROBING_POSITION { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 }

and in Configuration_adv.h, enable DEBUG_LEVELING_FEATURE
and in

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

Line 251 in cbc07e4

add the following:

#if defined(SAFE_PROBING_POSITION)
  const xyz_pos_t safe_probing_position_high = SAFE_PROBING_POSITION_HIGH;
  const xyz_pos_t safe_probing_position = SAFE_PROBING_POSITION;
  do_blocking_move_to(safe_probing_position_high);
  do_blocking_move_to(safe_probing_position);
#endif

Test gcode:

M502
M500
M111 S38
G28
G1 X15 Y15 Z80 A10 B10 C10 U10
G29

With these changes, I expect that at the beginning of G29, the machine will first raise to Z100, then goes to position X20.0 Y20.0 Z100.0 A0.0 B0.0 C0.0 U0.0 and then to X0.0 Y0.0 Z100.0 A0.0 B0.0 C0.0 U0.0, then lower to Z0, then start probing. If that does not work, change to #define SAFE_PROBING_POSITION { 0.0, 0.0, 10.0, 0.0, 0.0, 0.0, 0.0 } to prevent grinding into the bed.

[HendrikJan-5D]

I have copied your changes into the files.
But get a compiler error.
Am I doing something wrong?

[DerAndere1]

In the modified G29.cpp

  const xyz_pos_t safe_probing_position_high = SAFE_PROBING_POSITION_HIGH;

was my typo. It has to be

  const xyz_pos_t safe_probing_position_high = SAFE_POSITION_HIGH;

---

Also, in
https://github.com/DerAndere1/Marlin/blob/10axis_PR1/Marlin/src/module/motion.cpp#L500
Add the following:

  #if LINEAR_AXES >= 4
    const feedRate_t i_feedrate = fr_mm_s ?: homing_feedrate(I_AXIS);
  #endif
  #if LINEAR_AXES >= 5
    const feedRate_t j_feedrate = fr_mm_s ?: homing_feedrate(J_AXIS);
  #endif
  #if LINEAR_AXES >= 6
    const feedRate_t k_feedrate = fr_mm_s ?: homing_feedrate(K_AXIS);
  #endif
  #if LINEAR_AXES >= 7
    const feedRate_t u_feedrate = fr_mm_s ?: homing_feedrate(U_AXIS);
  #endif
  #if LINEAR_AXES >= 8
    const feedRate_t v_feedrate = fr_mm_s ?: homing_feedrate(V_AXIS);
  #endif
  #if LINEAR_AXES >= 9
    const feedRate_t w_feedrate = fr_mm_s ?: homing_feedrate(W_AXIS);
  #endif

---

Also, in

Marlin/Marlin/src/module/motion.cpp

Line 570 in cbc07e4

Add the following:

    #if LINEAR_AXES >= 4
      current_position.i = i;
      line_to_current_position(i_feedrate);
    #endif
    #if LINEAR_AXES >= 5
      current_position.j = j;
      line_to_current_position(j_feedrate);
    #endif
    #if LINEAR_AXES >= 6
      current_position.k = k;
      line_to_current_position(k_feedrate);
    #endif
    #if LINEAR_AXES >= 7
      current_position.u = u;
      line_to_current_position(u_feedrate);
    #endif
    #if LINEAR_AXES >= 8
      current_position.v = v;
      line_to_current_position(v_feedrate);
    #endif
    #if LINEAR_AXES >= 9
      current_position.w = w;
      line_to_current_position(w_feedrate);
    #endif

[DerAndere1]

In your Configuration.h, the following

#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE

looks wrong. the value of X_MAX_POS (and similarly Y_MAX_POS) should be high enough to allow moving the tool almost to the physikal x travel limit, but not more. You have bed center at 0,0, X_MIN_POS -173 and #define X_BED_SIZE 220. Suppose your X axis frame is slightly more than 300 mm long. Your x endstop switch is at position -173mm, so at max, the axis could physically go to position 133. then you should set something between #define X_MAX_POS 110 (half the bed size) and #define X_MAX_POS 133

[HendrikJan-5D]

Test report Safe Probing Position.txt

[DerAndere1]

You should ensure that a sheet of paper fits between tool and bed after

G28
G1 X0 X0 Z0 A0 B0 C0 U0

If you tool jams into the bed at position 0, you have to do one of the following:

• build a bed that sits on springs so that its hight can be adjusted manually with screws

• mount your physical z min endstop switches slightly higher
  An alternative method woud be:

• change Z_MIN_POS to a negative value (if your limit switch sits approx. 10 mm below the bed, start with Z_MIN_POS -20), send

M502
M500
G28
G1 X0 X0 Z0 A0 B0 C0 U0

, then determine the exact distance between tool and bed (lets assume you measure 9 mm) then adjust Z_MIN_POS accordingly (in this example, change it to the result of -20 - (- 9) , that means you would need Z_MIN_POS -11).

---

In all cases, another helpful setting you can try to enable is the following.

#define Z_AFTER_HOMING  10      // (mm) Height to move to after homing Z

This should prevent scratching the tool along the bed with vertical moves after homing like

G28
G1 X20 Y20 Z0

[HendrikJan-5D]

I know the alignment procedure for the bed.
And it works fine with my well-aligned bed.
But is it necessary for the z axis to go all the way to 0 before leveling?
This also does not happen with normal bed leveling .
Z after homing doesn't work for me.
Because I home Z to the max position.
Similar to a delta printer.
This is also used in CNC milling.

[DerAndere1]

Yeah, from the video I should have seen that you know what you are doing ;D - Wow. 5D print :-))))))))))))) Amazing work, congrats!

Was it a manually written gcode script, or did TU Delft come up with something? When you feel like you want to share information with the public, I can help documenting your progress and/or publishing info online. I have some experience with choosing a license and so on, just ask me.

But is it necessary for the z axis to go all the way to 0 before leveling?
This also does not happen with normal bed leveling .
Because I home Z to the max position.

Z home to max is a good decision for your setup, indeed and in that case Z_AFTER_HOMING is not necessary.
In the 10axis_PR1 branch I have now implemented a solution that should work for all bed leveling methods. The relevant change set was this commit: d7f8d07#diff-6a6786c59c62c9ee2983ef565565fcd779791a9006d2e8f2e348572f637e5cd2

You can use your existing cofiguration files with it. In Configuration_adv.h you can now set the following:

/**
 * Safe bed leveling start coordinates. If enabled, the respective axis is moved to the specified position at the beginning of the bed leveling procedure.
 * Required e.g. with LINEAR_AXES >= 4, if Z probe is not perpendicular to the bed after homing.
 * Values must be chosen so that the bed is oriented horizontally and so that the Z-probe is oriented vertically.
 */
//#define SAFE_BED_LEVELING_START_X 0.0
//#define SAFE_BED_LEVELING_START_Y 0.0
//#define SAFE_BED_LEVELING_START_Z 0.0
#define SAFE_BED_LEVELING_START_I 0.0
#define SAFE_BED_LEVELING_START_J 0.0
#define SAFE_BED_LEVELING_START_K 0.0
#define SAFE_BED_LEVELING_START_U 0.0
//#define SAFE_BED_LEVELING_START_V 0.0
//#define SAFE_BED_LEVELING_START_W 0.0

With this, only the axes for which the feature is enabled should move to the specified safe start coordinate at the beginning of G29. Depending on the needs of your machine, you may have to use other values than 0.0 for some axes. If you still witness crashing into the bed, try to decrease the value of Z_MAX_POS slightly.

[HendrikJan-5D]

Thank you for your nice comment.
I'm making a PowerPoint presentation with YouTube film about my 7 Axis 5D printer.
For our Hcc!3D group.
I also want to use this as an introduction to companies that are developing slicer software.
With the request if I can test their software with my printer.
It was also the intention to make it public at a fair and to invite you to this.
However, due to the covid situation, it was not possible to organize this.
At the moment I don't feel like promoting it public.
Takes me too much time, which I prefer to spend on new developments.
+++
The G code script was manually manipulated.

[DerAndere1]

the presentation and reaching out to slicer developers is a good idea. I was just worried that your work would be a once-only effort. But if you make some information available to your group members, that's good news. In case you have no financial interest in the subject, let your group members know if/how they can get access to the bill of materials or 3D models for the required parts to build the robot. Those can be a time saver for them when they want to join your efforts and push the limits of 3D printing. have a nice evening.

[HendrikJan-5D]

I have completely reconfigured the latest version of Marlin-10axis_PR1.
Because my old config files are out of date.
I run into a compilation problem.
See screen copy,
Would you like to see what the cause is

Marlin-10axis_PR1_7axisconfig 5.zip

[DerAndere1]

The 10axis_PR1 branch is still missing the fix for upstream Marlin issue 22887 as long as the final rebase/merge is not completed. As a work around, do the following: In Configuration.h

#define SOLENOID_PROBE SOL1_PIN

change that to

#define SOLENOID_PROBE
#define HAS_SOLENOID_1 1 // workaround for https://github.com/MarlinFirmware/Marlin/issues/22887

With that change I could compile your latest config.

[DerAndere1]

One general warning: Marlin is still not officially supporting rotational axes. Thus, the speed of each stepper is calculated from the specified feedrate as if all axes were linear (I believe the method for interpreting feedrate is called "multidimensional linear interpolation"). Thus, when the tool is in contact with the workpiece and X, Y and/or Z are different from 0, you have to set a lower feedrate before moving the rotational axes to account for the radius of the workpiece. Otherwise, the actual surface speed of the tool along the workpiece surface is too high. To properly support rotational axes, I guess the firmware has to calculate stepper speeds differently, depending on your inverse kinematic model. The most relevant section in this regard is probably https://github.com/MarlinFirmware/Marlin/blob/fa5bfca3678ef6e695e8e5d4a51af2bcd02e8e85/Marlin/src/module/planner.cpp#L2080-L2111. Note to myself: Other sections relevant for kinematics can be found from the merge that added DELTA inverse kinematics: MarlinFirmware@373f3ec. For more info regarding reverse kinematics, see
https://xyzdims.com/2021/02/08/3d-printing-penta-axis-pax-5-axis-printing-option/ . We have to see if te author of that article will eventually publish his modified RRF firmware at his github repo at https://github.com/Spiritdude/RepRapFirmware

[HendrikJan-5D]

Thanks for the info.

Still, the safe probing is not going well.

I have entered the following test values

At G29 goes

Axis A ---> 90
Axis B ----> 0
Axis C ----> 0
Axis U ----> 100

Then the Axes A and U go to 0
And start the actual bed leveling

See the log report.

Test.report.Safe.Probing.Position 2 .txt

---

I also want to report an older problem that has I not yet been reported to you.
From the Z axis, the HOMING_BUMP_MM function does not work.
The Z axis stops immediately at the limit switch.

[DerAndere1]

Thanks for testing other values than 0. Otherwise I wouldnt have seen that bug. I hope it does not move the IJKUVW axes to 0 anymore when you try this change:

Marlin/Marlin/src/module/probe.cpp

Line 768 in a8eae7a

xyz_pos_t npos = { rx, ry, TERN(DELTA, _MIN(delta_clip_start_height, current_position.z), current_position.z) };

change that to

  xyz_pos_t npos = LINEAR_AXIS_ARRAY(
    rx, ry, TERN(DELTA, _MIN(delta_clip_start_height, current_position.z), current_position.z),
    current_position.i, current_position.j, current_position.k,
    current_position.u, current_position.v, current_position.w
  );

For the issue with HOMING_BUMP_MM, i will try to reproduce on my machine. Maybe it is an isssue with one of your z limit switches (see MarlinFirmware/Marlin issue 20406 "[BUG] Homing bump doesn't work if both Z_MIN and Z_MAX enabled"). You can find out if one of your z endstops is triggering wrongly by enabling PINS_DEBUGGING in Configuration_adv.h and sending M43 E1 before homing. (https://marlinfw.org/docs/gcode/M043.html)

[HendrikJan-5D]

I copied your change to probe.cpp.
And enter the following values for test.

//#define SAFE_BED_LEVELING_START_X 0.0
//#define SAFE_BED_LEVELING_START_Y 0.0
//#define SAFE_BED_LEVELING_START_Z 0.0
#define SAFE_BED_LEVELING_START_I 45.0
#define SAFE_BED_LEVELING_START_J 45.0
#define SAFE_BED_LEVELING_START_K 45.0
#define SAFE_BED_LEVELING_START_U 45.0
//#define SAFE_BED_LEVELING_START_V 0.0
//#define SAFE_BED_LEVELING_START_W 0.0

Under these circumstances, the actual probing cannot take place.
But everything now works as expected.
The problem is solved.
If I set the values for I-J-K-U to 0, the bed leveling goes well.

See picture:
All four axes are rotated 45 degrees here and the probe is activated.

The HOMING_BUMP_MM issue has also been resolved.
I had activated the Z min plug.
This one was not connected

//#define USE_ZMIN_PLUG

Another general question.
This question keeps popping up in VisualStudio.

Do you want to install the recommendation extensions for C++ ?

Do I need to install this??

[DerAndere1]

That's great. I will apply the same fix in the 10axis_PR1 branch.

Do you want to install the recommendation extensions for C++ ?

No, those exensions are meant to make developing software in C++ a bit easier, but if you use VisualStudio only for configuration and compiling, you don't need them.

[HendrikJan-5D]

On your wiki page you can add the following tested parts.
Two stepper drivers per Axis (applied for the Y Axis)
#define AUTO_BED_LEVELING_LINEAR ( this is what I'm using now )

To cool the stepper drivers on the motherboard I connected a fan to the FAN2_PIN.
The extension board BTT M5 also has step drivers and connectors for extra fans.
Is it possible to control 2 PIN addresses with
#define CONTROLLER_FAN_PIN.
e.g. FAN2_PIN and FAN3_PIN

see print screen Configuration.adv.h

[DerAndere1]

I've added those to the wiki. I only plan to list features that have to do with axes in the wiki, so I won't mention the fans. It's never the less nice that you manage to improve your machine with additional features. In the meantime opened a feature request: Marlin firmware issue "[FR] rotational axes with feedrate calculation like in NIST RS274 NGC Interpreter - version 3" at:

https://github.com/MarlinFirmware/Marlin/issues/23116

Do you think that the proposed interpretation of feedrate is in accordance with industry standard multi axis CNC machines?

[HendrikJan-5D]

I have no knowledge of this complex matter.
So far I have configured the axes I - J - K - U in degrees.
And also controlled in degrees via G codes, which worked well until now.
Because all axes arrived at the same time at the end coordinate.

[HendrikJan-5D]

DerAndere1.

This for your information.

About multi Axis slicer software.
I received this from Guoxin Fang / TU Delft.

I also send you a poster which has been published by Hcc!3d.
However, this information is in Dutch.

Info Tu + Poster.zip

[DerAndere1]

That is very very good news. and the poster looks great. Thanks for contacting TU Delft! I spread the word about Guoxin Fang's slicer toolchain in the Marlin developer's communication channel on discord.
In the mean time I fixed another bug related to INCH_MODE_SUPPORT. Also, I verified your observation: the DEFAULT_MAX_FEEDRATE correctly limits the feedrate of multi-axis moves. The latest version can be obtained from https://github.com/DerAndere1/Marlin/tree/9axis_PR2. If you also need CONTROLLER_FAN2_PIN, I am preparing a new release of Marlin2ForPipetBot at https://github.com/DerAndere1/Marlin/tree/Marlin2ForPipetBot_edge . Would be great if you could test that branch with the attached updated configs for your printer. Here is a g-code script to test things:

G1 X50 Y50 Z50 A0 B0 C0; safe position
G91; incremental movement mode
G20; inch mode
G1 A4; rotates 4 degrees
G1 B4
G1 C4
M114
G1 A41 F3600; rotates A axis another 41 degrees at a feedrate of 3600 degrees per minute
G1 X2 A-20 F10; moves X axis 2 inches at a feedrate of 10 inches per minute. Simultaneously rotates A axis 20 degrees back
M114
G21; back to sanity with metric mode
G1 A-2; rotates 2 degrees back
G1 B-2
G1 C-2
M114
G90; absolute movement mode

Marlin2ForPipetBot_HendrikJan-5D.zip

[HendrikJan-5D]

Test report

Marlin 9axis_PR2 and
Marlin2ForPipetBot_edge
I tried to compile both branch with pre configuration
Marlin2ForPipetBot_HendrikJan-5D
Which gave all kinds of compeiler errors.
Then I reconfigured both branches.

I can't run your suggested test in either branch
In inch mode, it does not go well.
Below is a test report of 2 degrees of rotation

G1 X50 Y50 Z50 A0 B0 C0
SENDING:G1 X50 Y50 Z50 A0 B0 C0
G91
SENDING:G91
G20
SENDING:G20
G1 A2
SENDING:G1 A2 -------> rotates to 50.80 degrees
G1 B2
SENDING:G1 B2 ------->rotates to 50.80 degrees
G1 C2
SENDING:G1 C2 ------->rotates to 50.80 degrees
M114
SENDING:M114
X:50.00 Y:50.00 Z:50.00 A:50.80 B:50.80 C:50.80 U:0.00 E:0.00 Count X:8000 Y:8000 Z:80000 A:45156 B:45156 C:72249 U:0

Marlin-9axis_PR2-test.zip

[DerAndere1]

I have updated Marlin2ForPipetBot and will now maintain configs for your setup as an example for a multi axis printer at https://github.com/DerAndere1/Marlin/tree/Marlin2ForPipetBot/config/examples/multi_axis_3D_printer/HendrikJan-5D. Let me know whenever you have suggestions for changes.

[HendrikJan-5D]

I have looked at the configs.
These are in order.
I use this version but then modified with the Fan 2 function.
Which I will send along as a complete zip file.

In the meantime I have done some hardware testing and manual slicer testing.
I ran into a possible problem of bed leveling.
If I have done a bed leveling.
And then turn the bed for example 90 degrees around.
Turns the bed 90 degrees.
But according to me, the measured bed level pattern remains still.
And this should also rotate.
I'm still not quite out.
What is your vision on this.

I also played a little with the joystick function in Marlin.
It is very difficult to set and poorly documented.
I have a hopefully better joystick on order at Aliexpress.
Would this be something to extend this function to 9 Axis.
To e.g. apply in a robot arm configuration.

Marlin-9axis_PR2-7axisconfig Fan2 Pin.zip

[DerAndere1]

Turns the bed 90 degrees.
But according to me, the measured bed level pattern remains still.

Currently bed leveling only does the right thing if the rotational axes are in neutral position. IMHO, to do the right thing in case of rotated axes, one has to implement kinematics for your machine in the firmware. bed leveling has to be applied to the Z axis in cartesian space and then inverse kinematics have to applied to calculate the corrected joint (motor) positions. When the axis of rotation for the bed lie at the shafts of motors A and B, then the bed levelling data must be rotated when the A and B axes but not when other axes are moved. In other machines, the bed may not rotate around the same motor axes. This is handled by kinematics.

I have a hopefully better joystick on order at Aliexpress.
Would this be something to extend this function to 9 Axis.

Not sure how control of more than 2 axes with a joystick is typically handled. Most boards don't even have enough ADC (analog pins) to read more inputs. You might be better off just to connecting your joystick to a SOC (e.g. raspberry pi). Then write a host application that reads joystick inputs and sends G1 commands to your liking. Here is how to read joystick input into a wx.Python app: https://gist.github.com/robsears/3943374 . G code sending could be handled by the pronterface library or by mecode

[DerAndere1]

A workaround for the missing kinematics in Marlin would be to perform the bed probing with G29, then disable bedleveling in firmware with M420 S0 and send the bed leveling mesh data to the host software with G29 S0 or M420 V1. Then use that data in the post processor / slicer. Not a good solution, IMHO.

[DerAndere1]

9 axis support was merged into upstream MarlinFirmware/Marlin. I will maintain the Marlin2ForPipetBot fork which in addition has support for the second controller fan pin. I close this thread because it is no longer focussed on a single subject. whenever there is something to discuss, please open seperate issues (one per topic) at https://github.com/DerAndere1/Marlin/issues. Happy printing!

[Eljanaliyev]

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

hello dear. Sorry I didn't read all discussion. hopefully your problem has been solved. would you please tell me the name of stepper motor library if you use one.
I am working on a project which has 6 stepper motor( one for each axis) I have to be able to drive them at the same time with different direction or speed.
On arduino IDE accelstepper library is brilliant for such projects.
But I have to use Raspberry pi 3B+ for my project because I will need some other opportunities. and I will code in C/C++ programming language. if I'm not mistaken you code in C++ in this project. and you have used stepper motors. Do you use any library for Stepper motors?
I have been started learning Python. Because i haven't find good stepper motor library for such project in C/C++.

[HendrikJan-5D]

Hello,
Marlin does not use a stepper motor library like accelstepper.
Marlin is a uiniversal applicable program that can control stepper motors simultaneously using G codes.
To program this yourself is a very difficult job.
I would use Marlin with an arduino board e.g. Bigtreetech GTR V1.0
and then control it through your Raspberry pi program.

[Eljanaliyev]

Hello. Thank you to reply my email. I got it. But I have to create all program by myself. There are some good stepper motor libraries but they are in Python language. I have no enough experience with python and I am bad at it. I have to find a stepper motor library in C/C++ language. Or I have to find out another solution for my project. Actually I have found one. To control stepper motors with 2 esp32. And create serial port between raspberry pi and they. But it is still expensive for me. it is my last choice. Thank you dear. Have a good day. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: ***@***.***> Sent: 07 May 2022 11:47 To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [DerAndere1/Marlin] Marlin-9axis_pull hardware test report Axes 8 and 9 (#55) Hello, Marlin does not use a stepper motor library like accelstepper. Marlin is a uiniversal applicable program that can control stepper motors simultaneously using G codes. To program this yourself is a very difficult job. I would use Marlin with an arduino board e.g. Bigtreetech GTR V1.0 and then control it through your Raspberry pi program. — Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYTKTGUJZQXAIQGHYGAWFVTVIYNYLANCNFSM5CYN6TMQ>. You are receiving this because you commented.Message ID: ***@***.***>

[DerAndere1]

the BTT Octopus boards are another example of a suitable board that Supports 6 Stepper drivers. 2x ESP32 sounds like over-Engineering. I would choose a Board with a Single 32 Bit microcontroller that has enough Pins to Control 6 Stepper Drivers. Preferrably, its main microcontroller is Supported by your favourite software framework (e.g. Zephyr, CMSIS, mbed, STcube HAL, or Arduino libraries). Have a Look at the Library Collections and User Forums for these Frameworks. The PlatformIO
IDE has a Built-in Library Manager with search Funktion

[DerAndere1]

I would ask your supervisor, if it is ok if you put a microcontroller between Raspberry pi and stepper drivers. If it is not allowed, ask your supervisor if it is ok to use GPL licensed code and publish your code under the GPL license. In that case you can reuse Marlin code. Support for Raspberry pico is work in progress, see pull request 24042 "Support for RP2040 and BTT SKR Pico (WIP)" at https://github.com/MarlinFirmware/Marlin/pulls

[Eljanaliyev]

Hello again. I am sorry to reply you late. I am a student on master degree. And I am making 6 axis robot arm for dissertation. I haven’t planned all process. Because the dead line is in next year. But I am working on it. First I tried Arduino mega as a microcontroller and it worked enough for me. But when I was sending data from computer to Arduino via serial port I realised that Arduino stops the part of programming that control motors and goes serial communication part of program. I have mentioned this at last email. And I thought I need a controller that can do multitasking and there are some other tasks that I will need when time goes. Like camera control, perhaps Artificial intelligence, display, touchscreen ect. I want to control that robot without connecting to computer. That is why I want to use raspberry pi. But programming side is also hard for me right now. Because of I haven’t planned it. Right now exams are important for me. Therefore I will work on project after a month. I also want to create a software that can help me to create G-code and a program that can create moving from G-code. There are to many problems to solve. Thank you for your advices and help. Hopefully I will continue this project after a month. In my opinion I will contact you again. Or when I will finish my project I will inform you. You don’t have to reply this email. Thank you dear. Have a good day... Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: ***@***.***> Sent: 12 May 2022 18:03 To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [DerAndere1/Marlin] Marlin-9axis_pull hardware test report Axes 8 and 9 (#55) I would ask your supervisor, if it is ok if you put a microcontroller between Raspberry pi and stepper drivers. If it is not allowed, ask your supervisor if it is ok to use GPL licensed code and publish your code under the GPL license. In that case you can reuse Marlin code. Support for Raspberry pico is work in progress, see pull request 24042 "Support for RP2040 and BTT SKR Pico (WIP)" at https://github.com/MarlinFirmware/Marlin/pulls — Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYTKTGQLQ36HHGENJ6DDTC3VJUFSRANCNFSM5CYN6TMQ>. You are receiving this because you commented.Message ID: ***@***.***>

[DerAndere1]

A fast single core, 32 bit microcontroller is definively enough to control 6 steppers and perform serial communication as demonstrated by Marlin and other firmwares for 3D-Printers / CNC controllers. It should be possible to fix your existing program. Have a look at https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/module/stepper.cpp, and the files starting with serial* at https://github.com/MarlinFirmware/Marlin/tree/2.0.x/Marlin/src/core and have a look at the developer documentation at https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x/docs . But first, good luck with your exams!

[Eljanaliyev]

Thank you Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: ***@***.***> Sent: 12 May 2022 20:09 To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [DerAndere1/Marlin] Marlin-9axis_pull hardware test report Axes 8 and 9 (#55) A fast single core, 32 bit microcontroller is definively enough to control 6 steppers and perform serial communication as demonstrated by Marlin and other firmwares for 3D-Printers / CNC controllers. It should be possible to fix your existing program. Have a look at https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/module/stepper.cpp, and the files starting with serial* at https://github.com/MarlinFirmware/Marlin/tree/2.0.x/Marlin/src/core and have a look at the developer documentation at https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x/docs . But first, good luck with your exams! — Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYTKTGSNQAT4CQEAT7PKIGLVJUUKFANCNFSM5CYN6TMQ>. You are receiving this because you commented.Message ID: ***@***.***>

[DerAndere1]

Reopened. In my kinem2 branch, I have integrated inverse kinematics for 5 axis machines with a swivel head (B axis) and a rotating table ( C axis). This allowed me to add commands G43.4 and G43.9 to enable/disable rotational tool center point (TCP) control. If you are interested, you need to enable the new option XYZBC_HEAD_TABLE, and configure exactly 5 axes: XYZ, I (B axis) and J (C axis). Also, configure these new settings;

Marlin/Marlin/Configuration.h

Lines 1017 to 1027 in 8848649

	// For a 5 axis CNC machine in Head-Table configuration.
	// This machine has a swivel head (B axis parallel to the Y axis) and a horizontal rotary
	// table (C axis parallel to the Z axis).
	//#define XYZBC_HEAD_TABLE
	#if ENABLED(XYZBC_HEAD_TABLE)
	#define TOOLS 1 // Number of tools;
	// Machine rotary zero point offset is the distance between the center of rotation of the B axis to the gauge line at the tool head.
	#define DEFAULT_MRZP_OFFSET_MM 100.0 // (mm)
	#define XYZBC_SEGMENTS_PER_SECOND 200
	#endif

For a printer with a single nozzle, you may set DEFAULT_MRZP_OFFSET_MM to a value that equals the distance between shaft of the B axis and the nozzle tip in mm.

[HendrikJan-5D]

Great to hear from you again.

I have some questions before going into the configuration.
Is it still possible to control Axis 6 and 7 with G codes.
This to put the B Axis and the Bed in the right start position
And also the automatic bed leveling function.
Also concerning the new function for the B Axis
If I turn the B Axis, for example by 45 degrees, is the Z Axis height also automatically adjusted.
( see drawing )

Meanwhile, I made my 7 Axis 5D printer story public on YouTube.
To which I got a lot of positive reactions.

https://youtu.be/_r7DA78GrXg

[DerAndere1]

Is it still possible to control Axis 6 and 7 with G codes.

Currently not. it will result in compile errors if you try to configure anything with more than X,Y,Z,I(B),J(C) axes. You will have to bring axes 6 and 7 into neutral position manually before starting the newly configured machine. If you need it to be able to test, I can add the ability to compile and auto-home additional axes 6 and 7. Note that while using TCP (G43.4), additional axes 6 and 7 must stay in neutral position.

If I turn the B Axis, for example by 45 degrees, is the Z Axis height also automatically adjusted.

When configured correctly and TCP enabled (G43.4), when you move rotational axes B or C, XYZ motors should compensate so that the tool tip stays at the programmed XYZ position relative to the bed. In default state (TCP off, G43.9), no compensation occurs and axis positions in G-code directly represent motor positions ("joint space").

For correct configuration, set DEFAULT_MRZP_OFFSET_MM 150 (assuming the distance between tool tip and B axis motor shaft is 150mm when all axes are in neutral position). You may have to enable HOTEND_OFFSET_X/Y/Z and set it to { 0 }. Also, configurethe machine so that in neutral position I axis (B) is parallel to Y and J axis (C) is parallel to Z.

And also the automatic bed leveling function.

Bed leveling still does not work as intended when rotational axes are not in neutral position. In the long run, the plan is to make automatic bed leveling account for the kinematics, TCP is the first step towards that goal.

I tested as good as I can and tried to make the machine abort when geometric limits are reached, but better be safe than sorry: test carefully and be ready to push the kill switch.

[HendrikJan-5D]

Manually moving the bed into position is not a problem.
But my printhead is rotated 90 degrees wrong.
It is possible, but manually difficult to bring it into the correct test position.

[DerAndere1]

For initial testing a hack would be to plug motor for the 6th axis into B axis driver. Then send G1 B until the printhead is in the desired position. Then unplug 6th axis motor and plug B axis motor back into B axis driver. Then home the machine with G28.... I will let you know after I made things more convenient for you. I try to do it today.

Last week I was contacted by a developer from another project who is interested in collaborating on multi-axis printing. I mentioned you as someone with knowledge in hardware. Maybe there will be a chance to start a discussion involving contributors from different projects, I will let you know. I may end up porting my code to other firmwares. So any testing is appreciated.
Here are some useful links:

https://github.com/FreddieHong19/Open5x
https://github.com/epit3d/spycer

[DerAndere1]

If you have interests that conflict with those of Open5x, please let me know (here or non-publicly via https://gitlab.com/contact_derandere/contact_derandere by marking an issue as confidential) . I would then pause collaboration with them. Thanks.

[HendrikJan-5D]

I am very disappointed that Open5x FreddieHong19 has removed me from his GitHub platform.
I offered him all the knowledge and info with videos to move forward together.
He was definitely shocked that I am mechanically further with my printer than him .
And immediately removed everything from his platform, so others couldn't see where I was working on.
I think it's a shame that some students don't understand that you only get further by working together.

[DerAndere1]

Oh, I had no clue that that was the case. Good that I asked. This situation is unfortunate. But, as you already pointed out, it seems to be a result of his scientific ambitions, not because he is a bad guy per se. I know the pressure one feels as a student. I get that from your side there is no problem regarding sharing knowledge. I hope Mr. Hong can convince himself that the biggest breakthrough will be automatic tool path generation and that he has not much competition in that area.

[HendrikJan-5D]

What I was referring to was a Dutch company that mentioned they had developed a 5 Axis slicer.

[DerAndere1]

well, there are a couple of companies with closed source 5 axis slicers / CAM software (dotxcontrol came up in my search results recently, then there is Autodesk Fusion 360 or Powermill, Siemens NX Multi-Axis Deposition, ...) but everyone is looking for an open source solution. The Readme file of Open5x says that they are planning to add a slicer to their repository...

[HendrikJan-5D]

I am working on the configuration.
And miss #define NUM_AXES 5
Is this setting expired.
Also a picture of the hardware test setup.
Is this correct

For this test, I will have to remove the object fan first.
Can be mounted in another place later.

[DerAndere1]

If that photo is taken from the front of the printer, looking along the Y axis, your hardware configuration looks good.
NUM_AXES should be removed from the config and will be ignored. If you compile with #define NUM_AXES 5 you will trigger this informative warning:

Marlin/Marlin/src/inc/Warnings.cpp

Line 39 in 8848649

#warning "Note: NUM_AXES is now based on the *_DRIVER_TYPE settings so you can remove NUM_AXES from Configuration.h."

I forgot to mention the following new interesting options. (Here the recommended defaults):
To enable and set a (default) angular feedrate for all rotational-only G0 moves:

//#define G0_ANGULAR_FEEDRATE 2700 // (°/min)

and

#if HAS_ROTATIONAL_AXES
  #define DEFAULT_ANGULAR_MINIMUMFEEDRATE   0.0     // (°/s) Minimum feedrate for rotational-only moves. Set with M205 P.
  #define DEFAULT_ANGULAR_MINTRAVELFEEDRATE 0.0     // (°/s) Minimum travel feedrate for rotational-only moves. Set with M205 Q.
#endif

and

#if ENABLED(AXIS4_ROTATES)
  #define DEFAULT_ANGULAR_ACCELERATION        3000  // I, J, K acceleration for rotational-only printing moves
  #define DEFAULT_ANGULAR_TRAVEL_ACCELERATION 3000  // I, J, K acceleration for rotational-only travel (non printing) moves
#endif

[HendrikJan-5D]

I had taken the picture from the right side.
Looking along the X axis.
Rotated the print head and took a picture from the front.
Looked along the Y axis.

Your newly listed options are they already implanted in the latest version of kinem2 ?

[DerAndere1]

Ok. starting with the setup in the last photo, the axis that tilts the tool head should be the I (B) axis. The motor that rotates the bed around the vertical axis should be the J (C) axis. The motor that rotates the toolhead around the vertical axis should not be controlled and stay fixed in this position. The motor that tilts the bed should also not be controlled.

All mentioned options can be found in the config files of the kinem2 branch: See https://github.com/DerAndere1/Marlin/blob/kinem2/Marlin/Configuration.h and https://github.com/DerAndere1/Marlin/blob/kinem2/Marlin/Configuration_adv.h

[HendrikJan-5D]

I filled in the new configuration.
But get an error message.
All the info is in the folder.
See what I did wrong

compiler error.zip

[DerAndere1]

I was able to compile with your configs after the following fix:

Marlin/Marlin/src/module/motion.h

Line 243 in 8848649

#if EITHER(HAS_HOTEND_OFFSET, HAS_TOOL_LENGTH_COMPENSATION)

change that line to

  #if HAS_HOTEND_OFFSET

Also:

Marlin/Marlin/src/module/motion.cpp

Line 963 in 8848649

#if EITHER(HAS_HOTEND_OFFSET, HAS_MULTI_TOOLS)

change that line to

  #if HAS_HOTEND_OFFSET

and third:

Marlin/Marlin/src/module/motion.cpp

Line 1012 in 8848649

#elif EITHER(HAS_HOTEND_OFFSET, HAS_TOOL_LENGTH_COMPENSATION)

change that line to:

  #elif HAS_HOTEND_OFFSET

[DerAndere1]

I think we resolved the issue about the deleted comments in the Open5x repo. It seemed to be a misunderstanding/ lack of communication. I was told that Freddie moved the information you provided to the document "Other_works.md".

The plan is to integrate kinematics into RepRapFirmware and improve support for the Open5x printer. I wait for Jörg Schnur to finish implementation of a kinematics framework for RepRapFirmware (RRF) at https://github.com/JoergS5/RepRapFirmware/tree/3.5-dev and get his advice on how to use it. If I find enough time, Duet3D will send me one of their boards and try to make it work on an improvised test rig.

If you are interested, I could then try to configure Jörg's RRF for your printer and send you the Duet3D control board with pre-configured RRF for further testing on your machine.

[HendrikJan-5D]

Good to hear that the poor contact with Open5x was based on a misunderstanding.
Regarding the offer to test RepRap firmware on my printer.
I do not want to do this, because the wiring has to be changed completely.
And I have not enough time for that in the near future.

[HendrikJan-5D]

(Thank you for your positive response.)

I have loaded the firmware into the printer.
Homing ok.
In a test with G43.4 the Y axis hopped.
Emergency stop used.
What I noticed without the G43.4 function.
At G0 X0 Y0 B90 seems good
At G0 X0 Y0 B45 the X and Y axes stop momentarily on the way.
At G0 X0 Y0 B20 this can be seen even better.
See the movie in the hardware test folder.

Hardware testmap 1.zip

[DerAndere1]

Try to increase XYZBC_SEGMENTS_PER_SECOND as well as DEFAULT_IJERK and possibly DEFAULT_XJERK, DEFAULT_YJERK. If that does not help, increase values of DEFAULT_MAX_ACCELERATION and DEFAULT_TRAVEL_ACCELERATION. Verify that hotend offsets are enabled and set to 0. For a little more safety, enable ENDSTOPS_ALWAYS_ON_DEFAULT in Configuration_adv.h

Does the yump in the y axis happen if the nozzle points down vertically (B axis in "neutral" 0 position) ?

[HendrikJan-5D]

I have tested out all your suggestions.
It only reinforces the picture of the stuttering X and Y Axis.
Before testing the G43 godes I think it would be wise to solve this problem first.
If the X , Y , and B axes are operated independently of each other , everything is fine.
But if they are controlled together to go to 1 endpoint, something goes wrong in the synchronization.

((Console commands))
Connecting...
Printer is now online.
Using tool 0.

M502
SENDING:M502
echo:Hardcoded Default Settings Loaded
M500
SENDING:M500
echo:Settings Stored (806 bytes; crc 59371)
G28
SENDING:G28
G0 Z200
SENDING:G0 Z200
G0 X0 Y0 B20
SENDING:G0 X0 Y0 B20

#define HOTEND_OFFSET_X { 0.0, 0.00 } // (mm) relative X-offset for each nozzle.
#define HOTEND_OFFSET_Y { 0.0, 0.00 } // (mm) relative Y-offset for each nozzle.
#define HOTEND_OFFSET_Z { 0.0, 0.00 } // (mm) relative Z-offset for each nozzle

#define XYZBC_SEGMENTS_PER_SECOND 1000 //200

#define CLASSIC_JERK
#if ENABLED(CLASSIC_JERK)
#define DEFAULT_XJERK 150.0 //70.0
#define DEFAULT_YJERK 150.0 //70.0
#define DEFAULT_ZJERK 0.3
#define DEFAULT_IJERK 10.0 // 0.3
#define DEFAULT_JJERK 0.3

#define DEFAULT_MAX_ACCELERATION { 1000, 1000, 50, 50, 50, 10000 } // { 500, 500, 50, 25, 25, 10000 }

video.zip

[DerAndere1]

I suspect the function line_to_destination_kinematic() which is responsible for the segmentation of the move. On my machine, I have slight slowdowns between each segment. The frequency of slowdowns depends on the value of XYZBC_SEGMENTS_PER_SECOND.
Your machine seems to be more rigid so the slowdowns are less dampened. When I compare your last video with the previous video, the frequency of slowdowns is the same. Was the value of XYZBC_SEGMENTS_PER_SECOND already increased to 1000 for the last video?

[DerAndere1]

Maybe the hickups are caused if the block buffer runs empty. Try XYZBC_SEGMENTS_PER_SECOND 50 and set BLOCK_BUFFER_SIZE 32 in Configuration_adv.h

[HendrikJan-5D]

Your last suggestion solves the problem.

#define XYZBC_SEGMENTS_PER_SECOND 50 //1000 //200

#if BOTH(SDSUPPORT, DIRECT_STEPPING)
#define BLOCK_BUFFER_SIZE 32 //8
#elif ENABLED(SDSUPPORT)
#define BLOCK_BUFFER_SIZE 32 //16
#else
#define BLOCK_BUFFER_SIZE 32// 16
#endif

How and what to test with the G43.4 and G43.9 funties