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.

[DerAndere1]

Very satisfying to watch :)

In the meantime I have uploaded the fixes mentioned above to the kinem2 branch.

When you update to the current version, the settings for the XYZBC_HEAD_TABLE kinematics will have to be renamed as follows:
XYZBC_SEGMENTS_PER_SECOND -> PAX_SEGMENTS_PER_SECOND,
XYZBC_PRINTABLE_RADIUS -> PAX_PRINTABLE_RADIUS
DEFAULT_MRZP_OFFSET_MM -> DEFAULT_MRZP_OFFSET_Z

In addition, I am in the process of adding kinematics for a 5 axis CNC machine in tilting rotary table configuration with axes XYZAC. It is not ready for testing in hardware. In my first draft I came up with these calculations which need to be verified on a calculator using example values:

Marlin/Marlin/src/module/penta_axis_trt.cpp

Lines 85 to 109 in 7266e35

	const float i_rad = RADIANS(pos.i);
	const float j_rad = RADIANS(pos.j);
	#if AXIS4_NAME == 'A'
	// computed position
	const xyz_pos_t joints_pos = NUM_AXIS_ARRAY(
	cos(j_rad) * (pos.x - mrzp_offset_x)
	- sin(j_rad) * (pos.y - mrzp_offset_y)
	+ mrzp_offset_x,
	sin(j_rad) * cos(i_rad) * (pos.x - mrzp_offset_x)
	+ cos(j_rad) * cos(i_rad) * (pos.y - mrzp_offset_y)
	+ sin(i_rad) * pos.z
	+ mrzp_offset_y,
	sin(j_rad) * sin(i_rad) * (pos.x - mrzp_offset_x)
	+ cos(j_rad) * sin(i_rad) * (pos.y - mrzp_offset_y)
	+ cos(i_rad) * (pos.z - mrzp_offset_z)
	+ mrzp_offset_z,
	joints_pos.i = pos.i,
	joints_pos.j = pos.j
	);
	#endif

[DerAndere1]

It would be nice to have a demo video showcasing the G43.4 command. Are you interested in licensing a short video under a liberal license like the Creative Commons Attribution ShareAlike License (CC-BY-SA-4.0)?

[HendrikJan-5D]

I will make a video for you to license the G43.4 command.
But first I want to do some more testing.
To clarify what is causing the mechanical deviation,
at the combined X Y B C Z axis displacement .
I see a deviation in the Z height,
and a deviation in the circle position.
It is not yet clear to me if this is caused by the mechanics or by the firmware calculations.

[DerAndere1]

You could try the M665 command that I extended to be able to fine-tune the machine rotational center point Z offset (MRZP). For the XYZBC_HEAD_TABLE setup with a single hotend, the MRZP is the pivot length of the tool head (measured from the joint of the B axis to the nozzle tip). The default value is given by DEFAULT_MRZP_OFFSET_MM and can be adjusted with the M-code M665 O<value>. In the latest version of the kinem2 branch this changed to DEFAULT_MRZP_OFFSET_Z and the associated command M665 Z<value>.

[DerAndere1]

if that does not help, it might be that you have to adjust settings [X/Y/Z]_MIN_POS and [X/Y/Z]_MAX_POS until the 0 position after homing is exactly at the center of the bed surface. Otherwise it could be a rounding error in firmware.

[hobiseven]

Hi That reminds me the error I was getting initially where the printer was not getting back to the initial position due to a small error in one of the piece of code in planner.cpp. Does each individual axis return to their exact initial position after many back and forth moves? Error was accumulating on I or j axis and resulted in a few steps off…. Olivier Briand / NXP Semiconductors

…

On 4 Nov 2022, at 10:51, HendrikJan-5D ***@***.***> wrote:  I will make a video for you to license the G43.4 command. But first I want to do some more testing. To clarify what is causing the mechanical deviation, at the combined X Y B C Z axis displacement . I see a deviation in the Z height, and a deviation in the circle position. It is not yet clear to me if this is caused by the mechanics or by the firmware calculations. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[HendrikJan-5D]

I also saw that error ,
but then thought I caused it myself.
After going back with G49 I found that the 0 position of the Y axis was not the same as before.
I am taking an additional look at this.

[HendrikJan-5D]

I downloaded your latest version kinem-2.
And modified the following in configuration.h.
XYZBC_SEGMENTS_PER_SECOND -> PAX_SEGMENTS_PER_SECOND,
XYZBC_PRINTABLE_RADIUS -> PAX_PRINTABLE_RADIUS
DEFAULT_MRZP_OFFSET_MM -> DEFAULT_MRZP_OFFSET_Z

And get a compiler error see info
.
Compiler Error.zip

[HendrikJan-5D]

Hardware and software testing for TCPC and G codes G43.4 / G49

Hardware Software testing.zip

[DerAndere1]

Thanks for the reports!!! Do I understand correctly that the last video can be used (shared with others) under the terms of the Creative Commons Attribution ShareAlike License, Version 4.0 ?

I updated the kinem2 branch again to fix compilation. I was able to compile it with your latest configs after changing values of HOTEND_OFFSET_X, HOTEND_OFFSET_Y and HOTEND_OFFSET_Z so they look like this:

#define HOTEND_OFFSET_X  { 0.0 } 
#define HOTEND_OFFSET_Y  { 0.0 }
#define HOTEND_OFFSET_Z  { 0.0 }

Note that the number of elements in these arrays must match the value of TOOLS (in your case 1)

Segments per second can now be changed at runtime using M665 S<value>

Currently, the G43.4 command must be followed by a move command that explicitely specifies the desired tool position for ALL axes, i.e. a complete G1 X... Y... Z... A... B... . Similarly, it may be unsafe to start TCPC mode while in relative positioning mode, so best send a G90 before the G43.4. This is generally good practice. Haas writes about their TCPC command:

Quote from https://www.haascnc.com/service/codes-settings.type=gcode.machine=mill.value=G234.html

When starting TCPC it is safest to establish a new XYZ

[HendrikJan-5D]

Yes You understand correctly that the last video can be used (shared with others) under the terms of the Creative Commons Attribution ShareAlike License, Version 4.0 ?.
Do I need to send you the original video via We Transfer for this.
Or can you down load the YouTube video for this.
I would like to make the video public linked to my YouTube Chanel 7 Axis 5D printer.
Could you indicate for me the best title to use for this.
And make a description of what the video shows
And what the next developments are.

[DerAndere1]

No file transfer needed.
I cannot give you the best title but a selection to choose from:

• "Testing TCPC on my 5D printer"
• "5D printer with tool center point control"
• "Testing TCPC on my multi-axis 3D printer"
• "Multi axis 3D printer with tool center point control"

Suggestion for the video description:

Test of the tool center point control (TCPC) function that was added to a development version of Marlin firmware.
The new G-codes G43.4 (enable TCPC) and G49 (disable TCPC) make continuous multi-axis operation of 3D printers easier.

Marlin2ForPipetBot firmware by DerAndere: https://github.com/DerAndere1/Marlin/tree/kinem2
Firmware documentation: https://github.com/DerAndere1/Marlin/wiki
Test G-code:

M121
G49
G1 X0 Y0 Z21 F1500
G1 X-100
G1 X100
G1 X0
G1 Y-100
G1 Y100
G1 Y0
G1 B45
G1 B0
G1 C360
G1 C0
G43.4
G1 B45
G1 B0
G49
G1 X100
G43.4
G1 C360
G1 C0
G1 B45 C360
G1 B0 C0
G49
G1 X0 Y0

[DerAndere1]

Regarding further developments, I cannot guarantee much.
I plan to finish kinematics and TCPC for the tilting rotating table configuration. But I will be more busy at my day job so it is unclear how much time I can spend with this. Then I will add the new features to the next tagged release of Marlin2ForPipetBot firmware, together with updated documentation. In the long run I will try to get bed leveling working with 5 axis machines. However, I will need help by other devs that know the bed leveling code. And then add forward kinematics for better position reporting.

[DerAndere1]

For your interest: another interesting aspect of the current kinem2 branch are improvements related to automatic tool changers and machines that combine 3D printing and milling. The value of the new option TOOLS can be equal or greater than EXTRUDERS. thus the lower tool indices can be used for extruders, higher tool indexes can be used for other tools. Tool length offsets and hotend offsets can now be set with the commands G10 L1 P<tool index> Z<tool length offset> or G10 L10 P<tool index> Z<value> like in LinuxCNC. By default, tool length compensation is off, but with G43.4 (for multi axis machining) or G43 ( for 3 axis machining), tool length compensation is on.

[HendrikJan-5D]

I reconfigured your latest version.
And get regular error message after code G49.
This only happens when I offer a whole G code batch.
If I output the G codes one by one it goes fine.
When it goes wrong I get the following message.
Got rubbish reply from COM7 at baud rate 115200:
Maybe a bad baud rate?

Connecting...
Printer is now online.
Using tool 0.
SENDING:M121
SENDING:G49 ------> Here it is going well
SENDING:G1 X0 Y0 Z21 F1500
SENDING:G1 X-100
SENDING:G1 X100
SENDING:G1 X0
SENDING:G1 Y-100
SENDING:G1 Y100
SENDING:G1 Y0
SENDING:G1 B45
SENDING:G1 B0
SENDING:G1 C360
SENDING:G1 C0
SENDING:G43.4
SENDING:G1 B45
SENDING:G1 B0
SENDING:G49 --------> Here it is going well
SENDING:G1 X100
SENDING:G43.4
SENDING:G1 C360
SENDING:G1 C0
SENDING:G1 B45 C360
SENDING:G1 B0 C0
SENDING:G49 ----> After this, things go somtimes wrong.
SENDING:G1 X0 Y0
Got rubbish reply from COM7 at baudrate 115200:
Maybe a bad baudrate?

[DerAndere1]

As you describe the issue, it repeatedly happens at the same command. This points to a firmware issue rather than hardware (loose/broken usb cable, too high baudrate). It is always recommended to have command M400 after the final move command. For debugging. send M111 S1 at the start of the Gcode script and see if you get the expected "OK" echos after each command, Maybe you could try increasing config setting BUFSIZE in Configuration_adv.h, I will try to reproduce

[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