HendrikJan-5D commented 2 years ago

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 commented 2 years ago

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

DerAndere1 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

It seems the P axis is always in relative mode. This seems to be related to issue https://github.com/DerAndere1/Marlin/issues/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 commented 2 years ago

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 commented 2 years ago

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.

Screen Shot 08-28-21 at 07 46 AM

Screen Shot 08-28-21 at 09 15 AM

DerAndere1 commented 2 years ago

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 commented 2 years ago

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

HendrikJan-5D commented 2 years ago

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.

Screen Shot 08-28-21 at 06 14 PM

DerAndere1 commented 2 years ago

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

DerAndere1 commented 2 years ago

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 commented 2 years ago

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

HendrikJan-5D commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

DerAndere1 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 Problem

DerAndere1 commented 2 years ago

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 commented 2 years ago

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

HendrikJan-5D commented 2 years ago

((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 commented 2 years ago

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 https://github.com/DerAndere1/Marlin/blob/de061ba5d1d1013ba3b118bf66c48ffc03399e8a/Marlin/src/gcode/bedlevel/abl/G29.cpp#L702)
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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

G29 AUTO BED LEVELING > LINEAR < also works

DerAndere1 commented 2 years ago

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 commented 2 years ago

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

HendrikJan-5D commented 2 years ago

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

I get Marlin-Marlin2ForPipetBot.zip

DerAndere1 commented 2 years ago

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

HendrikJan-5D commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/DerAndere1/Marlin/blob/cbc07e4a71d797c396e70561aa00b27bda30b7e9/Marlin/src/gcode/bedlevel/abl/G29.cpp#L251 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 https://github.com/DerAndere1/Marlin/blob/cbc07e4a71d797c396e70561aa00b27bda30b7e9/Marlin/src/gcode/bedlevel/abl/G29.cpp#L251 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Test report G29 change.txt

DerAndere1 commented 2 years ago

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 https://github.com/DerAndere1/Marlin/blob/cbc07e4a71d797c396e70561aa00b27bda30b7e9/Marlin/src/gcode/bedlevel/abl/G29.cpp#L251 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 commented 2 years ago

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

DerAndere1 commented 2 years ago

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 https://github.com/DerAndere1/Marlin/blob/cbc07e4a71d797c396e70561aa00b27bda30b7e9/Marlin/src/module/motion.cpp#L570 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 commented 2 years ago

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 commented 2 years ago

Test report Safe Probing Position.txt

DerAndere1 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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: https://github.com/DerAndere1/Marlin/commit/d7f8d076e1e3704267f16f867030e52606438745#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 commented 2 years ago

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 commented 2 years ago

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.

DerAndere1 / Marlin

Marlin-9axis_pull hardware test report Axes 8 and 9 #55

define MANUAL_I_HOME_POS -90